[Experimentierwiese] BRouter - Karten selbst bauen

Damit der Haupt BRouter-Thread nicht unnötig mit Details vollgemüllt wird, habe ich das Bauen eigener Karten in einen eigenen Thread ausgelagert.

Kleine Warnung: Experimentierwiese !! Normale Nutzer laden die Karten am besten wie bisher herunter - entweder in der App oder vom Server :slight_smile:

Prima, das schaue ich mir mal an.

Zu den Höhendaten: Für Europa würde sich evtl. http://www.eea.europa.eu/data-and-maps/data/eu-dem anbieten.

Wenn ich das richtig sehe, müssten die Höhendaten im AAIGrid-Format vorliegen, damit sie vom Parser sauber verarbeitet werden können. Die Frage ist nur, ob ich die TIFF-Dateien vorher noch reprojezieren muß?


gdal_translate -of AAIGrid eudem_dem_5deg_n45w010.tif n45w010.asc

Ergebnis sieht so aus:


ncols        18000
nrows        18000
xllcorner    -10.000000000000
yllcorner    45.000000000000
cellsize     0.000277777778
NODATA_value    nan
 nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan nan 

Schritt 1: GitHub Repository auf lokalen Rechner klonen


git clone https://github.com/abrensch/brouter

Schritt 2: Bauen der Android-App abstellen

Für das reine Erstellen der Karten erscheint es nicht notwendig, auch die Android-App zu bauen. Das lässt sich in der Datei pom.xml anpassen, indem man den Eintrag " brouter-routing-app " mit " " auskommentiert.
Paket analog zur Anleitung in README.md kompilieren, dazu wird u.a. Apache Maven 3.0.3+, Java 6+ benötigt.

Schritt 3: SRTM-Daten downloaden

Dem maven-Test nach würde ich darauf tippen, dass ich zumindest Zip-Files im Verzeichnis /private-backup/srtm/ mit dem Namen srtm_38_02.zip (als Beispiel) benötige, die ein “.asc” File im schon beschriebenen Format enthalten.

Hier kann man immerhin ASCII-Grid wählen: http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp

und von dort aus direkt ftp://srtm.csi.cgiar.org/SRTM_v41/SRTM_Data_ArcASCII/srtm_38_03.zip downloaden.

mvn sieht schon mal gut aus, Testfälle laufen auch mit den beiden srtm-Dateien sauber durch.
Die Meldung für die Android App stört mich im Moment nicht (irgendein jarsigner-Problem).


[INFO] Reactor Summary:
[INFO] 
[INFO] brouter ........................................... SUCCESS [1.708s]
[INFO] brouter-util ...................................... SUCCESS [8.734s]
[INFO] brouter-expressions ............................... SUCCESS [1.940s]
[INFO] brouter-mapaccess ................................. SUCCESS [2.022s]
[INFO] brouter-core ...................................... SUCCESS [2.197s]
[INFO] brouter-map-creator ............................... SUCCESS [11.184s]
[INFO] brouter-server .................................... SUCCESS [2.791s]
[INFO] brouter-routing-app ............................... FAILURE [22.394s]

Leider macht schon der erste Schritt im Script process_pbf_planet.sh Probleme, dort fehlt irgendwie der Parameter für das Filterprofil. Sind die Sourcen auf Github nicht aktuell? Nun gut, ich habe all.brf mal ergänzt.


osmconvert osm_extract.pbf --out-osm | java -Xmx256m -Xms256m -Xmn32m -cp ../../brouter.jar btools.mapcreator.OsmCutter lookups.dat nodetiles ways.dat relations.dat all.brf

Weiter geht’s mit:


java -Xmx2600M -Xms2600M -Xmn32M -cp ../../brouter.jar -Ddeletetmpfiles=true -DuseDenseMaps=true btools.mapcreator.RelationMerger ways.dat ways2.dat relations.dat ~/brouter/misc/profiles2/lookups.dat ~/brouter/misc/profiles2/trekking.brf ~/brouter/misc/profiles2/softaccess.brf


