Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

viw · 2011-06-20T06:12:06.000Z

Fabi2:

stephan75:

Oder sollten für PLZ-Grenzen und Gemeindegrenzen (bei Deckungsgleichheit!) doch je eine eigene (dann wohl inhaltsgleiche) Relation einmal mit boundary = administrative und einmal mit
boundary = postal_code angelegt werden (bzw. so belassen werden)?

Zwei Relationen. Weil bei einer müßte man ja nach dem derzeitigen Schema boundary=administrative;postal_code in die Relation schreiben. Interessanterweise wird Taggimg mit dem “;”-Separator hier von manchen Leuten jetzt nicht so toll gefunden, wo sie es an anderer Stelle angeblich OK ist. Entscheidet euch doch mal!

Wenn ich boundary=administrative benutze, wie bekomme ich denn dann die Postleitzahlrelationen, wenn ich eine Abfrage nach boundary=postal_code mache? Zwar bekommt man die Postleitzahlen noch mit einem Filter nach Relationen mit postal_code=* aus der Datenbank, aber von einem ordentlichen Schema oder Abfragestil ist das weit entfernt, ähnliches gilt ersatzweise für admin_level=* . Da bleibt also nur zwei Relationen zu erstellen, damit es sauber ist.

Also ich denke in einem ordentlichen Schema braucht es keine doppelten Informationen. Es würde also genügen admin_level= zu definieren oder postal_code=
Welchen Vorteil habe ich jetzt von einem Tag namens boundary= ? Eigentlich keinen.
Das ist beim ÖPNV genau das Gleiche. Hier habe ich das sinnlose Tag type=route und dann route=… Ob in in der Datenbank also nun erst type=route suche und anschließend alles mit route=bus tram und Co suche oder ob ich gleich nur nach route=bus suche ist doch egal. Wobei letzteres sogar schneller sein sollte.

tiototo · 2011-06-20T06:44:23.000Z

Ich bin auch für zwei Relationen, allein um die alten Daten vom Import noch zu haben. Wenn aber beschlossen ist alles auch Gebiete umzustellen, an die ich über postal_code=xxxxx rankomme soll mir das auch recht sein. Wichtig ist nur dass man eine Abfrage machen kann, wo man zu einem Punkt die PLZ bekommen kann, das muss funktionieren!

ajoessen · 2011-06-20T06:56:02.000Z

viw:

Das ist beim ÖPNV genau das Gleiche. Hier habe ich das sinnlose Tag type=route und dann route=… Ob in in der Datenbank also nun erst type=route suche und anschließend alles mit route=bus tram und Co suche oder ob ich gleich nur nach route=bus suche ist doch egal. Wobei letzteres sogar schneller sein sollte.

Sehe ich anders:

Wenn ich erst nach type=route filtere (z.B. mit osmosis), und aus dem erzeugten Unterdatenbestand mir die benötigten bus,tram,trolleybus,rail,light_rail usw rausfische, sollte das erheblich schneller gehen, als immer in sämtlichen Relationen aufs neue suchen zu müssen.

Gruß,
ajoessen

viw · 2011-06-20T07:03:00.000Z

ajoessen:

viw:

Das ist beim ÖPNV genau das Gleiche. Hier habe ich das sinnlose Tag type=route und dann route=… Ob in in der Datenbank also nun erst type=route suche und anschließend alles mit route=bus tram und Co suche oder ob ich gleich nur nach route=bus suche ist doch egal. Wobei letzteres sogar schneller sein sollte.

Sehe ich anders:

Wenn ich erst nach type=route filtere (z.B. mit osmosis), und aus dem erzeugten Unterdatenbestand mir die benötigten bus,tram,trolleybus,rail,light_rail usw rausfische, sollte das erheblich schneller gehen, als immer in sämtlichen Relationen aufs neue suchen zu müssen.

Gruß,
ajoessen

also ich weiß nicht wie genau Osmosis filtert, aber bei o5mfilter kann ich statt nach type=route auch nach route= filtern. und damit hätte ich fast das Gleiche Ergebnis. Wenn in einem zweiten Schritt dann nach route=bus gesucht wird sogar wieder ein identisches.
Aber wahrscheinlich unterstützt auch Osmosis einen Filter nach route=*
Also bei Punkten und Wegen gibt es statt key value auch nur die Option nach key zu suchen. Für Relationen konnte ich das leider nicht finden.
Der einzige Unterschied ist das alle Relationen rausfliegen, welche nur mit type=route getagt sind und nicht weiter spezifiziert wurden. Diese brauchst du aber in deinem Beispiel nicht.
Auch der Umkehrschluss, dass jemand alle Relationen mit type=route raus haben möchte ließe sich über den key route=* lösen. Ich kann also den Sinn nicht erkennen.

