Shapes mappen (Wahlbezirke)

Communities Deutschland (Germany)
21

Vertrauen ist gut, Kontrolle ist besser:

hab aber noch 220 Wahlkreise (boundary=political, political=election) in DE gefunden.

willst du die Liste? 219 in Bonn und einmal Ulm.

Gruss
walter


3215389,3215406,3215390,3215408,3215409,3205723,3203342,3203344,3205565,3203345,3203243,3205563,3205592,3219608,3203158,3205688,3205684,3205687,3205588,3205590,3215405,3213633,3213637,3213614,3213613,3213612,3213611,3213588,3213589,3213602,3213603,3211366,3213601,3213587,3213631,3213590,3216951,3216873,3216872,3216870,3216789,3216790,3217118,3217116,3217174,3211368,3216788,3216766,3216763,3215404,3215410,3215385,3215386,3213533,3213532,3203312,3203314,3217081,3216953,3213615,3213641,3216954,3216950,3216952,3216871,3216955,3213640,3211367,3211363,3211223,3210870,3210868,3210758,3182493,3182507,3217082,3215481,3203244,3211161,3215480,3217117,3210867,3213638,3205591,3217175,3217173,3217172,3217171,3217170,3217115,3217079,3216787,3215485,3217078,3216786,3216785,3216791,3216764,3213632,3215483,3215482,3213639,3213635,3213642,3213636,3213634,3203241,3182510,3205685,3205589,3203242,3182421,3182509,3182492,3182491,3182508,3182157,3180298,3180212,397325,397323,389527,3205724,3210706,3211160,3215388,3211034,3210756,3210707,3210709,3210705,3205716,3210704,3205715,3210708,3205720,3180297,3213530,3210871,3210759,3203106,3210757,3211033,3210755,3213599,3213600,3211364,3213531,3182418,3203024,3205721,3215484,3182156,3203173,3203175,3216765,3216762,3205712,3217080,3205713,3205722,3205711,3205714,3205686,3205689,3203156,3203155,3203154,3203157,3180213,3180214,3215387,3215407,3211162,3211222,3211219,3211036,3210760,3203119,3203118,3181921,3181282,3205564,3201733,3202962,3211220,445433,3211365,3211221,3211163,3210869,3211035,3182417,445436,3182158,3182330,3203645,3203047,3203174,3203178,3217077,3217076,3213610,3182420,3203177,3210761,3182159,3211224,3182331,3203343,3203341,7129051,3182419,3213591,3182416,3213534,3203313,3203176,389497,175067
22

Danke, Walter, für die Liste. Ich werde sie jetzt noch nicht löschen. Ich hatte damals nur Bundestagswahlkreise gelöscht.

23

Mal eben etwas Klugscheißen, damit’s nicht untergeht:

Nein, die Daten liegen in EPSG:25833 vor. Aufgrund eines ultra nervigen Fehlers in QGIS werden EPSG:25832 und EPSG:25833 nahezu immer als EPSG:3044 und EPSG:3006 interpretiert. Das hat u.a. mit der Reihenfolge zu tun, in welcher die EPSG-Code-Datei geführt wird und wie die Parameter daraus übernommen werden. Ich hatte schon massive Probleme damit, aber bei QGIS kann oder will es keiner fixen. Aus geodätischer Sicht ist dieser Fehler fatal, da u.a. Ordinate und Abszisse gedreht sind und Programme, die ein wenig komplexer als QGIS sind, fliegen einem dann regelmäßig um die Ohren.

GDAL (ogr2ogr) interpretiert die PRJ-Dateien übrigens korrekt.

24

Viele Dank für die Aufklärung. Ich hatte mich schon gewundert, da ja in den Hinweisen zu dem Datensatz steht:

Aber QGIS hat das immer als EPSG 3006 interpretiert.

Maas

25

@wambacher @Nakaner
Dann solltet ihr konsequenterweise auch gleich den Wiki-Artikel löschen. Der verleitet sonst nur zu weiterem mapping von Wahlkreisen.
http://wiki.openstreetmap.org/wiki/DE:Wahlkreise

Maas

26

Yop, ist ein nerviger Bug. Ich führe das kurz mal aus, auch wenn’s Offtopic wird.

EPSG:3006 und EPSG:25833 werden von QGIS (oder Proj4 - keine Ahnung) intern wie folgt behandelt:

+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

Beim Lookup geht QGIS (oder Proj4 - keine Ahnung) dann die interne Liste durch und endet bei EPSG:3006, weil’s weit vor EPSG:25833 in der Liste steht.

27

