boundary=nuts, nuts2=xxx oder ähnlich gefällt mir ganz gut. Nur gerendert werden die dann nicht mehr, aber damit kann ich prima leben.
Das siehts du richtig und daher sollten wir mit gutem Vorbild vorangehen. Ich schau mir das morgen mal an.
Das Wiki ist schon lange nicht mehr meine “Bibel”, da manche Sachen uralt sind und sich Situationen/Sichtweisen schon mal ändern können.
Gruss
walter
Da ist jeder mit gefordert, Aktivität zieht Aktivität an. Du hast sicher ein paar Grenzenartikel im Hinterhof die man beenden könnte…
Moin,
hier die aktuelle Missing Boundaries-Auswertung: http://osm.wno-edv-service.de/index.php/10-osm-reports/246-countries-compare-2015-07-08
Datenstand 00:31 heute früh.
Gruss
walter
Ich würde sie lieber gar nicht wirklich “mappen”, weil das nur Spam ist bzw. immer kaputt geht. Einfacher wäre es, wie teils bei den Wahlkreisen, nur Relationen mit Parts zu definieren.
Da kann man dann zwar nicht einfach “ist in NUTS-Region xy” anfragen, aber das ist ein eher simples Toolproblem, wo mir die Datenqualität wichtiger wäre.
Und: Unterscheiden die sich wirklich so sehr von den (ehemaligen) Regierungsbezirken?
. Spam? Versteh ich nicht.
Grübel Grübel: was ist denn bei den Wahlkreisen anders? Das sind Rels, die zwar “unbeliebt” sind und öfters “leiden”, aber technisch ist da doch kein Unterschied, oder?
Kann ich auch nicht nachvollziehen - aber eventuell liege ich ja völlig daneben.
Noch was zum “Projekt”: Richtig scharf bin ich auf NUTS nicht, aber es stellt sich für mich so dar, dass manche Grenzen, die wirklich nicht adminitrativ sind (mMn weil sie keinen ISO3166-2 Code haben), damit aus den Administrativen Grenzen verschwinden könnten, aber dennoch in OSM vorhanden sind. Halt als boundary=nuts o.ä.
Wir haben weltweit die Situation, dass Administrative Grenzen und - ich nenne es mal “Regionen, die eine Struktur vortäuschen, aber keine Verwaltungsgrenzen sind” - alle unter einer Flagge laufen. Klar ist das so im Wiki definiert aber wer hat sich vor vielen Jahren darüber Gedanken gemacht? Ein wenig Scheu habe ich schoin, das anzufassen, deshalb taste ich mich mal ran - und das am besten in “userem Revier”.
So wie ich die ISO3166-2 sehe, ist dort die Struktur der Grenzen für jedes Land weltweit eindeutig definiert - Disputed Areas ausgenommen. Und darauf möchte ich aufsetzen.
Gruss
walter
PS: Beim Durchlesen vor dem Posten beginne ich zu ahnen, was du mit “Relationen mit Parts zu definieren” meinst. Das sollte doch kein Problem sein. Gib mir mal ein Beispiel, da ich mir da noch nicht sicher bin.
Hallo Walter,
es gibt in DE Wahlkreise, die durch ihren Umriss definiert sind (wie admin-Grenzen), und solche, die nur durch ihre Teile definiert sind (enthaltene Gemeinden als Rel-Member mit Rolle Part). Keine Ahnung, wie es dazu gekommen ist.
GIS-technisch könnte man bei letzteren dann nicht z.B. fragen “Region/MP enthält Punkt”, sondern müsste anfragen “Region hat Teil, der Punkt enthält”. Einfacher wäre natürlich, wenn osm2pgsql das von Haus aus könnte (in ein MP übersetzen würde).
Ich will nur Grenzsegmente vermeiden, wo logisch redundant zig Relationen dranhängen (“Spam”), wenn es auch viel einfacher und robuster ginge. Ich will damit nicht sagen, dass nicht-administr. Regionen gar nicht in OSM gehören.
Viele Grüße
Jan
Andererseits bin ich immer mehr der Auffassung, dass Grenzen gar nicht gleichberechtigt in die reguläre OSM gehören, weil es oft unnötige Lizenzprobleme gibt und wie man hier doch sieht, andauernd Leute etwas kaputtmachen (absichtlich oder auch nicht), oder (abstrakte) Grenzen mit (konkreten) Objekten wie Straßen, Eisenbahnschienen etc. verkleben.
EDIT: Typo
ISO3166-2 geht nur eine Stufe unterhalb der Staatsgrenzen, in DE also die Bundesländer.
Über die anderen Level bis hinunter zu AL8/9 sagt der Code nichts aus.
Selbst ohne Wahlkreise und NUTS-Regionen bleiben auch bei den admin-Grenzen in DE einige Sonderfälle, die in die weltweite OSM-AL-Klassifizierung nicht hineinpassen.
Die müssen dann als boundary=administrative ohne admin_level getaggt werden. Auf “Lösungen” a la admin_level=x.5 möchte ich verzichten.
In BW sind das die Regionen, die zwischen den Kreisen (AL6) und den Regierungsbezirken (AL5) liegen.
Da gibt es welche, die sogar ein direkt gewähltes Kommunalparlament haben, andere sind nur konsultativ (z.T. länderübergreifend) ohne administrative Kompetenzen.
Da bleibt ein weites Feld für Interpretationen, ob nun admin oder nicht.
Aber wenn mit ISO3166-2 wenigstens die Stufe unter den Staatengrenzen einheitlich festgelegt wäre, wäre das ja auch schon was.
(Auf die Zuarbeit eines HiWis an einer Uni würde ich aber nicht zuviel Zuversicht setzen.)
kann osm2pgsql das immer noch nicht? muß ich mal prüfen - und dazu eine der komischen Rels suchen, die du mir mühsam verheimlichst 
Ja deine Vorbehalte wegen “Umwartbarkeit” kenne ich und teile sie auch (ein wenig). Nur der Begriff “Spam” dafür sagte mir nix.
Gruss
walter
Hab mal recherchiert:
relation/2959029 (Sammelrelation für alle Wahlkreise der Art)
relation/2959367 (nur ein Part, da identisch mit Kreis)
relation/2998725 (mehrere Parts)
omg - das darf doch nicht wahr sein. nun denn, ignorieren wir die einfach mal.
Da diese Rel kein type=boundary hat, wird sie von osm2pgsql verworfen. Da hilf auch kein “part von”.
Dito. type=election ist zwar nett, aber absolut sinnlos.
osm2pgsql speichert nur Relationen mit type=route, type=multipolygon oder type=boundary in der PostGIS-DB ab. Alle anderen “Exoten” werden ignoriert.
/* Only a limited subset of type= is supported, ignore other */
if ( (*type != "route") && (*type != "multipolygon") && (*type != "boundary"))
return 0;
Daher fehlen die Wahlkreise total in der DB - unabhängig von Part oder nicht. Die lassen sich damit auch nicht mit Mapnik & Co rendern oder mit QGIS darstellen. Overpass ist möglicherweise was anderes, aber das steht hier nicht zur Diskussion.
Gruss
walter
ps: Ich suche mir mal ein anderes Beispiel für verschachtelte Relationen; Wahlkreise sind dafür ungeeignet.
pps: Eventuell errinnert sich noch jemand an die Diskussion über die Umweltzonen? http://forum.openstreetmap.org/viewtopic.php?pid=446446#p446446
Genau deshalb habe ich auf damals auf type=boundary, boundary=low_emission_zone bestanden.
Ich bin den Relationen mit “Part” oder auch “outer” nachgegengen - es funzt nicht. Es ist auch so nicht in Josm vorgesehen und wird dort als fehlerhaft angemosert.
Daher werde ich die Nuts testweise nur als “richtige” Relationen mit den äusseren Ways als Member erfassen. Alles andere bringt nichts.
Ich habe extra eine Test-Datenbank neu aufgesetz, eine Nuts-Rel mit Part/outer erzeugt und das allerneueste osm2pgsql (0.87-dev) verwendet; nicht dass die Entwickler diese Funktion klammheimlich eingebaut haben 
Was ich übrigens für gut halten würde.
Gruss
walter
Moin,
hier die aktuelle Missing Boundaries-Auswertung: http://osm.wno-edv-service.de/index.php/10-osm-reports/247-countries-compare-2015-07-09
Datenstand 00:39 heute früh.
International scheint alles ok zu sein bis auf zwei"dicke" AL4 auf den Philppinen und der übliche Kleinkram.
Gruss
walter
Hmpf, ich habe in den letzten beiden Tagen ein paar fehlende ISO3166-2-Codes eingetragen und dabei auch ein paar kleingeschriebene Tags auf Großschreibung geändert, da die großgeschriebenen ISO-Tags in der Datenbank ziemlich eindeutig in der Mehrzahl sind. Heute bekam ich eine Beschwerde, dass ich das nicht hätte tun sollen und alle “falsch” großgeschriebenen Tags in Kleinschreibung ändern soll: http://www.openstreetmap.org/changeset/32489537
Zur Unterstützung: Es gibt zwar in OSM die Regel, Begriffe klein zu schreiben, das gilt aber nicht für Eigennamen im Werte-Feld.
Als solche würde ich die Einträge in ISO3166-2 und erst recht -1 werten.
Das sollte man nicht mit dem Key-Feld verwechseln, wo sogar Unterschiede von DE zu de eine Bedeutung haben.
Der Standard sagt doch Großschreibung. “DE” Deutschland ( ISO 3166-2), “de” Deutsch (ISO 639-1)
Ich kann im Wiki nichts über die Schreibweise der Keys mit ISO finden; es ist nur definiert, dass das Value, also der Country-Code (DEU, AUT,…), gross geschrieben wird. Üblicherweise sind Keys aber klein. Als ich aber bei den AL2 vor 2-3 Jahren aufgeräumt habe, hat sich niemand drüber aufgeregt.
In den entsprechenden Texten ist ISO immer gross geschrieben, aber in den Beispielen klein.
Was tun? zurücksetzen? aussitzen? verteidigen?
Mein Vorschlag: einige Edits zurücknehmen und Gras drüber wachsen lassen. Man kann das natürlich auch ganz einfach in den Auswertungen/Listen mit if upper(key)==‘ISO3166-2’ abfangen.
alles umkrempeln geht natürlich auch.
Gruss
walter
ps: Neue Liste https://osm.wno-edv-service.de/Dataserver/osm/files/iso2.txt
Danke für die Klarstellung.
Hier geht es eindeutig um die Gebietsnamen [edit]als value[/edit].
Nein, es geht um ISO3166-2=DE-XX oder iso3166-2=DE-XX.
Gruss
walter
Ok. Ohne den Changeset anzuschauen, war das auf den ersten Blick nicht klar zu verstehen.
In diesem Fall bin ich gleichgültig.