I needed a bigger kick in the butt to try something else.
Honestly, what a sell out. What was once neutral territory for businesses is now available for bidding.
Does Google need this revenue? What is the problem with the existing maps that they are solving?
I see the full keynote is here [1]
At least in Germany Open Streetmaps has vastly better maps than Google Maps. On a global scale Google or Bing maps are very consistent while OSM depends on the local community, but they are well worth checking out.
For satellite images Google Earth is hard to beat, but Bing has good images as well
* Standardization of the model for mapping on multiple levels, and with 3D, and integration of that with the editors.
* Finding standardized ways to test, approve and automate maintenance of data consistency. There seems to be a lot of ad-hoc script editing, like someone writing a script to make a one-off edit of the global dataset to do a spelling correction. If that's going to happen, it should have pre-approval, and probably be integrated into an official, periodic checking and consistency process. Along the same lines, I'm not convinced small malicious or mistaken data edits will be picked up as quickly as they should be. I think most of the tools and structures are there to build the map, but not necessarily to maintain it.
* Doing more to link the OpenStreetMap.org site to the projects using the data. i.e. more clearly positioning the site as a data repository, and place to find ways to consume the data, and less as a toe-to-toe competitor to Google Maps.
* Pushing forward in links with wikipedia, preferably forming a connection with the structured/geographical data on wikipedia (if it's possible to find a license which is compatible with both projects, and wouldn't lock in either party). Having more eyes on the data should help to prevent bit rot.
* Finding hardware to automate data collection for Mapillary (the Streetview equivalent).
* Improvement of search/geocoding algorithms - to try to fill in patchy street data information (i.e. detecting sequences in house numbering). Then using those algorithms both to improve the geocoding capability, and to prioritize where data most needs to be collected - a handful of house numbers are vital for a major 5km road through the centre of a city, but they are far less important for a 30m cul-de-sac.
* Finding ways to have more area based mapping for pavements, cycleways, shared space roads, pedestrian crossings, public squares etc, as an additional, progressive enhancement to the line and dot model for footways, highways, etc. Something which can be used to provide additional information in city areas where that sort of low-level mapping is useful/necessary, but isn't necessary elsewhere (clearly the whole world will never be mapped in the detail that you'd like to map central London, or one particular central railway station)
In general, trying to develop policies to encourage the database to be maintained, and data collection to be managed, in a way which makes it easy to consume the data in a structured way.
Glad to be corrected if I'm wrong, or ignorant of progress.
Do you mean getting Wikipedia to use OSM more? The basic scheme of tagging wikipedia and wikidata links on OSM objects seems pretty complete on the OSM side (there's just lots of things that could have tags that don't).
Area mapping for highways is well enough sketched out, but I think there isn't a natural way to derive a graph, so it ends up being visual detail and a low priority (I don't care about having it in my area so will spend ~0 time on it).
The search on OSM.org (nominatim) is slightly pedantic, approximately for the reason in your last point. Pelias and Photon both bring stronger search to OSM data.
> Automated fixing of them is generally pushed back against socially though. I think for good reasons. One is that a data user can do the automated fixes if they want to, so it's better to put human eyes on all the issues so that the ambiguous ones get fixed correctly. This is perhaps a conservative pov, the less ambiguous cases can probably be safely resolved with automation.
I just think that sporadic, automatic editing of the global dataset, without much (or any) pre-approval, doesn't make sense. Better that there was more effort put into coming to formal decisions, and that those decisions, when adopted, become official and consistently applied. To take a trivial example, if someone's going to collapse MacDonalds, Mcdonald's, McDonald's, "MacDonald's Restaurant" and 15 other permutations down to one spelling worldwide, that shouldn't be a decision to be made by one individual, posibly reversed if they really get out of line or end up making some bad mistake, and applied only once or sporadically, it would be better IMO to be debated up-front, approved or rejected as a formal policy, and maintained.
On wikipedia, I mean finding ways to couple their structure/geographical data with OSM, for instance if you have a building article on wikipedia, with structured data about construction date, architect, location, possibly 3D model, and similar and overlapping information about construction date, outline, entrances, etc on OpenStreetMap. Probably you'll never have an automatic coupling, but you could for instance have joint efforts to set shared conventions for the structure of the data, and constitency tools to point out where data is available in one but not the other, or disagrees between the two.
I don't really see the need for shared conventions with the Wikipedia stuff, as long as each project ends up settling on a convention it shouldn't be a big deal to reconcile just those 2 conventions. Wikipedia/Wikidata are anyway probably the better place to put endless trivia.
Excellent point about the suggestions through the web editor, though, perhaps that will be enough. As a matter of interest, do you have any idea who decides what items are in the editor (for instance, if tags are disputed or inconsistent)? And are the suggestions done by popularity, or are they manually decided?
On shared conventions, it's just, do you have separate start and end construction dates, or combined, do you write that 1930-34 or 1930:1934, how do you handle approximate dates, are you going to write C19, 19th C, 19th century or 19C, and so on.
In general I just think you need more active decision making, and a process towards consistency in the data. It's really tough to consume data from a geographical database where everything is up in the air.
The preset system in iD is driven by the data here:
https://github.com/openstreetmap/iD/tree/master/data
In particular, the suggestions are built here:
https://github.com/osmlab/name-suggestion-index
The process looks at popularity and then tries to do some standardization from there, suggesting a most popular form when less popular forms are encountered. There's a shorter list of committers, but I would say it's overall reasonably open to contributions.
My point with the Wikipedia is who cares. If you know Wikipedia does 1930-34 and OSM does 1930:1934, the details of converting one to the other will tend to be a lot simpler than any interesting thing you are trying to do with the combined data. It's a bunch of annoying cat herding to get a little bit of hypothetical convenience (hypothetical because what interesting thing is presently held back by the different forms?).
Luckily, most of my map needs are met by a local competitor (mapy.cz). They are not perfect, but are still much superior, at least for what I want from maps.
Coincidentally, their Android app (which supports offline maps) got really slow few months back. I wish I could easily downgrade to an older version (as I did with online Google maps before I gave up).
http://www.wsj.com/articles/google-to-increase-size-frequenc...
Noooooooooooooooo =(. Sounds like a good chance for competitors to jump in.
Thanks for sharing this though, I didn't know that =)
Yes, of course.
> What is the problem with the existing maps that they are solving?
It's not generating enough revenue.