Utilisation de Mobac pour générer des tuiles RMAP à partir OrthoPhotos IGN en ligne ?

Kommentare

41 Kommentare

  • Avatar
    FREDERIC ALONSO

    Bonsoir et merci pour la longue réponse.

    Probablement j'ai mal expliqué ce que j'essaye de faire. Et je dois faire les choses de façon incorrecte car je n'arrive pas bien au résultat que je souhaite. Alors je vais essayer d'expliquer ce que je fais en détails.

    Mon attente est de pouvoir sélectionner par exemple toute l'Ile de France en un seul bloc (comme dans IGNmap) et avoir en sortie directement un milliers de petites dalles RMAP qui s'assemblent dans une carte IMP.

    Tout d'abord, je ne prends que des sélection rectangulaires, donc cela n'est pas le problème.

    Mais comme il est pas possible de choisir une zone plus grande que 500k tuiles, je ne peux sélectionner qu'une partie de l'IDF, par exemple la sélection ci-dessous qui fait 488480 tuiles

    Cette sélection a été faite en zoom 19 (je souhaite la résolution max) :

    Dans mon atlas, je ne prends également qu'un seul niveau de zoom (également 19 donc niveau ortho-photos) ; donc le multi-zoom n'est pas non plus le problème :

    Ensuite, c'est la que ça bloque.

    1. Soit je choisis la taille maximale des cartes au max (comme ci-dessous) : en général cela marche. Mais au résultat j'ai un seul fichier RMAP pour toute la zone (18Gb), ce qui n'est pas l'objectif.

     

    2. Donc j'ai essayé en réduisant cette taille maximale, par exemple à 15000 en espérant que cela couperait automatiquement ma sélection en multi-cartes RMAP de cette dimensions, comme dans IGNmap...

    Mais là ça plante :

     

    Quelques questions par rapport à vos remarques:

    >> la génération de la carte, plus elle est importante, plus les dérives de calibration se cumulent (il y en a toujours, ne serait-ce qu'à cause des arrondis de calcul). Avec des tuiles de taille raisonnables, la jointure et la calibration est de meilleure qualité.

    C'est un point important que m'avait souligné le concepteur d'IGNmap qui a eu la gentillesse de répondre à mes nombreuses questions. Même avec un PC, les calculs en virgule flottante génèrent un risque d'arrondi et de décalage.
    Pour éviter cela, il faut sélectionner une zone avec "chiffres ronds" et dans IGNmap cela se fait de façon automatique (le fameux petit bouton "km" que j'explique dans mon Tuto, qui permet d'ajuster automatiquement la sélection en "km ronds", du coup il n'a plus de problème de calcul car les divisons en sous-dalles se font sur des chiffres entiers, aucun arrondi).

    Peut-être est-ce le même problème avec Mobac : il faut que la largeur et la hauteur de la sélection soient des multiples "ronds" de la taille des tuiles de sortie (15000 dans mon essai ci-dessous) ??

    Comme il n'y a pas le fameux bouton magique "km", je suppose qu'il faille entrer manuellement la taille de la sélection dans la zone en bas à gauche. Est-ce cela le truc ? Mais comment faire ?...

    Faut-il sélectionner le format "tuile x/y" comme ci-dessous :

     

    >> Bien évidement, pour une partie plus étendue de carte, il faut ajouter des sélections, ça va générer autant de RMAP. Mais ça, c'est l'usage normal des RMAP, on les regroupe dans un répertoire, et on fait un .IMP avec wildcards pour les ouvrir tous.

    Cette information semble vouloir dire que ce que je cherche à faire au-dessus est impossible. Est- ce que cela veut dire qu'il faille faire des petites sélections une par un des tuiles finales souhaitées et les ajouter dans l'atlas, et ainsi Mobac génèrera autant de fichier RMAP que de petites sélections ajoutées dans l'atlas ?

    Si c'est cela la solution, c'est difficile à envisager pour un département ; il y a plus de 1000 tuiles RMAP en taille 12500x12500 pixels résolution 20 cm pour un département moyen... impossible de faire ces sélection une par une et les ajouter à l'atlas. 

    Je suis sûr que je suis passé à côté de la solution... c'est pourquoi j'attends beaucoup de cet échange.

    Bonne soirée confinée

    Fred

     

     

     

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Maxime Muller

    Perso, je n'utilise pas plusieurs échelles pour mes cartes Mobac donc pas besoin de me compliquer, en général je sauvegarde au niveau 15 pour une carte topo IGN ce qui est très lisible sur mon Anima+. Pour la grandeur des cartes je me limite à 1Go (cela représente une très grande surface sur le terrain) sinon MAPC2MAPC ne veut pas les prendre.

    J'utilise aussi MAPC2MAPC pour transformer mes RMAP en JNX compatible Garmin et de JNX je passe en IMG directement compatible Garmin (sans patcher le firmware du Garmin) avec un petit logiciel JNX2IMG bien pratique.

    0
    Aktionen für Kommentare Permalink
  • Avatar
    FREDERIC ALONSO

    Merci Bernard

    Entre temps, j'ai fait d'autres tests pour essayer de comprendre le bug, mais cela me donne des résultats non compréhensibles.

    J'ai choisi pour mon test la limitation à 25000 pixels pour la dimensions des cartes de sorties ("Outils" dans Mobac).

    Ensuite j'ai cherché quelle devrait être la taille de ma sélection pour que cela corresponde pile à la dimensions maxi des cartes (ou un multiple exact de cette dimension maxi): 

    - Je suis en zoom 19, donc résolution 0.2m par pixels
    - La taille des tuiles source est de 50m en zoom 19 (vérifié en faisant un essai sur une seule tuile)
    - Donc une tuile source fait 250 pxiels (= 50 / 0.2) de côté
    - En théorie, si je sélectionne un carré de 100x100 tuiles Z19, cela doit faire 25000 pixels de côté, soit très précisément la taille maxi de la carte de sortie.
    - Mon idée était donc de ne sélectionner que des zones rectangulaire avec des côtés multiple de 100 tuiles Z19.

    >> J'ai fait le test avec un carré de 100x100 tuiles (donc normalement la dimensions exacte de la carte maxi), mais j'ai le fameux blocage  "all maps in one layer have to cover the same area".

    Ensuite j'ai fait des tests en réduisant progressivement la taille de la sélection. Conclusion : jusqu'à 96x96 tuiles c'est bon ça marche. Mais à partir de 97 tuiles, ça plante. La dimension de 96 tuiles est de 96x50m= 4800m, soit 24000 pixels en zoom 19. Celle de 97 tuiles 4850m soit 24250 pixels, ce qui est en dessous de la taille limite choisie au départ, donc cela devrait me sortir une seule carte sans pb.

    Je n'arrive pas à comprendre pourquoi il y a ce problème "all maps in one layer have to cover the same area"  alors que je n'ai qu'un seul layer, qu'un seul zoom (Z19) et que je sélectionne très précisément 100x100 tuiles z19soit la dimension exacte 25000 pixels.

    Cela va s'en dire que j'attends impatiemment les explications du pourquoi et du comment faire différemment...

    Cordialement

    Fred

     

    0
    Aktionen für Kommentare Permalink
  • Avatar
    FREDERIC ALONSO

    Re_bonjour

    Suite des tests.

    Avec les mêmes paramétrage que dans le post précédent, mais en prenant une sélection carrée de 200x200 tuiles Z19 toujours avec taille de carte maxi 25000 pixels et j'ai tenté une sortie en format PNG+MAP (OziE) ; la sortie s'est fait sans problème.

    Mais au lieu d'obtenir 4 sous-dalles (en effet, 200 tuiles Z19 cela fait 200 x 250 = 50000 pixels, soit 2 fois la taille maxi de 25000 pixels), j'ai obtenu 9 fichiers.

    J'ai donc ouvert les cartes obtenues dans Land et j'ai compris le problème. Il y a bien les 4 sous-dalles carrées attendues, mais en plus des étroites dalles sur le bord (voir image Land).

    Et surprise, surprise, je découvre que les tuiles PNG, qui devraient faire 25000 pixels, ne font que 24 832 pixels. Il semble que Mobac ne génère pas des tuiles de 25k pixels , mais légèrement plus petites !!! Donc du coup, cela ne tombe jamais juste sur la dimensions des dalles source d'IGN.

    Cela n'a rien à voir avec le format RMAP (ici c'est du PNG !) mais c'est bloquant avec le RMAP car il faut que cela colle.

    De plus, comme on le voit sur la copie d'écran ci-dessous, Land voit 0.19 m/pixel de résolution alors que la carte devrait être en 0.2m (résolution IGN). Le problème pourrait bien être cela aussi ?

     

    Je vais continuer mes investigations en attendant de lire vos autres possibilités de faire cela d'une autre façon...

    Cordialement

    Fred

     

     

     

    0
    Aktionen für Kommentare Permalink
  • Avatar
    FREDERIC ALONSO

    Bonsoir

    Que dire... 

    Je viens de faire un essai sur 3 tuiles sélectionnées en Z13 et converties en RMAP-Z19 et effectivement ça marche nickel

    C'est d'une telle simplicité que je ne comprends pas ne pas avoir trouvé l'explication dans la Doc. Cela parait simple quand on sait. Moi je suivais ce que j'avais lu : je dessinais un cadre avec la souris et je pensais que c'est Mobac qui aller les redécouper en tuiles selon la taille max, au lieu de rajouter une par une les dalles dans l'atlas. C'est bête que j'ai perdu tant de temps là-dessus.

    Cette approche est très simple en effet mais une petite contrainte quand même : je souhaite  que mes cartes aient une petite dimension, par exemple celle d'une tuile Z13. Du coup pour faire une grande surface, il faut ajouter une à une dans l'atlas potentiellement des dizaines/centaines de tuiles Z13... Peut-être je vais être obligé de passer à des tuiles de taille Z11 pour un département et accepter d'avoir des rmap plus gros.

    Je vais lancer cela ce soir... :-)

    Merci de m'avoir aiguiller sur la bonne voie !

    Fred_

     

    0
    Aktionen für Kommentare Permalink
  • Avatar
    FREDERIC ALONSO

    @Bernard Perrot

    Bonsoir,

    Taille Z11 est un peu trop gros pour moi, mais sélectionner une par une les très nombreuses dalles Z13 serait très fastidieux, trop long. 
    Donc je pense que je vais faire la taille Z12, qui est je crois la taille initiale des dalles IGN JPEG2000 environ 30k pixels de côté (que j'ai réduit en 4 sous-dalles de 12500 pixels de côté avec IGNmap (cf autre post). Je pense que Z12 sera le bon compromis.

    Il ne me reste plus qu'à trouver le temps de préparer cela dans Mobac... Heureusement il y a du temps avant la prochaine sortie VTT :-(

    En tout cas, grand merci !

    -------------

    Proposition d'une fonctionnalité bien cool à rajouter à Mobac : après avoir fait une sélection à la souris d'un ensemble de tuiles, avoir un autre bouton "Ajouter la sélection sous forme de cartes séparées", en plus du bouton "Ajouter la sélection" dans le bloc "Contenu de l'atlas".

    Cela permettrait de rajouter d'un seul coup toutes les tuiles définies par la sélection à la souris dans l'atlas, mais chaque tuile du zoom choisi serait ajoutée sous forme de fichier distinct, pour automatiser en un seul clic la sélection de centaines de tuiles une par une et mise dans l'atlas avec le bouton "Ajouter la sélection".

    J'ai imaginé ce bouton supplémentaire dans la simulation ci-dessous... si le concepteur de Mobac lit ce forum :-)

     

    Cordialement

    Fred

    0
    Aktionen für Kommentare Permalink
  • Avatar
    FREDERIC ALONSO

    @Bernard Perrot
    il est bien de les renommer en .rtmap (juste renommer), ça évite sur les GPS de voir les dalles dans le menu, mais seulement le .imp.

    Trop génial !!!

    Malgré plusieurs recherches sur le web, je n'avais pas réussi à comprendre la différence entre les 2 extensions. J'avais fait un test en changeant mes cartes en rtmap, en espérant que Land serait plus rapide à l'ouverture des fichiers, mais je n'avais vu aucune différence.

    Maintenant je comprends ! Effectivement c'est galère de voir le nom de toutes ses cartes dans la liste sur le GPS ; d'autant que comme je n'utile que des cartes toutes petites, cela fait des centaines de cartes ! Afin de retrouver facilement mes fichier IMP, je les nommer toujours avec un tiret au début "- xxxx.imp" afin qu'ils apparaissent toujours en haut de la liste de toutes mes cartes.

    Maintenant je sais à quoi sert cette extension :-)

    Je vais renommer tout ça et faire un test sur mon GPS avant la prochaine sortie. Et si j'ai bien compris, je ne verrai plus que quelques noms de cartes dans ma liste sur le GPS.

    Bonne soirée

    fred_

     

     

    0
    Aktionen für Kommentare Permalink
  • Avatar
    FREDERIC ALONSO

    Note complémentaire :

    Je viens de finaliser la sélections en tuiles Z12 de toute l'Ile de France. Un peu fastidieux mais finalement très facile. J'ai voulu lancer la conversion pour cette nuit. Mais déception : la taille maximale de 500 000 tuiles source vaut pour l'atlas entier, pas pour caque carte, du coup cela bloque (j'ai 10 fois trop !).

    J'ai enregistré mon atlas et sauvegardé sous nouveau nom en ne gardant que 10% des dalles. Et là ca marche. Il faudra que je lance 10 conversions. C'est parti.

    fred

     

    0
    Aktionen für Kommentare Permalink
  • Avatar
    FREDERIC ALONSO

    Bonsoir

    Petite question aux connaisseurs de Mobac :

    Je souhaite avoir un atlas de cartes de ma région (cf posts précédents) mais il n'est pas possible de le télécharger en une seule fois à cause de la limitation de 500k tuiles. Du coup j'ai coupé le travail en plusieurs morceaux.

    Au lieu de créer directement les cartes en RMAP, j'ai choisi l'option de sortie "tile store download only" qui permet de télécharger les cartes en cache sans les traiter, dans le répertoire "tilestore". Une fois des différentes passes terminées, j'ai toutes les tuiles dans ce cache local (fichiers .jdb) sur mon disque.

    Mais, même en ayant toutes les tuiles en local (donc plus besoin d'aller sur le serveur Internet), il est toujours impossible de faire la transformation en RMAP en une seule fois, à cause de la limitation arbitraire à 500k, qui est vraiment inutile dans ce cas, puisque 100% des tuiles sont sur mon disque dur. Je pense que c'est parce que Mobac utilise les cartes locales quand elles sont présentes, mais garde active l'option d'aller sur le serveur externe chercher les manquantes.

    Ma question est donc la suivante : est-il possible de créer un fichier .bsh dans "mapsources" qui pointerait vers le disque dur local (vers le répertoires de cache des cartes déjà téléchargées par petit bout) et permettrait de traiter une zone supérieure à 500k tuiles, ce qui ne serait nul problème pour le serveur externe puisque ce serait un travail purement local ?

    Si pas possible, je ferai la conversion RMAP par petit bout comme j'ai fait le download des tuiles, mais c'est vraiment absurde cette limitation pour des cartes locales sur mon disque dur.

    Cordialement

    fred

     

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Maxime Muller

    Bonjour,

    Ce n'est pas le fichier *.bsh qui bloque les cartes de plus de 500Ko, perso, je n'ai pas cette limitation avec les RMAP, certaines de mes cartes pèsent 700Ko.

    Cordialement,

    Maxime

    0
    Aktionen für Kommentare Permalink
  • Avatar
    FREDERIC ALONSO

    Bonjour

    Merci pour la réponse. 700Ko... On n'est pas du tout dans le même ordre de grandeur... J'ai 60Go en fichier .jbd dans le répertoire titlestore, 6400 tuiles .jbd à résolution Z19 et de dimension Z12, stockées en local, ce qui correspond à environ 6400 x 16384 tuiles sources sur Mobac Z19...

    La limitation de 500k est dans le code source qui est disponible sur Internet (même avec un bas niveau de codage informatique, il est facile d'isoler la boucle qui compare le nbr de tuiles à 500k). Je sais que certains ont changer ce code (cela semble très simple) et recompiler le code java. 

    Cette limitation à 500k est là pour une bonne raison : éviter d'engorger les serveurs (IGN par exemple) avec un nbr massif de téléchargement. Mais elle est totalement absurde avec des cartes locales.

    D'où ma question : est-il possible de créer un fichier .bsh qui pointerait vers mon répertoires de cartes locales au lieu du serveur IGN ?

    J'ai lu quelque part sur un Forum que cela est possible : si par exemple on a un répertoire de cartes venant d'un autre logiciel, tout en local ; dans le même forum il disait que la limitation est alors inactive (logique encore une fois).
    Mais il n'y a pas le script à mettre dans le fichier .bsh donc je ne sais pas comment on fait. Et je ne sais pas non plus si les tuiles temporaires .jbd seront reconnues en tant que cartes pouvant être importées en tant que cartes externes.

    L'autre solution est de modifier le script java, mais je m'y refuse (d'autres l'ont déjà fait).

    Cordialement

    fred

     

     

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Maxime Muller

    Bonjour,

    Quel intérêt de fabriquer des cartes de ce volume ? 

    Je ne vois pas de fichier bsh concernant ton problème, il y a le forum Trekbuddy http://www.trekbuddy.net/forum/viewtopic.php?t=7215&postdays=0&postorder=asc&start=0  qui donne des infos mais je n'ai jamais rien lu concernant ton bsh.

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Maxime Muller

    Bonjour,

    Je rajouterai que le Z15 (sur cartes topo IGN) est suffisant et pour Land et pour les GPS, grossir n'apporte pas plus de détails puisque c'est une carte raster. Ne pas oublier qu'un millimètre correspond à 25m sur le terrain, grossir ne fait que grossir les traits mais ne donne pas plus de précision.

    Ou bien utiliser les photos aériennes Google Earth qui permettent de zoomer davantage que celles de l'IGN.

    Cordialement,

    Maxime

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Maxime Muller

    Zoom 15 que faut-il de plus......

     

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Maxime Muller

    OK pour les carte otho.....Z19 est un bon compromis avec Google Earth et l'IGN Ortho.

    Maxime

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Maxime Muller

    Il semble que j'ai des bsh IGN qui sont illimités et ce depuis longtemps....Est-ce possible ?

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Maxime Muller

    Pourquoi dans le code de Mobac, n'est-ce pas plutôt l'IGN qui calcule le téléchargement en fonction de la clé ?

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Maxime Muller

    Dans configuration de Mobac il est dit ceci :

    On peut télécharger une taille maxi (largeur et hauteur) de 1408575, ça signifie quoi en fait ? Est-ce en tile, en mètre, on ne sait pas.Un tile fait dans les 10Ko.

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Maxime Muller

    C'est en bas, décidément je ne vois pas clair... Ce doit être la taille du tile...1048575 pixels fait un tile de 1024x1024.

    Il faut demander au concepteurs si il y a un blocage.

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Maxime Muller

    Sur le forum Mobac Guithub, il y a une question  :

    "Chers tous.

    J'ai récemment créé une nouvelle source de carte mbtyles locale sur mon PC.

    J'essaie de créer une carte en utilisant plusieurs couches, et le nombre total de styles est supérieur à 500000.

    J'ai essayé de trouver le moyen d'éviter cette limitation sans succès.

    Pourriez-vous éventuellement me donner les instructions pour résoudre ce problème?

    Merci d'avance,

    Carlos."

    Il n'y a pas de réponse......

    0
    Aktionen für Kommentare Permalink
  • Avatar
    stephane leroy

    Bonjour, je suis certainement "un peu" hors sujet, n'utilisant MOBAC que pour une autre utilisation pour une autre application, mais...
    Concernant la "récupération" de données cartographiques, connaissez vous ça?
    http://fcgp.e-monsite.com/
    Bonne continuation

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Maxime Muller

    Merci pour le lien. J'ai essayé mais ça ne me plait pas car pas d'enregistrement en RMAP ou Oziexplorer.

    Cordialement,

    0
    Aktionen für Kommentare Permalink
  • Avatar
    FREDERIC ALONSO

    Bonjour

    Bon... probablement je me suis mal exprimé. Voilà mon cheminement:

    - Depuis le début on ne parle que d'OrthoPhotos en effet, donc Z15 est exclu. J'ai bien noté qu'en Z18 j'en aurais 4 fois moins qu'en Z19, mais je souhaite rester en Z19 car toutes mes autres cartes (dispo gratuitement et sans limite de téléchargement directement sur le site IGN (cf plus bas)) sont en Z19. Ce n'est pas pour le GPS mais pour utilisation sur mon PC quand je n'ai aucune liaison Internet (vacances).

    - Moi aussi je n'utilise que des IMP avec des petites cartes. La limite de 500k n'a absolument rien à voir avec un souhait de faire une grosse carte. En réalité, c'est juste l'inverse : je cherche au contraire à avoir des cartes plus petites que  d'une dimension maxi d'un carré Z12. 
    - J'ai sélectionné chaque dalle Z12 une par une, et ajoutée une par une dans l'atlas ; exactement selon la méthode expliquée par Bernard qui fonctionne nickel. J'ai donc un atlas avec plein de petites cartes de tailles Z12 qui deviendront mes petites cartes RMAP pour mon IMP.
    - Mais le problème c'est que cet ensemble fait environ 10 fois 500k tuiles ; or la limite n'est pas pour chaque carte mais pour tout l'atlas. Donc je ne peux pas le traiter d'un seul coup.

    - Donc, j'ai  créé plusieurs atlas (une dizaine), toujours avec des petites cartes de dim Z12, et comme indiqué je les ai téléchargé un par un en sortie "tile store download only". J'ai tout en local maintenant en format .jpd.
    - Ensuite il est possible de convertir chaque atlas en rmap, un par un (c'est ce que je suis en train de faire). Ensuite je récupère tous mes petits rmap et je mets tout cela dans un IMP.

    >> Ce que je cherchais c'était la possibilité de recréer un seul atlas avec toutes les 6400 .jbd de dim Z12 qui sont physiquement sur mon PC (obtenus comme indiqué par sortie "tile store download only") et à les convertir en un seul bloc. Cela représente donc 10 fois 500k tuiles sources mais cela ne générerait aucune bande passante puisque tout est en local.
    J'espérais qu'il y ait une solution simple pour faire cela (l'idée de débrider les 500k était juste pour le traitement local et je suis pleinement d'accord qu'il serait incorrect de le faire pour le téléchargement ; de toutes les façons, je ne sais pas le faire...).

    Comme apparemment c'est compliqué (merci à Bernard d'avoir suggéré un lien pour créer un xml mais je ne me sens pas d'attaque...), je continue ma conversion un par un des 10 atlas et je réunirai ensuite les rmap dans un IMP. Un peu fastidieux mais en fait assez rapide puisque que j'ai toutes les tuiles en local, donc cela converti direct sans Internet.

    Sujet clos donc.

    -------------

    De façon générale, je n'utilise Mobac que pour les département qui ne sont pas en téléchargement gratuit directement sur le site IGN, en qualité Z19 sous format JPEG2000. Notamment ma région n'est pas dispo. :-(

    Mais quand le département recherché est dispo sur IGN, je préfère prendre les JPEG2000 (sans limite aucune de téléchargement !) j'utilise la méthode JPEG2000>TIFF>RMAP décrite dans mon Tuto qui permet de convertir en même temps des très grandes surface en haute qualité sans limite de taille (par contre c'est long).

    Pour référence, je donne le lien légal où trouver les JPEG2000:
    https://geoservices.ign.fr/documentation/diffusion/telechargement-donnees-libres.html
    Pas tous les départements mais quand même pas mal de choix.

    -------------

    Encore merci à tous et vivement qu'on puisse sortir pour tester nos cartes sur nos GPS !!

    Fred

     

    0
    Aktionen für Kommentare Permalink
  • Avatar
    FREDERIC ALONSO

    Note pour Bernard

    J'ai quand même regardé votre lien sur les fichiers XML pour créer une carte locale. Comme vous l'indiquez, en effet ils parlent d'utiliser le format Sqlite.

    Malheureusement avec l'option de sortie "tile store download only"  que j'avais choisie (j'avais vu cela comme un téléchargement sans conversion, donc plus rapide avant de convertir après coup), j'ai des fichiers .JDB ; mais je n'ai rien vu concernant l'utilisation de ce format (sûrement propre à Mobac comme fichiers temporaires) pour faire une utilisation locale via XML.

    Bon je le saurai... le mieux c'est de rester sur des atlas de moins de 500k et assembler ensuite, comme finalement je l'ai fait.

    Entre temps, j'ai fini de convertir mes 10 atlas de petites cartes en RMAP, je vais les réunir dans un seul dossier et tester via IMP dans Land un peu plus tard. Normalement la région sera prête :-)

    Bonne soirée

    0
    Aktionen für Kommentare Permalink
  • Avatar
    FREDERIC ALONSO

    Bernard

    Merci. Même si j'ai déjà converti tout au format RMAP (et mon IMP marche nickel, super rapide), ej vais essayé de mettre 2 atlas de 30 tuiles Z12 .JBD en SQlite pour ensuite tester si je peux les réunir en un seul atlas et les transformer en RMAP sans la limite 500k.

    Mais j'ai noté qu'il y avait de nombreuses sorties SQlite possible dans Mobac.
    Savez-vous laquelle il faut sélectionner ?

    Cordialement

     

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Maxime Muller

    Une question, pourquoi utiliser Sqlite avec Locus, les Rmap vont très bien, pourquoi s'embêter avec deux fichiers cartes au lieu d'un ? Avantages ?

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Maxime Muller

    OK, merci, donc pour mon usage je n'y vois aucun avantage car je n'ai pas besoin de grosses cartes, je les fabrique à la demande en fonction de la région où je dois aller.

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Maxime Muller

    Je répond juste pour dire que l'affichage des cartes en RMAP sous Locus avec mon smartphone est extrêmement rapide et d'une fluidité sans comparaison, j'ai un Xiaomi MI9 le processeur joue aussi dans la rapidité.

    0
    Aktionen für Kommentare Permalink
  • Avatar
    FREDERIC ALONSO

    Bernard

    En suivant les instructions, j'ai créé une base SQLite en l'alimentant par 2 des atlas .jbd de mon cache (chacun fait de 30 cartes .jbd de dimension Z12 en résolution Z19 chacun couvrant environ 480k tuiles). Puis j'ai créé le XML.

    Mon problème initial était que, n'étant alimenté que par des info en Z19, il n'est pas possible de visualiser quoique ce soit (sauf en zoom 19, mais à ce niveau de zoom, impossible de retrouver les dites cartes car le zoom 19 couvre une toute petite surface).

    Pour contourner le pb, j'ai rajouté des cartes faibles résolution de grande dimension à mon SQLite. Cela a marché : à l'ouverture de l'XML, j'ai pu me positionner correctement au bon endroit.

    Ensuite, par tâtonnements, j'ai créé un nouvel atlas avec 40 cartes de dimension Z12 en résolution Z19 (il fallait que ma sélection soit des cartes présentes dans le SQLite, donc dans les 2 atlas initiaux ajoutés dans le SQLite). J'ai réussi à créer un atlas de 655k tuiles (voir copie d'écran) :

    J'ai lancé un début de conversion RMAP :

    Et miracle : la conversion d'un atlas de 655k tuiles est possible, il n'y a pas la limite des 500k quand on travaille sur des données locales dans une base SQLite !!!

    Conclusion : mon seul soucis est celui indiqué au départ ; toutes mes cartes en cache (fichier JBD obtenus par sortie "tile store download only") ne contiennent qu'une seule couche Z19 donc on ne peut les visualiser à l'écran qu'en zoomant à 19, mais à ce niveau de zoom, il est impossible de sélectionner une zone à exporter.

    Donc dès le départ, il faut mettre des couches avec niveaux de zoom bien inférieurs (par exemple Z8/9 et Z12) quand on télécharge le cache pour alimenter le SQLite (ou alors les rajouter après coup comme j'ai fait).

    >>> A ce propos, j'ai une question : est-il possible d'ajouter des couches de zoom supplémentaires aux cartes d'un atlas existant ??
    Ce que je veux dire c'est que dans mes atlas initiaux chaque carte (cf "Tuile taille Z12 xx" dans ma copie d'écran ci-dessous) contient seulement une seule couche en Z19. Est-il possible d'ajouter d'autres couches (par exemple Z12 et Z8) sans avoir à re-sélectionner chaque dalle et la rajouter de nouveau ?

     

    Sinon manuellement dans le fichier mobac-profile-.xml de l'atlas :

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <atlas version="1" name="NA Region" outputFormat="TwoNavRMAP">
    <Layer name="Tuile taille Z12 -_1">
    <Map maxTileCoordinate="66781183/47251455" minTileCoordinate="66748416/47218688" mapSource="- France IGN Topo &amp; Ortho" zoom="19" name="Tuile taille Z12 -_1 19"/>

    En modifiant avec un éditeur de texte ce fichier atlas pour ajouter d'autres niveaux de zoom ?

     

    Bon encore plein de questions donc... mais en tout cas, il est prouvé que la limite des 500k n'existe pas pour des données locales dans un fichier SQLite. :-)

    Cordialement

    Fred

     

     

     

     

    0
    Aktionen für Kommentare Permalink
  • Avatar
    FREDERIC ALONSO

    Bonsoir Bernard

    Je n'osais pas revenir avec d'autres questions... mais puisque c'est vous qui relancez :-)

    Voici mon objectif et mes essais : 

    - Comme IGN ne met pas en téléchargement massif gratuit (sur le site que j'ai mentionné  avant) certains départements / régions de mon intérêt en OrthoPhoto 20cm (je ne sais pas pourquoi ; je pense que cela dépend du financement ou non de la région), je souhaite les obtenir par Mobac. C'était notamment l'IDF où je réside mais aussi l'Aquitaine d'où je suis originaire.
    - J'ai déjà récupéré toute l'IDF comme expliqué précédemment par morceaux de 30 dalles taille Z12 (c'est la limite juste en dessous des 500k tuiles), d'abord "tile store download only"  dans "tilestore" , puis conversion en RMAP.
    - Pour l'Aquitaine, qui est une région incroyablement plus grande, je sais que cela va être beaucoup plus long... mais bon en ce moment on a plus de temps.

    - J'ai donc d'abord sélectionné toutes les dalles de tailles Z12 couvrant l'Aquitaine. C'est facile bien sûr mais très long et fastidieux car il faut le faire dalle par dalle (car chaque dalle Z12 sera une de mes cartes rmap finales).
    A noter : étant donné que c'est très long, je trouve très très utile de pouvoir sauvegarder cela dans un "mobac-profile.xml", sinon cette sélection qui m'a pris plus d'une heure sera éventuellement à refaire dans le futur. Pour ma part, je trouve très utile de pouvoir sauvegarder ce lent et long travail de sélection dans un fichier "mobac-profile.xml" que je peux rappeler et modifier à tout moment.

    - Comme il n'est pas possible de tout télécharger en bloc, j'ai fait comme pour IDF : j'ai splitté mon atlas en atlas plus petit de 30 dalles z12 pour être sous les 500k tuiles (c'est assez facile quand on a un "mobac-profile.xml" : on le rappelle et on supprime une partie des dalles pour n'en garder que 30 dans mon cas ; la fois suivante, je prends les 30 dalles suivantes).
    - J'ai donc lancé la conversion, mais au lieu d'utiliser "tile store download only" comme la première fois, cette fois-ci j'ai choisi la sortie "RMaps Sqlite" recommandée.
    - Pour tester, j'ai fait cela sur 2 parties de l'atlas total, donc 2 atlas réduits de 30 dalles taille z12.
    - Avant de poursuivre, j'ai fait un test en créant une carte xml  vers le SQLite dans "mapsources", puis j'ai lancé une conversion RMAP à partir de cette SQLite local. Ca a marché très bien sur ce point.

    >>> Mes observations et interrogations sont les suivantes :
    - La conversion des tuiles vers le SQLite est lente, extrêmement lente. Ce n'est pas à cause du téléchargement qui se fait rapidement mais une fois les tuiles téléchargées, le PC mouline des heures pour intégrer mes 30 dalles (taille Z12 en résolution Z19) au SQLite.
    - Une fois que le SQLite est disponible sur le disque dur, la conversion vers RMAP est par contre très rapide. Mais en partant des fichiers .JDB obtenus avec l'option de sortie "tile store download only" , la conversion RMAP était aussi très rapide.

    >> Je n'ai pas mesuré mais il me semble que la méthode consistant en passer par des fichiers temporaires .JDB avec la sortie "tile store download only"  reste au total nettement plus rapide que le passage par SQLite, à cause de la lenteur de création de la base SQLite. 

    Le gros avantage reste qu'une fois le SQLite finalisé, la conversion en RMAP peut se faire en une seule fois même pour de grande surface, sans limite de 500k tuiles, alors qu'à partir des fichiers .JDB dans "tilestore" je ne peux faire que 30 dalles à la fois car la limite de 500k tuiles est là (de façon un peu absurde puisque toutes les cartes sont pourtant déjà téléchargées).

    Du coup, à ce stade, je ne sais plus si je dois aller dans un sens ou dans l'autre... Constituer une base SQLite me semble très long compte tenu de la surface de mon projet.

    ---

    Je me disais aussi que nous sommes sûrement des milliers à faire des téléchargements et des conversions. Si on partageait nos données (par exemple SQLite), cela éviterait de charger le serveur IGN, on pourrait s'échanger des bases beaucoup plus grosses en P2P que la limite de 500k, et... je rêve quoi. 

    Bonne soirée

     

    0
    Aktionen für Kommentare Permalink

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.