Hausnummern, associatedStreet, und einiges mehr

hurdygurdyman · 2013-12-05 11:13:04

Bin hier http://osm.org/go/0DLGZrJmV-
auf eine Art der Hauserfassung gestoßen, die aus meiner Sicht etwas überzogen ist.
- Hausumrisse sind relativ gut und vollständig erfasst
- In den Umrissen liegt ein Node mit den Adressdaten des Hauses
- Die Adress-Nodes sind mit Straßen(-teilen) zu Relationen als associatedStreet verbunden

Ist das nicht etwas zuviel des Guten?
(Die umliegenden Ortschaften sind teilweise ähnlich)

GeorgFausB · 2013-12-05 12:02:40

Moin,

hurdygurdyman wrote:

Ist das nicht etwas zuviel des Guten?

mir wäre das zuviel Aufwand - aber wir Beide müssen es ja auch nicht genauso eintragen ...

Gruß
Georg

chris66 · 2013-12-05 12:45:37

Lustig ist das Nachbardorf. Spielfeldlinien und Swimmingpools sind erfasst, aber Hausnummern?
Fehlanzeige.
http://www.openstreetmap.org/#map=18/48.25638/7.82452
Malen nach Zahlen.

Pepito · 2013-12-05 12:50:17

Ich weiß nur, dass die Navigationssoftware Navit das auflöst für die Adresssuche.

Der Multipolygon-Wahnsinn ist ja nur ein Teil des viel umfassenderen Relation-Wahnsinns!

Netzwolf · 2013-12-05 15:03:56

Nahmd,

chris66 wrote:

Lustig ist das Nachbardorf. Spielfeldlinien und Swimmingpools sind erfasst, aber Hausnummern?
Fehlanzeige.

Möglicherweise chronifizierte Frischluftphobie?

Gruß Wolf

Nadjita · 2013-12-05 15:09:10

Oder akute Couchmapperitis?

Netzwolf · 2013-12-05 15:29:53

Nahmd,

Pepito wrote:

Der Multipolygon-Wahnsinn ist ja nur ein Teil des viel umfassenderen Relation-Wahnsinns!

Ich betrachte <relation type="multipolygon"> als Ersatz für <area>.

Unsere kommerzielle Konkurrenz unterscheidet zwischen Geometrien (Punkte, Linien und Flächen ohne Semantik) und Features. Und ein Feature, sagen wir mal ein Hotel, kann eine Punkt-Geometrie haben, oder eine Flächengeometrie, oder eine Flächengeometrie mit Loch: die Id des Features ändert sich nicht.

Bei uns hängt die Id eines Features von der verwendeten Geometrie ab: das gleiche Hotel ändert seine Id von p6192734612 über w12346137 zu r658723649. Und das macht es schwer, externe Datenbanken sauber anzubinden.

Trenne ich Features von Geometrie, so kann ich an die gleiche Geometrie mehrere Features hängen; so als Beispiel kann eine Linie zu einem Brückenfeature gehören und das Brückenfeature als Namen den Namen der Brücke tragen, und gleichzeitig zu einem Straßenfeature und das Straßenfeature kann als Namen den Straßennamen tragen. Unsere Nachbildung mit bridge:name ist ein Krampf dagegen.

Oder ich ordne einer Flächengeometrie ein Hausfeature zu und gleichzeitig ein Bäckerei-POI-Feature und ein Zahnarzt-POI-Features, die beide im gleichen Haus auf unterschiedlichen Etagen existieren. Fügt sich alles zwanglos und nahtlos ein.

Der Wahnsinn sind nicht die Relationen, sondern die Betrachtung von Relationen als etwas Exotisches – bei unserer Konkurrenz gehören die (äquivalenten) Features zum Kern des Datenmodels – und die stiefmütterliche Behandlung.

Mir ist klar, dass wir unser Datenmodell nicht ändern können, weil alle Tools auf den jetzigen Schrott zugeschnitten sind und angepasst werden müssten.

Es ist aber genau so klar, dass so ein Krampf wie POIs als Punkte in ein flächiges Haus abzukippen um auszudrücken, dass die POIs in dem Haus liegen – und jedem Auswerter die Aufgabe aufzudrücken, das wieder zusammenzusortieren –, oder andauernd wiederkehrende Diskussionen wie die, ob eine Adresse an das Haus oder an das POI oder an beides gehört – und viele mehr –, durch das schrottige Modell, das nicht zwischen Geometrie und Feature unterscheidet, verursacht werden.

