besser machen? naja, aber einfacher geht es mit meiner Boundaries-Karte (siehe Signatur).
Gewünschte Grenzen links anklicken, Poly auswählen und Export drücken.
Gruss
walter
ps: was hast du denn mit den Polygonen vor? Eventuell sind die Polygone mit Buffer (bpoly) besser.
Kurze Antwort:
Ich habe mich neulich mit POI-Auswertungen beschäftigt (http://wiki.openstreetmap.org/wiki/L%C3%BCneburg/POI ist mein “Werk”) und möchte das in Teilaspekten auf das Gebiet der Metropolregion Hamburg (MRH) ausdehnen. Da ich an grenzscharfen Auswertungen interessiert bin, wäre Buffer - wenn ich das jetzt nicht missverstehe - eher kontraproduktiv )
Lange Antwort:
Da die Grenzen der Metropolregionen in Deutschland (ich arbeite bei einer, nämlich der MRH) zwar häufig auf staatlichen Regelungen (Staatsverträge, Verwaltungsvereinbarungen) beruhen, aber keinem administrativen Level entsprechen, gibt es kein “offizielle” Relation “MRH”. Die hätte ich aber prinzipiell gern, da nicht immer das Geoportal der MRH (http://geoportal.metropolregion.hamburg.de/) der richtige Platz für unsere Aktivitäten ist. Daher kam ich auf die Idee, die *.poly der Mitglieder der MRH in eine *.poly zu packen. Dann habe ich das nötige Rüstzeug, wenn ich mit osmconvert Auswertungen lokal fahren möchte (via overpass packe ich mir die (Land)kreise in eine …)
Danke, Walter, diesen Dienst kannte ich nicht. Das hilft mir sehr.
Was bleibt ist der Umstand, dass der OSM Route Manager offenbar solche Relationen (Relationen mit Ex- oder Enklaven) nicht korrekt anzeigt (Beispiel: http://osmrm.openstreetmap.de/relation.jsp?id=2083535). Wen informiere ich darüber? Auf der Seite finde ich keine Kontaktadresse, bei der man was melden könnte.
Hi Sven, ich wollte ja nur bemerken, daß ich beide Versionen “anbiete”. Es gibt manchmal beim Clippen mit den “scharfen” Polygonen Probleme mit Objekten (z.b. Straßen), die genau auf der Grenze liegen. Kann man mit Postgis ST_ContainsProperly anstelle ST_Contains in den Griff bekommen aber manchmal eben nicht.
Ja, ist ein vernünftiger Ansatz.
Ich habe schon mal überlegt, den Union in den Export einzubauen, um ein einziges Multipolygon für alle ausgewählten Grenzen zu erstellen. Mit PostGis natürlich kein Problem für mich, aber es klemmt an der GUI (Boundaries). Das ist eine elende Fummelei.
Ich vermute mal, das die die Polygone irgendwie selber “zusammenbasteln” anstelle den Job PostGis zu überlassen. Wenn dem so ist, wird das schwer zu lösen sein.
Mit welchen Tags könnte man für dieses gesamte Gebiet eine eintige Relation neu erschaffen und speichern, welche dann alle Landkreise umschließt?
Denn die Frage ist ja: type=boundary und boundary=???
Gibt es in Deutschland vergleichbare Regionen? und wenn ja, wie sind die getaggt?
Brauchen wir wirklich immer mehr redundante boundary-Relationen an den Grenzsegmenten? Gibt es nicht andere Möglichkeiten, z.B. Unions in PostGIS/Overpass?
Wenn es allerdings als irgendeine boundary mit Gemeinden u.ä. als “part”/“subarea” modelliert wird, sehe ich kein Problem. Nur mit osm2psql kann man die Relation dann nicht direkt als Gebiet nutzen…
Noch nicht oder ganz wenige, aber ich denke gerade drüber nach (wer sich an meine Fragen dazu im PLZ-Thread vor einigen Tagen erinnert, ist echt gut ;))
(A) Das technisch Einfachste ist es, wenn man neue Relationen aufbaut, natürlich mit type=boundary und dann boundary=irgendwas (region wäre ganz hübsch).
Dieses missfällt allerdings einigen Kollegen (oder nur einem?), da dadurch die “normalen” Grenzen komplizierter werden. Genaugenommen sind dann manche Grenzwege in noch einer weiteren Relation drin.
(B) die wohl elegantere Lösung: Masterrelationen, die die Gebiete als Subrelationen beinhalten.
Hier habe ich aber Bedenken, daß der Zugriff auf diese Gebiete z.B. für euch mit der Overpass oder für einige mit PostGis nicht einfach oder gar unmöglich wird.
Sucht euch was aus.
Ich bin für A, da das Argument “Dann werden die Grenzen noch komplizierter” z.B. bei Busrelationen nicht gebracht wird. Da sind manche Straßen auch Member von sehr vielen Bus-Routen.
Und wo in OSM sind dann die Regionen definiert? Lokal bei mir zuhause kann ich alles machen, aber was hat OSM davon?
genau, dann haben wir die daten drin und - fast - keiner kommt dran.
sieh es mal so: Du kümmerst dich vorrangig um defekte Admin- und PLZ-Grenzen - so wie ich es eigentlich auch tue.
Wenn jetzt eine Region kaputt geht, was wurmt dich das? Ich kümmere mich z.B. auch nicht um die Wahlkreise, die ab und zu auch mal einen Querschläger abbekommen und dann defekt sind. Zumindest suche ich nicht danach und hab auch keinen Tool dafür.
Ich könnte jetzt sagen: Macht Euren “Mist” und ich kümmere mich nicht darum. Aber so bin ich nicht. Ich repariere ja nicht nur Grenzen, sondern verbessere sie auch, wenn ich kann. Dabei machte ich dann ggf. die aus meiner Sicht unnötigen neuen Grenzen kaputt. Und das will ich auch nicht. Also macht es mir meine Arbeit dann schwerer.
Aber ich weiß eh nicht, wie lange ich das noch so machen kann. Ich habe bald die Zeit einfach nicht mehr, um “Grenzkindergärtner” zu spielen. Außerdem finde ich Grenzen in OSM (vermischt mit allem anderen Kram) aus technischen und auch lizenzrechtlichen Gründen immer schlechter.
Kann ich irgendwie schon verstehen. Irgendwie biegt man das dann doch zurecht.
Hast du Alternativen? Grenzpolygone als Ortsbezug werden in OSM doch ständig benötigt.
Ok, über PLZ könnte man nachdenken, da diese letztendlich “nur” die Verwaltungsdaten einer Firma sind, aber Administrative oder ähnliche Grenzen möchte ich nicht missen.
Ja, ich will das alles behalten. Aber ich will es nicht gleichberechtigt in OSM haben mit allen daraus folgenden Problemen.
Mir schwebt etwas vor, wie eine eigener Datenlayer. Dafür braucht man wohl eine geänderte API. Die wäre dann für Grenzen in der Regel read-only. Aber das finden einige dann auch wohl wieder zu autoritär bzw. unpraktikabel.
Bliebe mir nur ein Fork oder ich setzte gleich auf amtliche Daten für meine Auswertungen.
Der Vorschlag kommt immer mal wieder auf - nur wird der leider nie richtig zuende gedacht.
Wenn man eine separate DB aufbaut (was ich garnicht so schlecht fände), die solche etwas OSM-fernen Daten aufnimmt, reicht es nicht aus, irgend einen Server zu installieren, sondern die ganze Toolchain von der Eingabe mit Berechtigungen, Verteilung der Daten, Einbindung in OSM-Anwendungen, Administration, Backup, … muß gegeben sein. Da wird es wohl am meisten klemmen.
Oder aber die Integration in die bestehende Infrastruktur? Kannst du vergessen. Ob ich die API-0.7 noch erleben werde?
Nun ja, da du Grenzen ja nicht aus Spass an der Freude pflegst (wie unser einer), sondern damit durchaus berufliche Aktivitäten verbindest, kann ich dich schon verstehen.
Ich behelfe mich für manche Sachen einfach mit einigen lokalen Tabellen, die ich nur dann von OSM updaten lasse, wenn ich die Datenlage für ok halte.
Gruss
walter
OT? für diesen Thread schon aber sonst sicher wichtig - auch für OSM
Man könnte doch einfach die gleiche OSM-API und -Formate benutzen, aber eine andere API-URL mit allem dahinter. In JOSM kann man die URL z.B. umstellen.
Für Auswertungen etc. (auch Overpass) müsste man die Geometrien jedoch wieder mit der normalen OSM verbinden können.
Aber auch nur so sehr wie bei allen anderen Grenzen auch, also dafür sorgen, dass alle zugehörigen Relationen und alle angrenzenden Ways geladen sind (Way markieren, [Strg]+[Alt]+[D], [E], [Strg]+[Alt]+[D]).
Wenn man die Teile wirklich ausseinandernehmen will (z.B. ein Way, der sich zwischendrin in zwei Varianten aufteilen soll) kann man das mit etwas Nachdenken auch so schaffen, dass man sich nur eine Standard-Lösung aussuchen muss, die dann für alle Relationen wirkt, die man nicht bewusst bearbeitet
Bei Strassen geht das wegen der Richtungsgebundenheit leider nicht so gut…
So offtopic ist das alles nicht, weil die Frage, die Stephan wegen der Grenzen einer Metropolregion aufrief, ja meine Frage ist.
Die Metropolregionen kämpfen auf europäischer Ebene ja sxhon sein längeren darum in der NUTS Systematik berücksichtigt zu werden - für das Monitoring dieser (zumeist) wirtschaftsstarken Regionen wäre das schon wichtig. Ebene einer Karte zu sein, wäre in meinen Augen nicht so relevant, zumal die meisten Metropolregionen keine staatlich-administrativen Aufgaben wahrnehmen. Zudem könnte man dann noch vielfältige Grenzen aufmachen, die für Bürger oder Unternehmen deutlich mejr Auswirkungen haben (Gerichtsbezirke, Finanzamtsgwbiete, Fördergebiete diverser EU-Förderungen …) Ich könnte schon verstehen, wenn man da bemüht wäre, das nicht ausufern zu lassen.
Ich behelfe mir für meine Zwecke jetzt mit Unions oder klebe mir Polygone zusammen.
