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