What this viewpoint does hint at is it's comparison to Wikipedia, and the differences in geospatial data of a current map of the world. Pekk is correct, an area in OSM needs to be continually updated and refreshed, and this requires appropriate tools and a user base. Both of these exist or are being improved upon with OSM.
For example, work has happened re: Monitoring of changes, comparisons with imagery, map bug reports, automated feeds, academic and industry reports and evaluations of the quality with proprietary and national mapping agency datasets.
Proprietary geospatial data can be very hit and miss. If you assume that the majority will be high quality, you're setting yourself up for disappointment...
There is actually not a lot of "high quality bulk data" out there. What datasets are you thinking of?
Remember OSM is "open data", so you can't import propriatary data. Some bulk datasets might not allow commerical reuse, or might forbid derivative works (i.e. no-one can change it).
> OSM requires contributors to manually trace shapes in their weird browser app
There are many editors. iD is the browser app. There's JOSM a desktop, advanced app. And you can always upload raw data via the API.
There is however a wariness to use it too much since maintenance and community building both suffer.
It has been found that encouraging a community around the data collection creates much better data in the long run. An involved community can go beyond what is provided by other datasets and do more than can be done with 'tracing'.
There's more to OSM that road centre-lines and building outlines.
Nine years' experience is that a community of people is the best way to make good data and keep it up-to-date.
Why do you think OSM isn't capable of utilizing automated processes? If anything, the manual editing process allows OSM to catch the long-tail data touch-ups that automated processes will never be able to handle.
Oh. I think yes this is scalable. I'll give folks some examples of how crowd-sourcing works like this, and how it can be scalable.
1. A person knows where they live, they can add their own street. They may know their neighbourhood, they can map it from scratch, or more likely keep it up to date. The user may see that their family home or where they vacation needs a tweak here and there, and pops on and edits. It's very casual, very local based monitoring and editing. This is scalable in the sense that it's small tasks that take a small time.
2. Based on an academic evaluation of a countries government's base map and OSM, several places are shown to be less well covered in OSM. These are targets for more dedicated mappers to examine, on foot, or with aerial imagery to improve. Hardcore mappers mainly here, large tasks, large time.
3. Mapping workshops are held in a small town to blitz a new development, fill holes and cover an entire area all at once. Twenty participants can do a large area with transport and the right equipment.
4. web based task manager is set up to allocate squares of land for people to trace from, dozens of people can take a small square and trace over the top. Local knowledge can then quickly add in names and landmarks.
So you can see that there are a number of different crowd-sourced labour approaches which would replicate what an import would do, but that by crowdsourcing you actually increase the number of people in that labour pool. An import does not help increase the number of contributors.
Now, this is more scalable in developed countries where there are more people with time to donate (same applies to any unpaid crowdsourced project), and so that example no. 1 in developing countries of an organic community keeping things up to date wouldn't really happen. However it's quite widespread in the developing world that there are no proprietary datasets of any decent quality. Imports could not even be considered in these places.
A recent push is to make sure that people doing imports have some sort of plan for updating and maintaining the imported data.
So it isn't 'cannot or refuse to make use of', it is more 'not interested in being a dumping ground for anything and everything'.
Whereas some other countries seem to have had better sources of data available and got on with the job of figuring out the best ways to import them without making a mess.
I like the current assisted approach of letting you turn on a TIGER 2012 overlay in the editor, and/or use tools like the "TIGER 2012 Battlegrid" (http://maproulette.org/battlegrid/) to find where OSM/TIGER differ.
So far based on some limited experience fixing OSM based on those tools, it's a good decision imo not to do it in an automated fashion, because when I've found OSM/TIGER differences, it was about 50/50 which of the two was right.
See also the recent buzz around gcc (TL;DR: gcc is about freeing users from proprietary implementations, not about having the best product ever), and Wikipedia (everybody knows something, Wikipedia is here to share this knowledge and make sure it can't be withheld)
Only for those who speak with ignorance...
Because a person who rationally cares about great map data for their whole lives, and also cares about other things (like liberty) might well prefer the growing pains of being an earlier adopter to the instant convenience of using Google Maps.
I understand that you, like many people, have decided that the attributes you care about are the only ones that are rational to care about. But that is a gross mistake, and that mistake undermines the entire premise of your rant.
Do you think you could squeze some more status posturing out of your choice of software products?
As another example within GPS, Waze used to give truly horrendous routes, as it would often fail to understand the difference between overpasses and intersections. A bunch of early adopters liked the promise of Waze and helped crowd-source the fixes, so that now Waze is a very good navigator.
By the OP's logic, the early adopters who helped make Waze great were irrational, because it truly was worse for quite a long time.
That said, I get it, you're just here to snark at strangers. After all, if you'd had even a hint of an interest in a real conversation you would've realized I never stated that any set of attributes was better than any other, nor that my interpretation of attribute definitions was the only valid one.
Anyway, thanks for the snarky bullshit and have a nice day.
Setting aside ideological purity, the actual rationality of switching solely to OSM depends on the actual quality and freshness of its data. And most of the world with money in play is more likely to follow rationality than ideological purity here.
But with regard to data quality, OSM is encumbered its own policy. OSM cannot (or refuses to) make use of high-quality bulk data from outside, regardless of how that data was licensed. Automation allows more frequent updates with a lot less manual labor as input - but OSM requires contributors to manually trace shapes in their weird browser app. Even where plenty of excellent liberally licensed data is available, OSM insists on making an army of unpaid monkeys re-make the SAME data in perpetuity.
That puts its pipeline at a permanent disadvantage to companies building proprietary datasets, which can take advantage of all kinds of automation. OSM simply isn't doing as much as it could to verify its data and stay fresh, and so it isn't doing as much as it could to end the status quo of proprietary data. Even if OSM reaches a usable state at a given moment, the world keeps changing to invalidate previously traced data, and OSM's policy ensures it will always be playing catch-up no matter who wants to donate data, because all the data has to come through this dopey manual process.