Yeah, I agree those days should be excluded.

Updated list here!

Good job! 😀😀😀😀😀

The piece I was missing is that a single range request can ask for multiple non-adjacent ranges, so you can request an arbitrary number of non-sequential tiles in a single request. Thanks for the explanation.

I saw Brandon’s presentation on pmtiles at SOTM US in Richmond but didn’t really grok the significance. I now understand better what many of the advantages are, but I don’t know enough about cloud services to understand the big reduction in cost. Is it because AWS charges based on number of files so by putting everything in a single file (and use range requests) you can hack the usage fees? I’d really appreciate a more thorough explanation.

So nice to see the fluent use of bash and the unix toolchain for this. It feels like it’s a dying art.

There is a QA tool (I unfortunately don’t recall which one) that does something similar, but also ensures that the POI name appears somewhere on the first page of the site. With a slightly longer awk script you could do the same.

Very nice!

You can also read the changeset data already hosted on AWS rather than uploading it yourself: osm.org/user/Jennings%20Anderson/diary/394762

@Aurimas Fišeras You’re right, and your streak is incredible! Table is updated with improved data.

Lots of locales have food carts that never get mapped since they’re not permanent structures, but are still relatively permanent establishments.

Thanks!

Lorry driver joke is inappropriate (and not in the TW version).

If anyone else is curious about the map access statistics referenced here, it’s the number of times each map tile has been served by the tile server: https://planet.openstreetmap.org/tile_logs/

Very interesting!

I didn’t know about pbzip2, which I agree might be a big time saver. But the documentation says the input needs to have been compressed with pbzip2 to yield a speed up during decompression. Is that the case for the planet file dumps?

Okay it’s working now. It would be great to have a button to zoom to your current location.

I don’t see any markers on iOS using either Safari or Firefox Focus (didn’t try other browsers).

A little more analysis, looking at the year the data was created indicates that new data is using Unicode, we just need to clean up the old data:

Should have pushed Preview before Publish:

• 298 MAPS.ME
• 295 iD
• 121 JOSM
• 28 Vespucci
• 5 OSM Contributor
• 1 Potlatch
• 1 Go Map!!

It seems that as long as the editor apps enforce display of the data using Unicode, and intentionally not support Zawgyi and other non-Unicode fonts, that users will naturally be pushed to “do the right thing” when adding new data, or updating old data.

I went through your file and pulled statistics about where the non-Unicode strings originated (to simplify things I only looked at objects that were version=1): 298 MAPS.ME 295 iD 121 JOSM 28 Vespucci 5 OSM Contributor 1 Potlatch 1 Go Map!!

Around 10 mappers are responsible for > 50% of the strings, so perhaps a direct appeal to them would be effective. It’s not clear whether the non-Unicode strings are intentional or simply a lack of guidance.

While I agree that having native speakers do the translations is ideal, it would also be easy to have the same Google toolchain you used to do detection also do the “best guess” conversion to Unicode. Then native speakers could just confirm/fix the conversion. Or, if you want to be really fancy, you could display the Zwangyi font and Unicode font side-by-side and user’s could just confirm they’re visually identical.