Je ne vois pas en quoi ce changement de "multipolygon" en "boundary" devrait avoir un impact sur l'interprétation et la "remontée" des tags des ways membres vers les relations qui les référence.
Cela reste un bogue de la conversion OSM en pgsql, qui ne tient pas compte des critères nécessaires (tags identiques dans tous les ways membres ayant un rôle "outer" ou vide, ce qui n'était pas le cas des "name=*"). En revanche remonter les "highway=*" vers la relation (peu importe que ce soit une "boundary" ou un "multipolygon") est problématique, dans les faits tous les "highway=*" sont linéaires (exceptions faite des "highway=pedestrian" et à condition qu'ils soient tagués avec "area=yes", ce qui n'était pas du tout le cas ici, car par défaut les "highway=*" sont soit linéaires, soit des noeuds isolés pour des passages piétons, priorités, stops...). Il reste donc bien une anomalie de osm2pgsql ici, et je ne vois pas pourquoi osm2pgsql devrait se demander ce que sont ces "multipolygon", d'autant plus qu'ils ont déjà des tags nécessaires, qu'ils soient tagués comme "multipolygon", boundary", ou encore comme "landuse", "natural" (qui n'ont eux rien non plus à voir avec les "highway=*") Le 6 décembre 2016 à 23:38, LeTopographeFou <letopographe...@gmail.com> a écrit : > 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 ;) > > Bonjour et merveilleux !! Je n'avais pas compris le sous-entendu. Merci. > > 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... > [...] > > Tout là fait d'accord (sans rentrer dans la discussion ici : j'aime bien > ta proposition, elle est plus proche de l'existant et donc plus naturelle > que la proposition Section). > > Pour info il se trouve que j'ai eu un échange de mail avec l'auteur de la > proposition Section cet été (à propos d'un cimetière que je > visitais/cartographiais à l'époque) et il m'a dit qu'il n'avait pas eu le > courage pour animer sa proposition jusqu'au bout. Il m'a encouragé à la > retravailler voir à faire une contre-proposition, car il reste persuadé du > besoin initial (parcelles forestières, sections dans un cimetière...). > > > 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 > > Alors là c'est drôle car pendant que tu changeais le type de relation je > recalais exactement l'endroit que tu cite (ce qui m'a valu de résoudre > quelques conflits d'éditions quand j'ai voulu envoyer sur le serveur). Donc > en me basant sur le cadastre j'ai regroupé hier ce qui devait l'être dans > la zone (je n'ai pas déplacé les frontières administratives mais les > layons, chemins et bordures de forêt. Il reste encore une bonne partie du > périmètre à recaler) et j'en avais profité pour ajouter un gros morceau de > forêt manquant côté Yvelines (http://www.openstreetmap.org/ > relation/6770020). > > Bref il reste du boulot mais problème de rendu de parcelle réglé, je > déploierai la solution sur les forêts alentours qui ont le même soucis, > merci ! > > Cordialement > > LeTopographeFou > > Le 05/12/2016 à 23:18, Christian Quest a écrit : > > 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 > listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr > > > > _______________________________________________ > 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