GeorgFausB · 2011-06-20T07:20:18.000Z

Moin,

ajoessen:

viw:

Ob in in der Datenbank also nun erst type=route suche und anschließend alles mit route=bus tram und Co suche oder ob ich gleich nur nach route=bus suche ist doch egal. Wobei letzteres sogar schneller sein sollte.

Sehe ich anders:

Wenn ich erst nach type=route filtere (z.B. mit osmosis), und aus dem erzeugten Unterdatenbestand mir die benötigten bus,tram,trolleybus,rail,light_rail usw rausfische, sollte das erheblich schneller gehen, als immer in sämtlichen Relationen aufs neue suchen zu müssen.

Ihr solltet schon Gleiches mit Gleichem vergleichen:
Dem Wortlaut nach hat viw recht - solange er nur eine Unterkategorie in allen Relationen sucht (dies ist die Analogie zu postal_code und admin_level).
Andre hat recht - wenn er mehrere Unterkategorien von route bearbeiten möchte. (Dies ist der Unterschied bei ÖPNV - road ist wieder eigentlich nur eine Einzelunterkategorie).

Bei den Relationen mit nur einer Unterkategorie ist der Aufwand identisch, ob man nun nach Relations-Typ oder nach tatsächlicher Eigenschaft sucht - von daher sind die eigenen Relationen (für postal_code und admin_level bei identischem Verlauf) zwar Ariel-reines Schema - aber eigentlich nur Selbstzweck.

Gruß
Georg

viw · 2011-06-20T07:26:02.000Z

GeorgFausB:

Moin,
Ihr solltet schon Gleiches mit Gleichem vergleichen:
Dem Wortlaut nach hat viw recht - solange er nur eine Unterkategorie in allen Relationen sucht (dies ist die Analogie zu postal_code und admin_level).
Andre hat recht - wenn er mehrere Unterkategorien von route bearbeiten möchte. (Dies ist der Unterschied bei ÖPNV - road ist wieder eigentlich nur eine Einzelunterkategorie).

Bei den Relationen mit nur einer Unterkategorie ist der Aufwand identisch, ob man nun nach Relations-Typ oder nach tatsächlicher Eigenschaft sucht - von daher sind die eigenen Relationen (für postal_code und admin_level bei identischem Verlauf) zwar Ariel-reines Schema - aber eigentlich nur Selbstzweck.

Gruß
Georg

Wo ist der Unterschied? Ich möchte alle Straßen haben. Ich suche also nach highway=. Ich möchte alle Routen haben ich suche also nach route=.
Heute kann ich alle Routen aber zusätzlich mit type=route finden. Und genau dieses überflüssige type=route kann man sparen.
Ja ich weiß Josm filtert danach und sortiert die unterschiedlichen types. Aber das kann man anpassen!

wambacher · 2011-06-20T08:56:33.000Z

stephan75:

und welche Applikationen werten denn bisher auch die PLZ-Relationen aus?

u.A. meine http://wnordmann.homeunix.com/otm/plz1.html
und das ohne Probleme, solange ihr hier nur diskussiert aber nichts gravierendes ändert.
Grosse Sorgen mach ich mir aber nicht, da aus solchen “man müsste, man sollte, im wiki müsste man”-Diskussionen fast nie was rauskommt.

Gegen eine Vereinfachung hab ich allerdings nichts einzuwenden.

Gruss
Walter

viw · 2011-06-20T09:07:42.000Z

wambacher:

stephan75:

und welche Applikationen werten denn bisher auch die PLZ-Relationen aus?

u.A. meine http://wnordmann.homeunix.com/otm/plz1.html
und das ohne Probleme, solange ihr hier nur diskussiert aber nichts gravierendes ändert.
Grosse Sorgen mach ich mir aber nicht, da aus solchen “man müsste, man sollte, im wiki müsste man”-Diskussionen fast nie was rauskommt.

Gegen eine Vereinfachung hab ich allerdings nichts einzuwenden.

Gruss
Walter

So dann werde mal konkret. Welche Vereinfachungen Deiner Meinung nach zulässig werden und ab wann eine Auswertbarkeit Verloren geht?

wambacher · 2011-06-20T10:42:26.000Z

viw:

So dann werde mal konkret. Welche Vereinfachungen Deiner Meinung nach zulässig werden und ab wann eine Auswertbarkeit Verloren geht?

so könnte es aussehen:


./.                   Admin           PLZ                  beides
type                  boundary        boundary             boundary
boundary              administrative  postal_code          administative 
admin_level           *               -                    *
postal_code           -               *                    *

