Soll die Boundaries Map eigentlich mal bei http://wiki.openstreetmap.org/wiki/Shapefiles#Download_shapefiles eingetragen werden? Immerhin kriegt man da auch Shapefiles.
Danke, ist jetzt drin. Wem ein besserer Text einfällt, der mag es gerne ändern.
Ich wundere/freue ich mich jeden Morgen, wer sich da neu angemeldet hat. Das Teil scheint wirklich populär zu sein. 
Meinen letzten “Übeltäter” hab ich gestern erwischt. Er hat sich ganze Länder mit curl runtergeladen, da er mit dem Full Export nichts anfangen konnte. Hab lange mit ihm diskutiert und wir haben eine Lösung gefunden. Mal sehen, wann ich die optional einbaue.
Gruss
walter
ps: kennt sich wer mit dem Donate-Button und den Voraussetzungen dafür aus? So ein 24/7-Dienst frisst doch einiges an Strom.
Hatten wir in diesem Thread eigentlich auch schonmal den Hinweis auf die Datensätze für administrative Grenzen von Mapzen.com?
Über eine Antwort aug gis.stackexchange.com bin ich darauf gekommen.
siehe https://mapzen.com/data/borders/
Machen die irgendwas von der Vorgehensweise ganz anders als du, Walter?
Jo, völlig anders. Die machen einen Spezialimport des Planeten mit nur für Grenzen wichtige Daten. Ich hab halt alles in der DB und filtere mir nach Bedarf das passende raus.
“Spinoffs” wie die Missing Boundaries haben die natürlich nicht.
nun denn, Konkurrenz belebt das Geschäft 
Gruss
walter
Jo, kleiner Fehler - grosse Auswirkung.
Wenn man nach Admin_Level sortiert und AL ist ein String, rutscht die ‘10’ nach ganz oben. Und den “obersten” Namen nimmt er für das Zip-File. Sortiert man das AL numerisch, funzt es natürlich.
Danke und Gruss
walter
Hi,
ich erweitere derzeit die Export-Funktion der Boundaries Map um einige Optionen.
Hauptsächlich soll dadurch gesteuert werden, wie das Ausgabe-Layout der Exporte aussehen soll.
- Split: jede Grenze erhäit ein eigene File.
- Levels: alle Grenzen eines Admin-Levels kommen zusammen in ein separates Shp/GeoJSON/POLY,…-File
- Single: Alle Grenzen kommen in ein einziges File.
“Levels” ist das bisherige Verhalten, das bei manchen Heavy-Usern als nicht optimal angesehen wurde.
Danach wird wie bisher ein ZIP erzeugt und das steht dann zum Download zur Verfügung.
Split/Levels/Single: Fällte jemanden was besseres ein? nur kurz muss es sein.
Sonstige Wünsche oder Vorschläge? Das sind die offene “Todos”, wobei einige wohl nie geschlossen werden:
101: Farbschema verbessern wambacher open
102: Scrolling im linken Fenster verbessern wambacher open
107: Save des Trees im Cookie wambacher open
109: Ausgabe von Prefix und Suffix im Namen stephan75 open
111: CAD-verarbeitbare Polygonliste MichelFS open
118: Suche nach ISO wambacher open
120: Hover in der Karte einbauen wambacher open
121: Bearbeiten ermöglichen (per Link) aselngiu open
122: Land durch Klick auf Karte auswählen cepesko open
131: GPX-Export wambacher open
zu finden: Einfach den Sidebar-Button klicken.
Gruss
walter
Hallo,
Ich habe da eine “Lücke” in der Boundaries Map gefunden. Ich glaube das ist “working as designed”, aber ich wollte es trotzdem mal zwecks Meinungsbildung auf den Tisch bringen.
Es geht um folgendes Amt: https://de.wikipedia.org/wiki/Amt_Itzstedt
Dementsprechend ist es auch richtig in OSM eingetragen (meinem Verständnis nach…).
Das Problem tritt jetzt im Baum auf:
-
Germany / Schleswig-Holstein / Kreis Storman (6) => Gebiet Tangstedt wird mit angezeigt => OK
-
Germany / Schleswig-Holstein / Kreis Seegeberg (6) => Gebiet Tangstedt wird nicht mit angezeigt => OK
-
Germany / Schleswig-Holstein / Kreis Seegeberg / Itzstedt (7) => Gebiet Tangstedt wird mit markiert => OK
-
Germany / Schleswig-Holstein / Kreis Seegeberg / Itzstedt / Select children => Gebiet Tangstedt wird nicht mit markiert, weil Admin_Level (8) nicht zum Kreis Seegeberg gehört => OK
-
Germany / Schleswig-Holstein / Kreis Stroman / Select children => Gebiet Tangstedt wird nicht mit markiert, weil es keinen admin_level (7) gibt, wo das Gebiet dazu gehören würde => OK
Offene Frage: Wo gehört Tangstedt (8) nun richtig hin? Es ist nirgends vorhanden (oder habe ich es nur übersehen) und ich wüsste auch nicht, wo es korrekt eingehängt werden müsste. Vielleicht noch am ehesten doch mit unter Itzstedt (7) im “falschen” Landkreis als direktes Parent?
Oder fällt es einfach durchs Raster und hat Pech gehabt? 
Mit freundlichem Gruß
Das erste was mir auffällt: Tangstedt wird bei der Suche 2x gefunden, ist also 2x in OSM drin. Ist das ok so?
aha: und es wird nur das Tangstedt in Pinnau im Tree angezeigt.
Jo, aber laut Wikipedia stimmt das. 
auch die DB sieht (auf den ersten Blick) sauber aus:
localhost:planet2=# select id,country,value,level,path
localhost:planet2-( from boundaries
localhost:planet2-( where type='admin'
localhost:planet2-( and value='Tangstedt';
id | country | value | level | path
--------+---------+-----------+-------+-------------------------------------
444300 | DEU | Tangstedt | 8 | {0,51477,51529,62546,442744,444300}
443706 | DEU | Tangstedt | 8 | {0,51477,51529,62408,443732,443706}
(2 Zeilen)
localhost:planet2=#
localhost:planet2=# select id,value,level
localhost:planet2-( from boundaries
localhost:planet2-( where id in
localhost:planet2-( (select unnest(path) id
localhost:planet2(( from boundaries
localhost:planet2(( where id in(443706,444300))
localhost:planet2-( order by level;
id | value | level
--------+--------------------+-------
0 | | 1
51477 | Germany | 2
51529 | Schleswig-Holstein | 4
62546 | Kreis Stormarn | 6
62408 | Kreis Pinneberg | 6
443732 | Pinnau | 7
442744 | Itzstedt | 7
444300 | Tangstedt | 8
443706 | Tangstedt | 8
(9 Zeilen)
localhost:planet2=#
Grübel, Grübel
Also mal kurz dazwischen gegrätscht:
Ja, 2 Tangstedts ist in Ordnung und gewollt. Hast du ja schon verschieden gegengeprüft. Es geht also nicht um das Pinneberger Tangstedt (im Westen), sondern nur um das 16km östliche gelegene Stormaner Tangstedt.
Wenn ich in der Suche (auf die Idee bin ich nicht gekommen) auf das Stromaner/Itzstedter Tangstedt klicke, passiert bei mir gar nichts? Das würde ich mal als Bug ansehen. Beim Pinneberger klappt das.
Nachtrag:
http://www.openstreetmap.org/relation/444300 sieht für mich seltsam aus, speziell das:
Wobei http://www.openstreetmap.org/relation/2959368 wiederrum kein admin_level hat und da auch nicht sinnvoll reinpasst.
Ich habe das Gefühl das hat man (sinnlos?) irgendwo hingehängt, damit es überhaupt ein “Teil von” ist
Nachtrag 2:
Ok, das war verrannt. Die aufgezeigte Relation hat was mit Wahlkreisen/Bundestagswahl zu tun. Logisch, dass sie dann kein admin_level hat.
Ja, das ist schon klar. Tangstedt (OST) fehlt auf der BM im Kreis Storman. Ich hatte erst die beiden outer von Tangstedt(W) in Verdacht, die sehen aber für mich sauber aus.
Ich schau mir mal das Logfile von heute Nacht an, ob da irgendwas steht.
gruss
walter
Itzstedt ist komisch.
BITTE NICHTS IN OSM KORRIGIEREN _ SONST KANN ICH DAS NICHT NACHVOLLZIEHEN
Tangstedt (West), Relation 443706, gehört zum Kreis Pinneberg. Das liegt da und das ist auch ok. Alles gut da. Keine Probleme
Tangstedt (Ost), Relation 44300, gehört zum Kreis Storman (OD) aber auch gleichzeitig zum “Amt Itzstedt”, welches zum Großteil im Kreis Segeberg liegt.
Ich behaupte: Da ist in Osm alles richtig, daher sehe ich auch keine Notwendigkeit etwas zu ändern. Ich befürchte eher, dass der Parser für so ein wildes Konstrukt nicht ausgelegt ist.
Man hat ja folgende Kette:
Germany → Schleswig-Holstein → Kreis Segeberg → Amt Itzstedt → Gemeinde Tangstedt (welche Teil des Kreises Storman ist)
bzw
Germany → Schleswig-Holstein → Kreis Storman → (nix da fremdverwaltet ) → Gemeinde Tangstedt
Wobei mir als Anfänger noch nicht wirklich klar ist, wo die Beziehungen zwischen den Relationen herkommen.
–
OT und nicht ganz ernst:
Bei wem kann man eigentlich Relationen “beantragen”? M-V hat so eine schöne “Küstengewässer inkl. Festlandsockel”-Relation! Sowas möchte ich auch für S-H duck und wegrenn
Solche Aufträge sind bei OSM immer an die eigene Adresse zu stellen.
Aufrecht stehen bleib
Baßtölpel
Ja, ich hab mal die Suchausgabe erweitert. Er findet Tangstedt(O) in Itzstedt(7). Und da Itzstedt(7) ja über zwei Kreise geht, flippt die Geometryanalyse aus.
Sorry, aber dazu fällt mir nix mehr ein. Wenn das so ist, dann ist das so. Ich beantrage hiermit eine Gebietsreform.
Bau eine. Solange die nicht mit den vorhandenen Rels kollidiert, sollte das kein Problem sein.
Das Thema mit den “Küstengrenzen” möchte ich aber nach der Sommerpause anschneiden. Da könnte man einiges besser machen.
Gruss
walter
Baßtölpel:
DAS wollte ich jetzt aber nicht hören gg
warmbacher:
Ja, wenn das so ist, dann ist das halt so. Müssen wir alle mit leben.
Das mit den Küstengrenzen der Landkreise ist halt auch ein schwieriges Thema. Ich habe da Punkte hustingresshust die liegen auf den Seebrücken, Anlegestellen u.ä… Die gehören offiziell nicht mehr zum angrenzenden Landkreis aber irgendwie doch. Viele Landkreise haben eine “richtige” Grenze, die hier verwendet wird und eine “lazy” Grenze, die o.g. noch mit einschließt. Für meine Zwecke wird da halt die “falsche”/zu strenge Grenze genommen 
Aber das fällt auch unter persönliche Einzelfallprobleme. Genug mimimit 
Das Problem ist, dass nur die Relationen (Grenzen sind Relationen) in der lokalen Datenbank landen, die type=boundary, type=multipolygon oder type=route haben. Alle anderen Rels werden beim Import mit osm2pgsql verworfen. osm2pgsql ist DAS Importprogramm, mit dem das Planet-File und die Diffs in die lokale Datenbank gelangen.
Und diese lokale Datenbank ist in der Regel die Basis von der aus gerendert wird oder die auch für andere Sachen zu gebrauchen ist. Was da nicht drin steht, ist nicht da
Daher habe ich in den letzten beiden Jahren immer auf type=boundary, boundary=killefitt bestanden, da nur sowas “durchkommt”. Siehe type=boundary, boundary=low_emission_zone für die Umweltzonen.
TMC haben type=TMC und Landareas haben type=land_area und die sind lokal einfach nicht da. Zumindest nicht als Flächenobjekte (OGC Multipolygone) so wie jede andere “vernünftige” Boundary.
Da liegt der Hase im Pfeffer.
Lösung: aus type=land_area einfach type=boundary, boundary=land_area machen und alles wird gut.
Da die lokal nicht vorhandenen Daten eh niemand verwenden kann, sollte das keine Probleme machen.
Gruss
walter
ps: dass die blöden Dinger type=land_area haben, ist vor einigen Jahren teilweise auch auf meinem eigenen Mist gewachsen. Das war anfangs eine rein deutsche Entscheidung, die wir mMn auch revidieren können und sollen.
Hi,
ich habe gerade die Version 3.4 frei geschaltet und diese sollte sich in den letzten Minuten automatisch upgedated haben.
Vorerst sind hoffentlich keine Änderungen bemerkbar aber morgen Vormittag werde ich eine verschärfte Zugriffskontrolle anschalten, sodass man immer OAuth aktiviert haben muss. Das war leider notwendig, da es immer noch zu Störungen im Betrieb durch nicht identifizierbare User kam.
Gruss
walter
Hi,
hier mal eine kleine Statistik der letzten 2 Tage:
user | kb | mb
----------------------+--------+-----
Pas********** | 289050 | 261
Phi****** | 259574 | 252
Jea***************** | 15479 | 14
Chr************** | 10079 | 8
Ale*** | 9968 | 8
Noi*** | 9141 | 7
wam****** | 6993 | 5
Dim************ | 3948 | 0
mas****** | 2681 | 0
kha***** | 1961 | 1
MMM******** | 1324 | 0
lim***** | 788 | 0
rom***** | 823 | 0
Ari*********** | 491 | 0
Jac************ | 332 | 0
Lju** | 293 | 0
Foo***** | 155 | 0
Amv** | 110 | 0
dan***** | 104 | 0
Bri***** | 42 | 0
dav******** | 7 | 0
jgo**** | 5 | 0
(22 Zeilen)
eventuell findet sich da jemand wieder. Obwohl die meisten Anwender keine Mapper sind, sondern sich extra für den Export registrieren mussten.
wam****** bin übrigens ich, muss ja auch mal testen.
Die Version 3.5 wird drei Export-Layouts besitzen:
- single: alle Daten in einem einzigen SHP/GEOJSON/…-File
- levels: jeweils die Daten eines Admin-Levels zusammengefasst. Das ist die aktuelle Situation.
- split: eine Grenze - ein File
Dadurch wird die Weiterverarbeiung der Daten auf den lokalen Systemen hoffentlich einfacher.
Gruss
walter
Schon interessant. 2 User haben also den Großteil der Last erzeugt.
Erbsenzähl
wam****** | 6993 | 5
Dim************ | 3948 | 0
mas****** | 2681 | 0
kha***** | 1961 | 1
MMM******** | 1324 | 0
…da stimmt was nicht, wenn kb und mb die Dateigrößen-Einheiten sein sollen.
Da hab ich wenig Probleme mit, denn sie das mit “Export Full Subtree” machen. Sobald man sich aber einige hundert Boundaries “zusammenklickt”, kommt der Server ins Schleudern. Ich überlege bereits, ein “max selectable”-Limit zu machen, damit die man sowas den Subtree-Export benutzt. Geht aber wohl erst mit der 3.5/3.6, weil da einiges mit den Exportten anders wird.
besser so?
user | kb | mb
----------------------+-----------+--------
Pas********** | 1436666.4 | 1403.0
Phi****** | 357998.0 | 349.6
Kil*************** | 185120.0 | 180.8
jgo**** | 88217.0 | 86.1
Saj***** | 82588.6 | 80.7
Chr************** | 61353.6 | 59.9
Bad** | 48789.8 | 47.6
dk_** | 27188.6 | 26.6
Jea***************** | 15479.8 | 15.1
Arc***** | 13574.8 | 13.3
jgl** | 13557.3 | 13.2
Ale*** | 9969.0 | 9.7
Noi*** | 9142.1 | 8.9
wam****** | 6997.0 | 6.8
Cae***** | 6429.4 | 6.3
Dim************ | 4058.3 | 4.0
Kád******* | 3682.4 | 3.6
mas****** | 2683.1 | 2.6
hyz***** | 2463.3 | 2.4
kha***** | 1961.6 | 1.9
Flo********* | 1603.1 | 1.6
MMM******** | 1325.9 | 1.3
lim***** | 869.9 | 0.8
rom***** | 823.5 | 0.8
jra***** | 717.5 | 0.7
Ari*********** | 491.9 | 0.5
Mr ********* | 470.1 | 0.5
Jac************ | 332.3 | 0.3
Lju** | 293.0 | 0.3
ern***** | 195.1 | 0.2
Foo***** | 156.1 | 0.2
Amv** | 110.9 | 0.1
cap*********** | 108.9 | 0.1
dan***** | 104.2 | 0.1
Pau********* | 75.8 | 0.1
Ter******** | 64.3 | 0.1
Bri***** | 42.3 | 0.0
Har************ | 31.1 | 0.0
dav******** | 7.8 | 0.0
ors**** | 2.6 | 0.0
Gruss
walter
ps: Pascal werde ich wohl blocken. Hab ihm mehrere Mails geschickt und nix kam.
Die Landmassegrenzen sind derzeit noch nicht auf der Website oder?