Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

Was meinst du mit “belassen” genau? Den “komischen” name-Tag so lassen oder die ganze Umstellung (PLZ-Rels komplettieren, PLZ aus Gemeinde-Rel raus)?

+1

bitte nein, wir haben schon genug Stress mit type=boundary/multipolygon gehabt. Es handelt sich um Grenzen mit allen deren Eigenschaften (nicht überlappend, ergeben zusammen eine große Fläche, hierarchisch strukturiert). Dann sollte man die auch Boundary nennen dürfen.

schwierig, schließlich sucht er sich ja zusammen, was er kriegen kann: erst name, dann note dann desription oder auch in einer anderen Reihenfolge?.

Gruss
walter

ps: hast du schon eine Meinung zu Nominatim? Ich bin mir derzeit noch unsicher.

Ich habe leider keine Ahnung von Nominatim. Aber wenn man sich anschaut, welche PLZ-Informationen bisher anscheinend genutzt wurden (places und admins?), glaube ich nicht, dass eine Umstellung auf postal_code-Relationen für Nominatim ein Rückschritt wäre.

Dann ist mir auch (fast) egal, ob ein postal_code an der admin-Relation ist. Wenn das aber so ist, wäre ich dafür, einheitlich die eine PLZ aus den DESTATIS-Daten für die Gemeindeverwaltung zu nehmen. Das hieße dann z.B. “postal_code=28195” für Bremen und “postal_code=80331” für München. Oder bringt das dann Nominatim durcheinander? Experten hier?

Ich denke, an diesem Beispiel sind wir an tatsächlich an ein grundsätzliches Problem gestoßen.
Es gibt in OSM echte ortsbezogene Daten (das kann ein Name, aber auch ein Jahreszahl für ein Ereignis an diesem Ort sein) und andere, ich nenne sie mal Metadaten. Dazu gehören die eindeutigen Objekt-IDs, ohne die keine DB funktionieren kann, aber auch Einträge, um Relationen z.B. im Editor besser identifizieren zu können. So ist ja wohl der note-Eintrag in PLZ-Relationen entstanden.

Wir taggen nicht für den Auswerter sollte ja mMn im Kern bedeuten, dass man nicht echte Geo-Informationen manipuliert, um bestimmte Darstellungen zu erzeugen. Wir taggen aber auch nicht gegen den Auswerter, sollten ihm die Arbeit im Gegenteil so gut es geht erleichtern. Sollte man da nicht Nägel mit Köpfen machen und diese Meta-Informationen ehrlich deklarieren? Der note-Tag ist so ein Fall: Er richtet sich nur an andere Tagger und ist keine eigentliche Geo-Information. Kann man nicht einen Tag finden, der ausdrücklich nur für interne Zwecke vorgesehen ist und gezielt ignoriert oder z.B. im Editor gezielt verwendet werden kann? Als Kandidat fällt mir da “label” ein, “ref” sagt mir nicht so zu, da es in vielen Fällen (Straßennummern) eine echte Geo-Information ist.
Bleibt “nur” noch das Problem, dass die Auswerter das für sie gedachte Tag auch verwenden. Die Aussicht, damit endlich mal echte von unechten Geo-Informationen zu trennen, scheint mir die Mühe

Ein ähnlich gelagertes Problen hat man auch, wenn man dem Renderer eine geeignete Stelle für die Plazierung eines Namens vorschlagen will. Da ist ja das place-Tag leicht zweckentfremdet worden (das ja als place=locality eindeutig eine Geo-Bedeutung hat).

Hallo Walter

In dem Fall meinte ich statt name= besser bei note= bleiben.
Die PLZ-Relationen sollten besser von den Admin-Relationen getrennt werden.
Die Wege kann man ja dort, wo sie gemeinsam sind, in beiden Relationen benutzen.

Das bedarf einer Menge Überzeugungsarbeit.
Aber im Augenblick scheinen die Zeichen für Änderungen bei Mapnik einigermaßen günstig zu stehen.

Das überzeugt mich, Option gestrichen.

Die Anzeige-Reihenfolge für Relationen-Bezeichnungen sind eine Liste von Schlüsseln, die man auch lokal ergänzen oder ändern kann. Es wäre also kein große Sache, einen neuen Schlüssel für die Relationen-Bezeichnungen standardmäßig in JOSM zu integrieren.

In welcher Hinsicht? PLZ-Gebiete findet er offensichtlich über die ref-Angabe.
Ob Nominatim Stimmbezirke finden soll, da habe ich mir noch keine Meinung gebildet.

Edbert (EvanE)

Wie wäre es mit “relation_name=” oder kürzer “rel_name=*”? Irgendetwas mit “label” könnte irreführend sein, da “label” bei Relationen schon anders belegt ist.