*** RelationMerger: merge relations into ways
marked 220 routes for tag: route_hiking_
marked 1122 routes for tag: route_bicycle_icn
marked 1930 routes for tag: route_hiking_nwn
marked 311 routes for tag: route_bicycle_mtb
marked 2271 routes for tag: route_hiking_lwn
marked 2950 routes for tag: route_bicycle_rcn
marked 476 routes for tag: route_foot_lwn
marked 2530 routes for tag: route_hiking_rwn
marked 722 routes for tag: route_mtb_lcn
marked 424 routes for tag: route_mtb_
marked 3 routes for tag: route_hiking_iwn
marked 90 routes for tag: route_mtb_mtb
marked 3123 routes for tag: route_bicycle_lcn
*** WayIterator reading: ways.dat
** relation access conflict for wid = 27268889 tags: highway=service service=parking_aisle access=private (ok=true)

Die Meldung erscheint mir plausibel, way 27268889 ist Teil eines Jakobswegs, darf aber nicht benutzt werden.
Nach diesem Schritt finde ich nur noch ein File “ways2.dat”. Das File ways.dat wurde in diesem Schritt gelöscht. Laut Script benötige ich das aber für den 3. Schritt.

Seltsamerweise sind im MapcreatorTest.java die beiden Schritte NodeFilter und RelationMerger genau in umgekehrter Reihenfolge drin…

Ich hatte mir neulich mal eine Routing-Datei lokal gebaut und dazu die Skripte angepasst (ohne Garantie). Die wollte ich bei Gelegenheit nochmal überarbeiten und abstimmen, aber vielleicht hilft Dir das ja so schon, hab deshalb den aktuellen Stand mal bei mir eingecheckt:

process_pbf.sh (misc/scripts/mapcreation/)

compile_parser.sh (misc/pbfparser/)
Zum Lesen von PBF Dateien, muss separat kompiliert werden (siehe README.txt). Am besten Osmosis latest verwenden, das mit Ubuntu 12.04 ausgelieferte ist zu alt.

Mir ist erst jetzt aufgefallen, dass ich den RelationMerger bei mir noch gar nicht drin hab, hilft also an der Stelle schon mal nicht wirklich.

Hi, ja sorry, das hat nicht ganz gepasst, bzgl. genau der Ungereimtheiten, die Du gelistet hast (hab’s jetzt nochmal synchronisiert) aber Du warst schon ziemlich nah dran.

Dem NodeFilter ist das egal, ob die Relationen schon in die Ways gemerged sind, denn der filtert nur die Nodes raus, die zu garkeinem Way gehören. Ich hatte es wohl umgedreht, um den Disk-Space-Peak runterzukriegen, weil ich auf dem Server knapp an Disk-Space bin. Aber dann muss es natürlich ways2.dat im nächsten Schritt heissen.

Die cgiar v41 SRTM Files, die Du oben verlinkt hast, sind genau die, die ich verwende. Die andere Möglichkeit, die Du erwähnt hast, also die EU-DEM Tiffs per gdal_translate nach AAGrid (und dann nochmal zippen) sollte aber auch funktionieren, jedenfalls habe ich das mal genau so getestet. Nur sind die EU-DEM Files idiotisch gross (wegen 1’’ Auflösung), von daher sind die cgiar v41 Files die erste Wahl. Nur war zu meiner Zeit dieser ftp-Server bisschen zickig und eine Geduldsprobe.

Der Github-Head baut das neue Dateiformat, das mit der alten App NICHT gelesen werden kann, von daher wärs schon wichtig, auch die Android-App zu bauen. Aber weil das tatsächlich bisschen Bastelei ist bis man den richtigen Android SDK, maven-plugin, Signing Key etc hat hab ich jetzt mal das Distribution-Zip für die neue Version hochgeladen:

http://brouter.de/brouter_bin/brouter_1_0_1.zip

Das neue APK kann die alten Dateien lesen (aber nicht umgekehrt…), von daher kann man das bedenkenlos installieren, und das überschreibt oder löscht auch nichts.

Das mit dem “softaccess” filter und den “Relation access conflict” ist übrigens noch bisschen ein Hack und sollte ich noch zurück bauen. Das trekking-Profil routet bedenkenlos über jeden Weg, der Teil einer Rad-Relation ist, und im Falle von access=no/private ist das auch so beabsichtigt, nur hatte ich Probleme mit Rad-Relationen über Motorstrassen und die schnelle Lösung war, sie schon im Präprozessor rauszufiltern. Nur jetzt, wo ich sowieso neue Profile deployen will, sollte ich das eigentlich noch umbauen und diese Prüfung in das Profil schreiben, wo sie hingehört.

Ich würde mich (unabhängig von dem Versuch, RD5-Dateien selbst zu compilieren) freuen, wenn der eine oder andere die neue Version der App schon testet. Die Routing-Daten im neuen Format sind auch schon auf dem Server unter brouter.de/brouter/segments3, und von dort werden sie von der neuen App auch geladen.

Gruss, Arndt

Hallo Arndt,

etwas OffTopic (?) und Auffrischung einer früheren Frage:

Läßt sich in der neuen/ zukünftigen Version über die API Schnittstelle (lokale Nutzung) von einem Punkt der nächstliegende Knoten abfragen und die zugehörigen Attribute zB.: Elevation auslesen?

Vielen Dank für BRouter
Achim

Hi Achim,

ja dann mal die Auffrischung der Antwort :slight_smile: :

http://forum.openstreetmap.org/viewtopic.php?pid=413970#p413970

Ja klar, ich kann da was machen, aber wäre besser zu wissen, was Du konkret tun willst. Weil eine API gibt es ja: Route abfragen mit Startpunkt=Zielpunkt. Ist natürlich nicht sehr schnell und gibt kein Ergebnis bei >250m Entfernung zum nächsten Weg, Aber das zeigt, dass, um was besseres zu definieren, man wissen muss, was man will. Eine bestehende GPX-Datei nachträglich mit Höhendaten versehen würde ich anders angehen als möglichst schnell eine einzelne Höhenschätzung zu einer Location zu finden.

mmmhhhh…

Ich möchte mehrere Dinge, welche ich in meinen DesktopViewer einbauen möchte. Zunächst mal eine einfache Funktion getElevation(latlon) und das sehr “flott”…

Das hat aber nichts mit dem (B)Router zu tun. Ich möchte zur Auswahl meines nächsten VIA-Point (Float-VIA-Point) von einem vorherigen Fix-VIA-Point eine Luftlinie ziehen und so wie ich an der aktuellen Cursorposition (Float-VIA-Point) Latitude und Longitiude anzeige auch die Höheninformation anzeigen und das “fließend” mit der Cursorbewegung. Paralell dazu wird zwischen dem letzten FIX-VIA-POINT und dem FLOAT-VIA-POINT ein “Life” Entfernungs/Höhendiagramm erzeugt das mit der Cursorbewegung “lebt”.

Zwischen zwei "FIX-VIA-POINT"s erzeuge ich dann beliebig viele RouteSegmente mit BRouter und seinen Alternativen, Graphhopper,…etc. oder händisch. Von einem solchen RouteSegment erzeuge ich dann Entfernung, Höhendiagramm etc. Das funktioniert auch schon ganz gut. Durch Auswahl der einzelnen RouteSegmente bastel ich mir dann letzendlich meine Fahrradroute zusammen. So generiere ich dann in meiner Gegend mein erprobtes Fahrradnetz.

Was mir noch fehlt ist bzw. wo und wie ich die Info bekomme über die einzelnen Attribute wie WegName, Wegbeschaffenheit (Trackgrad) etc. Zur Zeit nutze ich dazu Funktionen von Graphhoper und dem Mapsforge Framework.

Viele Grüsse und nochmals vielen Dank für den SUPER-BRouter

Achim

Ps.: Bitte auch zukünftig die lokale PC-Version mit seiner alternativen Routengenerierung nicht aus den Augen verlieren

Hi,

Sorry for writing in English but my German is only passive and very limited.

