Spenden würden das Problem nicht unbedingt lösen, aber es spricht auch nichts dagegen.
Ich werde mal drüber nachdenken.
Gruss
walter
Hab schon Kontakt zu einem anderen Tschechischen “Kunden”, den ich zuerst als Übeltäter in Verdacht hatte. Er schaut sich da mal ein wenig um.
Ausserdem ist das ja ein allgemeines Problem, dass nur gestern/heute echt krass wurde.
Gruss
walter
Hi, hab mich vorhin mal bei den Tschechischen Kollegen, die mich so geärgert hatten, umgesehen. Die bieten neben vielen Papierkarten auch kostenpflichtige Downloads an, die wohl auf OSM basieren. Dort ist mit der Attributierung anscheinend alles ok.
Gruss
walter
ps: wenn jemand das Gefühl hat, mit der Boundaries Map klappt nicht alles wie sonst, möge bitte einfach mal einen Reload machen. Mir ist da heute Nachmittag in der Hektik ein Bug reingerutscht.
Wenn Dein Projekt so erfolgreich ist, könnte man ja auch überlegen, es das Baby freizulassen und irgendwo beim Fossgis oder OSMF laufen zu lassen.
Christian
Nee, lieber nicht. Nicht mit dem Spaghetti-Code 
Ausserdem hab ich kein Ressourcen-Problem sondern die Zugriffe auf die Datenbank werden nicht optimal verwaltet.
Da ist die Anwendung zu tolerant und zwingt jeden Rechner in die Knie, z.B. wenn die Anwender halt “mal eben” 10000 Grenzen am Stück abrufen sollten.
Ich “gönne” ihm ja die Daten, aber bitte nicht so.
Gestern hat es jemand geschafft, durch eine geschickte Suche im Suchfeld, alle 299398 Grenzen auszuwählen und war wohl kurz davor den Export anzuwerfen.
Klar, das sind Programmschwächen, aber die kann man abstellen.
Ein anderes Problem sind Bots, aber dazu fällt mir ausser Captchas noch nichts ein.
Gruss
walter
Das ist leider ein viel zu oft genanntes “Argument” seinen Code nicht freizugeben. Irgendwann hat der Entwickler keine Zeit/Lust und das Projekt ist tot (z.B. Kosmos, Maperitive).
Ich stelle es mir immer so vor, jede weitere Abfrage ein wenig mehr zu verzögern, am besten bevor sie zur DB geht. Das müßte doch den Massendownloader bremsen, aber nicht den Otto-Normal-Nutzer.
Christian
unten die leiste zum auswählen des formats verschwindet zum teil außerhalb des aktiven bildes, ich kann so nicht .svg auswählen. ich kann auch zum verschwundenen teil nicht sonst irgendwie hinscrollen.
nachtrag: sichtbar wird es wieder wenn man die browser zoomfunktion (verkleinerung) benutzt. in der normalansicht eben nicht.
Jo, da bin ich vor einigen Tagen auch mal drüber gestolpert. Eigentlich sollte der Footer sich an die Browsereinstellungen anpassen aber CSS ist wirklich nicht meine Stärke.
Gruss
walter
Hi,
ich habe einen neue Version (2.5) der Boundaries Map freigegeben, die viele kleine Änderungen und Korrekturen enthält.
Wer derzeit gerade die 2.4 oder noch ältere Versionen nutzt , möge bitte einen Reload machn, damit auch er die allerneueste Version verwendet.
Gruss
walter
Hallo,
habe mit Freuden die Boundaries Map gefunden! Mein Problem ist aktuell, dass ich gerne die Grenzen von Bundesländern z.B. Brandenburg per QuickOSM in QGIS laden möchte. Leider verstehe ich nicht wie eine korrekte Abfrage dazu aussieht…
Habe es bisher mit
Schlüssel: boundary
Wert: administrative
versucht.
Wie baue ich da jetzt noch admin_level= 4 und dass ich nur Brandenburgs Grenzen haben möchte mit rein?
Grüße!
Max
Mit QuickOSM greifst du direkt auf die OSM API Overpass API zu. Die Boundaries Map ist ein davon unabhängiger Service. In der Boundaries map kannst du Grenzen wie folgt downloaden: gewünschte Grenzen auswählen, Dateiformat wählen → Export
Vielen Dank! Der Export aus wambachers boundaries map sowie import nach qgis hat super geklappt. Sorry, dass ich so Basic Fragen in diesem Spezialthread stelle, bin aber noch etwas verloren … Wie würde denn eine OSM Api Abfrage aussehen nach der man die Grenzen von Brandenburg abfrägt?
Grüße!
Max
Sry, ich habe mich obigen Beitrag verschrieben. QuickOSM greift nicht auf die OSM API zu sondern auf die Overpass API.
Overpass Language Guide: http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide
Overpass QL: http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL
btw: Für Fragen zu Overpass bzw. QuickOSM solltest du einen eigenen Thread öffnen, das geht hier am Thema vorbei.
Hab ich mal gemacht. Also bitte hier weiter: http://forum.openstreetmap.org/viewtopic.php?pid=512306#p512306
Hi,
da ich es immer öfters erlebt habe, dass manche User (vornehmlich aus den osteuropäischen Ländern) mit allen möglichen und auch unmöglichen Tricks versuchen ganze Länder herunterzuladen, habe ich mich entschlossen, das ab sofort zu erlauben.
Aufruf: Man gehe mit dem Cursor im linker Tree auf die gewünschte Startgrenze (hier Hessen), Context-Menu mit rechter Maus und klicke dann bei “Export Full Subtree”. Es wird dann ein Zip-File erzeugt, das alle Grenzen ab dem Startpunkt beinhaltet, wobei pro Adminlevel eine eigenes File erstellt wird. Datenstand ist der unten im Footer angezeigte Timestamp, dieser beträgt in der Regel ca 00:30 des aktuellen Tages.
Derzeit geht das nur für JSON aber SHP und SVG werden bald folgen. Für Poly-Files macht das mMn keinen Sinn, ich lass mich aber gerne umstimmen.
Bitte nicht alle sofort Germany laufen lassen nur um zu sehen, ob es geht. Dauert ca 2-3 Minuten aber ich glaube nicht, dass die jemand gerade jetzt dringend ganz Deutschland braucht. Testen kann man auch mit seiner Heimatstadt.
Gruss
walter
ach ja: Reload nicht vergessen.
Hi,
der Full Subtree Export kann jetzt auch Shapefiles erzeugen. Erzeugt wird ein Zip-File, das alle Admin Level ais seperate Shapes enthält.
wambacher@wno-server:~/Downloads$ unzip exported_boundaries_Hesse.shp.zip
Archive: exported_boundaries_Hesse.shp.zip
......
inflating: Hesse_AL4.dbf
inflating: Hesse_AL4.prj
inflating: Hesse_AL4.shp
inflating: Hesse_AL4.shx
inflating: Hesse_AL5.dbf
inflating: Hesse_AL5.prj
inflating: Hesse_AL5.shp
inflating: Hesse_AL5.shx
inflating: Hesse_AL6.dbf
inflating: Hesse_AL6.prj
inflating: Hesse_AL6.shp
inflating: Hesse_AL6.shx
inflating: Hesse_AL8.dbf
inflating: Hesse_AL8.prj
inflating: Hesse_AL8.shp
inflating: Hesse_AL8.shx
inflating: Hesse_AL9.dbf
inflating: Hesse_AL9.prj
inflating: Hesse_AL9.shp
inflating: Hesse_AL9.shx
inflating: Hesse_AL10.dbf
inflating: Hesse_AL10.prj
inflating: Hesse_AL10.shp
inflating: Hesse_AL10.shx
wambacher@wno-server:~/Downloads$
In QGIS sieht das dann so aus:
Gruss
walter
Als nächstes kommt in den folgenden Tagen noch der SVG-Export dran.
Hallo Walter,
Umlaute in Ortsnamen… werden in der Shape-Datei noch verkrumpelt: z.B. Lübben (Spreewald):
die Shape-Datei heißt dann z.B. L++bben (Spreewald)_AL8.* ect.
Sven
Uii, ich dachte ich hätte das hinbekommen. nun den, muß ich nochmals dran.
Was wir damals gemacht hatten, war eine Datei mit der Codierung zum Archiv hinzuzufügen. Allerdings hatte Visum diese beim Einlesen ignoriert. Eventuell macht die Software von streckenkundler das auch so.
Hm… ich hab im Firefox lediglich Lübben markiert, bzw. beim zweiten Mal mit Untereinheiten auf shape und auf exportieren… Die Shape-Datei in der zip-Datei hatte dann diese Zeichenersetzung. Zum Einsatz kam Firefox 31.6 esr.
Das Laden ins ArcGis mit dieser Zeichenersetzung funktionierte… diese Zeichenersetzung ist nur ein Schönheitsfehler. …
[Nachtrag] es betrifft auch nur die Benennung der Shape-Datei im ZIP-Container… Die Zeichensatzverwendung der Attribut-Tabelle (*) im Shape ist ok… laden läßt es sich auch…
Nebenbei: In den jüngeren ArcGis-Versionen taucht bei der Esri-Shape-Datei immer eine “xyz.cpg” Datei auf. “xyz” steht für den Namen der Shape-Datei. Der Inhalt dieser Datei ist die Zeichencodierung des Zeichensatzes, z.B. steht nur “UTF-8” drin… ist wichtig ernn mal Umlaute und Sonderzeichen verkrumpelt sind. QGis beachtet diese Datei anscheinend auch.
[/Nachtrag]
Sven