Status quo der deutschen PLZ in OSM (11.11.2013, ca. 21:00 Uhr):
Es gibt 6128 dedizierte postal_code-Relationen. Eine ist nicht eineindeutig (PLZ: 16835)
Es gibt für davon nicht erfasste PLZ 1075 PLZ-getaggte Admin-Relationen mit postal_code_level=8.
Außerdem gibt es noch 1005 Gemeinden, die einen postal_code-Tag haben, für die aber keine PLZ-Relation gegeben und kein postal_code_level getaggt sind.

Laut Post gibt es in DE 8208 Zustellgebiete.
Insgesamt sind 8207 PLZ erfasst. Fehlte also eigentlich nur noch eine PLZ, wenn denn keine falschen dabei wären!
Lücken bestehen noch in Düsseldorf. Dort fehlen 17 PLZ-Gebiete: 40210, 40212, 40213, 40215, 40217, 40219, 40221, 40223, 40225, 40227, 40229, 40231, 40233, 40235, 40237, 40239, 40591.

Als nächstes möchte ein 3D-Mapper Gebäudeteilen ohne echten Namen einen Hilfsnamen für die Übersicht im Editor geben: way_name. Und der nächste sammelt Automaten und braucht dann node_name für “Kondomautomat an der Pariser Allee”, “Zigarettenautomat Reemtsma-Straße”. Und im Jahr 2030 kommt die API 0.7 mit einem area-Datentyp und es geht weiter mit area_name. Dann doch lieber was generisches.

Klingt nach einem überschaubaren Projekt.

Du hast mit deinen Überlegungen vollkommen Recht. Dieses Problem taucht ja an allen Ecken irgendwann mal auf. Und es betrifft nicht nur Relationen sondern auch, was in JOSM als Beschriftung gezeigt wird. Einfach mal in den “Erweiterten Einstellungen” nach Order suchen. In all den Fällen, in denen man einen Namen braucht / nutzen will, den Namen aber nicht gerendert haben will.

Ich habe an norender_name oder an virtual_name gedacht. Der konkrete Name des Schlüssels ist mir unwichtig. Er sollte nur in möglichst vielen Fällen nutzbar sein.

Edbert (EvanE)

Akzeptiert. Dann versuche ich es mal mit "identifier=* ( http://www.dict.cc/englisch-deutsch/identifier.html ).
Wäre das generisch genug?

jetzt sind wir schon drei :wink:

Wieder eines der kleinen Josm-Geheimnisse.

ref? die haben wir doch garnicht drin, oder? Ansonsten hab ich mal ein wenig getestet. Er benutzt -natürlich- die plz aus der plz-relation und damit sollte alles ok sein.

warum nicht, wenn der als boundary mit seinem passenden boundary=* drin ist. Eventuell kann man das bei der Suche (als Anwender) filtern?

Gruss
walter

Gut, wenn label schon anderweitig belegt ist (ich wollte neue Schlüssel nur einführen, wenn unvermeidbar), dann ein neuer Schlüssel. Da tendiere ich bei so einer grundsätzlichen Funktion (ich bin keine echte Geo-Information) auch eher zu etwas auf oberster Stufe wie identifier. Das stünde dann auf gleicher Stufe wie label oder note. Ob es identifier heißt, wäre wäre mir nicht so wichtig, Hauptsache ein griffiger und selbsterklärender Begriff.

Als Zwischenlösung, solange noch ignoriert wird, würde ich parallel dazu bei note bleiben, mit dem Vermerk, dass diese (unerwünschte) Verwendung aufgegeben wird, sobald auf breiter Basis für Darstellungen, Anzeigen etc. ausgewertet wird.

Er nimmt definitiv auch die PLZ-Boundary zur Suche. Wenn ich in openstreetmap.org nach “65388” suche (PLZ von Schlangenbad) hat er als 2. Treffer die PLZ-Relation http://www.openstreetmap.org/browse/relation/3320567 und auf nomination.openstretmap.org zeigt er die auch sauber an: http://nominatim.openstreetmap.org/details.php?place_id=9149874830
Scheint also alles in Butter zu sein.

Ist das die PLZ der Gemeindeverwaltung? Sollte wohl kein Problem machen.

Gruss
walter

Ich finde, dieser Aspekt ist einen eigenen Thread wert, sonst geht der hier unter. Besonders die gerade startende Grundsatzdebatte “Wohin mit den Rel-Tags und wenn ja, welche?” :wink: könnte dort geführt werden.

Gruss
walter

Hallo Walter

