siehe: http://www.openstreetmap.org/browse/changeset/18977684
Ich hab um Jossa herumgefummelt und muss da wohl mehrere Relationen zerschossen haben. Fakt ist, dass es Fehler am laufenden Band gibt und irgendwie alles ziemlich verworren ist. Wie groß der Schaden ist, kann ich nicht sagen; ich hab da nur ein paar Grenzen angepasst.
Ich schaue mir das mal schnell an.
Puh. Viele Relationen. Wird etwas länger dauern.
EDIT: War doch nicht so wild. Alles, was ich gefunden haben ist wieder heil.
Muss aber noch mal weiter prüfen.
Die Wahlkreise Hanau und Main-Kinzig - Wetterau II - Schotten überlappen sich offenbar. Das kann ich jetzt nicht klären.
Und ob das Grenz-Chaos bei Ober-Laudenbach so in Ordnung ist, vermag ich auch nicht zu sagen.
Wikipedia widerspricht unserem Umfang des Wahlkreises Hanau. Einer von beiden hat Unrecht - ich glaube eher, dass wir es sind.
Ist der andere denn korrekt? Dann würde ich das noch fixen.
BTW: Wahlkreise sind echt ein Ärgernis, wenn sie als Weg-Relationen definiert sind.
Wenn man Sie nur als Meta-Relationen aus anderen admin-Relationen zusammensetzt, stören sie mich überhaupt nicht.
Dann könnten von mir aus auch alle Wahljahre eine eigene Relationsgruppe haben.
Korrigiere: Da sich nicht nur Wahlkreise, sondern auch Verwaltungsgebiete ändern, wird es im Detail doch etwas unschön.
Aber dennoch: Ich plädiere dafür, sie zumindest als Wegrelationen abzulösen.
Main-Kinzig-Wetterau II-Schotten scheint korrekt zu sein. Nur der Hanauer Wahlkreis ist zu groß dimensioniert.
Habs mal geändert.
Nur so zur Info: Wer diese (noch nicht existierenden) Meta-Relationen wirklich benutzen/darstellen will, hat dann ein riesiges Problem, so er osm2pgsql zum Erstellen seiner Renderer-DB benutzt. Was wohl die große Mehrzahl derjenigen macht, die überhaupt rendern. osm2pgsql schmeißt Meta-Relationen (Relationen mit Relationen als Member) kommentarlos weg. (*)
Das hat allerdings einen kleinen Vorteil, da auch die Mapnik-Karte mWn mit osm2pgsql arbeitet: die Namen der Wahlkreise wären dann weg 
Gruss
walter
*) Hab vor kurzem auf osm2pgsql umgestellt und vermisse seitdem schmerzlich einige Meta-Relationen (z.B. 1111111 und D-A-C-H)
Das war hier schon Thema. Das ist tatsächlich so ein Durcheinander (Exklave in der Exklave, Straße zu Baden, Häuser zu Hessen).
Völlig OT: aber du hast schon mal “select tags from planet_osm_rels where id=1111111;” auf deiner DB probiert?
Die slim tables zu verwenden ist zwar etwas unfein, aber gängige Praxis.
Jo, da sind die Dinger natürlich drin - aber die slim-Tables sind bei mir nicht komplett.
planet.osm.nodes ist bei mir leer, da ich mit --flat-nodes arbeite. Und daher hab ich diesen Weg nicht weiter verfolgt.
Aber: die Geometrien der Member sind natürlich in planet_osm_polygon drin, und damit krieg ich die übergeordnete Geometrie wohl hin.
Danke, für den Tip. Du hast mich da wohl aus einer blöden Sackgasse geholt
Gruss
walter
Um mal zu erklären wieso es da gescheppert hat:
Ich wollte die Grenze von Sinntal bzw. Jossa mit der hessischen Staatsgrenze verbinden; dazu musste ich die bestehende Grenzlinie aufteilen und neu mit der Staatsgrenze verbinden. Das ist natürlich ganz schlecht wenn da noch Relationen daran hängen, da die dann zerstört werden. Die Grenzen von Jossa und vom Gutsbezirk konnte ich gerade noch so geradebiegen, durch den sehr, sehr irregulären Grenzverlauf in diesem Gebiet blickte ich dann aber gar nicht mehr durch, was noch wo kaputt ist. Ich glaube, dass man vor lauter Grenzen irgendwann den Überblick komplett verliert, ist verständlich.
Ich halte das Grenz-/Relationsthema auch für hochproblematisch und fehleranfällig (“error-prone”).
Insbesondere Potlatch und iD sind problematisch, wenn sie die oft nicht so erfahrenen Nutzer nicht einmal warnen, dass etwas kaputt ist/sein könnte.
Ich weiß, das ist technisch (derzeit) ein Problem (bzgl. Polygonen und so): Aber ich verstehe aus Modellsicht nicht, warum Grenzregionen, die sich definitiv aus anderen Unterregionen zusammensetzen, nicht auch genau so modelliert werden.
Ein Beispiel, wie es mMn sein sollte: Ein Kreis hat als Meta-Relation seine Gemeinden als “part” und das Bundesland hat wiederum Kreise oder Regierungsbezirke als part - keine ways. Mir erscheint das im status quo einfach nur redundant.
EDIT: Typos usw.
Diese Meta-Relation wäre eine Fläche. Die ist bei vektorbasierter Darstellung aber nur durch den Umriss definiert. Die könnte man theoretisch auch “zusammenwerfen”, müsste dann aber alle Innenlinien per Automatik eliminieren. Das würde in Gegenden wie Ober-Laudenbach auch eine ziemliche Herausforderung.
Aber es hilft nichts: Diese Entscheidung für ways als Mitglied von Relationen bei Grenzen wurde bei OSM eben relativ früh so getroffen, das ist ziemlich sicher nicht mehr rückgängig zu machen.
Das ist relativ einfach zu erklären: Das Modell ist von ca 2007 und du bist 2014 eingestiegen.
Gruss
walter
Eigentlich bin ich seit 2011 sehr aktiv. Aber im Forum erst kurz, ja. Bis 2011 habe ich promoviert. Da blieb wenig Zeit für OSM und “Ablenkung” im Forum.
Erstmal nimmt man als OSM-Nutzer ja alles als gegeben und “muss-halt-so” hin. Aber seit ich intensiver mit den Daten arbeite und fast jeden Tag zerstörte Grenzrelationen (nur in DE! Heute z.B. in Erfurt) flicken muss, fange ich halt an, manches zu hinterfragen.
Ich glaube, das ist gar nicht sooo ein riesen Problem mit den Polygonen. Die Polygone von Relationen müssten halt rekursiv erstellt werden. Entstehende Innengrenzen zu eliminieren, ist recht einfach.
Das Datenmodell muss dazu ja auch gar nicht verändert werden; Meta-Relationen gibt es ja auch längst. osm2pgsql müsste aber lernen, diese zu verarbeiten…
Das Problem ist m.E. die Verknüpfung der Grenzen mit anderen Wegen (Waldgrenze, Flüsse, Straßen). Wird dort ein Stück geändert geht meist etwas in einer Relation kaputt.
Ja das passiert recht oft, aber nicht sehr oft. Am häufigsten sind “Grenzkorrekturen”, bei denen Grenzwege nicht oder nicht richtig aufgespalten werden. Oft werden Grenzwege auch einfach gelöscht.
Ich müsste mal eine Statistik führen.