Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

Learning more about OSM is something I've been meaning to do for a while, but I'll commit time and do it, because I think it's a great project.

That said, every time I look at an OSM map, I find them uglier and far less usable than google maps.

Here's the Sochi example using OSM's Transport layer (which is less cluttered):

http://www.openstreetmap.org/#map=16/43.5883/39.7263&layers=...

vs:

https://maps.google.com/maps?q=sochi&aq=&sll=37.0625,-95.677...

If I had to navigate Sochi, I would overwhelmingly prefer Google's version. It's cleaner, has better contrast and a number of subtle touches (english translations, one-way arrows, ...). When I travel, I always download offline OSM maps, in case, but eagerly get a SIM card with a data plan and switch to Google Maps (and I suddenly find myself better oriented).



The point of OpenStreetMap is that we provide the data and you provide (or you use services that provide) an interpretation of the data that's useful to you.

The rendering style you picked is certainly different than Google's. MapQuest Open's rendering style is pretty darn close to the Google Maps link you pointed at [0], and other map providers like MapBox let you build maps with styling how you like it in just a few clicks (including picking English labels when known). I made one just now [1].

We don't do a great job of making the point when you arrive at osm.org, but we aren't competing with Google Maps. We're competing with Navteq/Nokia and other map data providers.

[0] http://www.openstreetmap.org/#map=16/43.5883/39.7236&layers=... [1] https://a.tiles.mapbox.com/v3/iandees.h675i5pf/page.html?sec...


While I get your point, I don't think it's very productive.

The majority of the people who interact with OSM will get a perception of it that's biased by the presentation. Even with the MapQuest Open style, Google Maps, to me, are far more pleasant to look at and easier to understand. The text seems to be rendered in a better, more readable way, and GMaps has a better handle on decreasing contrast for things that aren't that important, allowing more important features to stand out.

You can tell me that I shouldn't care, because you provide such awesome data, and I'm tempted to agree, but my reptilian brain will give me opposite feelings every time I try to look at your maps.


I'm not sure how you define 'productive' in this sense. OpenStreetMap provides data for people to make maps with. What you do with that data is (gloriously) up to you.

OSM doesn't have to "sell" their maps. It's the folks like Telenav that need to make their maps look better.


'productive' parsed for me as 'beneficial to the project'; OSM doesn't have to do anything. Notably, they don't have to garner any usage or mindshare.


OSM doesn't have to "sell" their maps. It's the folks like Telenav that need to make their maps look better.

They certainly do if "I’d like it to get OSM to seven billion contributors in the next year or two"


With a world population of seven billion, that seems a little ambitious...


This is GNU/Linux/Ubuntu disambiguation and customer support problem.