type=multipolygon ist eine “Null-Information”, die imho nicht notwendig ist.
Es handelt sich hier um eine Relation, deren interne Struktur bereits aus den Members hervorgeht.
Das ist ein Multipolygon; das braucht man nicht nochmal dranzuschreiben.
Es muss nur klar sein, dass es sich um eine beliebige Art von Grenze handellt.
beide Informationen in eine Relation reinzuschreiben erscheint mir irgendwie unsauber; dadurch sind schon speziellere Abfragen notwendig.
Andererseits ist das Erfassen/Pflegen der Rels einfacher.

Erst wollte ich type sogar ganz weglassen aber es gibt noch andere Rels mit postal_code (z.B. associatedStreet)

Das ist mein Vorschlag:


./.                   Admin           PLZ
type                  boundary        boundary                
boundary              administrative  postal_code    
admin_level           *               -                    
postal_code           -               *

rein theoretisch könnte man sogar noch boundary=* weglassen.


./.                   Admin           PLZ
type                  boundary        boundary                  
admin_level           *               -                    
postal_code           -               *

aber irgendwie geht mir das zuweit.

Gruss
Walter

viw · 2011-06-20T10:51:18.000Z

wambacher:


./.                   Admin           PLZ
type                  boundary        boundary                  
admin_level           *               -                    
postal_code           -               *

aber irgendwie geht mir das zuweit.

Gruss
Walter


./.                   Admin           PLZ                  beides
admin_level           *               -                    *
postal_code           -               *                    *

Und was spricht dagegen?

SunCobalt · 2011-06-20T10:55:39.000Z

viw:


./.                   Admin           PLZ                  beides
admin_level           *               -                    *
postal_code           -               *                    *

Und was spricht dagegen?

Wie willst Du eine Grenze taggen, deren admin_level Du nicht kennst?

viw · 2011-06-20T10:59:37.000Z

SunCobalt:

viw:
./.                   Admin           PLZ                  beides
admin_level           *               -                    *
postal_code           -               *                    *     
Und was spricht dagegen?
Wie willst Du eine Grenze taggen, deren admin_level Du nicht kennst?

Das ist ein interessanter Einwand, aber wenn es der einzige ist, kann man hier ja auch 0 nehmen.

SunCobalt · 2011-06-20T11:04:08.000Z

viw:

SunCobalt:
viw:
./.                   Admin           PLZ                  beides
admin_level           *               -                    *
postal_code           -               *                    *     
Und was spricht dagegen?
Wie willst Du eine Grenze taggen, deren admin_level Du nicht kennst?
Das ist ein interessanter Einwand, aber wenn es der einzige ist, kann man hier ja auch 0 nehmen.

Was, wenn es andere Dinge gibt oder geben wird, die eine administrative Rangordnung haben? Es wird halt von admin_level ein boundary impliziert. Und wo man impliziert, muss man sich sicher sein, dass das alle anderen intuitiv auch richtig verstehen. Und da habe ich einige Zweifel.

viw · 2011-06-20T11:14:49.000Z

SunCobalt:

Was, wenn es andere Dinge gibt oder geben wird, die eine administrative Rangordnung haben? Es wird halt von admin_level ein boundary impliziert. Und wo man impliziert, muss man sich sicher sein, dass das alle anderen intuitiv auch richtig verstehen. Und da habe ich einige Zweifel.

Mhhh auch ein berechtigter Einwand. Dazu kann ich bei Grenzen auch nichts entgegensetzen. Aber beim ÖPNV könnte man doch auch das type=route verzichten, da man danach ohnehin mit route=* den Type der route spezifiziert. Richtig? Da gäbe es dann auch nichts mehr daran zu interpretieren.

wambacher · 2011-06-20T11:18:06.000Z

viw:


./.                   Admin           PLZ                  beides
admin_level           *               -                    *
postal_code           -               *                    *

Und was spricht dagegen?

bis auf die Tatsache, dass type=boundary hier fehlt, nicht viel (*)
Es gibt derzeit in DACH+ ca 230 Rels mit admin_level oder postal_code, die keine Boundaries sind oder zumindest nicht leicht als solche zu erkennen sind.

siehe: http://wnordmann.homeunix.com/images/stories/osm/forum/al_und_plz.txt

(*) ich muss erstmal die berechtigten Einwände von Thomas “verdauen”. wie schon geschrieben, geht mit diese absolute Minimalversion gegen den Strich.

Gruss
Walter

wambacher · 2011-06-20T11:25:57.000Z

viw:

SunCobalt:

Was, wenn es andere Dinge gibt oder geben wird, die eine administrative Rangordnung haben? Es wird halt von admin_level ein boundary impliziert. Und wo man impliziert, muss man sich sicher sein, dass das alle anderen intuitiv auch richtig verstehen. Und da habe ich einige Zweifel.

Mhhh auch ein berechtigter Einwand. Dazu kann ich bei Grenzen auch nichts entgegensetzen. Aber beim ÖPNV könnte man doch auch das type=route verzichten, da man danach ohnehin mit route=* den Type der route spezifiziert. Richtig? Da gäbe es dann auch nichts mehr daran zu interpretieren.

lenk nicht ab
wir reden hier von Grenzen und nur Grenzen. Mach biite zum ÖPNV nen eigenen Thread auf anstatt die Sachen gemeinsam zu bekakeln. Dazu sind die zu unterschiedlich.
Gruss
Walter

viw · 2011-06-20T12:10:21.000Z

wambacher:

viw:
./.                   Admin           PLZ                  beides
admin_level           *               -                    *
postal_code           -               *                    *     
Und was spricht dagegen?
bis auf die Tatsache, dass type=boundary hier fehlt, nicht viel (*)
Es gibt derzeit in DACH+ ca 230 Rels mit admin_level oder postal_code, die keine Boundaries sind oder zumindest nicht leicht als solche zu erkennen sind.

siehe: http://wnordmann.homeunix.com/images/stories/osm/forum/al_und_plz.txt

(*) ich muss erstmal die berechtigten Einwände von Thomas “verdauen”. wie schon geschrieben, geht mit diese absolute Minimalversion gegen den Strich.

Gruss
Walter

Die Auswertung ist schon interessant. Vor allem scheint hier noch das veraltete “associatedStreet” vorhanden zu sein. Bei den admin_level sind es vorwiegend boundary_segment und municipality
Jetzt kann man also darüber streiten ob diese Relationen eine Berechtigung haben für dieses Tag. Bei route und enforcment ist der postal_code sicher genauso falsch wie das admin_level bei collection.
Andererseits sieht man hier auch gut das es offenbar Relationen mit dem Type postal_code gibt, welche nach dem anderen Schema nicht gefunden werden. Gleiches gilt natürlich auch für country und commune

ajoessen · 2011-06-20T12:17:11.000Z

wambacher:

lenk nicht ab
wir reden hier von Grenzen und nur Grenzen. Mach biite zum ÖPNV nen eigenen Thread auf anstatt die Sachen gemeinsam zu bekakeln. Dazu sind die zu unterschiedlich.
Gruss
Walter

Es wäre eine gute Idee, ** nichts ** einfach als “überflüssig” zu betrachten, was in OSM seit Jahren etabliert ist.
osm2pgsql wertet im postprocessing nach dem Import Relationen je nach Typ als Weg, Fläche oder garnicht aus. Das muß man nicht künstlich verkomplizieren.

gruß,
ajoessen

wambacher · 2011-06-20T12:48:52.000Z

ajoessen:

wambacher:

lenk nicht ab
wir reden hier von Grenzen und nur Grenzen. Mach biite zum ÖPNV nen eigenen Thread auf anstatt die Sachen gemeinsam zu bekakeln. Dazu sind die zu unterschiedlich.
Gruss
Walter

Es wäre eine gute Idee, ** nichts ** einfach als “überflüssig” zu betrachten, was in OSM seit Jahren etabliert ist.
osm2pgsql wertet im postprocessing nach dem Import Relationen je nach Typ als Weg, Fläche oder garnicht aus. Das muß man nicht künstlich verkomplizieren.

gruß,
ajoessen

sorry, ich verstehe hier nicht, was du damit meinst.
passt auch nicht zu meinem “dezenten” hinweis, in diesem thread am thema zu bleiben.

Gruss
Walter

ajoessen · 2011-06-20T12:53:03.000Z

wambacher:

ajoessen:

Es wäre eine gute Idee, ** nichts ** einfach als “überflüssig” zu betrachten, was in OSM seit Jahren etabliert ist.
osm2pgsql wertet im postprocessing nach dem Import Relationen je nach Typ als Weg, Fläche oder garnicht aus. Das muß man nicht künstlich verkomplizieren.

sorry, ich verstehe hier nicht, was du damit meinst.
passt auch nicht zu meinem “dezenten” hinweis, in diesem thread am thema zu bleiben.

Das type=* ist bei Grenzen genausowenig überflüssig wie bei Routen, weil sich Rohdatenverarbeitende Programme darauf verlassen, dass es vorhanden ist.

Gruß,
ajoessen