No. I am stating that OSM has no setup for, or desire to, accept useful but incomplete data. And unless they do, they will not have data available that other services have.

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 don’t want to argue, I understand your position of trying to publish this data and being frustrated by the data being deemed not useful or in scope by other contributors.

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.

What qualifies as useful but incomplete data is relative (and to a degree -- a matter of opinion). If am told "there is a big mountain here, give-or-take 1 km" that's probably useful. But if I'm told "there is a water fountain here give-or-take 1 km" that is pretty darn useless.

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.

alltheplaces is almost what you are looking for.

https://github.com/alltheplaces/alltheplaces

I guess you'd be looking to bypass the hard part.

No, that's the opposite of what we are looking for. We're not looking for data that other people have uploaded. We've got that data straight from the companies before it is publicly announced. We're publishing it to everywhere the companies want it published to.

OSM is not one of the places that we want to deal with providing that data to.

If you hand alltheplaces your data, people ingesting alltheplaces will have your data.

I was suggesting it as an alternative open distribution channel that was less concerned with details.

Hello. I am the creator of alltheplaces and Max is absolutely correct. Alltheplaces is a bunch of scrapers right now because it was the fastest way to get the data, but if you have data in a machine readable format already then I don't have to scrape it. I can just download your data file and distribute it to whomever wants to use it (people interested in importing to OSM, geocoders/search engines, etc.).

Comming from the other side I've dealt with a lot of companies trying to use Openstreetmap, and they are all really bad at it. Two things I say to everyone who want to import data to Openstreetmap. These seems to be very hard things for people to manage, do you have any idea why that would be?

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

The broader point is that there's a structural issue here, as there's no ability to link data to addresses in a form that doesn't require literally knowing the location of a store within a building ahead of time.

I think in this case his criticism is merited. There is plenty of open data for street addresses available, and almost certainly already in osm. Instead of linking the most basic form of physical site identification -- which is basically a legal data set maintained by governments -- to their data import functionality/process, they just refuse data. Sounds off to me.

Plenty of governments restrict use of their address 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.

I am certainly not an expert on international data access regulations. But at the same time, there is more than enough of that information publicly available to make it a basic first step in a mapping application/dataset.

Open address has a good map that show this (http://results.openaddresses.io/), but for any area that is grey on that map you are going to be a long way from that "basic first step" you talk about. Adress data is hard, there are so many shitty collections with bad licenses.

Thanks for that link. I dropped their coverage chart into a spreadsheet to come up with 1,184,252,000 (surely estimated) people covered by their address data - not to mention covered commercial addresses, which started this thread. My point was that there is enough green on that map, and enough obvious, critical demand, to make it a pretty fundamental feature for a mapping process, not that it would work most of the time.