Es gibt nun einige kleine Gemeinden, bei denen sind die bereits erfassten PLZ-Grenzen identisch mit den Gemeindegrenzen. Somit könnten die PLZ-Grenzen ja auch als boundary=administrative dienen. Wie gesagt: nur dort wo die Grenzen tatsächlich identisch wären.
Z.B. für den Ort Deutsch Evern habe ich den Schlüssel boundary=postal_code auf =administrative geändert sowie admin_level=8 hinzugefügt.
d.H. für BEIDE Grenzarten (politisch und PLZ) existiert jetzt nur EINE Relation. Ist das so in Ordnung?
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)?
Wie habt ihr das in anderen Gegenden der Republik gemacht? Was sagt Taginfo oder Tagwatch dazu?
Solche Gemeinden oder Städte gibts viele - Du hast den Value geändert? Sprich es gibt nun keinen postal_code mehr? Das wäre blöd. Ich nehm mal eher an Du hast da etwas ergänzt. Dann ist der Schlüssel aber doppelt belegt. Ich hab hier Software die sucht nach dem postal_code und dann gäbe es Ecken die hätten dann gar keinen mehr.
Nur mal eben dass ich das richtig verstehe. Wenn ich von einem Punkt wissen will in welcher PLZ der liegt dann reicht das nicht dass ich boundary=postal_code suche sondern muss außerdem noch nach postal_code=XXXXX gucken? Oder hat sowie jedes PLZ-taugliche Polygon ein postal_code=XXXXX und ich kann mir die Abfrage mit dem boundary sparen? Dann frag ich mich warum es überhaupt noch den Fall das Tag boundary=postal_code gibt. Was wertet Mapnik denn aus?
Danke für den Link, sehr interessant. Wenn ich das richtig verstehe, ist das Ziel, alles mit postal_code=XXXXX zu haben.
Fürs nächste Update ist der Schlüssel dann auch für meine Datenbank vorgemerkt, der default.style für osm2pgsql hat das normal nämlich nicht drin. Demnach hat Mapnik die PLZ-Grenzen noch aus der “alten” Schreibweise oder ich hab nicht die aktuelle Datei.
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.
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!
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.
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.
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.
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!
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.
