How to compile OsmConversionPipeline

[ravenfeld]

Hello, I know that the project is old but not finding a solution I test all that exists ;)
I'm looking to do routing on my Android phone in offline. I just want it to use the paths if it happens I will fix it by hand. I tried graphhopper but for France I have the ram of the phone that explodes.

I could understand that your project you cut in small pieces which looks good. I can't seem to use the software to cut my pbf.

If you remember, please help me.

[ravenfeld]

I managed to get ahead. If you want I'll make you a mr I had to fix the pom.xml

Otherwise I have a problem, some bridges I can't get over. I'll see if I understand the problem. In any case level ram it is top.

[jgrunert]

Sure, that would be great. Surprised that this still runs at all after all those years!

Not sure about the bridges, maybe a new road type the import pipeline doesn't support?
Also one quirk about the routing algorithm, I made the A* overestimate so that it routes quicker along highways, in some cases that can lead to optimal paths not being discovered but makes it much faster.

[ravenfeld]

Thank you for answering me.

I don't know if you are still interested in the project but I think your help could be welcome.

What I see for the moment:

• The result is in the opposite direction of start and target.
  

If I do a reverse on the list the result is better.

• I also notice that the result always ends on a node so I have this.
  

• I still don't understand why some paths are taken or not especially since they are taken at other times.
  

• If I have the expression that we must use the whole length of a path and not just between the nodes of it.
  

I hope to be able to correct it but if you could help me it would be nice because I don't understand anything.

Why am I looking at your project?
I'm looking to make sure that when I give a start and end point to use the highways to not have a straight line.
I tested graphhopper, brouter, valhalla but it's quite difficult to set up for some and for graphhopper it doesn't manage several regions and if your region is too big you blow the ram of your phone because I want to do it in offline without using a server or api.
What I found with your project is that on the ram and cpu level it is the most economical without being the slowest especially since I'm not looking to find the best paths even if it's a plus but just to use the highways so that the user does not create all the points.

Do you think it's difficult to add the altitude data?

I know that your project is quite old but if you have time and desire to help me it's with pleasure.

https://gitlab.com/ravenfeld/android-maps-viewer

[ravenfeld]

I think I understood one of the problems is that you are working with intersection nodes and not all nodes. You get them back afterwards to reconstruct the path.

So I don't know yet if it's in Android or in the export that I have to find how to modify but working with everything could also remove this error.

The problem is that we are looking for the closest node to the start and finish point but shouldn't we work with the node + edge? I'm afraid that the optimization level is momentary, maybe just for the beginning and the end?

What you should have if possible.

[ravenfeld]

Just to say that I corrected the concerns I had. It's not optimal but now I have some that work almost fine.
If some need the code it's available here https://gitlab.com/ravenfeld/android-maps-viewer

[jgrunert]

Hey,
It is a really long time ago so my memory is quite spotty - and I don't have much time to check the code again.

Yes I think removing redundant nodes between intersections was one of the key parts that made the routing possible. Other optimizations were the dynamically loaded grids and use of lookup tables because at least in 2016 trigenometric functions were extremely slow.

Briefly looking at AStarRouteSolver.java it seems that the skipped nodes are reconstructed later. Using all the points would have exceeded the RAM, only with the node skipping and dynamic grids it was possible to do it offline.

And indeed this algorithm can lead to suboptimal results in quite a few cases, it was mostly a proof of concept for a university project, focused on mostly correct long routs - it can certainly be improved :)
That said it performed quite good and mostly correct on German routes across Germany.

For adding altitude data I guess you have to adapt the format and pass it through the data pipeline.

[ravenfeld]

Thanks for the feedback, as I said in my last post I have a few things working right now. There are still some issues but it's not too blocking I might fix them one day.
In any case you are the only project that allows you to do something offline, if one day I master the subject better maybe I'll make a lib because there is a little bit of domain especially in outdoor app.