[OSM-talk-fr] Problème de représentation avec des parcelles forestières

[Christian Quest]

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.sanspourriel at spamgourmet.com> a écrit :

> Le 05/12/2016 à 21:57, LeTopographeFou - letopographefou at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20161205/bdd9fd8b/attachment.htm>