Hallo
Mir ist aufgefallen, dass in Bern viele Adressen ein addr:suburb-Tag [^1] besitzen (z. B. addr:suburb=Länggasse), obwohl das Quartier nicht zur postalischen Adresse gehört.
[^1]: https://wiki.openstreetmap.org/wiki/Key:addr:suburb
Gibt es einen Grund für diese addr:suburb-Tags? Würden die eingezeichneten Quartier-Grenzen nicht ausreichen?
Grüsse
Markus
Salut
Wenn es nur um Daten an und für sich geht, reichen IMHO die importierten Quartier-Grenzen.
Wenn man dem gemeinen OSM Benutzer einen Komfort bieten will, denke ich, das die addr:suburb-Tags noch ganz praktisch/hilfreich sind; klar, sie müssen korrekt sein, sonst sind sie eher verwirrlich.
Just my 2 cents...
cheeers, h.
Am 01.05.2018 um 19:06 schrieb Selfish Seahorse:
Hallo
Mir ist aufgefallen, dass in Bern viele Adressen ein addr:suburb-Tag [^1] besitzen (z. B. addr:suburb=Länggasse), obwohl das Quartier nicht zur postalischen Adresse gehört.
Gibt es einen Grund für diese addr:suburb-Tags? Würden die eingezeichneten Quartier-Grenzen nicht ausreichen?
Grüsse
Markus _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Ich frage mich jedoch, ob die Angabe zum Quartier dann nicht besser in einem anderen Tag (z. B. is_in:neighbourhood=*) untergebracht wäre.
2018-05-03 13:39 GMT+02:00 Andreas Bürki abuerki@anidor.com:
Salut
Wenn es nur um Daten an und für sich geht, reichen IMHO die importierten Quartier-Grenzen.
Wenn man dem gemeinen OSM Benutzer einen Komfort bieten will, denke ich, das die addr:suburb-Tags noch ganz praktisch/hilfreich sind; klar, sie müssen korrekt sein, sonst sind sie eher verwirrlich.
Just my 2 cents...
cheeers, h.
Am 01.05.2018 um 19:06 schrieb Selfish Seahorse:
Hallo
Mir ist aufgefallen, dass in Bern viele Adressen ein addr:suburb-Tag [^1] besitzen (z. B. addr:suburb=Länggasse), obwohl das Quartier nicht zur postalischen Adresse gehört.
Gibt es einen Grund für diese addr:suburb-Tags? Würden die eingezeichneten Quartier-Grenzen nicht ausreichen?
Grüsse
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
étant donné que quasiment aucun outil n'utilise is_in et que cela provoque des tags redondant en grand nombre, si l'étendue du quartier est connue, le mieux est de faire un polygone avec place=neighbourhood + name=*
Le 03. 05. 18 à 18:15, Selfish Seahorse a écrit :
Ich frage mich jedoch, ob die Angabe zum Quartier dann nicht besser in einem anderen Tag (z. B. is_in:neighbourhood=*) untergebracht wäre.
2018-05-03 13:39 GMT+02:00 Andreas Bürki abuerki@anidor.com:
Salut
Wenn es nur um Daten an und für sich geht, reichen IMHO die importierten Quartier-Grenzen.
Wenn man dem gemeinen OSM Benutzer einen Komfort bieten will, denke ich, das die addr:suburb-Tags noch ganz praktisch/hilfreich sind; klar, sie müssen korrekt sein, sonst sind sie eher verwirrlich.
Just my 2 cents...
cheeers, h.
Am 01.05.2018 um 19:06 schrieb Selfish Seahorse:
Hallo
Mir ist aufgefallen, dass in Bern viele Adressen ein addr:suburb-Tag [^1] besitzen (z. B. addr:suburb=Länggasse), obwohl das Quartier nicht zur postalischen Adresse gehört.
Gibt es einen Grund für diese addr:suburb-Tags? Würden die eingezeichneten Quartier-Grenzen nicht ausreichen?
Grüsse
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
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
En effet, on a déjà des relations pour les quartiers et Nominatim les comprends ; par exemple il identifie le quartier Mattenhof pour l'adresse Pilgerweg 7, Bern bien que cette adresse n'ait pas d'attribut addr:suburb :
https://www.openstreetmap.org/search?query=7%20pilgerweg%20bern#map=19/46.94...
2018-05-03 18:18 GMT+02:00 marc marc marc_marc_irc@hotmail.com:
étant donné que quasiment aucun outil n'utilise is_in et que cela provoque des tags redondant en grand nombre, si l'étendue du quartier est connue, le mieux est de faire un polygone avec place=neighbourhood + name=*
Le 03. 05. 18 à 18:15, Selfish Seahorse a écrit :
Ich frage mich jedoch, ob die Angabe zum Quartier dann nicht besser in einem anderen Tag (z. B. is_in:neighbourhood=*) untergebracht wäre.
2018-05-03 13:39 GMT+02:00 Andreas Bürki abuerki@anidor.com:
Salut
Wenn es nur um Daten an und für sich geht, reichen IMHO die importierten Quartier-Grenzen.
Wenn man dem gemeinen OSM Benutzer einen Komfort bieten will, denke ich, das die addr:suburb-Tags noch ganz praktisch/hilfreich sind; klar, sie müssen korrekt sein, sonst sind sie eher verwirrlich.
Just my 2 cents...
cheeers, h.
Am 01.05.2018 um 19:06 schrieb Selfish Seahorse:
Hallo
Mir ist aufgefallen, dass in Bern viele Adressen ein addr:suburb-Tag [^1] besitzen (z. B. addr:suburb=Länggasse), obwohl das Quartier nicht zur postalischen Adresse gehört.
Gibt es einen Grund für diese addr:suburb-Tags? Würden die eingezeichneten Quartier-Grenzen nicht ausreichen?
Grüsse
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
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
C'est pourquoi que je me suis demandé si les relations ne seraient pas suffisantes.
2018-05-03 18:35 GMT+02:00 Selfish Seahorse selfishseahorse@gmail.com:
En effet, on a déjà des relations pour les quartiers et Nominatim les comprends ; par exemple il identifie le quartier Mattenhof pour l'adresse Pilgerweg 7, Bern bien que cette adresse n'ait pas d'attribut addr:suburb :
https://www.openstreetmap.org/search?query=7%20pilgerweg%20bern#map=19/46.94...
2018-05-03 18:18 GMT+02:00 marc marc marc_marc_irc@hotmail.com:
étant donné que quasiment aucun outil n'utilise is_in et que cela provoque des tags redondant en grand nombre, si l'étendue du quartier est connue, le mieux est de faire un polygone avec place=neighbourhood + name=*
Le 03. 05. 18 à 18:15, Selfish Seahorse a écrit :
Ich frage mich jedoch, ob die Angabe zum Quartier dann nicht besser in einem anderen Tag (z. B. is_in:neighbourhood=*) untergebracht wäre.
2018-05-03 13:39 GMT+02:00 Andreas Bürki abuerki@anidor.com:
Salut
Wenn es nur um Daten an und für sich geht, reichen IMHO die importierten Quartier-Grenzen.
Wenn man dem gemeinen OSM Benutzer einen Komfort bieten will, denke ich, das die addr:suburb-Tags noch ganz praktisch/hilfreich sind; klar, sie müssen korrekt sein, sonst sind sie eher verwirrlich.
Just my 2 cents...
cheeers, h.
Am 01.05.2018 um 19:06 schrieb Selfish Seahorse:
Hallo
Mir ist aufgefallen, dass in Bern viele Adressen ein addr:suburb-Tag [^1] besitzen (z. B. addr:suburb=Länggasse), obwohl das Quartier nicht zur postalischen Adresse gehört.
Gibt es einen Grund für diese addr:suburb-Tags? Würden die eingezeichneten Quartier-Grenzen nicht ausreichen?
Grüsse
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
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Pour moi oui les relations sont suffisantes. Idéalement il faudrait faire un énorme nettoyage pour tous les niveaux d'adresses continent, pays, canton, commune
j'ai aussi en projet de faire des tickets pour que les principales applications et éditeur prennent mieux en compte les informations présente sur les relations. c'est sans doute une raison pour laquelle certaines personnes les dupliquent sur de nombreux objets
Le 03. 05. 18 à 18:39, Selfish Seahorse a écrit :
C'est pourquoi que je me suis demandé si les relations ne seraient pas suffisantes.
2018-05-03 18:35 GMT+02:00 Selfish Seahorse selfishseahorse@gmail.com:
En effet, on a déjà des relations pour les quartiers et Nominatim les comprends ; par exemple il identifie le quartier Mattenhof pour l'adresse Pilgerweg 7, Bern bien que cette adresse n'ait pas d'attribut addr:suburb :
https://www.openstreetmap.org/search?query=7%20pilgerweg%20bern#map=19/46.94...
2018-05-03 18:18 GMT+02:00 marc marc marc_marc_irc@hotmail.com:
étant donné que quasiment aucun outil n'utilise is_in et que cela provoque des tags redondant en grand nombre, si l'étendue du quartier est connue, le mieux est de faire un polygone avec place=neighbourhood + name=*
Le 03. 05. 18 à 18:15, Selfish Seahorse a écrit :
Ich frage mich jedoch, ob die Angabe zum Quartier dann nicht besser in einem anderen Tag (z. B. is_in:neighbourhood=*) untergebracht wäre.
2018-05-03 13:39 GMT+02:00 Andreas Bürki abuerki@anidor.com:
Salut
Wenn es nur um Daten an und für sich geht, reichen IMHO die importierten Quartier-Grenzen.
Wenn man dem gemeinen OSM Benutzer einen Komfort bieten will, denke ich, das die addr:suburb-Tags noch ganz praktisch/hilfreich sind; klar, sie müssen korrekt sein, sonst sind sie eher verwirrlich.
Just my 2 cents...
cheeers, h.
Am 01.05.2018 um 19:06 schrieb Selfish Seahorse:
Hallo
Mir ist aufgefallen, dass in Bern viele Adressen ein addr:suburb-Tag [^1] besitzen (z. B. addr:suburb=Länggasse), obwohl das Quartier nicht zur postalischen Adresse gehört.
Gibt es einen Grund für diese addr:suburb-Tags? Würden die eingezeichneten Quartier-Grenzen nicht ausreichen?
Grüsse
Markus
Rechner/Computer benötigen imho die Angaben in einem Knoten nicht. Jedoch sind die Angaben für Menschen ganz nützlich
https://www.openstreetmap.org/node/703577602
Auf einen Blick sieht/liest der Mensch alle Details zu einer Adresse und kann sie beispielsweise für seine verbale Kommunikation verwenden.
Wenn die OSM Software in der Lage wäre, die Objekte, wie Häuser mit den Daten aus einem Polygon zu ergänzen, also für Menschen lesbar zu machen so wie im Knoten oben, müsste man sie (Land, (Kanton), Gemeinde, Quartier und Strasse) nicht mehr von Hand eingeben. Somit wäre es für den Mapper weniger Arbeit bei gleichem Nutzen für den gemeinen OSM Webanwender.
Bezüglich des is_in Tag werde ich im allgemeinen nicht ganz schlau. Scheint mir so ein Überbleibsel aus den frühen OSM-Anfängen zu sein.
* https://wiki.openstreetmap.org/wiki/Key:is_in
Ich fragte mich aber auch, ob es sinnvoll sein könnte, is_in zu nutzen um den *Standort* von Objekten (z.B. Brunnen, Hydranten) besser (oder überhaupt) zu beschreiben - z.B. für uMaps - und somit addr:* nicht zu "belasten"
Beispiele (mit Adresse oder Standort):
* https://commons.wikimedia.org/wiki/Category:Fountains_in_Bern -> Link zu uMap * https://umap.osm.ch/de/map/brunnen-in-stadt-und-gemeinde-bern_124
* http://umap.osm.ch/de/map/standorte-defibrillatoren_172
Adressen/Standorte werden direkt aus OSM (addr:* was teilweise etwas einschränkend ist) generiert/verwendet.
Wäre die Verwendung von is_in:Freie_Standortbeschreibung geeigneter als addr:* ?
cheeers, h.
Am 03.05.2018 um 19:32 schrieb marc marc:
Pour moi oui les relations sont suffisantes. Idéalement il faudrait faire un énorme nettoyage pour tous les niveaux d'adresses continent, pays, canton, commune
j'ai aussi en projet de faire des tickets pour que les principales applications et éditeur prennent mieux en compte les informations présente sur les relations. c'est sans doute une raison pour laquelle certaines personnes les dupliquent sur de nombreux objets
Le 03. 05. 18 à 18:39, Selfish Seahorse a écrit :
C'est pourquoi que je me suis demandé si les relations ne seraient pas suffisantes.
2018-05-03 18:35 GMT+02:00 Selfish Seahorse selfishseahorse@gmail.com:
En effet, on a déjà des relations pour les quartiers et Nominatim les comprends ; par exemple il identifie le quartier Mattenhof pour l'adresse Pilgerweg 7, Bern bien que cette adresse n'ait pas d'attribut addr:suburb :
https://www.openstreetmap.org/search?query=7%20pilgerweg%20bern#map=19/46.94...
2018-05-03 18:18 GMT+02:00 marc marc marc_marc_irc@hotmail.com:
étant donné que quasiment aucun outil n'utilise is_in et que cela provoque des tags redondant en grand nombre, si l'étendue du quartier est connue, le mieux est de faire un polygone avec place=neighbourhood + name=*
Le 03. 05. 18 à 18:15, Selfish Seahorse a écrit :
Ich frage mich jedoch, ob die Angabe zum Quartier dann nicht besser in einem anderen Tag (z. B. is_in:neighbourhood=*) untergebracht wäre.
2018-05-03 13:39 GMT+02:00 Andreas Bürki abuerki@anidor.com:
Salut
Wenn es nur um Daten an und für sich geht, reichen IMHO die importierten Quartier-Grenzen.
Wenn man dem gemeinen OSM Benutzer einen Komfort bieten will, denke ich, das die addr:suburb-Tags noch ganz praktisch/hilfreich sind; klar, sie müssen korrekt sein, sonst sind sie eher verwirrlich.
Just my 2 cents...
cheeers, h.
Am 01.05.2018 um 19:06 schrieb Selfish Seahorse: > Hallo > > Mir ist aufgefallen, dass in Bern viele Adressen ein addr:suburb-Tag > [^1] besitzen (z. B. addr:suburb=Länggasse), obwohl das Quartier nicht > zur postalischen Adresse gehört. > > [^1]: https://wiki.openstreetmap.org/wiki/Key:addr:suburb > > Gibt es einen Grund für diese addr:suburb-Tags? Würden die > eingezeichneten Quartier-Grenzen nicht ausreichen? > > Grüsse > > Markus
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Bonjour,
Je suis d'accord que l'affichage de l'adresse d'un bâtiment sur osm.org sans devoir demander l’adresse serrait utile. Si les autres sont du même avis, souhaites-tu faire le ticket ?
pour les fontaines, je ne connais aucune fontaine ayant une adresse postale pour écrire à la fontaine :) je pense donc que addr: est erroné sur une fontaine. Que veux dire is_in:Freie_Standortbeschreibung ? que la fontaine est dans un lieu public et pas dans un jardin privé ? Si oui, je le remplacerait par un tag access=private sur la fontaine privé et aucun tag sur la fontaine publique.
Salutations, Marc
Le 03. 05. 18 à 23:46, Andreas Bürki a écrit :
Rechner/Computer benötigen imho die Angaben in einem Knoten nicht. Jedoch sind die Angaben für Menschen ganz nützlich
https://www.openstreetmap.org/node/703577602Auf einen Blick sieht/liest der Mensch alle Details zu einer Adresse und kann sie beispielsweise für seine verbale Kommunikation verwenden.
Wenn die OSM Software in der Lage wäre, die Objekte, wie Häuser mit den Daten aus einem Polygon zu ergänzen, also für Menschen lesbar zu machen so wie im Knoten oben, müsste man sie (Land, (Kanton), Gemeinde, Quartier und Strasse) nicht mehr von Hand eingeben. Somit wäre es für den Mapper weniger Arbeit bei gleichem Nutzen für den gemeinen OSM Webanwender.
Bezüglich des is_in Tag werde ich im allgemeinen nicht ganz schlau. Scheint mir so ein Überbleibsel aus den frühen OSM-Anfängen zu sein.
* https://wiki.openstreetmap.org/wiki/Key:is_inIch fragte mich aber auch, ob es sinnvoll sein könnte, is_in zu nutzen um den *Standort* von Objekten (z.B. Brunnen, Hydranten) besser (oder überhaupt) zu beschreiben - z.B. für uMaps - und somit addr:* nicht zu "belasten"
Beispiele (mit Adresse oder Standort):
* https://commons.wikimedia.org/wiki/Category:Fountains_in_Bern ->Link zu uMap * https://umap.osm.ch/de/map/brunnen-in-stadt-und-gemeinde-bern_124
* http://umap.osm.ch/de/map/standorte-defibrillatoren_172Adressen/Standorte werden direkt aus OSM (addr:* was teilweise etwas einschränkend ist) generiert/verwendet.
Wäre die Verwendung von is_in:Freie_Standortbeschreibung geeigneter als addr:* ?
cheeers, h.
Am 03.05.2018 um 19:32 schrieb marc marc:
Pour moi oui les relations sont suffisantes. Idéalement il faudrait faire un énorme nettoyage pour tous les niveaux d'adresses continent, pays, canton, commune
j'ai aussi en projet de faire des tickets pour que les principales applications et éditeur prennent mieux en compte les informations présente sur les relations. c'est sans doute une raison pour laquelle certaines personnes les dupliquent sur de nombreux objets
Le 03. 05. 18 à 18:39, Selfish Seahorse a écrit :
C'est pourquoi que je me suis demandé si les relations ne seraient pas suffisantes.
2018-05-03 18:35 GMT+02:00 Selfish Seahorse selfishseahorse@gmail.com:
En effet, on a déjà des relations pour les quartiers et Nominatim les comprends ; par exemple il identifie le quartier Mattenhof pour l'adresse Pilgerweg 7, Bern bien que cette adresse n'ait pas d'attribut addr:suburb :
https://www.openstreetmap.org/search?query=7%20pilgerweg%20bern#map=19/46.94...
2018-05-03 18:18 GMT+02:00 marc marc marc_marc_irc@hotmail.com:
étant donné que quasiment aucun outil n'utilise is_in et que cela provoque des tags redondant en grand nombre, si l'étendue du quartier est connue, le mieux est de faire un polygone avec place=neighbourhood + name=*
Le 03. 05. 18 à 18:15, Selfish Seahorse a écrit :
Ich frage mich jedoch, ob die Angabe zum Quartier dann nicht besser in einem anderen Tag (z. B. is_in:neighbourhood=*) untergebracht wäre.
2018-05-03 13:39 GMT+02:00 Andreas Bürki abuerki@anidor.com: > Salut > > Wenn es nur um Daten an und für sich geht, reichen IMHO die importierten > Quartier-Grenzen. > > Wenn man dem gemeinen OSM Benutzer einen Komfort bieten will, denke ich, > das die addr:suburb-Tags noch ganz praktisch/hilfreich sind; klar, sie > müssen korrekt sein, sonst sind sie eher verwirrlich. > > > Just my 2 cents... > > > cheeers, h. > > Am 01.05.2018 um 19:06 schrieb Selfish Seahorse: >> Hallo >> >> Mir ist aufgefallen, dass in Bern viele Adressen ein addr:suburb-Tag >> [^1] besitzen (z. B. addr:suburb=Länggasse), obwohl das Quartier nicht >> zur postalischen Adresse gehört. >> >> [^1]: https://wiki.openstreetmap.org/wiki/Key:addr:suburb >> >> Gibt es einen Grund für diese addr:suburb-Tags? Würden die >> eingezeichneten Quartier-Grenzen nicht ausreichen? >> >> Grüsse >> >> Markus
Salut
Am 04.05.2018 um 07:18 schrieb marc marc:
Bonjour,
Je suis d'accord que l'affichage de l'adresse d'un bâtiment sur osm.org sans devoir demander l’adresse serrait utile. Si les autres sont du même avis, souhaites-tu faire le ticket ?
pour les fontaines, je ne connais aucune fontaine ayant une adresse postale pour écrire à la fontaine :) je pense donc que addr: est erroné sur une fontaine.
Richtig, im Allgemeinen hat ein Brunnen oder ein Denkmal oder ein Defibrilator keine Postadresse. Ich kenne nur eine Ausnahme: Der Lenbrunnen im Haus Postgasse 68 in der Berner Altstadt (https://de.wikipedia.org/wiki/Lenbrunnen)
Aber: JEDER Brunnen, JEDES Denkmal, JEDER Hydrant, JEDER Defibrilator hat einen STANDORT (https://de.wikipedia.org/wiki/Standort).
Ein Standort kann z.B. sein (Anm. Phantasie Adressen): - Vor dem Haus Hauptstrasse 14 in 3011 Bern - In der Ecke des Münsterplatzes vor dem Haus Junkerngasse 37 in der Altstadt von 3011 Bern - Ecke Länggassstrasse / Neubrückstrasse im Länggassequartier in 3012 Bern
usw.
Heisst, der Standort wird frei beschreiben. Das ist mit Freie_Standortbeschreibung gemeint
*Einfach nur die addr=* Tags zu löschen, ist keine Lösung! Ersetzen ja, mit was auch immer, aber nicht löschen!!!
Also sagt mir bitte, wie ich taggen -
is_in= oder location= oder
note= note_1= oder
note_location= oder
location_note= oder
location:description= oder ?
- soll, nicht zu taggen ist IMHO ganz sicher keine Lösung.
cheeers, h.
Que veux dire is_in:Freie_Standortbeschreibung ? que la fontaine est dans un lieu public et pas dans un jardin privé ? Si oui, je le remplacerait par un tag access=private sur la fontaine privé et aucun tag sur la fontaine publique.
Salutations, Marc
Le 03. 05. 18 à 23:46, Andreas Bürki a écrit :
Rechner/Computer benötigen imho die Angaben in einem Knoten nicht. Jedoch sind die Angaben für Menschen ganz nützlich
https://www.openstreetmap.org/node/703577602Auf einen Blick sieht/liest der Mensch alle Details zu einer Adresse und kann sie beispielsweise für seine verbale Kommunikation verwenden.
Wenn die OSM Software in der Lage wäre, die Objekte, wie Häuser mit den Daten aus einem Polygon zu ergänzen, also für Menschen lesbar zu machen so wie im Knoten oben, müsste man sie (Land, (Kanton), Gemeinde, Quartier und Strasse) nicht mehr von Hand eingeben. Somit wäre es für den Mapper weniger Arbeit bei gleichem Nutzen für den gemeinen OSM Webanwender.
Bezüglich des is_in Tag werde ich im allgemeinen nicht ganz schlau. Scheint mir so ein Überbleibsel aus den frühen OSM-Anfängen zu sein.
* https://wiki.openstreetmap.org/wiki/Key:is_inIch fragte mich aber auch, ob es sinnvoll sein könnte, is_in zu nutzen um den *Standort* von Objekten (z.B. Brunnen, Hydranten) besser (oder überhaupt) zu beschreiben - z.B. für uMaps - und somit addr:* nicht zu "belasten"
Beispiele (mit Adresse oder Standort):
* https://commons.wikimedia.org/wiki/Category:Fountains_in_Bern ->Link zu uMap * https://umap.osm.ch/de/map/brunnen-in-stadt-und-gemeinde-bern_124
* http://umap.osm.ch/de/map/standorte-defibrillatoren_172Adressen/Standorte werden direkt aus OSM (addr:* was teilweise etwas einschränkend ist) generiert/verwendet.
Wäre die Verwendung von is_in:Freie_Standortbeschreibung geeigneter als addr:* ?
cheeers, h.
Am 03.05.2018 um 19:32 schrieb marc marc:
Pour moi oui les relations sont suffisantes. Idéalement il faudrait faire un énorme nettoyage pour tous les niveaux d'adresses continent, pays, canton, commune
j'ai aussi en projet de faire des tickets pour que les principales applications et éditeur prennent mieux en compte les informations présente sur les relations. c'est sans doute une raison pour laquelle certaines personnes les dupliquent sur de nombreux objets
Le 03. 05. 18 à 18:39, Selfish Seahorse a écrit :
C'est pourquoi que je me suis demandé si les relations ne seraient pas suffisantes.
2018-05-03 18:35 GMT+02:00 Selfish Seahorse selfishseahorse@gmail.com:
En effet, on a déjà des relations pour les quartiers et Nominatim les comprends ; par exemple il identifie le quartier Mattenhof pour l'adresse Pilgerweg 7, Bern bien que cette adresse n'ait pas d'attribut addr:suburb :
https://www.openstreetmap.org/search?query=7%20pilgerweg%20bern#map=19/46.94...
2018-05-03 18:18 GMT+02:00 marc marc marc_marc_irc@hotmail.com:
étant donné que quasiment aucun outil n'utilise is_in et que cela provoque des tags redondant en grand nombre, si l'étendue du quartier est connue, le mieux est de faire un polygone avec place=neighbourhood + name=*
Le 03. 05. 18 à 18:15, Selfish Seahorse a écrit : > Ich frage mich jedoch, ob die Angabe zum Quartier dann nicht besser in > einem anderen Tag (z. B. is_in:neighbourhood=*) untergebracht wäre. > > 2018-05-03 13:39 GMT+02:00 Andreas Bürki abuerki@anidor.com: >> Salut >> >> Wenn es nur um Daten an und für sich geht, reichen IMHO die importierten >> Quartier-Grenzen. >> >> Wenn man dem gemeinen OSM Benutzer einen Komfort bieten will, denke ich, >> das die addr:suburb-Tags noch ganz praktisch/hilfreich sind; klar, sie >> müssen korrekt sein, sonst sind sie eher verwirrlich. >> >> >> Just my 2 cents... >> >> >> cheeers, h. >> >> Am 01.05.2018 um 19:06 schrieb Selfish Seahorse: >>> Hallo >>> >>> Mir ist aufgefallen, dass in Bern viele Adressen ein addr:suburb-Tag >>> [^1] besitzen (z. B. addr:suburb=Länggasse), obwohl das Quartier nicht >>> zur postalischen Adresse gehört. >>> >>> [^1]: https://wiki.openstreetmap.org/wiki/Key:addr:suburb >>> >>> Gibt es einen Grund für diese addr:suburb-Tags? Würden die >>> eingezeichneten Quartier-Grenzen nicht ausreichen? >>> >>> Grüsse >>> >>> Markus
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Bonjour Andreas,
Le 29. 05. 18 à 23:17, Andreas Bürki a écrit :
Am 04.05.2018 um 07:18 schrieb marc marc:
Je suis d'accord que l'affichage de l'adresse d'un bâtiment sur osm.org sans devoir demander l’adresse serrait utile. Si les autres sont du même avis, souhaites-tu faire le ticket ?
This question remain open.
pour les fontaines, je ne connais aucune fontaine ayant une adresse postale pour écrire à la fontaine :) je pense donc que addr: est erroné sur une fontaine.
Richtig, im Allgemeinen hat ein Brunnen oder ein Denkmal oder ein Defibrilator keine Postadresse. Ich kenne nur eine Ausnahme: Der Lenbrunnen im Haus Postgasse 68 in der Berner Altstadt (https://de.wikipedia.org/wiki/Lenbrunnen)
This one https://www.openstreetmap.org/node/5543349328 ? imho this fountain also doesn't have any postal address. The postal addresses is for the building, not for the fountain. Think for a moment about the indoor tag, we don't add the postal code on steps, walls, lift, indoor rooms of the building, etc.. We only put addr:* once on the building or on a node We don't duplicate housenumber to give a fictional housenumber to every object near or inside this building..
Aber: JEDER Brunnen, JEDES Denkmal, JEDER Hydrant, JEDER Defibrilator hat einen STANDORT (https://de.wikipedia.org/wiki/Standort).
Of course. every object in osm have at least on longitude and latitude. You can request if a fountain is inside a building or near this building and get the postal address of this building. You can also request a routing to this location without any need to duplicate any addr
*Einfach nur die addr=* Tags zu löschen, ist keine Lösung! Ersetzen ja, mit was auch immer, aber nicht löschen!!!
If you are talking about this changeset https://www.openstreetmap.org/changeset/59365364 nothing is lost, see for ex : https://www.openstreetmap.org/node/5543349328 https://www.openstreetmap.org/search?query=46.94886%2C7.45294 the fountain doesn't have a fictional addr:* any more but you can still request the postal address of this location.
If it doesn't solve you usecase, can you explain witch usecase you try to solve with this fictional postal addr on a fountain ? understand the need 'll help to find a better solution.
Also sagt mir bitte, wie ich taggen -
For an postal addr, put it once on the building or one node near the related building. Every nearby object will inherit this information.
To specify the not-postal location of an object, you can use the key location https://wiki.openstreetmap.org/wiki/Key:location
- soll, nicht zu taggen ist IMHO ganz sicher keine Lösung.
Do you add a key to each building near a park with note="this building is near a park" ? I don't think so. we (try to) put the info once on the related object.
cheeers, h.
Regards, Marc
Que veux dire is_in:Freie_Standortbeschreibung ? que la fontaine est dans un lieu public et pas dans un jardin privé ? Si oui, je le remplacerait par un tag access=private sur la fontaine privé et aucun tag sur la fontaine publique.
Salutations, Marc
Le 03. 05. 18 à 23:46, Andreas Bürki a écrit :
Rechner/Computer benötigen imho die Angaben in einem Knoten nicht. Jedoch sind die Angaben für Menschen ganz nützlich
https://www.openstreetmap.org/node/703577602Auf einen Blick sieht/liest der Mensch alle Details zu einer Adresse und kann sie beispielsweise für seine verbale Kommunikation verwenden.
Wenn die OSM Software in der Lage wäre, die Objekte, wie Häuser mit den Daten aus einem Polygon zu ergänzen, also für Menschen lesbar zu machen so wie im Knoten oben, müsste man sie (Land, (Kanton), Gemeinde, Quartier und Strasse) nicht mehr von Hand eingeben. Somit wäre es für den Mapper weniger Arbeit bei gleichem Nutzen für den gemeinen OSM Webanwender.
Bezüglich des is_in Tag werde ich im allgemeinen nicht ganz schlau. Scheint mir so ein Überbleibsel aus den frühen OSM-Anfängen zu sein.
* https://wiki.openstreetmap.org/wiki/Key:is_inIch fragte mich aber auch, ob es sinnvoll sein könnte, is_in zu nutzen um den *Standort* von Objekten (z.B. Brunnen, Hydranten) besser (oder überhaupt) zu beschreiben - z.B. für uMaps - und somit addr:* nicht zu "belasten"
Beispiele (mit Adresse oder Standort):
* https://commons.wikimedia.org/wiki/Category:Fountains_in_Bern ->Link zu uMap * https://umap.osm.ch/de/map/brunnen-in-stadt-und-gemeinde-bern_124
* http://umap.osm.ch/de/map/standorte-defibrillatoren_172Adressen/Standorte werden direkt aus OSM (addr:* was teilweise etwas einschränkend ist) generiert/verwendet.
Wäre die Verwendung von is_in:Freie_Standortbeschreibung geeigneter als addr:* ?
cheeers, h.
Am 03.05.2018 um 19:32 schrieb marc marc:
Pour moi oui les relations sont suffisantes. Idéalement il faudrait faire un énorme nettoyage pour tous les niveaux d'adresses continent, pays, canton, commune
j'ai aussi en projet de faire des tickets pour que les principales applications et éditeur prennent mieux en compte les informations présente sur les relations. c'est sans doute une raison pour laquelle certaines personnes les dupliquent sur de nombreux objets
Le 03. 05. 18 à 18:39, Selfish Seahorse a écrit :
C'est pourquoi que je me suis demandé si les relations ne seraient pas suffisantes.
2018-05-03 18:35 GMT+02:00 Selfish Seahorse selfishseahorse@gmail.com:
En effet, on a déjà des relations pour les quartiers et Nominatim les comprends ; par exemple il identifie le quartier Mattenhof pour l'adresse Pilgerweg 7, Bern bien que cette adresse n'ait pas d'attribut addr:suburb :
https://www.openstreetmap.org/search?query=7%20pilgerweg%20bern#map=19/46.94...
2018-05-03 18:18 GMT+02:00 marc marc marc_marc_irc@hotmail.com: > étant donné que quasiment aucun outil n'utilise is_in et que cela > provoque des tags redondant en grand nombre, > si l'étendue du quartier est connue, le mieux est de faire un polygone > avec place=neighbourhood + name=* > > Le 03. 05. 18 à 18:15, Selfish Seahorse a écrit : >> Ich frage mich jedoch, ob die Angabe zum Quartier dann nicht besser in >> einem anderen Tag (z. B. is_in:neighbourhood=*) untergebracht wäre. >> >> 2018-05-03 13:39 GMT+02:00 Andreas Bürki abuerki@anidor.com: >>> Salut >>> >>> Wenn es nur um Daten an und für sich geht, reichen IMHO die importierten >>> Quartier-Grenzen. >>> >>> Wenn man dem gemeinen OSM Benutzer einen Komfort bieten will, denke ich, >>> das die addr:suburb-Tags noch ganz praktisch/hilfreich sind; klar, sie >>> müssen korrekt sein, sonst sind sie eher verwirrlich. >>> >>> >>> Just my 2 cents... >>> >>> >>> cheeers, h. >>> >>> Am 01.05.2018 um 19:06 schrieb Selfish Seahorse: >>>> Hallo >>>> >>>> Mir ist aufgefallen, dass in Bern viele Adressen ein addr:suburb-Tag >>>> [^1] besitzen (z. B. addr:suburb=Länggasse), obwohl das Quartier nicht >>>> zur postalischen Adresse gehört. >>>> >>>> [^1]: https://wiki.openstreetmap.org/wiki/Key:addr:suburb >>>> >>>> Gibt es einen Grund für diese addr:suburb-Tags? Würden die >>>> eingezeichneten Quartier-Grenzen nicht ausreichen? >>>> >>>> Grüsse >>>> Markus
Hello Marc
Am 30.05.2018 um 01:31 schrieb marc marc:
Bonjour Andreas,
Le 29. 05. 18 à 23:17, Andreas Bürki a écrit :
Am 04.05.2018 um 07:18 schrieb marc marc:
Je suis d'accord que l'affichage de l'adresse d'un bâtiment sur osm.org sans devoir demander l’adresse serrait utile. Si les autres sont du même avis, souhaites-tu faire le ticket ?
This question remain open.
Yup...
pour les fontaines, je ne connais aucune fontaine ayant une adresse postale pour écrire à la fontaine :) je pense donc que addr: est erroné sur une fontaine.
Richtig, im Allgemeinen hat ein Brunnen oder ein Denkmal oder ein Defibrilator keine Postadresse. Ich kenne nur eine Ausnahme: Der Lenbrunnen im Haus Postgasse 68 in der Berner Altstadt (https://de.wikipedia.org/wiki/Lenbrunnen)
Yes
imho this fountain also doesn't have any postal address.
No, the fountain doesn't have a postal address. But a location and now, without addr:=* nothing is displayed related to location and a web browser user has to guess the address or to have a second or a third look in oder to see/describe or communicate the location address. Needless to talk about vandalism on OSM (e.g. moving knots to some other place on the map, thus users will be misleaded.)
The postal addresses is for the building, not for the fountain. Think for a moment about the indoor tag, we don't add the postal code on steps, walls, lift, indoor rooms of the building, etc..
In general rue. We add indoor tags only to businesses as shops, restaurants, offices etc. in order to display all related information (usually on the left side in the brower window) , e.g.
https://www.openstreetmap.org/node/2320901399
Thus, you have as an ordinary user of a web browser all information in one go and no need for additional action.
And it should not be a problem with several knots having the same postal address; a smart software of a GPS navigation device should be able to find the relevant knot.
We only put addr:* once on the building or on a node We don't duplicate housenumber to give a fictional housenumber to every object near or inside this building..
Aber: JEDER Brunnen, JEDES Denkmal, JEDER Hydrant, JEDER Defibrilator hat einen STANDORT (https://de.wikipedia.org/wiki/Standort).
Of course. every object in osm have at least on longitude and latitude.
That's nice for computers, but not really for humans who are talking to each other...
You can request if a fountain is inside a building or near this building and get the postal address of this building. You can also request a routing to this location without any need to duplicate any addr
Computers yes, humans have to guess or to take more actions, as nothing related to the location/address is displayed in a web browser.
*Einfach nur die addr=* Tags zu löschen, ist keine Lösung! Ersetzen ja, mit was auch immer, aber nicht löschen!!!
If you are talking about this changeset https://www.openstreetmap.org/changeset/59365364 nothing is lost,
On OSM never something get lost, we all know that :-)
see for ex : https://www.openstreetmap.org/node/5543349328 https://www.openstreetmap.org/search?query=46.94886%2C7.45294 the fountain doesn't have a fictional addr:* any more but you can still request the postal address of this location.
See my comments above... very inconvenient and a lot more work.
If it doesn't solve you usecase, can you explain witch usecase you try to solve with this fictional postal addr on a fountain ?
A uMap for Fountains in Bern: https://umap.osm.ch/de/map/brunnen-in-stadt-und-gemeinde-bern_124
My notes for the map:
https://wiki.openstreetmap.org/wiki/User:Hugi99/Workbench/uMap_Berner_Brunne...
Code for the pop-up window on the left: # **{name}** [[{image}|{{{image}}}]] *Bildquelle und weitere Fotos: [[https://commons.wikimedia.org/wiki/%7Bwikimedia_commons%7D%7Ccommons.wikimed...
Standort: {addr:street}, {addr:postcode} {addr:city}
Beschreibung: {description:de}
Wikipedia: [[https://de.wikipedia.org/wiki/%7Bwikipedia%7D%7C%7Bwikipedia%7D]]
Wikidata: [[http://www.wikidata.org/wiki/%7Bwikidata%7D%7C%7Bwikidata%7D]]
Same principles apply as well to: https://umap.osm.ch/de/map/standorte-defibrillatoren_172 (of course without wiki stuff) https://umap.osm.ch/de/map/kulturguter-in-bern_112 https://umap.osm.ch/de/map/feuerwehrstandorte-und-hydranten_98 (of course without wiki stuff)
understand the need 'll help to find a better solution.
Also sagt mir bitte, wie ich taggen -
For an postal addr, put it once on the building or one node near the related building. Every nearby object will inherit this information.
See my comments above...
To specify the not-postal location of an object, you can use the key location https://wiki.openstreetmap.org/wiki/Key:location
That one I was thinking as well. But then reading the values of this key, I got to the conclusion, that I'll run into trouble, as key is not some kind of an "address replacement", but more of a specification related to an object.
Or, as a ugly solution, I could use or create keys like: note_1= (note= is often already busy) or description:location=
Just my 2 cents so far...
cheeers, h.
- soll, nicht zu taggen ist IMHO ganz sicher keine Lösung.
Do you add a key to each building near a park with note="this building is near a park" ?
No, as the building has an address, thus no need to do so.
I don't think so. we (try to) put the info once on the related object.
Underline "try" :-)
BTW, I'm a big fan of DRY, but sometimes it simply doesn't work or the trade-off is quite inconvenient for an ordinary user of a web browser.
cheeers, h.
Regards, Marc
Que veux dire is_in:Freie_Standortbeschreibung ? que la fontaine est dans un lieu public et pas dans un jardin privé ? Si oui, je le remplacerait par un tag access=private sur la fontaine privé et aucun tag sur la fontaine publique.
Salutations, Marc
Le 03. 05. 18 à 23:46, Andreas Bürki a écrit :
Rechner/Computer benötigen imho die Angaben in einem Knoten nicht. Jedoch sind die Angaben für Menschen ganz nützlich
https://www.openstreetmap.org/node/703577602Auf einen Blick sieht/liest der Mensch alle Details zu einer Adresse und kann sie beispielsweise für seine verbale Kommunikation verwenden.
Wenn die OSM Software in der Lage wäre, die Objekte, wie Häuser mit den Daten aus einem Polygon zu ergänzen, also für Menschen lesbar zu machen so wie im Knoten oben, müsste man sie (Land, (Kanton), Gemeinde, Quartier und Strasse) nicht mehr von Hand eingeben. Somit wäre es für den Mapper weniger Arbeit bei gleichem Nutzen für den gemeinen OSM Webanwender.
Bezüglich des is_in Tag werde ich im allgemeinen nicht ganz schlau. Scheint mir so ein Überbleibsel aus den frühen OSM-Anfängen zu sein.
* https://wiki.openstreetmap.org/wiki/Key:is_inIch fragte mich aber auch, ob es sinnvoll sein könnte, is_in zu nutzen um den *Standort* von Objekten (z.B. Brunnen, Hydranten) besser (oder überhaupt) zu beschreiben - z.B. für uMaps - und somit addr:* nicht zu "belasten"
Beispiele (mit Adresse oder Standort):
* https://commons.wikimedia.org/wiki/Category:Fountains_in_Bern ->Link zu uMap * https://umap.osm.ch/de/map/brunnen-in-stadt-und-gemeinde-bern_124
* http://umap.osm.ch/de/map/standorte-defibrillatoren_172Adressen/Standorte werden direkt aus OSM (addr:* was teilweise etwas einschränkend ist) generiert/verwendet.
Wäre die Verwendung von is_in:Freie_Standortbeschreibung geeigneter als addr:* ?
cheeers, h.
Am 03.05.2018 um 19:32 schrieb marc marc:
Pour moi oui les relations sont suffisantes. Idéalement il faudrait faire un énorme nettoyage pour tous les niveaux d'adresses continent, pays, canton, commune
j'ai aussi en projet de faire des tickets pour que les principales applications et éditeur prennent mieux en compte les informations présente sur les relations. c'est sans doute une raison pour laquelle certaines personnes les dupliquent sur de nombreux objets
Le 03. 05. 18 à 18:39, Selfish Seahorse a écrit :
C'est pourquoi que je me suis demandé si les relations ne seraient pas suffisantes.
2018-05-03 18:35 GMT+02:00 Selfish Seahorse selfishseahorse@gmail.com: > En effet, on a déjà des relations pour les quartiers et Nominatim les > comprends ; par exemple il identifie le quartier Mattenhof pour > l'adresse Pilgerweg 7, Bern bien que cette adresse n'ait pas > d'attribut addr:suburb : > > https://www.openstreetmap.org/search?query=7%20pilgerweg%20bern#map=19/46.94... > > 2018-05-03 18:18 GMT+02:00 marc marc marc_marc_irc@hotmail.com: >> étant donné que quasiment aucun outil n'utilise is_in et que cela >> provoque des tags redondant en grand nombre, >> si l'étendue du quartier est connue, le mieux est de faire un polygone >> avec place=neighbourhood + name=* >> >> Le 03. 05. 18 à 18:15, Selfish Seahorse a écrit : >>> Ich frage mich jedoch, ob die Angabe zum Quartier dann nicht besser in >>> einem anderen Tag (z. B. is_in:neighbourhood=*) untergebracht wäre. >>> >>> 2018-05-03 13:39 GMT+02:00 Andreas Bürki abuerki@anidor.com: >>>> Salut >>>> >>>> Wenn es nur um Daten an und für sich geht, reichen IMHO die importierten >>>> Quartier-Grenzen. >>>> >>>> Wenn man dem gemeinen OSM Benutzer einen Komfort bieten will, denke ich, >>>> das die addr:suburb-Tags noch ganz praktisch/hilfreich sind; klar, sie >>>> müssen korrekt sein, sonst sind sie eher verwirrlich. >>>> >>>> >>>> Just my 2 cents... >>>> >>>> >>>> cheeers, h. >>>> >>>> Am 01.05.2018 um 19:06 schrieb Selfish Seahorse: >>>>> Hallo >>>>> >>>>> Mir ist aufgefallen, dass in Bern viele Adressen ein addr:suburb-Tag >>>>> [^1] besitzen (z. B. addr:suburb=Länggasse), obwohl das Quartier nicht >>>>> zur postalischen Adresse gehört. >>>>> >>>>> [^1]: https://wiki.openstreetmap.org/wiki/Key:addr:suburb >>>>> >>>>> Gibt es einen Grund für diese addr:suburb-Tags? Würden die >>>>> eingezeichneten Quartier-Grenzen nicht ausreichen? >>>>> >>>>> Grüsse >>>>> Markus
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hello everyone
I see it the same way Marc does. An address usually belongs to a building and therefore should only be added to the building (or part of it). I also don't duplicate addresses for restaurants or shops, because I think that a map application should get that information form the building area, the same way as for example addr:country is taken from the country multipolygon. In my opinion, we shouldn't try to fix the mentioned deficiencies of the OSM homepage with tagging.
Something else regarding the fountains in Bern: Are names like 'Brunnen Lorrainestrasse Ecke Schulweg', 'Brunnen Spielplatz Rosengarten' or 'Brunnen Innenhof ehemaliges Gebäude Schweizer Mobiliar' really known names of these fountains? It rather seems to me that these are descriptions.
Good night
Markus
On 31 May 2018 at 17:03, Andreas Bürki abuerki@anidor.com wrote:
Hello Marc
Am 30.05.2018 um 01:31 schrieb marc marc:
Bonjour Andreas,
Le 29. 05. 18 à 23:17, Andreas Bürki a écrit :
Am 04.05.2018 um 07:18 schrieb marc marc:
Je suis d'accord que l'affichage de l'adresse d'un bâtiment sur osm.org sans devoir demander l’adresse serrait utile. Si les autres sont du même avis, souhaites-tu faire le ticket ?
This question remain open.
Yup...
pour les fontaines, je ne connais aucune fontaine ayant une adresse postale pour écrire à la fontaine :) je pense donc que addr: est erroné sur une fontaine.
Richtig, im Allgemeinen hat ein Brunnen oder ein Denkmal oder ein Defibrilator keine Postadresse. Ich kenne nur eine Ausnahme: Der Lenbrunnen im Haus Postgasse 68 in der Berner Altstadt (https://de.wikipedia.org/wiki/Lenbrunnen)
Yes
imho this fountain also doesn't have any postal address.
No, the fountain doesn't have a postal address. But a location and now, without addr:=* nothing is displayed related to location and a web browser user has to guess the address or to have a second or a third look in oder to see/describe or communicate the location address. Needless to talk about vandalism on OSM (e.g. moving knots to some other place on the map, thus users will be misleaded.)
The postal addresses is for the building, not for the fountain. Think for a moment about the indoor tag, we don't add the postal code on steps, walls, lift, indoor rooms of the building, etc..
In general rue. We add indoor tags only to businesses as shops, restaurants, offices etc. in order to display all related information (usually on the left side in the brower window) , e.g.
https://www.openstreetmap.org/node/2320901399
Thus, you have as an ordinary user of a web browser all information in one go and no need for additional action.
And it should not be a problem with several knots having the same postal address; a smart software of a GPS navigation device should be able to find the relevant knot.
We only put addr:* once on the building or on a node We don't duplicate housenumber to give a fictional housenumber to every object near or inside this building..
Aber: JEDER Brunnen, JEDES Denkmal, JEDER Hydrant, JEDER Defibrilator hat einen STANDORT (https://de.wikipedia.org/wiki/Standort).
Of course. every object in osm have at least on longitude and latitude.
That's nice for computers, but not really for humans who are talking to each other...
You can request if a fountain is inside a building or near this building and get the postal address of this building. You can also request a routing to this location without any need to duplicate any addr
Computers yes, humans have to guess or to take more actions, as nothing related to the location/address is displayed in a web browser.
*Einfach nur die addr=* Tags zu löschen, ist keine Lösung! Ersetzen ja, mit was auch immer, aber nicht löschen!!!
If you are talking about this changeset https://www.openstreetmap.org/changeset/59365364 nothing is lost,
On OSM never something get lost, we all know that :-)
see for ex : https://www.openstreetmap.org/node/5543349328 https://www.openstreetmap.org/search?query=46.94886%2C7.45294 the fountain doesn't have a fictional addr:* any more but you can still request the postal address of this location.
See my comments above... very inconvenient and a lot more work.
If it doesn't solve you usecase, can you explain witch usecase you try to solve with this fictional postal addr on a fountain ?
A uMap for Fountains in Bern: https://umap.osm.ch/de/map/brunnen-in-stadt-und-gemeinde-bern_124
My notes for the map:
https://wiki.openstreetmap.org/wiki/User:Hugi99/Workbench/uMap_Berner_Brunne...
Code for the pop-up window on the left: # **{name}** [[{image}|{{{image}}}]] *Bildquelle und weitere Fotos: [[https://commons.wikimedia.org/wiki/%7Bwikimedia_commons%7D%7Ccommons.wikimed...
Standort: {addr:street}, {addr:postcode} {addr:city}
Beschreibung: {description:de}
Wikipedia: [[https://de.wikipedia.org/wiki/%7Bwikipedia%7D%7C%7Bwikipedia%7D]]
Wikidata: [[http://www.wikidata.org/wiki/%7Bwikidata%7D%7C%7Bwikidata%7D]]
Same principles apply as well to: https://umap.osm.ch/de/map/standorte-defibrillatoren_172 (of course without wiki stuff) https://umap.osm.ch/de/map/kulturguter-in-bern_112 https://umap.osm.ch/de/map/feuerwehrstandorte-und-hydranten_98 (of course without wiki stuff)
understand the need 'll help to find a better solution.
Also sagt mir bitte, wie ich taggen -
For an postal addr, put it once on the building or one node near the related building. Every nearby object will inherit this information.
See my comments above...
To specify the not-postal location of an object, you can use the key location https://wiki.openstreetmap.org/wiki/Key:location
That one I was thinking as well. But then reading the values of this key, I got to the conclusion, that I'll run into trouble, as key is not some kind of an "address replacement", but more of a specification related to an object.
Or, as a ugly solution, I could use or create keys like: note_1= (note= is often already busy) or description:location=
Just my 2 cents so far...
cheeers, h.
- soll, nicht zu taggen ist IMHO ganz sicher keine Lösung.
Do you add a key to each building near a park with note="this building is near a park" ?
No, as the building has an address, thus no need to do so.
I don't think so. we (try to) put the info once on the related object.
Underline "try" :-)
BTW, I'm a big fan of DRY, but sometimes it simply doesn't work or the trade-off is quite inconvenient for an ordinary user of a web browser.
cheeers, h.
Regards, Marc
Que veux dire is_in:Freie_Standortbeschreibung ? que la fontaine est dans un lieu public et pas dans un jardin privé ? Si oui, je le remplacerait par un tag access=private sur la fontaine privé et aucun tag sur la fontaine publique.
Salutations, Marc
Le 03. 05. 18 à 23:46, Andreas Bürki a écrit :
Rechner/Computer benötigen imho die Angaben in einem Knoten nicht. Jedoch sind die Angaben für Menschen ganz nützlich
https://www.openstreetmap.org/node/703577602Auf einen Blick sieht/liest der Mensch alle Details zu einer Adresse und kann sie beispielsweise für seine verbale Kommunikation verwenden.
Wenn die OSM Software in der Lage wäre, die Objekte, wie Häuser mit den Daten aus einem Polygon zu ergänzen, also für Menschen lesbar zu machen so wie im Knoten oben, müsste man sie (Land, (Kanton), Gemeinde, Quartier und Strasse) nicht mehr von Hand eingeben. Somit wäre es für den Mapper weniger Arbeit bei gleichem Nutzen für den gemeinen OSM Webanwender.
Bezüglich des is_in Tag werde ich im allgemeinen nicht ganz schlau. Scheint mir so ein Überbleibsel aus den frühen OSM-Anfängen zu sein.
* https://wiki.openstreetmap.org/wiki/Key:is_inIch fragte mich aber auch, ob es sinnvoll sein könnte, is_in zu nutzen um den *Standort* von Objekten (z.B. Brunnen, Hydranten) besser (oder überhaupt) zu beschreiben - z.B. für uMaps - und somit addr:* nicht zu "belasten"
Beispiele (mit Adresse oder Standort):
* https://commons.wikimedia.org/wiki/Category:Fountains_in_Bern ->Link zu uMap * https://umap.osm.ch/de/map/brunnen-in-stadt-und-gemeinde-bern_124
* http://umap.osm.ch/de/map/standorte-defibrillatoren_172Adressen/Standorte werden direkt aus OSM (addr:* was teilweise etwas einschränkend ist) generiert/verwendet.
Wäre die Verwendung von is_in:Freie_Standortbeschreibung geeigneter als addr:* ?
cheeers, h.
Am 03.05.2018 um 19:32 schrieb marc marc:
Pour moi oui les relations sont suffisantes. Idéalement il faudrait faire un énorme nettoyage pour tous les niveaux d'adresses continent, pays, canton, commune
j'ai aussi en projet de faire des tickets pour que les principales applications et éditeur prennent mieux en compte les informations présente sur les relations. c'est sans doute une raison pour laquelle certaines personnes les dupliquent sur de nombreux objets
Le 03. 05. 18 à 18:39, Selfish Seahorse a écrit : > C'est pourquoi que je me suis demandé si les relations ne seraient pas > suffisantes. > > 2018-05-03 18:35 GMT+02:00 Selfish Seahorse selfishseahorse@gmail.com: >> En effet, on a déjà des relations pour les quartiers et Nominatim les >> comprends ; par exemple il identifie le quartier Mattenhof pour >> l'adresse Pilgerweg 7, Bern bien que cette adresse n'ait pas >> d'attribut addr:suburb : >> >> https://www.openstreetmap.org/search?query=7%20pilgerweg%20bern#map=19/46.94... >> >> 2018-05-03 18:18 GMT+02:00 marc marc marc_marc_irc@hotmail.com: >>> étant donné que quasiment aucun outil n'utilise is_in et que cela >>> provoque des tags redondant en grand nombre, >>> si l'étendue du quartier est connue, le mieux est de faire un polygone >>> avec place=neighbourhood + name=* >>> >>> Le 03. 05. 18 à 18:15, Selfish Seahorse a écrit : >>>> Ich frage mich jedoch, ob die Angabe zum Quartier dann nicht besser in >>>> einem anderen Tag (z. B. is_in:neighbourhood=*) untergebracht wäre. >>>> >>>> 2018-05-03 13:39 GMT+02:00 Andreas Bürki abuerki@anidor.com: >>>>> Salut >>>>> >>>>> Wenn es nur um Daten an und für sich geht, reichen IMHO die importierten >>>>> Quartier-Grenzen. >>>>> >>>>> Wenn man dem gemeinen OSM Benutzer einen Komfort bieten will, denke ich, >>>>> das die addr:suburb-Tags noch ganz praktisch/hilfreich sind; klar, sie >>>>> müssen korrekt sein, sonst sind sie eher verwirrlich. >>>>> >>>>> >>>>> Just my 2 cents... >>>>> >>>>> >>>>> cheeers, h. >>>>> >>>>> Am 01.05.2018 um 19:06 schrieb Selfish Seahorse: >>>>>> Hallo >>>>>> >>>>>> Mir ist aufgefallen, dass in Bern viele Adressen ein addr:suburb-Tag >>>>>> [^1] besitzen (z. B. addr:suburb=Länggasse), obwohl das Quartier nicht >>>>>> zur postalischen Adresse gehört. >>>>>> >>>>>> [^1]: https://wiki.openstreetmap.org/wiki/Key:addr:suburb >>>>>> >>>>>> Gibt es einen Grund für diese addr:suburb-Tags? Würden die >>>>>> eingezeichneten Quartier-Grenzen nicht ausreichen? >>>>>> >>>>>> Grüsse >>>>>> 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
Hello Everyone,
I'm a beginner editor, Geneva - Nyon area, so no comments from me.
Your mails are very useful for my reading and learning, thank you.
Salutations de , Grüssen von, Titus.
On 31. 05. 18 22:29, Selfish Seahorse wrote:
Hello everyone
I see it the same way Marc does. An address usually belongs to a building and therefore should only be added to the building (or part of it). I also don't duplicate addresses for restaurants or shops, because I think that a map application should get that information form the building area, the same way as for example addr:country is taken from the country multipolygon. In my opinion, we shouldn't try to fix the mentioned deficiencies of the OSM homepage with tagging.
Something else regarding the fountains in Bern: Are names like 'Brunnen Lorrainestrasse Ecke Schulweg', 'Brunnen Spielplatz Rosengarten' or 'Brunnen Innenhof ehemaliges Gebäude Schweizer Mobiliar' really known names of these fountains? It rather seems to me that these are descriptions.
Good night
Markus
On 31 May 2018 at 17:03, Andreas Bürki abuerki@anidor.com wrote:
Hello Marc
Am 30.05.2018 um 01:31 schrieb marc marc:
Bonjour Andreas,
Le 29. 05. 18 à 23:17, Andreas Bürki a écrit :
Am 04.05.2018 um 07:18 schrieb marc marc:
Je suis d'accord que l'affichage de l'adresse d'un bâtiment sur osm.org sans devoir demander l’adresse serrait utile. Si les autres sont du même avis, souhaites-tu faire le ticket ?
This question remain open.
Yup...
pour les fontaines, je ne connais aucune fontaine ayant une adresse postale pour écrire à la fontaine :) je pense donc que addr: est erroné sur une fontaine.
Richtig, im Allgemeinen hat ein Brunnen oder ein Denkmal oder ein Defibrilator keine Postadresse. Ich kenne nur eine Ausnahme: Der Lenbrunnen im Haus Postgasse 68 in der Berner Altstadt (https://de.wikipedia.org/wiki/Lenbrunnen)
Yes
imho this fountain also doesn't have any postal address.
No, the fountain doesn't have a postal address. But a location and now, without addr:=* nothing is displayed related to location and a web browser user has to guess the address or to have a second or a third look in oder to see/describe or communicate the location address. Needless to talk about vandalism on OSM (e.g. moving knots to some other place on the map, thus users will be misleaded.)
The postal addresses is for the building, not for the fountain. Think for a moment about the indoor tag, we don't add the postal code on steps, walls, lift, indoor rooms of the building, etc..
In general rue. We add indoor tags only to businesses as shops, restaurants, offices etc. in order to display all related information (usually on the left side in the brower window) , e.g.
https://www.openstreetmap.org/node/2320901399
Thus, you have as an ordinary user of a web browser all information in one go and no need for additional action.
And it should not be a problem with several knots having the same postal address; a smart software of a GPS navigation device should be able to find the relevant knot.
We only put addr:* once on the building or on a node We don't duplicate housenumber to give a fictional housenumber to every object near or inside this building..
Aber: JEDER Brunnen, JEDES Denkmal, JEDER Hydrant, JEDER Defibrilator hat einen STANDORT (https://de.wikipedia.org/wiki/Standort).
Of course. every object in osm have at least on longitude and latitude.
That's nice for computers, but not really for humans who are talking to each other...
You can request if a fountain is inside a building or near this building and get the postal address of this building. You can also request a routing to this location without any need to duplicate any addr
Computers yes, humans have to guess or to take more actions, as nothing related to the location/address is displayed in a web browser.
*Einfach nur die addr=* Tags zu löschen, ist keine Lösung! Ersetzen ja, mit was auch immer, aber nicht löschen!!!
If you are talking about this changeset https://www.openstreetmap.org/changeset/59365364 nothing is lost,
On OSM never something get lost, we all know that :-)
see for ex : https://www.openstreetmap.org/node/5543349328 https://www.openstreetmap.org/search?query=46.94886%2C7.45294 the fountain doesn't have a fictional addr:* any more but you can still request the postal address of this location.
See my comments above... very inconvenient and a lot more work.
If it doesn't solve you usecase, can you explain witch usecase you try to solve with this fictional postal addr on a fountain ?
A uMap for Fountains in Bern: https://umap.osm.ch/de/map/brunnen-in-stadt-und-gemeinde-bern_124
My notes for the map:
https://wiki.openstreetmap.org/wiki/User:Hugi99/Workbench/uMap_Berner_Brunne...
Code for the pop-up window on the left: # **{name}** [[{image}|{{{image}}}]] *Bildquelle und weitere Fotos: [[https://commons.wikimedia.org/wiki/%7Bwikimedia_commons%7D%7Ccommons.wikimed...
Standort: {addr:street}, {addr:postcode} {addr:city}
Beschreibung: {description:de}
Wikipedia: [[https://de.wikipedia.org/wiki/%7Bwikipedia%7D%7C%7Bwikipedia%7D]]
Wikidata: [[http://www.wikidata.org/wiki/%7Bwikidata%7D%7C%7Bwikidata%7D]]
Same principles apply as well to: https://umap.osm.ch/de/map/standorte-defibrillatoren_172 (of course without wiki stuff) https://umap.osm.ch/de/map/kulturguter-in-bern_112 https://umap.osm.ch/de/map/feuerwehrstandorte-und-hydranten_98 (of course without wiki stuff)
understand the need 'll help to find a better solution.
Also sagt mir bitte, wie ich taggen -
For an postal addr, put it once on the building or one node near the related building. Every nearby object will inherit this information.
See my comments above...
To specify the not-postal location of an object, you can use the key location https://wiki.openstreetmap.org/wiki/Key:location
That one I was thinking as well. But then reading the values of this key, I got to the conclusion, that I'll run into trouble, as key is not some kind of an "address replacement", but more of a specification related to an object.
Or, as a ugly solution, I could use or create keys like: note_1= (note= is often already busy) or description:location=
Just my 2 cents so far...
cheeers, h.
- soll, nicht zu taggen ist IMHO ganz sicher keine Lösung.
Do you add a key to each building near a park with note="this building is near a park" ?
No, as the building has an address, thus no need to do so.
I don't think so. we (try to) put the info once on the related object.
Underline "try" :-)
BTW, I'm a big fan of DRY, but sometimes it simply doesn't work or the trade-off is quite inconvenient for an ordinary user of a web browser.
cheeers, h.
Regards, Marc
Que veux dire is_in:Freie_Standortbeschreibung ? que la fontaine est dans un lieu public et pas dans un jardin privé ? Si oui, je le remplacerait par un tag access=private sur la fontaine privé et aucun tag sur la fontaine publique.
Salutations, Marc
Le 03. 05. 18 à 23:46, Andreas Bürki a écrit :
Rechner/Computer benötigen imho die Angaben in einem Knoten nicht. Jedoch sind die Angaben für Menschen ganz nützlich
https://www.openstreetmap.org/node/703577602Auf einen Blick sieht/liest der Mensch alle Details zu einer Adresse und kann sie beispielsweise für seine verbale Kommunikation verwenden.
Wenn die OSM Software in der Lage wäre, die Objekte, wie Häuser mit den Daten aus einem Polygon zu ergänzen, also für Menschen lesbar zu machen so wie im Knoten oben, müsste man sie (Land, (Kanton), Gemeinde, Quartier und Strasse) nicht mehr von Hand eingeben. Somit wäre es für den Mapper weniger Arbeit bei gleichem Nutzen für den gemeinen OSM Webanwender.
Bezüglich des is_in Tag werde ich im allgemeinen nicht ganz schlau. Scheint mir so ein Überbleibsel aus den frühen OSM-Anfängen zu sein.
* https://wiki.openstreetmap.org/wiki/Key:is_inIch fragte mich aber auch, ob es sinnvoll sein könnte, is_in zu nutzen um den *Standort* von Objekten (z.B. Brunnen, Hydranten) besser (oder überhaupt) zu beschreiben - z.B. für uMaps - und somit addr:* nicht zu "belasten"
Beispiele (mit Adresse oder Standort):
* https://commons.wikimedia.org/wiki/Category:Fountains_in_Bern ->Link zu uMap * https://umap.osm.ch/de/map/brunnen-in-stadt-und-gemeinde-bern_124
* http://umap.osm.ch/de/map/standorte-defibrillatoren_172Adressen/Standorte werden direkt aus OSM (addr:* was teilweise etwas einschränkend ist) generiert/verwendet.
Wäre die Verwendung von is_in:Freie_Standortbeschreibung geeigneter als addr:* ?
cheeers, h.
Am 03.05.2018 um 19:32 schrieb marc marc: > Pour moi oui les relations sont suffisantes. > Idéalement il faudrait faire un énorme nettoyage pour tous les niveaux > d'adresses continent, pays, canton, commune > > j'ai aussi en projet de faire des tickets pour que les principales > applications et éditeur prennent mieux en compte les informations > présente sur les relations. c'est sans doute une raison pour laquelle > certaines personnes les dupliquent sur de nombreux objets > > Le 03. 05. 18 à 18:39, Selfish Seahorse a écrit : >> C'est pourquoi que je me suis demandé si les relations ne seraient pas >> suffisantes. >> >> 2018-05-03 18:35 GMT+02:00 Selfish Seahorse selfishseahorse@gmail.com: >>> En effet, on a déjà des relations pour les quartiers et Nominatim les >>> comprends ; par exemple il identifie le quartier Mattenhof pour >>> l'adresse Pilgerweg 7, Bern bien que cette adresse n'ait pas >>> d'attribut addr:suburb : >>> >>> https://www.openstreetmap.org/search?query=7%20pilgerweg%20bern#map=19/46.94... >>> >>> 2018-05-03 18:18 GMT+02:00 marc marc marc_marc_irc@hotmail.com: >>>> étant donné que quasiment aucun outil n'utilise is_in et que cela >>>> provoque des tags redondant en grand nombre, >>>> si l'étendue du quartier est connue, le mieux est de faire un polygone >>>> avec place=neighbourhood + name=* >>>> >>>> Le 03. 05. 18 à 18:15, Selfish Seahorse a écrit : >>>>> Ich frage mich jedoch, ob die Angabe zum Quartier dann nicht besser in >>>>> einem anderen Tag (z. B. is_in:neighbourhood=*) untergebracht wäre. >>>>> >>>>> 2018-05-03 13:39 GMT+02:00 Andreas Bürki abuerki@anidor.com: >>>>>> Salut >>>>>> >>>>>> Wenn es nur um Daten an und für sich geht, reichen IMHO die importierten >>>>>> Quartier-Grenzen. >>>>>> >>>>>> Wenn man dem gemeinen OSM Benutzer einen Komfort bieten will, denke ich, >>>>>> das die addr:suburb-Tags noch ganz praktisch/hilfreich sind; klar, sie >>>>>> müssen korrekt sein, sonst sind sie eher verwirrlich. >>>>>> >>>>>> >>>>>> Just my 2 cents... >>>>>> >>>>>> >>>>>> cheeers, h. >>>>>> >>>>>> Am 01.05.2018 um 19:06 schrieb Selfish Seahorse: >>>>>>> Hallo >>>>>>> >>>>>>> Mir ist aufgefallen, dass in Bern viele Adressen ein addr:suburb-Tag >>>>>>> [^1] besitzen (z. B. addr:suburb=Länggasse), obwohl das Quartier nicht >>>>>>> zur postalischen Adresse gehört. >>>>>>> >>>>>>> [^1]: https://wiki.openstreetmap.org/wiki/Key:addr:suburb >>>>>>> >>>>>>> Gibt es einen Grund für diese addr:suburb-Tags? Würden die >>>>>>> eingezeichneten Quartier-Grenzen nicht ausreichen? >>>>>>> >>>>>>> Grüsse >>>>>>> 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
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hello Markus
Am 31.05.2018 um 22:29 schrieb Selfish Seahorse:
Hello everyone
I see it the same way Marc does. An address usually belongs to a building and therefore should only be added to the building (or part of it). I also don't duplicate addresses for restaurants or shops, because I think that a map application should get that information form the building area, the same way as for example addr:country is taken from the country multipolygon.
One exception will always remain: Buildings (e.g. Shopping malls, commercial centers) with several, different postal addresses and entrances. There, adding addr=* to businesses is the only way to display the correct address.
In my opinion, we shouldn't try to fix the mentioned deficiencies of the OSM homepage with tagging.
Sure. - But as long mentioned deficiencies are not fixed, adding addr=* to businesses as well, is the only way to add value for web browser OSM users.
Something else regarding the fountains in Bern: Are names like 'Brunnen Lorrainestrasse Ecke Schulweg', 'Brunnen Spielplatz Rosengarten' or 'Brunnen Innenhof ehemaliges Gebäude Schweizer Mobiliar' really known names of these fountains?
No. Fountain names in Bern are a bit of a mess. There are several sources, where you can find fountain names (but not all of them in one document/place) as e.g.:
- https://map.bern.ch/stadtplan - http://bauinventar.bern.ch/search?streetname=&streetnumber=&Searchab... - https://www.archives-quickaccess.ch/search/25/results?generalterm=Brunnen - http://www.bern.ch/themen/stadt-recht-und-politik/finanzen/rechnung-jahresbe... (-> Jahresbericht 2017 Band 1: Jahresrechnung HRM2 (PDF, 5.0 MB) - Search for: Brunnen, first hit page 253, main bunch is p. 259 and 260 "Figuren-Brunnen" and "Brunnen" ) - Internal document "ewb-Brunnen-Inventar Stadt Bern" (~ 120 fountains, is available upon private request)
Maybe there are other inventories on top of before mentioned ones, as e.g. from Stadtgrün Bern for fountains on playground or at schools.
Here you can find a list (actually 194, still missing 10-15) with photos :
https://commons.wikimedia.org/wiki/Category:Fountains_in_Bern
and of course, more photos are welcome :-)
It rather seems to me
that these are descriptions.
True. - Otherwise: No name or tons of fountains with name "Brunnen"
cheeers, h.
Good night
Markus
On 31 May 2018 at 17:03, Andreas Bürki abuerki@anidor.com wrote:
Hello Marc
Am 30.05.2018 um 01:31 schrieb marc marc:
Bonjour Andreas,
Le 29. 05. 18 à 23:17, Andreas Bürki a écrit :
Am 04.05.2018 um 07:18 schrieb marc marc:
Je suis d'accord que l'affichage de l'adresse d'un bâtiment sur osm.org sans devoir demander l’adresse serrait utile. Si les autres sont du même avis, souhaites-tu faire le ticket ?
This question remain open.
Yup...
pour les fontaines, je ne connais aucune fontaine ayant une adresse postale pour écrire à la fontaine :) je pense donc que addr: est erroné sur une fontaine.
Richtig, im Allgemeinen hat ein Brunnen oder ein Denkmal oder ein Defibrilator keine Postadresse. Ich kenne nur eine Ausnahme: Der Lenbrunnen im Haus Postgasse 68 in der Berner Altstadt (https://de.wikipedia.org/wiki/Lenbrunnen)
Yes
imho this fountain also doesn't have any postal address.
No, the fountain doesn't have a postal address. But a location and now, without addr:=* nothing is displayed related to location and a web browser user has to guess the address or to have a second or a third look in oder to see/describe or communicate the location address. Needless to talk about vandalism on OSM (e.g. moving knots to some other place on the map, thus users will be misleaded.)
The postal addresses is for the building, not for the fountain. Think for a moment about the indoor tag, we don't add the postal code on steps, walls, lift, indoor rooms of the building, etc..
In general rue. We add indoor tags only to businesses as shops, restaurants, offices etc. in order to display all related information (usually on the left side in the brower window) , e.g.
https://www.openstreetmap.org/node/2320901399
Thus, you have as an ordinary user of a web browser all information in one go and no need for additional action.
And it should not be a problem with several knots having the same postal address; a smart software of a GPS navigation device should be able to find the relevant knot.
We only put addr:* once on the building or on a node We don't duplicate housenumber to give a fictional housenumber to every object near or inside this building..
Aber: JEDER Brunnen, JEDES Denkmal, JEDER Hydrant, JEDER Defibrilator hat einen STANDORT (https://de.wikipedia.org/wiki/Standort).
Of course. every object in osm have at least on longitude and latitude.
That's nice for computers, but not really for humans who are talking to each other...
You can request if a fountain is inside a building or near this building and get the postal address of this building. You can also request a routing to this location without any need to duplicate any addr
Computers yes, humans have to guess or to take more actions, as nothing related to the location/address is displayed in a web browser.
*Einfach nur die addr=* Tags zu löschen, ist keine Lösung! Ersetzen ja, mit was auch immer, aber nicht löschen!!!
If you are talking about this changeset https://www.openstreetmap.org/changeset/59365364 nothing is lost,
On OSM never something get lost, we all know that :-)
see for ex : https://www.openstreetmap.org/node/5543349328 https://www.openstreetmap.org/search?query=46.94886%2C7.45294 the fountain doesn't have a fictional addr:* any more but you can still request the postal address of this location.
See my comments above... very inconvenient and a lot more work.
If it doesn't solve you usecase, can you explain witch usecase you try to solve with this fictional postal addr on a fountain ?
A uMap for Fountains in Bern: https://umap.osm.ch/de/map/brunnen-in-stadt-und-gemeinde-bern_124
My notes for the map:
https://wiki.openstreetmap.org/wiki/User:Hugi99/Workbench/uMap_Berner_Brunne...
Code for the pop-up window on the left: # **{name}** [[{image}|{{{image}}}]] *Bildquelle und weitere Fotos: [[https://commons.wikimedia.org/wiki/%7Bwikimedia_commons%7D%7Ccommons.wikimed...
Standort: {addr:street}, {addr:postcode} {addr:city}
Beschreibung: {description:de}
Wikipedia: [[https://de.wikipedia.org/wiki/%7Bwikipedia%7D%7C%7Bwikipedia%7D]]
Wikidata: [[http://www.wikidata.org/wiki/%7Bwikidata%7D%7C%7Bwikidata%7D]]
Same principles apply as well to: https://umap.osm.ch/de/map/standorte-defibrillatoren_172 (of course without wiki stuff) https://umap.osm.ch/de/map/kulturguter-in-bern_112 https://umap.osm.ch/de/map/feuerwehrstandorte-und-hydranten_98 (of course without wiki stuff)
understand the need 'll help to find a better solution.
Also sagt mir bitte, wie ich taggen -
For an postal addr, put it once on the building or one node near the related building. Every nearby object will inherit this information.
See my comments above...
To specify the not-postal location of an object, you can use the key location https://wiki.openstreetmap.org/wiki/Key:location
That one I was thinking as well. But then reading the values of this key, I got to the conclusion, that I'll run into trouble, as key is not some kind of an "address replacement", but more of a specification related to an object.
Or, as a ugly solution, I could use or create keys like: note_1= (note= is often already busy) or description:location=
Just my 2 cents so far...
cheeers, h.
- soll, nicht zu taggen ist IMHO ganz sicher keine Lösung.
Do you add a key to each building near a park with note="this building is near a park" ?
No, as the building has an address, thus no need to do so.
I don't think so. we (try to) put the info once on the related object.
Underline "try" :-)
BTW, I'm a big fan of DRY, but sometimes it simply doesn't work or the trade-off is quite inconvenient for an ordinary user of a web browser.
cheeers, h.
Regards, Marc
Que veux dire is_in:Freie_Standortbeschreibung ? que la fontaine est dans un lieu public et pas dans un jardin privé ? Si oui, je le remplacerait par un tag access=private sur la fontaine privé et aucun tag sur la fontaine publique.
Salutations, Marc
Le 03. 05. 18 à 23:46, Andreas Bürki a écrit :
Rechner/Computer benötigen imho die Angaben in einem Knoten nicht. Jedoch sind die Angaben für Menschen ganz nützlich
https://www.openstreetmap.org/node/703577602Auf einen Blick sieht/liest der Mensch alle Details zu einer Adresse und kann sie beispielsweise für seine verbale Kommunikation verwenden.
Wenn die OSM Software in der Lage wäre, die Objekte, wie Häuser mit den Daten aus einem Polygon zu ergänzen, also für Menschen lesbar zu machen so wie im Knoten oben, müsste man sie (Land, (Kanton), Gemeinde, Quartier und Strasse) nicht mehr von Hand eingeben. Somit wäre es für den Mapper weniger Arbeit bei gleichem Nutzen für den gemeinen OSM Webanwender.
Bezüglich des is_in Tag werde ich im allgemeinen nicht ganz schlau. Scheint mir so ein Überbleibsel aus den frühen OSM-Anfängen zu sein.
* https://wiki.openstreetmap.org/wiki/Key:is_inIch fragte mich aber auch, ob es sinnvoll sein könnte, is_in zu nutzen um den *Standort* von Objekten (z.B. Brunnen, Hydranten) besser (oder überhaupt) zu beschreiben - z.B. für uMaps - und somit addr:* nicht zu "belasten"
Beispiele (mit Adresse oder Standort):
* https://commons.wikimedia.org/wiki/Category:Fountains_in_Bern ->Link zu uMap * https://umap.osm.ch/de/map/brunnen-in-stadt-und-gemeinde-bern_124
* http://umap.osm.ch/de/map/standorte-defibrillatoren_172Adressen/Standorte werden direkt aus OSM (addr:* was teilweise etwas einschränkend ist) generiert/verwendet.
Wäre die Verwendung von is_in:Freie_Standortbeschreibung geeigneter als addr:* ?
cheeers, h.
Am 03.05.2018 um 19:32 schrieb marc marc: > Pour moi oui les relations sont suffisantes. > Idéalement il faudrait faire un énorme nettoyage pour tous les niveaux > d'adresses continent, pays, canton, commune > > j'ai aussi en projet de faire des tickets pour que les principales > applications et éditeur prennent mieux en compte les informations > présente sur les relations. c'est sans doute une raison pour laquelle > certaines personnes les dupliquent sur de nombreux objets > > Le 03. 05. 18 à 18:39, Selfish Seahorse a écrit : >> C'est pourquoi que je me suis demandé si les relations ne seraient pas >> suffisantes. >> >> 2018-05-03 18:35 GMT+02:00 Selfish Seahorse selfishseahorse@gmail.com: >>> En effet, on a déjà des relations pour les quartiers et Nominatim les >>> comprends ; par exemple il identifie le quartier Mattenhof pour >>> l'adresse Pilgerweg 7, Bern bien que cette adresse n'ait pas >>> d'attribut addr:suburb : >>> >>> https://www.openstreetmap.org/search?query=7%20pilgerweg%20bern#map=19/46.94... >>> >>> 2018-05-03 18:18 GMT+02:00 marc marc marc_marc_irc@hotmail.com: >>>> étant donné que quasiment aucun outil n'utilise is_in et que cela >>>> provoque des tags redondant en grand nombre, >>>> si l'étendue du quartier est connue, le mieux est de faire un polygone >>>> avec place=neighbourhood + name=* >>>> >>>> Le 03. 05. 18 à 18:15, Selfish Seahorse a écrit : >>>>> Ich frage mich jedoch, ob die Angabe zum Quartier dann nicht besser in >>>>> einem anderen Tag (z. B. is_in:neighbourhood=*) untergebracht wäre. >>>>> >>>>> 2018-05-03 13:39 GMT+02:00 Andreas Bürki abuerki@anidor.com: >>>>>> Salut >>>>>> >>>>>> Wenn es nur um Daten an und für sich geht, reichen IMHO die importierten >>>>>> Quartier-Grenzen. >>>>>> >>>>>> Wenn man dem gemeinen OSM Benutzer einen Komfort bieten will, denke ich, >>>>>> das die addr:suburb-Tags noch ganz praktisch/hilfreich sind; klar, sie >>>>>> müssen korrekt sein, sonst sind sie eher verwirrlich. >>>>>> >>>>>> >>>>>> Just my 2 cents... >>>>>> >>>>>> >>>>>> cheeers, h. >>>>>> >>>>>> Am 01.05.2018 um 19:06 schrieb Selfish Seahorse: >>>>>>> Hallo >>>>>>> >>>>>>> Mir ist aufgefallen, dass in Bern viele Adressen ein addr:suburb-Tag >>>>>>> [^1] besitzen (z. B. addr:suburb=Länggasse), obwohl das Quartier nicht >>>>>>> zur postalischen Adresse gehört. >>>>>>> >>>>>>> [^1]: https://wiki.openstreetmap.org/wiki/Key:addr:suburb >>>>>>> >>>>>>> Gibt es einen Grund für diese addr:suburb-Tags? Würden die >>>>>>> eingezeichneten Quartier-Grenzen nicht ausreichen? >>>>>>> >>>>>>> Grüsse >>>>>>> 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
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
On 4 June 2018 at 23:10, Andreas Bürki abuerki@anidor.com wrote:
I see it the same way Marc does. An address usually belongs to a building and therefore should only be added to the building (or part of it). I also don't duplicate addresses for restaurants or shops, because I think that a map application should get that information form the building area, the same way as for example addr:country is taken from the country multipolygon.
One exception will always remain: Buildings (e.g. Shopping malls, commercial centers) with several, different postal addresses and entrances. There, adding addr=* to businesses is the only way to display the correct address.
Yes, this is the only case where I duplicate addresses, as there doesn't seem to be an alternative at the moment.
In my opinion, we shouldn't try to fix the mentioned deficiencies of the OSM homepage with tagging.
Sure. - But as long mentioned deficiencies are not fixed, adding addr=* to businesses as well, is the only way to add value for web browser OSM users.
Are the developers of the OSM homepage aware of these deficiencies? Has this issue already been reported?
Something else regarding the fountains in Bern: Are names like 'Brunnen Lorrainestrasse Ecke Schulweg', 'Brunnen Spielplatz Rosengarten' or 'Brunnen Innenhof ehemaliges Gebäude Schweizer Mobiliar' really known names of these fountains?
No. Fountain names in Bern are a bit of a mess. There are several sources, where you can find fountain names (but not all of them in one document/place) as e.g.:
[...]
Apart from the fact that these sources may not be compatible with the OSM license, these seem to be internal references of the fountains, not names, as that's not how these fountains are known to the general public.
It rather seems to me
that these are descriptions.
True. - Otherwise: No name or tons of fountains with name "Brunnen"
If they don't have a name better not adding one.
On Wed, 6 Jun 2018 at 12:34, Selfish Seahorse selfishseahorse@gmail.com wrote:
On 4 June 2018 at 23:10, Andreas Bürki abuerki@anidor.com wrote:
In my opinion, we shouldn't try to fix the mentioned deficiencies of the OSM homepage with tagging.
Sure. - But as long mentioned deficiencies are not fixed, adding addr=* to businesses as well, is the only way to add value for web browser OSM users.
Are the developers of the OSM homepage aware of these deficiencies? Has this issue already been reported?
As it seems that this hasn't reported before, I've done it now:
https://github.com/openstreetmap/openstreetmap-website/issues/1901
Something else regarding the fountains in Bern: Are names like 'Brunnen Lorrainestrasse Ecke Schulweg', 'Brunnen Spielplatz Rosengarten' or 'Brunnen Innenhof ehemaliges Gebäude Schweizer Mobiliar' really known names of these fountains?
No. Fountain names in Bern are a bit of a mess. There are several sources, where you can find fountain names (but not all of them in one document/place) as e.g.:
[...]
Apart from the fact that these sources may not be compatible with the OSM license, these seem to be internal references of the fountains, not names, as that's not how these fountains are known to the general public.
Am I the only one who doesn't like these 'names'?
Le 15. 06. 18 à 10:02, Selfish Seahorse a écrit :
On Wed, 6 Jun 2018 at 12:34, Selfish Seahorse selfishseahorse@gmail.com wrote:
On 4 June 2018 at 23:10, Andreas Bürki abuerki@anidor.com wrote:
In my opinion, we shouldn't try to fix the mentioned deficiencies of the OSM homepage with tagging.
As it seems that this hasn't reported before, I've done it now: https://github.com/openstreetmap/openstreetmap-website/issues/1901
Thanks for doing it for Andrea :) I put a comment on it.
Fountain names in Bern are a bit of a mess. There are several sources, where you can find fountain names
Apart from the fact that these sources may not be compatible with the OSM license, these seem to be internal references of the fountains, not names, as that's not how these fountains are known to the general public.
Am I the only one who doesn't like these 'names'?
I can't tell if they're real names or invented names. if the inhabitants of the place call this fountain by this name, it seems to me a local but real name and which in its place in name=* On the other hand if the name only describes the object, it is not a name=* but a description=* it's a bit like amenity=post_office name=Post :-(
Regards, Marc
On Fri, 15 Jun 2018 at 10:53, marc marc marc_marc_irc@hotmail.com wrote:
I can't tell if they're real names or invented names. if the inhabitants of the place call this fountain by this name, it seems to me a local but real name and which in its place in name=* On the other hand if the name only describes the object, it is not a name=* but a description=* it's a bit like amenity=post_office name=Post :-(
Maybe people are talking for example about the fountain on the corner of Lorrainestrasse and Schulweg, but not about the corner-of-Lorrainestrasse-and-Schulweg fountain (https://www.openstreetmap.org/node/5562045081). Even the inventory linked in the note tag doesn't mention any name.
Hello
I'm proposing to move the name tag of the fountains in the city of Bern that don't end with "...brunnen", and thus are obvious descriptions, to the description tag.
Overpass query: http://overpass-turbo.eu/s/A35
100 fountains would be affected by this edit. If there is no opposition, I'm going to carry out this edit in 14 days.
Should I document this edit somewhere on the wiki?
Regards
Markus
Salut
If, please, don't use description as such, but:
description:de:name
as description might be used for general or more generic descriptions.
So far in use for fountains in Bern are:
description:de:location (examples see at the end of this email)
decription:de (example see at the end of this email)
...just my 2 cents, cheers, h.
Am 03.07.2018 um 23:18 schrieb Selfish Seahorse:
Hello
I'm proposing to move the name tag of the fountains in the city of Bern that don't end with "...brunnen", and thus are obvious descriptions, to the description tag.
Overpass query: http://overpass-turbo.eu/s/A35
100 fountains would be affected by this edit. If there is no opposition, I'm going to carry out this edit in 14 days.
Should I document this edit somewhere on the wiki?
Regards
Markus
Examples of description:de:location
Auf dem Areal des Salem-Spitals zwischen Hauptgebäude an der Schänzlistrasse 39 und der ehemaligen Salem-Kapelle an der Schänzlistrasse 27 in 3013 Bern.
Auf dem Areal des Salem-Spitals in einem kleinen Wäldchen südöstlich der ehemaligen Salem-Kapelle an der Schänzlistrasse 27 in 3013 Bern.
Im Garten des Hofes westlich vor dem ehemaligen Stürlerspital an der Altenbergstrasse 60 in 3013 Bern.
Beim Bärengraben-Kreisel zwischen dem Grossen und dem Kleinen Muristalden in 3006 Bern.
An der Hofmauer zwischen dem Hopfgut Gebäude Brunnmattstrasse 50 und dem Nebengebäude Brunnmattstrasse 50a in 3007 Bern.
Auf der Westseite des Hopfgut Gebäudes Brunnmattstrasse 50 in 3007 Bern.
An der Schwarzenburgstrasse 59 am westlichen Rande des Waldes Steinhölzli in 3008 Bern.
Im Spickel Keltenstrasse/Bernstrasse vor dem Haus Bernstrasse 72 in 3018 Bern.
Unter der ehemaligen Tennenauffahrt hinter dem Bienzgut Bernstrasse 77 in 3018 Bern.
Im Garten zwischen Herrenhaus Brünnengut Brünnenstrasse 4 und Pavillon Brünnenstrasse 8 in 3027 Bern.
Unter der ehemaligen Tennenauffahrt zum Bauernhaus Brünnengut Brünnenstrasse 10 in 3027 Bern.
Ungefähr 90 Meter nordöstlich entfernt vom Herrenhaus Brünnengut Brünnenstrasse 4 in 3027 Bern.
An der Waldmannstrasse vor dem Wohngebäude Knospenweg 2 in 3027 Bern.
Auf der Aareseite der Altenbergstrasse gegenüber dem Wohnhaus Altenbergstrasse 46-48 in 3013 Bern.
Beim Klösterlistutz gegenüber dem Gebäude Altenbergstrasse 6 in 3013 Bern.
Auf dem Areal des Bahnhofplatzes Bümpliz Süd gegenüber dem Bahnhofgebäude Bümplizstrasse 202 in 3018 Bern.
Vor dem Statthalterschulhaus Wangenstrasse 9, unter einem offenen mit Pultdach gedeckten Unterstand der Teil des Schulgebäudes Wagenstrasse 11 ist, in 3018 Bern.
Auf dem Platz im Tscharnergut zwischen Gebäude Waldmannstrasse 21 und Gebäude Fellerstrasse 28 in 3027 Bern.
Auf dem Spielplatz Nordring/Dammweg nördlich des Gebäudes Nordring 49 in 3013 Bern.
Auf dem Spielplatz Steckgut östlich des Gebäudes Lorrainestrasse 80 in 3013 Bern.
Auf dem Spielplatz KITA Lorraine Lorrainestrasse 43 in 3013 Bern.
Auf dem Spielplatz Brünnengut östlich gegenüber der Pfrundscheune Brünnengut Brünnenstrasse 12 in 3027 Bern.
Auf dem Innenhof der St. Mauritiuskirche Waldmannstrasse 60 in 3027 Bern.
Auf dem Spielplatz Brünnen Acherli im Park westlich des Gebäudes Waldmannstrasse 68 in 3027 Bern.
Auf dem Hof vor der Kirche Bethlehem Eymattstrasse 2 in 3027 Bern.
Auf der Grünfläche beim Spielplatz Tscharnergut C gegenüber des Schlittelhügels zwischen den Wohngebäuden Waldmannstrasse 53 und 67 in 3027 Bern.
Examples of description:de
Der Marabut-Brunnen wurde 1984 vom Berner Künstler René Ramp (1941-2004) kreiert. Das begehbare Objekt ist ein aus Beton gefertigter offener, riesiger Würfel in den periodisch Wasser durch das runde Deckenloch geleitet wird.
On Tue, 3 Jul 2018 at 23:31, Andreas Bürki abuerki@anidor.com wrote:
If, please, don't use description as such, but:
description:de:nameas description might be used for general or more generic descriptions.
OK
While I'm fairly undecided on the question of if a textual location description is useful or not, could we at least use normal tag construction conventions?
So not
description:de:name
or
description:de:location
but
/key/*:*/iso_language_code /And//in line with other description tags (for example wheelchair:description):
/key/:*description*
So in this case
*location:description:de * Thank you
Simon**
Am 03.07.2018 um 23:55 schrieb Selfish Seahorse:
On Tue, 3 Jul 2018 at 23:31, Andreas Bürki abuerki@anidor.com wrote:
If, please, don't use description as such, but:
description:de:nameas description might be used for general or more generic descriptions.
OK _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
On Tue, Jul 03, 2018 at 11:27:24PM +0200, Andreas Bürki wrote:
Salut
If, please, don't use description as such, but:
description:de:nameas description might be used for general or more generic descriptions.
So far in use for fountains in Bern are:
description:de:location (examples see at the end of this email)
I must have missed the discussion on that. That's really ugly.
OSM is a geospatial database that stores locations in the form of geo-coordinates. The coordinates are also useful to figure out the relative position to surrounding objects (aka: look at the map). If you rather like to have a database that stores location in the form of textual descriptions, so be it. I just don't think OSM is the place to dump all that information.
Just my 2 cents.
Sarah
decription:de (example see at the end of this email)...just my 2 cents, cheers, h.
Am 03.07.2018 um 23:18 schrieb Selfish Seahorse:
Hello
I'm proposing to move the name tag of the fountains in the city of Bern that don't end with "...brunnen", and thus are obvious descriptions, to the description tag.
Overpass query: http://overpass-turbo.eu/s/A35
100 fountains would be affected by this edit. If there is no opposition, I'm going to carry out this edit in 14 days.
Should I document this edit somewhere on the wiki?
Regards
Markus
Examples of description:de:location
Auf dem Areal des Salem-Spitals zwischen Hauptgebäude an der Schänzlistrasse 39 und der ehemaligen Salem-Kapelle an der Schänzlistrasse 27 in 3013 Bern.
Auf dem Areal des Salem-Spitals in einem kleinen Wäldchen südöstlich der ehemaligen Salem-Kapelle an der Schänzlistrasse 27 in 3013 Bern.
Im Garten des Hofes westlich vor dem ehemaligen Stürlerspital an der Altenbergstrasse 60 in 3013 Bern.
Beim Bärengraben-Kreisel zwischen dem Grossen und dem Kleinen Muristalden in 3006 Bern.
An der Hofmauer zwischen dem Hopfgut Gebäude Brunnmattstrasse 50 und dem Nebengebäude Brunnmattstrasse 50a in 3007 Bern.
Auf der Westseite des Hopfgut Gebäudes Brunnmattstrasse 50 in 3007 Bern.
An der Schwarzenburgstrasse 59 am westlichen Rande des Waldes Steinhölzli in 3008 Bern.
Im Spickel Keltenstrasse/Bernstrasse vor dem Haus Bernstrasse 72 in 3018 Bern.
Unter der ehemaligen Tennenauffahrt hinter dem Bienzgut Bernstrasse 77 in 3018 Bern.
Im Garten zwischen Herrenhaus Brünnengut Brünnenstrasse 4 und Pavillon Brünnenstrasse 8 in 3027 Bern.
Unter der ehemaligen Tennenauffahrt zum Bauernhaus Brünnengut Brünnenstrasse 10 in 3027 Bern.
Ungefähr 90 Meter nordöstlich entfernt vom Herrenhaus Brünnengut Brünnenstrasse 4 in 3027 Bern.
An der Waldmannstrasse vor dem Wohngebäude Knospenweg 2 in 3027 Bern.
Auf der Aareseite der Altenbergstrasse gegenüber dem Wohnhaus Altenbergstrasse 46-48 in 3013 Bern.
Beim Klösterlistutz gegenüber dem Gebäude Altenbergstrasse 6 in 3013 Bern.
Auf dem Areal des Bahnhofplatzes Bümpliz Süd gegenüber dem Bahnhofgebäude Bümplizstrasse 202 in 3018 Bern.
Vor dem Statthalterschulhaus Wangenstrasse 9, unter einem offenen mit Pultdach gedeckten Unterstand der Teil des Schulgebäudes Wagenstrasse 11 ist, in 3018 Bern.
Auf dem Platz im Tscharnergut zwischen Gebäude Waldmannstrasse 21 und Gebäude Fellerstrasse 28 in 3027 Bern.
Auf dem Spielplatz Nordring/Dammweg nördlich des Gebäudes Nordring 49 in 3013 Bern.
Auf dem Spielplatz Steckgut östlich des Gebäudes Lorrainestrasse 80 in 3013 Bern.
Auf dem Spielplatz KITA Lorraine Lorrainestrasse 43 in 3013 Bern.
Auf dem Spielplatz Brünnengut östlich gegenüber der Pfrundscheune Brünnengut Brünnenstrasse 12 in 3027 Bern.
Auf dem Innenhof der St. Mauritiuskirche Waldmannstrasse 60 in 3027 Bern.
Auf dem Spielplatz Brünnen Acherli im Park westlich des Gebäudes Waldmannstrasse 68 in 3027 Bern.
Auf dem Hof vor der Kirche Bethlehem Eymattstrasse 2 in 3027 Bern.
Auf der Grünfläche beim Spielplatz Tscharnergut C gegenüber des Schlittelhügels zwischen den Wohngebäuden Waldmannstrasse 53 und 67 in 3027 Bern.
Examples of description:de
Der Marabut-Brunnen wurde 1984 vom Berner Künstler René Ramp (1941-2004) kreiert. Das begehbare Objekt ist ein aus Beton gefertigter offener, riesiger Würfel in den periodisch Wasser durch das runde Deckenloch geleitet wird.
--
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
On Wed, 4 Jul 2018 at 08:57, Sarah Hoffmann lonvia@denofr.de wrote:
OSM is a geospatial database that stores locations in the form of geo-coordinates. The coordinates are also useful to figure out the relative position to surrounding objects (aka: look at the map). If you rather like to have a database that stores location in the form of textual descriptions, so be it. I just don't think OSM is the place to dump all that information.
I agree with you. Perhaps Wikidata would be the better place to store location descriptions as well as those descriptive names. I also still wonder whether the sources from which Andreas got the names of the fountains [^1] are permissible on OSM. As far as I know, this shouldn't be a problem on Wikidata.
[^1]: http://lists.openstreetmap.ch/pipermail/talk-ch/2018-June/009578.html
Cheers
Markus
Hello
Am 06.07.2018 um 15:52 schrieb Selfish Seahorse:
On Wed, 4 Jul 2018 at 08:57, Sarah Hoffmann lonvia@denofr.de wrote:
OSM is a geospatial database that stores locations in the form of geo-coordinates. The coordinates are also useful to figure out the relative position to surrounding objects (aka: look at the map). If you rather like to have a database that stores location in the form of textual descriptions, so be it. I just don't think OSM is the place to dump all that information.
I agree with you. Perhaps Wikidata would be the better place to store location descriptions as well as those descriptive names. I also still wonder whether the sources from which Andreas got the names of the fountains [^1] are permissible on OSM. As far as I know, this shouldn't be a problem on Wikidata.
I was thinking about WikiData as well. For the moment, I don't know how to do that properly.
If you could do a valid example in WikiData of a fountain in Bern *with* a Wikipedia article and one *without* a Wikipedia article, but both examples with commons category, that would be very helpful.
Thanks in advance.
cheeers, h.
Cheers
Markus _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
On Fri, 6 Jul 2018 at 16:16, Andreas Bürki abuerki@anidor.com wrote:
I was thinking about WikiData as well. For the moment, I don't know how to do that properly.
If you could do a valid example in WikiData of a fountain in Bern *with* a Wikipedia article and one *without* a Wikipedia article, but both examples with commons category, that would be very helpful.
Konservatoriumbrunnen (no Wikipedia article): https://www.wikidata.org/wiki/Q55401244 Zähringerbrunnen (with Wikipedia article): https://www.wikidata.org/wiki/Q247322
However, as I had to find out, location descriptions can't be added to Wikidata object at the moment. Unlike OSM, Wikidata properties (~ keys in OSM) can't be added by everyone; they have to go through a proposal process first. [^1]
[^1]: https://www.wikidata.org/wiki/Help:Properties#Creating_properties
Hello
Am 06.07.2018 um 17:55 schrieb Selfish Seahorse:
On Fri, 6 Jul 2018 at 16:16, Andreas Bürki abuerki@anidor.com wrote:
I was thinking about WikiData as well. For the moment, I don't know how to do that properly.
If you could do a valid example in WikiData of a fountain in Bern *with* a Wikipedia article and one *without* a Wikipedia article, but both examples with commons category, that would be very helpful.
Konservatoriumbrunnen (no Wikipedia article): https://www.wikidata.org/wiki/Q55401244 Zähringerbrunnen (with Wikipedia article): https://www.wikidata.org/wiki/Q247322
Thank you.
However, as I had to find out, location descriptions can't be added to Wikidata object at the moment. Unlike OSM, Wikidata properties (~ keys in OSM) can't be added by everyone; they have to go through a proposal process first. [^1]
Indeed. I have learned that as well at a WikiData Workshop (held by Beat).
Unfortunately I'm not familiar enough with WikiData to (a) create such a property "location description" in a meaningful way. And (b), assuming there would be such property in WikiData, I have no idea how to integrate it's content in e.g. uMap.
In the actual situation it's quite easy to integrate the content of *location:description:de=* in uMap[1] in order it gets rendered properly (at the moment 25 fountains gets rendered[2], some 200 still to do... )
...just my 2 cents
cheeers, h.
[1] https://umap.osm.ch/de/map/brunnen-in-stadt-und-gemeinde-bern_124 [2] http://overpass-turbo.eu/s/A9d
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hi,
Could you point me to a dataset with the kind of "location descriptions" you would like to ingest into Wikidata?
Before creating a new property, I would advise you to examine whether the following property could be used:
https://www.wikidata.org/wiki/Property:P2795
directions: describe how to find the subject - directions, objects along way, comments Wegbeschreibung: Beschreibung zum Auffinden eines Objektes – Richtungen, Objekte entlang des Weges, Kommentare
Cheers, Beat
-----Original Message----- From: Andreas Bürki [mailto:abuerki@anidor.com] Sent: Sonntag, 8. Juli 2018 17:53 To: talk-ch@openstreetmap.ch Cc: Estermann Beat beat.estermann@bfh.ch Subject: Re: [talk-ch] Proposed mechanical edit: fountain names/descriptions in Bern (was: Re: addr:suburb in Bern + tagging POI -> Standort) + WikiData
Hello
Am 06.07.2018 um 17:55 schrieb Selfish Seahorse:
On Fri, 6 Jul 2018 at 16:16, Andreas Bürki abuerki@anidor.com wrote:
I was thinking about WikiData as well. For the moment, I don't know how to do that properly.
If you could do a valid example in WikiData of a fountain in Bern *with* a Wikipedia article and one *without* a Wikipedia article, but both examples with commons category, that would be very helpful.
Konservatoriumbrunnen (no Wikipedia article): https://www.wikidata.org/wiki/Q55401244 Zähringerbrunnen (with Wikipedia article): https://www.wikidata.org/wiki/Q247322
Thank you.
However, as I had to find out, location descriptions can't be added to Wikidata object at the moment. Unlike OSM, Wikidata properties (~ keys in OSM) can't be added by everyone; they have to go through a proposal process first. [^1]
Indeed. I have learned that as well at a WikiData Workshop (held by Beat).
Unfortunately I'm not familiar enough with WikiData to (a) create such a property "location description" in a meaningful way. And (b), assuming there would be such property in WikiData, I have no idea how to integrate it's content in e.g. uMap.
In the actual situation it's quite easy to integrate the content of *location:description:de=* in uMap[1] in order it gets rendered properly (at the moment 25 fountains gets rendered[2], some 200 still to do... )
...just my 2 cents
cheeers, h.
[1] https://umap.osm.ch/de/map/brunnen-in-stadt-und-gemeinde-bern_124 [2] http://overpass-turbo.eu/s/A9d
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hello
Am 09.07.2018 um 08:03 schrieb Estermann Beat:
Hi,
Could you point me to a dataset with the kind of "location descriptions" you would like to ingest into Wikidata?
Up to my knowledge, there is so far no official dataset, except the actual 25 ones in OSM. You get it by:
http://overpass-turbo.eu/s/A9d
-> run it by click "Ausführen" and then choose "Daten"
Is this ok or what did you expect, a calc table sheet?
Before creating a new property, I would advise you to examine whether the following property could be used:
Property:P2795 is named directions. Or it's "instance of":
"Wikidata property to indicate a location" ?
https://www.wikidata.org/wiki/Q18615777
cheeers, h.
directions: describe how to find the subject - directions, objects along way, comments Wegbeschreibung: Beschreibung zum Auffinden eines Objektes – Richtungen, Objekte entlang des Weges, Kommentare
Cheers, Beat
-----Original Message----- From: Andreas Bürki [mailto:abuerki@anidor.com] Sent: Sonntag, 8. Juli 2018 17:53 To: talk-ch@openstreetmap.ch Cc: Estermann Beat beat.estermann@bfh.ch Subject: Re: [talk-ch] Proposed mechanical edit: fountain names/descriptions in Bern (was: Re: addr:suburb in Bern + tagging POI -> Standort) + WikiData
Hello
Am 06.07.2018 um 17:55 schrieb Selfish Seahorse:
On Fri, 6 Jul 2018 at 16:16, Andreas Bürki abuerki@anidor.com wrote:
I was thinking about WikiData as well. For the moment, I don't know how to do that properly.
If you could do a valid example in WikiData of a fountain in Bern *with* a Wikipedia article and one *without* a Wikipedia article, but both examples with commons category, that would be very helpful.
Konservatoriumbrunnen (no Wikipedia article): https://www.wikidata.org/wiki/Q55401244 Zähringerbrunnen (with Wikipedia article): https://www.wikidata.org/wiki/Q247322
Thank you.
However, as I had to find out, location descriptions can't be added to Wikidata object at the moment. Unlike OSM, Wikidata properties (~ keys in OSM) can't be added by everyone; they have to go through a proposal process first. [^1]
Indeed. I have learned that as well at a WikiData Workshop (held by Beat).
Unfortunately I'm not familiar enough with WikiData to (a) create such a property "location description" in a meaningful way. And (b), assuming there would be such property in WikiData, I have no idea how to integrate it's content in e.g. uMap.
In the actual situation it's quite easy to integrate the content of *location:description:de=* in uMap[1] in order it gets rendered properly (at the moment 25 fountains gets rendered[2], some 200 still to do... )
...just my 2 cents
cheeers, h.
[1] https://umap.osm.ch/de/map/brunnen-in-stadt-und-gemeinde-bern_124 [2] http://overpass-turbo.eu/s/A9d
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Dear Andreas,
I've started to set up an example item: https://www.wikidata.org/wiki/Q55411751
- P2795 for directions - P137 for operator
What we are missing right now in Wikidata is a property to refer to the OSM node ID. I have therefore submitted a property proposal: https://www.wikidata.org/wiki/Wikidata:Property_proposal/Authority_control#O... Feel free to add more examples and endorse the proposal. Creation of the property should take about 2 weeks.
And feel free to submit a property proposal for OSM ways if you see a need for it.
In view of the data ingest: - Yes, extract the data in spreadsheet format - Then, map all relevant data fields to Wikidata properties - Reconcile the items in the spreadsheet against Wikidata to avoid duplicates (possibly, this has already been done, as some the OSM nodes already contain Wikidata Q-numbers) - Ingest the data using QuickStatements
What I don't like in the OSM data is the fact that the source ("survey") does not have proper references (which survey? publication date?). And there is potentially a HUGE PROBLEM when it comes to larger data ingests due to license incompatibilities between OSM and Wikidata: https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=5... See also: https://www.wikidata.org/wiki/Wikidata:OpenStreetMap The data to be imported is not copyrighted under Swiss law. However, OpenStreetMap seems to be operated from London, which means that EU database law probably is applicable in addition to Swiss law. You would need a IP lawyer to sort this out.
If you are planning to do larger data ingests from OSM (after sorting out the legal issues), we should create a WikiProject where we can document the ingest process (which sources have been ingested? Mapping information, etc.). As I told you at the Wikidata workshop in Bern, there is another project focusing on Wikidata and fountains: https://water-fountains.org/ - I guess you guys should coordinate between each other.
In the longer run, we should address the question which data should primarily be maintained in Wikidata and which data should be maintained within OSM. In principle, for each data field, one could act as the master database and the other as the slave. Decision criteria could be: power of the data model, ease of use of interfaces, presence of a dedicated community, etc. However, given the current licensing situation, compatibility works only in one way – data from Wikidata can be imported into OSM, but not the other way round. This means that if you want your data to remain in the public domain and to be used also within Wikidata, you should maintain it in Wikidata and import it into OSM in a further step.
Cheers, Beat
-----Original Message----- From: Andreas Bürki [mailto:abuerki@anidor.com] Sent: Montag, 9. Juli 2018 22:44 To: Estermann Beat beat.estermann@bfh.ch; talk-ch@openstreetmap.ch Subject: Re: [talk-ch] Proposed mechanical edit: fountain names/descriptions in Bern (was: Re: addr:suburb in Bern + tagging POI -> Standort) + WikiData
Hello
Am 09.07.2018 um 08:03 schrieb Estermann Beat:
Hi,
Could you point me to a dataset with the kind of "location descriptions" you would like to ingest into Wikidata?
Up to my knowledge, there is so far no official dataset, except the actual 25 ones in OSM. You get it by:
http://overpass-turbo.eu/s/A9d
-> run it by click "Ausführen" and then choose "Daten"
Is this ok or what did you expect, a calc table sheet?
Before creating a new property, I would advise you to examine whether the following property could be used:
Property:P2795 is named directions. Or it's "instance of":
"Wikidata property to indicate a location" ?
https://www.wikidata.org/wiki/Q18615777
cheeers, h.
directions: describe how to find the subject - directions, objects along way, comments Wegbeschreibung: Beschreibung zum Auffinden eines Objektes – Richtungen, Objekte entlang des Weges, Kommentare
Cheers, Beat
-----Original Message----- From: Andreas Bürki [mailto:abuerki@anidor.com] Sent: Sonntag, 8. Juli 2018 17:53 To: talk-ch@openstreetmap.ch Cc: Estermann Beat beat.estermann@bfh.ch Subject: Re: [talk-ch] Proposed mechanical edit: fountain names/descriptions in Bern (was: Re: addr:suburb in Bern + tagging POI -> Standort) + WikiData
Hello
Am 06.07.2018 um 17:55 schrieb Selfish Seahorse:
On Fri, 6 Jul 2018 at 16:16, Andreas Bürki abuerki@anidor.com wrote:
I was thinking about WikiData as well. For the moment, I don't know how to do that properly.
If you could do a valid example in WikiData of a fountain in Bern *with* a Wikipedia article and one *without* a Wikipedia article, but both examples with commons category, that would be very helpful.
Konservatoriumbrunnen (no Wikipedia article): https://www.wikidata.org/wiki/Q55401244 Zähringerbrunnen (with Wikipedia article): https://www.wikidata.org/wiki/Q247322
Thank you.
However, as I had to find out, location descriptions can't be added to Wikidata object at the moment. Unlike OSM, Wikidata properties (~ keys in OSM) can't be added by everyone; they have to go through a proposal process first. [^1]
Indeed. I have learned that as well at a WikiData Workshop (held by Beat).
Unfortunately I'm not familiar enough with WikiData to (a) create such a property "location description" in a meaningful way. And (b), assuming there would be such property in WikiData, I have no idea how to integrate it's content in e.g. uMap.
In the actual situation it's quite easy to integrate the content of *location:description:de=* in uMap[1] in order it gets rendered properly (at the moment 25 fountains gets rendered[2], some 200 still to do... )
...just my 2 cents
cheeers, h.
[1] https://umap.osm.ch/de/map/brunnen-in-stadt-und-gemeinde-bern_124 [2] http://overpass-turbo.eu/s/A9d
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hi Beat
Thank you for your post. I have no experience with wikidata, so I am happy that more knowledgable people give their comments :) however I still have a comment regarding OSM iD:
On 10/07/18 10:13, Estermann Beat wrote:
What we are missing right now in Wikidata is a property to refer to the OSM node ID. I have therefore submitted a property proposal: https://www.wikidata.org/wiki/Wikidata:Property_proposal/Authority_control#O... Feel free to add more examples and endorse the proposal. Creation of the property should take about 2 weeks.
I am pretty sure that has been discussed, and the Problem is that OSM does not provide stable IDs. So the way to link wikidata with OSM is either with the wikidata tag in OSM, or via coordinates (OSM fountain the closest to the coordinate in wikidata).
Also for the license issue, you can only use the data for both OSM and wikidata if you know the underlying source and the source is compatible with both.
By the way, survey in OSM context means the mapper was there, in person, and mapped the fountain. Read the name plate, or whatever other information was gathered on site. Publications as sources are rare for OSM again because of licensing problems.
Best Michael
Hi Beat
On 10.07.2018 10:13, Estermann Beat wrote:
What we are missing right now in Wikidata is a property to refer to the OSM node ID. I have therefore submitted a property proposal: https://www.wikidata.org/wiki/Wikidata:Property_proposal/Authority_control#O... Feel free to add more examples and endorse the proposal. Creation of the property should take about 2 weeks.
I doubt that it's a good idea to create a property for OSM IDs on Wikidata, as OSM IDs aren't "stable". Editors may (and sometimes do) assign new IDs even though the real-world object may still be the same, and previously used IDs might be re-assigned if not currently in use. (See e.g. the vivid history of Node Nr. 1: https://www.openstreetmap.org/node/1)
Instead, OpenStreetMap entities (nodes, ways or relations) with a corresponding Wikidata object should refer to the Q-number (which AFAIK /is/ stable). Determining the corresponding OpenStreetMap object(s) for a Wikidata entry would then require something like an Overpass query, but I can't think of any alternative way to make this linking sound and future-proof.
And feel free to submit a property proposal for OSM ways if you see a need for it.
Dito.
What I don't like in the OSM data is the fact that the source ("survey") does not have proper references (which survey? publication date?).
This is probably a misunderstanding. The source declaration "survey" in OpenStreetMap is understood to mean that the editor observed the represented facts themselves on-the-ground, not that the data stems from some published survey document or dataset. If the information stems from an pre-existing dataset, that specific dataset should be mentioned in the "source" changeset tag.
See the value's explanation at https://wiki.openstreetmap.org/wiki/Key:source#General_sources_commonly_used... :
The OSM user was there and saw it himself/herself. The OSM user may or may not have done any precision measurement of the location etc. using a device such as a GPS receiver or a theodolite.
Note that use of the "source" tag https://wiki.openstreetmap.org/wiki/Key:source on OpenStreetMap entities (nodes, ways or relations) is considered historic and (according to the Wiki not officially, but de-facto) deprecated https://wiki.openstreetmap.org/wiki/Key:source#Historic_usage_on_objects_and_attributes. The tag should be used on changesets instead. Occurrences on nodes, ways or relations should not be taken at face value (they are likely to be outdated or incomplete if the object has been edited since) and should probably be ignored by OSM data consumers and/or augmented with the source information of the complete history of the object.
Regards, Raphael
Thanks Raphael for bringing this up. I want to backup your doubts.
Dear Beat
Although many (third party) apps are using OSM ID's, it is strongly recommended to abstain using such an "ID", especially in projects like Wikidata. Even the OSM relation ID should never have passed it's proposal to become a Wikidata property.
Use coordinate property in the first place. This is also what this extension https://www.mediawiki.org/wiki/Help:Extension:Kartographer does.
Discussion about OSM IDs are repeatedly coming up in OSM mailing lists, and let to the "Permanent ID" proposal which is still in experimental stage. The idea is to use properties of an object to identify it: see https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID .
I hope you understand these reasonings and withdraw your Wikidata property proposal: https://www.wikidata.org/wiki/Wikidata:Property_proposal/Authority_control#O...
:Stefan
2018-07-10 19:05 GMT+02:00 Raphael Das Gupta lists.openstreetmap.ch@raphael.dasgupta.ch:
Hi Beat
On 10.07.2018 10:13, Estermann Beat wrote:
What we are missing right now in Wikidata is a property to refer to the OSM node ID. I have therefore submitted a property proposal: https://www.wikidata.org/wiki/Wikidata:Property_proposal/Authority_control#O... Feel free to add more examples and endorse the proposal. Creation of the property should take about 2 weeks.
I doubt that it's a good idea to create a property for OSM IDs on Wikidata, as OSM IDs aren't "stable". Editors may (and sometimes do) assign new IDs even though the real-world object may still be the same, and previously used IDs might be re-assigned if not currently in use. (See e.g. the vivid history of Node Nr. 1: https://www.openstreetmap.org/node/1)
Instead, OpenStreetMap entities (nodes, ways or relations) with a corresponding Wikidata object should refer to the Q-number (which AFAIK is stable). Determining the corresponding OpenStreetMap object(s) for a Wikidata entry would then require something like an Overpass query, but I can't think of any alternative way to make this linking sound and future-proof.
And feel free to submit a property proposal for OSM ways if you see a need for it.
Dito.
What I don't like in the OSM data is the fact that the source ("survey") does not have proper references (which survey? publication date?).
This is probably a misunderstanding. The source declaration "survey" in OpenStreetMap is understood to mean that the editor observed the represented facts themselves on-the-ground, not that the data stems from some published survey document or dataset. If the information stems from an pre-existing dataset, that specific dataset should be mentioned in the "source" changeset tag.
See the value's explanation at https://wiki.openstreetmap.org/wiki/Key:source#General_sources_commonly_used... :
The OSM user was there and saw it himself/herself. The OSM user may or may not have done any precision measurement of the location etc. using a device such as a GPS receiver or a theodolite.
Note that use of the "source" tag on OpenStreetMap entities (nodes, ways or relations) is considered historic and (according to the Wiki not officially, but de-facto) deprecated. The tag should be used on changesets instead. Occurrences on nodes, ways or relations should not be taken at face value (they are likely to be outdated or incomplete if the object has been edited since) and should probably be ignored by OSM data consumers and/or augmented with the source information of the complete history of the object.
Regards, Raphael
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Dear Stefan, Raphael,
Thank you for your clarifications!
I've added a comment to the property proposal:
https://www.wikidata.org/wiki/Wikidata:Property_proposal/OSM_node_ID
I'm not withdrawing it for now, as I think it is important to have this discussion.
I'm not familiar with OSM, but at first sight, it does not seem reasonable to renounce to having "permanent" IDs on the OSM side.
With "permanent" I mean that they must not be reassigned to a completely different entity after being deprecated. – This principle should not be very hard to implement on the OSM side, but again, I'm totally unaware of past discussions in this regard within the OSM community.
Regarding the proposal of using Wikidata Q numbers as identifiers for matching between OSM and Wikidata:
* Wikidata Q numbers are not absolutely "permanent": the scope of items may change (e.g. Qx "building and organization" is disentangled into Qx "building" and Qy "organization" - or vice versa). * Wikidata items may be merged (in this case, the deprecated Q-number gets a re-direct to the valid Q-number). * In some rare cases, Wikidata items may get deleted altogether (but the Q-numbers won’t get re-used for another item). * I don’t think that under these conditions, we should just rely on Wikidata Q-numbers for the matching of items. – When disentangling or merging items on Wikidata, we should be able to explicitly deal with the related OSM IDs inside Wikidata.
Regarding the proposal of constructing some make-shift OSM IDs from tags and coordinates:
* If you create unique identifiers for the entries in OSM, they should be exportable to external databases. In my understanding, this is presently not the case due to licensing restrictions. * And again, we should have a way of explicitly addressing OSM entries from within Wikidata.
See also: https://www.wikidata.org/wiki/Wikidata:OpenStreetMap
Maybe we should have this discussion over there.
Cheers,
Beat
-----Original Message----- From: Stefan Keller [mailto:sfkeller@gmail.com] Sent: Mittwoch, 11. Juli 2018 01:54 To: Openstreetmap Schweiz/Suisse/Svizzera/Svizra talk-ch@openstreetmap.ch Subject: Re: [talk-ch] OSM + Wikidata: No stable OSM IDs, meaning of source=survey in OSM
Thanks Raphael for bringing this up. I want to backup your doubts.
Dear Beat
Although many (third party) apps are using OSM ID's, it is strongly recommended to abstain using such an "ID", especially in projects like Wikidata. Even the OSM relation ID should never have passed it's proposal to become a Wikidata property.
Use coordinate property in the first place. This is also what this extension https://www.mediawiki.org/wiki/Help:Extension:Kartographer
does.
Discussion about OSM IDs are repeatedly coming up in OSM mailing lists, and let to the "Permanent ID" proposal which is still in experimental stage. The idea is to use properties of an object to identify it: see https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID .
I hope you understand these reasonings and withdraw your Wikidata property proposal:
https://www.wikidata.org/wiki/Wikidata:Property_proposal/Authority_control#O...
:Stefan
2018-07-10 19:05 GMT+02:00 Raphael Das Gupta
<lists.openstreetmap.ch@raphael.dasgupta.chmailto:lists.openstreetmap.ch@raphael.dasgupta.ch>:
Hi Beat
On 10.07.2018 10:13, Estermann Beat wrote:
What we are missing right now in Wikidata is a property to refer to
the OSM node ID. I have therefore submitted a property proposal:
https://www.wikidata.org/wiki/Wikidata:Property_proposal/Authority_con
trol#OSM_node_ID Feel free to add more examples and endorse the
proposal. Creation of the property should take about 2 weeks.
I doubt that it's a good idea to create a property for OSM IDs on
Wikidata, as OSM IDs aren't "stable". Editors may (and sometimes do)
assign new IDs even though the real-world object may still be the
same, and previously used IDs might be re-assigned if not currently in
use. (See e.g. the vivid history of Node Nr. 1:
Instead, OpenStreetMap entities (nodes, ways or relations) with a
corresponding Wikidata object should refer to the Q-number (which
AFAIK is stable). Determining the corresponding OpenStreetMap
object(s) for a Wikidata entry would then require something like an
Overpass query, but I can't think of any alternative way to make this
linking sound and future-proof.
And feel free to submit a property proposal for OSM ways if you see a
need for it.
Dito.
What I don't like in the OSM data is the fact that the source
("survey") does not have proper references (which survey? publication date?).
This is probably a misunderstanding. The source declaration "survey"
in OpenStreetMap is understood to mean that the editor observed the
represented facts themselves on-the-ground, not that the data stems
from some published survey document or dataset. If the information
stems from an pre-existing dataset, that specific dataset should be
mentioned in the "source" changeset tag.
See the value's explanation at
https://wiki.openstreetmap.org/wiki/Key:source#General_sources_commonl
y_used_by_human_mappers
:
The OSM user was there and saw it himself/herself. The OSM user may or
may not have done any precision measurement of the location etc. using
a device such as a GPS receiver or a theodolite.
Note that use of the "source" tag on OpenStreetMap entities (nodes,
ways or
relations) is considered historic and (according to the Wiki not
officially, but de-facto) deprecated. The tag should be used on changesets instead.
Occurrences on nodes, ways or relations should not be taken at face
value (they are likely to be outdated or incomplete if the object has
been edited
since) and should probably be ignored by OSM data consumers and/or
augmented with the source information of the complete history of the object.
Regards,
Raphael
talk-ch mailing list
talk-ch@openstreetmap.chmailto:talk-ch@openstreetmap.ch
I've made the proposed mechanical edit: https://www.openstreetmap.org/changeset/60894196
Regards, Markus
Salut
Am 20.07.2018 um 09:46 schrieb SelfishSeahorse:
I've made the proposed mechanical edit: https://www.openstreetmap.org/changeset/60894196
So far - except some uMap trouble, but this is not your fault - it looks OK to me. Thank you for your work.
cheeers, h.
Regards, Markus _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
On Fri, 20 Jul 2018 at 12:27, Andreas Bürki abuerki@anidor.com wrote:
So far - except some uMap trouble, but this is not your fault - it looks OK to me. Thank you for your work.
You're welcome.
Unfortunately, my Overpass query only found fountain nodes, but after defining an area set (http://overpass-turbo.eu/s/ArJ), it seems that it now has also found fountain ways and relations. Here's the link to the 2nd changeset:
https://www.openstreetmap.org/changeset/60914486
Regards, Markus
Hello
Am 20.07.2018 um 19:49 schrieb SelfishSeahorse:
[...]
Unfortunately, my Overpass query only found fountain nodes, but after defining an area set (http://overpass-turbo.eu/s/ArJ), it seems that it now has also found fountain ways and relations. Here's the link to the 2nd changeset:
Locks to me like you confused
name:description:de with description:name:de
Can you please fix that?
Correct tag is:
name:description:de
Thank you for your work.
cheeers, h.
Regards, Markus
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Oh, I'm sorry! :-( I've fixed it: https://www.openstreetmap.org/changeset/60961446
Please excuse the mistake.
BTW: JOSM complains about 'multipolygon outer way shares segment(s) with other ring' and 'role verification problem' errors. Could you please have a look at that? Or send me a message, if I can help you.
Regards, Markus On Sun, 22 Jul 2018 at 21:27, Andreas Bürki abuerki@anidor.com wrote:
Hello
Am 20.07.2018 um 19:49 schrieb SelfishSeahorse:
[...]
Unfortunately, my Overpass query only found fountain nodes, but after defining an area set (http://overpass-turbo.eu/s/ArJ), it seems that it now has also found fountain ways and relations. Here's the link to the 2nd changeset:
Locks to me like you confused
name:description:de with description:name:de
Can you please fix that?
Correct tag is:
name:description:de
Thank you for your work.
cheeers, h.
Regards, 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
Hello,
sorry for my very late opinion
Markus thanks it's a good thing you made these fixes
but for me it doesn't go far enough. Andreas as lonvia says (if I'm not mistaken), there's a conceptual error in what you put in the osm database and I get the impression that every attempt to solve this problem results in a new version of the same problem. in fact what is the meaning of having localisation:description if this description is not one and is limited to a "nominatim literal version"? for me a description of the location would be "this fountain is in a lovely park with a beautiful view of the lake". "go to 23 and turn right" is not a description, it's a routing info. "this fountain is close to number 23" isn't a description either.
let's push this problem to the absurd. amenity=fountain amenity:description="it's a fountain" note=Ausser Betrieb note:description="the note explain that the fountain doesn't work" source=Survey source:description="a survey was made and the mapper doesn't put this key on the changeset but put it on the objet" lat:description=The lat is 123" long:description=The long is 456" neighbourhood:description=The fountain is in a park nearest_bus_stop:descrition=The nearest mapped bus stop is 18.5m fair away nearest_cafe:descrition=The nearest mapped cafe is 72m fair away
none of this makes any sense ! if a umap needs to display the nearest address or any other information already in the osm database, it is counterproductive to duplicate every tag on any objects where this information is needed. duplicate it with addr:* nor duplicate it with description solve the main issue.
PS1: the bassin of a fountain isn't a barrier=retaining_wall if you want to micro-map it, it's maybe better to tag it as landuse=reservoir + content=water like the one I have fixed https://www.openstreetmap.org/relation/8322503 PS2: putting the same tag on a MP relation and on the outer way is often wrong PS3: tag:de is only need if tag already exist. having a langage variant without any variant is imho not needed. so location:description is enought if no other location:description:xxx exist
Regards, Marc
Le 22. 07. 18 à 22:38, SelfishSeahorse a écrit :
Oh, I'm sorry! :-( I've fixed it: https://www.openstreetmap.org/changeset/60961446
Please excuse the mistake.
BTW: JOSM complains about 'multipolygon outer way shares segment(s) with other ring' and 'role verification problem' errors. Could you please have a look at that? Or send me a message, if I can help you.
Regards, Markus On Sun, 22 Jul 2018 at 21:27, Andreas Bürki abuerki@anidor.com wrote:
Hello
Am 20.07.2018 um 19:49 schrieb SelfishSeahorse:
[...]
Unfortunately, my Overpass query only found fountain nodes, but after defining an area set (http://overpass-turbo.eu/s/ArJ), it seems that it now has also found fountain ways and relations. Here's the link to the 2nd changeset:
Locks to me like you confused
name:description:de with description:name:de
Can you please fix that?
Correct tag is:
name:description:de
Thank you for your work.
cheeers, h.
Regards, 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
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Salut Marc
Am 22.07.2018 um 23:18 schrieb marc marc:
Hello,
sorry for my very late opinion
Markus thanks it's a good thing you made these fixes
but for me it doesn't go far enough. Andreas as lonvia says (if I'm not mistaken), there's a conceptual error in what you put in the osm database and I get the impression that every attempt to solve this problem results in a new version of the same problem.
To make a long story short; What is your precise proposal, Marc?
Could you please make some detailed examples with all keys of your idea, in order that I or others can apply your concept to the ~ 240 fountains?
Thank you in advance for your constructive efforts. :-)
cheeers, h.
in fact what is the meaning of having localisation:description if this description is not one and is limited to a "nominatim literal version"? for me a description of the location would be "this fountain is in a lovely park with a beautiful view of the lake". "go to 23 and turn right" is not a description, it's a routing info. "this fountain is close to number 23" isn't a description either.
let's push this problem to the absurd. amenity=fountain amenity:description="it's a fountain" note=Ausser Betrieb note:description="the note explain that the fountain doesn't work" source=Survey source:description="a survey was made and the mapper doesn't put this key on the changeset but put it on the objet" lat:description=The lat is 123" long:description=The long is 456" neighbourhood:description=The fountain is in a park nearest_bus_stop:descrition=The nearest mapped bus stop is 18.5m fair away nearest_cafe:descrition=The nearest mapped cafe is 72m fair away
none of this makes any sense ! if a umap needs to display the nearest address or any other information already in the osm database, it is counterproductive to duplicate every tag on any objects where this information is needed. duplicate it with addr:* nor duplicate it with description solve the main issue.
PS1: the bassin of a fountain isn't a barrier=retaining_wall if you want to micro-map it, it's maybe better to tag it as landuse=reservoir + content=water like the one I have fixed https://www.openstreetmap.org/relation/8322503 PS2: putting the same tag on a MP relation and on the outer way is often wrong PS3: tag:de is only need if tag already exist. having a langage variant without any variant is imho not needed. so location:description is enought if no other location:description:xxx exist
Regards, Marc
Le 22. 07. 18 à 22:38, SelfishSeahorse a écrit :
Oh, I'm sorry! :-( I've fixed it: https://www.openstreetmap.org/changeset/60961446
Please excuse the mistake.
BTW: JOSM complains about 'multipolygon outer way shares segment(s) with other ring' and 'role verification problem' errors. Could you please have a look at that? Or send me a message, if I can help you.
Regards, Markus On Sun, 22 Jul 2018 at 21:27, Andreas Bürki abuerki@anidor.com wrote:
Hello
Am 20.07.2018 um 19:49 schrieb SelfishSeahorse:
[...]
Unfortunately, my Overpass query only found fountain nodes, but after defining an area set (http://overpass-turbo.eu/s/ArJ), it seems that it now has also found fountain ways and relations. Here's the link to the 2nd changeset:
Locks to me like you confused
name:description:de with description:name:de
Can you please fix that?
Correct tag is:
name:description:de
Thank you for your work.
cheeers, h.
Regards, 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
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Le 22. 07. 18 à 23:59, Andreas Bürki a écrit :
Am 22.07.2018 um 23:18 schrieb marc marc:
Andreas as lonvia says (if I'm not mistaken), there's a conceptual error in what you put in the osm database and I get the impression that every attempt to solve this problem results in a new version of the same problem.
To make a long story short; What is your precise proposal, Marc? Could you please make some detailed examples with all keys of your idea,
my "proposal" is the version #2 of https://www.openstreetmap.org/relation/8322503 the diff with version #3 : - source tag on the changeset - location:description can be avoid with a Nominatim query
Regards, Marc
Hi Marc, hi everyone
On Sun, 22 Jul 2018 at 23:18, marc marc marc_marc_irc@hotmail.com wrote:
but for me it doesn't go far enough. Andreas as lonvia says (if I'm not mistaken), there's a conceptual error in what you put in the osm database and I get the impression that every attempt to solve this problem results in a new version of the same problem.
[...]
duplicate it with addr:* nor duplicate it with description solve the main issue.
Same opinion. This is why I proposed Wikidata. Unfortunately, uMap doesn't seem to work with data from Wikidata ... However, it would be better to not fix that with tagging in OSM.
PS1: the bassin of a fountain isn't a barrier=retaining_wall if you want to micro-map it, it's maybe better to tag it as landuse=reservoir + content=water like the one I have fixed https://www.openstreetmap.org/relation/8322503
If I understand the wiki right, landuse=reservoir is mainly used for artificial lakes. To me, it seems landuse=basin, which Andreas uses, is correct. Regarding the basin border, barrier=retaining_wall really fells a bit odd, especially in winter, when the basin is empty. Maybe barrier=wall would be better?
By the way, does anyone have a better idea how to tag this water pump on a playground (see picture in image tag): https://www.openstreetmap.org/node/5732793622? In my opinion, it isn't a fountain, which is why I removed amenity=fountain and invented playground=water_pump.
Regards, Markus
Hello Markus
Thank you for the fix.
Am 22.07.2018 um 22:38 schrieb SelfishSeahorse:
Oh, I'm sorry! :-( I've fixed it: https://www.openstreetmap.org/changeset/60961446
Please excuse the mistake.
No prob.
BTW: JOSM complains about 'multipolygon outer way shares segment(s) with other ring' and 'role verification problem' errors. Could you please have a look at that? Or send me a message, if I can help you.
Yes, please, go ahead and let's see how the rendered map will look.
cheeers, h.
Regards, Markus On Sun, 22 Jul 2018 at 21:27, Andreas Bürki abuerki@anidor.com wrote:
Hello
Am 20.07.2018 um 19:49 schrieb SelfishSeahorse:
[...]
Unfortunately, my Overpass query only found fountain nodes, but after defining an area set (http://overpass-turbo.eu/s/ArJ), it seems that it now has also found fountain ways and relations. Here's the link to the 2nd changeset:
Locks to me like you confused
name:description:de with description:name:de
Can you please fix that?
Correct tag is:
name:description:de
Thank you for your work.
cheeers, h.
Regards, 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
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
-
Andreas Bürki -
Estermann Beat -
marc marc -
michael spreng -
Raphael Das Gupta -
Sarah Hoffmann -
Selfish Seahorse -
SelfishSeahorse
-
Simon Poole -
Stefan Keller -
Titus Thornber