Genau so. Der “richtige” Weg ist natürlich eine Frage der Filterung und Priorisierung. Zuerst würde ich schon mal alles rausschmeißen, was sich nicht wirklich zum Andocken eignet. Es kommen also nur Ways in Frage, die auch relativ beständig sind. Mir fallen da spontan erstmal Straßen, Wege, Pfade, Eisenbahnlinien, etc. ein. Die Ways von z.B. Häusern würde ich hinten anstellen oder eher ganz rausschmeißen aus der Auswahl. Und wenn es dann immer noch mehrere Möglichkeiten gibt kommt nach der Filterung die Priorisierung. Also zuerst wurde geschaut, was überhaupt ein Minimum an Beständigkeit aufweist und danach wird eine Liste gemacht was am Beständigsten ist. Dann kommt die Frage Prio-Liste vs. Entfernung vs. Abweichung vom ursprünglichen Pfad (Neigung/Richtung). Da sehe ich eher die Schwierigkeit, könnte aber über ein Punktesystem geregelt werden. Das sind am Ende eine ganze Menge Berechnungen, aber Computer sind ja zum arbeiten da, nicht zum Lüfter drehen.

Maas

28

Wäre ich absolut dafür.
Mindestens ein Hinweis, dass das Mappen von Wahlkreisen umstritten ist, sollte da rein.

29

Was mir an der Betrachtung komplett fehlt, ist, dass OSM kein Softwareprojekt, sondern ein Community-Projekt ist, und es nicht Zielsetzung ist, per Bot irgendwelche Daten möglichst redundanzfrei in die Datenbank zu kippen, egal, ob die restlichen Daten dadurch komplett unwartbar für die normalen Mapper werden. Einfach mal etwas hier im Forum recherchieren…

30

Wenn man Abschnitt 1 der Import-Richtlinie beachtet und dafür nicht nur ein paar Stunden, sondern ein Jahr aufwendet und hier im Forum mitliest, wird man verstehen, was mmd meint, aber nicht ausspricht. Wer Grenzen importieren will, solltet tatsächlich ordentlich Erfahrung mit OSM haben!

Zudem sei noch in der Wahlkreisfrage angemerkt, dass OSM kein kostenloser Geodatenhoster ist. Man kann problemlos die Shapefiles auch auf seinem eigenen Webserver hosten. Zudem spart man sich dann das aufwendige Konvertieren von/aus dem OSM-Format.

31

Natürlich ist OSM kein Softwareprojekt. Es ist ein Datenprojekt. Das wird allerdings mit Hilfe von Software gefüttert. Und umso besser die Software, umso besser die Daten (ganz allgemein gesagt).
Und in der Import-Richtlinie habe ich jetzt auch nichts gegenteiliges gelesen. Es geht halt hauptsächlich darum, dass Daten, die über Jahre mit hohem Aufwand und hohem Detailgrad eingepflegt wurden, nicht durch automatische (dumpfe Haudrauf-)Imports zerstört werden sollen. Das halte ich für eine Selbstverständlichkeit. Entsprechend muss die Software und die Konfiguration dieser angepasst werden, sowie Absprachen getroffen werden. Deshalb verstehe ich die ganzen Einwände nicht wirklich…aber ich lese ja auch noch nicht lange mit.

Zum generellen Verständnis von OSM habe ich bisher rausgelesen, dass es im Grunde zwei Fraktionen gibt. Die einen sagen “back to the roots”: nur das Nötigste und vor allem nur physisches am Boden. Die anderen sehen das eher als eine Art “Geo-Wikipedia”: Umso mehr, umso besser.
Habe ich das im großen und ganzen richtig verstanden?

Maas

32

Ja, wenn du es auf diese zwei Fraktionen runterbrechen bzw. zusammenfassen willst, ja, dann hast du es im großen und ganzen richtig verstanden. Du kannst aber ganz allgemein auch noch die Fraktionen der Puristen und Pragmatiker und Theoretiker und und und hinzufügen :wink:

33

Zur Klarstellung: Ich habe an einen ähnlichen Algo gedacht bei der Fragestellung, wie man einen Radweg, der nahezu parallel zu einer hw=primary läuft, von anderen unterscheiden könnte. Weil ich solche Wege gar nicht gerne entlang fahre. Ging also nur um maschinelle Auswertung, nicht um Imports.

34

Mach dazu bitte einen neuen Thread auf. Shapes->OSM-Polygone ist eine knifflige aber machbare Sache. Ob die auch sinnvoll sind, hängt von vielen speziellen Eigenschaften ab.

Aber bitte hier nicht.

Gruss
walter

35

Done.

Wiki ist nicht gerade meine Leidenschaft. Wenn das also jemand ein wenig optisch aufwerten will, gerne.

Gruss
walter, auf einen Shitstorm wartend :wink:

36

Ob du’s glaubst oder nicht: Dafür hatte ich eigentlich diesen Thread hier aufgemacht. Mein Hauptthema war nicht Wahlbezirke, sondern das Tool.
Aber egal. Ich lasse das lieber. Ich habe schon gemerkt, dass das böse Auto-Importen ein ganz heißes Eisen ist. :smiley:

Maas

37

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:

38

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

39

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

40

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.