Bonjour,
Je partage l'avis de Markus : - faire des relations parce que wikidata n'accepte pas un id node/way, c'est une mauvaise idée. d'ailleurs renseigner un id osm dans wikidata même pour une relation me semble une mauvaise idée, les id dans osm ne sont pas permanent. si quelqu'un supprime la relation, tout s'écroule. il faut mieux utiliser si nécessaire le système de permiD d'overpass - j'ai aussi corrigé de nombreuse fontaines -- multipolygone invalide (pas de outer, outer qui se croise, ...) -- paroi du bassin définit comme une barrière voir un mur de soutènement.
il y a aussi (mais je n'ai pas corrigé) le tag source qui me semble erroné (je doute fort qu'un survey ai permis par exemple de connaître l'altitude... beaucoup des données semblent venir d'une source non renseignée). le mieux me semblerait un survey:data=2018 une fontaine ne change pas si souvent que cela :) ou les tags location:description:de utilisé pour contourné le fait de ne pas pouvoir récupérer l'adresse dans umap (Ybon est pourtant ouvert aux suggestions et aux questions) Idem pour name:description dont je ne comprend pas le sens.
Cordialement, Marc Le 07.01.19 à 22:12, Markus a écrit :
Hallo Andreas
Ich habe mir erlaubt, einige der von dir als Multipolygone gemappten Brunnen zu korrigieren, da mehrere Fehler aufweisen (hauptsächlich sich überschneidende Members). Dabei habe ich fehlerhafte Multipolygone durch einfache Flächen ersetzt.
1-Member-Multipolygone zu erstellen, nur weil Wikidata keine OSM-Way-ID akzeptiert, finde ich eine schlechte Idee.
Übrigens verstehe ich deine Tag-Kombination
area = yes barrier = kerb landuse = basin
nicht. Wieso Bordstein? Wieso Fläche?
Das Brunnenbecken würde ich eher
landuse = basin content = water material = stone
mappen. Oder noch besser mit man_made = basin anstatt landuse = basin, da ein Becken keine Landnutzung darstellt.
Gruss, Markus _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch