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

[Philip Barnes]

On Sun, 2017-05-07 at 10:40 +0200, Pavel Machek wrote:
> 
> 
> We want to update data from the import in the future, so this kind of
> id is ok.

That type of data cannot be relied upon for maintenance. As others have
said these 'meaningless' tags will be removed by mappers. Objects will
be copied to create nearby competitor modified but this "meaningless"
tag left behind.

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

[David Woolley]

On 13/05/17 10:48, David Woolley wrote:

Also, maps are covered by database rights as well as copyright, for 15
years, and that is the real issue for geocoding, as it doesn't require
any degree of creativity.


I should have added that the fair dealing exemption for database rights 
explicitly forbids commercial use, see clause 20(1)(b) 
, whereas OSM 
licensing requires that the data be usable for commercial purposes.


___
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

[David Woolley]

On 13/05/17 08:08, Richard Fairhurst wrote:

There is no "fair use" clause in UK copyright law, which is important not
just because OSM is hosted in England & Wales but also because this is
presumably a dataset in part containing materials with an E copyright
holder.


Also, maps are covered by database rights as well as copyright, for 15 
years, and that is the real issue for geocoding, as it doesn't require 
any degree of creativity.


UK copyright law does cover databases, but only to the extent that there 
has been an element of creativity.  For most maps that element almost 
certainly exists, in terms of how shapes have been simplified, and 
features selected as important enough to include.


However there is a second level of protection, which covers things like 
telephone directories, once you eliminate the copyright that does exist 
in the typographical arrangement.  See 
.  In 
particular see clause 16(2) 
, where 
it explicitly says that piecemeal extraction of the data is as much an 
offence as extracting a substantial part all at once.  This is why OSM 
cannot adopt the Wikipedia philosophy of allowing databases to be copied 
one entry per article.


(On fair use and fair dealing, these terms are not well defined in 
English or US law, but one element of them is generally that it should 
not be to the commercial disadvantage of the rights owner, and another, 
at least for the UK, is that there must be a public interest in doing so.)


IANAL TINLA


___
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]

Thanks, Richard. The dataset in question definitely was not geocoded, 
but I will inform Navads about possible issues with geocoded datasets.


Ilya

13.05.2017 10:08, Richard Fairhurst пишет:

Ilya Zverev wrote:

I think that would fall into the "fair use" clause.


There is no "fair use" clause in UK copyright law, which is important not
just because OSM is hosted in England & Wales but also because this is
presumably a dataset in part containing materials with an E copyright
holder.

The comparable clause is "fair dealing" and has significantly less scope
than the US "fair use". There may be other aspects of copyright law you
could look at but I wouldn't rely on this one.

Richard



--
View this message in context: 
http://gis.19327.n8.nabble.com/Re-Imports-Importing-fuel-stations-in-UK-and-future-similar-imports-tp5896663p5896679.html
Sent from the Great Britain mailing list archive at Nabble.com.

___
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] [Imports] Importing fuel stations in UK and future similar imports

[Richard Fairhurst]

Ilya Zverev wrote:
> I think that would fall into the "fair use" clause.

There is no "fair use" clause in UK copyright law, which is important not
just because OSM is hosted in England & Wales but also because this is
presumably a dataset in part containing materials with an E copyright
holder.

The comparable clause is "fair dealing" and has significantly less scope
than the US "fair use". There may be other aspects of copyright law you
could look at but I wouldn't rely on this one.

Richard



--
View this message in context: 
http://gis.19327.n8.nabble.com/Re-Imports-Importing-fuel-stations-in-UK-and-future-similar-imports-tp5896663p5896679.html
Sent from the Great Britain mailing list archive at Nabble.com.

___
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

[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