mmd

Out of curiosity, I looked at dulcy‘s munin stats and wonder where this might hit a bottleneck in the near future. CPU seems somewhat busy (with high system time!) but...

First of all, it's quite difficult to assess the situation from the outside with only munin stats at hand. So please bear with me if the following is too much...

According to https://munin.openstreetmap.org/openstreetmap.org/dulcy.openstreetmap.org/cpu.html and https://github.com/openstreetmap/operations/issues/337, Nominatim doesn't appear to be overloaded anymore. Closing again until next time?

Augmented diffs (as described here https://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs ) are somewhat computationally expensive (at least when using an official Overpass release), in particular as they're only cached for a few hours on...

Given that augmented_diffs just boil down to a simple QL query covering a one minute interval (eg. https://overpass-api.de/api/augmented_diff?id=4983215&debug=true ), updating once per day would indeed be a massive overkill. A...

> it would be super to just increase the tagvalue length in the database to something like varchar(2000), bump the API minor version, and move on That will for sure...

Yeah, right, my point was more to raise a bit of awareness to think about such a change in a much wider context. People tend to be too much focused...

After all, the API supports 255 Unicode characters. Instead of writing `13:00` you can simply write 🕐 which counts as a single character. This saves a whopping 4 characters already,...

To answer your question: cgimap is already prepared to run multiple API versions in parallel (assuming this is somehow meaningful from a data model pov). Not sure about the Rails...

Hmm... API 0.6 has no way to convey an out-of-band information about tag values having more than 255 characters. So whatever schema you use to abbreviate long strings, you still...