Why not ask your question on the new OpenStreetMap Community Forum?

Hi All Considering I have a private instance of the world with 96gb ram

Is there a theoretical limit per second on how many reverse geocodes per second (with road speed) is possible?

I saw a limit of around 25/sec with 48gb ram, and i'm wondering if with whatever spec I can scale to 500 per second

Is this a figure that is just unrealistic on one server? or possible? Does anyone have any approx figures of what might be possible per sec?

asked 23 Mar '19, 00:32

Mark%20Davies1664's gravatar image

Mark Davies1664
accept rate: 0%

Many systems that have requirements like that are badly designed - for example, I have seen in-car location trackers that would transmit their location every second and a backend that would reverse geocode them all even if the location had only changed by 3 centimetres since the last transmission, or it would geocode them all even if nobody was looking. In many cases, a clever re-design can bring down the number of reverse geocoding queries by a factor of 10 or even 100 without any UI degradation.

I haven't yet build a 500 query/second server but if I wanted to, I would probably build a machine that holds the complete database in RAM, and take steps to minimize the size of the database - not only to save $$$ on RAM but also for increased performance. For example, import only data for areas you will actually be using. If you know that 95% of your queries will be within country A but you want to support world-wide queries nonetheless, then build a super-fast RAM-only server serving only the rectangle that contains country A, and forward queries outside to a slower, world-wide server. If you don't need house numbers, don't import them, and so on.

permanent link

answered 23 Mar '19, 10:04

Frederik%20Ramm's gravatar image

Frederik Ramm ♦
accept rate: 23%

thanks, that is an interesting reply in regarding to caching. I'm already discarding geocoding if the movement is less than 10 meters to limit the amount of requests. I've also seen another geocoder called photon which claims to be faster.

my application is vehicle tracking, and i need just roadnames and roadspeed so not sure if there is any other data in the DB that is bloating the data set that I can safely remove, I'm using roadspeed data on every lookup to check for incidents of overspeeding so if i move it to UI based rather than data import, I lose that functionality.

(25 Mar '19, 05:29) Mark Davies1664

Nominatim contains buildings and address points which would seem useless to you. I'm not sure if simply deleting them is a good way forward, as it is likely to first search for a building/address point and only if that is not found will it fall back to searching for a street, so even if you delete buildings there'll be some time wasted here. Perhaps it makes sense for you to dive a bit deeper into the source and try to eliminate checking for buildings in the first place. -- Having said that, a geocoder is not the best tool for your task since it will give you the nearest road to the GPS fix, rather than the road most likely travelled on. You will have many false alerts when e.g. a fast road is used and your GPS is just a little off near an intersection and you'll match the slower road. More reliable/stable results can be had from a routing engine's track matching feature.

(25 Mar '19, 07:00) Frederik Ramm ♦

Thanks Frederik, can you suggest some areas for me to start looking for a routing engine?

(25 Mar '19, 11:33) Mark Davies1664
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 23 Mar '19, 00:32

question was seen: 1,909 times

last updated: 25 Mar '19, 11:33

powered by OSQA