<div dir="ltr"><div><div><div>created_by is deprecated, but JOSM will take care of that.<br>source belongs on the changeset<br><br>Is it possible to include brand:wikidata=Q154950 ? US, Canada and Nigeria seem to have different wikidata ids.<br><br></div>I'm not sure about operator, shouldn't that be the person/company operating that particular branch?<br><br></div>Maybe it's a good idea to be careful with name. Aren't there cases where this includes the name of the operator/subsidiary/franchise + the brand?<br><br></div>Polyglot<br></div><div class="gmail_extra"><br><div class="gmail_quote">2017-05-11 18:15 GMT+02:00 Christoph Hormann <span dir="ltr"><<a href="mailto:osm@imagico.de" target="_blank">osm@imagico.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thursday 11 May 2017, Ilya Zverev wrote:<br>
><br>
> The import is done with the OSM Conflator script. It matches dataset<br>
> points to all amenity=fuel nodes and polygons inside a 50 meter<br>
> radius.<br>
<br>
</span>So if current mapping in OSM is off more than 50m you get duplicates?<br>
<br>
What do you do if the location you want to add a node at is in the<br>
middle of a road or a lake as mapped in OSM?<br>
<span class=""><br>
> If found, the object is not moved, but tags are updated from<br>
> the dataset. The object gets correct opening hours, uniform brand and<br>
> operator tags, and so on.<br>
<br>
</span>So if Shell 'knows' a station opens at 8 am although mappers have<br>
verified locally that it actually is not open before 8:15 you replace<br>
that information with the 'correct' one?<br>
<span class=""><br>
> Every object is given a "ref:navads_shell" tag with an identifier,<br>
> which will later be used for updating the data.<br>
<br>
</span>I think we long ago established that proprietary IDs not verifiable by<br>
mappers have no place in OSM.<br>
<span class=""><br>
> After this import there will be others of similar nature and quality.<br>
<br>
</span>To be clear - import review is always for the specific import as<br>
planned, there is no carte blanche for future supposedly similar<br>
imports.<br>
<br>
In any case you need to follow the import guidelines which means you<br>
have to write a page on the OSM wiki documenting your import plans (in<br>
particular what tags to use) and you have to make clear the data you<br>
want to import is either published under a compatible license or<br>
document the owner of the data has given explicit permission for use in<br>
OSM.<br>
<span class=""><br>
> Uploading will be done with a dedicated account (not created yet).<br>
> The NavAds company specializes in putting businesses on maps, and we<br>
> are helping them to include OpenStreetMap in their choice of target<br>
> maps. I hope you are okay with this.<br>
<br>
</span>Who is 'we' here?<br>
<br>
Overall and to be perfectly honest i hope you set aside a decent<br>
fraction of what they are paying you to donate to the OSM project as<br>
compensation for the review of a half baked import plan you present<br>
here. ;-)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Christoph Hormann<br>
<a href="http://www.imagico.de/" rel="noreferrer" target="_blank">http://www.imagico.de/</a><br>
</font></span><div class="HOEnZb"><div class="h5"><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>