Daran liegt es nicht, ich hab auch schon mit dem Entwickler darüberdiskutiert: die kurze Version ist: es ist besser wenn die Hausnummern am richtigen Ort, sprich Eingang oder Hausteil sind. Was natürlich auch niemand bestreitet, nut ist es deswegen nicht “falsch”.
Ich halte mich auch dafür an den Grundsatz „One feature, one OSM element“. Das sind zwei Adressen, also zwei OSM-Objekte, in dem Fall zwei Adress-nodes. Damit braucht sich weder ein Geocoder noch sonst jemand, der den Ort zu einer Adresse sucht, damit herumschlagen, die beiden Adressen aus einem Ojekt zu extrahieren.
Es gibt auf Fabrikgeländen oder in Häuserblocks, die aus Zusammenlegung mehrerer Grundstücke entstanden sind, aber sehr wohl “Adressen” die diese Entstehung widerspiegeln, also z.B. 37-41, die für einen Eingang, eine Rezeption oder für ein Treppenhaus stehen. Das ist also ein OSM-Objekt mit halt etwas “komischer” Hausnummer. Das künstlich zu zerlegen, widerspricht mMn der Grundidee “one element, one OSM-object”. Eigentlich ist das (Falsch-)Taggen für den Geocoder.
Dann ist das auch genau ein Adressobjekt. Aber dann ist die Hausnummernangabe eine Einheit, quasi eine “nicht-numerische Hausnummer”, und es gibt keine eigenen Adressen mit den einzelnen Hausnummern mehr, insbesondere keine mit der Hausnummer 38, 39 und 40.
Im Thread geht es aber offensichtlich um eine Zusammenfassung eigenständiger Adressen mit unterschiedlichen Hausnummern in einem Objekt. Warum sollte man sonst über die richtigen Listentrennzeichen diskutieren?
Natürlich wieder das übliche Totschlagargument “… Taggen für”. Wofür erfassen wir denn Adressen? Um zu einer gegebenen Adresse die geographisch Lage herauszufinden? Was ist dann daran falsch, für jede einzelne Hausnummer genau einewn Adressknoten anzulegen und damit dem Geocoder die Auswertung zu erleichtern?
Weil, in den Fällen von wir hier Reden wir typischerweise gar keine (auch nicht ungefähre) Informationen haben wo denn die Adressen sind, sprich mappt man die als einzelne Knoten täuscht man einen Informationsgehalt den die Objekte gar nicht haben vor. Manchmal kann man das nicht umgehen, aber in diesen Fall schon.
Dass Geocoder halt nicht die einzigen Nutzer von Adressen sind. Hausnummern werden z.B. eben auch gerendert, und das Kartenbild wird nicht richtiger, wenn man in ein Gebäude mehrere Adressnodes setzt, obwohl die alle für das ganze Gebäude stehen. Auch für andere Auswertungen kann dadurch der Zusammenhang zwischen dem einen Gebäude und den mehreren Adressen verloren gehen oder erschwert werden. Insofern: Ja, wir erfassen Adressen für Geocoder, aber wir erfassen Adressen nicht nur für Geocoder sondern für jede Anwendung, die Adressen brauchen kann. Und deshalb gilt eben, und das ist ja die Aussage hinter “Wir taggen nicht für XY”, dass wir die Realität so gut wie möglich abbilden und nicht so, dass es für eine bestimmte Anwendung besonders leicht auszuwerten wäre. Natürlich kann man diskutieren, ob es nicht die Realität am Besten abbildet, wenn man zwei getrennte Adressknoten in ein Gebäude setzt. Aber zumindest sollte man sich der Tatsache nicht verschließen, dass es eben auch gute Argumente dafür gibt, dass zumindest in manchen Fällen die Realität besser durch ein Gebäude mit zusammengefassten Adresstags abgebildet wird.
Gut, das habe ich nicht bedacht, wenn ich 37-41 lese, gehe ich erst mal von eine lückenlosen Reihe natürlicher ganzer Zahlen aus.
Aber eine gesicherte Aussage ist für keine der Zahlen dazwischen möglich. Die Regel, dass gerade Hausnummern auf der gegenüberliegenden Straßenseite mit den ungeraden Hausnummern liegen, ist kein Naturgesetz. Also dürfen genau genommen nur die Hausnummern 37 und 41 nicht ails eigenständige Adresse existieren.
Im Prinzip d’accord, aber der Textstring “37-41” meint üblicherweise die “Adressen” einer Seite, also hier 37,39,41, ich erwarte aber von einem Auswerter nicht, dass er das aufdröseln muss.
Dann aber lieber einzelne nodes im Umriss, die man ggf. später an die richtige Position (typisch: Eingang) verschieben kann.
Ich bin auch dafür, es dem Auswerter nicht unnötig schwer zu machen, aber nicht um den Preis, dass aus einem realen Objekt mehrere virtuelle gemacht werden. Da sehe ich den Auswerter in der Pflicht, mit “,” “;” u.ä. tolerant umzugehen.
Ansonsten: Vollkommenheit ist eine Zier, bequemer lebt’s sich ohne ihr (frei nach Busch)
Soweit ich das kenne, sind diese von-bis Nummern dadurch entstanden, dass hier früher mal einzelne Häuser mit den Hausnummern standen, aber die jetzt weg sind. Die Grundstücke wurden zusammengelegt und es wurde EIN Haus drauf gebaut. Da müssen also nicht mehrere Eingänge mit “richtiger” Hausnummer vorhanden sein.
Da wurden postalische Adressen zusammengelegt und ich sehe keinen Sinn darin, diese für OSM wieder auseinanderzupfriemeln.