<div dir="ltr"><span style="font-size:12.8px">> </span><span style="font-size:12.8px">Ilya: </span><span style="font-size:12.8px">I am not sure if I should add the brand:wikidata=Q154950 tag, and for now decided against that.<br></span><br>If the brand:wikidata=   will be included, we need to discuss what is the correct Wikidata ID,   Q28974622  or Q154950?<br><br><a href="https://www.wikidata.org/wiki/Q28974622">https://www.wikidata.org/wiki/Q28974622</a> Shell UK; official website = <a href="http://www.shell.co.uk">http://www.shell.co.uk</a><div>or the linked parent organization:   <a href="https://www.wikidata.org/wiki/Q154950">https://www.wikidata.org/wiki/Q154950</a>   Royal Dutch Shell;  official website= <a href="http://www.shell.com">http://www.shell.com</a> </div><div><br>Imre<br><br><br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-05-12 18:08 GMT+02:00 Ilya Zverev <span dir="ltr"><<a href="mailto:ilya@zverev.info" target="_blank">ilya@zverev.info</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
<br>
First, I was amazed at the response. Thanks for constructive feedback, which I answer below, and no thanks for toxic responses, including asking for money (what money? We — as in <a href="http://maps.me" rel="noreferrer" target="_blank">maps.me</a> — get none out of this) and imposing impossible restrictions (manually investigate context for each of thousands of points?). No import is perfect, and I cannot make this one too good for you. But it is pretty okay to me.<br>
<br>
I have refined the tag processing script. Removed name tags, changed postal_code to addr:postcode and formatted phone numbers according to the wikipedia table. "Navads" is appended to the source tag if present. I am not sure if I should add the brand:wikidata=Q154950 tag, and for now decided against that.<br>
<br>
You can see the updated result here: <a href="http://bl.ocks.org/Zverik/raw/ddcfaf2da25a3dfda00a3d93a62f218d/" rel="noreferrer" target="_blank">http://bl.ocks.org/Zverik/raw/<wbr>ddcfaf2da25a3dfda00a3d93a62f21<wbr>8d/</a> (with OpenStreetMap and Satellite layers).<br>
<br>
Also I have started the wiki page: <a href="https://wiki.openstreetmap.org/wiki/Navads_Imports" rel="noreferrer" target="_blank">https://wiki.openstreetmap.<wbr>org/wiki/Navads_Imports</a><br>
<br>
* Geocoding and accuracy: as I see on the map, all points in the dataset are placed properly on top of the fuel stations. The error based on OSM data is mostly inside 10 meters. I will ask NavAds for coordinate source for further datasets, but since most points are already in OSM, I think that would fall into the "fair use" clause. In this import, only 125 points are added as unmatched.<br>
<br>
* Other fuel stations inside 50 meters: I have found only one instance where the brand was changed. It is here: <a href="https://goo.gl/maps/9GLTVg1EWR82" rel="noreferrer" target="_blank">https://goo.gl/maps/<wbr>9GLTVg1EWR82</a> . The Street View from 2015 shows the BP station, but the map lists both BP and Shell. I assume the fuel station was overtaken in the past two years.<br>
<br>
Then I filtered fuel stations with the ref_distance > 30 meters (there are eight) and placed them on satellite imagery. Looks like that all of these are correct, and the big distances come from placement errors in OSM.<br>
<br>
* Official information vs on the ground: five objects have their opening hours changed. I assume Shell knows how their fuel stations work. Regarding other tags, only phone and addr:postcode replace OSM values (11 and 9 changed); other tags, including operator, are preserved. In the Frederik's hypothetical example, the number of rooms will be added only if there are no such tag on the already existing hotel.<br>
<br>
* Freshness: Navads will update the data when Shell provides the update. It is as fresh as can be, but your changes to OSM won't be overwritten: if you saw opening hours changed, do update these. By the way, Robert's example about mismatch between opening hours on the Shell website and in the data is incorrect, I checked it and they match.<br>
<br>
* Five Ways Roundabout issue: I have forwarded that to NavAds. Also I asked them about links to branches (I cannot find any on the Shell website though) and names.<br>
<br>
* "The general view seems to be against IDs like this": what has happened with the principle "any tags you like"? Did we saturate the key space and not accepting new keys anymore? Can I read that "general view" documented anywhere? The "ref:navads_shell" key is the only one that is not verifiable on the ground, and is clearly added so the further updates do not have to rely on matching.<br>
<br>
Ilya<br>
<br>
> 12 мая 2017 г., в 1:22, Frederik Ramm <<a href="mailto:frederik@remote.org">frederik@remote.org</a>> написал(а):<br>
<div class="HOEnZb"><div class="h5">><br>
> Hi,<br>
><br>
> On 05/11/2017 05:39 PM, Ilya Zverev wrote:<br>
>> Together with the NavAds company, we plan to import a thousand Shell<br>
>> fuel stations to the United Kingdom. The source is official, which<br>
>> means, Shell company specifically shared the dataset to put them on<br>
>> maps. Do you have any objections or questions?<br>
><br>
> There are a couple other "we make your business visible on the map"<br>
> SEO-type businesses active in OSM, some better, some worse.<br>
><br>
> Typical problems include:<br>
><br>
> * Geocoding. We will want to know how the lat,lon pairs they use for<br>
> import have been generated. Sometimes the "official" source will<br>
> actually be based on measured GPS coordinates (good). Sometimes the<br>
> "official" source has simly geocoded their address with Google or HERE<br>
> (not admissible, license violation). Sometimes they have geocoded their<br>
> address with OpenStreetMap which is also bad because it can reinforce<br>
> errors or imprecisions - for example, if OSM has an address<br>
> interpolation range along a street, and a POI is placed with a specific<br>
> address at the computed interpolation point, then it looks like a<br>
> precise address but isn't.<br>
><br>
> * Ignoring the area around the imported information. We want imports to<br>
> match the existing data; automatic conflation is often not enough. A POI<br>
> can end up in a house, a lake, or in the middle of a road, and if that<br>
> is not just a one-off but a systematic problem (of the "let's dump our<br>
> stuff into OSM and the community can then fix it" kind) then it is<br>
> reason enough to revert the whole import and ask the importer to go back<br>
> to the drawing board.<br>
><br>
> * Mismatch between "official" data and reality. Especially for larger<br>
> chains it can easily happen that the company database doesn't reflect<br>
> reality on the ground, either through an error or because the reality on<br>
> the ground is somehow undesirable. For example, a hotel might be in the<br>
> chain's offical database with 49 rooms because local regulations tighten<br>
> for hotels of 50 rooms and up, but everyone knows in practice that the<br>
> hotel has 60 rooms and this is mapped in OSM. We wouldn't want<br>
> "official" data to overwrite what we have in OSM.<br>
><br>
> * Advertising. Some SEO companies go as far as putting advertising<br>
> messages in note tags, or invent new tags to describe the business in<br>
> the most colourful terms. While such advertising may occasionally be<br>
> factually correct ("family-owned since 1948"), we're usually not<br>
> interested in that.<br>
><br>
> These are *general* comments.<br>
><br>
> Looking at your proposed import specifically,<br>
><br>
> 1. I'd be interested in the geocoding source as per the first bullet<br>
> point above. Of course this is only relevant to newly added POIs.<br>
><br>
> 2. It seems to me that you're setting brand, operator, and occasionally<br>
> even name to "Shell". In Germany, the operator of a fuel station is<br>
> usually a small local business that has a franchise relationship with<br>
> the fuel company. Are you absolutely sure that Shell is actually the<br>
> operator of all these fuel stations? (It should be easily visible on a<br>
> receipt you get there.)<br>
><br>
> 3. Also, in those cases where no name was set before and you put<br>
> "name=Shell", are you absolutely sure that it's not "name=Joe's Garage"<br>
> or something? Would such a situation be correctly recorded in your data?<br>
> I notice that e.g. the station in Dursley with the ID NVDS298-10019092<br>
> is a proposed import with "name=Shell", whereas Shell's own station<br>
> locator lists this as "Millwood Motor Company Limited".<br>
><br>
> 4. I would also recommend not plastering the <a href="http://www.shell.co.uk" rel="noreferrer" target="_blank">www.shell.co.uk</a> URL all<br>
> over the place - if the *individual* fuel station doesn't have a web<br>
> site then it's not worth pointing to the Shell corporate site IMHO.<br>
><br>
> 5. New stations look generally well placed compared to aerial imagery (I<br>
> only looked at a random sample) but the second bullet point above is an<br>
> issue; for example you have placed a new fuel station at the correct<br>
> location but in the middle of a school campus<br>
> <a href="http://www.openstreetmap.org/query?lat=53.56053&lon=-2.12306#map=19/53.56035/-2.12300" rel="noreferrer" target="_blank">http://www.openstreetmap.org/<wbr>query?lat=53.56053&lon=-2.<wbr>12306#map=19/53.56035/-2.12300</a><br>
> - a high quality import would have a human verify the sitation, detect<br>
> the issue, and reduce the school grounds accordingly (or maybe call the<br>
> chain and ask if this is some special kind of training fuel station...)<br>
><br>
> Bye<br>
> Frederik<br>
><br>
> --<br>
> Frederik Ramm  ##  eMail <a href="mailto:frederik@remote.org">frederik@remote.org</a>  ##  N49°00'09" E008°23'33"<br>
><br>
> ______________________________<wbr>_________________<br>
> Imports mailing list<br>
> <a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/imports" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/imports</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
Imports mailing list<br>
<a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/imports" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/imports</a><br>
</div></div></blockquote></div><br></div>