4 ms·

I'm confused. Are the tiles meant to be delivered in a vector format? Their demo was using pngs...

fpp 13y ago
Yes, would be great to see a live example of client rendered tiles. I believe their ProtoBuffer approach sounds promising and their position in the mapping / OSM community is strong enough to get this to some kind of standard. Have seen a few client vector-based approaches before. 2 of the better ones: https://github.com/jywarren/cartagen https://github.com/jywarren/cartagen MapDroyd - was a product of OneStepAhead - now seemingly part of Cloudmade ( http://wiki.openstreetmap.org/wiki/MapDroyd http://wiki.openstreetmap.org/wiki/MapDroyd - still in Google Play with screenshots etc search for MapDroyd )
- aw3c2 13y ago
  Don't forget OruxMaps and OSMAnd (capitalisation as you like it). Both are Android apps that support vector data as well. Also KothicJS, a JS renderer.
aw3c2 13y ago
Confusing indeed. No, the vector tiles are "just" small extracts of global data that then get rendered to standard png files again. Vector means vector geodata here.
vidarh 13y ago
Not so far, though this means they can experiment with that. Part of the challenge of rendering maps quickly is simplifying features, clipping and filtering the data. E.g. you might have a layer containing really high resolution national boundaries. Most tiles won't even contain any part of it, and those who do will either contain a small subsection or a vastly simplified version. If you were to try client side rendering based on that, you're potentially looking at gigabytes of data to transfer to the client. What they're doing is essentially doing all the steps apart from the final rasterisation, and then storing that vector data on a per tile basis, so that they can process only the relevant vector data - whether to serve it up as is, or rasterise it. One major advantage is that things like styles (line widths, colours) can be modified without having to re-render the entire map data set. Instead you just have to on-the-fly rasterise the already prepared tiles, which you can do without totally killing performance.
ferongr 13y ago
Vector performance is still abysmal in browsers (apparently there's no vector benchmark used by the press to pressure vendors) so it's no wonder maps are served as prerendered images. Even Google Maps WebGL implementation that only uses vectors for the streets is laggy as hell.
urbanbiker 13y ago
Yeah, it's not clear. Does the browser eventually create a vector or just work out a png itself?
smackfu 13y ago
It seems almost intentionally misleading to call raster tiles "vector", when vector-based maps is a real thing that is superior to raster-based maps.

fpp 13y ago

Yes, would be great to see a live example of client rendered tiles. I believe their ProtoBuffer approach sounds promising and their position in the mapping / OSM community is strong enough to get this to some kind of standard. Have seen a few client vector-based approaches before. 2 of the better ones: https://github.com/jywarren/cartagen https://github.com/jywarren/cartagen MapDroyd - was a product of OneStepAhead - now seemingly part of Cloudmade ( http://wiki.openstreetmap.org/wiki/MapDroyd http://wiki.openstreetmap.org/wiki/MapDroyd - still in Google Play with screenshots etc search for MapDroyd )

aw3c2 13y ago
Don't forget OruxMaps and OSMAnd (capitalisation as you like it). Both are Android apps that support vector data as well. Also KothicJS, a JS renderer.

aw3c2 13y ago

Confusing indeed. No, the vector tiles are "just" small extracts of global data that then get rendered to standard png files again. Vector means vector geodata here.

vidarh 13y ago

Not so far, though this means they can experiment with that. Part of the challenge of rendering maps quickly is simplifying features, clipping and filtering the data. E.g. you might have a layer containing really high resolution national boundaries. Most tiles won't even contain any part of it, and those who do will either contain a small subsection or a vastly simplified version. If you were to try client side rendering based on that, you're potentially looking at gigabytes of data to transfer to the client. What they're doing is essentially doing all the steps apart from the final rasterisation, and then storing that vector data on a per tile basis, so that they can process only the relevant vector data - whether to serve it up as is, or rasterise it. One major advantage is that things like styles (line widths, colours) can be modified without having to re-render the entire map data set. Instead you just have to on-the-fly rasterise the already prepared tiles, which you can do without totally killing performance.

ferongr 13y ago

Vector performance is still abysmal in browsers (apparently there's no vector benchmark used by the press to pressure vendors) so it's no wonder maps are served as prerendered images. Even Google Maps WebGL implementation that only uses vectors for the streets is laggy as hell.

urbanbiker 13y ago

Yeah, it's not clear. Does the browser eventually create a vector or just work out a png itself?

smackfu 13y ago

It seems almost intentionally misleading to call raster tiles "vector", when vector-based maps is a real thing that is superior to raster-based maps.