With the exception of adding additional addresses that previously was done by the mapboxes of the world, I don’t quite see why everyone is reading an ‘open google competitor’ into this. Overture has neither announced open aerial / sat data nor open traffic data and I don’t see any economic reason why that would change. These are the things that most people find missing in purely OSM based apps.
I would aggree that technically the Overture play is similar to what cloudmade, mapbox and others have done in the past and what others that haven’t pivoted away from that yet are still doing. But as I pointed out in my 1st comment, there is a qualitative difference between having a multitude of small players serving as an intermediary and a single big business pressure group as sole distributor.
Ok, I think you meant that even if technically they would not be sole distributor, then there is real risk that they just do what Google Maps did 20yrs ago to bulk of geo business: have more famous, nicer, richer and cheaper (free!) product than now provided by small ones (like MapTiler), right? And then OM would be way stronger and tougher partner for OSM community (and OSMF) than previous corps, who have also tried to nudge OSM to be better for their commercial needs. Valid point.
As someone with history of being pushed out of my OSM-based microbusiness by mapbox (kinda) I see that the next level of consolidations, the big ones taking over them is just a law of nature and business, something companies always need to take into account. Now for OSMF the key is to make clear to OM parties that OSM is first of all living community with own strong opinions and everyone needs to be super careful with community who gives them golden eggs. Use the data, attribute, sponsor a bit, but stay in a safe distance.
Via a hacker news post, I came across this blog post from 2018: Seems to have flagged some of the underlying concerns that the group behind Overture has and tries to solve from their perspective?
Some form of persistent IDs, standardized tagging, protection from poor edits by having a review method, and layers
To me as a new contributor to the project that mostly map POIs, that blog post calls out very sensible things that I wish the OSMF could pick up on
He actually followed up and provided more details in a new comment
He’d tried to import addresses in Vancouver based on public government data, but had gotten pushback from someone that said you could only map that on the ground.
For the avoidance of doubt he suggested trying to do this in 2014, and said then that he didn’t know how to do the work himself (“and I don’t know if my weak GIS/coding skills would be enough to achieve it”). What this has to do with anything now I have no idea.
@andygol : I wanted to quickly comment on the API part in your blog post, part 2:
The site code itself is inseparable from the API code. A limited circle of people is responsible for its maintenance, which is good, but they only have enough strength to maintain the infrastructure. I assume that they no longer have the energy or time for any innovations, and they are not obliged to do it either. They act on a voluntary basis without receiving any reward other than moral satisfaction and understanding of their own significance for the project.
It seems you’ve missed some of the recent progress in the API space. Most of the productive API code resides in a separate repo nowadays and was written in C++. In particular the changeset upload was rewritten from scratch back in 2019 and now runs about 60 times faster than the old version. As a result of that, we could shut down 3 out of 6 servers, b/c they were no longer needed.
Besides, the API evolved over time:
we’ve added JSON support as an example, retired no longer needed endpoints, password security was enhanced, we’ve added OAuth 2.0 to enable single sign on for this Discourse instance, etc.
Of course, none of this is managed by the OSMF directly, the OSMF doesn’t run the osm website project (I guess you knew that already).
Behind the scenes, there’s much more software running (like osmdbt, planet-dump-ng, Chef cookbooks, osmosis, osm2pgsql, mod_tile…), which you didn’t even mention. Some of it was also sponsored in part by the OSMF.
I agree with essentially all in the above posting, except the quoted which is patently wrong.
While it might be arguably true that the OSMF dosen’t control the websites code development (though they have in the past directly or indirectly paid for parts of it), not only does the OSMF own all hardware that the site runs on, pays in full for all hosting and employs a full time SRE to keep it running, every user of it and associated services agrees to the OSMFs ToS.
Speaking for myself, I am more enlightened by (much of) this thread and will continue to keep my eyes open to this. I think we (OSM Contributors) should keep our eyes open to this and continue to “discuss amongst ourselves.” Maybe this isn’t an ideal space (some heat, some light), but it seems some of us found some value here.
This could be a “landing place” for any news updates our community might wish to post about this topic.
To be actually useful for data consumers (in this case: router applications), OpenStreetMap data needs to be put through quite a number of preprocessing.
This is not anything that can be blamed on OSM not being flexible enough or something, but simply it is sometimes not prudent to keep the data always in a form that is easiest to consume by certain data consumers. For example (referring to the discussion linked above), expecting mappers to add the street name it belongs to to every separately mapped sidewalk is utopian, even more so to create a relation for every street into which separately mapped sidewalks (etc) would be added.
So, data processing needs to be done for at least relating separately mapped sidewalks, cycleways, (parkings,) etc. to their associated street in order to facilitate proper pedestrian and cyclist routing.
Then, the 85% missing maxspeeds on roads have to be filled with more or less educated guesses about default speed limits (I talked about this on the SOTM2022) as well as any other rules that may apply in or outside of built-up areas. For the latter of course, it is necessary to also first ascertain which road is likely inside and which is likely outside of a built-up area first through geospatial analysis and/or using third party data sources.
Currently, every (router) application developer more or less brews its own stew here. I see a chance that Overturemaps could build the foundation to father the open source software necessary to transform the OSM data into a more user-facing data set by inferring and complementing data into a more accessible form. This software could then in turn be used by anyone (given that indeed there is a committment to develop it as open source software).
That’s an interesting idea. That said, given the identity of Overture’s founding partners, I suspect their focus is going to be on car-centric and POI datasets. I doubt walking and cycling will really register on their radar.
As a person that works as a corporate editor, I can attest that the focus of these entities is very much concerned with car navigation. When I interact with non-car related objects in my daily job it is because they often interact with the road system in some fashion.
One of the more intriguing aspects of the OMF is while they have made lots of noises about “open”, in concrete terms, the only take on this has been from Tomtom that explicitly said that they -wouldn’t- be contributing their proprietary data.
The OMF person interviewed above suggested a release of something that “wasn’t just a schema” (i.e. some actual data) by June. Obviously a repackaging of OSM data in some way (like Facebook’s “Daylight Map”) is a possibility, but presumably some sort of “appropriately licensed data aggregation” (think https://openaddresses.io/, but wider in scope) is also an option? Another “data” option is a pile of “machine learning”-derived stuff (we’ve already seen lots of alleged “missing buildings” and “missing roads” from the OMF partners) but I suspect that’s less likely because it’d be more open to ridicule if it was (as some previous contributions in that area have been) a bit rubbish.
Obviously (like everyone else here) I am just idly speculating , but in organisational terms the beginning of June isn’t that far away and the question may well become “what can we do by then” rather than “would would we like to do”.
I wasn’t implying that they wouldn’t release anything, just that it wouldn’t be their proprietary data and that likely includes POIs (which they for the major part will have bought from yelp etc to start with). I suspect that they we will see a daylight distribution probably with their new schema and associated data as they currently do (MS buildings and so on). Addresses might be tricky from single source right now, so they would probably need to restart collecting suitable open data for that.
Naturally the elephant in the room is when and how they will start working on removing OSM from their road network.
