Re: [OSM-talk] Proposed bot edit: automatic replacement of surface values where it is safe

[Cj Malone]

I'm sure there will be edge cases where this bot gives us wrong data,
but I think overall this will make OSM data better.


Thank you for taking the time to improve OSM.

CJ


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proposed bot edit: automatic replacement of surface values where it is safe

[Cj Malone]

I'm sure there will be edge cases where this bot gives us wrong data,
but I think overall this will make OSM data better.


Thank you for taking the time to improve OSM.

CJ



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] When two bots go to war

[Cj Malone]

On Tue, 2023-09-12 at 15:06 +0200, Snusmumriken via talk wrote:
> My speculation is that Distriktstandvården (a chain of dental
> clinics)
> has taken "ownership" of "their" nodes and once a day check that the
> values in osm database correspond to that of their internal database.

I've added a more specific website tag to test this. If they restore it
(Probably 03:00) to the generic home page I agree with you. They need
to be informed that 1) there data needs improving (eg covid opening
hours, POI specific not brand specific contact details) 2) they don't
own these nodes, other people can edit them.

CJ

https://www.openstreetmap.org/changeset/141243391


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] ODbl concerns

[Cj Malone]

On Mon, 2023-07-03 at 18:03 +0200, Marc_marc wrote:
> Le 03.07.23 à 16:10, Cj Malone a écrit :
> > On Mon, 2023-07-03 at 00:05 +, Robert C Potter (DTP) via talk
> > wrote:
> > > Google, Tomtom and Apple.
> > 
> > Maybe it's not their preferred license, but they already use odbl
> > data.
> 
> for Tomtom and Appel, of course they use it, including osm.
> 
> but any reference about "google using ODBl" ?

https://lists.openstreetmap.org/pipermail/talk/2021-October/087049.html


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] ODbl concerns

[Cj Malone]

On Mon, 2023-07-03 at 00:05 +, Robert C Potter (DTP) via talk
wrote:
> Google, Tomtom and Apple.

Maybe it's not their preferred license, but they already use odbl data.

CJ



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] bot proposal: shop values cleanup (low use values only, 1 used 250 times, three over 100 times, many used less)

[Cj Malone]

Sounds good to me. Thank you.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Automated Edit - Bus stops status link & Bus lines timetable link (Tenerife)

[Cj Malone]

On Fri, 2023-03-24 at 20:33 +0100, Sören Reinecke wrote:
> If these urls are following a fixed scheme like you mentioned then I
> see no need to add the urls. There is no need to store them if you
> can create them from a combination of the hard coded [url] and a
> variable part retrieved by reading the value of the "ref" osm
> key

I used to agree with this, but we can't expect OSM consumers to do this
all over the globe, especially when it's not documented anywhere. I
support adding the URLs.

CJ


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] UPRN wiki page

[Cj Malone]

On Tue, 2020-11-17 at 14:10 +, Jez Nicholson wrote:
> Whilst i'm here, am I correct that a UPRN can *only* be on a single
> thing?
> So anything in
> https://taginfo.openstreetmap.org/keys/?key=ref%3AGB%3Auprn#values mo
> re
> than once is an error?
> 
> ...or can a road have a USRN *and* a UPRN?

As far as I know a road should have only 1 USRN, but it can have
multiple UPRNs. I think it's mainly if it goes over a admin boundary,
each area will have a UPRN but the road will have one USRN.

Also OSM often has multiple ways per road, each of these ways should
share a USRN and more often than not share the UPRN.



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

Re: [Talk-GB] Q4 2020 Quarterly Project: Defibrillators

[Cj Malone]

> Firstly, I have seen a few buildings that have an AED pictogram sign
> outside, suggesting that there is a defibrillator inside. Is this
> considered sufficient 'on the ground' evidence to add to the map.
> These are often locations that are noted up on the Survey Me! tool,
> but not always.

I would argue so, we add phone numbers to hotels from outside signs.

There is a question of if private defibs should be added to OSM, and
again I would argue for there addition. We aren't using these defibs
for routing in emergencies. We have no access liability with Ambulance
Services. These are added to OSM for education purposes, so that local
people can be better informed about there situation and so people can
process the data to workout areas that are under served, improve
coverage and save lives.

> Secondly, I notice that Rob's otherwise excellent Survey Me! tool
> occasionally incorrectly matches a point quite far away, and so flags
> up a missing defibrillator, even though it is correctly mapped in the
> location expected by the tool. Is there an easy way to resolve these,
> or is this just too complex a problem?

I don't think Rob has manual matching on his defib site, but I may be
wrong.

The underlying issue is the quality of the source data, they don't
typically have coordinates, just a postcode so the location isn't that
accurate. They also don't have refs so we can't match defibs.

