[talk-ch] addr:suburb in Bern + tagging POI -> Standort

Andreas Bürki abuerki at anidor.com
Mon Jun 4 23:10:54 CEST 2018


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=&SearchableText=Brunnen
    -
https://www.archives-quickaccess.ch/search/25/results?generalterm=Brunnen
    -
http://www.bern.ch/themen/stadt-recht-und-politik/finanzen/rechnung-jahresbericht
(-> 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 at 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)
>>>
>>> This one https://www.openstreetmap.org/node/5543349328 ?
>>
>> 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_Brunnentour
>>
>>
>> Code for the pop-up window on the left:
>> # **{name}**
>> [[{image}|{{{image}}}]]
>> *Bildquelle und weitere Fotos:
>> [[https://commons.wikimedia.org/wiki/{wikimedia_commons}|commons.wikimedia.org]]*
>>
>> Standort:
>> {addr:street}, {addr:postcode} {addr:city}
>>
>> Beschreibung:
>> {description:de}
>>
>> Wikipedia:
>> [[https://de.wikipedia.org/wiki/{wikipedia}|{wikipedia}]]
>>
>> Wikidata:
>> [[http://www.wikidata.org/wiki/{wikidata}|{wikidata}]]
>>
>>
>> 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/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 at 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.94274/7.42219
>>>>>>>>>
>>>>>>>>> 2018-05-03 18:18 GMT+02:00 marc marc <marc_marc_irc at 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 at 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 at openstreetmap.ch
>>> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
>>>
>>
>> --
>>
>> Andreas Bürki
>>
>> abuerki at 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 at openstreetmap.ch
>> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
>>
> _______________________________________________
> talk-ch mailing list
> talk-ch at openstreetmap.ch
> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
> 

-- 

Andreas Bürki

abuerki at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.ch/pipermail/talk-ch/attachments/20180604/b1f38e15/attachment.sig>


More information about the talk-ch mailing list