CARTE - Permettre la juxtaposition de cartes présentes sur des fichiers différents
Opened this issue · 6 comments
Actuellement, notamment pour l'ortho, comme la carte est lourde (fichiers de 4Go max supportés), le tuilage est splité en 10 fichiers mbtiles s'appuyant sur la numérotation des colonnes ou des lignes ou du nom des tuiles.
Le splitage est une opération qui est lourde à réaliser (installer python, mbutil.py, mbtilessplit.py) et longue.
Pouvoir juxtaposer des cartes produites en dalles de taille moyennes, simplifierait la production des cartes en évitant le splitage.
Bonjour,
Suite aux précédentes discussions, le projet de changer la gestion des fonds de carte mbtiles est remis d'actualité. Pour éviter les manipulations évoquées par Gil ci-dessus, on a regardé ce qui se fait pour une application comme Orux Map par exemple qui peut travailler avec plusieurs mbtiles de style et d'emprises différentes. Le but étant que la gestion des fonds de carte de fasse de manière la plus transparente pour l'utilisateur, quelle que soit l'emprise, les niveaux de zoom et le nombre de tuiles disponibles.
OruxMap propose un paramètre permettant de définir le chemin des fichiers mbtiles. Il y lit tous les fichiers disponibles dans le dossier en question et ses sous-dossiers.
(Ici 2 dossiers, chacun comprenant un fichier .db (world)+1.xml ou .mbtiles (aura) )
Il génère un "index" des cartes (parfois inexact!) et propose de sélectionner l'un des fonds existants si on sort de l'emprise.
(Dans cet exemple, seul le fond de carte "AURA.mbtiles"=test2018... est affiché, pour autant l'index calculé par l'application lui associe une emprise plus petite)
Sur un principe qui semble similaire si j'ai bien compris ce que fait orux - S.Grimault qui assurera la prestation pour le développement de ces évolutions - propose que l'utilisateur renseigne en paramètre le chemin vers les cartes.
- D'une part un chemin vers les fonds ortho,
- d'autre part un second chemin vers les fonds type scan/OSM.
A son lancement, l'application fait un scan de ces tuiles, et calcule un index avec les emprises de chaque tuile. Selon le niveau de zoom et la zone demandée par l'utilisateur, l'appli laisse le choix, ou passe automatiquement sur le seul type de fond disponible.
L'avantage de cette méthode et que l'utilisateur peut ajouter ou enlever des tuiles (faire des compléments, ajouter une zone lorsqu'il change de secteur, supprimer les fonds d'une zone qu'il ne fréquente plus, ajouter un niveau de zoom ou autre) sans avoir à toucher à l'application. De plus, les fonds n'ont pas à être dupliqués, il suffit d'indiquer à d'autres applications comme Orux le même chemin que pour GeoNature-Atlas, chaque application fait ses scans et peut se partager les mêmes fonds.
Est-ce que cette proposition vous semble pertinente, est-ce qu'il y a des choses à anticiper auxquelles nous n'aurions pas pensé etc?
Le développement se ferait courant 2018 pour une livraison vers l'automne par exemple, en prévision d'une V2 qui intègrerait cette gestion des fonds directement,
Donovan
Oui ça me semble bien si on peut parametrer ça par defaut pour pas que l'utilisateur n'ait à se soucier de ces questions techniques.
Ca marche, alors on garde en tête un chemin renseigné par défaut lors de l'install, propre à l'appli dans ce cas, dans lequel un organisme peut rentrer ses propres mbtiles au cours de l'install comme c'est actuellement le cas, sans que l'utilisateur n'ait à y toucher.
Camille : pour voir si j'ai bien suivi :
Il faudrait un paramètre à l'install pour choisir entre "définir par défaut un répertoire et ne pas laisser la main sur ce point à l'utilisateur" et "donner le choix à l'utilisateur et lui permettre de définir le chemin via l'interface de l'application'. Ou simplement définir un chemin par défaut mais dans tous les cas l'utilisateur pourrait le modifier?
J'imagine que pour les grosses structures mieux vaut donner le choix de définir un fond et que l'utilisateur ne puisse pas avoir la main sur ce paramètre?
Euh je ne connais pas assez comment ça marche actuellement.
Mais si je dis pas de bêtise, il y a un fichier de conf du chemin vers la carte.
Dans notre cas, on le remplit et l'utilisateur n'intervient jamais dessus.
Pour des utilisateurs avancés qui veulent changer le fond, ils peuvent modifier ce chemin dans la conf.
Mais je ne vois pas l'intérêt de paramètre à l'installation, ni de faire des choix, ni d'intégrer ces fonctionnalités dans l'interface de l'application.
Le fait de l'intégrer à l'interface sert juste à faciliter le paramétrage pour l'utilisateur, notamment s'il souhaite changer de fonds ou les déplacer pour coller à d'autres appli sans embarquer plusieurs de fonds, et sans avoir à refaire toute l'install.
Cet aspect là en particulier pourrait s'avérer intéressant si à termes on souhaite faciliter l'installation de ces applications pour qu'un utilisateur puisse installer lui même ses appli. Ce qui a termes pourra servir pour un certain nombre d'assos où la structure n'a pas la main directement sur les appareils des personnes qui font les saisies. Mais à voir si ça colle avec votre manière de fonctionner