Wrong that OSM should be a service provider and not a database - I think it should be a database, and corporations are good for OSM. The post calls for OSM to essentially become Mapbox. It's insanely expensive to be Mapbox, and Mapzen just failed trying to be a less corporate version of Mapbox. And then the usage policy part of the article is moot or at least not that consequential if you don't believe OSM should be a service provider.
Right: Moderation tools need to be created/fixed. New mappers need to be encouraged/onboarded better. Vandalism is a problem. OSMF culture is toxic. Hidden gatekeepers are toxic. Imports need to be supported. Bots need to be enabled, and we need to consider people who contribute code/tech/imports first class OSM contributors and not just glorify the individual mapper.
Probably right: OSM needs layers, or even a more sweeping re-architecture to allow better versioning, moderation, better tooling, and easier understanding of the data.
Probably wrong: Expanding the scope of OpenStreetMap to include transient data. Too much other work to do, maybe later for this.
The problem is that most companies using OSM are using Mapbox. This leads to a few problems, including attribution, which I decided not to touch on, but is a serious problem that Mapbox doesn't address sufficiently.
If they could use OSM directly, they'd be engaged with OSM directly. They'd care about OSM. Right now OSM shoves these users away and makes them into customers of some third party (maybe Mapbox, maybe someone else) instead of caring about OSM itself.
> Expanding the scope of OpenStreetMap to include transient data. Too much other work to do, maybe later for this.
How about letting users experiment and seeing what cool stuff they can come up with?
Is that even true? And is number of companies even a good metric? Based on revenue/market cap, the bulk of companies use OSM directly.
The world's biggest company (Apple) uses OSM directly. Telenav uses it directly. Don't Tesla and Uber use OSM directly too? And we use Mapbox at Gaia GPS, but we also use OSM data directly.
> How about letting users experiment and seeing what cool stuff they can come up with?
In my experience building a company, if you focus on too many things, you get everything wrong. This smells to me of being not on target for making OSM as strong as possible, even though it has alluring upside.
can't there be an open source set of service
APIs that's self hosted
Unfortunately, the developer experience is much more painful than using Google Maps.
Compared to that, self-hosting OSM tile generation requires a bunch of extra knowledge, equipment and maintenance.
With image tiles it's a hurdle. You have to build 18 zoom levels of tiles. The most detailed layers have an astronomic number if tiles. You also need a huge amount if storage.
Did I mention the data being huge? What's the point of having 15Tb container, which takes forever to deploy? You can certainly containerize the services, but there's no benefit containerizing the data, since you have to replace it all at once rather than synchronizing the differences.
Even if you could make the general setup and maintenance incredibly easy somehow, just syncing the map data from osm regularly would require decent hardware: the extra cost of each dev doing this themselves just doesn't compare to using a central tile host.
On top of that, if every dev was regularly updating their own OSM data, OSM would have a lot of extra strain on their data download servers to deal with. Not sure if this could be comparable to the hardware overhead of providing a tile hosting service though.
We need servers with at least 24 CPU threads and 256 GB RAM and moving the data into PostGIS, region by region takes a week or two. Plus you manually have to fix the process when it just spits out an error and aborts after 15 hours of churning.
You can get country level extracts, which can be updated every day. Nearly any server which can import OSM data is able to keep it up to date.
I have a hobby site about railways  I'm picking up again after a decade of inactivity. I wanted to display a route map of each railway, with clickable stations and the route highlighted.
I can not work out how to do that. OSM has the route and station data (there and in Open Railway Map ). I expected to find a layer called 'Railways' with sub-layers, one for each railway, and I could export the data and highlight it on another map.
Instead I have raster tiles, and no way to highlight the railway I'm talking about. I know the data must be there somewhere but how on earth do I get it?
A brief google search came back with this; I haven't inspected the data or even tried to use it to see what it contains, but the page description indicates it may not be exact routes you are looking for-but it's a start. Implementing the data is a bit more work in order to display route maps, something like the previously mentioned MapBox does this very interactively.
My email address is in the profile, feel free to shoot over an email if you'd like some help with it. Depending on the complexity, I can probably devote a few cycles this weekend to show you a one-off map with railway routes, and show you how it's done.
I'm only a hobbyist with GIS, so I can't really say or speak to how practical of a format KML/KMZ are in production.
But that's a really good question.
KML/KMZ is decently useful as an interchange format and simple rendering but almost all web GIS software has better support for GeoJSON. It’s richer and easier to work with.
I’ve never worked on a GIS system that used KML/KMZ in prod for rendering. It’s usually shapefiles, PostGIS Geometry, ESRI’s proprietary GDB feature, WKB/WKT or GeoJSON on the backend being served up to clients.
I have used it as a lightweight way to deliver simple data in the past though for use cases where there was no proper client renderer (we would just tell the end user to download google earth and open up the file)
In the sense of being easy to retrieve I guess it isn't a layer. Global railway data will be pretty huge, so Overpass-API may not work out if that is what you want. In that case, the strategy is to grab a planet file (a snapshot of the db) and filter it locally:
And then you probably have to translate the resulting data into a format that you would use for your map.
As to why you have to do that work instead of just pulling layers, it comes down to the core data model being focused on editing and there being many different end use cases (making it difficult to anticipate and serve each one).
And really, any strict layering system in OSM would quickly just fall apart into debates of exactly what belonged in each layer. The range of detail captured by OpenStreetMap users in different areas is really far too nuanced to work crammed into coarse, crude "layer" classifications.
Absolutely not. Not only is the selection of types huge and full of shades of grey, but an element can be tagged as things from multiple different categories at once (and this is a wonderful feature). Take a browse of the OpenStreetMap wiki sometime. OpenStreetMap data is far richer than a layer model could cope with.
However, let's not confuse this with an editor having a layers-like interface feature to help the user focus on a particular subset of the data. JOSM for instance does this very successfully with the "filters" tool, which I use heavily.
e.g. the railway nerds have very detailed ways to tag railway infastructure: https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging
My current solution is based on OpenMapTiles and uses their stack for creating, and subsequently rendering, vector tiles. First, I obtain an extract of OSM data via the Overpass API. Then I convert it from XML to protobuf, as it's a much more efficient format. Afterwards I import it into a PostGIS database using imposm3 and define some SQL functions that transform that data. Then I generate some vector tile definition from the OMT format into tm2source format. After that I finally generate the vector tiles in mbtiles format using tilelive, server them as GeoJSON using tileserver-gl and style them using maputnik and mapbox-gl styles.
There seems to be some bug with imposm3 and relations, because I can't get them to import. Or I'm just not doing it right.
It sounds like Overpass is the way to get the data I need - once I figure out how to reference it in Overpass (network/relation details).
It talks about the errors in Open Street Map data, and the consequences of that for railway routing.
The main point against a service seems to be that’s it’s an expensive thing to do, however I don’t see how we can draw any conclusion from that without weighing the costs against the upsides.
I don’t see how the expense argument can be made with confidence without first establishing some basic data points. For example:
1) How expensive is expensive?
2) Have the benefits and advantages been throughly explored ie what’s the value proposition?
3) Given this value proposition, what level of fund raising success would be plausible?
As an aside, the ineffectiveness of leadership and how it is seemingly blocking progress is quite striking.
Off the top of my head, I can’t think of any actively developed software with a non-deprecated api that hasn’t changed in so many years.
Sure, these aren't provided by what's formally known as the "OSM API". They are provided by OSRM/Graphhopper, Mapbox GL/Tangram, Leaflet/OpenLayers 3, and Overpass respectively. Because that's, deliberately, how OSM works: it's the centre of an ecosystem, not a single service provider.
The OSM API is for the use of map editing programs. It's an implementation detail for the authors of iD, JOSM, Vespucci and a few others. It isn't something that anyone who isn't writing an editor needs to concern themselves about; and I honestly haven't heard many comments from editor maintainers that they want the API to do things it doesn't at present (though, Bryan, Dirk, Simon, do jump in and correct me if I'm wrong).
Mentioning OSM has gained functionality is irrelevant, the article’s point is the API which serves a different purpose. What other companies offer is irrelevant that’s not OSM.
Your other points seem to attempt to diminish the importance of the API, yet the state of modern software has become such that almost any significant software project can benefit from a rich, well implemented and maintained API.
Not to mention maintaining a high quality API often in and of itself leads to improvements in the overall architecture of software, due to how it encourages careful thought about the purpose and organization of the system.
The OSM ecosystem has gained some new, much more powerful APIs, which Doctor_Fegg mentions. OSRM's API, GraphHopper's API, Overpass's API, these are all better than the APIs that were available in 2009
What other significant, widely used software, depends only on the “ecosystem” for APIs development, while having no active API efforts in the core project?
I can think of none. Maybe some examples exist somewhere, but at the least it’s unusual, especially given the overall context of the article.
HTTP itself is fundamental and a different level of abstraction. We would not want monthly updates.
A closer analogy is Wikipedia (see wikimedia api). It hasn’t had the fastest evolution, but it makes OSM look like the stone age. You could look at the github api as a project that’s invested more frequently.
And it’s not just because these are projects with vast riches (even though WP’s multi-million budget is actually tight). There are countless smaller projects that keep a well maintained API. I just list these because they are well known.
The role and importance of APIs in software has changed dramatically over the last 20 years. It’s true at one point it was more of a luxury and just wasn’t as central to many projects.
Those days are far enough in the past and so anachronistic that a ~10 year stale API at this point should be considered architectural malpractice.
And then you could lay out why those things should be done centrally rather than on separate servers. For example, there is a sophisticated data query api https://wiki.openstreetmap.org/wiki/Overpass_API that keeps up with edits within a minute or two but is free to lay out the backing database in a way that is optimized for queries and people can run their own instance and so on.
Then how is this productive you ask? Because for now I’m only drawing much smaller conclusions, which also generalize to most actively developed software. Rich, well maintained APIs tend to be useful. As of yet I see no real explanation of why that doesn’t apply to OSM.
To start, not sure why you mention a central server vs. “separate servers”. SaaS users shouldn’t care, or ideally even need to know whether something runs on 10 or 100 servers.
Maybe instead of separate servers, you meant different companies? Knowing which organization is the provider of each service is paramount. For each provider it’s also important to know something about their business model, reputation, roadmap, and the pros/cons of using multiple providers vs. one stop shopping. It’s important enough that companies like Gartner are paid a truckload of money by SaaS users to analyze these details.
So back to my original point: Most significant and active projects benefit from investing in rich and well maintained APIs.
Take that fact, and add in a domain expert taking the time to write an article asserting it’s indeed a problem relevant to OSM. One person’s opinion is not always a smoking gun. But combined with the fact a 10 year old stale API is so unusual, and the fact that what other companies do is a red herring argument being made, at minimum it sure seems like a bright red flag that warrants better understanding of what’s going on over there.
There's a particular service running on some OSM servers that provides data to editing software and receives changes from editing software and applies those changes to the master database. The primary version number on that api is 10 years old. It has still evolved over that time. But it is not the entirety of the OSM API, it is the OSM editing API, which probably benefits from being at least somewhat stable.
I mean, I guess the basic data model could be changed all the time so that all the tooling had to chase after it, but the only big proposal along those lines is to add an explicit "area" type which would simplify some things (it wouldn't really create room for any new capabilities).
Take a look at the vector tile stack Mapbox has put together if you want to see a new way of working with OSM data that has come about over that same 10 year period. Mapzen and OpenMapTiles have also worked on vector tile stacks.
I had to implemented a specialized geocoder/administrative boundaries referential last year. Mapzen was really compelling, the documentation about how they handled hierarchical data was clear and interesting but execution was lacking. I am French, handling European data was important and I quickly hit several pain points:
- Their github repository organization was a mess. A lot of small ones without a clear map of which did what.
- The vagrant setup to experiment locally was unmaintained
- I found a basic unicode normalization issue in the geocoder several hours after playing with it.
- Manipulating their dataset via git-lfs was a massive pain
- Their geocoder was nicely presented but relations to administrative levels was done with neightbourhood search to administrative area centroids, instead of (even approximated) geometries.
- The data was not as comprehensive and up to date as OSM one, at least in France. For instance, France second level administrative areas (Régions) were redesigned at the beginning of 2016. They were defined in OSM but progress seemed fairly slow in Mapzen.
Now, I appreciate Mapzen was a very ambitious project and handling cartographic data at this scope and scale is a difficult job, but as pure data consumer, it was not comparable to OSM.
I eventually used OSM data and while their documentation/tools are quite a mess too, wiki style, it is workable. Datasets are large but there are a lot of way to retrieve them efficiently. Their non-protobuf binary format hits a sweet spot between size efficiency and ease of processing. And at least in Europe, the data is fairly good, at least for my requirements.
Maybe I'm misunderstanding the whole domain, but if OSM would get layers, that would lead to better composability, then wouldn't the question of transient/frivolous data kinda become moot? The way I see it, in that scenario I could make and host my own whatever pokemon layer and OSM proper could provide the base layer, and then they could be easily merged at usage point; whereas based on the discussion now without layers you'd need to essentially make hard fork of the OSM data to make your own pokemon map?
I don't really agree. I have seen so many wrong imports and I have seen imports demotivating individual mappers.
With a good data source an import can be a good start, but it's not a silver bullet.
I agree to your other items, though.
That's strange. What were you trying to do? If you convert your data to OSM's relatively simple XML format, you can open that file in JOSM, and just press the upload button. That's what most people do with imports. It's possible to communicate with the OSM API directly and make API calls, but that's essentially what JOSM does. JOSM also has a validator, which can spot some problems with your data.
Isn't all of the data in OSM transient to some degree?
What's the threshold for when data is too fleeting to be worth storing? Days, months, years, decades?
I think David Ogilvy said something like "Search all the parks in your city, you'll find no statues of committees". Everyone was super keen to make OSM in to a web of committees, and this is one root of the problem from an organizational point of view. It's not super clear to me what the OSMF has done in the last (to pick a number) 5 years. (I don't regard "doing the same thing as last year" as relevant to anything, I just have a personal bias towards new things).
From a technical point of view we merged sysadmin (who inherently want stability) with development (who inherently want change) and stability won (it doesn't involve arguments or as much work, I guess). That's why the API looks the same way I designed it X number of years ago.
It's still a wonderful project, but more of a work of art than anything else. It's not like wikipedia didn't have all the same problems. Making a project that really evolves and grows over large periods of time is really hard. Like - most of the things on the S&P 500 won't be there in 10 or 20 years or something.
I think what really happens is that projects go through a lifecycle and something new comes along to replace them, rather than anything getting fixed. I'm not sure if this is a good example, but, you could try to "fix" Apache, or you could just do this new thing, "nginx". For all kinds of reasons, the new thing is more efficient. One of the few counter examples I think is going to be Amazon.
The world has moved on from making vector maps and OSM solved almost all the related problems (just not geocoding, which annoys me no end). It moved on, because of OSM! All the money and interest in maps is now around autonomous navigation, which means 3D maps and other things outside of OSMs area.
I agree with you in regards to the OSMF. There has been a lack of motivation and a lack of desire to experiment.
> From a technical point of view we merged sysadmin (who inherently want stability) with development (who inherently want change)
Agreed, operations and development are often at odds. I've done both, and there are organizational ways to solve this, but they require a great deal of work.
> It's still a wonderful project
I completely agree. A prominent OSMer just sent me a message saying how he never wants to hear from me again, but this is not me writing against OSM, but rather me getting down and dirty into exactly where I think OSM doesn't do a good job.
I can love something (especially software) and advocate for it to change.
Steve, you and I don't always agree, but I think we both agree that we want the project to succeed and are frustrated by the current situation.
> I think what really happens is that projects go through a lifecycle and something new comes along to replace them, rather than anything getting fixed.
I'd hate for this to be the case, but it seems that if the project can't move forward, this is what will happen.
It would be possible to start by stiching together data from existing libre data sources, and then using tools to augment them. I'm not a computer vision expert, but I bet much of what we (you and I and many of our bretheren) were doing tracing roads and buildings could be done better by computer.
BTW, if you're Liking my post- like the parent post, since Steve is the primary founder of OSM. I mention him in the post.
All I can find is "Dietary Reference Intake" on https://www.merriam-webster.com/medical/DRI -- what do you mean?
(I agree with most of your post by the way (except for the bit about it being art, which would mean it has no function except to be art), I'm just unclear on what you meant here.)
I can think of some cases where it would still fit. You seem okay, though ;)
Not useful in this case, but acronymfinder.com gives 60 possible meanings. Also the intented meaning as 54th down the list.
...A-and we still don't have a single decent map people can use. And positively undoubtedly we don't have a single decent map people can use, that is owned by society and free in a sense Wikipedia is. I use Google Maps on a daily basis, and I hate Google.
Oh come come Steve, you know better than me that's not true. There is one genuine committee in OSM (OSMF board, which does nothing, which is probably a good thing given how well their attempts to do something work out) and three things that are nominally committees but in reality just a small number of self-motivated volunteers doing thankless grunt work (Licensing Working Group, Data Working Group, State of the Map [conference] Working Group).
OSM is about the least hierarchical, least committee-fied project there is. Compare to Wikimedia - or, you know, any form of government - if you want to see what committees are really like.
This doesn't necessarily mean that committees did not play a vital role in various historical events, just that people don't like to make statues of them.
For all their flaws committees are a primary way in which people pool their collective experience and effort which is ultimately how anything significant is built.
Well, maybe one or two:
I was touring the USGS in Palo Alto about 10 years ago, and the librarian there was lamenting the existence of Google. He said that while it was nice that Google was doing all this work, it was causing the USGS to stop doing it, since they could get the data from Google.
He predicted that the USGS would get severely cut in their funding for mapping activities because of it, and he was right. He was worried that all the best data would be locked up in Google's servers, and he was right about that too.
(A challenge: download a routable road network for the US from a USGS source)
Naturally I turned to OSM instead of Google Maps. But I was really surprised by how strange and difficult it was to install and use. As the author mentioned, OSM itself doesn't have any apps, which is very confusing. After some research I figured out that you have to download a 3rd party app. The 3rd party apps that do exist all use different terminologies, require downloading huge amounts of data and picking what maps you want ahead of time, and had different levels of functionality. The UIs were universally terrible (at the time at least).
Needless to say I quickly gave up on using OSM and turned back to Google Maps--and I'm their perfect use case, a skilled techie with a deep interest in using free software! I can't imagine trying to explain how to use OSM to my mom, even if I somehow managed to install it for her.
I can't comment on the rest of the article but its usability worries are on point.
My mom got an iPhone gifted from my dad, so there's mistake number one (I don't know of any decent OSM apps on that proprietary platform), but for what it's worth, my non-technical girlfriend has no trouble with it. Then again, that was 2014ish, not sure what time you're talking about.
> require downloading huge amounts of data and picking what maps you want ahead of time
It's not easy to find, I agree, but you can use it without downloading a single map. If being online all the time floats your boat, you can do that (at least in Osmand, the de facto app for Android).
> The UIs were universally terrible (at the time at least)
OsmAnd invested a lot of time in this. I didn't mind the old UI that much and the new one has some things I don't like (but are probably easier for newbies), but it might be worth a try again. Especially if you live in Europe, and definitely if you live in the Netherlands or west Germany, the map data is much more complete than Google's on everything but business information.
I believe it has one of nicest and most usable map keys for outdoor navigation:
Is ViewRanger of use? (Disclosure: I used to work there).
It’s focused on outdoor pursuits such as hiking and biking rather than driving or public transit, but OSM is one of the available maps.
You should try Waze. I too mostly use Google to route me around traffic, but Waze is an order of magnitude better at it. It has more frequently updated traffic data and is willing to take you on side streets.
For example the other day I was driving down a major road, and Google said to just stay on it, but Waze took me down a side street for two blocks and then back to the main road, saving me four minutes, which was 25% of the total trip time.
Also, when making a long drive, Google chooses a route that is optimal right now for the entire route. Waze accounts for the fact that it will be an hour later when you get to the second half of your trip, and uses that to make better choices.
What I wish Waze would do is have a mode that allowed me to learn a route. Maps, and Waze both 'optimize' so much that its sometimes hard to learn a route from point a -> b because every time you go it sends you on different paths.
Many of the path optimizations seem to save you _seconds_ and when I'm driving I don't care about seconds, I care about minutes in greater quantities than 10.
Google might route me through a turn that's theoretically allowed according to street signs but takes forever to make in heavy traffic; Waze might route me through a turn or "street" that's theoretically not usable but all the locals are using it anyway.
I'm using Here for longer trips. Google has the habbit of making questionable routing decisions. We ended up on roads that looked like after bombardment using it.
No, Google, I am not going to make a left turn here, because I have someplace I need to be by Wednesday.
This made me laugh a whole lot more than it should have. Thank you.
And their pathing is just bad: it insists on cutting through a gated community to get to my place, something that's physically impossible. And even worse, the entrances to that gated community and my townhouse complex are on different arterials. It also doesn't recognize the entrance to my townhouse complex as a valid entrance too (if you try to enter via the entrance, Waze will shriek at you to turn around, get back on the arterial, and find the gated community). I've also seen it straight-up get lost before when trying to go to one bar that's near my office.
Because of this, I long ago decided that whenever I request a Lyft, and I'm going either to or from home, I will call the driver and say "My name is Amy, I requested a ride. I'm calling to confirm that you are not using Waze.", and I will hang up and cancel if they say they're using Waze, if they don't speak enough English to understand the question (I live in a pretty diverse city, so this is common), or if they demand why I'm asking and then start angrily grilling me about every detail related to my destination.
And, yes, the third scenario is sadly common. I have never seen people get angry in real life like Waze partisans do except where actual religion is involved... imagine the worst kinds of vim/emacs warriors, Linux/Mac/Windows fanboys, PlayStation/Xbox/Nintendo/PC zealots, iPhone/Android partisans, etc., except in real life instead of on the Internet. It's actually why I started calling ahead: I used to just wait for the driver to get here, get in the car, and then as soon as they start the navigation and Waze comes up, I would calmly say "please don't use Waze, it can't get to where I'm going". The reaction was, more often than not, angry and aggressive. They treat "Waze can't get to where I'm going" as an attack on their lifestyle. After dealing with abusive drivers who will call me a liar to my face, screaming "that's the only thing I have!" at the top of their lungs, getting violent (I had one lady who punched her steering wheel while screaming the aforementioned), and sometimes getting straight-up kicking me out of the car (my response is always "Gladly!"), I've learned to call ahead and filter them out, as I have no desire to come within 10 feet of nasty, aggressive religious warriors. Oh, sure there have been plenty of Waze users who will let me navigate them manually (I can navigate from my office to my home in my sleep) or who will let me open Google Maps on my own phone and listen to the voice nav from there, but the number of angry fanboys and fangirls with no emotional maturity means that I'm not willing to risk it.
And it's because of the aggressive religious warriors who I'm afraid to share a vehicle with, and to a smaller degree because Waze's pathing sucks in general, I've started to call ahead to make sure they're not using Waze even when I'm not going to or from my house.
GMaps may notice the bridge is crowded when you get there, but at the point it can't reroute you, because you're already on the wrong side of the bay, so it will just update your ETA.
What I've found is that the Waze ETA is almost always accurate when I start the trip, whereas the GMaps one keeps updating as I go.
Waze on the other hand will often give me an estimate that's 20 minutes faster than Google Maps, and with the traffic that eventually pop up on that route, take me 20 minutes longer than what Google Maps estimated.
I'd be surprised if gmaps doesn't do the prediction you describe (I used to be in a sister team of the team doing traffic prediction).
Yes, Waze is willing to take you on side streets, by design, just like Google Maps isn't, deliberately. Waze is Gentoo, Google Maps is Ubuntu. One is tuned for the quickest drive, the other for directions that are simpler and thus easier to follow or remember (e.g., it doesn't reroute you if it knows it will save you just 2-3 minutes).
As a direct result Waze was unusable in large Italian cities for the longest time, long enough that the gap in free turn to turn navigation that was once there got filled by google maps on ios and everyone forgotten about that experiment. They eventually conceded and started mapping all the details as needed by turn to turn navigation, but too little, too late.
(source, in italian https://www.waze.com/forum/viewtopic.php?f=28&t=1408&start=1... )
In my experience, though, traffic has to be very bad for it to do this. Maybe it does it less often?
There are thing like OpenLR, which were invented exactly to solve these kinds of problems.
Technical issues can have solutions :)
I guess someone motivated could run some experiments and try to figure out what is actually shared.
Not that it wouldn't be nice to have in OSM, but it's just not something that fits into what OSM is. It's a whole separate service, even if such a service could be integrated with the third party apps that use OSM data.
But with only 7 map downloads I might as well not bother. Even just the Netherlands is more than 10 map downloads and you probably want at least a piece of Germany too.
On the one hand, OSMAnd felt like it was more accurate or well-behaved in some sense. But the interface was just so confusing (a few years ago), there were a couple of unlabeled icons for its major functions that were (to me) just too generic and could mean any of map/directions/route/search/location related. Even after a long period of use I found myself confusing these icons, having to tap-and-try and navigate (hah) myself through the navigation app.
... so did I understand correctly that the F-Droid version of OSMAnd does not have the 7 map limitation either?
Not wanting to pay for that is fine, whatever, but it's not exactly over the top for the people building the app and running the map infrastructure to charge a fee.
But why would your mum have heard of OSM and be trying to download it in the first place?
She might well have heard of a third-party app - in certain countries and communities OSM-based apps are massive and have significant brand recognition - and download that. Or she might be using a name brand like Apple or Facebook or Garmin or whoever, all of whom use OSM under the hood.
OSM isn't a consumer-facing brand and doesn't aim to be.
I work for a company that syndicates location data for businesses. We had a couple of businesses that wanted to syndicate to OSM.
It. Was. A. Nightmare.
We have addresses for every store. We don't know where the building is. Any store we place is going to be easy to place on a street near the building. If you've not placed it inside of the strip mall on the right spot, other people delete it. And what do you do with NYC? Suppose that you have a store that is somewhere on the second floor of a skyscraper. We don't know where it is in that building.
Have you tried to map out thousands of department stores? We know hours, phone numbers, and addresses for each department. We have NO idea what the actual store layout is. Without the layout, OSM basically didn't seem to want the rest of what we can give them.
If a customer is willing to pay us to deal with OSM, we're going to discourage them and ask for top dollar if they insist. It is that painful.
If you are, I would like you to also consider this from the point of view of (maybe volunteer) contributors who prefer less data but correct data in OSM. Maybe draw a parallel with Wikipedia where a page that is not up to the standards might be deleted.
(Not a contributor to OSM myself, but I have helped the French Drupal community and cofounded the Museomix community. Also, I appreciate precise data in OSM)
I know where Google, Bing, Facebook, Yelp, Foursquare, etc get phone numbers and current business hours for our clients. They are straightforward for us to work with, and we are happy to give it to them. OSM is not easy to work with us, so don't get that data.
OSM has a choice. Be easy to work with, or have limited data. OSM has chosen to be hard to work with. That is a valid choice, but then you have to live with the result.
I’m not an OSM expert at all — but I can guess that opening hours or phone numbers for a store that has no proper geographical location (and thus no geo-existence) would be perceived as not having its place in geographical database.
I suppose OSM is really a GIS (geographical information system) more than, for example, a tourist map, so it’s not totally absurd that volunteers would have issues with integrating data not properly aligned with the ideal way of working of a GIS (everything is geo-localized).
Google Maps has obviously diverging goals and incentives in that regards (serving ads, being an intermediate to stores).
As Google Maps and other online maps are trying to be many things, including the yellow pages, they probably don’t care about being an ideal GIS.
Open communities of contributors are often misunderstood when they enforce limits to contributions, and at the same time seek more contributors! But it makes sense when your success is defined on building a digital commons—scope and values is really what define the project, not much else.
(The Wikipedia community has to explain constantly that the goal is an encyclopedia, for example to people trying to use it for publishing their own findings, personal biography or fan pages. The Linux kernel won’t accept some driver contributions too.)
Of course it now seems that the OSM community of contributors is itself divided on what is the scope of OSM.
Your data is probably not near as bad as that, but if you put a POI on a map, and somebody goes there, but doesn't find it because its a couple hundred metres away, they're going to assume that it moved/went out of business (and remove the data).
I can think of two ways around this. One is to make a note about the incomplete data you have and hope that somebody finds the actual location and adds it. The second is to go-ahead and add the thing with a "fixme" tag saying "location approximate" or something. I've seen both techniques used in the past.
I guess you'd be looking to bypass the hard part.
OSM is not one of the places that we want to deal with providing that data to.
I was suggesting it as an alternative open distribution channel that was less concerned with details.
1. just make it available for everyone to download, try to add as much metadata as possible.
2. make it clear what kind of license you have for this data
Address coverage in OSM in general isn't great. There are regions that are good and then regions where there basically aren't addresses.
That absolutely isn't to say that the OSM community isn't interested in your data. Plenty of companies have offered their data to OSM, and OSM volunteers have done the hard work of finding the correct location for each store (or whatever) and adding it in. As I write, the UK community is integrating data on every Shell petrol station in the country; the result is much better than if we'd simply dumped the raw Shell data into OSM.
• Tags and relations are a total mess. There are many different and overlapping schemes. There is obviously outdated/sub-standard data, but automated fixes are forbidden. There are some neat tools to make sense of the tag data, but ultimately I had to deal with all that mess and complexity on my end.
• The lack of moderation or a way to officially act as an intermediary for edits (other than clunky oAuth flow) meant I couldn't expose an Add/Edit/Fix functionality for my users. Similarly, if I wanted to let my users upload a photo of a venue, there was no service to store it, no identifier or tag to associate it.
• The API returns only nodes entirely within an area, rather than everything intersecting a given area. If you fetch small lat/long area, you won't get a node for the country/city/district it's in, unless you stumble upon a point in its border or label. That meant I couldn't fetch things from OSM API as needed, and had to have my own copy of the data and the DB and custom search.
• The map looks ugly without buildings. There was free building data available for areas I was interested in, but I was told to copy them by hand.
The osm.org API is meant for editing. It's not a map rendering and querying API. There are lots of alternatives for that.
> There was free building data available for areas I was interested in, but I was told to copy them by hand.
OSM is open to imported data. It just has to be done carefully because "with great power comes great responsibility" - add millions of items to the OSM database and you can royally screw it up (there is an argument to say that most of OSM's problems in the US stem from this). But there's a well documented imports process and lots of people with experience in importing buildings to help you through it.
Neither automated edits nor imports are forbidden; they’re allowed with careful planning and consultation with the community.
In that case you wouldn't have to add the buildings to OSM to show them, just merge the data during your map preparation.
Nominatim does have a reverse geocode api which returns the sort of place information you want in your third point (given a coordinate, returns an address).
Please consider arms race encouraging automated edits would begin. A lot of people have a lot of awfully different views about how map data should be recorded (you thought source code formatting was contentious?)
> I couldn't expose an Add/Edit/Fix functionality for my users.
Lots of tools have managed this.
> if I wanted to let my users upload a photo of a venue, there was no service to store it
No. That's not what OpenStreetMap is. They aren't there to give out free image storage.
> The API returns only nodes entirely within an area
Yes, it's meant to be a low-level API which makes few assumptions about the meaning of any of the data. For the ability to make more complex queries you could have looked at Overpass. And possibly there is a space for a third party service to provide an API with such an ability. Again, I don't see that as OSM's business - OSM here should be considered more like the UN.
And yet NYC have managed somehow to get most city building data into OSM, so perhaps you haven't investigated every possible option for getting what you want here...?
I have given a few talks about using OSM data in the US government and it comes down to authoritative data sources and validation. It's a great starting point, but there needs to be another layer (or two) of validation before it can be used at the enterprise level. The National Map Corps has some good examples of how this can be implemented with data stewardship.
I am also working on a few projects to take public domain data and put it into OSM. While it's useful and mostly open, it's definitely less open than the original data sources. Another issues is that as soon as someone edits the imported data, it will become less authoritative as well.
Or better than the authoritative original.
Like with Wikipedia, where you often hear that people prefer to cite a single person as source (because "anyone could edit Wikipedia", as if no single person can setup a website or write a paper), at least Wikipedia has had thousands of reads and often dozens or hundreds of reviews. People are scared of the idea "it could be anyone", while the most likely editor is just a peer with good intentions.
There are established ways to combat this (peer review, data stewards, reputation scoring) and even OSM has a checkbox for further validation.
OSM will never fit every use case, but it's good to understand where it falls short and can improve.
And I still love OSM. I want to see it succeed!
My edits are probably not perfect, but while somebody cared about mapping the town in the first place, it was out of date enough that probably nobody would bother to approve or perfect my changes. Having them rejected would probably have caused me to stop contributing too.
What kinds of issues and vandalisms did you experience?
I think the beauty of this system is that it gives complete autonomy with no oversight to individuals dealing with obscure data that nobody else cares about, while more popular data is subjected to higher scrutiny.
So in OSM it's perfectly acceptable to delete an object and re-create it whereas in MusicBrainz deletions are very much frowned upon.
This means that you often can't really track changes to a single OSM object which would be pretty much necessary for implementing robust rollback behaviour.
Map additions are probably generally safe, although there are some spammy ones for various reasons. Map edits are basically all suspect because you never know when someone is trying to sabotage something.
I think it's good to keep in mind that OSM already has moderation, though, just not in the shape of a formalized approval process. Instead, edits go live instantly – but are inspected, discussed and possibly undone afterwards. So while vandalism does get through at first, it will hopefully be short-lived enough that it does not pay off for the vandal.
Ultimately, I believe it comes down to weighing priorities based on the project's current needs. OSM's current approach lowers the bar for contributors and rewards them with instant gratification when the change is visible on the map right away. Because of that, I believe it makes sense when your focus is on growing the community. Stricter moderation makes sense once the primary focus switches from growth to preserving the valuable database you've already built.
Looking at Wikipedia, for example, they started out with a setup resembling OSM's current model, and switched to a more strict moderation process only once they had grown large enough to become the world's default encyclopedia.
Based on my personal experiences in OSM, vandalism is not yet a big enough problem to justify stricter moderation practices. But of course that is a matter of opinion to some degree.
Those edits are usually people adding useless businesses and phone-numbers. I've seen people advertising bitcoin-related business and general spam.
Moderation isn't the worst idea, OSM in many areas basically has large scale edit wars, wasting editors time as they fight over road and building alignment with other editors that don't realize Microsoft's satellite data is 20ft off from reality.
But where OSM has failed most in my view (and maybe I need to add this to the article) is that there are now free geographic datasets from local governments and without the ability to integrate them into OSM easily, and then update them (which we basically can't do), I fear OSM is going to ultimately fail at its mission
Far from the case, I'm afraid.
There's relatively generalized tools for diffing data against OSM and outputting a change file, but lots of data is released using ambiguous or slightly incompatible licensing.
One example is http://blog.improve-osm.org/en/2018/01/new-features-and-enha...
If Apple has trouble keeping feature parity with Google Maps, there is no way that an endeavor like Open Street Maps has any real chance of making something with the breadth, features, and usability of Google Maps.
Before making such an insulting claim to so many volunteers' hard work, get your facts straight. We did it.
In the few countries I have experience with the data (western Europe), the quality is great. It could be more complete on business information, but for the rest (think hiking trails, footpaths, cycling paths, etc.), OSM is more complete in every country I know of.
The data is also more current: when a tunnel nearby here was opened on a Thursday at 8pm, I checked the next weekend to see if someone had mapped it yet. Turns out, at 7am the next morning someone already did it. A few subsequent edits completed the thing. People here care and are jumping on projects like that. Google Maps, the winner (according to you) took a few weeks to get their facts straight. People drove wrong so many times to our place and we keep telling them, just use OSM... Some of our friends do, but not everyone. It's a marketing problem, not a lack of talent or manpower.
I'm honestly not even sure what half this article is about. I'm an active mapper and have yet to discover a single case where it's vandalism beyond doubt of stupidity. I've heard of cases, but never found any. Even stupidity, only in very few cases does it truly mess something up (like like disconnecting roads). I'm guessing OP is not from Europe, and local quality varies on the number of mappers, availability of open data, etc. That it's failing in the USA because it's a completely different world (people seem to think differently, more commercially) doesn't mean the project failed as a whole.
Which is true, but Google doesn't get to define "maps".
Indeed, Google Maps as expounded by Mr O'Beirne is the very antithesis of OSM. He argues that Google is unstoppable because of its technology: that it can derive building shapes, heights, etc. from imagery much better than anyone else can.
That's almost certainly true (though Facebook is doing interesting ML-based stuff in this area with OSM) but it's not what OSM is. If Google is the apotheosis of technology, OSM is the apotheosis of human curiosity. It's the collected works of everyone with a particular interest that can be recorded geographically. You're interested in cycle routes? Add them in. Long-distance hiking paths? Go for it. Detailed coverage of the area where you live? We'd love to have you.
So for cycle paths, for long-distance hikes, for areas where we have committed contributors, OSM is streets ahead of Google. It doesn't always work. We struggle with stuff that no-one is interested in (principally addressing, which is just insanely boring to survey) and in areas where people aren't motivated to add stuff (basically, poor areas: OSM is a very middle-class pursuit and this is our biggest problem by a long way). Still, OSM is pretty much the opposite of Google Maps, and any comparison will fall down on that.
(Footnote: in this regard, Google's biggest advantage is that they get to draw on the entire Google search corpus. For POIs, that can be the equal of the best OSM can do, and I don't think we can easily match it. That said, Google hasn't yet worked out how to scrape linear/polygon data, and their attempt at mobilising a community to do this - Google Map Maker - ended in fairly spectacular failure.)
A big issue is consistency though: OpenStreetMap varies way more in quality between regions, to the point that detailed conversations almost make no sense without disclaimers about where you are talking. OpenStreetMap is a really good map where a strong community exists (either locally or dedicated remote interest) and a pretty bad map if no large effort has touched the area.
I checked the "I consider my work public domain" box, 6 months latter google started giving better directions around my neighborhood. I doubt this is coincidence. However the ability to fix directions to your personal house is something OSM does better than google today.
Usefulness while on foot. In well-mapped areas, OpenStreetMap has every little footpath between buildings, through parks and forests, ..., with information if it is publicly accessible or not. Google Maps is missing tons of them.
Offline functionality. (Google could change this, but I somehow don't see them allowing to download entire countries at once)
For historic example see:
There are a few local specific maps ( Here's one in Welsh https://openstreetmap.cymru/ )
Interested in what shops/venues are wheelchair accessible? Wheelmap has you covered https://wheelmap.org/map#/?zoom=14
Kurviger is a routing service for motorcyclists. Pick a point, select a direction, and a distance, and it'll generate a round trip that doesn't go on the same road twice, you can go direct, or sorta curvy, or very curvy roads. https://kurviger.de/en
I've never been to Japan. Can you elaborate?
One nice thing about open data is it can outlast. What do you think will survive and be readily accessible on the internet longer, Wikipedia or Quora? My money's on Wikipedia 100%.
With OSM things are similar. Obviously geo data has additional ways it can grow stale, but still. Google is big today but there's no guarantee for the future.
OSM had the street in its database from the start.
It took Google Maps more than a year (?) to catch up, and consequently in 2015 for example an Uber driver at the time would try and drive you to the opposite side of Paris where a museum had a garden of the same name… not good when you had an appointment with an official there :-)
Get Microsoft, Tom Tom, Samsung - everyone else - to work on OSM.
Right now, Apple is basically building the "Windows Phone" of map solutions, because it "wants to be different", and making the same mistake Nokia did in smartphones.
They should get over their own egos and actually choose the option with the highest chance of success against Google Maps.
But does it need to? Isn't there a market for basic mapping, without all the needless feature bloat?
I'd rather a mapping service concentrate on getting roads right, and not whether there is a Howard Johnson's nearby.
There should be a strict schema that would be community managed through some process.
And if you do find a situation where there are multiple options, it takes only a quick check on taginfo to find the more commonly used one. If you go with that, it should converge soon.
Maybe something in the middle, like the current wiki system but with an enforcement rule of whatever is on the wiki. Anyone could freely edit it because it's a wiki (adding allowed options, and removing/changing any that have extremely few uses (zero, or perhaps a few which are then removed)), but at least there is a correct spec.
If people really had to adhere to a strict, slow-moving standard with pre-approval, the spec would also become extremely complex and very difficult to implement, because the spec-makers will want to think of every eventuality. See any other large specification ever, like HTML or something. I can't see that ending well. I think a hybrid system might be better than a strict one, given the choice between those two.
I like thinking about it though! Always good to have hear ideas.
Improvement over what exists now would require that the schema be applied strictly and that isn't going to happen with a huge crowdsourced project.
I looked closely at getting deeply involved with OSM a few years back. And bounced off hard because the community is infested with assholes. There's a lot of very rude people who are active on the mailing lists that set the culture. It made me uninterested in trying to work through those cultural problems to improve the technical project. I'm not alone in this feeling.
The tools were difficult, as is mentioned in the main post. That is certainly an inconvenience but I figured we could muddle through that. The bigger problem is that the customers just never got it. They wanted a single, authoritative classification for an object.
Our plan is to move to a system inspired by the model used in BIM for classification. The princicple difference is that in open street map all data identifying an object has to lie within the tags. In the alternate system, a single identifier for the object type is used, and this references external metadata that gives you additional information which does not have to be embedded in the tags on the object. An example of additional information held external to the map and tags is that a bathroom is a type of room. I don't have to include in the map data that the object is both a bathroom and a room.
I should add, the external meta data also gives a strict definition of what types of tags (and maybe values) are allowed on the given type of object. If you need something a little different, you can make a new type.
I am not sure how well this type of system could work in open street map. Is it too rigid? Or would there be too much proliferation of types? Classification is always hard and I am not sure people have solved that problem in any large context.
And of course, changes like this would mean a new database. If people ever do think about making an OSM 2.0 maybe this, or another tagging alternative, is something to consider.
> I am not sure how well this type of system could work in open street map. Is it too rigid? Or would there be too much proliferation of types? Classification is always hard and I am not sure people have solved that problem in any large context.
Ontologies are well-researched. Unfortunately they're not my area of expertise as I turned away from doing a PhD in them and went into business.
I have been playing with a controlled vocabulary since Christmas for a personal project and the complexity of definition has made me think this is why Google et al have gone for a more flexible, machine-learned typing, and why the types for schema.org are so broad.
Having been negative, I think this is exactly what OSM needs to organise the world's objects.
On this point and the main part of the first argument, I kinda disagree; the OSM project should specifically aim to do that: providing means for one to create a service.
However, providing an actual map service would cost much, much more in bandwidth and I doubt a free software project like this has that kind of funds - actually serving tiles can add up to large costs pretty fast if enough people use the service.
So if you want an actual service, you either do the hosting yourself or go see mapbox/whatever.
On my Galaxy Note 2 (2012), you're right. I've ordered a new phone yesterday because it's getting quite bad after five years of daily use.
My girlfriend bought a phone for €300, and the one I ordered (now, a year later) for €250 actually has the same chipset. It runs great on that.
I consider ~250eur to be the bottom of the smartphone market unless you're going for a potato to call and text with (not even browse the web). Given that it runs smooth on that... I'm not sure what you're running OsmAnd on with expectations of fast rendering.
That's ridiculous statement in itself. The bottom of the market are those <$100 china wonder phones, and you have a selection of low-end, but actually branded, devices in the <150eur category. Surprisingly enough, those <150eur devices look like they might be perfectly usable, with specs comparable to my current daily driver (which is couple of years old). As a random example, Huawei Honor 6A  currently retails for 99eur around here
So, now that we clarified I'm not a troll, nor a bot, I ask you: how should we deal with those issues? Join en masse the OSMF so we can vote for a change? Begin the "New-OSM-But-Better Foundation"?
I also think having layers (particularly, layers vouched by governments) would be awesome. I saw several governmental branches in Brazil wanting to be more integrated with OSM - this would allow them to stay "inside" OSM (and being an accredited citizen), instead of creating their own silos, importing data from time to time.