Pour une utilisation "read-only" (dans un simple rendu), effectivement les versions ou infos sur les auteurs sont inutiles (elles peuvent être dans une base annexe dans le cas d'une utilisation sur un outil de veille qualité qui en fin de compte sera en ligne pour suivre les modifications en continu, donc pas utiles non plus). Je verrais bien produire des tuiles vectorielles contenant tous les attributs (non filtrés) et objets façon MVT (PBF sur SQLLite, ou GeoJSON), les tuiles vectorielles étant découpées sur des "Quadtiles".
On produit un seul fichier de base, libre ensuite aux applis de mettre en place leur propre filtrage et éventuellement produire à partir de ça un fichier plus petit à installer (dans lequel il peut y avoir aussi des simplifications géométriques si l'appli n'a pas besoin d'un haut niveau de zoom), mais pouvant aussi utiliser le fichier inchangé : par exemple un navigateur embarqué pourrait avoir un fichier "monde" à faible résolution (géométrie très simplifiée), un fichier Europe, un fichier pays, et un fichier détaillé par région (le découpage des zones est fait sur des limites de "quadtiles" et non des géométries exactes de pays/régions). Les utilisateurs peuvent installer les fichiers séparément en fonction de la capacité de stockage de l'appareil (ou de la carte SD). Un outil générique devrait permettre de faire ces extractions du fichier générique à l'autre, ou les assembler pour produire un fichier sur une zone plus large mais à résolution plus faible. L'appli embarquée peut alors facilement mixer les fichiers en fonction de leur résolution (niveau de zoom) maximum supporté, l'appli utilisant les quadtiles pour savoir quoi dans quel fichier chercher en prenant le quadtile de niveau le plus élevé disponible. Le 31 juillet 2018 à 06:15, <[email protected]> a écrit : > Le 29/07/2018 à 19:17, PanierAvide - [email protected] a écrit : > > (...) Ça peut sembler surprenant mais les tuiles vectorielles contiennent > des infos "light", qui ne sont pas suffisantes pour le niveau de détail que > demande StreetComplete. > > Adrien. > > Il y a pas mal de problèmes pour la compatibilité. > Ceux déjà évoqués (l'optimisation pour le routage, le géocodage ou > l'affichage n'ont simplement pas grand chose à voir) mais ici c'est encore > un autre : le format vectoriel qu'il s'agisse de MVT (MapBox, > OpenVectorTiles...: mbtiles: pbf sur du sqllite) ou des formats plus > propriétaires même si ouverts (style OsmAnd) essayent de ne récupérer que > ce qui les intéresse d'où des infos insuffisantes pour d'autres besoins. > Dans les projets OpenVectorTiles il y a des outils permettant de générer > des tuiles vectorielles et les schemas d'imports imposm3 correspondants. > Si tu mets les bonnes infos, tu pourras faire ce que tu veux. Sinon... > > Pour donner un exemple : si tu ne peux modifier, si tu ne peux que > récupérer les infos en totalité, tu n'as pas besoin de la version de > l'objet. > > N. B. : si on porte TileServer GL sur Android (Termux?) en théorie on peut > avoir le service tiers (il y a sans doute plus simple mais là on a la > possibilité d'avoir le stylage MapBox GL, le stockage mbtiles, la > productions de tuiles vecteur ou image). Mais sauf à convertir vers le > format natif d'OsmANd tu ne pourras que l'afficher pas l'exploiter sur > OsmAnd. > Quelqu'un a comparé d'un point de vue interne la solution OsmAnd et les > mbtiles pour voir si une compatibilité est complètement illusoire ? > > À défaut de compatibilité complète je verrais bien les uns et les autres > capables de produire des tuiles image pour les autres afin d'avoir a minima > l'affichage dans les autres appli sans tout dupliquer. > > Jean-Yvon > > _______________________________________________ > Talk-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
