Announcing MapBox Streets: A Global Map with Street Level Detail(mapbox.com)
mapbox.com
Announcing MapBox Streets: A Global Map with Street Level Detail
http://mapbox.com/blog/announcing-mapbox-streets/
14 comments
Yes. You can preview a desaturated version to be released soon here: http://mapbox.com/tour/#maps (click on MapBox Light). You can render your own layers for things like POIs and transit stations using TileMill, and we'll be adding those in as separate layers soon too.
There's not enough contrast between the street names and the rest of the map, making readability a problem. It's the kind of design mistake that young people with nice monitors make!
This was designed primarily on a MacBook Pro running Linux, so the colors were oddly calibrated. We tested it on several other calibrated monitors, and a few other devices (iPhone/Pad/Android).
Short story is that it could be much bolder and more colorful, at the cost of aesthetics. A growing number of users have good screens - sometimes excellent screens like most mobile devices.
Short story is that it could be much bolder and more colorful, at the cost of aesthetics. A growing number of users have good screens - sometimes excellent screens like most mobile devices.
Ok, but have you tested it on the absolute worst your users will be using?
What does it look like on grandma's 17 inch crt from 2002?
What does it look like on grandma's 17 inch crt from 2002?
It'll probably look odd, just like everything on an old computer. Designing for the craziest CRT is just as bad or worse than designing for a cinema display.
I know this guy's being downvoted here, but he's got a point. I find people on nice, big cinema displays tend to make choices on colors and labeling that people with shittier monitors wouldn't make. Eg, colors that are very close, tinier labels, etc.
Looks interesting. Pricing looks to be roughly 15% of what we pay to google to use the maps api. Nice-looking too.
I see the hat-tip to OpenStreetMap - what's the relationship between OSM and MapBox? Do you own the content, or is your added value the servers and the API?
I see the hat-tip to OpenStreetMap - what's the relationship between OSM and MapBox? Do you own the content, or is your added value the servers and the API?
We use OpenStreetMap data for all roads - for some political boundaries and labels, you've got to bring in some other open data sources to make things look decent. Copyright on this rendition of the maps is MapBox's, data is OpenStreetMap's - that distinction is cleared up by their licensing.
Besides that, the relationship is that we contribute, with a lot of hours, to OpenStreetMap's data & code, and try to get more visibility for the project. There's very little official about OpenStreetMap, so it's not like anyone has a title or secret plans.
Besides that, the relationship is that we contribute, with a lot of hours, to OpenStreetMap's data & code, and try to get more visibility for the project. There's very little official about OpenStreetMap, so it's not like anyone has a title or secret plans.
You should make the freeways a different color from the rest of the roads. I just tried to zoom into my house, and I discovered that when looking at the city-wide view, I use the freeways as a high-level roadmap. When everything's the same color (gray!) it's hard to locate yourself.
I hope you've all seen this article, about subtle design changes they made at google. Attention to detail is really critical:
http://google-latlong.blogspot.com/2009/10/evolving-look-of-...
I hope you've all seen this article, about subtle design changes they made at google. Attention to detail is really critical:
http://google-latlong.blogspot.com/2009/10/evolving-look-of-...
still the same problem with the OSM renderer :
http://a.tiles.mapbox.com/v3/mapbox.mapbox-streets.html#10.0...
there are more than 6 cities in this area, why so few labels ? (look at gmaps: http://maps.google.fr/?ll=47.38834,6.678009&spn=0.65269,... ).
and I think there are not enough details for a medieval city : http://a.tiles.mapbox.com/v3/mapbox.mapbox-streets.html#16.0...
but I think the color scheme is pleasant.
and I think there are not enough details for a medieval city : http://a.tiles.mapbox.com/v3/mapbox.mapbox-streets.html#16.0...
but I think the color scheme is pleasant.
All of the issues you cite are actually just a matter of choice by the designer of this map stylesheet (for lack of a better word).
OSM rendering is extremely customizable. One can present city labels on zoom level 10 and above, or they could just start showing the city labels on zoom level 11. Each zoom level can have different parameters for the 2000+ map components. In a way it is overwhelming, but it's also fabulous!
OSM rendering is extremely customizable. One can present city labels on zoom level 10 and above, or they could just start showing the city labels on zoom level 11. Each zoom level can have different parameters for the 2000+ map components. In a way it is overwhelming, but it's also fabulous!
why do everybody makes the same choices regarding labels then ?
Great news! Is this available at high zooms across the US and Canada yet?
It's z16 globally - as soon as this is solidly out in the wild, we'll be working hard on getting deeper zoom levels. Each zoom level is exponentially larger than the last, so it's a significant challenge.
As a maps dev, I'm very familiar with those exponential scaling problems, 4^z is a bitch. :-) Thanks for taking on this problem.
What zoom level are you all at in major US metro areas?
What zoom level are you all at in major US metro areas?
Is there a way to selectively cache to deeper levels in certain areas? That'd be rad.
We're doing selective rendering with MapBox Light, which is deeper in cities. For this, it's better to have always-there zoom levels. Otherwise you grapple with the deep, deep problem of someone panning from a high-zoom area to a low one, or using an API like Leaflet programmed to zoom to a level. Unless you control the API and have a zoom-depth-api like Google, having a map with highly variable max zooms isn't an easy call.
And that's why I won't need Google Maps anymore; congrats guys, that is awesome work.
A couple questions/comments;
- You'll probably need to work on the readability of some of the Asian charsets; Korean works just fine, Thai and especially Chinese are very hard to read. I guess you'd need to detect specific characters and render them slightly bigger (that is what we sometimes do with Chinese, rendering English text as 14 px and Chinese at 15 for example).
- I'd be interested in knowing what the final size of the tileset is.
A couple questions/comments;
- You'll probably need to work on the readability of some of the Asian charsets; Korean works just fine, Thai and especially Chinese are very hard to read. I guess you'd need to detect specific characters and render them slightly bigger (that is what we sometimes do with Chinese, rendering English text as 14 px and Chinese at 15 for example).
- I'd be interested in knowing what the final size of the tileset is.
I hope the terribly slow map rendering is just a direct result of early release scaling problems. Because it's running unusably slow here.
Edit: I'd like to clarify, it is running in a usable, if laggy fashion, in general, but the main advantage of Google Maps to most competition IMO, is the blistering speed.
Edit: I'd like to clarify, it is running in a usable, if laggy fashion, in general, but the main advantage of Google Maps to most competition IMO, is the blistering speed.
On the plus side, the current slowness enabled me to see some interesting Cloudfront response headers. I see "X-Cache:Hit from cloudfront", "X-Cache:Miss from cloudfront", and "X-Cache:Error from cloudfront" in responses from various tile files.
And I see that they're helpfully using 4 hostname aliases for map tile downloads, namely [a-d].tiles.mapbox.com, to increase parallel downloads.
And I see that they're helpfully using 4 hostname aliases for map tile downloads, namely [a-d].tiles.mapbox.com, to increase parallel downloads.
We just saw a genuine torrent of traffic and are scaling up as I speak.
For me (on an iPad), the problem isn't the loading speed, but the interface that blocks/loses the pinch state when rendering new layers.
Zooming in/out stops working and you have to restart the pinching gesture to continue.
Zooming in/out stops working and you have to restart the pinching gesture to continue.
Personally I find Google Maps to be quite slow, especially on mobile devices! Looking forward to comparing this one on mobile phones!
I'm working on a map-based business that currently uses google maps. I might switch to this before or shortly after I open to the public. It looks great and is much cheaper than google!
Really? A dark share button taking away screen real estate? Are you out of your freaking mind?
Also, preload tiles so I don't get ugly white boxes for just midly steering out of my current viewbox.
Also, preload tiles so I don't get ugly white boxes for just midly steering out of my current viewbox.
The share button is only on the embeds. When you use the API, you won't have to worry about these. (See: http://mapbox.com/hosting/mapbox-streets/)
Tile loading should behave just like you see with Google Maps or MapQuest, or any other tile-based slippy map.
Tile loading should behave just like you see with Google Maps or MapQuest, or any other tile-based slippy map.
Nice color scheme, but the labels need more contrast
I disagree. It's so low contrast, it's hard to see anything.
Plus it plain lacks detail. Compare the same view of Manhattan:
http://i.imgur.com/2uR67.png
http://i.imgur.com/m4tXF.png
Google's result is actually useful in many ways. It shows street direction, subway stops (very important!), some points of interest. The font's are easily readable. The names of the streets are abbreviated, no need to have the words "street", "east", "west" all over your map.
Plus it plain lacks detail. Compare the same view of Manhattan:
http://i.imgur.com/2uR67.png
http://i.imgur.com/m4tXF.png
Google's result is actually useful in many ways. It shows street direction, subway stops (very important!), some points of interest. The font's are easily readable. The names of the streets are abbreviated, no need to have the words "street", "east", "west" all over your map.
I'm curious, the US Interstate Highway numbers appear to be missing. Is this a design decision, or a yet-to-add feature?
Any chance of getting an SRTM terrain layer?
See the rest of the maps: http://tiles.mapbox.com/mapbox In short, not really, but kind of. Global SRTM = a lot of preprocessing, postprocessing, and design choices, that we haven't been motivated to do by any specific use case.
"Global SRTM = a lot of preprocessing, postprocessing, and design choices" -- yes but only once per year or so. Terrain data doesn't get monthly or quarterly quality upgrades like OSM data or satellite aerials do.
For anyone interested, from my own experience a few weeks back when I hacked up my elevation data workflow in 1-2 days. First off, data sources:
1. CGIAR-CSI for SRTM3, v4.1 core elevation tiles (N60 down to S60)
2. vastly improved-over-SRTM .hgt tiles for various mountaineous areas and many north-of-N60 areas from viewfinderpanoramas.org, can replace SRTM tiles with those where applicable but they don't have global coverage so need to merge 1. and 2.
3. anything not covered by 1. and 2. use the HGT tiles by "Radio Mobile" (rmw.recordist.com)
Now encode all roughly 144*360=51840 (minus pure ocean) tiles either to GeoTiffs (insane storage space requirements!) or (my approach) to PNG using any custom mapping of the elevation signed-int16 values to your RGB(A) channels. The compression/decompression is fast yet the storage needs are awesome, some 300kb max for a complex tile vs. many MB for tiff. Reading out PNG pixels can be done in client-side JavaScript these days.
For anyone interested, from my own experience a few weeks back when I hacked up my elevation data workflow in 1-2 days. First off, data sources:
1. CGIAR-CSI for SRTM3, v4.1 core elevation tiles (N60 down to S60)
2. vastly improved-over-SRTM .hgt tiles for various mountaineous areas and many north-of-N60 areas from viewfinderpanoramas.org, can replace SRTM tiles with those where applicable but they don't have global coverage so need to merge 1. and 2.
3. anything not covered by 1. and 2. use the HGT tiles by "Radio Mobile" (rmw.recordist.com)
Now encode all roughly 144*360=51840 (minus pure ocean) tiles either to GeoTiffs (insane storage space requirements!) or (my approach) to PNG using any custom mapping of the elevation signed-int16 values to your RGB(A) channels. The compression/decompression is fast yet the storage needs are awesome, some 300kb max for a complex tile vs. many MB for tiff. Reading out PNG pixels can be done in client-side JavaScript these days.
Have you considered doing different map renderings for different purposes? (this very brown-grey theme might not work well for dark-background websites, and some people might want extra data such as train stations added)?