Da bin ich zufällig drüber gestolpert, als ich etwas ganz anderes suchte. Als ich das sah, machte es Klick bei mir. Das war doch ein Teilproblem bei den Stimmbezirken, die in der Relationenliste leicht von anderen Grenzen unterscheiden zu können.

Vielleicht hat jemand einen Tipp für mich, wie ich mein ursprüngliches Problem lösen kann. Es geht darum den Platz für die Objektanzeige in der Infoleiste ganz unten zu vergrößern. In all den hunderten einstellbaren Werten habe ich nichts gefunden, was nur im entferntesten passend klang.

Edbert (EvanE)

Hallo Walter

Bei den reinen PLZ-Relationen hier in Bonn ist die PLZ zusätzlich als ref=* eingetragen.
(“reine PLZ-Rel.” im Sinne von ohne Verquickung mit Admin-Grenzen)

Edbert (EvanE)

Status quo der deutschen PLZ in OSM (12.11.2013, ca. 21:00 Uhr):
Es gibt 6128 dedizierte postal_code-Relationen. Eine ist nicht eineindeutig (PLZ: 16835)
Es gibt für davon nicht erfasste PLZ 1075 PLZ-getaggte Admin-Relationen mit postal_code_level=8.
Außerdem gibt es noch 1005 Gemeinden, die einen postal_code-Tag haben, für die aber keine PLZ-Relation gegeben und kein postal_code_level getaggt sind.

Laut Post gibt es in DE 8208 Zustellgebiete.
Insgesamt sind 8207 PLZ erfasst. Fehlte also eigentlich nur noch eine PLZ, wenn denn keine falschen dabei wären!
Lücken bestehen noch in Düsseldorf. Dort fehlen 17 PLZ-Gebiete: 40210, 40212, 40213, 40215, 40217, 40219, 40221, 40223, 40225, 40227, 40229, 40231, 40233, 40235, 40237, 40239, 40591.

Ergo: Keine Änderung zu gestern (habe allerdings heute bereits 2 ungültige PLZ aufgespührt und korrigiert: 01827 Graupa und 02744 Oberoderwitz)

Hallo zusammen,

ich habe mich mal der 40591 angenommen ;). Bei der Gelegenheit sind direkt noch ein paar Adressen mit falscher PLZ auf meine TODO-Liste gewandert…

Alex (Athemis)

Status quo der deutschen PLZ in OSM (13.11.2013, ca. 21:00 Uhr):
Es gibt 6130 dedizierte postal_code-Relationen.
Für davon nicht erfasste PLZ gibt es 1072 PLZ-getaggte Admin-Relationen mit postal_code_level=8.
Außerdem gibt es noch 1005 Gemeinden, die einen postal_code-Tag haben, für die aber keine PLZ-Relation gegeben und kein postal_code_level getaggt sind.

Laut Post gibt es in DE 8208 Zustellgebiete.
Insgesamt sind 8207 PLZ erfasst. Fehlte also eigentlich nur noch eine PLZ, wenn denn keine falschen dabei wären!
Lücken bestehen noch in Düsseldorf. Dort fehlen 15 PLZ-Gebiete: 40212, 40213, 40215, 40217, 40219, 40221, 40223, 40225, 40227, 40229, 40231, 40233, 40235, 40237, 40239.

@Athemis: Vielen Dank für 40591 Düsseldorf!

Ich werde mich der PLZ 40212, 40213 und später 40215 annehmen.

Ich hab mal versucht, die Sache mit QGIS zu visualisieren:

groß: http://osm.wno-edv-service.de:8080/DataServer/osm/forum/plz_overlay1.png

groß: http://osm.wno-edv-service.de:8080/DataServer/osm/forum/plz_overlay2n.png

groß: http://osm.wno-edv-service.de:8080/DataServer/osm/forum/plz_overlay2s.png

Gelb: PLZ an boundary=postal_code
Blau: PLZ an boundary=administrative
Grün: beides

an manchen Stellen “schimmert” OSM durch; da ist nichts erfasst oder es liegt ein MP-Fehler von. (z.B. bei Grünstadt/Pfalz war das MP defekt, ist aber inzwischen erledigt und die Lücken in Düsseldorf und im Bayrischen Wald bestehen weiterhin)

Ich werde wohl in meiner PLZ-Karte entsprechende Anpassungen machen, falls Interesse daran besteht.

Gruss
Walter

Vielen Dank, Walter!

Die gestern zerstörten Grenzen bei Luxemburg (PLZ 54441) habe ich heute morgen gefixt.

In Bayern sind drei Seen gemeindefrei. Für eine volle Abdeckung (auch im Hinblick auf eine PLZ-Regionenkarte) müsste man die einer Region zuschlagen. Die Post macht das in ihrer Karte auch so.