Krieg ich wohl hin, aber dann müssten wir alle - also nicht nur wir beide - uns einig sein.
Gruss
walter
Es geht nicht nur um PLZ - dort wurde es bloß zuerst eingeführt. Auch bei einem landuse=farmland-Multipolygon “Äcker um Hintertupfistan” ist es praktisch, dieses in der Relationsliste leicht identifizieren zu können. Ausgerechnet note dafür zu verwenden ist sicherlich nicht die beste Wahl, weil ein sinnvoller Gebrauch so blockiert wird. (Ich gestehe: von mir eingetragene PLZ-Relationen tragen auch note=*.) Etabliert wurde diese Verwendung von note freilich durch einige wenige Änderungssätze, von denen dieser (“… wird nicht gerendert”) der größte und letzte war. Auf der Wikiseite tauchte der Vorschlag etwa gleichzeitig auf.
Man muß diese andere Lösung nur definieren. fake_name, editor_display_name, bogus_name, … letztlich ist es mir egal, wie der Schlüssel aussieht.
Mit dem Unterschied, daß eine Stadt (etc.) im Gegensatz zu “Äcker um Hintertupfistan” tatsächlich einen Namen hat.
Edit: Link korrigiert.
Jup. Aber es scheint ja bisher keiner hier wirklich der Meinung zu sein, dass es keine dedizierte postal_code-Relation geben darf, wenn die admin-Relation zufällig passt.
Einige halten es aber für unnötig.
Übrigens, wenn alles auf postal_code-Relationen umgestellt wäre, dürfte doch auch ein postal_code in einer admin-Relation nicht mehr stören. Die würde dann ja eh ignoriert.
ich könnte auch gut mit einer Lösung leben, welche für alle Gebiete eine eigene PLZ-Relation vorsieht.
Begrüßen würd ich es, wenn wir ein Konzept gemeinsam dafür entwerfen, verfeinern und dann auch im Wiki dokumentieren.
Stimmt, weil man sich dann als Auswerter darauf verlassen kann, dass man für “Post-Sachen” nur die PLZ-Relationen braucht. Derzeit sind alle meine Queries (auch in der PLZ-Karte) so geschrieben, dass sie beides berücksichtigen - mit allen daraus entstehenden Problemen und Widersprüchen.
Aber dazu noch eine Frage, die ich mir bisher verkniffen habe: Was ist mit Nominatim? Bekommt der - und damit wir - Probleme?
Gruss
walter
Hallo Walter
Der Schlüssel description ist für eine textliche Beschreibung oder Hintergrund-Informationen eines Objektes. Der kann recht lang werden. Weiter ist es vorgesehen den Text in description irgendwann einmal den Kartennutzern anzuzeigen.
Zudem gehört er nicht zu den Schlüsseln, die JOSM bei der Benennung einer Relation nutzt. Eigentlich wäre ref=* ideal, jedoch erscheint dann nur eine wenig aussagekräftige Nummer in der Relationsliste, die man nur schwer als PLZ zuordnen kann.
Was die Postleitzahl-Relationen angeht, sollten wir es beim aktuellen Zustand belassen, wir sind schließlich daran gewöhnt.
Wir sollten allerdings mal einen Schritt zurücktreten und bemerken dann, dass generell ein Namens-Problem bei boundary-Relation besteht (siehe die Diskussionen zu Stimmbezirken). Das Problem besteht aus drei Teilen:
- Solche Relationen haben meist einen für Menschen erkennbaren Namen.
- Mapnik rendert standardmäßig die Namen aller Boundary-Relationen
Diese Namen will man aber oft nicht in der normalen Karte sehen. - JOSM benennt Relationen nach Name, Referenz-Nummer, Notiz usw.
Alle bisher vorgeschlagenen Alternativen scheitern an diesem Punkt.
Es gibt mehrere Ansätze, dieses Problem anzugehen:
- Mapnik ändern, sprich statt “Alle unbekannten Boundaries mit Name rendern”
zu “Alle unbekannten Boundaries nicht rendern” wechseln. - Etwas anderes als boundary verwenden (= neuer Relationstyp).
Wie Mapnik dann mit den Namen umgeht, ist jedoch unklar. - Etwas anderes als name=* für den Namen benutzen (= neuer Schlüssel).
Dann müsste man JOSM bitten, das für die Benennung in der Relationsliste aufzunehmen.
Alles leider voneinander abhängig und daher nicht einfach zu lösen.
Sinnvoll wäre auf jeden Fall eine allgemeine Lösung für diesen Problemkreis.
Edbert (EvanE)
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 
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?” 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)