Hacker News Reader

Comment by phabricator | Hacker News Reader

This is an advertisement, I was hoping it would be about cartography. I don't mind plugging your product at the end but "Why are maps so hard to make?" is never answered.

> creating and collaborating a map today is not much easier than it was in the 90s

Yes, yes it is. It is MUCH easier. This product looks nice but there's no insight here.

View on HN

Well if you're looking for some insight, I've recently had the (dis?)pleasure of implementing tile rendering for a web satnav type thing for a mobile robot with OpenStreetMap.

Tile servers are an interesting thing, there's 70 TB of data composed of 256x256 prerendered images on one end, and a user wanting a picture that goes below some weird angles they have on the other.

They call the map setup a "slippy map", and it's composed of up to around 20 zoom levels, each one being a subdivision of the previous one. So the first tile covers the entire planet, the next one is split into 4, and then into 16, etc. Level 20 zoom which is used to be the max offered by OSM (now only 19 it seems) is roughly a trillion tiles, each measuring up to about a 40 meter square. https://wiki.openstreetmap.org/wiki/Zoom_levels

Anyhow, these tile servers let you request tiles in a somewhat standard format of http://url.com/zoom/x/y.png. X and Y not being the latitude and longitude of course, but they are tile indexes which have an entire wiki page on their calculation in most languages you'd want: https://wiki.openstreetmap.org/wiki/Slippy_map_tilenames

But wait, we live on a spheroid don't we? Projecting a sphere onto a flat plane has always been a futile endeavour (https://xkcd.com/977/) but what's used by functional maps at large seems to be Mercator. It's mostly fine, but it does have this tiny issue that the tiles aren't all the same size in all places. So for example at max zoom Saudi Arabia gets 0.149 m/pixel while Iceland only gets 0.06 m/pixel, which means you need more tiles the further away from the equator you go. How many do you need at the poles you ask? Well...

I'm not entirely sure how this tile size fits together with the fixed subdivision setup, but boy am I glad I didn't need to figure that out. Luckily if you're rendering just one part of the map at high zoom you can just scale it properly, tile it sequentially, and you can forget the rest of these shenanigans and treat it like it's linear space. If you can live with that it's not too hard.

The tile size doesn't change, but the number of pixels per meter does as you note--distortion being greater the farther you get from the equator (in the Mercator projection).

The protomaps blog has some heady stuff you may enjoy reading: https://protomaps.com/blog/free-tier-maps. Felt apparently uses protomaps.js, which you can learn more about in that blog as well.

Well tile size in meters changes. Pixels stay the same but when a tile is rendered at a specific zoom level of meters/pixel on the screen it needs to be scaled differently and you may even need to request another ring of tiles to fill up the same FoV. Perhaps that was just a specific quirk of my application since I needed to overlay a metric grid with other data.

Thanks for the link, that was an interesting read. Though it seems odd to me that they insist on using AWS and complain about bandwidth when there are providers like Scaleway that do not charge for bandwidth usage at all. Though on the other hand they do only have EU locations so you can't use the CDN principle to reduce latency. But I'm sure people would wait a second longer if it meant a free API.

I don’t get it, projecting a curved surface onto a flat surface given some constraints isn’t even grad school level math. The 2D Map is hard because it requires knowledge of undergrad Math?

Assuming your not not seeking to create a perfect representation of 3D reality since that is impossibly hard.

> Assuming your not not seeking to create a perfect representation of 3D reality since that is impossibly hard.

Come on Micheal, English isn't hard. Even an undergrad can write better than this.

If you mean the best undergrad in the world can write better than that yes, I agree. If you mean the median I would disagree since worse spelling mistakes are commonly made. Assuming everyone’s using a tablet with 15 seconds of free time and auto spell check turned off.

What’s your point?

> What’s your point?

Just as you had a reason for making errors in writing they may have had a reason for engineering OSM the way they did.

Our whole subthread is off-topic for this site, it was a mistake on my part to turn this around on you. Reminder of site guidelines: https://news.ycombinator.com/newsguidelines.html

Right, but I don’t claim that writing on HN is fundamentally hard, or that I went through a great effort to write comments here. And I would expect for someone to call me out on it if I did.

Even the most charitable view of the parent comment would indicate that there was an erroneous belief that a perfect, or near perfect, map would only be finitely more difficult, and achievable in finite time. Whereas in reality the difficulty and time required asymptomatically approaches infinity.

Projecting a curved surface onto a flat surface is easy. Doing it without distortions is well, basically impossible.

Right, that’s my point. Anyone with knowledge of undergrad math would understand a perfect projection is impossible whereas a less than perfect projection is easy.

Is there a reason OSM uses image tiles? I think Google Maps has been serving vector tiles since 2010.

I read somewhere was that apparently vector data would be too slow to render on the client for some reason. Now that's likely to be somewhat true for the low zoom tiles where you need to render out an entire continent worth of roads and borders, but the more you zoom in the more the trade-off becomes in favour of using svgs instead since there's less overall data on screen.

I bet you could also move away from the tile system if you used vector graphics, since the client can just render its own seamless zoom levels and then request specific data based on what it can comfortably display. I'm sure Google, Bing, etc. have already implemented all that ages ago.

KDE Marble can render vector OSM data on my under powered Pinephone in real time.

Yeah that statement may have been completely accurate 15, maybe even 10 years ago, but gets less and less true as time goes on. After all OSM was apparently conceived in 2006.

I used this last weekend, I'm not sure what you're talking about.

Ah, re-reading what I wrote I see I made it ambiguous. The statement I'm talking about is "vector data would be too slow to render on the client", not your comment.

Reply on news.ycombinator.com