There needs to be separate organizations to package and distribute this data and make apps for it. (A web map project will have different needs than an offline phone navigation app. OSM shouldn't try to gain/maintain domain expertise in everything.)


Let's try another example: do you use foursquare and if so how do you feel about its maps?

I think its a good example of data > render, with ux in the front of mind. Unfortunately we are good at the read case, not as good at the contribute case.


> We don't do a great job of making the point when you arrive at osm.org, but we aren't competing with Google Maps. We're competing with Navteq/Nokia and other map data providers.

If you want seven billion people using it, it's going to be quite necessary to create a consumer-facing canonical front-end.

I'm sure you can get lots of volunteer hackers to contribute if you throw up an MVP on github.


That's a bit like saying if you want Linux to be a success on servers, mobile phones, game consoles, routers etc. then you need to have a single distribution that they can all use.

Instead, there's room for Valve's SteamOS, Google's Android, Google's ChromeOS, Canonical's Ubuntu and many more, both commercial and community focused, competing in some ways, collaborating in others.

This announcement is one company that did exactly that, and provided a consumer-facing product built on OSM, who just got bought by a bigger producer of consumer-facing products who intend to do the same on an even bigger scale.


Not really. But Linux would not be what it is today if not for Red Hat historically and Ubuntu today. There needs to be a canonical (no pun intended) use case.

libpcap has tcpdump. linux has ubuntu. http has nginx (and previously, apache).

It would be great if there were a canonical frontend stack for OSM that we could all hack on to make as usable as Google Maps. It should be hosted somewhere central but also ship with easy chef or puppet configs to deploy a stack yourself easily.

I'd get tons of use out of something like that, and I'd contribute to the code, too.


Having used a few map services and utility libraries, I prefer that we aim towards more modular and distributed territory with geospatial technologies.

Monolithic engines are great for getting 80% of what your exact requirements are, then you're stuck with a bulky system that you're probably only using 10% of, and it doesn't do the other 10% of what you need.

Something like leaflet.js is nice because it gives you a simple way to present layers on a device, and it's modular meaning you can plug in extra behaviors or develop your own easily.

If a similar approach were taken for the other problem areas, like route finding, traffic monitoring, etc, I'd much prefer that over a bulky platform I'd never want to use the entirety of for any one project.

Of course once these modular components mature enough, no doubt soon, they will be packaged into some service that with a few simple clicks of a button generates the right combination to suit your requirement.

tl;dr OSM should do the data collation and serving and be good at that. Other services should spring up to do their magic with that data. And yet other services should provide easy ways to thread it altogether for a whole world of possible use-cases. (all IMHO of course...)


There are already several javascript libraries that use OSM tiles out there, most popular being OpenLayers[0] which offers an comprehensive API and Cloudmade's Leaflet[1]

[0] http://openlayers.org/ [1] http://leafletjs.com/


I disagree. Wikipedia is a similar effort, and yet they have a highly polished look. I agree with the fact that OSM doesn't look as nice as GMaps, and I also agree that a better color/font scheme needs to be implemented if they want 7 billion users.


I don't know if I'd agree that Wikipedia has a highly polished look, but my point was more that you can have multiple polished looks, and it's actually easier to have a polished Linux for mobile phones and a seperate polished Linux for server usage (and so on), than to try to be all things to everyone. Wikipedia for example has multiple skins, multiple clients (including totally offline ones, similar to one of OSMs key differentiators).

And this article is the equivalent of say, Canonical taking Debian and saying they're going to make an easy to use desktop linux from it. It will almost certainly be more "polished" and end-user focused than openstreetmap.org, because they serve two different types of users.

Interestingly Wikipedia are actually a user facing front-end for OpenStreetmap data, in fact they have at least 4 projects using slightly different tech to put different front-ends on OSM as appropriate for their usage, e.g. the official Android app uses MapQuest OSM tiles to show articles that relate to your physical surroundings:

https://play.google.com/store/apps/details?id=org.wikipedia&...

and the german wikipedia has a couple of gadgets in the top right hand corner to show the geographical context of the articles:

http://de.wikipedia.org/wiki/Kongo_%28Fluss%29

They also extract a lot of vector data from OSM to hand built appropriate maps and diagrams for articles:

http://commons.wikimedia.org/wiki/File:Aruba_travel_map.png

Again, not always what I'd call polished, but they're making creative use of map data, rather than putting some pins on Google Maps (or on an OSM based clone) and that's a good thing.


You could argue that Mediawiki has Wikipedia. Wikipedia didn't change the look much from the stock Mediawiki look.


https://github.com/openstreetmap has existed for several years. And these projects are some of the most contributor-friendly projects ever. Really, just jump in and help with something.


> I'm sure you can get lots of volunteer hackers to contribute if you throw up an MVP on github.

This is quite belittling to the thousands of hours professionals have put into the OSM tools, infrastructure & interface over the years.

But this is hacker news, home of armchair pundits.


I don't mean to belittle anyone, but I see no open source tools that consume the OSM data and output polished maps, or tools with which we can polish those maps ourselves easily.

Mapbox comes to mind, but it is a proprietary service, not open source.

I guess I'm wondering why enabling people to build an entirely free/oss mapbox isn't near the top of their priority list.


Mapbox's products are all made with open source. They're good OSS citizens in that they release all their tools under permissive licences, but perhaps more relevant is that they've hired several of the brightest coders in the OSM ecosystem.

If you want to render polished maps, you use Mapnik (developed outside, creators hired by Mapbox), probably creating your stylesheets in CartoCSS (developed by Mapbox) and using the friendly TileMill wrapper for prototyping (developed by Mapbox). If you want to do routing, you use OSRM (developed outside, creator hired by Mapbox). And so on.

So for your question, there absolutely is such an open source tool, and it's called Mapnik. Download it (maybe as part of TileMill) and have a play.


we aren't competing with Google Maps

Of course you are. That's why there is a comparison of OSM and Google Maps smack in the middle of the blog post we're all talking about. User mindshare matters as much as developer mindshare.


On my iPhone, all the text and graphics are highly pixelated for the links you provide. Any idea why?


I don't why Mapbox's tiles would be pixelated (except that they might have the preview page misconfigured), but I don't think Mapquest Open supports retina tiles yet.

A solution is to make the tiles half the size, but then all the labels are tiny. In addition to this, I dislike Mapquest Open's tiles because they're subject to jpeg compression. Unfortunately, it's the only free tile service out there without usage limits.


On my iPad Mini Retina on iOS 7.0.4 they look perfectly fine for me, I wonder what's wrong there?


As a counterpoint, take a look at the map of Sochi's Olympic Mountain Cluster:

http://tools.geofabrik.de/mc/?lon=40.29583&lat=43.67232&zoom...

Yes, the OSM map is busier. Because it has the entire Olympic venue on it, wheras Google Maps shows it as empty space. Open, contribution-friendly data is a great thing.


Google Maps is less cluttered because it's displaying far less information.

In the Sochi example, take a look at the park to the left. OSM displays all the footpaths in the park, Google Maps display none. This is a running theme: all the red dashed lines are pedestrian rights of way that Google simply doesn't know about.

What if you wanted to cross the railway line on foot? You'd be out of luck with Google Maps...

And while we're looking at the railway, notice anything missing from Google Maps? Only the largest road (looks to be a highway) on the map! It seems like this is new and has yet to be added by the Google Maps team.

OSM has been shown to have more detailed data for many Asian and European countries (like Russia, in our example) than Google Maps, and this serves to make those maps "look more cluttered". But if I was visiting Sochi, I know which map I'd rather be using.


Using the transport layer is a bit of an odd choice for this comparison. The regular layer has the one-way arrows, as well as a wealth of other details: foot paths, parking areas, bus stops. I suppose that does makes it look a bit cluttered, but still to me in this instance OSM is clearly superior.


As you say, that extra detail makes it cluttered. I can only speak for myself, but having traveled to completely foreign locations, that extra clutter (that paradox of choice) just adds to the confusion and overwhelmingness of unknown territory.

When I look at OSM for a city that I know well, i'm not nearly as overwhelmed and I do find the information quite handy. Two different use cases, I guess.


The "MapQuest Open" layer seems better for a comparison to gmaps:

http://www.openstreetmap.org/#map=16/43.5883/39.7263&layers=...


For the sake of comparison -- Yandex (Russia's top search engine) http://maps.yandex.com/-/CVfuFU67


I notice that they all (Google, OSM, Yandex) have comprehensive coverage of buildings and house numbers (though you might have to zoom to see them). I'm guessing this is open government data that's been imported, as I don't recall seeing them in the UK much.


Uk have a bit of a legacy mess of systems. they use ordinance survey for mapping which is quite detailed for physical features (roads, fences, woods, buildings) but often doesn't provide actual property boundaries. they charge quite a lot (for reasonable reasons in some industries) to access this. the post office hold a separate database (also costly) of real addresses


Something like https://www.mapbox.com may help


Sure, I didn't know about that until someone else pointed it out to me just now. I agree it's a beautiful rendering. It's paid though. That point aside, Sneak said what I meant to. If the goal is to have 7 billion people using OSM, this needs to be out of the box / default. Usability can't be an afterthought or something that's left up to the developer (if the goal is that sort of penetration)


Thanks for this piece of insight. Nobody in OSM's community of many thousands had ever brought it up before.

The reality is that if OSM is to scale to 7 billion users it itself can _not_ be the provider of all the tiles. The amount of infrastructure that this would require would be prohibitive for a nonprofit. Rendering & serving map tiles isn't like serving wikipedia pages.


You still don't seem to understand. There's nothing that comes "out of the box". The OSM project provides the data, that's it. Use the map provider that you like best to visualize that data.


Yes it's paid, because it's storing and rendering images that are updated by the minute in a very fast time. That sort of compution, and calculation isn't cheap. As you can see the compressed file format is about 25GB.


you can use TileMill to render the tiles and then host them yourself. its the hosting and the render farm that you can pay MapBox for, but there are ways around it if you are small and prepared to do work.

I agree the default OSM map is a bit ... pink. and yellow. and then blue. but at least it isn't Simpsons Yellow like default google. but see the link I posted here: https://qht.co/item?id=7174856 for more free examples


n people using OSM the dataset, _not_ n people using osm.org.


use != going to the website


this interface lets you switch between many free tile providers: http://leaflet-extras.github.io/leaflet-providers/preview/


> If I had to navigate Sochi, I would overwhelmingly prefer Google's version.

Do note that then you might miss a few details that Google doesn't yet include, like, say, the highway A-148 that now goes through the centre of town...


Except Google's version seems to be missing all of the new roads they've built for the Olympics.

That's why you use OSM, not because it's prettier, but because it has more detail, and it's more up to date.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: