Hallo, vielerorts gibt es massive Probleme mit Grenzen. Ich habe daher einige Fragen, die ich nicht so einfach im Wiki beantwortet finde.
Ist die Relation “Multipolygon” für eine Grenze unbedingt erforderlich?
Wie wirkt sich die Relation “Multipolygon” auf die Datenbank aus?
kann ich falsche Datenbankeinträge manuell löschen?
Beispiel: “Kirchstraße, Limbach-Oberfrohna” wird mit der Postleitzahl von Hartmannsdorf gefunden.
Ich habe eine redundante Grenzenrelation von Limbach-Oberfrohna, die fälschlicherweise um Niederfrohna herum ging und ohne Postleitzahlinformation war, entfernt. Jetzt will ich noch die Grenzen von Hartmannsdorf untersuchen.
Wichtigste Frage: Wie wichtig ist die Multipolygon-Relation, die gar nicht bei allen Grenzen vorhanden ist? Ist die eventuell veraltet und kann entfernt werden? Aus meiner Sicht ist die Grenzenrelation vollkommen ausreichend.
Wenn die Relationen ansonsten identisch sind (gleich ways enthalten, etc.) dann kann man eine Löschen.
Aber wie gesagt, ein Beispiel wäre hilfreich.
Die Nummer der Relation sollte im Editor (zB JOSM) angezeigt werden, oder Du schaltest auf osm.org den Datenlayer ein und
klickst Dich durch.
Das kann, muss aber nicht mit den OSM Daten zusammen hängen.
Du kannst auch mal die OSM-eigene Suchfunktion nominatim probieren. (Suchfeld auf openstreetmap.org).
Mit Ctrl+Shift+I wird die Seite sogar gleich im Brauser geöffnet.
Sie zu korrigieren hätte ich besser gefunden als sie zu löschen.
Auch wenn ich damit nur Chris’ zweifache Aufforderung wiederhole: Gib mal ein Beispiel. Ansonsten kann Dir niemand sagen, ob beide äquivalent sind und somit eine überflüssig ist. Ehrlich gesagt halte ich das für ziemlich unwahrscheinlich. Der Große-Multipolygone-Klagelied-Faden hat übrigens nichts mit Grenzen zu tun.
In dem Relationseditor von JOSM wird die Relationsnumer in der Titelleiste des Fensters angezeigt, dort habe ich sie jetzt mal abgeschrieben. Normalerweise bin ich ein Freund von Copy und Paste
Relation auswählen, Ctrl+C drücken und anderswo einfügen.
PS. Die dritte der verlinkten Relationen ist tatsächlich gelöscht und lag zuvor in Japan.
PPS. Gemeint war wohl diese: http://www.openstreetmap.org/browse/relation/1295917 Und nein, einfach löschen ist nicht. Die eine ist eine admin-Grenze, die andere eine PLZ-Grenze. Man könnte letztere löschen, wenn zugleich die PLZ an erstere übertragen wird. Korrektur: Die PLZ steht schon an der admin-Grenze. Somit kann die reine PLZ-Relation in diesem Fall tatsächlich weg.
Ok, das ist interessant. Ich möchte nur gerne wissen wie sich die Grenzen auf die Datenbank auswirken und wie die falsche Postleitzahl in ost-Limbach-Oberfrohna entstanden ist.
Ok. Wenn die Admin-Grenze besser ist, kann das PLZ-Multipolygon entfernt werden. Allerdings - wenn die Relation nicht für Fehler sorgt, kann man sie auch lassen. Im Mapfactor Navigator geht die OVI Suche für Hartmannsdorf korrekt.
Wahlbezirke: Landtag 2012, Kommunalwahl 2012 (Stimm- und Wahlbezirke),
Bundestagwahl 2013, Landtagswahl 2014.
Als elftes kommen noch die Postleitzahl-Gebiete dazu.
Ach ja, jedes Grenzstück wird natürlich zweimal in Relationen verwendet (die eine und die andere Seite).
Die Postleitzahl-Gebieten sind oft als Multipolygon ohne Name definiert. Die sollte man wegen ihres anderen Inhalts jedoch nicht löschen.
Ja, die Löcher dort hatte ich auch gesehen (und ein paar davon gestopft). Erzeugt hat sie der User, der OSM um die Bonner Wahlbezirke bereichert hat (und munter weiter bereichert). Vermutlich der übliche Fehler: nur die Wege geladen, nicht ihre Elternrelationen. Es entstehen auch immer noch defekte Relationen, Beispiel, größeres Beispiel.
Angeschrieben hast du ihn schon? In JOSM lässt sich das ja einfach verhindern, in Merkaartor bestimmt (lies: hoffentlich) auch. Zumindest in JOSM sollte man dazu auch noch alle(!) angrenzenden Ways laden um die richtige Reihenfolge zu erhalten (ist bei Grenzen aber nicht ganz so wichtig wie z.B. bei Strassen).
Falls er nicht reagieren sollte würde ich hoffen, dass die DWG da etwas tun könnte. Nach einem netten Hinweis, dass man etwas falsch (und damit andere Daten kaputt) macht, kommentarlos weiterzumachen würde ich jedenfalls als (leichten) Vandalismus ansehen.
Immer langsam, es handelt sich a) um einen erfahrenen Mapper und b) fast nur um neue Relationen. Der macht das schon einigermaßen ordentlich und vor allem er kontrolliert (genau wie ich) mithilfe von OSMI ob das auch alles in Ordnung geht. Beim Reparieren ist mal er/sie, mal ich schneller. Also zwar etwas lästig aber in diesem Fall kein Grund zu voreiligen Handlungen.
@chris66:
Über die Benennung muss man in der Tat mal reden. Das “Stimmbezirk xyz” ist in der Tat etwas lästig, da es zum Teil andere Beschriftungen verdrängt. Ich werde das beim Stammtisch nächste Woche mal zur Sprache bringen.
Wie auch immer: Beim Reparieren gibt es meist auch ein wenig ‘Beifang’, den ich bei der Gelegenheit gleich mit verbessere.
Ok, dann ist es nicht so schlimm wie es sich zuerst anhörte. Sollte es auch “normale” Grenzrelationen betreffen sollte er jedoch etwas finden um das vor dem Hochladen zu korrigieren. Wenn er das kurz danach selbst repariert ist es imo aber nicht so dringlich, dass jemand “kraftvoll” nachhelfen müsste.
Na, dann ist ja gut - allerdings hatte ich bislang einen komplett gegenteiligen Eindruck. Als ich neulich den großen OSMI-Fleck namens Bonn entdeckt habe, waren ausschließlich Bestandsrelationen (admin, PLZ) kaputt und es deutete nichts darauf hin, daß der Mapper selbst sich um seine Fehler kümmerte.
PS. Aktuell sind von den Bestandsrelationen u.a. Bornheim und Dransdorf kaputt, den ebenfalls zerschossenen Rhein-Sieg-Kreisscheint der Mapper gestern tatsächlich selbst geflickt zu haben hat er nicht.
Ich bleibe dabei: das ist auf der Karte hässlich! Wieso kriegen die Dinger einen name=…, wo sie doch schon die eindeutige ref=… haben, und man den Namen in Note=… oder comment=… packen könnte?
Note=* wäre zu bevorzugen, da dann der ‘Name’ aus der note=* in der Relationsliste von JOSM angezeigt wird. So wird das bei den PLZ-Bereichen gemacht. Nachteil dieser Lösung ist, dass note=* in einigen FIXME-Layern für Garmin angezeigt wird.
Naja, die Wahlkreise/Stimmbezirke heißen schon so, name ist also nicht falsch. Es handelt sich auch um echte Namen: sie lassen sich im allgemeinen nicht eindeutig aus anderen Gegebenheiten ableiten, sondern sind mehr oder weniger willkürlich festgesetzt. Daß das Ergebnis in auf der Mapnik-Hauptkarte ziemlich bescheiden aussieht, ist kaum zu bestreiten - ist aber eher ein Symptom von Mapniks Nominitis.
Dem stimme ich voll zu, jedoch würde ich es für sinnvoll halten, wenn wenigstens das Wort Wahlkreis/Stimmbezirk etc. immer im Name enthalten wäre, was aber in Bonn schon der Fall zu sein scheint. Alternativ könnte man auch einen Key für ein Name-Prefix definieren, den Mapnik allerdings noch lernen müsste.
Am besten wäre, man würde sich darauf einigen, dies wo noch nötig per Bot hinzufügen. Technisch wäre dies doch wohl möglich, oder fehlen da wichtige Informationen?
Damit würde man dann z.B. vermeiden, dass in der Karte z.B. eine Grenze Hamburg-Nord Hamburg-Wandsbek auftaucht, die aber nicht mit Grenze zwischen diesen Bezirken übereinstimmt. Ausserhalb eines expliziten Wahlzusammenhangs würde man z.B. unter Hamburg-Nord wohl nicht den Wahlkreis, sondern nur den Bezirk verstehen.
