151–156 of 156 posts
This looks really great! Do you offer an api as well? I'm part of the team behind https://cyclema.ps and we'd love to see if we could incorporate this as a backend.
Sorry, forgot to mention. The planner is a mess on mobile I totally forgot to make it mobile friendly as I didn't think anyone would want to plan their trip on a phone.
Interesting assumption. My mind goes to to a) Most people are mobile first and b) In this category of app, i imagine people want the route with them on their phone as they bike (as they're probably unfamiliar with the route, hence the need to plan it) Cool idea, i'd love to try it but honestly i'd love it on my phone for the aforementioned reasons! --- Edit: Some follow up remarks (From Chrome on a Mac) 1. I found it…
Regarding state: it's only a matter of changing the blacklist array in redux persist config. Right now I have all global state blacklisted because I noticed a small bug with rendering the map layers when the state is persisted and I didn't have time to fix it but in the next version it will be persisted in localstorage.
Earlier quoted context omitted.
Hey karussell, I really appreciate all the hard work you’ve put into Graphhopper. I wouldn't be able to create this project without GH. I have a question about memory usage during the import stage (specifically in the OSM Reader's preprocessRelations function). I'm using a HashMap > to map way IDs to OSM bike route relation IDs, which means allocating lots of arrays. Could this be causing me to run out of heap memory…
Love your project! Maybe you already considered, but there are a number of collection libraries out there that are optimized for holding Java primitives and/or for very large sets of data, which could help you save significant memory. Eclipse Collections [0] and Fastutil [1] come to mind first, but there are many out there [2] [0] https://github.com/eclipse-collections/eclipse-collections [1] https://fastutil.di.unim…
Earlier quoted context omitted.
Love your project! Maybe you already considered, but there are a number of collection libraries out there that are optimized for holding Java primitives and/or for very large sets of data, which could help you save significant memory. Eclipse Collections [0] and Fastutil [1] come to mind first, but there are many out there [2] [0] https://github.com/eclipse-collections/eclipse-collections [1] https://fastutil.di.unim…
Thank you! I'm a total Java noob - actually, this is the first project where I've written any Java code (had to slightly modify the Graphhopper source code to suit my needs). Those libraries look very interesting. I'm saving this post for another battle with processing maany GBs of OSM data :D
Another trick for planet size data structure could be to use a List instead of the Map and the OSM ID as index. Because the memory overhead of a Map compared to a List is huge (and you could use DataAccess) and the OSM IDs for planet are nearly adjacent or at least have not that many gaps (as those gaps are refilled I think).
All these tricks (there are more!) are rather tricky&low level but necessary for memory efficiency. A simpler way for your use case could be to just use a database for that, like MapDB or sqlite. But this might be (a lot) slower compared to in-memory stuff.