Je me demande pourquoi les océans ne pourraient pas être découpés arbitrairement en cellules plus nombreuses juxtaposées en damier, pour ensuite réduire cette dépendance à une complexité de plus en plus exponentielle qu'on accroît la complexité des côtes. Ne peut-on pas envisager de limiter TOUS les polygones à une bounding-box maximale, découpée préférablement sur les limites des "quadtiles" ou limiter le nombre de noeuds qui les définit ? Avantage: une grande partie des mers serait stable, ultra simple (des carreaux, qu'on redivise seulement là où c'est nécessaire pour ne pas dépasser cette limite), sans pour autant augmenter drastiquement le nombre total de polygones pour dessiner de grande zones (comme la carte du monde). Cela devrait même être automatisé dans les éditeurs, en élaborant un nouveau type d'objet (pseudo-relation) groupant les éléments découpés dont tous les attributs sont communs (strictement aucun attribut sur ces découpes artificielles, maximisation et renforcement de l'option d'héritage pour ne plus jamais dupliquer les attributs et simplifier la collecte des découpes dans un objet collecteur). Et là je parle de la création d'un nouveau type d'objet "fragment", qui n'aura JAMAIS aucun autre attribut que la référence à l'objet parent (non-fragment) qui le référence en liste, de sorte que ces fragments sont librement réassemblables et optimisables sans jamais avoir à revoir le "tagging" porté uniquement et strictement dans l'objet principal collecteur (way fermé ou pas, ou relation multipolygone/multiline). Ces fragments n'aurait donc aucune autre propriété que leur géométrie "synthétique" découpée arbitrairement et que n'importe quel outil de dessin/rendu pourra regrouper librement avec les autres fragments par des opération purement géométriques simples (d'où des contraintes sur la géométrie des fragments: les lignes de découpe arbitraires devraient être de simples horizontales/verticales le long des "quadtiles", et on ne peut assembler les fragments que s'ils partagent un côté commun qui est sur une ligne de découpe du quadtile de niveau supérieur. Cependant on peut imaginer que cette transformation peut se faire sur le serveur de rendu sans que cela soit visible dans OSM, mais le faire dans OSM aurait l'avantage d'assurer que les découpes sont recalculées sur la base elle-même et maintenues de façon synchrone: on ne serait donc plus obligé de charger les objets entiers mais des fragments et c'est la base OSM qui s'occupe du réassemblage optimal. Au final on ne travaille alors plus au niveau global mais toujours localement sur des fragments homogènes et complets. La gestion des historiques s'en trouve simplifiée, le rendu aura mois de travail à faire. La question alors du découpage et du traitement spécial des océans est oublié: on pourra tout traiter localement sans chercher loin, les requêtes sont optimisées sur les quadtiles, on peut même avoir un rendu effaice à la demande et quasi instantané sans traitement complexe car toute la géométrie nécessaire est localisée. Et plus de problème d'accollement des tuiles rendues de façon complètement incohérente (même si là on devrait faire l'effort de mettre fin au rendu bitmap pour avoir des tuiles vectorielles partout, rendant obolètes les rendus PNG sur quelques gros serveurs surchargés et jamais à jour).
Le sam. 1 août 2020 à 17:38, Christian Quest <cqu...@openstreetmap.fr> a écrit : > Le 26/07/2020 à 23:53, Christian Quest a écrit : > > Moins de trafic aussi sur les serveurs de l'asso alors c'est le moment > > des chantiers ! > > Le chantier continue avec la remise à jour des limites terre/mer et > l'occupation des sols à petite échelle... > > > Limites terre/mer : > > Les natural=coastline mises bout à bout forment d'immenses polygones qui > sont nécessaires pour avoir la mer en bleu et la terre dans une couleur > claire par défaut. > > Ces polygones sont relativement coûteux à calculer, car composés de très > nombreux noeuds. Ils sont gigantesques car couvrant des continents entiers. > > Du coup, ils sont calculés de temps en temps et mis à disposition sur > https://osmdata.openstreetmap.de/ sous une forme découpée (oui, façon > puzzle) avec une version aux géométries simplifiées adaptée aux petites > échelles. > > Les derniers fichiers shapefile dataient de janvier et ils ont été remis > à jour hier. > > Pour le rendu FR, j'en ai profité pour changer la logique car depuis > toujours, on mettait un fond bleu par défaut et on dessinait les > continents par dessus. > > Or... on calcule bien plus souvent des tuiles sur terre que sur mer, > donc autant avoir ça de moins à dessiner dans la majorité des cas même > si c'est sûrement négligeable. > > > L'occupation des sols à petite échelle : > > Pour les premiers niveaux de zoom, le rendu FR affiche l'occupation des > sols (landuse=*). Le problème ici c'est le très grand nombre de > polygones, parfois très petits et non visibles à ces échelles. > > Il y a quelques années, j'avais calculé une couche transparente au zoom > 8 ne contenant que ces landuse pour l'appliquer par simple réduction sur > les zoom 0 à 7. > > J'ai regénéré cette couche, cette fois-ci directement au zoom 7, en > éliminant tous les polygones d'une surface de moins d'un pixel. > > Le résultat est un fichier geotif de 89Mo : > http://osm13.openstreetmap.fr/~cquest/z7.tif > > On a désormais des déserts bien plus cohérents en Afrique ! > > > Conséquence, les tuiles ont toutes été recalculées jusqu'au zoom 12 et > devraient apparaître au fur et à mesure de la mise à jour du cache. > > > Si vous voyez des anomalies... signalez-les... > > -- > Christian Quest - OpenStreetMap France > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
