Idee: Städte und Gemeinden in Relationen taggen

KaChing_Cacher · 2009-05-25T13:10:31.000Z

Denkbar wäre doch auch addr:city dafür weiter zu benutzen.
Aber als Relation fände ich das auch gut, weil man
sich das im Gegensatz zu addr:city im Analyzer anzeigen lassen kann.

oli · 2009-05-25T13:15:15.000Z

Klar, addr:city wäre auch eine Idee. Aber das muss dann jeder einzelner Node/Track zugewiesen werden. Und gerade für Attribute, die viele Nodes/Tracks gemeinsam haben, gibt es ja die Relations.
Wenn man die Geschichte weiterspinnt, müsste man dann auch jeder Node/Track einen is_in-Rattenschwanz mitgeben. Auch das könnte man in der Relation vereinheitlichen.

Oli

TEL0000 · 2009-05-25T14:34:34.000Z

Am einfachsten ist es, die Stadtgrenzen zu erfassen…

Nop · 2009-05-25T14:37:50.000Z

TEL0000:

Am einfachsten ist es, die Stadtgrenzen zu erfassen…

Was soll daran einfach sein? Bzw. wie willst Du einem beliebigen Way ansehen, ob er dazugehört oder nicht?

oli · 2009-05-25T15:06:30.000Z

TEL0000:

Am einfachsten ist es, die Stadtgrenzen zu erfassen…

Sorry, wenn ich so dumm frag, aber in wiefern ist das einfacher? Eine Stadt- oder Gemarkungsgrenze ist nicht so einfach zu erfassen, es sein denn, man hat Zugriff auf die öffentlichen Daten, was in den wenigsten Fällen der Fall sein dürfte.

Oli

TEL0000 · 2009-05-25T15:11:01.000Z

oli:

TEL0000:

Am einfachsten ist es, die Stadtgrenzen zu erfassen…

Sorry, wenn ich so dumm frag, aber in wiefern ist das einfacher? Eine Stadt- oder Gemarkungsgrenze ist nicht so einfach zu erfassen, es sein denn, man hat Zugriff auf die öffentlichen Daten, was in den wenigsten Fällen der Fall sein dürfte.

Oli

Woran willst du denn dann festmachen, was in die Relation kommt, und was nicht?

oli · 2009-05-25T15:23:55.000Z

TEL0000:

Woran willst du denn dann festmachen, was in die Relation kommt, und was nicht?

Gute Frage…

Klar, Grenzen müssen sein, da hast Du vollkommen recht. Aber für die auswertende Software wäre doch eine klare objektorientierte Struktur wesentlich einfacher auszuwerten.
Wenn man einfach die Stadtgrenze erfasst und die Auswerte-Software (ich schreibe bewusst nicht Renderer, weil da gibt’s noch mehr) dann aufgrund von Koordinaten mehr oder weniger raten muss, ob z.B. ein Wald jetzt inner- oder außerhalb dieser Grenzen liegt, wäre es doch einfacher, wenn die Software nur auf die Relation schauen muss.

Ich programmier halt seit über 10 Jahren objektorientiert und da denkt man halt irgendwann in Objekten und Klassen. Und eine Relation ist da das entsprechende Pendant dazu.

Oli

SIR · 2009-05-25T16:09:09.000Z

Prinzipiell fände ich eine konsequente Anwendung von Relationen auch sinnvoll und dadurch ließen sich viele Dinge vereinheitlichen. Momentan (soweit ich das bisher realisiert habe) scheint es kein einheitliches System zu geben. Und das betrifft nicht nur die Zuordnung von Objekten zu Ortschaften.

Ich bevorzuge (solang es keine Alternative gibt) ein area mit place=city o.ä. mit name-Tag und source=estimated. Ich schätze auf Grund meiner Ortskenntnisse die Ortsgrenze und damit sollten auch die darin befindlichen Objekte korrekt zugeordnet werden. So hoffe ich jedenfalls.

Gruß
Ronny

Hobby_Navigator · 2009-05-25T16:34:53.000Z

Schätzen ? Na ich weis nicht. Lasst und lieber zu Grenzgängen aufrufen, dass bringt die Leute an die Luft und jede Menge Spaß
Ne, im Ernst ich denke es wird nicht so einfach werden die Gemarkungsgrenzen zu bekommen. Der Vorschlag an sich ist mir jedoch sehr symphatisch.
Georg

Marcus_Wolschon · 2009-05-28T06:22:52.000Z

oli:

Hallo!

Keine Ahnung, ob das schon irgendwo andiskutiert wird, ich hab’s jedenfalls nirgends gefunden:

Wäre es nicht sinnvoll, für jede Ortschaft eine Relation zu erstellen, in die alles innerhalb der Ortschaft zusammengefasst ist (Straßen, Adressen, POIs, Grenzen, …)?

Wäre nicht sinnvoll, da das
a) jede Grenze von maximalen Anzahlen an Elementen in einer Relation sprengt
b) diese gigantischen Relationen keiner runterladen kann
c) das ganze auch keiner pflegen kann und wird.

Marcus_Wolschon · 2009-05-28T06:25:50.000Z

oli:

TEL0000:

Am einfachsten ist es, die Stadtgrenzen zu erfassen…

Sorry, wenn ich so dumm frag, aber in wiefern ist das einfacher? Eine Stadt- oder Gemarkungsgrenze ist nicht so einfach zu erfassen, es sein denn, man hat Zugriff auf die öffentlichen Daten, was in den wenigsten Fällen der Fall sein dürfte.

Oli

Da wo die Häuser aufhören ist in erster Näherung die Stadt sowohl für Post-Adresse, Verkehrsregeln und Verwaltung zuende.

Zweite Näherung: Ortseingangs-Schilder.

Dritte Näherung: Anwohner wissen sowas meist. (bzw. Adressen in denen der Name der Ortschaft steht)

Achtung:
Ortschaften haben mindestens 3 verschiedene Grenzen:

Post-Adresse
geschlossene Ortschaft nach StVO
Verwaltungs-Zugehörigkeit

oli · 2009-05-28T07:32:59.000Z

Hallo, Marcus,

Marcus Wolschon:

Wäre nicht sinnvoll, da das
a) jede Grenze von maximalen Anzahlen an Elementen in einer Relation sprengt
b) diese gigantischen Relationen keiner runterladen kann
c) das ganze auch keiner pflegen kann und wird.

zu a) Ok, das wusste ich nicht, dass es Obergrenzen gibt. Wo liegen denn die?
zu b) Ob ich jetzt 10000 Einzelelemente runterlade, oder eine Relation mit 10000 Elementen, wo ist da der Unterschied? Und außerdem: Ich MUSS ja nicht zwingend über die Relation auf ein Element zugreifen.
zu c) In wiefern ist der Pflegeaufwand größer als ohne Relation? Gut, es ist ein Tag mehr, der gesetzt werden muss. Aber sonst?

Marcus Wolschon:

Da wo die Häuser aufhören ist in erster Näherung die Stadt sowohl für Post-Adresse, Verkehrsregeln und Verwaltung zuende.

Und wie ist es z.B. mit Aussiedlerhöfen? Bei uns gibt es z.B. einen Aussiedlerhof, der ist näher am Nachbarort. Hier muss zwingend eine Zugehörigkeit getaggt werden (is_in oder eben Relation).

Marcus Wolschon:

Zweite Näherung: Ortseingangs-Schilder.

Nicht an jeder Einfahrtsstraße ist ein Ortseingangsschild.

Marcus Wolschon:

Dritte Näherung: Anwohner wissen sowas meist. (bzw. Adressen in denen der Name der Ortschaft steht)

Wäre schlecht, wenn’s nicht so wäre. Aber in welcher Form kommt dieses Wissen in die Datenbank? Das ist doch die große Frage.

Nochmals zur Verdeutlichung:
Ich will hier nicht meine ach so tolle Idee durchdrücken. Ich möchte einfach nur mal das Für und Wider abwägen können. Aus dem Alter, in dem ich mit dem Kopf durch die Wand gerannt bin, bin ich mittlerweile raus.
Ich habe offen gestanden auch keine Ahnung, wie die OSM-Datenbank aufgebaut ist. Vielleicht spricht ja auch schon das gesamte Konzept, so wie Du sagst, gegen dieses Vorgehen. Aber dann erlaube ich mir die Frage, ob das DB-Konzept das richtige ist.

Gruß
Oli

Mirko_Küster · 2009-05-28T11:33:19.000Z

Die technische Obergrenze an Membern in einer Relation liegt bei 2000. Das reicht bei detailreichem Mapping bis maximal großes Dorf oder kleine Kleinstadt.

Der Erfassungsaufwand hat keinerlei Vorteil. Ob ich nun alles im Ort selektiere und in einem rutsch addr zuordne oder alles selektiere und in eine Relation mit mit addr packe. Das ist plus minus null. Genau wie der Pflegeaufwand. Es ist genauso schwierig Objekte ausfindig zu machen wo addr vergessen wurde, wie Objekte die nicht in in die Relation aufgenommen wurde. Eines ist aber sicher. Eine relation wird schneller fehlerhaft, als das es vorkommt, dass großflächig addr an allen Objekten verschwindet. Und da haben wir noch ein Problem. Die ganzen aufkeinemenden Relationsideen werden von keinem Programm ausgewertet. Tags allerdings schon.

Ich vergebe jede einzelene Adresse mit einem vollem Satz nach Karlsruher Schema. Jeder der bei mir nach einer konktreten Adresse sucht, wird so auch eindeutig fündig.

oli · 2009-05-28T11:48:43.000Z

Na, das nenne ich doch mal eine fachmännische Auskunft!
Vielen Dank, Mirko, für die Klärung.

Wegen der Gemarkungsgrenzen hab ich übrigens mal ne nette Mail an unseren Herrn Bürgermeister geschrieben und gleichzeitig ein bisschen Webung für OSM gemacht. Mal schauen, ob was zurückkommt…

Gruß
Oli

S-A-L · 2009-05-28T12:17:56.000Z

Mirko Küster:

Eines ist aber sicher. Eine relation wird schneller fehlerhaft, als das es vorkommt, dass großflächig addr an allen Objekten verschwindet.

Genau das wäre eigtl. der Vorteil, denn so schnell wie sowas Fehlerhaft werden kann, kann der fehler auch wieder behoben werden. Wogegen eine falsche PLZ in einem von 10000 Häusern wohl kaum bemerkt wird und das Haus demnach wahrscheinlich auch nicht gefunden wird wenn man sich auf die dortigen Angaben verlässt.

Mirko_Küster · 2009-05-28T12:33:25.000Z

Zeitlich habe ich da nichts gewonnen. Man kann nicht festellen was fehlt oder im Eimer ist. Relationen sind dafür zu dumm. Bleibt wieder nur regelmäßig alles selektieren und übernehmen und hoffen das man alles drin hat.

Relationen können derzeich nur eines. ZUsammenfassen und sortieren, das wars. Vererben, Logik, Selbstdiagnose. Alles Wunschträume und weit weg von einer Umsetzung.

Eine Fehlerhafte PLZ findet sich genauso schnell. Wenn ich alles selektiere muss mir der bei addr:postcode immer die entsprechende PLZ stehen. Steht dort , ist ein Fehler drin. Das zu beheben ist dann auch kein Akt. Einfach bei wieder die PLZ eintragen, speichern und hochladen. So hast du in 5 Sekunden alles mit einer PLZ. Das geht ebenfalls bei für das Gebiet globalen Werten wie addr:country und adrr:city.

Andere Fehler wie falsch geschriebene Straße oder Nummer muss man bei egal welcher Umsetzung händisch suchen. Es gibt keine Möglichkeit eine art Makro für die Fehlersuche einzubauen. Hier hilft nur die Überwachung des eigenen Gebietes. Nach jeder Änderung müssen aktuell geänderte und fehleranfällige Objekte gesichtet werden.

Um das etwas abzufangen und die manuelle Fehlersuche auf Nummern zu beschränken und die Memberanzahl klein zu halten, müsste man Relationen verschachteln. Eine Relation für jede Straße. Die zusammengefasst in einer Relation für den Stadt- oder Ortsteil, welche wiederum von einer Ortsrelation zusammengefasst sind. Bleibt aber ein altes Problem. Im Gegensatz zu den Tags, werden solche Konstrukte von keiner Anwendung ausgewertet, also schlicht nicht gefunden.

alv · 2009-05-28T13:37:17.000Z

http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories

JohannesF · 2009-05-28T14:03:28.000Z

Hi alv,

…der ist gut!

Ich bin auch der Meinung, dass man die Sache durch Grenz-Flächen ganz gut in den Griff bekommt. Selbst wenn die Gemeindegrenzen nicht exakt bekannt sind, so weiss man doch, ob ein bestimmter Weg in die eine oder die andere Gemeinde / Stadt gehört. [EDIT: Ohne dieses Wissen könnte man auch keine entsprechende Relation erstellen. Und die Grenz-Umrandung hat den Vorteil, dass alle Wege, die innerhalb neu gemacht werden automatisch drin sind.]

Klar gibt es hier und da mal Exklaven, die könnte man dann aber als Multipolygon einbeziehen.

Bis dann
johannes

oli · 2009-05-28T14:19:04.000Z

Interessanter Artikel, den kannte ich noch nicht.
Das bringt mich zu einem Thema, was ich noch nicht ganz verstanden habe: Wieso wird z.B für jede Autobahn eine Relation erstellt, wenn doch überall schon ein “ref” drinsteht?
Ouh, jetzt wird’s off-topic

Oli

JohannesF · 2009-05-28T14:21:54.000Z

@ Mirko Küster:
bist du dir sicher mit den 2000 Elementen pro Relation? Ich hab’ nur die Beschränkung 2000 Nodes pro Way (seit API 0.6) gefunden…

johannes