Shapes mappen (Wahlbezirke)

Ja, ist ein wenig “schief” gelaufen.

Importe per Shapes sind durchaus machbar - wenn man die bei Importen zwingend notwendigen Bedingungen erfüllt.
Es sind z.B. viele Admingrenzen (*) in Mexico durch bessere ausgetauscht worden. War aber ein heftiger K(r)ampf, bis die das sauber hinbekommen haben. https://forum.openstreetmap.org/viewtopic.php?id=53721

Knackpunkte dabei:

  • Shapes sind Ringe, die sich an jeder Stelle (bis am Rand des Gebietes) überlappen. Da gib es immer 2 Wegstücke mit identischen Daten.
  • Es werden neue Daten erzeugt, die mit den bereits bestehenden Daten “verwoben” werden müssen.
  • oft müssen auch alte Daten - unter Beibehaltung der Tags - ersetzt werden.

Ich selber sehe mich trotz meiner Erfahrungen nicht in der Lage, das so zu machen.

Gruss
walter

*) sorry, ist nun mal meine “Nische” :wink:

Ja, da gibt es eine Menge Punkte die beachtet werden müssten. Vor allem beim “Verweben” der Daten würde es eine Menge zu beachten geben. Aber das Problem liegt eigentlich woanders.

Offtopic:
Ich denke letztendlich, dass das alles auf ein Problem zurück geht: das Datenmodell von OSM.
Es gibt keine Layer und das sorgt für so einige Probleme, nicht nur im technischen Bereich. Auch im “zwischenmenschlichen”, wie man an den vielen Diskussionen sehen kann, was denn nun in OSM rein gehört und was nicht. Das Thema wäre schlagartig vom Tisch, wenn es eine Layerstruktur geben würde. Dann gäbe es einen (oder ein paar wenige) Basislayer und viele zielgruppenspezifische Layer, die niemanden stören, der sich nicht dafür interessiert. So wie es jetzt ist, kann ich verstehen, dass sich die Leute aufregen, wenn ein Node mit 50 (für sie unnützen) Relationen verknüpft wurde, etc. Und da ja anscheinend das Thema Indoor-Mapping immer beliebter wird, frage ich mich, wie das dann werden soll. Da gibt es Gebäude mit mehreren tausend Punkten. Und das nur bei einem Gebäude. Was aber auch nachvollziehbar ist, wenn man jeden Raum und Flur und Etage erfassen will. Damit ist doch fast jeder Editor überfordert, wenn dann noch all die anderen Daten hinzukommen. Als Folge aus dem Problem, dass mit steigender Datenmenge die Übersichtlichkeit und Bearbeitungsfreundlichkeit sinkt, kommt es dann halt zu Reaktionen, dass bloß keine Nicht-Mainstream-Daten eingepflegt werden sollen. Und dann sind da noch die ganzen Tools, die ja auf das derzeitige Datenmodell 100% ausgerichtet sind. Das verhindert natürlich auch eine Änderung, da ja dann ein riesiger Rattenschwanz an Refactoring hinterher kommen würde.
Meine ganz subjektive Meinung: Ich denke, das aktuelle Datenmodell wird früher oder später entweder zusammenbrechen oder OSM wird in der Entwicklung stehen bleiben müssen, da das Datenmodell nicht mehr hinterher kommt.

https://forum.openstreetmap.org/viewtopic.php?pid=662068#p662068
Bei dem Post könnte ich fast jeden Satz unterschreiben.

Maas

Richtig erkannt. Nur gibt es derzeit niemanden der das Problem wirklich angehen möchte.

Das finde ich zu einfach. Diese Diskussionen gingen i.W. um die Darstellung der Namen in der Karte. Damals hatte Mapnik grundsätzlich alles mit “name=” dargestellt und die Diskussionen drehten sich um die Darstellung.

Besser finde ich das Argument aus der Changesetdiskussion, dass Daten, die eher zu 2013 als zu 2017 passen, als historische Daten raus sollten. Man kann hier (und sollte) darüber diskutieren, ob das ein (in OSM nicht seltenes) “Hinterherhinken” ist oder ob es “historische Daten” sind.