I encountered a problem during the preparation of my own maps:


$java -Xmx2600M -Xms2600M -Xmn32M btools.mapcreator.OsmCutter /home/emes/devel/br/brouter/misc/profiles2/lookups.dat nodetiles ways.dat relations.dat ../maps/all.brf /home/emes/devel/br/maps/map.pbf
*** OsmCutter: cut an osm map in node-tiles + a way file
*** PBF Parsing: /home/emes/devel/br/maps/map.pbf
Exception in thread "main" java.lang.NoClassDefFoundError: org/openstreetmap/osmosis/osmbinary/Fileformat$BlobHeader
	at btools.mapcreator.OsmParser.readMap(OsmParser.java:51)
	at btools.mapcreator.OsmCutter.process(OsmCutter.java:83)
	at btools.mapcreator.OsmCutter.main(OsmCutter.java:41)
Caused by: java.lang.ClassNotFoundException: org.openstreetmap.osmosis.osmbinary.Fileformat$BlobHeader
	at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
	... 3 more

I use latest brouter from github and osmosis-0.43.1-1. The org.openstreetmap.osmosis.osmbinary.Fileformat.BlobHeader class seems to be in the right place. There it is in the source, as well as in the .jar file (Fileformat$BlobHeader.class).

I have no experience with Java so I don’t know what else could be wrong with the code. Any ideas?

The “right” place is in the class-path, and you did not specify a classpath at all. See https://github.com/abrensch/brouter/blob/master/misc/pbfparser/README.txt for some hints.

I just forgot to set the classpath in each of my scripts. Thank you!

OK, I’ve got the maps compiled and it works. However, there’s no elevation info in the generated route (I get -8192m everywhere).
I downloaded the SRTM zip files for my area and placed it to the srtm folder. The processor seems to look for that data:


*** NodeIterator reading: nodes55/E25_N55.n5d
reading: srtm/srtm_42_01.zip ilon=205041162 ilat=149957409
*** NodeIterator reading: nodes55/E25_N60.n5d
*** NodeIterator reading: nodes55/E10_N55.n5d
reading: srtm/srtm_39_01.zip ilon=193826042 ilat=145425148
*** NodeIterator reading: nodes55/E20_N55.n5d
reading: srtm/srtm_41_01.zip ilon=201565135 ilat=149076259
*** NodeIterator reading: nodes55/E15_N55.n5d
reading: srtm/srtm_40_01.zip ilon=195151329 ilat=145065117
*** NodeIterator reading: nodes55/E10_N50.n5d
reading: srtm/srtm_39_02.zip ilon=194986061 ilat=141154807
*** NodeIterator reading: nodes55/E15_N45.n5d
reading: srtm/srtm_40_03.zip ilon=199495833 ilat=139582239
*** NodeIterator reading: nodes55/E20_N45.n5d
reading: srtm/srtm_41_03.zip ilon=201103546 ilat=139375040
*** NodeIterator reading: nodes55/E20_N50.n5d
reading: srtm/srtm_41_02.zip ilon=200032568 ilat=140082070
*** NodeIterator reading: nodes55/E15_N50.n5d
reading: srtm/srtm_40_02.zip ilon=198702828 ilat=140290858

However, I have only two of these files listed above and the others aren’t there. Still, I get no error on the absent ones, so I cannot know if anything gets processed at all.

true, this message is the same mo matter if the srtm-file exists or not, see the source: https://github.com/abrensch/brouter/blob/master/brouter-map-creator/src/main/java/btools/mapcreator/PosUnifier.java

Are your 2 files named like 2 of the files in your log snippet?

You need very special srtm files, look into the zip-file, there’s a file with meta-data, they should have 6001 rows and 6001 cols, and the nodata-value should be -9999

You get them from an ftp-server from cgiar. I can send you a download-link for the ones that you need, however the license does not allow me to expose a public link

The elevation data is still work in progress, I have an uncommitted patch to read the new 1 arc second data. Howevr, this will become even more complicated and involve another pre-processing step just for the elevation data.