[Imports] Worldwide fuel stations import, 59k objects

Levente Juhász jlevente89 at gmail.com
Thu Mar 8 15:38:31 UTC 2018


Thanks for the clarifications, Ilya. I started typing my response as I read
your original mail and gave my first impressions. Some questions got
answered after checking the data and reading through your entire mail but
remained in my response. Anyway, 2nd round below:

As for 0), I was thinking two things. You're right about adding new,
existing stations not being overrides, there's no question about that.
However, there's still the questions of the overall currentness of the
NavAds data. For example, to get an idea about how long it takes on average
to remove a permanently closed gas station from the dataset. If it takes
too long, then there might be a monthly add-remove-add battle between you
and a local mapper, which is not ideal. I later checked my area and
stations looked good (i.e. no closed gas stations in the NavAds data).
Hopefully as more people review the data we'll see that this is not an
issue. Another thing I had in mind was about tags. For example, I wasn't
sure what tags you're planning to update and how. Like updating operator to
"Shell Oil Company" from "Shell" didn't seem like a good idea if a local
community already agreed on using "Shell". Same for other tags. Now knowing
that this is in fact not part of your import, I don't have any problems
with it. It was more like a hypothetical question since the whole process
wasn't entirely clear (which again comes down to having a documentation).

1) Fair enough. I wasn't aware of the different notations for different
countries. It just looked strange at first but now it makes sense.

2) Great.

3) OK, hopefully it's not a common case.

As for easing the tension about cross-country imports, you could for
example divide the import changeset into multiple changesets for each
country. With that, even if some concerns or a strong opposition arise from
a local community, it would only affect one changeset out of the ~20 total.
Since you have addresses this could be done without spatial operations.
It's just something to think about.

Cheers,
Levente


On Thu, Mar 8, 2018 at 9:17 AM Ilya Zverev <ilya at zverev.info> wrote:

> Hi Levente,
>
> Thanks for reviewing the import. You have many valid points, which
> mostly come from the lack of documentation on my side.
>
> 0) Why do you think this import overrides any work? Adding new fuel
> stations certainly does not, so does adding phones and websites hurt the
> mappers? I'd be glad and more understanding of local mappers if you
> elaborated on this.
>
> 1) The wiki page you link to explicitly tells to use the E.164 standard,
> which mandates different notation for different countries. The wiki
> specifically mentions the format for US phone numbers. For formatting
> the numbers, I am using the Google's libphonenumber library. It is the
> same that is used by Android phones to format numbers, and I haven't
> seen any critique on these phones' formatting errors.
>
> 2) I guess these links were pointing to specific stations, but the Shell
> website was changed a while ago, making these links invalid. I'll
> contact NavAds about that.
>
> 3) With that gas station you have found that the source dataset has
> duplicates. OSM Conflator has not means of detecting that. But I will
> definitely look for any other duplicates, remove them and report back to
> NavAds.
>
> Thanks,
> Ilya
>
> 07.03.2018 22:32, Levente Juhász пишет:
> > Hi All,
> >
> > Generally, I think imports can be super useful if carefully executed.
> > This includes precise documentation. More importantly, as
> > Christoph pointed out, local communities should be involved as we just
> > simply don't know whether they've already put efforts into mapping gas
> > stations, or if they've already agreed on some country specific best
> > practices. I don't think overriding their previous work with a global
> > import is a good idea.
> >
> > Also, I checked a few data points manually and have the following
> comments:
> >
> > 1) Phone number patterns should follow the same rules within the
> > dataset. E.g. "+36 62 464 024 <+36%2062%20464%20024>"
> > (http://audit.osmz.ru/browse/navads_fuel/NVDS353_10201112) in Hungary vs
> > "+1 561-544-6012 <(561)%20544-6012>"
> > (http://audit.osmz.ru/browse/navads_fuel/NVDS353_10008561) in the US
> > (dashes/no dashes in the local part of the number). See the wiki
> > (https://wiki.openstreetmap.org/wiki/Key:phone#Usage) for example
> patterns.
> >
> > 2) Some urls don't point to the specific station. E.g. for this station:
> > http://audit.osmz.ru/browse/navads_fuel/NVDS353_10201112
> >   website=
> http://www.shell.hu/products-services/on-the-road/shell-station-locator.html?id=10201112&modeselected=true will
> be redirected to:
> https://www.shell.hu/autosok/shell-station-locator.html#vanity-aHR0cHM6Ly93d3cuc2hlbGwuaHUvcHJvZHVjdHMtc2VydmljZXMvb24tdGhlLXJvYWQvc2hlbGwtc3RhdGlvbi1sb2NhdG9yLmh0bWw
> which is not a unique page of that station. Same thing with Shell in Poland
> (e.g. http://audit.osmz.ru/browse/navads_fuel/NVDS353_10034854). In these
> cases, a general website pointing to www.shell.hu <http://www.shell.hu>
> or www.shell.pl <http://www.shell.pl> would be a better choice if you
> want to add a website. Additional url parameters here just don't serve any
> purpose without the correct pattern, therefore I don't think they should be
> used added.
> >
> > I'm not familiar with the OSM Conflator tool but it would be great to
> > know what parameters it uses for finding already existing OSM features.
> > I randomly found the following example:
> > http://audit.osmz.ru/browse/navads_fuel/NVDS106_1073560996PL0 which
> > shows a newly created feature (green) and a feature to be modified
> > (blue). In this case, those feature refer to the same gas station so it
> > should be a simple update. I'm wondering about the conflation parameters
> > and if you've tested different values and evaluated the differences. I'm
> > also wondering if you have a general idea about the number of similar
> > cases. This is the information that would be helpful in the import
> > documentation. This scenario is also related to 1) above since the phone
> > number is about to be updated with the same value, in a different
> > format. Quite possibly the updated pattern is the correct one, but I'd
> > ask the Polish community whether the old value was intentional or not.
> >
> > All in all, this could be a great addition, but I think the import
> > workflow needs some more work.
> >
> > Cheers,
> > Levente
> >
> > On Wed, Mar 7, 2018 at 1:09 PM Christoph Hormann <osm at imagico.de
> > <mailto:osm at imagico.de>> wrote:
> >
> >     On Wednesday 07 March 2018, Ilya Zverev wrote:
> >      > Hi everyone,
> >      >
> >      > Following the recent UK Shell stations import, I've got ahold of
> the
> >      > entire NavAds dataset. A major part of it are fuel stations all
> >      > across the world: UK, US, France, Germany, Australia, and many
> other
> >      > countries. [...]
> >
> >     I don't want to comment on the import itself - have done so in the
> past,
> >     nothing really to add - except maybe that i looked for documentation
> of
> >     the mentioned UK Shell stations import on the wiki or an entry in the
> >     import catalogue - both of which are required by the import
> guidelines
> >     and neither of which seems to exist (and neither for this import
> >     apparently).
> >
> >     The import guidelines also clearly state that
> >
> >     "You must not import the data without local buy-in"
> >
> >     which leads me to conclude that for a multi-country import you have
> to
> >     consult with each of the local communities affected individually.
> >
> >     The local communities need to have the right to object to the import
> or
> >     to have specific local conventions regarding tagging that the import
> >     needs to follow in their domain.  Local mappers must not be required
> to
> >     write here in English to ask questions and raise concens about local
> >     aspects to be heard.
> >
> >     --
> >     Christoph Hormann
> >     http://www.imagico.de/
> >
> >     _______________________________________________
> >     Imports mailing list
> >     Imports at openstreetmap.org <mailto:Imports at openstreetmap.org>
> >     https://lists.openstreetmap.org/listinfo/imports
> >
> >
> >
> > _______________________________________________
> > Imports mailing list
> > Imports at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/imports
> >
>
>
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20180308/6f9e1ce3/attachment.html>


More information about the Imports mailing list