Ich würde das nicht unbedingt als Bug bezeichnen… Nur nervig ist das…

Da kommt man aber raus, wenn wenn man sauber mit den Daten umgeht…

QGis kann oder will ja leider nicht die Esri-eigene prj-Datei mit den entsprechenden Informationen lesen. Bei QGis hat man aber die Möglichkeit, im QGis-Browser bei der Shape-Datei das richtige KBS einzustellen, und zwar mit der Funktion “Layer-KBS setzen”.
Es wird dann eine qpj-Datei angelegt.

Für Berlin/Brandenburg mit EPSG 25833 steht dann drin:

PROJCS["ETRS89 / UTM zone 33N",GEOGCS["ETRS89",DATUM["European_Terrestrial_Reference_System_1989",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6258"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4258"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",15],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG","25833"]]

Das sollte man immer machen, oder zu mindestens immer vorher kontrollieren, gerade wenn mit Shape-Dateien arbeitet. Dann klappt auch sicher die OnTheFly-Transformation der Daten.

Das ist umgekehrt übrigens genauso… erst wenn ich mit ArcCatalog bei neuen Daten die ggf. fehlende Projektionsinformation nachgetragen habe, klappt alles sauber.

Übrigens sollt man auch immer mal den räumlichen Index aktualisieren…

Sven,

…der sich gelegentlich auch mit QGis beschäftigt.

Ok, lassen wir mal die Meta-Diskussion für einen Moment hinter uns. Für das Verweben von existierenden Ways mit neuen Ways gab es im letzten Jahr in Blogpost zu einem Tool “Cygnus” (siehe http://wiki.openstreetmap.org/wiki/Conflation → OSM-specific tools). Ich habe das selbst noch nicht ausprobiert und weiß nicht, wie gut das wirklich funktioniert. Vielleicht ist das Tool aber auch nur zum Hinzufügen / Updaten von Straßen geeignet. Es beschreibt aber zumindest vom Ansatz her eine Möglichkeit, das Thema anzugehen.

Danke für den Hinweis.

Jetzt braucht es nur noch ein Tool, dass die zu verwebenden Punkte anhand eines Shapes erkennt (inkl. konfigurierbarer Toleranz). :slight_smile:

Maas

Wäre es denkbar, die shapes als background image für alle Mapper bereitzustellen, falls das Lizenz-technisch überhaupt passt?
Noch besser wäre ein Layer, der anzeigt, wo in OSM evtl. was fehlt, ähnlich wie OSMI anzeigt, wo z.B. Geometrieprobleme sind.

Könntest du das etwas ausführen? Bin mir nicht sicher ob ich das verstanden habe.
Meinst du eine Art von Tile-Layer, damit man die Shapes manuell nachzeichnen kann?

Maas

Ja, so in etwa. Wenn ich Dich richtig verstanden habe, dann laufen Wahlkreisgrenzen entlang von Straßen, zumindest die Grenzen zwischenden Kreisen. Wenn die Daten zusätzlich auch noch ortographisch exakt sind, könnte man entweder danach abzeichnen oder Sat-Bilder ausrichten. Wenn die Grenzen aber auch irgendwo mitten durch Wälder oder Wiesen laufen, dann wäre das eher irreführend.

Beides. Zu 99% verlaufen die Grenzen entlang von Straßen oder Admin-Boundaries. Es gibt aber in den Randbezirken (hier Berlin) auch (Teil-)Strecken, die einfach durch den Wald verlaufen.
Das war ja der Ansatz meiner Frage, ob man das automatisieren könnte, da 99% der Strecken ja bereits gegeben sind und nur ein sehr geringer Teil neu hinzugefügt werden müsste.
Sicherlich wäre es möglich das als Grafik in den Hintergrund zu legen und dann alles zu zeichnen, aber bei ein paar hundert oder tausend Shapes, wäre eine (halb-)automatische Lösung wohl angebracht. Ich hätte nicht die Geduld für so viele Shapes und noch viel mehr Nodes. :slight_smile:

Dann kam aber auch noch die Frage auf (unabhängig von Wahlbezirken), ob es überhaupt sinnvoll ist, diese Shapes mit den Straßen-Ways/-Nodes zu verknüpfen.

Maas

Josm kann Shapes laden - natürlich :wink: Und die sind dann gleich als Datenlayer drin. Muss man ein wenig mit den Layern spielen und aufpassen, dass man die Shapes nicht einfach hochlädt.

Es muss wahrscheinlich das Opendata-Plugin installiert sein(*)

gruss
walter

*) wenn man erstmal ein Plugin installiert hat, ist es ziemlich schwierig herauszubekommen, welcher Plugin für welche Funktion “verantworlich” ist.

ps: die Ringe der Shapes sind NICHT geschlossen, sehen aber so aus. 1. und letzter Punkt liegen zwar übereinander, sind aber nicht miteinander verbunden. Muttu suchen und mergen (M)

Kann man bei JOSM auch die Strichstärke eines Layers ändern?
Ich hatte die Shapes auch schon mal als eigenständigen Layer reingeladen, hatte dann aber ein Problem mit der Übersichtlichkeit. Wenn man die Shapes in den OSM-Datenlayer lädt, gibt es dann Probleme mit dem anklicken der richtigen Ways. Mit Mittlere Maustaste + STRG geht es zwar letztendlich, ist aber sehr umständlich. War alles irgendwie nicht so der Bringer.

Maas

ja, aber frag mich nicht wie :wink: Man kann Styles für bestimmte Tags definieren und dann Farben und ähnliches setzen.
Da wissen die Kollegen sicher mehr.

edit: Einstellungen/Kartenstile ist der Weg.

Muttu “nur noch” einen eigenen Style erzeugen

Stimmt. s.o.

Gruss
walter

Super, wieder was gelernt :slight_smile:

Maas

Noch ein Tip, wenn jemand in beiden Welten (wie ich) arbeitet, Esri und QGis…

Bei QGis gibt es das Ärgerniss, daß es beim Festlegen des Koordinatenreferenzsystemes neben der einen *.qpj-Datei, die es erstellt, auch die vorhandene *.prj-Datei verändert. Da muß man mit ArcCatalog wieder nacharbeiten… :frowning: in meinen Augen ein sehr unschöner Bug…

Man darf erst nachdem man die Shapes im QGis Brower angepasst hat, im ArcCatalog das Referenzsystem anpassen… sonst handelt man sich Ärger ein.

Ich muß mal bei QGis ein Ticket setzen…

Sven

Kann man nun die Wahlkreise zur Bundestagswahl 2013 löschen? Im Wiki steht zwar, dass sie gelöscht wurden, das stimmt aber nicht, fast alle sind noch da.

Ich stoße bei meinen OSMI-Reparaturen auch immer noch regelmäßig auf Wahlkreise… ich scheue mich noch immer, diese zu löschen und repariere lieber erst mal…

Wenn gewünscht, kann ich die aber auch gleich löschen.

Sven

Hallo,

Die Löschdiskussion sollte in einem separaten Thread geführt werden, damit es allen, die betroffen sind oder sich betroffen fühlen, offensichtlich ist, worum es geht.

Ich hatte die Wahlkreise mal still und heimlich, aber technisch sauber gelöscht, bis es nach ein paar Wochen ihr Urheber gemerkt und den Revert gefordert hat. Ich habe mich im Juni (?) mit ihm mal darüber unterhalten und festgestellt, dass wir eine erheblich abweichende Meinung zur Definition der Übeprüfbarkeit haben, die in OSM das Hauptkriterium ist.

Da ich bislang Wichtigeres zu tun hatte, als die Löschung zu diskutieren, existieren sie noch.

Ich würde jedoch jedem raten, die Wahlkreise nicht zu reparieren, da es sich Dinge am Rande (oder jenseits) des Zwecks und der “Relevanzkriterien” von OSM handelt.

Viele Grüße

Michael

Dann mache ich mal einen neuen Beitrag auf.

Sven