I am currently hosting it on Azure and was looking for ways to save up money.
For France (4GB pbf) with 3 profiles (car, bike regular & hiking) I am currently paying 150$+ a month (Azure Container Instances: 3* (1vCPU + 12GB RAM)).
Since the rule of thumb is to allocate 2*(pbf file size) in RAM, I tried to see if filtering out nodes not needed for directions in the pbf file would help reduce the RAM requirements. I did something like this: osmium tags-filter osm-file-full.pbf nwr/highway nwr/route -o osm-file.pbf
and was able to go from 4GB to 880MB. My hypothesis was then that 2GB should now be ok. I tried with 6GB (since i knew the normal file would require 8) and got java.lang.OutOfMemoryError: Java heap space.
Am I then to assume that filtering out nodes in the pbf file cannot help (since the graph is only using routes / highways tags anyway)? If so, any tips for reducing the server hosting bill (I would like to host the full planet at some point)?
yes, filtering nodes and ways from the pbf beforehand will reduce parsing time, but not graph size, since as you correctly states ors mostly only uses highway=* nodes and ways (and some others).
Regarding reducing a server hosting bill, maybe @adam has some ideas?
I’m new to ORS and have had exactly the same thought as @loulou and that answers my question in the first instance. However there is perhaps something more that I can do. I’m only interested in the car profile. Not HGV, not bike, not hiking etc. So my question is - which are the only highway types required for the car profile? If I could filter out bike / hiking etc. or trails / roads not suitable for cars then would that reduce the graph (and associated RAM requirements) size? Or is that done automatically during the build process?
have a look here for the tags used for car.
However, the same reasoning as above applies - filtering them from the pbf before will probably reduce build time, but not graph size.