Re: [Talk-GB] [Imports] Importing fuel stations in UK and future similar imports

[Andrew Black]

> the "fair use" clause.
Which specific legislation are you referring to.

On 12 May 2017 17:10, "Ilya Zverev"  wrote:

> Hi everyone,
>
> 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 maps.me — 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.
>
> 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.
>
> You can see the updated result here: http://bl.ocks.org/Zverik/raw/
> ddcfaf2da25a3dfda00a3d93a62f218d/ (with OpenStreetMap and Satellite
> layers).
>
> Also I have started the wiki page: https://wiki.openstreetmap.
> org/wiki/Navads_Imports
>
> * 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.
>
> * Other fuel stations inside 50 meters: I have found only one instance
> where the brand was changed. It is here: https://goo.gl/maps/9GLTVg1EWR82
> . 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.
>
> 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.
>
> * 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.
>
> * 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.
>
> * 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.
>
> * "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.
>
> Ilya
>
> > 12 мая 2017 г., в 1:22, Frederik Ramm  написал(а):
> >
> > Hi,
> >
> > On 05/11/2017 05:39 PM, Ilya Zverev wrote:
> >> Together with the NavAds company, we plan to import a thousand Shell
> >> fuel stations to the United Kingdom. The source is official, which
> >> means, Shell company specifically shared the dataset to put them on
> >> maps. Do you have any objections or questions?
> >
> > There are a couple other "we make your business visible on the map"
> > SEO-type businesses active in OSM, some better, some worse.
> >
> > Typical problems include:
> >
> > * Geocoding. We will want to know how the lat,lon pairs they use for
> > import have been generated. Sometimes the "official" source will
> > actually be based on measured GPS coordinates (good). Sometimes the
> > "official" source has simly geocoded their address with Google or HERE
> > (not admissible, license violation). Sometimes they have geocoded their
> > address with OpenStreetMap which is also bad because it can reinforce
> > errors or imprecisions - for example, if OSM has an address
> > interpolation range along a street, and a POI is placed with a specific
> > address at the computed interpolation point, then it looks like a
> > precise address but isn't.
> >
> > * Ignoring the area around the imported information. We want imports to
> > match the existing data; automatic conflation is often not enough. A POI
> > can end up in a house, a lake, or in the middle of a road, and if that
> > is not just a one-off but a systematic problem (of 

Re: [Talk-GB] [Imports] Importing fuel stations in UK and future similar imports

[Philip Barnes]

A few issues I have spotted with the proposed data,

Website: This should only be included if it refers to the actual object
and should not be set to the shell.co.uk site.

I have spotted some really silly street names, such as
addr:street=A46/A6 A46/A6 Trunk Road.

A filling station is often part of something larger such as
highway=services, in that case many of the tags i.e. postcode/phone
number belong on the higher level object, not the filling station. 

Service Areas often have more than one filling station, one for cars
and bikes and another for HGVs.

Phil (trigpoint)

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] [Imports] Importing fuel stations in UK and future similar imports

[Andy Mabbett]

On 12 May 2017 at 17:08, Ilya Zverev  wrote:

> I am not sure if I should add the brand:wikidata=Q154950 tag, and for now 
> decided against that.

I would encourage you to include this.

> * "The general view seems to be against IDs like this": what has happened 
> with the principle "any tags you like"?

I see no reason you should not include this data as originally
proposed. Anyone suspicious of it, or who does not recognise it, can
ignore it.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] [Imports] Importing fuel stations in UK and future similar imports

[Ilya Zverev]

Hi everyone,

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 maps.me — 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.

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.

You can see the updated result here: 
http://bl.ocks.org/Zverik/raw/ddcfaf2da25a3dfda00a3d93a62f218d/ (with 
OpenStreetMap and Satellite layers).

Also I have started the wiki page: 
https://wiki.openstreetmap.org/wiki/Navads_Imports

* 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.

* Other fuel stations inside 50 meters: I have found only one instance where 
the brand was changed. It is here: https://goo.gl/maps/9GLTVg1EWR82 . 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.

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.

* 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.

* 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.

* 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.

* "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.

Ilya

> 12 мая 2017 г., в 1:22, Frederik Ramm  написал(а):
> 
> Hi,
> 
> On 05/11/2017 05:39 PM, Ilya Zverev wrote:
>> Together with the NavAds company, we plan to import a thousand Shell
>> fuel stations to the United Kingdom. The source is official, which
>> means, Shell company specifically shared the dataset to put them on
>> maps. Do you have any objections or questions?
> 
> There are a couple other "we make your business visible on the map"
> SEO-type businesses active in OSM, some better, some worse.
> 
> Typical problems include:
> 
> * Geocoding. We will want to know how the lat,lon pairs they use for
> import have been generated. Sometimes the "official" source will
> actually be based on measured GPS coordinates (good). Sometimes the
> "official" source has simly geocoded their address with Google or HERE
> (not admissible, license violation). Sometimes they have geocoded their
> address with OpenStreetMap which is also bad because it can reinforce
> errors or imprecisions - for example, if OSM has an address
> interpolation range along a street, and a POI is placed with a specific
> address at the computed interpolation point, then it looks like a
> precise address but isn't.
> 
> * Ignoring the area around the imported information. We want imports to
> match the existing data; automatic conflation is often not enough. A POI
> can end up in a house, a lake, or in the middle of a road, and if that
> is not just a one-off but a systematic problem (of the "let's dump our
> stuff into OSM and the community can then fix it" kind) then it is
> reason enough to revert the whole import and ask the importer to go back
> to the drawing board.
> 
> * Mismatch between "official" data and reality. Especially for larger
> chains 

Re: [Talk-GB] Public Rights of Way data for Cambridgeshire

[Adam Snape]

I would be interested to add rights of way information closer to home
(Lancashire).

Dave refers to the long list of other councils that have released row
information. Is this the rowmaps website or is it somewhere on osm that I'm
missing?

The information on rowmaps is not clear. Is all of the data on there
compatible with osm?

Adam

On 11 May 2017 8:25 p.m., "John Aldridge"  wrote:

> One bit of feedback, from a first try at doing this for real: footpaths
> often cross parish boundaries, and at least in this area change their
> reference when they do so. But your slippy map only displays geometry for a
> single parish at a time, meaning that tracking the prow_ref value for the
> full length of a single path can take a lot of navigation within your tool.
>
> Would it be hard to display geometry for all ROWs overlapping the current
> slippy map extent, whichever parish they are from?
>
> --
> Cheers,
> John
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-gb-westmidlands] West Midlands Data Discovery Centre

[Brian Prangle]

Hi everyone

Take a look at this amazing facility which is a development of our work
locally with ODI,Birmingham Innovation Centre and Deft351. It's still only
a demonstrator, developed by Opendatasoft, but I'm pretty impressed with
its visualisation capabilities

https://datadiscoverycenter.opendatasoft.com/pages/homepage/


Regards

Brian
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

Re: [Talk-GB] Proposed Import of UK Shell Filling Stations

[Dave F]

Apologies to Brian, who's clearly just passing on the message.


On 12/05/2017 00:58, Dave F wrote:

1. Wouldn't it be better to sort out your trees first?

2. What does ref_unused_tags.name refer to?

3. Are there any out of date stations that need removing/changing to 
another operator?


DaveF

On 11/05/2017 21:36, Brian Prangle wrote:

Hi everyone

There is a proposal for this import currently under discussion on the 
talk import mailing list and the OSMUK chapter has asked the proposer 
that it be discussed on the talk GB mailing list


Regards

Brian


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb




___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Proposed Import of UK Shell Filling Stations

[Frederik Ramm]

Dave,

On 12.05.2017 01:58, Dave F wrote:
> 1. Wouldn't it be better to sort out your trees first?

It's not OSM-UK that proposes this import; Brian has only pointed out
that there's a discussion going on. The import has been proposed by
commercial entities NavAds (who publicize store locations for retail
chains as a service) and Mail.ru (the company behind maps.me).

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Proposed Import of UK Shell Filling Stations

[Jez Nicholson]

for background info: a couple of links about Navads and what they do for
Shell (and other brands)
http://www.prweb.com/releases/navads/shell/prweb13779126.htm and
https://navads.eu/businesslistings/

It would be interesting for OSM[UK] to be an official recipient of
up-to-date, clean data if indeed it is proved to be clean enough for import.

On Fri, 12 May 2017 at 08:59 Robert Whittaker (OSM lists) <
robert.whittaker+...@gmail.com> wrote:

