J'ai basculé ces "type=multipolygon" en "type=boundary"... et tout rentre dans l'ordre comme je l'avais imaginé dans mon précédent message qui n'a visiblement pas été lu ;)
Ces sections forestières sont bien des frontières et ça évite à osm2pgsql de chercher à savoir par une euristique imparfaite ce que sont ces multipolygones mystérieux... En terme de logique de tagging je verrai plutôt quelque chose comme: type=boundary (il s'agit d'une frontière qui découpe un ensemble plus grand) boundary=forest (frontière forestière) forest=section (il s'agit d'une section) Mais ça mérite discussion sur le wiki plutôt que d'y aller à l'arrache... surtout que l'import des données est pas génial non plus car les données d'origine ne sont pas forcément bien calées... Exemple: http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#18/48.53494/1.97682 Les tuiles sont en train de se remettre à jour... un peu de patience. Le 5 décembre 2016 à 22:17, <osm.sanspourr...@spamgourmet.com> a écrit : > Le 05/12/2016 à 21:57, LeTopographeFou - letopographe...@gmail.com a > écrit : > > Bonsoir à tous, > > A vrai dire je croyais que le moteur ne dessinait que les objets issus > d'une requête (donc les objets connus) et pas tous les objets. Visiblement > ce n'est pas le cas. > > Jusqu'à peu c'était le cas. J'ai vu que maintenant les "noms" des > transformateurs apparaissent sur la carte. > Assez absurde pour une carte générique. > > Entre nous, ce système de "je fais remonter les valeurs communes" me > parait biaisé et n'incite pas à correctement tagger. Je préfère 100x plus > un moteur de rendu stricte et exigent qui pousse à bien faire mais dessine > avec ce qu'on lui donne plutôt qu'un qui interprète les données avec des > attributs qui n'existent pas et dessine des relations qu'il ne connait pas > (avec 50% de risque de se planter). Si le moteur ne connait pas une > relation, il devrait l'ignorer. Si il lui manque une propriété, il devrait > pouvoir faire sans. Dixit un gars qui n'a pas sué dans le développement de > ces beaux outils :-) . > > Si c'est une info commune, pourquoi pas ? Je dis bien commune c'est à dire > identique dans tous les membres. > Sinon c'est éventuellement un candidat pour un outil d'assurance qualité > (que des noms identiques ou pas de noms : peut-être que les sans noms > devraient avoir le même nom, ça peut avoir du sens pour des réseaux, des > trajets tels que des pistes cyclables sans nom connectés à d'autres pistes > cyclables ayant un nom... ou une référence). > > Jean-Yvon > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > -- Christian Quest - OpenStreetMap France
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
