I worked on a system at Martin Marietta in the late 80's and early 90's where we created tiled maps for use by the US Army. We had a large scanner we'd use to scan their maps, then we'd georectify the scan and slice the result up into tiles of 128x128 pixels which would be compressed before storing to a whopping 360 Meg hard drive. I participated in a number of Army field exercises in the US and Europe where we'd show the digital maps and graphic overlays off to troops who were using paper maps with little paper icons they move around to reflect the current situation. Our capability never went anywhere because Management wasn't really into map-maping and the Defense Mapping Agency started doing it themselves, distributing their maps on CD.
I don't understand. There were loads of online maps before Google maps and they all used tiles. How else would you do it? What Google added was smooth panning between tiles, pretty much as soon as native browser technology was up to the job. If they hadn't someone else would have.
Fair enough, but these were solutions that worked without js, and they weren't dynamically rendering maps on the front or back end. They were just showing squares of pre-rendered bitmap, and the square boundaries were fixed. If your point of interest was near an edge it could be quite annoying, like trying to navigate somewhere in the gutter of a paper atlas.
Even if they'd had an API that took a viewport, the result would have been stitched together from bitmap tiles because that's what they had.
It seems like the "invention" of tiles for maps must have happened as soon as anyone starting using a computer to render maps to bitmaps. The Ordnance Survey wouldn't at any point have rendered the entire UK to a single bitmap (at least not a map with any detail). It would have always been tiled.
Edited to add: Actually, the invention was much earlier than that. Paper maps were tiled before computers were a thing. And this would naturally have carried over to computer-rendered maps.
Read latitude/longitude/zoom parameters from the request and render a map image on demand. It's slow and inefficient, but it's simple to implement and I suspect it's what most of the first-generation mapping services did.
Yes, to me it's the canonical way to represent maps on a computer, that anyone could come up with after spending a bit of time pondering the question. And it looks rather straightforward to implement, probably a bit less so with ancient browser tech.
I worked on supercomputer algorithms to render planetary terrain data (image plus digital elevation) using tiling back in the early 90’s. I’m not sure where my co-worker got the idea, but it seemed like an obvious thing to do.
I worked on a system at Martin Marietta in the late 80's and early 90's where we created tiled maps for use by the US Army. We had a large scanner we'd use to scan their maps, then we'd georectify the scan and slice the result up into tiles of 128x128 pixels which would be compressed before storing to a whopping 360 Meg hard drive. I participated in a number of Army field exercises in the US and Europe where we'd show the digital maps and graphic overlays off to troops who were using paper maps with little paper icons they move around to reflect the current situation. Our capability never went anywhere because Management wasn't really into map-maping and the Defense Mapping Agency started doing it themselves, distributing their maps on CD.
Another term for theses is "raster pyramids". Here's an example from 1993: https://www.usgs.gov/publications/pyramid-system-multiscale-...
I don't understand. There were loads of online maps before Google maps and they all used tiles. How else would you do it? What Google added was smooth panning between tiles, pretty much as soon as native browser technology was up to the job. If they hadn't someone else would have.
> How else would you do it?
Render a viewport, given an API like mining/maxing/minlat/maxlat.
Fair enough, but these were solutions that worked without js, and they weren't dynamically rendering maps on the front or back end. They were just showing squares of pre-rendered bitmap, and the square boundaries were fixed. If your point of interest was near an edge it could be quite annoying, like trying to navigate somewhere in the gutter of a paper atlas.
Even if they'd had an API that took a viewport, the result would have been stitched together from bitmap tiles because that's what they had.
It seems like the "invention" of tiles for maps must have happened as soon as anyone starting using a computer to render maps to bitmaps. The Ordnance Survey wouldn't at any point have rendered the entire UK to a single bitmap (at least not a map with any detail). It would have always been tiled.
Edited to add: Actually, the invention was much earlier than that. Paper maps were tiled before computers were a thing. And this would naturally have carried over to computer-rendered maps.
> How else would you do it?
Read latitude/longitude/zoom parameters from the request and render a map image on demand. It's slow and inefficient, but it's simple to implement and I suspect it's what most of the first-generation mapping services did.
Yes, to me it's the canonical way to represent maps on a computer, that anyone could come up with after spending a bit of time pondering the question. And it looks rather straightforward to implement, probably a bit less so with ancient browser tech.
Some of these sure look a lot like mipmaps.
i thought there would be a line or two about Terravision https://en.wikipedia.org/wiki/Terravision_(computer_program)
I worked on supercomputer algorithms to render planetary terrain data (image plus digital elevation) using tiling back in the early 90’s. I’m not sure where my co-worker got the idea, but it seemed like an obvious thing to do.