Hopefully there will eventually be a central list of defibs that OSM
can work with and improve, BHF has hopes of doing this but it seems to
be a bit stagnant. I also hope this will be released Open Data, OSMUK
would be happy to help with that.

> Either way, it just highlights another reason why this too cannot be
used to add data to OSM.

The copyright situation is the external reason, it'll put OSMF in a bad
position. Copying this data is just as bad as using Google Maps as a
source.

> However, next time I am passing by the station, I think there is one
> missing that I can add. This might fix this incorrect matching…

I have noticed that the more defibs in OSM, the better the matching
gets. But that's not always the case.




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

Re: [Talk-GB] Mapping a building that's two connected separate buildings

[Cj Malone]

You could also consider at Simple 3D buildings [1], in which case I
think you'd have 1 building around the entire footprint and 3
building:parts.

Cj

[1] https://wiki.openstreetmap.org/wiki/Simple_3D_buildings



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

Re: [Talk-GB] Q4 2020 Quarterly Project: Defibrillators

[Cj Malone]

On Mon, 2020-10-12 at 08:54 +0100, Robert Whittaker (OSM lists) wrote:
> I've got the AED data from all the Ambulance Services in the UK apart
> from Northern Ireland and London in my OSM comparison tool at
> https://osm.mathmos.net/defib/progress/ . Much of the data is more
> than a year old, but given our current levels of mapping, that
> probably doesn't matter too much for now. Of the 25k AEDs in those
> Ambulance Services' data, we've currently only got about 12.4% of
> them mapped. So there's lots to do.

NI has an online map hosted by esri. [1] It's data can be extracted at
[2], but it would be nice to get the data properly.

> The Ambulance Services are currently moving to a central UK-wide
> database of AEDs called "The Circuit" (see [1] and [2]), which is
> being run by the British Heart Foundation. It's not clear whether
> they're intending to publish the national set of locations,

I've heard that they do intent to publish it, but I've not managed to
confirm that. I tried to contact them in the beginning of September,
but I just got a response saying to contact them at the end of
November. I guess they aren't set up completely yet.

It would be nice to have a relationship with The Circuit where they are
responsible for the list of difibs, ensuring that they are kept up to
standard, and in contact with the operators and the Ambulance Services,
and we are responsible for the Lat Long of each defib. That could mean
getting the ODbL into some official-ish datasets.

Cj

[1] 
https://niamb.maps.arcgis.com/apps/webappviewer/index.html?id=1f3c3a534b854738b2d4f685715198ff
[2] 
https://services9.arcgis.com/pjJLy2FNWtiR7Kii/arcgis/rest/services/AED_Locations_NI/FeatureServer/0/query?f=json=1%3D1=true=esriSpatialRelIntersects=OBJECTID%2CIdentifier%2CIndustry%2CPCT%2CSCLGD%2CLocation_Name%2CLocation_Street%2CLocation_Town_or_City%2CLocation_County%2CPost_Code%2CX_Co_ordinate%2CY_Co_ordinate%2CAccess_Information=OBJECTID%20ASC=102100


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

Re: [Talk-GB] Q4 2020 Quarterly Project: Defibrillators

[Cj Malone]

On Mon, 2020-10-12 at 09:45 +0100, Jez Nicholson wrote:
> What tags should I be capturing? phone=999 + indoors=no? access=code?

I don't think phone=999 is necessary. Potentially adding the operators
phone number would be more useful as people could report issues or
vandalism.

I think defibrillator:location is an important tag, having the location
context can be more useful than coordinates in some cases. I typically
write something like "On the outside wall of X opposite/near Y".

Cj



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

Re: [Talk-GB] Proposal: Import EV charging point data

[Cj Malone]

On Tue, 2020-08-18 at 12:18 +0100, Steven Hirschorn wrote:
> Are we allowed to put the points on a non-OSM map to ask local
> mappers to survey?

Legally I think it's a bit ambiguous, but current practice is to do
exactly that. See tools like [1] where most of the data isn't
compatible with the ODbL but they are overlaid for local mappers to
survey and add them selves [2]. At a certain point it may be easier to
"import to notes", but the current way at least has plausible
deniability if any data provider was upset that there dataset was used
to inform surveys.


Cj

[1] https://osm.mathmos.net/defib/
[2] https://osm.mathmos.net/defib/progress/NE/


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

Re: [Talk-GB] Street-name toids

[Cj Malone]

On Sat, 2020-08-15 at 20:55 +0100, Steve Doerr wrote:
> On 13/08/2020 13:06, SK53 wrote:
> > This location 
> >  on
> > Robert's site shows several UPRNs on streets:
> > 
> >   * 10009154384 on Averton Square
> > 
> 
> That's a link to openstreetmap.org, not to something called 'Robert's
> site'.

https://osm.mathmos.net/addresses/uprn/#17/52.96216/-1.14852



> > 10009154384 on Averton Square

https://www.openstreetmap.org/way/29380518#map=19/52.94994/-1.18950
https://osm.mathmos.net/addresses/uprn/#20/52.9496/-1.1896

> > 10009156248 at start of Longore Square

https://www.openstreetmap.org/way/29380532#map=19/52.95061/-1.18961
https://osm.mathmos.net/addresses/uprn/#19/52.9506/-1.1899

> > 10009156248 at E end of Fairham Drive

https://www.openstreetmap.org/way/29380511#map=19/52.95022/-1.18877
https://osm.mathmos.net/addresses/uprn/#19/52.9506/-1.1899


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

Re: [Talk-GB] Electric vehicle charging points

[Cj Malone]

On Tue, 2020-07-21 at 17:30 +0100, Mark Goodge wrote:
> But it's not reliable enough for an unfiltered bulk import; there are
> duplicate entries, incorrect coordinates and incorrect or missing
> addresses.

We could turn this into an advantage of Open Data and OSM. Validation
of other datasets makes them more accurate and in turn useful to
everyone, including the original publisher.

> What it would be useful for, though, is adding the technical data to
> a chargepoint that has been mapped by on-the-ground observation. So
> long as we can match an entry in the NCR to a mapped chargepoint,
> the metadata (eg, connector types, owner/operator/network) can be
> updated automatically.

+1
But I think we should also add the other data (after other validation,
like de duplication and null island), possibly like the naptan import
with, naptan:verified, or a more generic import_verified. That could
easily be fitted into on the ground verification tools like
StreetComplete. Or perhaps a more visible option is to make notes for
the ones that aren't matched to existing data allowing local mappers to
check and add them manually.

On Tue, 2020-07-21 at 18:44 +0200, Kai Michael Poppe - OSM wrote:
> Again, this sounds like a perfect job for MapRoulette where the NCR
> goes into a GeoJSON and people get to work on that data with what's
> in OSM already - the part that requires effort is to correct what's
> bogus ;)

I think of MapRoulette as being more "arm chair mapping", I think you'd
get people just adding it without any validation.

Cj



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

Re: [Talk-GB] (no subject)

[Cj Malone]

Passenger does a lot of good stuff. There down stream customers use
OSM, and credit it [0]. They release more up to date NaPTAN formatted
data that NaPTAN its self [1]. Honestly it's a bit of a shame the OSM
bus stop data is so neglected.


Cj

[0] https://www.islandbuses.info/explore
[1] https://www.islandbuses.info/open-data



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

Re: [Talk-GB] POI files of Pub/Restaurant chain

[Cj Malone]

Hey,

You'd have to contact them to ask what license those files are
published under, or get explicit permission for it to be used in OSM.

If you do make contact it may be better to ask for permission to use
the store data from whole website which will include phone number,
opening times, toilets/accessible toilets etc.

If they don't respond or refuse a compatible license, you can still get
address data from FHRS Open Data [0], along with linking it so clients
could show it's hygiene score to end users. See my edit of it [1].

Cj

[0] https://ratings.food.gov.uk/
[1] https://www.openstreetmap.org/changeset/88052606



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

Re: [Talk-GB] Holiday camp tagging

[Cj Malone]

On Mon, 2020-07-13 at 20:47 +0100, David Woolley wrote:
> If separate areas have been mapped for tents and caravans, you should
> not coalesce them.

Is this not the same as amenity=university on each building though?
Where the correct method is one closed way or relation
with amenity=university around the site.

There is one holiday camp, but in OSM there are 3.

Cj



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

[Talk-GB] Holiday camp tagging

[Cj Malone]

Hello everyone,

I'm mapping a local camp site [0], and have a few questions regarding
tags.

1 - It's mainly static caravans with some cabins, but it also has an
area for tents/caravan pitches. It should tagged as
one tourism=caravan_site with tents=yes, right? It's currently split
into one main tourism=caravan_site [0] with another tourism=camp_site
that lacks many details [1] and even a second tourism=caravan_site [2].

2 - The site is split into areas with names, I've started adding
address details to aid in routing, mapping them as addr:housename=area
and addr:unit=#. I was originally planning to use addr:place instead of
addr:housename, but this specific camp site uses real local places
names. eg 28 Appley [3] and Appley suburb [4]. 6 Freshwater [5]
vs Freshwater village [6]. Was this the wrong choice? Should I just use
addr:place and add a place=locality name=Appley way around the area?
Will this damage routing with the real Appley [4]?

Thanks
Cj

[0] https://www.openstreetmap.org/way/339576373
[1] https://www.openstreetmap.org/way/448717739
[2] https://www.openstreetmap.org/way/467598597
[3] https://www.openstreetmap.org/way/492581478
[4] https://www.openstreetmap.org/node/5449148626
[5] https://www.openstreetmap.org/way/492575073
[6] https://www.openstreetmap.org/node/8092847


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

Re: [Talk-GB] New Bing Imagery

[Cj Malone]

I was splitting houses in Portsmouth/Southsea this morning. The imagery
is great, I don't know if it was part of this update, or if it's been
like this for a while.


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

Re: [Talk-GB] UPRN Locations Map

[Cj Malone]

On Sat, 2020-07-04 at 22:24 +0100, Lester Caine wrote:
> What is needed is a means of adding LAYERS of data which can be
> managed either via third party data sets, or manual edited using
> existing tools to add data that is missing from the narrow view
> confined to 'current' objects ...

If I understand you right, I like the idea of this, for example a layer
of bus stops in the UK would be sourced from NapTAN. That layer would
be kept up to date with NapTAN (most bus stops in OSM are a decade old,
unmodified, not validated) and OSM mappers could add
corrections/modifications.
Potentially we could have a line of communication to NapTAN to inform
them of errors in there dataset.

It'll be hard to change some peoples minds, but it's worth discussing.

Cj


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

Re: [Talk-GB] Virtual meeting: New open data and towards more UK addresses

[Cj Malone]

I can't make it for 7:00 pm Saturday, will the discussion be recorded
or notes taken?

Cj



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

Re: [Talk-GB] positioning of shop nodes as entrances

[Cj Malone]

>Personally, I don't like tagging the whole building as 'amenity=cafe' as it
>is only the downstairs of the building being used for that purpose, which
>is why they were nodes.

I agree, it also means that shops on buildings sometimes have `level`, which 
doesn't makes sense.

>So, is there any downside to marking the entrance? I can see that it links
>the cafe node to the building better.

One down side I can think of is that people might deleted the old node, and 
make a new one, and copy the tags across. Losing the history isn't ideal, but 
it's not really an argument against.

Also is there a way to link entrances to a poi as a node? In the example below 
Boots has 2 entrances. Could they both be linked to the pharmacy?

https://www.openstreetmap.org/node/336202468#map=19/50.70033/-1.29443

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

Re: [Talk-GB] Farmfoods clean up

[Cj Malone]

Hello everyone,

I've gone through this and done what I can. I've gone through the OSM
listings and looked through Mapillary to add missing stores.

I didn't keep the stats as well as I intended to, but I now think there
are 327 Farmfoods stores, with 228 of them existing in OSM. They now
have brand data and website links. I decided not to add ref:store as I
couldn't think of a reason for it to exist in OSM.

I did use frozen_food, if anyone disagrees, just change it, I'm not
going to partake in edit wars over it.

There are still 99 missing from OSM, so it might be worth checking if
your local Farmfoods is listed, and if not adding it.

Cj



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

Re: [Talk-GB] Farmfoods clean up

[Cj Malone]

On Wed, 2020-05-27 at 12:01 +0100, Phil Endecott via Talk-GB wrote:
> Cj Malone wrote:
> > This also means shop=frozen_food, currently they are mainly
> > shop=supermarket
> 
> My local one was doing a roaring trade in 36-packs of loo roll
> a few weeks ago.  I believe they are also one of the cheapest
> places to get cans of coke.  So frozen_food sounds a bit too
> limited.

I don't think we should take the tag literally, the wiki says "used for
shops that mainly sell frozen food". I think that's a fair description
of Farmfoods.

Cj



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

Re: [Talk-GB] Farmfoods clean up

[Cj Malone]

On Wed, 2020-05-27 at 11:28 +0100, SK53 wrote:
>  I presume its being applied to Iceland (and Heron?) too.

According to the name suggestion index it's recommended for Iceland but
not for Heron Foods. From memory I think Heron Foods would probably fit
frozen_food but their homepage exclusively shows ambient products so
I'm unsure.

https://nsi.guide/index.html?k=shop=frozen_food#Iceland
https://nsi.guide/index.html?k=shop=supermarket#Heron%20Foods
https://heronfoods.com/

> I suspect the page would be better split across several pages.
> Ideally the numbers could come from a taginfo query, but this would
> probably need a special template & may be too complex because of name
> variants.

I updated some of them to use taginfo, using the brand instead of name,
however this has some issues to.

 - brand is less used so it'll miss a high amount that are mapped but
not using the brand tag. I'm trying to fix this, but it'll be slow.
 - It's not limited to the UK so global brands how have a higher mapped
number than UK stores.
 - I don't think taginfo can be used on multiple tags, so we can't
split out amenity=fuel and shop=supermarket when they operate under the
same brand.

Cj



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

Re: [Talk-GB] Farmfoods clean up

[Cj Malone]

On Wed, 2020-05-27 at 06:35 +, Ed Loach wrote:
> If you can't copy the opening hours data, are you sure you can copy
> the store reference?

That's a good point. I guess I was thinking because it's in the url
it's usable, but I don't know enough about copyright. I'll leave it
out, unless anyone knows more.

> I've already checked and I used shop=supermarket for their local
> store, probably based on
> https://wiki.openstreetmap.org/wiki/Retail_chains_in_the_United_Kingdom

I think that page could do with some restructuring, I started updating
the numbers but it's a lot to deal with. I'd be happy to go with
either, but I do think shop=frozen_food is a better fit.

https://wiki.openstreetmap.org/wiki/Tag:shop%3Dfrozen_food



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

[Talk-GB] Farmfoods clean up

[Cj Malone]

Hello everyone,

I'm intending on doing some maintenance on Farmfoods stores across the
country, and looking for some comments before I do. I've been looking
at it and as far as I can tell Farmfoods has 329 stores, with OSM
having 223 of them. I don't think I'm going to go through Mapillary
images to try and add the missing 106 stores, but I may do.

I'm going to use the nsi recommended tags:

"brand": "Farmfoods"
"brand:wikidata": "Q5435841"
"brand:wikipedia": "en:Farmfoods"
"name": "Farmfoods"
"shop": "frozen_food"

So I'll be unifying on on "Farmfoods" the majority are already tagged
as that with some using "Farm Foods" with various different
capitalisation.

This also means shop=frozen_food, currently they are mainly
shop=supermarket, although a surprising amount don't even have a shop
tag, or invalid tags like shop=food or shop=yes. I imagine this might
be a bit controversial, the standard map on osm.org seems to render
shop=frozen_food as a generic dot and label.

I'll add the website tag to the specific store page, eg 
https://farmfoods.co.uk/store-finder.php?branch_code=880.
I can't copy any data from there but I would also like to add opening
hours, I can do this with opening_hours:url. So I can use the above
link or https://farmfoods.co.uk/includes/opening_hours.php?branch=880.
The second link is more specific to opening hours, and might even look
better if a user agent renders the page inline. But I doubt any user
agents do that, and I don't know how committed to those URLs Farmfoods
are, it would be unfortunate if they update their site without
redirects.

I could also add the stores number/branch code. 880 in the above
example. Should I use store_ref or ref:store, neither seem very common
according to taginfo GB.

I've done a similar thing for Asda except I had permission to use data
from there site, so we now have most of the stores (notes for the
remaining) and instore facilities like pharmacies and cafes. See 
https://www.openstreetmap.org/user/CjMalone/diary/392901

So any comments or anything I should/shouldn't do before I get started
on this?

Cj


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

Re: [Talk-GB] Q2 2020 Quarterly project GP Surgeries and health sites

[Cj Malone via Talk-GB]

I think a lot of the confusion comes from the name suggestion index (some of 
the presets for iD) listing Boots twice. However basically all (if not all) of 
Boots in the UK are pharmacies, because they do prescriptions. In some regions 
this is not the case, Boots without prescriptions is a chemist.

In the UK it's more obvious using Superdrug as an example, some stores do 
prescriptions, some don't. If Superdrug does prescriptions it may be 
amenity=pharmacy or it may have a separate node for the pharmacy, with 
different contract details and opening times, but I don't think this is usually 
worth it for small shops.

Supermarkets on the other hand, I would have there pharmacies as separate 
nodes, partly for the above, different details. But also because the location 
inside the store can be massively helpful for people who just want the 
pharmacy, not the supermarket. See Sainsbury's with a Lloyds Pharmacy inside it 
https://www.openstreetmap.org/node/6868601075 Tesco with a Tesco pharmacy 
inside https://www.openstreetmap.org/node/6841571554

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

Re: [Talk-GB] Quarterly Project Suggestion - drink_water:refill

[Cj Malone]

"You can download our proprietary app, that uses our proprietary data, on 2 
proprietary app stores, on 2 proprietary platforms. The app is open."

Doesn't make much sense to me, but oh well.

Seriously though, I added the only local place I know about. But would it be 
appropriate to contact some of the corporate chains involved, like Costa and 
Starbucks, see if it is 100% universal across there UK stores and then talk 
about an bulk import?

Cj

On 20 March 2020 10:55:39 GMT, European Water Project 
 wrote:
>Dear All,
>
>Just got off a long conversation with Rebecca Burgess, CEO of Refill.
>
>Unsurprisingly, Refill has no plans to share any of their proprietary
>data,
>but their App is open because anybody can use it  :)
>
>Refill has plans to use more and more OpenStreetMap data to populate
>their
>network over time without re-contributing ...   Just a shame everyone
>can't
>just use the Refill App (sarcasm) !
>
>Best regards,
>
>Stuart
>
>PS: Stay safe !
>
>On Sat, 14 Mar 2020 at 23:59, European Water Project <
>europeanwaterproj...@gmail.com> wrote:
>
>> Dear Andy,
>>
>> If Refill.org.uk  were to "license" their data to OSM, under what
>terms
>> would that be concretely?  I don't want to misspeak (not show my
>total
>> ignorance on the subject) when I talk to Rebecca Burgess, the Refill
>CEO on
>> Tuesday.
>>
>> In the unlikely event that Refill's position changes, with whom can I
>put
>> her in contact with?
>>
>> Best regards,
>>
>> Stuart
>>
>> On Sat, Mar 14, 2020, 21:10 Andy Mabbett 
>> wrote:
>>
>>> On Thu, 12 Mar 2020 at 11:27, Jake Edmonds via Talk-GB
>>>  wrote:
>>> >
>>> >  I understand Refill.org.uk are unwilling to license their data.
>>>
>>> They said this in July 2017:
>>>
>>>https://twitter.com/Refill/status/31637345234945
>>>
>>> I've been pressing them on the point of open licensing, recently:
>>>
>>>https://twitter.com/pigsonthewing/status/1216689988357718018
>>>
>>> and have again today chased them for a response:
>>>
>>>https://twitter.com/pigsonthewing/status/1238919492568260609
>>>
>>> --
>>> Andy Mabbett
>>> @Pigsonthewing
>>> http://pigsonthewing.org.uk
>>>
>>> ___
>>> Talk-GB mailing list
>>> Talk-GB@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-gb
>>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Update bus stop names

[Cj Malone]

Hey Neil,

I don't know which nodes you are talking about, but of the ones I'm
looking at (where "name" != name from new NaPTAN data using
"naptan:AtcoCode"). The vast majority haven't been updated in 10 years,
since the NaPTAN import, or one edit where "naptan:verified" was
changed to yes.

I am not doing automatic, or blind edits. It would have been helpful if
when you changed names from NaPTAN import to surveyed you used
"not:name", but that doesn't matter. When I make the edits I can look
at the history of the node, and if a mapper has changed the name semi
recently I will not change it but rather add a "fixme" describing the
issue.

Thanks,
Cj

On Sat, 2020-01-18 at 15:01 +, Neil Matthews wrote:
> No, please don't update mismatched bus stop names "blindly".
>
> I've surveyed a lot locally and have updated them to the newest
> values
> from paper timetables -- which have newer names than on metal
> signage.
> They also match the names that the local council have used when
> updating
> OSM. A lot of names were surveyed that didn't need to be changed -- I
> don't know how you would ensure that you didn't change them to some
> incorrect official value. Obviously, you shouldn't be changing names
> that weren't in the preious Naptan data -- you should at least assume
> that they are now newer and likely to come from surveyed data.
>
> The best approach is either to add official_name (naptan_name?) and
> leave "name" alone, or provide a mechanism where local mappers can
> survey mismatches between your dataset and what is currently in OSM.
> At
> the very, very least you should move "name" to "old_name".
>
> Best regards,
> Neil
>
> P.S. At least locally there are locations where several bus stops
> have
> been amalgamated into a single one. Also some are now
> disused:bus_stop
> if no services are currently stopping there.
>
>
>
> ___
> 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] Update bus stop names

[Cj Malone]

Thanks, I didn't really understand the NaPTAN site, but your link to download 
the data really helped.

Although now I have another issue, which data source should be preferred. Take 
https://www.openstreetmap.org/node/550691387 for example, no name in OSM. It's 
napcode appears to be 23062, Southern Vectis has that as "Redwood Close" 
whereas the nap data calls it "Silverbirch Drive".

I'm going to do a survey now, and hopefully it will be clear which dataset 
should be preferred. ie does SV have outdated nap data, or do they pull the 
official nap data, make edits, but not publish that back.

Or maybe this issue could arise that the name on the bus speaker/other digital 
reference could be different to the name on the sign on the road. Then, what 
one would be name vs alt_name, but hopefully that isn't the case.

I currently only intend to add name and nap reference codes to OSM, in my 
opinion the other data like naptan:CommonName should stay in the nap dataset, 
and not be copied to OSM. OSM mappers collecting, or even just storing that 
data will just make more conflicts in the datasets.

Cj

On 18 January 2020 12:16:35 GMT, Stuart Reynolds 
 wrote:
>Hi Cj,
>
>What you have got there is Southern Vectis’s link to a subset of the
>current NaPTAN data. Please note, though, that Southern Vectis are not
>responsible for this data - that is maintained by Isle of Wight
>Council.
>
>NaPTAN data is always available by local authority, or for the entire
>country, from the official source. You don’t need to have a login, and
>instructions can be found at
>http://naptan.app.dft.gov.uk/DataRequest/help on how to download
>individual areas. Essentially, you will need the Atcoprefix to form the
>URL and you can get this most easily by following the “last
>submissions” link contained within that page.
>
>But all this comes with a health warning!
>
>NaPTAN data from the official source will generally be more up to date
>than what has been imported into OSM some years ago. But I know, from
>when I proposed a mechanical edits few years ago, that many mappers
>have surveyed their local stops and would be unhappy with it being
>updated without a further survey by what they regard as an inferior
>source, particularly if is not well maintained.
>
>Be aware of “Custom and practice” stops in NaPTAN which are unmarked.
>Buses stop there, but there isn’t something that you can see on the
>ground that you can map, necessarily. Hail and Ride stops are even
>worse, because they are virtual stops intended to give something that a
>scheduling system can hang a time on rather than an accurate
>representation of where a bus stops. You can identify all of these by
>BusStopType in the data.
>
>Common errors in the official NaPTAN data set may be missing stops, or
>the inclusion of stops that are no longer in use. Some areas remove
>stops when they are no longer served, even though the infrastructure is
>still in place on the ground (wrong, in my opinion, but there you go).
>You may also find stops that are not precisely where you expect them to
>be, and they may also not have the name that is on the stop flag on the
>ground.
>
>That last one is a point worth dwelling on. NaPTAN is intended to be
>granular in its data. That means that the street that a stop is on
>should go into the “streetname” field, and a short name should go into
>the “commonname” field. Our advice to database administrators is that
>where there isn’t a prominent landmark (bus station, pub, etc) then
>this is most suited to a nearby side road. That way stops along a long
>road can have different names, which is essential in a journey planner
>or timetable. On the ground, though, many authorities will put
>composite names on the flags, and often the other way round if they
>consider the main road to be more important. And they then differ on
>occasion from what the operator wants to call the stop (although
>operators tend to focus on just the timetabled points). Oh, and some
>areas misuse the fields. In Sheffield (for good historic reasons, so I
>don’t want to pick on them unduly) you will find that the commonname is
>simply the stop letter e.g. CS1 which should properly be in the
>Indicator field, and the common name (which should be “Century Square”)
>is only found by looking at the stop area name.
>
>All this just goes to highlight that you will need to reflect carefully
>on what the fields that you are updating in OSM should be before making
>the changes - although I agree that in many places the data in OSM is
>way out of date and desperately needs updating.
>
>Regards,
>Stuart Reynolds
>for traveline south east and anglia
>
>On 18 Jan 2020, at 11:18, Cj Malone via Talk-GB
>mailto:talk-gb@openstreetmap.org>> wrote:
>
>He

[Talk-GB] Update bus stop names

[Cj Malone via Talk-GB]

Hello,

I've recently found an open data set with more accurate bus stop names
than OSM. Based on my limited survey of differences in OSM data and
this data, theirs has been more accurate. Not really surprising, since
it's there network, and most of the OSM data hasn't been updated since
the naptan import nearly a decade ago.

I intent to start updating OSM based on this data. The legal mailing
list has OK'ed this as it's OGLv3.

I won't be importing any nodes, but I do intend for it to be "machine
assisted". I will create a report similar to
https://gregrs.dev.openstreetmap.org/fhrs/ where I will then go through
on a node by node basis and decide if the node should be updated. Any
tag I edit I will add source:name=Southern Vectis, and leave the
naptan:CommonName untouched.

While I do this I could also upgrade from highway=bus_stop to
public_transport=platform, bus=yes. Keeping the legacy tags as the wiki
recommends.

I will be using this data set https://www.islandbuses.info/open-data
the same data set is available for more regions, but at the moment I don't 
intent to use them, a local mapper would be better suited. 
https://www.discoverpassenger.com/2019/06/25/open-data-portals-go-
ahead-group/

Any comments?

Thanks
Cj


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

Re: [OSM-legal-talk] New data source

[Cj Malone]

Thanks Kathleen,

I'll add attribution to the wiki tomorrow.

My current intention isn't to automatically import, but rather generate a 
report where I can see where OSM names differ, then manually change the names 
is OSM via JOSM on a per node basis. Similar to 
https://gregrs.dev.openstreetmap.org/fhrs/ for food hygiene data.

Based on my limited survey of differences in OSM data and SV data, theirs has 
been more accurate. Not really surprising, since it's there network, and most 
of the OSM data hasn't been updated since the naptan import nearly a decade ago.

I don't think I will be making the report public, although since the data is 
not unique to the local bus operator, but rather their service providers. I 
could make reports for all areas available if desired. 
https://www.discoverpassenger.com/2019/06/25/open-data-portals-go-ahead-group/

I don't really think this is an import, but rather "machine assisted" (if 
that's a thing in OSM vocabulary) I will however message the import mailing 
list to check there opinion on this. And I'll ask them if there is any point 
moving to the newer tagging method of public_transport=platform, as well as 
(for legacy reasons) highway=bus_stop.

Thank you

On 17 January 2020 21:28:16 GMT, Kathleen Lu via legal-talk 
 wrote:
>Hi Cj,
>Easiest method would be for you to update
>https://wiki.openstreetmap.org/wiki/Contributors with this information.
>(But please do note the import guidelines if you are thinking about
>importing)
>Best,
>Kathleen
>
>On Thu, Jan 16, 2020 at 5:26 AM Cj Malone  wrote:
>
>> Hello,
>>
>> I recently saw that some bus stop names are out of date in my area. I
>> updated the one I saw (
>> https://www.openstreetmap.org/node/533814248/history)
>>
>> But the local bus operator offers this data under Open Government
>> License Version 3.0. (https://www.islandbuses.info/open-data)
>>
>> As far as I understand it OGL can be used in OSM, but needs
>> attribution. Is this correct? How can OSM add the attribution so I
>can
>> start using this dataset?
>>
>> Once someone verifies that I can use this dataset I intend to correct
>> any OSM names, add fixme tags to any this I don't think exist any
>more.
>> And possibly add naptan:AtcoCode=x to nodes that don't have it in OSM
>> but do in the Southern Vectis dataset. And add "SouthernVectis" to
>the
>> source tag which would usually mean, source=naptan_import ->
>> source=naptan_import;SouthernVectis.
>>
>> Thanks
>> Cj
>>
>>
>> ___
>> legal-talk mailing list
>> legal-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/legal-talk
>>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

[OSM-legal-talk] New data source

[Cj Malone]

Hello,

I recently saw that some bus stop names are out of date in my area. I
updated the one I saw (
https://www.openstreetmap.org/node/533814248/history)

But the local bus operator offers this data under Open Government
License Version 3.0. (https://www.islandbuses.info/open-data)

As far as I understand it OGL can be used in OSM, but needs
attribution. Is this correct? How can OSM add the attribution so I can
start using this dataset?

Once someone verifies that I can use this dataset I intend to correct
any OSM names, add fixme tags to any this I don't think exist any more.
And possibly add naptan:AtcoCode=x to nodes that don't have it in OSM
but do in the Southern Vectis dataset. And add "SouthernVectis" to the
source tag which would usually mean, source=naptan_import ->
source=naptan_import;SouthernVectis.

Thanks
Cj


___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-GB] Stale Developments

[Cj Malone via Talk-GB]

In that case wouldn't it be handy to add 'survey:date=-MM-DD'?

Plus that bumps the edit date that'd push it out of this, and related 
out-of-date tools.

On 10 January 2020 14:42:11 GMT, Andy Robinson  wrote:
>Excellent Robert, very useful.
>
>Note that brownfield sites can remain that way for many many years
>before eventually being developed. I recall investigating brownfield
>sites in Birmingham as part of my degree in the 1980's (photogrammetry
>module). Some of those sites are still brownfield. Many heavily
>contaminated sites in our urban sprawls require cleaning up before they
>can ever be reused.
>
>Cheers
>Andy
>
>-Original Message-
>From: Robert Whittaker (OSM lists)
>[mailto:robert.whittaker+...@gmail.com] 
>Sent: 10 January 2020 14:10
>To: talk-gb
>Subject: [Talk-GB] Stale Developments
>
>I'd like to announce a new mini QA tool that I've put together for UK
>OSMers: Stale Developments: https://osm.mathmos.net/developments/
>
>It finds OSM UK highway and landuse tags with tags values of
>construction, brownfield and greenfield, which haven't been edited for
>over a year. The idea is that such objects should correspond to
>real-life developments, whose status is likely to change on that
>timescale. Hence the OSM objects probably need reviewing and updating.
>
>To keep the numbers reasonable, the page above only lists the most
>stale objects (no edits for over four years), but the full set of the
>data is exposed through my Survey Me tool at
>https://osm.mathmos.net/survey/ .
>
>Do take a look if you're interested. I hope this is useful to some of
>you.
>
>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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb