The Next Generation of OpenStreetMap — in Python!

[pnorman (Paul Norman)]

@Minh_Nguyen

Besides osm.org, other deployments of openstreetmap-website are running in environments with different characteristics. I’m not in a position to say with any certainty, but anecdotally, CGIMap has very significantly improved the user experience on OpenHistoricalMap. That project was all but forced to switch to CGIMap because the /map command simply couldn’t handle the data volume and density in some parts of that database. Now the browser is the performance bottleneck, which is a good problem to have.

cgimap was deployed for calls other than map as part of my GSoC a number of years ago. It makes a huge difference.

My understanding of the issues with the rails map and other API calls is that their slowness is a combination of poor queries from the ORM and how objects are created/serialized in the code. Keep in mind the rails map call was written 16-17 years ago, and no one has bothered to optimize it because we have cgimap, and rails has also changed as a language since then.

Code that no one uses doesn’t get worked on.

My understanding is that most of the time was spent creating and serializing objects, but I don’t have details for the same reason - we use cgimap.

I don’t know how the performance of an optimized rails implementation would compare to an optimized python implementation or the current optimized C++ implementation. I expect all would be faster than the unoptimized rails implementation by as much as an order of magnitude.