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
<mailto:osm.sanspourr...@spamgourmet.com>> a écrit :
Le 05/12/2016 à 21:57, LeTopographeFou - letopographe...@gmail.com
<mailto: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 <mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr
<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
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
