möchte meine Kartendaten über die Overpass API herunterladen. Leider mag mir das nicht so recht gelingen. Die Datenmenge des downloads besitzt gerade mal ein Zehntel des Volumens, welches ich eigentlich erwarte. Es lässt sich damit auch keine Karte generieren (mkgmap). Splitter generiert gerade mal eine Kachel, anstatt wie gewohnt sechs.
Mein Ausschnitt hat die Dimensionen left=10.6 bottom=49.2 right=12.9 top=50.7, also gestalte ich die Abfrage an die Overpass API folgendermaßen:
(
node(49.2,10.6,50.7,12.9);
rel(bn)->.x;
way(bn);
rel(bw);
);
out meta;
Mein Ausschnitt hat normalerweise ca. 1.8GByte. Die Overpass-Daten kommen gerade mal auf 160MByte.
Als erstes ist die Datenmenge das Problem. Denn die 1,8 GB hat die Overpassapi nicht mal eben für dich frei. Das zweite Problem ist wie gesagt wenn du alles für deine Karte runterladen möchtestet, dann nimm statt dessen Extrakte und bearbeite filtere diese entsprechend. Das entlastet nicht nur die Overpassapi erheblich, sondern auch deine Nerven.
Ja. Das ist leider nur praktisch für Leute, die zufällig *nicht * an der Bundesgrenze wohnen. Hole aktuell meine Daten über http://140.78.94.22/osm/ (Germany+50). Wollte mir halt nur schnell mal aktuelle Daten saugen.
Ne…das geht mit kleineren Extrakten ganz ähnlich. Es gibt allerdings Probleme, wenn ein Objekt von außen in das Extrakt reingeschoben wird. Das Objekt sollte dann fehlen. Aber wenn du Europe aktualisierst und dann D+50 ausschneidest sollte man das egtl. vernachlässigen können. Auf der anderen Seite sehe ich egtl. auch nicht so das Problem, den ganzen Planeten zu aktualisieren. Den Plattenspeicher sollte egtl. jeder haben, der auch Garminkarten von ganz Deutschland rechnen kann.
Bevor ich einen neuen thread eröffne, mache ich hier weiter.
Wer kann mir vom Schlauch helfen?
Ich benötige die Syntax, mit der ich nodes finde, die den gemeinsamen Verbindungspunkt von ways mit verschiedenen Eigenschaften eines tags gehören und farbig hervorgehoben werden sollen. Gleichzeitig ist dieser node das Ende eines bestimmten way-typs.
Für die ganz Mutigen: Das geht mit PostGIS-Topology. Das ist eine PostGIS-Erweiterung, die für solche Aufgaben geschaffen wurde. Es werden dort Graphen aufgebaut, die die geometrischen Zusammenhänge zwischen den Objekten berücksichtigen. Beim Routing werden ähnliche Datenstrukturen verwendet.
Der Einstig ist nicht einfach und ich hab das auch noch nicht richtig geschnallt. Aber das ist der Weg.
Nimm doch eine Programmiersprache Deiner Wahl und schreibe folgendes:
Lies einen Way ein
Ist der Way eine Straße, wenn ja, merke Dir Highway-Typ, sonst gehe zu 1
Nimm die erste und letzte Node-ID des Ways, und merke Dir “an dieser Node-Id endet/beginnt ein Way vom Typ X”. In den meisten Skriptsprachen würdest Du dafür ein Hash von Arrays einsetzen, also in Perl zum Beispiel
Dann schreibst Du noch etwas Code, der diese Struktur untersucht, und der Dir diejenigen Nodes rausfiltert, bei denen die Liste “nicht aufgeht” (also 2x “residential” ist ok, und wenn ich Dich richtig verstehe, ist 2x “residential” und 1x “tertiary” auch ok, aber 1x “residential” und 1x “tertiary” nicht…)
Um dann die Node-Koordinaten dieser Nodes herauszufinden, könntest Du natürlich Overpass bemühen, oder Du liest Dein File einfach ein zweites Mal ein und schnappst Dir die notwendigen Koordinaten. Das erspart Dir, im ersten Durchgang alle Koordinaten “auf Vorrat” zu speichern, was u.U. viel Platz braucht.
Diesen Code kriegst Du in so ziemlich jeder Sprache einigermassen einfach hin. Wenn Du keine PBFs einlesen kannst/willst, kannst Du ja XML verwenden, das lässt sich notfalls auch ohne XML-Parser lesen.
Das ist ja lieb gemeint, aber selbst wenn ich meinem Hirnschmalz zutraue, nach einer Nutzungsdauer von sechzig Jahren noch eine Programmiersprache zu erlernen, stellt sich die Frage, ob dies bei der Restnutzungszeit sinnvoll ist.
Aber man hat ja seine Kontakte…