Wenn du jetty runner 8 benutzt. Geht das dann? (Use 8 or lower if you only have JRE6.)
Wenn ja dann werde ich das als default nehmen…
Keine Ahnung ob jetty runner 8 dort funktioniert. Ich habe kein .jar Archiv gefunden.
Allerdings habe ich ja auch die JRE7 installiert, weshalb ich erstmal genauer nachgeschaut habe. Und in der Tat es gibt auch noch die Version 6, welche offenbar Standard ist. Wenn ich aber zum ausführen explizit die Version 7 wähle, dann funktioniert es wie erwartet:
F:\graph>"C:\Program Files (x86)\Java\jre7\bin\java" -Dgraphhopper.config=config
-example.properties -Dgraphhopper.osmreader.osm=berlin-latest.osm.pbf -jar jetty
-runner-9.0.4.v20130625.jar --port 8989 graphhopper-web-0.2-20130720.103500-2.wa
r
2013-07-28 14:05:07.501:INFO:oejr.Runner:main: Runner
2013-07-28 14:05:07.751:INFO:oejs.Server:main: jetty-9.0.4.v20130625
2013-07-28 14:05:09.236:INFO:oejpw.PlusConfiguration:main: No Transaction manage
r found - if your webapp requires one, please configure one.
2013-07-28 14:05:11,501 [main] INFO com.graphhopper.GraphHopper - version 0.2|2
013-07-20T12:34 (1,2,1,1,1)
2013-07-28 14:05:11,548 [main] INFO com.graphhopper.GraphHopper - graph LevelGr
aphStorage|CAR|RAM_STORE|,,,,, details:edges:0(0), nodes:0(0), name: - (0), geo:
4(0), bounds:1.7976931348623157E308,-1.7976931348623157E308,1.7976931348623157E3
08,-1.7976931348623157E308
2013-07-28 14:05:11,548 [main] INFO com.graphhopper.GraphHopper - start creatin
g graph from berlin-latest.osm.pbf
2013-07-28 14:05:11,564 [main] INFO com.graphhopper.GraphHopper - using LevelGr
aphStorage|CAR|RAM_STORE|,,,,, memory:totalMB:24, usedMB:18
2013-07-28 14:05:16,095 [main] INFO graphhopper.reader.OSMReader - creating gra
ph. Found nodes (pillar+tower):170á601, totalMB:56, usedMB:34
2013-07-28 14:05:18,142 [main] INFO graphhopper.reader.OSMReader - 1á903á416, n
ow parsing ways
2013-07-28 14:05:20,345 [main] INFO graphhopper.reader.OSMReaderHelper - finish
ed way processing. nodes: 70811, osmIdMap.size:173002, osmIdMap:2MB, osmIdMap.to
String:Height:3, entries:1283 totalMB:102, usedMB:90
2013-07-28 14:05:20,345 [main] INFO graphhopper.reader.OSMReader - time(pass1):
4 pass2: 4 total:8
2013-07-28 14:05:20,361 [main] INFO com.graphhopper.GraphHopper - start finding
subnetworks, totalMB:102, usedMB:92
2013-07-28 14:05:20,439 [main] INFO routing.util.PrepareRoutingSubnetworks - op
timize to remove subnetworks (2237), zero-degree-nodes(0)
2013-07-28 14:05:20,517 [main] INFO com.graphhopper.GraphHopper - edges: 93272,
nodes 64537, there were 2237 subnetworks. removed them => 6274 less nodes. Rema
ining subnetworks:1
2013-07-28 14:05:20,517 [main] INFO com.graphhopper.GraphHopper - optimizing ..
. (totalMB:102, usedMB:77)
2013-07-28 14:05:20,517 [main] INFO com.graphhopper.GraphHopper - finished opti
mize (totalMB:102, usedMB:77)
2013-07-28 14:05:20,517 [main] INFO com.graphhopper.GraphHopper - calling prepa
re.doWork ... (totalMB:102, usedMB:77)
2013-07-28 14:05:23,033 [main] INFO routing.ch.PrepareContractionHierarchies -
1, nodes: 64á537, shortcuts:0, dijkstras:287á877, t(dijk):1, t(period):0, t(lazy
):0, t(neighbor):0, meanDegree:1, totalMB:102, usedMB:93
2013-07-28 14:05:23,158 [main] INFO routing.ch.PrepareContractionHierarchies -
2, nodes: 60á235, shortcuts:398, dijkstras:295á449, t(dijk):0, t(period):0, t(la
zy):0, t(neighbor):0, meanDegree:1, totalMB:102, usedMB:71
2013-07-28 14:05:23,205 [main] INFO routing.ch.PrepareContractionHierarchies -
3, nodes: 55á933, shortcuts:486, dijkstras:297á844, t(dijk):0, t(period):0, t(la
zy):0, t(neighbor):0, meanDegree:1, totalMB:102, usedMB:74
2013-07-28 14:05:25,064 [main] INFO routing.ch.PrepareContractionHierarchies -
4, nodes: 51á631, shortcuts:583, dijkstras:528á543, t(dijk):1, t(period):1, t(la
zy):0, t(neighbor):0, meanDegree:1, totalMB:102, usedMB:80
2013-07-28 14:05:25,111 [main] INFO routing.ch.PrepareContractionHierarchies -
5, nodes: 47á329, shortcuts:762, dijkstras:532á614, t(dijk):0, t(period):0, t(la
zy):0, t(neighbor):0, meanDegree:1, totalMB:102, usedMB:83
2013-07-28 14:05:25,283 [main] INFO routing.ch.PrepareContractionHierarchies -
6, nodes: 43á027, shortcuts:5á368, dijkstras:543á579, t(dijk):0, t(period):0, t(
lazy):0, t(neighbor):0, meanDegree:1, totalMB:102, usedMB:93
2013-07-28 14:05:27,284 [main] INFO routing.ch.PrepareContractionHierarchies -
7, nodes: 38á725, shortcuts:11á771, dijkstras:754á369, t(dijk):1, t(period):1, t
(lazy):0, t(neighbor):0, meanDegree:1, totalMB:102, usedMB:83
2013-07-28 14:05:27,471 [main] INFO routing.ch.PrepareContractionHierarchies -
8, nodes: 34á423, shortcuts:15á045, dijkstras:769á277, t(dijk):0, t(period):0, t
(lazy):0, t(neighbor):0, meanDegree:1, totalMB:102, usedMB:94
2013-07-28 14:05:27,737 [main] INFO routing.ch.PrepareContractionHierarchies -
9, nodes: 30á121, shortcuts:19á095, dijkstras:786á345, t(dijk):0, t(period):0, t
(lazy):0, t(neighbor):0, meanDegree:1, totalMB:102, usedMB:23
2013-07-28 14:05:29,268 [main] INFO routing.ch.PrepareContractionHierarchies -
10, nodes: 25á819, shortcuts:22á980, dijkstras:948á972, t(dijk):1, t(period):1,
t(lazy):0, t(neighbor):0, meanDegree:1, totalMB:102, usedMB:42
2013-07-28 14:05:29,502 [main] INFO routing.ch.PrepareContractionHierarchies -
11, nodes: 21á517, shortcuts:26á575, dijkstras:968á233, t(dijk):0, t(period):0,
t(lazy):0, t(neighbor):0, meanDegree:2, totalMB:102, usedMB:26
2013-07-28 14:05:29,956 [main] INFO routing.ch.PrepareContractionHierarchies -
12, nodes: 17á215, shortcuts:36á715, dijkstras:1á008á805, t(dijk):0, t(period):0
, t(lazy):0, t(neighbor):0, meanDegree:2, totalMB:102, usedMB:19
2013-07-28 14:05:31,706 [main] INFO routing.ch.PrepareContractionHierarchies -
13, nodes: 12á913, shortcuts:46á628, dijkstras:1á179á806, t(dijk):1, t(period):1
, t(lazy):0, t(neighbor):0, meanDegree:3, totalMB:102, usedMB:41
2013-07-28 14:05:32,252 [main] INFO routing.ch.PrepareContractionHierarchies -
14, nodes: 8á611, shortcuts:52á756, dijkstras:1á229á006, t(dijk):0, t(period):0,
t(lazy):0, t(neighbor):0, meanDegree:2, totalMB:102, usedMB:36
2013-07-28 14:05:33,127 [main] INFO routing.ch.PrepareContractionHierarchies -
15, nodes: 4á980, shortcuts:60á474, dijkstras:1á310á347, t(dijk):0, t(period):0,
t(lazy):0, t(neighbor):0, meanDegree:2, totalMB:102, usedMB:44
2013-07-28 14:05:34,862 [main] INFO routing.ch.PrepareContractionHierarchies -
16, nodes: 1á988, shortcuts:68á133, dijkstras:1á466á660, t(dijk):1, t(period):0,
t(lazy):0, t(neighbor):0, meanDegree:3, totalMB:102, usedMB:25
2013-07-28 14:05:37,565 [main] INFO routing.ch.PrepareContractionHierarchies -
new shortcuts 77103, FASTEST|CAR, CAR, removeHigher2LowerEdges:true, dijkstras:1
687619, t(dijk):2, t(period):0, t(lazy):0, t(neighbor):1, t(all):17, meanDegree:
1, periodic:3, lazy:10, neighbor:20
2013-07-28 14:05:37,565 [main] INFO com.graphhopper.GraphHopper - flushing grap
h LevelGraphStorage|CAR|RAM_STORE|1,2,1,1,1, details:edges:170á375(7), nodes:64á
537(1), name: - (1), geo:212á145(1), bounds:13.072623790933724,13.76397193440732
3,52.333507739011374,52.67961645900346, totalMB:102, usedMB:43)
2013-07-28 14:05:37,831 [main] INFO storage.index.Location2NodesNtree - locatio
n index created in 0.17943482s, size:70á251, leafs:2á144, precision:500, depth:3
, entries:[64, 16, 4], entriesPerLeaf:32.766323
2013-07-28 14:05:37,831 [main] INFO graphhopper.http.DefaultModule - loaded gra
ph at:berlin-latest.osm-gh, source:berlin-latest.osm.pbf, acceptWay:CAR, class:L
evelGraphStorage
2013-07-28 14:05:37,877 [ThreadPool Service Executor] INFO graphhopper.http.GHT
hreadPool$1 - ThreadPool Service Executor STARTED
2013-07-28 14:05:38.127:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppCo
ntext@b58e73{/,file:/D:/TEMP/jetty-0.0.0.0-8989-graphhopper-web-0.2-20130720.103
500-2.war-_-any-/webapp/,AVAILABLE}{file:/F:/graph/graphhopper-web-0.2-20130720.
103500-2.war}
2013-07-28 14:05:38.221:INFO:oejs.ServerConnector:main: Started ServerConnector@
1dc5ca2{HTTP/1.1}{0.0.0.0:8989}
2013-07-28 14:06:51,743 [qtp18690598-84] INFO graphhopper.http.GraphHopperServl
et - point=52.55068,13.351994&point=52.552246,13.414135&type=jsonp&callback=jQue
ry17207699428807042888_1375013204119&_=1375013211594 0:0:0:0:0:0:0:1 de_DE Mozil
la/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 52.55068, 13
.351994->52.552246, 13.414135, distance: 4.712710000000001, time:6min, points:25
, took:0.097469926, debug - idLookup:0.026840562s, algoInit:0.05424907s, dijkstr
aCH-routing:0.013433551s, extract time:4.41397E-4, simplify (86->25):1.70692E-4s
, instructions:0.001413028s, dijkstrabi, fastest, CAR
Noch einmal herzlichen Dank dafür.
Danke fürs Ausprobieren! Habe das mit JRE6 nochmal explizit im troubleshooting geschrieben + auf die alter jetty runner version verlinkt!
Die UnsupportedClassVersionError mit Unsupported major.minor version 51.0 bedeutet, dass die Java-Version auf dem Rechner des Benutzers älter ist als Java 7. Version 51 ist das Format des Java-Bytecodes von Java 7.
Zu dem Fehler kommt es, wenn ein Entwickler Code für Java 7 kompiliert aber der Endbenutzer ein Java älter als Version 7 hat. Zur Abhilfe muss der Entwickler Code für ältere Java-Versionen kompilieren oder aber der Benutzer mindestens Java 7 verwenden.
Das jetty team hat sich entschieden mit version 9 nur noch Java 7 (und höher) zu unterstützen. D.h. da kann ich nix machen nur die alte version verlinken.
GraphHopper selbst läuft ab Java6, aber auch auf Android (>=2.2) was nicht alle features von Java6 beherrscht…
Heute ist mir aufgefallen, dass immer nur ganze Streckenstücke zur Asuwahl stehen. Je nachdem wo der Marker steht wird immer der Anfang oder das Ende der Strecke gewählt. Wäre es nicht auch möglich zu interpolieren?
In der Offline Version habe ich es mit dem Configfile bisher nur geschafft Car zu routen. Nicht aber wie in der Onlineversion verschiedene Verkehrstäger. Man kann zwar den Graphen auf FOOT umstellen, aber die onlineabfragen laufen dann ins Leere, weil kein Car zu gelassen ist.
nächste version gibts das ja 
Also zum offline routen via FOOT muss der graph auch via FOOT präpariert werden. Die Dateien die du momentan von meinem server bekommst sind via CAR präpariert. D.h. du musst die Daten für dein Gebiet mit FOOT selber erstellen und noch ne mapsforge map reinkopieren. Dann sollte es gehen.
ODER du kannst dir das Präparieren für kleine Gebiete wie Städte auch sparen. Dazu musst du prepare.chShortcuts auskommentieren. Und anstatt hopper.forMobile() machst du dann auch hopper.setSimplifyRequest(false).setInMemory(true, true) und gibst ‘astar’ oder ‘astarbi’ als Algorithmus beim Anfragen an. Damit sollte es auch okayish schnell sein und du kannst auf deinem Graphen FOOT, BIKE oder CAR berechnen (oder deinen eigenen).
ODER Wenn du auf dem Android die Webversion anfragen willst, so sollte eigentlich alles funzen einfach via GraphHopperWeb …
Das klingt doch sehr gut. Wann kommt die version?
Mhh das war mir doch etwas zuviel “Latein”. Ich habe einfach versucht in der config-example.properties diese Zeilen zu ändern
# possible options: CAR,FOOT,BIKE (comma separated)
osmreader.acceptWay=CAR
Aber egal ob FOOT oder BIKE statt CAR es führt nur zu fehlern. Auch das löschen des Graphen vorher bringt keinen Erfolg.
wenn sie fertig ist 
also du kopierst dann aber die Dateien aufs android? ich hatte zu viel antworten präsentiert, da mir nicht ganz klar war was du machst. am besten du beschreibst mal schritt für schritt.
Die Android spezifischen Beschreibungen hast du aber gelesen, oder? https://github.com/graphhopper/graphhopper/wiki/Android
Ich mache nichts anderes als unter Quickstart https://github.com/graphhopper/graphhopper/wiki/Quickstart beschrieben ist. Nur das bevor ich Punkt 5 ausführe noch die Config Datei anpasse. Danach erhalte ich aber auf dem Desktop keine zu gebrauchende Version mehr.
Ein Versuch unter Android scheitert im Moment. Ich habe mir zwar das APK runtergeladen und auch installiert. Allerdings behauptet die Anwendung keine Internetanbindung zu haben. Damit bleibt die Option Download außen vor. Aber auch local bleibt das Auswahlmenü leer. Wohin sollte man da etwas verschieben? Er legt auf dem Internen Speicher kein Verzeichnis an.
Hi Peter,
will Dir mal bisschen die Geschichte von meinem Projekt (BRouter) erklären bzw. Dich motivieren, diesen Punkt ernster zu nehmen. Ich hab’ auch so angefangen, in die Datenfiles interpretierte Tag-Informationen zu schreiben, also am einfachsten direkt den Kostenfaktor (Du arbeitest mit SPEED-Werten, das ist einfach der Kehrwert, aber völlig egal).
Es war aber schnell klar, dass das zu unhandlich ist, also habe ich das refactored, um in den Datenfiles mehr oder weniger die Roh-Information zu speichern und die Interpretation nachgelagert zu machen. Das hat das Tuning der Routing-Profile enorm beschleunigt. Verschiedene Gewichtungen zu testen machst Du einfach nicht, wenn Du dafür jedesmal die Karte durch den Wolf drehen musst. Anfangs hab ich aber versucht, die Ausgangsinformation zu einer Wegbeschreibung in einen 32-bit Wert zu packen, was sich als Riesendummheit erwies, weil man dafür viel zu viel Information verwerfen muss und letztlich aber die Weginformation doch nur den kleineren Teil der Datenfiles ausmacht.
Also hab’ ich’s auf 64 bit erweitert, einfach weil das ohne struktrellen Umbau möglich war, und so ist es bis heute, aber es ist halt immer noch Murks: die Information ist limitiert, manche Way-Tags sind einfach nicht drin, und aus den Relationen hab ich mir nur ein einziges synthetisches Way-Tag abgeleitet (=Rad-Relation ja/nein).
Es ist also immer noch eine Krücke und muss nochmal refactored werden, um beliebig viele Tags kodieren zu können und vor allem, um die zu-Many Beziehung zu den Relationen richtig darzustellen: es muss möglich sein, zu einem, Way zwei Rad- und einer Wander-Relation zu kodieren, und da wird das Datenmodell dann schwierig, zumindest, wenn es noch kompakt und effizient sein soll
Also denk mal drüber nach, wohin Du Deine Kreativität lenkst. Die wirklichen Heraussforderungen stecken vielleicht nicht da, wo Du sie vermutest. Bei OSRM ist es krass, alles Engeneering in scheinbare technologische Perfektion, aber völlig am Bedarf vorbei, Radrouting kann er nicht, weil er keine Hardware für den zig-GB Cache übrig hat und MassenRequests (z.B. aus Trevelling Salesman-Anwendungen) bedienen tut er nicht, weil’s den Server belasten könnte. Wissenschaftler halt. Diese Nische ist also schon besetzt.
Nee, da hast du mich missverstanden. Das sind contraction hierarchie daten … wenn man CH nicht braucht gibts diese Einschränkung auch nicht.
Verstehe ich nicht. Das setzt doch einen eigenen auf (??). Ich glaube nicht dass dein Server das verkraften würde … zumal none-CH requests auch meist ne Menge RAM brauchen.
Ich glaube du siehst das alles viel zu schwarz ich sehe GraphHopper nicht als Konkurrenz zu irgendetwas. Auch nicht zu deinem router. Wäre natürlich cool wenn der Open Source wäre dann könnte man voneinander lernen …
Ich habe noch einen Wunsch für das interpolieren der Position bei Strecken.
Wenn man an ÖPNV Routing denkt, wäre es ganz sinnvoll, wenn von dem Startpunkt auf der Strecke immer nur nach rechts abgebogen werden dürfte. Das würde dann einer Haltestelle neben der Strecke entsprechen, welche immer nur in der einen Richtung bedient würde, während die Haltestelle auf der anderen Straßenseite der anderen Richtung entspräche.
Ja, die API wird so angepasst werden (müssen), dass die Richtung mit angegeben wird - anstatt zweier Knoten bekommt der Algorithmus zwei Kanten.
Was ist jetzt genau eine Kante? Ist das die Strecke A-B und B-A oder nur eine von beiden Strecken? Mir geht es darum das wenn der Startpunkt rechts daneben liegt nur nach oben geroutet wird und wenn der Knoten Links daneben liegt nur nach unten. Praktisch wie eine Einbahnstraße.
Also ich werde bei der zukünftige API so eine Option anbieten, ja. Aber nur anhand von “GPS Koordinate liegt etwas rechts neben der straße” werde ich das in der offiziellen UI nicht anbieten können. Natürlich kannst du das aber in deine UI einbauen.
Das klingt doch sehr gut. Ist die API irgendwo dokumentiert oder muss man das aus dem Code ersehen?
Nur durch unit tests dokumentiert aber besser als nix und man sieht dadurch wie man die API benutzen sollte. Etwas Doku gibts auch im wiki
Hallo zusammen,
ich lese mit Entzücken, dass sich hier zwei sehr kompetente Entwickler austauschen :-).
Als oller Radfahrer muss ich sagen, dass Brouter da aktuell noch deutlich besser ist. Was Brouter kann, habe ich bislang selten gesehen. Aber ich freue mich unheimlich, wenn das Interesse für optimiertes Offline Fahrrad-Router zunimmt! Wenn dadurch in den Städten ein paar Autos weniger unterwegs sind, ist das schon eine riesige Errungenschaft :-).
Ich wünsche beiden Entwicklern alles gut und bin ihnen unheimlich dankbar für diese Bewegung 
:).
Fröhliche Weihnachten an alle!!