Vector Tiles for MapBox Streets(mapbox.com)
mapbox.com
Vector Tiles for MapBox Streets
http://mapbox.com/blog/vector-tiles/
14 comments
Their MapBox.js library is a plugin for the increasingly popular Leaflet.js mapping library: http://mapbox.com/mapbox.js/api/v1.0.2/
As an aside, MapBox (via funding from the Knight Foundation) is also behind the shiny new iD Editor for OpenStreetMap: http://ideditor.com/
As an aside, MapBox (via funding from the Knight Foundation) is also behind the shiny new iD Editor for OpenStreetMap: http://ideditor.com/
> Is it based on any framework or library?
Nope. We have started to use a common set of base styles ( https://github.com/samanpwbb/fresh-start ) but those are basically a reset.css + columns, etc.
Nope. We have started to use a common set of base styles ( https://github.com/samanpwbb/fresh-start ) but those are basically a reset.css + columns, etc.
I love the style and yet how customisable it is. I've sent this to a friend of mine who's colour blind, one of his favourite hobbies has been ranting about how goolge/bing/here maps don't take into account his disability (in fairness, his is pretty rare).
http://maps.stamen.com shows the same kind of map transformations and is also based on OpenStreetMap. The Watercolor style is especially gorgeous in my opinion.
I'm confused. Are the tiles meant to be delivered in a vector format? Their demo was using pngs...
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.
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.
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.
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.
Even Google Maps WebGL implementation that only uses vectors for the streets is laggy as hell.
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
MapDroyd - was a product of OneStepAhead - now seemingly part of Cloudmade ( http://wiki.openstreetmap.org/wiki/MapDroyd - still in Google Play with screenshots etc search for MapDroyd )
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
MapDroyd - was a product of OneStepAhead - now seemingly part of Cloudmade ( http://wiki.openstreetmap.org/wiki/MapDroyd - still in Google Play with screenshots etc search for MapDroyd )
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.
Also KothicJS, a JS renderer.
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.
Yeah, it's not clear. Does the browser eventually create a vector or just work out a png itself?
Given the spat at OGC with regard to Geoservices REST API, its high time that we ditch OGC and start a clean standardization body. We need futuristic standards and that can take the geospatial industry forward, not as in ESRI. I see that the team at Mapbox is ideal for that and lets hope that can take the lead
Where can I find more info about this "spat"?
The 'spat' broke out on the OGC Mailing list, here's the May Archive: http://lists.osgeo.org/pipermail/discuss/2013-May/ There are about 100 messages about it on there.
There's also this Open Letter: http://wiki.osgeo.org/wiki/Geoservices_REST_API#Open_Letter_...
And James Fee's view on the whole thing: http://spatiallyadjusted.com/2013/05/09/esri-and-an-ogc-stan...
There's also this Open Letter: http://wiki.osgeo.org/wiki/Geoservices_REST_API#Open_Letter_...
And James Fee's view on the whole thing: http://spatiallyadjusted.com/2013/05/09/esri-and-an-ogc-stan...
> Now with hundreds of millions of map views across thousands of subscribers, the stability and scalability wins are clear
I'd also be interested to see a write up on these aspects, what are the gains here... 10%? 10x? 100x?
I'd also be interested to see a write up on these aspects, what are the gains here... 10%? 10x? 100x?
I wondered, too. Luckily, there's some hard data further down in the post:
[...] highly optimized, slim enough to fit the entire world onto a single USB stick.
Now that the exact size is known (1 world/stick), it's easy to get a feel for how this new format is better than the old alternatives, right? Grumble.
[...] highly optimized, slim enough to fit the entire world onto a single USB stick.
Now that the exact size is known (1 world/stick), it's easy to get a feel for how this new format is better than the old alternatives, right? Grumble.
This looks phenomenal. Anyone that's interested in online maps and hasn't taken a look at TileMill owes it to themselves to take a look.
Very cool and I' definitely going to dig into this.
For my use (topographic maps) the ability to combine this on the client side with tiled raster data for thing where that makes sense (ie grey scale elevation, their satellite layers etc) would make this a killer platform.
I already have code to do slope angle overlays client side by applying an image transformation to elevation data in a canvass [1] which could be used for hill shading etc but the only available web services are slow, query (instead of tile) base, and use poorly defined encodings.
[1] The "Custom Slope Analysis" tool for identifying avalanche prone slopes on hillmap.com
For my use (topographic maps) the ability to combine this on the client side with tiled raster data for thing where that makes sense (ie grey scale elevation, their satellite layers etc) would make this a killer platform.
I already have code to do slope angle overlays client side by applying an image transformation to elevation data in a canvass [1] which could be used for hill shading etc but the only available web services are slow, query (instead of tile) base, and use poorly defined encodings.
[1] The "Custom Slope Analysis" tool for identifying avalanche prone slopes on hillmap.com
Correct me if I'm wrong,
Their unique value proposition is a platform for styling maps?
Their unique value proposition is a platform for styling maps?
Styling maps is just an added feature. Their main uvp is simply "maps". Competitor and alternative to Google Maps, Mapquest, etc.
And there is also CloudMade as a choice for those seeking not to use Google Maps, Mapquest, Bing, etc.
http://cloudmade.com/
Both Cloudmade and MapBox use OpenStreetMap data. Leaflet ( http://leafletjs.com/ ) was created by Cloudmade and is the JavaScript lib for putting tiled maps on the web. Mapbox have their own version of Leaflet, but it's essentially much the same if all you want to do it drop pins, work with layers, choose a tile set.
Both are comparable, and both are strong in the same space: Custom styled, tiled maps. And both are weak in the same place: routing.
Not to say that they don't do routing, but it's certainly not their forte.
Thankfully the majority use-case for most sites and applications using maps is simply "show a map, drop a few pins here and there". So having this map look and feel like the site is actually a good selling point.
http://cloudmade.com/
Both Cloudmade and MapBox use OpenStreetMap data. Leaflet ( http://leafletjs.com/ ) was created by Cloudmade and is the JavaScript lib for putting tiled maps on the web. Mapbox have their own version of Leaflet, but it's essentially much the same if all you want to do it drop pins, work with layers, choose a tile set.
Both are comparable, and both are strong in the same space: Custom styled, tiled maps. And both are weak in the same place: routing.
Not to say that they don't do routing, but it's certainly not their forte.
Thankfully the majority use-case for most sites and applications using maps is simply "show a map, drop a few pins here and there". So having this map look and feel like the site is actually a good selling point.
I expect routing to become more prevalent in the OSM world thanks to the fantastic http://project-osrm.org/ project.
That's surprisingly good. As in; for a complex route across London and factoring in one-way streets it produces something that looks realistic.
Only allowed me to pick car as a mode of transport, and unrealistically suggested I could get across 14KM of central London in 14 mins, but ignoring those things this is very nice.
Would love to see the path output of this added to Leaflet and a standard form of API emerge for Mapbox, Cloudmade, Google Maps, etc.
Only allowed me to pick car as a mode of transport, and unrealistically suggested I could get across 14KM of central London in 14 mins, but ignoring those things this is very nice.
Would love to see the path output of this added to Leaflet and a standard form of API emerge for Mapbox, Cloudmade, Google Maps, etc.
I believe that other transport modes (public transport, on foot) are in the pipeline, but the amount of additional compute power they need is significant
Also Public Transport route and connectivity information is frequently a bit patchy in OSM, but this is steadily improving.
Also Public Transport route and connectivity information is frequently a bit patchy in OSM, but this is steadily improving.
I, ahem, might be working on a UK cycling router using OSRM ;)
You probably want to be talking to me... I run http://www.lfgss.com and am building community software to run cycling forums.
Email in my profile... that is, if you think we're your market.
Email in my profile... that is, if you think we're your market.
Have you seen CycleStreets: http://www.cyclestreets.net/
Yep. It's great. This one will aim at a different market, really.
Interesting. What other market is there though? They do different confidences of cyclists and leisure routes already?
I used OSRM a while back for a longish car trip. Worked great.
Adding public transport, cycling etc. would be fantastic.
Adding public transport, cycling etc. would be fantastic.
You should look into OpenTripPlanner by OpenPlans, they have built a multi-modal routing engine that can account for GTFS public data feeds as well as combining walking/cycling/public transit together to for a single route.
If you have a GIS dataset and you want to style it and serve it, your previous best bet was to use TileStache or something like that, to seed the png tiles for a zoom range. If you want to change the style, then you have to re-seed. I believe this allows you to 'seed' vectors and changing style is completely flexible.
Very nice work. I look forward to seeing where they go with this. I am curious as to how they handle polygons that span multiple tiles. If they take the rather straightforward approach of taking any polygon and splitting it up to fit in each respective tile, that has all sorts of implications for styling. Imagine you want to draw a building as a solid color and then draw the outline in some secondary color. What happens if the building falls on a tile boundary?
Without having looked at this implementation (but I know a startup doing something similar for an internal system): You add a suitably sized "buffer". So e.g. if your maximum stroke width is 20, you clip the polygon with an accordingly large margin. There are still potential caveats, e.g. if you want to allow changing automated label placement based on shapes etc., but the potential win is still massive even if you have to put some minor restrictions on what type of restyling can be done without having to "re-render" into vector tiles - this way at least most typical restyling such as changing colours or stroke widths can be done trivially.
As always, very beautiful work. Congratulations and thank you for contributing this back to the OSGEO community.
Does somebody know if there's a way to use these with one's own OSM server?
There is code on GitHub[1], although it emphasises "experimental" and "unsupported".
[1]: https://github.com/mapbox/tm2
[1]: https://github.com/mapbox/tm2
TileMill is the desktop app for designing/styling maps. It'll export to various formats, but primarily geared for upload to Mapbox's hosted map service (free and paid plans that are well worth it imo - just a happy customer).
For std image files, Mapbox make source available for their TileStream server (https://github.com/mapbox/tilestream). Not sure if/when it'll get support for the raster images.
For std image files, Mapbox make source available for their TileStream server (https://github.com/mapbox/tilestream). Not sure if/when it'll get support for the raster images.
Very nice, pricing seems pretty good too imho
This is pretty cool.
still waiting for the reverse geocoder
Use Nominatim.
Reverse geocode: http://nominatim.openstreetmap.org/reverse?format=json&l...
Forward geocode: http://nominatim.openstreetmap.org/?format=json&q=1600%2...
Reverse geocode: http://nominatim.openstreetmap.org/reverse?format=json&l...
Forward geocode: http://nominatim.openstreetmap.org/?format=json&q=1600%2...
Nice
http://mapbox.com
And the tour:
http://mapbox.com/tour/