Salut
Um Objekte, wie beispielsweise Brunnen, in Wikidata mit dem Identifier "OSM relation ID" (Property:P402) zu erfassen, können Node oder Way nicht verwendet werden. Für Node oder Way ist keine Property vorhanden; deshalb der dirty hack mit relation für Brunnen in Bern
Beispiel:
* https://www.wikidata.org/wiki/Q57205876
somit wird die OSM-Relation-ID auch in Commons angezeigt: * https://commons.wikimedia.org/wiki/Category:Zierbrunnen_Schloss_B%C3%BCmpliz...
* https://www.openstreetmap.org/relation/8797705
Meine Bitte:
Wenn ihr als OSM-Relation erfasste Brunnen, welche den technischen OSM-Qualitätsansprüchen nicht genügen, antrefft, nicht einfach in Way oder Node umwandeeln, jedoch gerne *als Relation - es kann auch eine neue sein - verbessern*.
Danke!
cheeers, h.
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
Salut Markus
Am 07.01.2019 um 22:12 schrieb Markus:
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.
Das sei dir unbenommen. :-)
Ich finde die Idee einen gangbaren Kompromiss. Den so wird OSM in commons.wikimedia.org und wikidata jeweils mit aktivem Link ein klein wenig sichtbarer; und das war meine Absicht. - Für meine kleine uMap-Bastelei "Karte der Brunnen in Stadt und Gemeinde Bern" ist es hingegen nicht relevant.
Klar, ich würde es auch begrüssen, wenn wikidata statt "OpenStreetMap-Relations-ID" (OSM relation ID (P402)) nur "OpenStreetMap-ID" verwenden würde und so Relations, Ways und Nodes verlinkt werden könnten. Die Einschränkung von wikidata nur auf Relations erschliesst sich mir nicht.
https://www.wikidata.org/wiki/Property_talk:P402
Übrigens verstehe ich deine Tag-Kombination
area = yes barrier = kerb landuse = basin
nicht. Wieso Bordstein? Wieso Fläche?
Mittlerweile habe ich bei den meisten den area tag rausgenommen. Kerb heisst übrigens auch (gemäss deepl) Steinrand, was ich ab und zu passender fand als retaining_wall, da niedriger.
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.
Jo klar, kann man machen, Sag's einfach, wenn dich der Tatendrang packt. Bei 341 und es werden noch ein paar mehr, wird das eine "gröbere Übung"; ob's was bringt, weiss ich nicht. :-)
cheeers, h.
PS Fall du oder wer anders Bock habt am rumprobieren auf "Karte der Brunnen in Stadt und Gemeinde Bern"(https://umap.osm.ch/de/map/brunnen-in-stadt-und-gemeinde-bern_124) bitte schreien und du/ihr kriegt Bearbeitungszugang.
Gruss, Markus _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
On Mon, 7 Jan 2019 at 22:42, Andreas Bürki abuerki@anidor.com wrote:
Mittlerweile habe ich bei den meisten den area tag rausgenommen. Kerb heisst übrigens auch (gemäss deepl) Steinrand, was ich ab und zu passender fand als retaining_wall, da niedriger.
Was zählt, ist, wie das Tag auf dem OSM-Wiki definiert wurde, und nicht die Definition eines Wörterbuchs. (Abgesehen davon finde ich in Wörterbüchern keine andere Bedeutung für kerb als Steinrand zwischen Fahrbahn und Trottoir.)
Gruss, Markus
Am 08.01.2019 um 10:56 schrieb Markus:
On Mon, 7 Jan 2019 at 22:42, Andreas Bürki abuerki@anidor.com wrote:
Mittlerweile habe ich bei den meisten den area tag rausgenommen. Kerb heisst übrigens auch (gemäss deepl) Steinrand, was ich ab und zu passender fand als retaining_wall, da niedriger.
Was zählt, ist, wie das Tag auf dem OSM-Wiki definiert wurde, und nicht die Definition eines Wörterbuchs. (Abgesehen davon finde ich in Wörterbüchern keine andere Bedeutung für kerb als Steinrand zwischen Fahrbahn und Trottoir.)
Danke für den Update des Zierbrunnes Lindehofspital
https://www.openstreetmap.org/relation/9194008
cheeers, h.
Gruss, Markus _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
The only reason Wikidata only allows relation IDs, is that they are considered more stable, especially those of administrative boundaries. By turning every other object into a relation to link from it from Wikidata is not a good idea, it does not create a more stable ID by doing that. Just add the Wikidata identifier to the node/polygon/way in OSM and you obtain more or less the same result.
There is already a database created from Wikidata and OSM that links via the Wikidata tag in OSM. This database can be used to make combined queries. There is no need to add an OSM identifier in Wikidata to accomplish that.
m.
On Tue, Jan 8, 2019 at 11:44 AM Andreas Bürki abuerki@anidor.com wrote:
Am 08.01.2019 um 10:56 schrieb Markus:
On Mon, 7 Jan 2019 at 22:42, Andreas Bürki abuerki@anidor.com wrote:
Mittlerweile habe ich bei den meisten den area tag rausgenommen. Kerb heisst übrigens auch (gemäss deepl) Steinrand, was ich ab und zu passender fand als retaining_wall, da niedriger.
Was zählt, ist, wie das Tag auf dem OSM-Wiki definiert wurde, und nicht die Definition eines Wörterbuchs. (Abgesehen davon finde ich in Wörterbüchern keine andere Bedeutung für kerb als Steinrand zwischen Fahrbahn und Trottoir.)
Danke für den Update des Zierbrunnes Lindehofspital
https://www.openstreetmap.org/relation/9194008
cheeers, h.
Gruss, Markus _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
--
Andreas Bürki
abuerki@anidor.com S/MIME certificate - SHA-256 fingerprint: 8A:1A:C2:93:10:4B:CE:91:2C:80:79:44:24:1D:38:CA:EE:0E:89:C9:A5:A4:A0:03:FF:5A:FB:D1:15:18:B5:45 GnuPG - GPG fingerprint: 5DA7 5F48 25BD D2D7 E488 05DF 5A99 A321 7E42 0227 _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
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
Salut
Habe einige Brunnen in Bern gemäss dem von Markus empfohlenen Schema getagt.
Für Zierbrunnen (Becken im Boden eingelassen):
Das Brunnenbecken würde ich eher
landuse = basin content = water material = stone
Für "normale" Brunnen (Becken freistehend):
noch besser mit man_made = basin anstatt landuse = basin,
da ein Becken keine Landnutzung darstellt.
Immer als relation=site (werde bei Gelegenheit die bestehende relation=multipolygon wandeln in site mit entsprechenden Anpassungen, sodass die Relation Nummer bestehen bleibt und es keine Probleme mit den Multipolygonen gibt.)
Konsequenz:
Derart getagte Brunnen (immer noch Mit: amenity=fountain und name=XYZ Brunnen - oder wie vor Zeiten empfohlen - name:description:de=XYZ Brunnen) werden in der OSM Karte nicht mehr gerendert. Kein Umriss, kein Icon, gar nichts. Ebenso können diese Brunnen mit der Search Funktion in OSM nicht mehr gefunden werden. -
Beispiele: * Brunngassbrunnen https://www.openstreetmap.org/relation/9148782 * Konservatoriumbrunnen https://www.openstreetmap.org/relation/9217480
Vielleicht wäre es sinnvoll, wenn jemand mit den nötigen Beziehungen, den OSM Devs diesen Umstand näher bringen könnte, sodass jegliche Objekte mit mit relation=site und amenity=fountain auch gerendert werden. Aber nur, falls dies jemand für sinnvoll hält; für uMap spielt es keine Rolle und für Wikidata ist es nur wichtig, dass es eine Relation ist (also bitte diese nicht einfach in Node oder Line wandeln.).
cheeers, h.
Am 07.01.2019 um 22:12 schrieb Markus:
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
Hallo Andreas
Solange ein Brunnen ausschliesslich aus mehreren Flächen besteht, benötigst du keine site-Relation, sondern eine multipolygon-Relation. site-Relationen benötigt man nur, wenn mindestens ein Element ein Knoten oder eine Linie ist. [1] Du musst bei den multipolygon-Relationen jedoch darauf achten, dass sich die Flächen nicht überschneiden; dies ist bei einigen Brunnen der Fall:
https://tools.geofabrik.de/osmi/?view=areas&lon=7.41794&lat=46.94549...
Übrigens scheint es, dass OSM-Carto keine site-Relation darstellt, weil die Definition des Vorschlags problematisch ist (u. a. weil sie unendlich ineinander verschachtelte Relationen erlaubt). [2]
[1]: https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site#Proposal [2]: https://github.com/gravitystorm/openstreetmap-carto/issues/2940#issuecomment...
Grüsse
Markus
-
Andreas Bürki -
Marc Gemis -
marc marc -
Markus