Und das andauernde Relations-Bashing verhindert zuverlässig, dass sich daran jemals was ändern wird.

Just my 2.38¢.

Gruß Wolf

hurdygurdyman · 2013-12-05 15:48:55

chris66 wrote:

Lustig ist das Nachbardorf. Spielfeldlinien und Swimmingpools sind erfasst, aber Hausnummern?

Darüber rege ich mich schon gar nicht mehr auf. Spielfeldlinien waren hier schon früher mal Thema
Aber wenn dann einer anfängt, Gullideckel mit Anzahl und Ausrichtung der Ritzen zu erfassen, ohne vorher ein Proposal mit Abstimmung vorzulegen, wird der Löschteufel zuschlagen

chris66 · 2013-12-05 16:07:13

Netzwolf wrote:

Möglicherweise chronifizierte Frischluftphobie?

Ich war heute draußen um einige Hausnummern die auf ALK fehlen zu recherchieren.
Trotz des frischen Lüftchens.

Gehrke · 2013-12-05 16:31:07

Netzwolf wrote:

Der Wahnsinn sind nicht die Relationen, sondern die Betrachtung von Relationen als etwas Exotisches – bei unserer Konkurrenz gehören die (äquivalenten) Features zum Kern des Datenmodels – und die stiefmütterliche Behandlung.
Mir ist klar, dass wir unser Datenmodell nicht ändern können, weil alle Tools auf den jetzigen Schrott zugeschnitten sind und angepasst werden müssten.
Es ist aber genau so klar, dass so ein Krampf wie POIs als Punkte in ein flächiges Haus abzukippen um auszudrücken, dass die POIs in dem Haus liegen – und jedem Auswerter die Aufgabe aufzudrücken, das wieder zusammenzusortieren –, oder andauernd wiederkehrende Diskussionen wie die, ob eine Adresse an das Haus oder an das POI oder an beides gehört – und viele mehr –, durch das schrottige Modell, das nicht zwischen Geometrie und Feature unterscheidet, verursacht werden.
Und das andauernde Relations-Bashing verhindert zuverlässig, dass sich daran jemals was ändern wird.

Genau.

errt · 2013-12-06 12:23:26

Netzwolf wrote:

Mir ist klar, dass wir unser Datenmodell nicht ändern können, weil alle Tools auf den jetzigen Schrott zugeschnitten sind und angepasst werden müssten.

Vielleicht, vielleicht auch nicht. Es gab immerhin schon die ein oder andere Änderung (keine Segmente mehr, Relationen, etc.), wenn auch zu Zeiten, wo das vielleicht noch einfacher war. Die Idee für einen Area-Datentyp gibt es schon eine Weile und ich denke, noch besteht Hoffnung, dass der irgendwann kommt. Letztlich ist doch alles eine Frage des Preprocessings, dass man für Tools, die mit den neuen Features nicht umgehen können machen kann. Wenn wir einen Flächendatentypen bekommen, würde man sicher eine Möglichkeit schaffen, alle solchen Flächen im Preprocessing in MPs umzuwandeln, mit denen heute zumindest viele Tools umgehen können. Wenn du sagst, getrennte Geometrie und Features machen Sinn, dann müsste man eben ein Preprocessing haben, dass die Daten wieder an die Geometrie klatscht. Selbst wenn das nicht für alle Fälle perfekt funktioniert (mehrere Features an einer Geometrie z.B.) - für die große Mehrzahl wird es das und auch heute funktioniert nicht jeder Spezialfall. Nur muss man über solche Vorschläge diskutieren, damit sie sich durchsetzen. Ich denke, dass beim Flächendatentyp schon große Übereinstimmung besteht, dass das sinnvoll wäre, nur fehlt momentan eben noch die Implementierung. Wenn niemand die Trennung von Features und Geometrie vorschlägt, woher soll der Konsens kommen, den wir brauchen, bevor an eine Implementierung überhaupt gedacht werden kann?

Timmo · 2013-12-06 15:13:40

hurdygurdyman wrote:

Darüber rege ich mich schon gar nicht mehr auf. Spielfeldlinien waren hier schon früher mal Thema
Aber wenn dann einer anfängt, Gullideckel mit Anzahl und Ausrichtung der Ritzen zu erfassen, ohne vorher ein Proposal mit Abstimmung vorzulegen, wird der Löschteufel zuschlagen

JedeR soll das zur DB hinzufügen, was ihm/ihr wichtig ist. Spielfeldlinien und Gullideckelritzen können ein Einstieg für jene sein, die akut Lust oder Nutzen daran haben. Ggf. informieren sie sich dann weiter und helfen bei wichtigeren Projekten (ACHTUNG: subjektiv!). Wenn dann ein Löschteufel kommt, haben wir wieder potentielle MapperInnen verloren. Führt nicht unbedingt zu der Diversität, die OSM nötig hätte.

hurdygurdyman · 2013-12-09 07:26:23

Timmo wrote:

...
JedeR soll das zur DB hinzufügen, was ihm/ihr wichtig ist. Spielfeldlinien und Gullideckelritzen können ein Einstieg für jene sein, die akut Lust oder Nutzen daran haben. Ggf. informieren sie sich dann weiter und helfen bei wichtigeren Projekten (ACHTUNG: subjektiv!). Wenn dann ein Löschteufel kommt, haben wir wieder potentielle MapperInnen verloren. Führt nicht unbedingt zu der Diversität, die OSM nötig hätte.

Was ich zum Ausdruck bringen wollte:
Ich habe etwas dagegen, wenn wild nach Lust und Laune Daten in OSM gekippt werden. Wir haben für neue Schlüssel und deren Werte etablierte Vorgehensweisen zur Einführung und Akzeptanz. (Diese gelten auch für Neulinge)

Und:
Was am einer Spielfeldlinie barrier sein soll, vermag ich nicht zu erkennen. Für mich ist das tagging for the renderer, weil barrier ausgewertet und dargestellt wird.

Pepito · 2013-12-09 13:47:15

hurdygurdyman wrote:

Wir haben für neue Schlüssel und deren Werte etablierte Vorgehensweisen zur Einführung und Akzeptanz. (Diese gelten auch für Neulinge)

Als ich vor einigen Jahren hier anfing, hieß es noch sinngemäß, ich könne auch schnukiputzi=wauwau taggen, wenn ich Lust dazu hätte. Seit wann ist das denn obsolet? Ist das Wiki jetzt verbindlich?

wambacher · 2013-12-09 14:07:20

Pepito wrote:

hurdygurdyman wrote:
Wir haben für neue Schlüssel und deren Werte etablierte Vorgehensweisen zur Einführung und Akzeptanz. (Diese gelten auch für Neulinge)
Als ich vor einigen Jahren hier anfing, hieß es noch sinngemäß, ich könne auch schnukiputzi=wauwau taggen, wenn ich Lust dazu hätte. Seit wann ist das denn obsolet? Ist das Wiki jetzt verbindlich?

Du kannst natürlich weiterhin alles eintragen wie du willst, nur wird sich niemand darum kümmern, daß das irgendwie/irgendwo/irgendwann ausgewertet wird. Wenn du willst, dass jemand "deine" Tags kennt, akzeptiert und auch auswertet, musst du wohl oder übel die "Spielregeln" einhalten.

Gruss
walter

Announcement

#1 2013-12-05 11:13:04

Hausnummern, associatedStreet, und einiges mehr

#2 2013-12-05 12:02:40

Re: Hausnummern, associatedStreet, und einiges mehr

#3 2013-12-05 12:45:37

Re: Hausnummern, associatedStreet, und einiges mehr

#4 2013-12-05 12:50:17

Re: Hausnummern, associatedStreet, und einiges mehr

#5 2013-12-05 15:03:56

Re: Hausnummern, associatedStreet, und einiges mehr

#6 2013-12-05 15:09:10

Re: Hausnummern, associatedStreet, und einiges mehr

#7 2013-12-05 15:29:53

Re: Hausnummern, associatedStreet, und einiges mehr

#8 2013-12-05 15:48:55

Re: Hausnummern, associatedStreet, und einiges mehr

#9 2013-12-05 16:07:13

Re: Hausnummern, associatedStreet, und einiges mehr

#10 2013-12-05 16:31:07

Re: Hausnummern, associatedStreet, und einiges mehr

#11 2013-12-06 12:23:26

Re: Hausnummern, associatedStreet, und einiges mehr

#12 2013-12-06 15:13:40

Re: Hausnummern, associatedStreet, und einiges mehr

#13 2013-12-09 07:26:23

Re: Hausnummern, associatedStreet, und einiges mehr

#14 2013-12-09 13:47:15

Re: Hausnummern, associatedStreet, und einiges mehr

#15 2013-12-09 14:07:20

Re: Hausnummern, associatedStreet, und einiges mehr

Board footer