> On 11 May 2017 at 23:25, Frederik Ramm  wrote:
> > Link to discussion so far on imports@:
> > https://lists.openstreetmap.org/pipermail/imports/2017-May/004956.html
> >
> >> My concern would be from where to they get their geocoding.  Most
> >> businesses, and particularly chain businesses, tend to use postcode
> >> centroids, which are not accurate enough, probably get them from Google.
> >
> > I voiced the same general concern, but a random sample I checked of the
> > (actually rather few) stations that are proposed to be newly added
> > seemed to be impeccably placed.
>
> In which case, there is a different concern: have they done their
> geo-coding from an acceptable source for use in OSM? If they've e.g.
> used Address Base (or a similar product) or got coordinates from a
> non-OpenData OS map, then there could be problems. I think we need
> more information on the data sources here.
>
> Some other comments:
>
> * If a ref/id is to be used, it should probably be Shell's branch
> reference number, not that of the third-party data provider. (These do
> exist, and at least in some cases are verifiable on the ground, as
> I've found at least one on a pump at a Shell garage up the road from
> me.)
>
> * There's an addressing edge-case error on a station near me, which is
> located on the Five Ways Roundabout near Mildenhall:
> http://www.openstreetmap.org/way/478902268 . We currently have
> (incorrectly) "addr:place=5 Ways Roundabout", but the script is
> proposing adding "addr:street=Ways Roundabout" and
> "addr:housenumber=5".
>
> * The script shouldn't just add source=Navads to objects it's only
> modifying, as that would imply the whole object was sourced from
> there. If existing tags and position are retained, then this needs to
> be acknowledged somehow. If there's an existing source tag, then
> Navads could just be added to the list (I haven't checked to see if
> this is the case). If not, then there's more of a challenge. The
> script current just adds source=Navads in this case. I think the
> importers need to propose a better solution for this.
>
> * As others have said, there needs to be more information about what
> happens if there are multiple amenity=fuel objects within 50m, and
> also what happens if any existing tags conflict with what the script
> would like to add.
>
> * The proposed website tag appears to point to http://www.shell.co.uk
> for all the branches. Would it be better pointing to a specific URL
> for that branch (assuming this exists)?
>
> * The opening_hours from the import script for
> http://www.openstreetmap.org/way/248030653 don't match those displayed
> on Shell's own website for the same station. One as open till 11pm on
> Saturday, the other only 10pm. So is the data accurate / up-to-date?
>
> Robert.
>
> --
> Robert Whittaker
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Proposed Import of UK Shell Filling Stations

[Robert Whittaker (OSM lists)]

On 11 May 2017 at 23:25, Frederik Ramm  wrote:
> Link to discussion so far on imports@:
> https://lists.openstreetmap.org/pipermail/imports/2017-May/004956.html
>
>> My concern would be from where to they get their geocoding.  Most
>> businesses, and particularly chain businesses, tend to use postcode
>> centroids, which are not accurate enough, probably get them from Google.
>
> I voiced the same general concern, but a random sample I checked of the
> (actually rather few) stations that are proposed to be newly added
> seemed to be impeccably placed.

In which case, there is a different concern: have they done their
geo-coding from an acceptable source for use in OSM? If they've e.g.
used Address Base (or a similar product) or got coordinates from a
non-OpenData OS map, then there could be problems. I think we need
more information on the data sources here.

Some other comments:

* If a ref/id is to be used, it should probably be Shell's branch
reference number, not that of the third-party data provider. (These do
exist, and at least in some cases are verifiable on the ground, as
I've found at least one on a pump at a Shell garage up the road from
me.)

* There's an addressing edge-case error on a station near me, which is
located on the Five Ways Roundabout near Mildenhall:
http://www.openstreetmap.org/way/478902268 . We currently have
(incorrectly) "addr:place=5 Ways Roundabout", but the script is
proposing adding "addr:street=Ways Roundabout" and
"addr:housenumber=5".

* The script shouldn't just add source=Navads to objects it's only
modifying, as that would imply the whole object was sourced from
there. If existing tags and position are retained, then this needs to
be acknowledged somehow. If there's an existing source tag, then
Navads could just be added to the list (I haven't checked to see if
this is the case). If not, then there's more of a challenge. The
script current just adds source=Navads in this case. I think the
importers need to propose a better solution for this.

* As others have said, there needs to be more information about what
happens if there are multiple amenity=fuel objects within 50m, and
also what happens if any existing tags conflict with what the script
would like to add.

* The proposed website tag appears to point to http://www.shell.co.uk
for all the branches. Would it be better pointing to a specific URL
for that branch (assuming this exists)?

* The opening_hours from the import script for
http://www.openstreetmap.org/way/248030653 don't match those displayed
on Shell's own website for the same station. One as open till 11pm on
Saturday, the other only 10pm. So is the data accurate / up-to-date?

Robert.

-- 
Robert Whittaker

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] weeklyOSM #355 02/05/2017-08/05/2017

[weeklyteam]

The weekly round-up of OSM news, issue # 355,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9055/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb