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

[Robert Whittaker (OSM lists)]

Maybe there should be a general good-practice recommendation / policy
that bots running in this fashion to keep things in sync should only
automatically add/update/remove a tag that they've previously set if
the current state/value in OSM is unchanged from the last state/value
that the bot set. This way, bots could be used to keep things up to
date automatically, but would not automatically override any manually
applied changes by other mappers between runs. (A sensible bot owner
would have the bot send them a report of any tags that couldn't be
updated for manual review.)

Robert.

On Thu, 14 Sept 2023 at 08:41, Cj Malone
 wrote:
>
> 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


-- 
Robert Whittaker

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

Re: [Talk-GB] UK street addressing

[Robert Whittaker (OSM lists)]

As others have said, having some uniform national scheme of
places/areas that each address is assigned to is useful for anyone
using addresses. No-one outside the local area will know which postal
districts correspond to which areas, or even where many remote postal
areas are. Local authorities would be better than postcode districts,
but again they may not always be well-known (even amongst local
residents), and their boundaries can change. Post towns provide a more
recognisable way for people to identify the rough location of an
address. They're also good for error checking / correction within
addresses.

In any case, if OSM is going to be a useful source of addresses for
businesses and the public, we need to replicate the official addresses
that everyone is currently used to using.

On Mon, 21 Dec 2020 at 16:19, Chris Hill  wrote:
> How are they verifiable? There is no open source that is compatible with
> the OSM licence that I am aware of that lets us look up an address.

There are plenty of open sources for addresses. They won't be
complete, but if you know the postcode of the address you're
interested in, in the vast majority of cases you should be able to
find an open address that's close enough to be able to infer the post
town. In particular, there is an open dataset of addresses for all
post office branches: https://osm.mathmos.net/postoffice/data/ . This
should cover pretty much all the post towns, and if you add in the
(admittedly imperfect) FHRS data, I'd have thought that you should be
able to deduce the correct post town in almost every case.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] UK street addressing

[Robert Whittaker (OSM lists)]

On Mon, 21 Dec 2020 at 12:02, Alan Mackie  wrote:
>
> I struggle with what to call the  in that example.
>
> A recent suggestion for named terraces was to use addr:street= 
> and addr:parentstreet=, but if the  relates the 
> whole building to to parentstreet, then reconstructing an address seems 
> impossible.

In cases where a building/property has a number and/or name on a main
street and is then sub-divided into dwellings, I would put the
building/property info in addr:housenumber and/or addr:housename with
addr:street as the main street. You then need a way to tag the
individual dwelling identifiers. Looking at
https://wiki.openstreetmap.org/wiki/Key:addr#Detailed_subkeys it looks
like addr:unit might be the best tag to use.

This is a different way of thinking about things from the "named
terrace" as a sub-street approach. There are certainly real
sub-streets branching off main streets that could use addr:street=*
and addr:parentstreet=* that will want that approach. And there will
be instances of named/numbered buildings that have flats or
appartments within them that will want the approach above. There will
be probably be borderline cases between the two that could use either
scheme, though if the main property/building has a number on the main
street, you wouldn't be able to use the sub-street approach.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Anglican churches

[Robert Whittaker (OSM lists) via Talk-GB]

On Fri, 18 Dec 2020 at 20:07, Donald Noble  wrote:
> Forgive me if I've missed it somewhere, but what do the different colours 
> represent on the nameless places of worship page?

It's not documented anywhere at the moment, but the different coloured
markers on the "nameless" maps at e.g.
https://osm.mathmos.net/nameless/amenity/place_of_worship simply
denote the type of OSM object: node, way or relation.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] UK street addressing

[Robert Whittaker (OSM lists)]

Like it or not, in the UK addresses are defined by Royal Mail. They're
introduced the concept of a "postal town", and this is one of the few
common elements that each address must always have. Once you accept
that the Post Town is intended to be a nearby significant place (to
help with delivery routing and identifying the rough location of the
addressed property) rather than being a place that the address is
"in", then it's really no more of a fiction than the postcode. (The
village I grew up in had a GL postcode, despite it being in
Worcestershire. I've currently got an IP postcode, despite being in
Norfolk and closer to Norwich (NR) than Ipswich.)

On the basis that it's a required part of each address, I would
recommend that we do store the post town in OSM addresses. There are
significant advantages to storing it in a consistent way, and the best
existing tag to do this would be addr:city. (We wouldn't want to
invent a new tag (e.g. addr:posttown), since as a UK-only term that
will simply be ignored by most international data consumers.

We then have a possible hierarchy of named localities between the
street and the post town to record as part of the address. I would
suggest using appropriate values from the set {addr:hamlet,
addr:village, addr:town, addr:suburb}. (I don't see any other
alternatives to this.) Most of these key names already have a
reasonable number of uses in OSM (addr:town is the lowest, but that
still has 59k uses), so it seems that others are doing this too.

Regarding properties (e.g. on named terraces or sub-streets), where
there are two street names (Thoroughfare and Dependent Throughourfare
in Rail Mail terminology) then we need a second key to store the other
street name under. Certainly if there is an addr:housenumber or
addr:housename, I think we need to use addr:street for the
street/terrace name on which that name or number applies. Otherwise,
software that's unaware of the second key name will think it's house
number n on the main street not the sub-street. There are already
about 3.5k uses of addr:parentstreet in OSM, so I'd recommend using
that for the main street, and addr:street for the terrace or
sub-street name. If any data-users aren't aware of addr:parentstreet
it's not a major issue, since it will still pick up the correct
terrace/sub-street name, and the locality, which will probably be
enough to use as an address.

I would strongly argue against using addr2 in connection with
sub-streets, as it's not standardised, and is likely to not be picked
up by any software. There's an abondoned proposal at
https://wiki.openstreetmap.org/wiki/Proposed_features/addr2 , but that
was for the case of a single property on a street corner having two
formal addresses, one on each street, not for the case of two streets
in a hierarchy.

Robert.

On Sun, 20 Dec 2020 at 12:47, Dave Abbott  wrote:
> I am trying to make sure I tag addresses correctly. I am currently
> trying to understand how to map in my area.
>
> The postal addresses are like:
>
> 99 Postal Street
> Smalltown
> Largertown
> West Yorks XY9 7GY
>
> Smalltown is geographically separate to Largertown, which however is the
> Postal Town. Omitting Smalltown from the address is probably correct
> postally-speaking, but local residents would object as Smalltown is seen
> as completely separate to other places under the same Postal Town.
>
> Currently tagging as -
> addr:housenumber=99
> addr:street=Postal Street
> addr:city=Smalltown, Largertown
>
> But I am pretty sure this is wrong.
>
> There is a page at
> https://wiki.openstreetmap.org/wiki/User:Rjw62/UK_Address_Mapping which
> mentions "suggested tags" but there is no evidence that this is in use.
> If correct I would be tagging as -
>
> addr:housenumber=99
> addr:street=Postal Street
> addr:town=Smalltown
> addr:city=Largertown
>
> Hoping someone can advise me as to the correct way to tag for the UK...
>
> Dave Abbott  (OSM user DaveyPorcy)
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb


-- 
Robert Whittaker

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

Re: [Talk-GB] Anglican churches

[Robert Whittaker (OSM lists)]

On Fri, 18 Dec 2020 at 18:05, Sean Blanchflower  wrote:
> In case anyone's interested I set myself the lockdown project of ensuring all 
> the active Anglican churches in England are mapped consistently in OSM, and 
> have gotten as far as I realistically can for the moment.
>
> The net result is that of the 15649 active Anglican churches that I know of 
> in England, all of them are now in OSM mapped as ways with 
> building=church;amenity=place_of_worship;religion=christian;denomination=anglican;name=XX
> other than...

Good stuff!

On a slightly related note, I've recently done a bit of an upgrade to
my "Nameless" tool. This flags objects that don't have a name=* tag
when you'd usually expect them too. There's now a page for each tag
combination with a map and list of the nameless objects. The
top-ranked tag combination is amenity=place_of_worship, with around
4,000 instances:
https://osm.mathmos.net/nameless/amenity/place_of_worship . I think a
lot of them may have been armchair-mapped from possibly out of date
maps. So if anyone is at a loose end and fancies trying to work out if
the places of worship listed there are still in use and if so what
their name is, please have a look.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Bridleway across field

[Robert Whittaker (OSM lists)]

On Tue, 8 Dec 2020 at 13:18, Dave F via Talk-GB
 wrote:
>
> https://snipboard.io/scrm5R.jpg
>
> There you go, free of any supposed copyright infringement.

Not quite. Before we're able to use any third-party data in OSM, we
need to verify that it is available under a suitable licence. So you
would still need to get permission from Wiltshire Council to use that
data, and ensure that any required attribution statements or
disclaimers are correctly recorded at
https://wiki.openstreetmap.org/wiki/Contributors#Public_Rights_of_Way_Data_from_local_councils
.

If you trust the author of Rowmaps, you could make use of the
Wiltshire data that's available from
https://www.rowmaps.com/datasets/WT/ (which claims to be re-usable
under the OGL v3) once the appropriate attribution statement is added
to the OSM Contributors page linked above. However the precise
attribution statement required isn't clear, and the copyright text in
the files on rowmaps conflicts with the statement that it's available
under the OGL v3. (If the text in the files is correct, then they're
incompatible with OSM use, due to the additional sub-licensing
requirement.)

So I think we'd be better to wait for a successful outcome at
https://www.whatdotheyknow.com/request/public_rights_of_way_gis_data_9
before using the Wiltshire data. Many other councils have made their
data available under terms we can use in OSM, as you can see from
https://osm.mathmos.net/prow/open-data/ .

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Bridleway across field

[Robert Whittaker (OSM lists)]

On Tue, 8 Dec 2020 at 12:37, Dave F  wrote:
> On 08/12/2020 12:08, Robert Whittaker (OSM lists) wrote:
> > On Tue, 8 Dec 2020 at 09:39, Mark Lee via Talk-GB
> >  wrote:
> >> Hello. I've just added a missing public bridleway 
> >> (https://www.openstreetmap.org/way/882278479) which is detailed on the 
> >> Wiltshire Definitive Map.
> > Generally these maps have lines drawn on top of
> > Copyrighted Ordnance Survey base-maps, which means they're off-limits
> > for use in OSM.
>
> Do you have evidence of this being the case? Has someone from OS (or
> anyone outside OSM) stated that?

Since the Definitive Maps are someone else's work, without a licence /
permission, we aren't allowed to make use of them in OSM. So the
question is usually moot. I'm not aware of any instances of a
Surveying Authority granting a re-use licence for its definitive maps.

But, generally speaking, the base-map will contain a OS copyright
notice, and OS have historically claimed derived data rights over
anything drawn on top of their base-maps. This would mean that local
authorities aren't able to authorise any re-use. That's changed
slightly in the last few years, with OS's "Presumption to Publish"
policy. But this makes it clear that it's only the derived data on its
own (and not the basemaps) that third-parties are able to licence. See
https://www.ordnancesurvey.co.uk/business-government/licensing-agreements/presumption-to-publish-form
and in particular point 5: "For example, you can’t use OS licensed
data as a background picture to give your data better real-world
context." The upshot of this is that Councils are able to allow re-use
of their Rights of Way data if it's separated from the OS base-map
(e.g. as a stand-alone GIS file), but not the Definitive Maps
themselves.

I guess if a council is still using a very old OS base-map that has
since gone out of copyright, things might be different. But you'd
still need an explicit licence from the council if their depictions of
the Rights of Way were still in copyright. And there's a question
about the status of derived data rights on derivations made while the
base-maps were still in copyright.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Bridleway across field

[Robert Whittaker (OSM lists)]

On Tue, 8 Dec 2020 at 09:39, Mark Lee via Talk-GB
 wrote:
> Hello. I've just added a missing public bridleway 
> (https://www.openstreetmap.org/way/882278479) which is detailed on the 
> Wiltshire Definitive Map.

I see that you've put source="Wiltshire Definitive Map" in the
tagging. Do you have permission to use information from the Definitive
Map in OpenStreetMap? Generally these maps have lines drawn on top of
Copyrighted Ordnance Survey base-maps, which means they're off-limits
for use in OSM.

Digitised Public Rights of Way data (without the base-map background)
is another matter though, and it is possible to get permission to use
these. But we need an explicit statement / licence from each Council.
Generally this will be permission to use the data under the Open
Government Licence, and we would then need to document this with the
specified attribution statement at
https://wiki.openstreetmap.org/wiki/Contributors#Public_Rights_of_Way_Data_from_local_councils
. Wiltshire is not currently listed there, although there is an FOI
request in progress to get the data and permission to use it:
https://www.whatdotheyknow.com/request/public_rights_of_way_gis_data_9
.

I maintain a table of which authorities we have PRoW data for and what
licence it can be used under at
https://osm.mathmos.net/prow/open-data/ . Any updates and corrections
to this would be most welcome.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Idea - OSMUK walkers' map application

[Robert Whittaker (OSM lists)]

On Sat, 5 Dec 2020 at 15:29, Nick Whitelegg via Talk-GB
 wrote:
> A shame really, an open, standard API - and accompanying open source clients 
> to the API - adopted by all councils for problem reporting would be a great 
> thing to have.

It would indeed be great. An open standard for this already exists --
it's called Open311. I don't think there's very much adoption of it
though. See https://www.open311.org/ and
https://www.mysociety.org/2013/01/10/open311-introduced/ . Fix
MyStreet can make use of it where it is available, and some of the
councils they have collaborated with may well support it.

If anyone is looking to create some sort of reporting tool for PRoW
faults, I'd suggest a system that will use Open311 if the council
supports it, and otherwise send the report through FixMyStreet.

Robert.

-- 
Robert Whittaker

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

Re: [OSM-talk] I’m running for OSMF board and I’ve set up office hours for questions

[Robert Whittaker (OSM lists)]

On Wed, 2 Dec 2020 at 21:56, Michal Migurski  wrote:
> First, the text of the ODbL is explicit about “reasonably calculated” 
> awareness. FB believes its maps comply with this. The ODbL does not require 
> that “every” person see the attribution. It requires that “any” person can.

I believe that you are wrong here. In ODbL 4.3, "any Person" is
synonymous with "every Person". The term "reasonably calculated"
modifies the whole clause, and is about the result of the scheme as a
whole, not "reasonable awareness" by individuals. It means that the
attribution method you use must be reasonably calculated to ensure
that *every* person viewing will be aware that content has come from
OpenStreetMap. Nowhere does the clause allow you to only provide the
opportunity for anyone to be able to discover the source if they
decide to, or to only ensure some people are aware. Yes, the
"reasonably calculated" means that not 100% of people necessarily have
to be aware, but the attribution scheme does have to have the purpose
and intention of making everyone aware. You have to be able to say
that under a reasonable assessment of the scheme, everyone viewing the
work will know of the ODbL source. I think it's clear this is not the
case for the current Facebook attribution, as clearly lots of people
will not choose to click on the "(i)" icon.

Given your interpretation of ODbL 4.3 and the statements you have made
so far, does this mean that you and/or Facebook are admitting that the
current Facebook attribution does not meet this stricter
interpretation of 4.3? i.e. the current Facebook attribution is not
"reasonably calculated" to ensure that every person who "uses, views,
accesses, interacts with, or is otherwise exposed to the Produced Work
aware that Content was obtained from" OpenStreetMap?

I think this is a crucial point that the OSM community needs an answer
to, given your candidacy for the OSMF Board.

Many thanks,

Robert.

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

Re: [OSM-talk] I’m running for OSMF board and I’ve set up office hours for questions

[Robert Whittaker (OSM lists)]

On Wed, 2 Dec 2020 at 03:41, Michal Migurski  wrote:

> Facebook is in compliance with the ODbL license which requires that 
> attribution be “reasonably calculated to make any Person that uses, views, 
> accesses, interacts with, or is otherwise exposed to the Produced Work aware” 
> of OSM’s contribution to a map.

Are you seriously claiming that *every* person who views one of the
maps on Facebook, will either already know that it uses OpenStreetMap
data, or will click on the faint "(i)" logo to find that out? Because
that is what the ODbL requires. This isn't just about a mechanism for
people who are already motivated to find out where the map data comes
from, your attribution needs to be reasonably calculated to ensure
that *everyone* viewing one of your maps (whether they're interested
or not) is aware that the map data has come from OpenStreetMap. I
don't see how you can claim that your current attribution does that.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] High quality NLS imagery of buildings and HOUSENUMBERS (!) available in London (and Scotland). Create a tasking manger to add this?

[Robert Whittaker (OSM lists)]

On Tue, 1 Dec 2020 at 09:53, Ken Kilfedder  wrote:
> IpswichMapper forwarded me this note, apparently received from NLS via an 
> enquiry made by Rob-from-OSMF:
>
> > “I wish I could give you better news on the 1940s OS maps of south-east 
> > England.
> > Unfortunately, you’re right, they were scanned by a third-party commercial 
> > company
> > who have placed commercial re-use restrictions on this layer – there are 
> > further
> > details under our Copyright Exceptions list at
> > https://maps.nls.uk/copyright.html#exceptions. These restrictions will last 
> > for
> > another couple of years – until the end of 2022 – which I know might seem a 
> > long
> > way off, but hopefully will pass quickly. Then we’ll be happily able to 
> > share
> > them with the OSM community, along with the rest of England and Wales
> > National Grid 1940s-1960s mapping, that will be of interest too.”

Looking at https://maps.nls.uk/copyright.html#exceptions am I right in
thinking that the non-commercial contract restriction also applies to
some other NLS layers (e.g. OS 1:25k and 7th series scans) which have
been available (and being used) in popular OSM editors for some time
now? Do we have some specific permission to use those layers, and if
so does that permission apply to the new house number layer as well?

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Recycling Points

[Robert Whittaker (OSM lists)]

On Sat, 28 Nov 2020 at 12:35, Mateusz Konieczny via Talk-GB
 wrote:
> 28 Nov 2020, 10:48 by robert.whittaker+...@gmail.com:
>
> I guess the problem is that recycling_type=container is being used
> both for individual containers and for mini sites with a group of
> containers.
>
> Is it really a problem?

It is if you want to be able to micro-map such a site and the
individual containers within it.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Recycling Points

[Robert Whittaker (OSM lists)]

On Fri, 27 Nov 2020 at 09:42, Jez Nicholson  wrote:
> Agreed, "point" sucks as a value, I won't use itmy fundamental reason for 
> it not being a 'centre' was size, but a Recycling Point _could_ be seen as a 
> mini Recycling Centre that only accepts recyclable waste. You can see a 
> perimeter boundary by the concrete area it is set on. I could go with a site 
> relation but you can't physically carry out other activities between the 
> constituent objects (unlike a wind farm).

How about recycling_type=container_site ?

I guess the problem is that recycling_type=container is being used
both for individual containers and for mini sites with a group of
containers. An alternative approach would be to continue to use
recycling_type=container for the site, and have a new tag for
individual containers within such a site. (Then it would be a bit like
mapping individual parking spaces within a car-park.)

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] UPRN wiki page

[Robert Whittaker (OSM lists)]

On Wed, 18 Nov 2020 at 10:42, Jez Nicholson  wrote:
> My personal opinion is that UPRNs never apply to a road or road section. They 
> apply to something that you cannot see, like a grit bin that is no longer 
> there.

It's definitely possible for UPRNs to be assigned to streets. I think
you can tell this by searching for such a UPRN at
https://www.findmyaddress.co.uk/ (I don't look at that now since they
added a new T forbidding any use of the information for competing
purposes.) IIRC, that site will tell you if a UPRN you enter is a
street reference, and then refuse to provide the usual address
information.

It could well vary by local authority, but looking at the pattern of
URPNs near where I live, it certainly seems that there is one assigned
to every public road. There is consistently exactly UPRN at one end or
the other of each road. The pattern is quite obvious if you look at a
housing estate with lots of little roads.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] "Survey Me" Tool Update

[Robert Whittaker (OSM lists)]

On Sat, 7 Nov 2020 at 13:02, ael via Talk-GB  wrote:
> On Sat, Nov 07, 2020 at 12:11:42PM +, Robert Whittaker (OSM lists) wrote:
> > For anyone who's interested, I've just updated my "Survey Me" tool at
> > https://osm.mathmos.net/survey/ .
>
> I took a look and it flagged up
>   https://www.openstreetmap.org/node/3149722064
> as having no name. But it has a perfectly good name?

It's not flagging https://www.openstreetmap.org/node/3149722064 , it's
flagging the building next to it:
https://www.openstreetmap.org/way/679205532 . That building is tagged
with shop=yes but no has name=* tag. When an issue concerns an
existing OSM object, you'll find a direct link to that object in the
popup bubble when you click/tap on the icon.

In this case see: https://osm.mathmos.net/survey/#19/51.7885/-1.4833 .
If the building is only that single shop, then you could remove the
shop node and transfer the tags to the building way. If the building
also has other uses (e.g. there's a flat above the shop, or it
contains more than one shop) then it might be better to remove the
shop=yes tag from the building, and move the shop node inside the
bounds of the building instead.

Robert.

-- 
Robert Whittaker

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

[Talk-GB] "Survey Me" Tool Update

[Robert Whittaker (OSM lists)]

For anyone who's interested, I've just updated my "Survey Me" tool at
https://osm.mathmos.net/survey/ . It now includes food retail chains
where OSM mapping doesn't agree with the "Retail Points" dataset from
Geolytix ( https://blog.geolytix.net/tag/retail-points/ ).

The idea of "Survey Me" is that it flags up potential errors or
omissions in OSM data that probably require a ground survey to
resolve. So mappers may like to have a look at their local area, or
anywhere they are visiting, to see if there's anything worth checking
out.

More details of the comparison between OSM data and Retail Points can
be found at https://osm.mathmos.net/chains/ .

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] OSM UK's first tile layer

[Robert Whittaker (OSM lists)]

On Sat, 17 Oct 2020 at 00:22, Rob Nickerson  wrote:
> Just in time for the AGM, I have just published OSM UK's first tile layer. No 
> don't get too excited it is not a full map render. Instead I have produced a 
> very simple tiling of the Land Registry polygon data now that this is under 
> the OGL Open Data Licence. My view is that this is a good layer to align our 
> mapping too - i.e. when tracing from imagery we should first align the 
> imagery to the Land Registry polygon layer before tracing from the imagery.
>
> The tile URL for JOSM is:
> tms[13,17]:http://tiles.osmuk.org/LRpolygons/{zoom}/{x}/{y}.png

Excellent. Ever since the new Bing imagery landed, I've been after a
good source to align things to. I've been having to rely on my own GPS
traces and/or existing mapping so far.

By the way, when there was some previous discussion on this list about
using OS data for imagery alignment, an issue was raised about needing
to ensure any transformation from OSGB grid coordinates to WGS84 is
accurate enough:
https://lists.openstreetmap.org/pipermail/talk-gb/2020-August/025077.html
. Popular transforms may be out by a few meters (which would be
noticeable in our detailed mapping.) Are you doing such a
transformation, and are you sure what you're doing is sufficiently
accurate?

Robert.

-- 
Robert Whittaker

-- 
Robert Whittaker

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

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

[Robert Whittaker (OSM lists)]

On Fri, 9 Oct 2020 at 16:20, Gareth L  wrote:
> The UK quarterly project for Q4 has been selected as Defibrillators. 
> https://wiki.openstreetmap.org/wiki/UK_2020_Q4_Project:_Defibrillators
>
> A check on taginfo shows there are 4181 nodes and ways with 
> emergency=defibrillator in Great Britain. Reading 
> https://cesafety.co.uk/list-of-public-access-defibrillators-across-the-uk 
> from August 2019 reports that there are 5304 defibrillators in London alone.

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.

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, though my
local Ambulance Service (East of England) have said they intend to
keep publishing a list for their region.

It's apparent from my tool that there are a significant number of AEDs
that we have mapped in OSM but which aren't on the Ambulance Services'
lists. It would be great if we could engage with the people running
The Circuit to look into ways in which they could use OSM data to help
them discover additional AEDs that haven't yet been registered with
them. I doubt they would take our data on trust (I think they want to
have contact details for the owners and regular assurances that the
AED is being actively maintained) but it would be a good source of
hints for them in who to contact to get the missing devices registered
with them.

Robert.

[1] https://www.thecircuit.uk/
[2] 
https://www.bhf.org.uk/how-you-can-help/how-to-save-a-life/defibrillators/ndn-the-circuit

-- 
Robert Whittaker

-- 
Robert Whittaker

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

[OSM-talk] Tagging health facilities offering COVID testing

[Antonin Delpeuch (lists)]

Hi,

I am wondering if and how it would be appropriate to map COVID testing
facilities. I have seen various national maps but given that they are
especially useful during international travel, I think it would be very
useful to have them in OSM.

I have seen the use of "healthcare:speciality=covid-19", for instance on
this node:

https://www.openstreetmap.org/node/7368671692

But according to TagInfo there are only two uses of that tag value.
Surely other people must have been tagging this by now, but how?

Note that I am primarily interested in mapping the places where samples
are collected, not the laboratories where the samples are actually
analyzed. I think the former is more interesting for the general public.

Thanks,


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

Re: [OSM-talk-fr] Carte des lieux de test COVID

[Antonin Delpeuch (lists)]

Merci Yves, c'est très utile ! Comme l'objectif serait de trouver
quelque-chose de consensuel à travers les frontières, je vais demander
sur talk@ s'ils ont d'autres avis.

Antonin

On 06/10/2020 11:26, Yves P. wrote:
>> Il y a 6 healthcare:speciality=covid-19 dans taginfo
>>
>>     amenity=centre
>>     healthcare=doctor
>>     healthcare:speciality=covid-19
>>
>> ou
>>
>>     amenity=hospital
>>     healthcare=hospital
>>     healthcare:speciality=covid-19
>
> J'ai retrouvé ce message :
>
>> Le 27 mai 2020 à 16:53, Yves P. > > a écrit :
>>
>> Ça Reste Ouvert affiche déjà les objets OSM avec les
>> tags *healthcare=centre* + *healthcare:speciality=covid19*.
>>
>
> __
> Yves
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Carte des lieux de test COVID

[Antonin Delpeuch (lists)]

On 05/10/2020 11:20, Denis Chenu wrote:
> Il existe une liste officielle semble t'il
> https://sante.fr/recherche/trouver/DepistageCovid
> Par contre : je ne sais pas ou la trouver autrement.

Oui, mais c'est juste pour la France - si on se mettait d'accord pour
représenter ça dans OSM, on pourrait avoir une carte internationale. Ça
aurait d'autant plus d'intérêt que les tests sont souvent requis quand
on change de pays :)

Antonin


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

[OSM-talk-fr] Carte des lieux de test COVID

[Antonin Delpeuch (lists)]

Bonjour à tous,

J'ai cherché s'il existait des conventions pour cartographier les lieux
où des tests COVID sont disponibles, mais n'ai rien trouvé de concret
sur https://wiki.openstreetmap.org/wiki/France/Covid-19.

Est-ce que ces informations sont considérées comme trop temporaires,
peut-être ? J'ai l'impression que le besoin est là et que ça risque de
durer un peu ! J'imagine que pour l'essentiel ça reviendrait à ajouter
des tags sur des POIs existants (cabinet de médecine générale, maison de
santé, etc).

Il existe des jeux de données par pays mais je n'ai pas trouvé de carte
globale, ça serait pratique si on pouvait faire ça avec une petite
requête Overpass. On pourrait aussi décliner ça pour les tests
d'anticorps et vaccins (en anticipation)…

Antonin


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

Re: [Talk-at] Gefahr durch Internet-Bergrouten

[nine-osm . org-lists]

Hallo Stefan,

kurze Rückmeldung zu diesem Vorschlag:

On 9/19/20 4:39 PM, Stefan Tauner via Talk-at wrote:

On Sat, 19 Sep 2020 15:29:29 +0200

[...]


Ich bin allerdings noch immer der Meinung, dass alles, wo erfahrene,
sicherheitsbewußte Bergsteiger nicht ohne Klettergurt gehen würden, als
highway=via_ferrata und nicht als highway=path eingetragen gehören. 


Das halte ich für falsch.

Nicht alles was schwierig zu gehen ist ist auch gleich ein "Via Ferrata" 
[1] - also ein Klettersteig mit fix montiertem Stahlseil == "Eisen-Weg".
Bei vielen Touren ist alpine Trittsicherheit [2] erforderlich. Das wird 
durch entsprchende Übung/Erfahrung bzw. eine Trittschulung erlangt.


LG
Erwin


Links:
[1] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dvia_ferrata
[2] https://akademie.alpinewelten.com/bergwandern/trittsicherheit

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

Re: [Talk-at] Gefahr durch Internet-Bergrouten

[nine-osm . org-lists]

Hallo,

als Alpinist und OSM Mapper halte ich die Keys
- sac_scale [1] und
- trail_visibility [2]
für relevante Information zum mappen alpiner Pfade.

Allgemein können Karten potentiell immer falsch sein, man denke nur an 
plötzliche Änderungen durch Naturereignisse wie Muren, Steinschlag, 
Gletscherschmelze, etc.


Allgemein und bei den angesprochenen Fällen ist Eigenverantwortliches 
und vorausschauendes Handeln ist daher im Gelände immer höchstes Gebot.


Wenn es in der Realität (also nicht in der App) zu schwer wird und der 
Pfad nicht zu finden ist dann soll man besser umdrehen. ¯\_(ツ)_/¯


LG
Erwin


Links
[1] https://wiki.openstreetmap.org/wiki/Key:sac_scale#Values
[2] https://wiki.openstreetmap.org/wiki/Key:trail_visibility


On 9/3/20 3:05 PM, Johann Haag wrote:
Mir wäre Neu, dass es im Internet Bergrouten gibt, Bergrouten gibt es am 
Berg.
In OpenStreetMap kann man sich unter osm.org  
öffentliche GPS-Tracks einblenden. Ich finde derlei Schwarmintelligenz 
zum erkennen von Hauptrouten jedenfalls sehr nützlich, praktisch und 
auch verlässlich.

Auch offizielle Karten können irren, https://youtu.be/oYdmqf_P8DM?t=165

Grüße Johann

Am Do., 27. Aug. 2020 um 12:39 Uhr schrieb PPete >:


Gestern gab es in ORF-Bundesland heute OÖ einen Bericht (mit jenem
Titel) über einige kürzlich stattgefundene Bergrettungseinsätze, die
teilweise mit falsch eingetragenen Pfaden in der OSM oder der
Verwendung von ungeeigneten Karten zum Bergwandern zu tun haben. Zu
einem der Fälle gabs kürzlich auch einen Bericht in den OÖN. Siehe:

https://ooe.orf.at/stories/3064030/

https://www.nachrichten.at/oberoesterreich/abkuerzung-per-routenapp-aufwendige-rettungsaktion-im-toten-gebirge;art4,3286408

Beim Fall am Mittagkogel geht's vermutlich um die Strecke vom
Rinnerkogel (2012 m) zum Mittagkogel (1823 m) und in weiterer Folge
über die Grünbergalm runter zum Offensee:
https://www.openstreetmap.org/#map=15/47.7238/13.8372

Ich muss sagen, ich kenne den Weg und Gegebenheiten vorort nicht,
aber es hört sich für mich an dass sich der Mapper damals Gedanken
darüber gemacht hat und Schwierigkeit und Sichtbarkeit so bewertet,
dass er als schlecht sichtbarer, sehr schwieriger alpiner Steig
eingetragen ist.
Der Pfad hat "sac_scale=demanding_alpine_hiking" und
"trail_visibility=horrible"

Nun das große Problem aus meiner Sicht: Es gibt nur sehr wenige
Karte die diese OSM-Skalen auch darstellen und man schon bei der
Planung oder später unterwegs sieht, was für ein Pfad einem in etwa
erwartet. Wenn ihr euch den obigen Openstreetmap-Link anschaut sehen
darauf alle Pfade gleich aus, ein rot gepunktete Linie. Also ein
kaum sichtbarer hochalpiner Steig genauso wie ein einfaches, bestens
markiertes Wanderwegerl durch flachen Wald.

Vorbildlich wird dies soweit mir bekannt nur z.b. auf
OpenAndroMaps-Karten dargestellt (die ich selber schon lange als
Standarkarte am Handy verwende) wo Pfade nach Farben
(=Schwierigkeit) und Strichlängen (=Sichtbarkeit) zu unterschieden
sind. Der angesprochene Weg ist darin schwarz (sehr schwer) und
punktiert (sehr schlechte sichtbarkeit) dargestellt.

Letztendlich bleibt die Eigenverantwortlichkeit das man sich vor so
einer alpinen Tour über geeignetes Kartenmaterial informiert. Und
zweitens muss man sich ev. als Kartenanbieter auch fragen ob ich
wirklich jedes hochalpine Steiglein aus den OSM-Daten in meine Karte
einzeichne, wenn diese darin nicht von gewöhnlichen, gefahrlosen
Wanderwegerl unterscheidbar sind.

Dann wird vom Bergrettungsmann im ORF-Bericht noch ein Steig
nördlich des Krippensteins erwähnt bzw. am PC gezeigt, der angeblich
gar nicht vorhanden ist und auch schon zu Einsätzen geführt hat. Was
damit machen? Ihn löschen und der Bergrettung über die Löschung
Bescheid geben? Oder vorher mit ihr Kontakt aufnehmen und fragen
welche Abschnitte genau zu löschen sind? Er hat gesagt er hätte zum
"Kartenanbieter" Kontakt aufgenommen, aber scheinbar ohne "Erfolg",
der Pfad dürfte immer noch vorhanden sein.
___
Talk-at mailing list
Talk-at@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-at



--
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at 

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




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

Re: [Talk-at] OSM AT Erreichbarkeit

[nine-osm . org-lists]

Hallo liebe Leute,

die Mailing-Liste  sehe ich wie alle weiteren 
offiziellen Openstreetmap.org Mailinglisten mit voller Berechtigung.


Übersicht über Openstreetmap.org Mailinglisten:
https://wiki.openstreetmap.org/wiki/Mailing_lists

Beste Grüße aus der Steiermark,
Erwin


On 8/17/20 8:13 PM, Johann Haag wrote:

Hallo Andreas,
Du verstehst mich völlig falsch, jede Mitarbeit von Freiwilligen ist zu 
unterstützen,
Löst dazu bitte einfach das talk mail Konstrukt auf, und arbeitet 
transparent unter einer OSM Identität im Webforum mit.
Spenden sind dem local chapter FOSSGIS zuzuweisen, dieser schüttet 
sicher projektbezogene Gelder wieder aus.


Wer unter dem Namen von OpenStreetMap agiert, muss hierbei auf 
weitestgehende Transparenz achten, und darf auch bei leiser Kritik nicht 
derart zimperlich reagieren, sondern hat seine Gebarung umfassend 
offenzulegen.


Mst. Johann Haag

Am 17.08.2020 um 19:35 schrieb Andreas via Talk-at 
mailto:talk-at@openstreetmap.org>>:


Am 16.08.20 um 23:15 schrieb Johann Haag:



Am 16.08.2020 um 22:39 schrieb scubbx 

>:

Der Österreichische Verrein hat die Kappen 2014 produziert, um die es
in der Anfrage von Simon Poole geht.
An wen hätte er sich sonst wenden sollen?




Man gründe also also einen Hobby Verein, genannt OpenStreetMap-Tirol,
gemeinnützigen Statuten Ehrensache. Dazu Tiroler OSM Kapperl. Einnahmen
nur im Umfang was wir auch tatsächlich ausgeben, keine Kunst. Fechten
nicht beim BEV und Gemeindebund, sondern aussschließlich bei Tiroler
Touristikern, wir sind ja gemeinnützig.
Künftig sämtliche OSM Belange mit Tirol Bezug an uns senden, garantierte
Reaktionszeit mal schauen (wir haben ja auch noch ganz viel anderes zu
tun), spätestens jedoch zur gesetzlich verpflichtend vorgeschriebenen
Jahreshauptversammlung.



Unglaublich wie du die Arbeit für OSM von Freiwilligen in den Schmutz
ziehst.OSM.at macht mehr als nur OSM-Kapperl. Wärst du 
in den letzten

Jahren auf einer Geo-Veranstaltung in Österreich gewesen, hättest du
dich persönlich an unserem Stand informieren können.

Mitglieder des Vereins nehmen teil an:
- AGIT
- Makerfaire Vienna
- Linuxtage / -wochen
- OSM Stammtische
- Mapathons

um nur ein paar der Veranstaltungen zu nennen. Im Gegensatz zu dir
versuchen wir mit anderen OSM Mappern oder Begeisterten in Kontakt zu
treten. Wir spielen uns nicht auf, dass wir die einzigen sind, die sich
um OSM kümmern.

Ich bitte daher in Zukunft auf Mails in dieser Form zu verzichten und
informiere dich bevor du unqualifiziert und unbelegte Behauptungen von
dir gibst.

Danke
Andreas


Grüsse, Mst. Johann Haag



Am 16.08.20 um 19:56 schrieb Johann Haag:



Am 16.08.2020 um 15:38 schrieb scubbx >:




Der Österreichische Verrein hat die Kappen 2014 produziert, um die
es in der Anfrage von Simon Poole geht.
An wen hätte er sich sonst wenden sollen?


Wie hat der Wiener Verein das finanziert, laut Statuten gibt es ja
keine Einnahmen. Ich möchte diesem Verein nun nichts unterstellen.
Hier gehört aber wesentlich mehr Transparenz hinein. OSM ist
inzwischen ein Ferrari.

Grüsse Mst. Johann Haag



Am 16.08.20 um 13:57 schrieb Johann Haag:

Österreich kann sich ja um eine eigene offizielle OpenStreetMap
Vertretung bemühen,
mir wurde vom Wiener Verein mitgeteilt, dass dieser nur eine lose
Vereinigung sei.
Sofern der Wiener Verein für offizielle Belange auf die Fossgis,
unseren local chapter verweist, sehe ich auch kein Problem. Eine
solche Erklärung fehlt aber auf dessen Webseite openstreetmap.at 



Wenn sich nun Simon Poole für offizielles,
https://lists.openstreetmap.org/pipermail/talk-at/2020-August/010645.html
an den Wiener Verein wendet, dann finde ich das ganz einfach falsch.
Der Wiener Verein hat aktuell nicht mehr Mandat als jeder andere
OSM- Stammtisch in Österreich.

Grüsse Mst. Johann Haag




Am 16.08.2020 um 10:40 schrieb Kevin Kofler
>:


Johann Haag wrote:

Es ist längst an der Zeit, dass man den Wiener Verein aus der Liste
https://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters

entfernt,
und den Domainopenstreetmap.at 
>

 mit
openstreetmap.de 
>

 zusammenführt.


Wieso soll Österreich von Deutschland aus verwaltet werden?
Österreich ist
ein unabhängiges Land und kein Teil von Deutschland! (Und die
kurze Zeit, in
der das anders war, wünscht sich hoffentlich keiner hier zurück!)

   Kevin Kofler


___
Talk-at mailing list
Talk-at@openstreetmap.org 

Re: [Talk-GB] New Bing Imagery

[Robert Whittaker (OSM lists)]

On Wed, 19 Aug 2020 at 15:36, SK53  wrote:
> This isn't necessarily true. If you open any OS Open Data product in QGIS one 
> is now confronted by a bewildering array of ways of converting from the OSGB 
> national grid co-ordinates to WGS84.
>
> The optimum one currently uses the 2015 file of detailed offset corrections 
> to the basic projection transformation. There was an earlier set of similar 
> data released in 2002. If one doesn't download this correction data then it 
> falls back on the basic transform using OSGB36 which can be anywhere between 
> 1 and 5 m off-true. In addition there has always been the slightly obscure 
> behaviour of OSGB projections specified in proj4 or WKT formats with respect 
> to the Helmert Transformation parameters (in early days of Open Data Chris 
> Hill & I found these were essential). At least part of the problem is that 
> EPSG:27700 appears to relate to several very slightly diverging projections, 
> whereas, for instance, Irish Grid changes are handled by EPSG:29001 through 
> EPSG:29003, and Swiss Grid CH1903 is EPSG:4149, CH1903+ is EPSG:4150 and the 
> newest CH1903+/LV95 is EPSG:2096.
>
> I don't know what transformation JOSM uses when reading EPSG:27700 so unless 
> one is very cautious it is not possible to be certain that one is anywhere 
> near the RMS 25 cm accuracy of OS data (especially as products, including 
> Boundary Line, may be partially generalised.

Perhaps this is what's causing the following problem for me then. I
GPS-surveyed a lot of the roads on my estate a few years ago when
aerial imagery wasn't so good. I've got GPS traces in OSM that
consistently follow the pavements on each side of the road and will
line up nicely with the aerial imagery if you put in the right
off-set. However, the required off-set for these traces is around 3m
out from the offset you need to make the OS OpenMap Local Functional
sites (as suggested above) line up, when I load the shapefile directly
in JOSM. This ~3m is very noticable when you have mapped buildings and
pavements sticking out into roads.

Perhaps it would be useful if someone could to do a correct
transformation of (e.g.) the OS OpenMap Local Functional Sites data to
a format and CRS that can be unambiguously read by JOSM, in order to
help our imagery alignment.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] National Cycle Network removal/reclassification

[Robert Whittaker (OSM lists)]

On Sat, 18 Jul 2020 at 14:49, Richard Fairhurst  wrote:
> Sustrans' own website mapping has just been updated to take account of this, 
> which you can see at https://osmaps.ordnancesurvey.co.uk/ncn . The dashed 
> lines are reclassified, while some sections have been removed entirely.
>
> It's not currently released under an open licence so not suitable for direct 
> inclusion into OSM. I will see if I can get permission for the data to be 
> used.

Sustrans' NCN data is available from
http://livingatlas-dcdev.opendata.arcgis.com/datasets/54a66fa3c15d4e118e085fbd9b141aae
as vector tiles under the ODbL. However, note that the "removed"
sections mostly won't be reflected on the ground yet. Also, the
dataset isn't perfect, as there's at least one bit near me where the
route Sustrans have is wrong. I think it's also likely that some of
the small gaps that have been created are inadvertent and will quickly
be filled back in as volunteers review the new network.

We also might need to think about our tagging, as there will now be
more levels of routes: Full NCN routes, other promoted named routes
that aren't on the NCN. How can we distinguish these in OSM?
network=ncn and network=rcn are typically used for national and
regional level routes rather than specifically the Sustrans NCN.

For anyone interested in working with the data, I'm wondering if
vector tiles is the most convenient format? Would a shapefile be
better for example? I was at Sustrans volunteer webinar last night,
and there was concern about getting various OSM-based maps and routers
updated. So if there's a more convenient data format for OSM mappers,
I think there's a good chance Sustrans would look in to it for us.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Street-name toids

[Robert Whittaker (OSM lists)]

On Wed, 12 Aug 2020 at 16:56, SK53  wrote:
> OpenRoads from the Ordnance Survey contains a field containing the toid for 
> the street name. I wonder if we should include these alongside usrn & uprn. 
> They may be more useful than either for gathering complex roads which share a 
> name.

I'd tend to see the TOIDs are just an internal ID used in OS MasterMap
and not something that there's much value in adding to OSM. I'd have
thought that that USRN should be a sufficient unique reference number
for highways. (Everything in OS MasterMap has a TOID, and actually I
think streets have two -- one for the centreline geometry, and one for
the bounding polygon. If we start adding TOIDs for streets, where
would we stop?)

However, from a practical point of view, if you want to check OSM for
completeness against OS Open Roads, then having the TOID in OSM would
be useful. But perhaps a better solution would be to persuade OS that
they should be including the USRNs in OS Open Roads -- as these are
now the promoted 'gold standard' open unique identifiers for streets.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Electric vehicle charging points

[Robert Whittaker (OSM lists)]

On Tue, 21 Jul 2020 at 23:12, Nick  wrote:
> Could the data be included in https://osm.mathmos.net/survey/ ?

I had a quick look at the National Charge Point Registry data a while
ago. I got as far as plotting a map showing both the OSM charge points
and those from the Registry:
https://osm.mathmos.net/chargepoint/progress/ . Unfortunately, the
Registry data seemed rather incomplete, and not always accurate. It
also wasn't clear exactly how to do matching between the two datasets.
I then got distracted by other things.

Due to the incompleteness of the Registry, there'd be no way to flag
OSM charge point objects that shouldn't be there. But if I could sort
out some way of matching between the two datasets, I would then be
able to add the charge points in the Registry that are "missing" in
OSM to https://osm.mathmos.net/survey/ .

-- 
Robert Whittaker

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

[Talk-GB] UPRN Locations Map

[Robert Whittaker (OSM lists)]

I'm not completely sure if/how we can best make use of the new OS
OpenData (UPRNs, USRNs and related links) in OpenStreetMap, but as a
first step I've set up a quick slippy map with the UPRN locations
shown:

https://osm.mathmos.net/addresses/uprn/ (zoom in to level 16 to show the data)

The UPRN dataset literally just contains the UPRN number and its
coordinates (both OS National Grid and WGS lat/lon). There are some
additional linking datasets that link these ids to other ids (e.g.
USRNs, TOIDs). But no address information is available directly. (You
may be able to get street names by matching to OS Open Roads via TOIDs
though. Coupled with Code-Point Open, you might be able to assign
quite a few postcodes in cases where there's only one unit for a whole
street.)

The UPRN data has already helped me find a mapping error I made
locally though -- it looks like I'd accidentally missed drawing a
house outline from aerial imagery, and also classified a large garage
a few doors down as a house. The two errors cancelled out when the
houses were numbered sequentially, so I didn't notice until now. Today
though I spotted a UPRN marker over some blank space on the map, and
no marker over the mapped house that's probably a garage.

Now a few initial thoughts on the data that I've explored so far:

I believe that the UPRNs are assigned by local authorities, so
conventions may vary from place to place. I don't know who actually
assigns the coordinates (authority or OS). Looking at those for rows
of houses around me, they don't seem to have been automatically given
coordinates from the house footprint, it looks more like someone
manually clicking on a map.

The UPRN dataset should include all addressable properties. It is also
ahead of reality in some places, as it includes locations for houses
on a new development near me that have yet to be built yet. For blocks
of apartments/flats, the UPRN nodes may all have the same coordinates
or may be displaced from each other, possibly in an artificial manner.

Other objects also appear to have UPRNs. Likely things I've noticed so
far include: car parks, post boxes, telephone boxes (even after
they've been removed), electricity sub-stations, roads and recorded
footpaths (the UPRN locations seem to be at one end of the street, so
usually lie at a junction), recreation grounds / play areas,
floodlight poles (around sports pitches), and allotments. There's no
information about the object type in the UPRN data unfortunately.

Anyway, I hope some of this is useful / interesting. I hope to be on
the OSMUK call on Saturday to discuss things further. Best wishes,

Robert.

-- 
Robert Whittaker
https://osm.mathmos.net/

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

Re: [Talk-GB] Land Registry INSPIRE data - 1 July OGL release

[Robert Whittaker (OSM lists)]

On Fri, 26 Jun 2020 at 20:50, Rob Nickerson  wrote:
> Looks like 1 July will be a big open data release day. Not only do we get the 
> USRN and UPRN data, but the land registry data will also be released:
>
> https://www.gov.uk/government/news/inspire-data-to-be-shared-under-open-terms
>
> Should we attempt to coordinate something to prevent a mixture of uses across 
> those OSMers who may want to do something with this date?

I'm not sure about the INSPIRE polygons, but for USRNs and UPRNs, I'd
imagine it will be useful to add these identifiers to the appropriate
OSM objects. (I can see doing this being very useful in terms or
measuring completeness in OSM, and finding missing streets/properties
to add.) To that end, we should agree on a tagging to use for these
references. I started a conversation at
https://lists.openstreetmap.org/pipermail/talk-gb/2020-April/024383.html
about this. My preference was for ref:GB:uprn and ref:GB:usrn, though
I think there were some people arguing for the simpler ref:uprn and
ref:usrn.

Does anyone have any details of the specifications of the UPRN, USRN
or INSPIRE releases? For example, I'm assuming we won't get the
addresses with the UPRNs, just the coordinates, but will they be
linked to streets (via USRNs) and will each include a type/class? Will
we get street names with the USRNs? For the INSPIRE polygons will we
just get the INSPIRE ID, or will it be linked to LAnd Registry title
numbers or UPRNs?

(Depending on exactly what we get, it could be very useful for adding
and checking postcodes. e.g. if we have all the UPRNs that are tied to
a single USRN, and we know there's only one postcode centroid on any
of them, it's a good bet those properties all have the same postcode.)

Robert.

-- 
Robert Whittaker

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

Re: [OSM-talk-fr] méthode et outil pour intégrer l'opendata (était: Import de points d'eau incendie en Saône-et-Loire)

[Antonin Delpeuch (lists)]

Juste pour mettre les choses au clair: il ne s'agit pas de mon outil ;)

Antonin

On 31/05/2020 09:46, Marc M. wrote:
> Bonjour,
>
> je ne souhaite pas "nous tirer dans les pattes"
> au contraire, je pense que tu poses le bon diagnostic :
> un outil pour intégrer l'opendata sans basculer entre plusieurs outils.
> mais je pense étrangement ton outil n'est pas adapté pour cela.
>
> je pense qu'il y a 3 cas :
>
> 1) les objets dont la position existe dans osm et auquel on ajoute des
> infos opendata : à mon avis on n'a pas besoin d'un contributeur
> qui fait un clic par objet sans aucune plus-value.
> ex : il y une borne très proche dans osm et dans l'opendata.
> l'opendata dit operator=A. c'est quoi la plus-value de le faire
> à la main ? à mon avis on fait mieux de faire une procédure pour
> importer tout cette donnée en une fois.
>
> 2) l'objet n'existe pas dans osm et la position de l'opendata n'est pas
> bonne. ton outil ne permettant pas de voir la borne, il va falloir
> ouvrir un autre outil, ce qui est donc l'exact contraire à ton but
> de n'avoir un outil ne nécessitant pas de basculer avec un autre.
>
> 2a) si on a une photo libre de l'endroit. à ce moment là une mission
> pic4review serrait bien adapté. encore mieux si elle peux récupérer
> toutes les points opendata sans sortir de l'outil. histoire justement
> de rester dans un seul outil.
> https://pic4review.pavie.info/#/mission/copy
> mission de type "intégrating fire hydrant"
>
> 2b) on n'a pas de photo libre de l'endroit. il faudra aller voir
> sur le terrain, c'est en ce sens que Vespucci est adapté.
> surtout qu'il permet de se connecter sur osmose, donc avoir
> tout, tout en restant dans un seul outil.
> il manque juste l'équivalent ios de Vespucci (dans le sens
> un éditeur osm connectable sur osmose, afin de valider
> la position sur le terrain)
>
> Cordialement,
> Marc
>
>
> Le 30.05.20 à 14:30, Antonin Delpeuch (lists) a écrit :
>> L'outil peut être utile pour intégrer toutes sortes de jeux de données:
>> il n'est évidemment pas conçu spécifiquement pour les PEI comme tu l'as
>> remarqué.
>>
>> Dans le cas spécique des PEI, c'est utile pour un contributeur qui
>> souhaite ajouter des métadonnées à des PEIs repérés sur le terrain,
>> qu'ils aient déjà des nœuds correspondant dans OSM ou pas.
>>
>> L'absence de dépendance à un éditeur externe est un gros plus pour moi,
>> car le passage répété entre les deux a un coût vraiment non-négligeable.
>>
>> Je pense que c'est bien de respecter la diversité des approches et des
>> outils, évitons de nous tirer dans les pattes…
>>
>> Antonin
>>
>> On 30/05/2020 11:21, Marc M. wrote:
>>> Bonjour,
>>>
>>> je prend mon clavier pour reposer la question tant évitée :
>>> la position est suposée mauvaise au point de ne pas vouloir d'import.
>>> et l'imagerie sat ne permet pas de voir la borne,
>>> du coup que fait le contributeur avec sa souris ?
>>>
>>> le positionement de ton outil m'échappe.
>>>
>>> Cordialement,
>>> Marc qui penche pour osmose+pic4review+vespucci
>>>
>>> Le 30.05.20 à 11:51, Nicolas Bétheuil a écrit :
>>>> Et bah voilà 12000 points de chargé
>>>>
>>>> amis contributeur, à vos souris
>>>>
>>>>
>>>>
>>>> Le ven. 29 mai 2020 à 22:21, Antonin Delpeuch (lists)
>>>> mailto:li...@antonin.delpeuch.eu>> a écrit :
>>>>
>>>> Salut Nicolas,
>>>>
>>>> Voilà la version complète:
>>>>
>>>> http://pintoch.ulminfo.fr/pei_sdis71.osm.geojson
>>>>
>>>> Antonin
>>>>
>>>> On 29/05/2020 17:07, Nicolas Bétheuil wrote:
>>>>> Les évolutions / correctifs avancent. Je pousse régulièrement.
>>>>> Écrivez moi directement, je verrais si je fais une diffusion
>>>>> spécifique pour vous gardez informé des nouveautés.
>>>>>
>>>>> Christian a ajouté od2osm au proxy IGN ! Merci !
>>>>>
>>>>> @Jean-Yvon j'ai des mails qui reviennent, les machinent veulent
>>>>> plus qu'on cause ensemble, je te propose de continuer en issue github
>>>>> @Antonin Le jeu de données que tu m'avais envoyé avait moins de 90
>>>>> points, loin des 12 000 points que tu avais évoqué.
>>>>>
>>>>> Le mer. 27 mai 2020 à 12:02, Yves P. >>>> <mailto:yves.prat...@gmail.com>> a écrit :
>>>>>
>>&

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire

[Antonin Delpeuch (lists)]

L'outil peut être utile pour intégrer toutes sortes de jeux de données:
il n'est évidemment pas conçu spécifiquement pour les PEI comme tu l'as
remarqué.

Dans le cas spécique des PEI, c'est utile pour un contributeur qui
souhaite ajouter des métadonnées à des PEIs repérés sur le terrain,
qu'ils aient déjà des nœuds correspondant dans OSM ou pas.

L'absence de dépendance à un éditeur externe est un gros plus pour moi,
car le passage répété entre les deux a un coût vraiment non-négligeable.

Je pense que c'est bien de respecter la diversité des approches et des
outils, évitons de nous tirer dans les pattes…

Antonin

On 30/05/2020 11:21, Marc M. wrote:
> Bonjour,
>
> je prend mon clavier pour reposer la question tant évitée :
> la position est suposée mauvaise au point de ne pas vouloir d'import.
> et l'imagerie sat ne permet pas de voir la borne,
> du coup que fait le contributeur avec sa souris ?
>
> le positionement de ton outil m'échappe.
>
> Cordialement,
> Marc qui penche pour osmose+pic4review+vespucci
>
> Le 30.05.20 à 11:51, Nicolas Bétheuil a écrit :
>> Et bah voilà 12000 points de chargé
>>
>> amis contributeur, à vos souris
>>
>>
>>
>> Le ven. 29 mai 2020 à 22:21, Antonin Delpeuch (lists)
>> mailto:li...@antonin.delpeuch.eu>> a écrit :
>>
>> Salut Nicolas,
>>
>> Voilà la version complète:
>>
>> http://pintoch.ulminfo.fr/pei_sdis71.osm.geojson
>>
>> Antonin
>>
>> On 29/05/2020 17:07, Nicolas Bétheuil wrote:
>>> Les évolutions / correctifs avancent. Je pousse régulièrement.
>>> Écrivez moi directement, je verrais si je fais une diffusion
>>> spécifique pour vous gardez informé des nouveautés.
>>>
>>> Christian a ajouté od2osm au proxy IGN ! Merci !
>>>
>>> @Jean-Yvon j'ai des mails qui reviennent, les machinent veulent
>>> plus qu'on cause ensemble, je te propose de continuer en issue github
>>> @Antonin Le jeu de données que tu m'avais envoyé avait moins de 90
>>> points, loin des 12 000 points que tu avais évoqué.
>>>
>>> Le mer. 27 mai 2020 à 12:02, Yves P. >> <mailto:yves.prat...@gmail.com>> a écrit :
>>>
>>>> Les "name" ont été enlevés du jeu de données et l 'outil
>>>> affiche maintenant soit name soit ref (en fonction de ce qui
>>>> existe)
>>>> J'ai ajouté le fond de carte BD Ortho
>>> Merci :)
>>>
>>>>  (j'ai laissé un mot sur le forum pour autorisé od2osm sur le
>>>> proxy
>>>> 
>>>> https://forum.openstreetmap.fr/viewtopic.php?f=5=4715=19681#p19681)
>>> ici ça marche aussi ;)
>>>
>>> Pour info, MyOSMatic (maposmatic) sort des carte
>>> <https://maposmatic.osm-baustelle.de/maps/116513> des PEIs :
>>> le résultat est plutôt bien :)
>>> Il faut revoir la taille des réserves incendie et des DAE, et
>>> éventuellement l'adapter avec les symboles utilisés en France.
>>>
>>> __
>>> Yves
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


pEpkey.asc
Description: application/pgp-keys
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire (osm: message 16 of 20)

[Antonin Delpeuch (lists)]

Salut Nicolas,

Voilà la version complète:

http://pintoch.ulminfo.fr/pei_sdis71.osm.geojson

Antonin

On 29/05/2020 17:07, Nicolas Bétheuil wrote:
> Les évolutions / correctifs avancent. Je pousse régulièrement.
> Écrivez moi directement, je verrais si je fais une diffusion
> spécifique pour vous gardez informé des nouveautés.
>
> Christian a ajouté od2osm au proxy IGN ! Merci !
>
> @Jean-Yvon j'ai des mails qui reviennent, les machinent veulent plus
> qu'on cause ensemble, je te propose de continuer en issue github
> @Antonin Le jeu de données que tu m'avais envoyé avait moins de 90
> points, loin des 12 000 points que tu avais évoqué.
>
> Le mer. 27 mai 2020 à 12:02, Yves P.  > a écrit :
>
>> Les "name" ont été enlevés du jeu de données et l 'outil affiche
>> maintenant soit name soit ref (en fonction de ce qui existe)
>> J'ai ajouté le fond de carte BD Ortho
> Merci :)
>
>>  (j'ai laissé un mot sur le forum pour autorisé od2osm sur le
>> proxy
>> https://forum.openstreetmap.fr/viewtopic.php?f=5=4715=19681#p19681)
> ici ça marche aussi ;)
>
> Pour info, MyOSMatic (maposmatic) sort des carte
>  des PEIs : le
> résultat est plutôt bien :)
> Il faut revoir la taille des réserves incendie et des DAE, et
> éventuellement l'adapter avec les symboles utilisés en France.
>
> __
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


pEpkey.asc
Description: application/pgp-keys
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire

[Antonin Delpeuch (lists)]

On 23/05/2020 23:30, deuzeffe wrote:
> Le 23/05/2020 à 21:24, Antonin Delpeuch (lists) a écrit :
> 
>> Sinon ça me semble difficile de vendre Osmose comme un outil adapté pour
>> l'intégration de jeux de données : c'est clairement un très bon outil de
>> validation pour les données existantes, mais c'est une tâche différente.
> 
> Euh... Tu préciser ? Il me semble que Osmose marche sur deux jambes :
> l'assurance qualité (QA) et l'intégration OD.
> 
> Enfin, c'est comme ça que Fred le présente. Et pour l'utiliser (Osmose,
> pas Fred !), il me semble bien avoir joué avec les deux aspects d'Osmose.
> 

C'est juste une impression d'utilisateur naif à chaud. Je me rends bien
compte que rendre l'expérience utilisateur plus simple représente du
travail. Mais ça vaudrait vraiment le coup.

Je trouve qu'od2osm donne un bon exemple: permettre d'ajuster la
position du point issue du jeu de données directement dans l'outil, puis
son ajout dans le changeset actuel. Du même coup, marquer le problème
comme résolu.

Bref, essayer de minimiser le nombre de clics (et de dépendances à des
outils externes comme JOSM) pour accélérer l'import.

Je trouve qu'en l'état, on sent que l'outil est conçu d'abord pour faire
de l'assurance qualité, et il a été réutilisé pour faire de
l'intégration de données après coup.

Encore une fois ce n'est pas pour minimiser le travail de Fred - Osmose
est un outil formidable !

Antonin

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

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire

[Antonin Delpeuch (lists)]

On 23/05/2020 21:47, Marc M. wrote:
> 
> la question est pour pintoch dans ce cas :)
> https://www.openstreetmap.org/changeset/85656627
> 

Pintoch connait ce coin-là comme sa poche et est tout à fait en mesure
de juger du placement correct des points créés dans ce changeset :)

Antonin

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

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire

[Antonin Delpeuch (lists)]

On 23/05/2020 21:33, Marc M. wrote:
> Le 23.05.20 à 21:24, Antonin Delpeuch (lists) a écrit :
>> On 23/05/2020 18:09, Marc M. wrote:
>>> ja'i du raté l'info de ce que tu fais pour pouvoir intégrer
>>> ces bornes comparé à un import ?
>>
>> La précision des coordonnées est jugée trop mauvaise 
>> pour importer ça directement
> 
> cette partie là j'avais compris :)
> mais du coup que fais-tu pour améliorer ?
> ne voyant pas le point d'eau sur l'ortho des points créés,
> je me demandais comment tu rectifiais la position pour créer
> les nouveaux points.
> 

Il n'y a aucune rectification. Je ne crée pas les nouveaux points, je
mets juste le jeu de données dans Osmose / od2osm pour que d'autres
puissent créer les points via ces outils, en les positionnant au bon
endroit, dans des lieux qu'ils connaissent.

Antonin

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

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire (osm: message 16 of 20)

[Antonin Delpeuch (lists)]

On 23/05/2020 21:19, Yves P. wrote:
> @Antonin et Nicolas
> D'où sort *name=PI CLUNY 19* ?
> Il y a une référence dans les données ouvertes : ID_SDIS.

C'est moi qui l'ai rajouté en tant que nom pour od2osm parce que l'outil
a besoin d'un nom sur chaque point. Je ne l'ai pas ajouté dans la
version publique de mon script parce que je ne pense pas que les gens
veuillent ajouter des noms aux poteaux incendie en général…

Antonin

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

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire

[Antonin Delpeuch (lists)]

On 23/05/2020 18:09, Marc M. wrote:
> ja'i du raté l'info de ce que tu fais pour pouvoir intégrer
> ces bornes comparé à un import ?

La précision des coordonnées est jugée trop mauvaise pour importer ça
directement, d'où Osmose ou d'autres outils.

> 
> Le 23.05.20 à 17:06, Antonin Delpeuch (lists) a écrit :
>> La possibilité d'ajouter les éléments manquants facilement depuis 
>> l'outil est un vrai plus - je ne vois pas
>> comment faire ça depuis Osmose
> 
> exemple :
> https://osmose.openstreetmap.fr/fr/map/#source=412054=8360=4=17=50.556896=2.899575=3==
> 
> clic sur "fix-josm" te l'ajoute en un clic dans josm

Ok mais c'est super lourd, ça nécessite d'avoir JOSM qui tourne en
parallèle et il faut passer d'un outil à l'autre pour ajuster la
position du point, marquer le problème comme résolu, etc.

Osmose permet déjà de modifier les tags de points existants sans quitter
l'outil, ça me semblerait naturel de pouvoir créer des nouveaux points
d'une façon similaire.

Sinon ça me semble difficile de vendre Osmose comme un outil adapté pour
l'intégration de jeux de données : c'est clairement un très bon outil de
validation pour les données existantes, mais c'est une tâche différente.

Antonin

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

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire

[Antonin Delpeuch (lists)]

Correction: la conflation marche malgré l'absence de noms (chouette !)
sauf dans certains cas (peut-être à cause de limites de nombre de
requêtes ?)

Autre détail: quand on ajoute un POI au changeset, il faut un certain
nombre de clics pour revenir à la liste des points à traiter dans la
quête. Ça serait pratique d'y revenir directement, ou même mieux, de
passer à un autre point à traiter.

En tout cas super outil !

Antonin

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

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire (osm: message 16 of 20)

[Antonin Delpeuch (lists)]

Merci !

Problèmes rencontrés:
- le jeu de donénes entier pour tout le département est rejeté car trop gros
- sans "id" dans le geojson, le fichier est juste rejeté comme geojson
invalide sans plus de détails: des messages d'erreurs explicites
seraient appréciés
- l'appli requiert un nom pour chaque POI à ajouter, et utilise ça pour
la conflation, hors les points d'eau incendie n'utilisent généralement
pas cet attribut, donc la conflation ne marche pas
- visualiser la liste des points à intégrer comme une liste de noms
n'est pas très utile, ça serait mieux de les voir sur une carte

À part ça, j'aime l'idée ! La possibilité d'ajouter les éléments
manquants facilement depuis l'outil est un vrai plus - je ne vois pas
comment faire ça depuis Osmose (ce que je trouve très bizarre… j'ai dû
louper quelque-chose ?)

Antonin

On 21/05/2020 22:50, Nicolas Bétheuil wrote:
> @Antonin: C'est fait
> http://od2osm.cleverapps.io/#/quests/add
> 
> ne pas hésitez à poser des questions si ce n'est pas clair
> 
> Salutations
> 
> Le mer. 20 mai 2020 à 19:48, Nicolas Bétheuil  <mailto:nbethe...@free.fr>> a écrit :
> 
> oui y a 0 doc, la peinture est pas sèche encore c'est tout neuf. 
> 
> à ma connaissance comme ça dépends de chaque jeu de données un
> script sale fera très bien le travail. 
> 
> vous pouvez voir ce que j'ai fait pour le premier jeu de donner sur 
> 
> https://github.com/wadouk/opendata-paris-commerces-ouvert-covid19-vers-osm/
> 
> et par
> exemple 
> https://github.com/wadouk/opendata-paris-commerces-ouvert-covid19-vers-osm/blob/master/taf.sh
> qui fait téléchargement conversion envoie. 
> 
> le coeur est du nodejs mais c'est à votre main. 
> 
> j'ai des changements à faire avant que vous envoyez, le temps pour
> vous de faire la conversion. 
> 
> sinon, pour le premier jeu de données je peux aussi regarder... mais
> j'ai aussi du boulot à faire pour faire que ce soit possible. 
> 
> Le mer. 20 mai 2020 à 19:31, Antonin Delpeuch (lists)
> mailto:li...@antonin.delpeuch.eu>> a écrit :
> 
> On 20/05/2020 19:10, Nicolas Bétheuil wrote:
> > sinon y a od2osm ;-p
> 
> Ça a l'air sympa, mais c'est pareil, je ne vois pas de
> documentation des
> étapes nécessaires pour contribuer un jeu de données :)
> 
> >
> > @antonin quelques compétences en développement ?
> 
> Oui mais j'ai pas beaucoup d'espace libre dans ma timeline github :(
>  
> >
> > sont-ce des nodes ? si oui c'est cool.
> 
> Oui, les points d'eau incendie sont des points, aléluia :)
> 
> >
> > pour une première version : transformer le jeu de données en
> geojson
> > osmifié (avec les tags qui vont bien dans les properties des
> feature) et
> > un simple curl sur od2osm et hop les contributeurs peuvent se
> partager
> > le boulot.
> 
> Est-ce qu'il y a des outils bien fichus pour osmifier du
> geojson, ou on
> fait un script dégoutant dans son coin ?
> 
> Antonin
> 
> >
> > Le mer. 20 mai 2020 à 16:26, Antonin Delpeuch (lists)
> > mailto:li...@antonin.delpeuch.eu>
> <mailto:li...@antonin.delpeuch.eu
> <mailto:li...@antonin.delpeuch.eu>>> a écrit :
> >
> >     Merci beaucoup ! La configuration de la source pour la
> Suisse est
> >     séduisante, avec son format complètement déclaratif - ça a
> l'air propre.
> >
> >     Je vais attendre que le processus soit plus documenté pour
> utiliser
> >     Osmose (ou même rendu plus simple si un système générique
> pour tous les
> >     SDIS français est envisageable).
> >
> >     Antonin
> >
> >     On 20/05/2020 16:04, Frédéric Rodrigo wrote:
> >     > La doc est là:
> >     > https://github.com/osm-fr/osmose-backend/tree/master/doc
> >     > Mais le chapitre que tu veux n'est pas encore écrit.
> >     >
> >     > Mais il y a des précédents
> >     > https://github.com/osm-fr/osmose-backend/issues/413
> >     > https://github.com/osm-fr/osmose-backend/issues/543
> >     >
> >     > Il y a déjà eu une analyse pour faire ça en Suisse (code
> source non
> >     > maintenu, à comparer avec celles toujours en cours
> d'utilisation)
> &

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire

[Antonin Delpeuch (lists)]

Suite à tous vos commentaires il semble que quelque soit la méthode
d'import, la première étape est de convertir les données du format
Afigeo aux tags OSM, en suivant la correspondance établie ici:
https://wiki.openstreetmap.org/wiki/FR:Tag:emergency%3Dfire_hydrant#Correspondance_avec_le_mod.C3.A8le_PEI_de_l.27Afigeo

Voilà une proposition de script dégoûtant pour ce faire:
https://gist.github.com/wetneb/a39aaacb4526e67b93580185fc372320

Il me semble que ça serait bien d'inclure les identifiants donnés par le
SDIS aux points d'eau, pour faciliter les mises à jour (et parce que le
SDIS est l'organisme pertinent pour émettre ces identifiants). Quel tag
utiliser pour ça ? Comme les identifiants ne sont uniques que dans un
département donné, j'ai pensé à "sdis71:id", ce qui donnerait
quelque-chose comme ça:

{
"emergency": "fire_hydrant",
"fire_hydrant:type": "pillar",
"fire_hydrant:diameter": 100,
"ref": "2",
"survey:date": "2019-05-02",
"operator": "VEOLIA",
"sdis71:id": "PI PIEVA 2",
"source": "SDIS 71"
}

Qui est la traduction de:

{
"INSEE": 71468,
"ID_SDIS": "PI PIEVA 2",
"NOM_GEST": "VEOLIA",
"REF_TERR": 2,
"TYPE_PEI": "PI",
"DIAM_PEI": 100,
"STATUT": "Communal",
"DEBIT": 60,
"DATE_CT": "2018/06/29 00:00:00",
"DATE_RO": "2019/05/02 00:00:00"
}

Dites-moi ce que vous en pensez,

Antonin

On 19/05/2020 13:42, Antonin Delpeuch (lists) wrote:
> Bonjour,
> 
> Je souhaiterais importer dans OpenStreetMap des points d'eau incendie
> (piliers, bouches et autres) à partir d'un jeu de données publié le mois
> dernier par le SDIS de Saône-et-Loire (sous Licence Ouverte).
> 
> https://trouver.ternum-bfc.fr/dataset/points-deau-incendie-repertories-en-saone-et-loire
> 
> Je compte évidemment dédoublonner ces points avec ceux qui sont déjà
> présents (environ 700 sur 12851):
> 
> https://overpass-turbo.eu/s/U9C
> 
> L'import suivrait les conventions décrites ici:
> 
> https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dfire_hydrant
> 
> Qu'en pensez-vous ? Quels sont les pièges à éviter ?
> 
> Merci pour vos retours sur ce projet !
> 
> Antonin
> 
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 


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

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire (osm: message 16 of 20)

[Antonin Delpeuch (lists)]

On 20/05/2020 19:10, Nicolas Bétheuil wrote:
> sinon y a od2osm ;-p

Ça a l'air sympa, mais c'est pareil, je ne vois pas de documentation des
étapes nécessaires pour contribuer un jeu de données :)

> 
> @antonin quelques compétences en développement ?

Oui mais j'ai pas beaucoup d'espace libre dans ma timeline github :(
 
> 
> sont-ce des nodes ? si oui c'est cool.

Oui, les points d'eau incendie sont des points, aléluia :)

> 
> pour une première version : transformer le jeu de données en geojson
> osmifié (avec les tags qui vont bien dans les properties des feature) et
> un simple curl sur od2osm et hop les contributeurs peuvent se partager
> le boulot.

Est-ce qu'il y a des outils bien fichus pour osmifier du geojson, ou on
fait un script dégoutant dans son coin ?

Antonin

> 
> Le mer. 20 mai 2020 à 16:26, Antonin Delpeuch (lists)
> mailto:li...@antonin.delpeuch.eu>> a écrit :
> 
> Merci beaucoup ! La configuration de la source pour la Suisse est
> séduisante, avec son format complètement déclaratif - ça a l'air propre.
> 
> Je vais attendre que le processus soit plus documenté pour utiliser
> Osmose (ou même rendu plus simple si un système générique pour tous les
> SDIS français est envisageable).
> 
> Antonin
> 
> On 20/05/2020 16:04, Frédéric Rodrigo wrote:
> > La doc est là:
> > https://github.com/osm-fr/osmose-backend/tree/master/doc
> > Mais le chapitre que tu veux n'est pas encore écrit.
> >
> > Mais il y a des précédents
> > https://github.com/osm-fr/osmose-backend/issues/413
> > https://github.com/osm-fr/osmose-backend/issues/543
> >
> > Il y a déjà eu une analyse pour faire ça en Suisse (code source non
> > maintenu, à comparer avec celles toujours en cours d'utilisation)
> >
> 
> https://github.com/osm-fr/osmose-backend/blob/master/analysers/disabled/analyser_merge_hydrant_point_CH_lausanne.py
> >
> >
> >
> >
> > Le 20/05/2020 à 15:29, Antonin Delpeuch (lists) a écrit :
> >> Merci Jean-Yvon, tu confirmes mes doutes.
> >>
> >> Comment faut-il s'y prendre pour envoyer le jeu de données dans
> Osmose ?
> >> Je ne trouve pas de documentation à ce sujet.
> >>
> >> Je vais aussi regarder du côté du greffon todolist.
> >>
> >> Antonin
> >>
> >> On 19/05/2020 22:35, osm.sanspourr...@spamgourmet.com
> <mailto:osm.sanspourr...@spamgourmet.com> wrote:
> >>> Tu vas polluer, c'est sûr.
> >>>
> >>> C'est pourquoi en France on préfère passer par Osmose pour que
> les gens
> >>> repositionnent.
> >>>
> >>> Tu peux aussi exclure les points qui tombent sur du bâti et par
> exemple
> >>> utiliser le greffon todolist de JOSM pour les importer à un
> endroit plus
> >>> réaliste.
> >>>
> >>> Tu peux aussi ajouter un fixme=repositionner, précision X m
> >>>
> >>> si tu ne sais pas le faire mais que tu as une bonne estimation
> de X avec
> >>> le jeu de données (à intégrer par département/caserne si c'est le
> >>> critère pour expliquer la précision).
> >>>
> >>> Mes 2 c€.
> >>>
> >>> Jean-Yvon
> >>>
> >>> Le 19/05/2020 à 21:16, Antonin Delpeuch lists -
> >>> li...@antonin.delpeuch.eu <mailto:li...@antonin.delpeuch.eu> a
> écrit :
> >>>> Ou
> >>>> est-ce que je vais polluer la carte avec des points imprécis
> dont tout
> >>>> le monde se fiche ? C'est pas clair pour moi…
> >>>>
> >>>> Antonin
> >>>
> >>> ___
> >>> Talk-fr mailing list
> >>> Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
> >>> https://lists.openstreetmap.org/listinfo/talk-fr
> >>
> >> ___
> >> Talk-fr mailing list
> >> Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
> >> https://lists.openstreetmap.org/listinfo/talk-fr
> >
> >
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 


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

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire (osm: message 16 of 20)

[Antonin Delpeuch (lists)]

Merci beaucoup ! La configuration de la source pour la Suisse est
séduisante, avec son format complètement déclaratif - ça a l'air propre.

Je vais attendre que le processus soit plus documenté pour utiliser
Osmose (ou même rendu plus simple si un système générique pour tous les
SDIS français est envisageable).

Antonin

On 20/05/2020 16:04, Frédéric Rodrigo wrote:
> La doc est là:
> https://github.com/osm-fr/osmose-backend/tree/master/doc
> Mais le chapitre que tu veux n'est pas encore écrit.
> 
> Mais il y a des précédents
> https://github.com/osm-fr/osmose-backend/issues/413
> https://github.com/osm-fr/osmose-backend/issues/543
> 
> Il y a déjà eu une analyse pour faire ça en Suisse (code source non
> maintenu, à comparer avec celles toujours en cours d'utilisation)
> https://github.com/osm-fr/osmose-backend/blob/master/analysers/disabled/analyser_merge_hydrant_point_CH_lausanne.py
> 
> 
> 
> 
> Le 20/05/2020 à 15:29, Antonin Delpeuch (lists) a écrit :
>> Merci Jean-Yvon, tu confirmes mes doutes.
>>
>> Comment faut-il s'y prendre pour envoyer le jeu de données dans Osmose ?
>> Je ne trouve pas de documentation à ce sujet.
>>
>> Je vais aussi regarder du côté du greffon todolist.
>>
>> Antonin
>>
>> On 19/05/2020 22:35, osm.sanspourr...@spamgourmet.com wrote:
>>> Tu vas polluer, c'est sûr.
>>>
>>> C'est pourquoi en France on préfère passer par Osmose pour que les gens
>>> repositionnent.
>>>
>>> Tu peux aussi exclure les points qui tombent sur du bâti et par exemple
>>> utiliser le greffon todolist de JOSM pour les importer à un endroit plus
>>> réaliste.
>>>
>>> Tu peux aussi ajouter un fixme=repositionner, précision X m
>>>
>>> si tu ne sais pas le faire mais que tu as une bonne estimation de X avec
>>> le jeu de données (à intégrer par département/caserne si c'est le
>>> critère pour expliquer la précision).
>>>
>>> Mes 2 c€.
>>>
>>> Jean-Yvon
>>>
>>> Le 19/05/2020 à 21:16, Antonin Delpeuch lists -
>>> li...@antonin.delpeuch.eu a écrit :
>>>> Ou
>>>> est-ce que je vais polluer la carte avec des points imprécis dont tout
>>>> le monde se fiche ? C'est pas clair pour moi…
>>>>
>>>> Antonin
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 


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

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire (osm: message 16 of 20)

[Antonin Delpeuch (lists)]

Merci Jean-Yvon, tu confirmes mes doutes.

Comment faut-il s'y prendre pour envoyer le jeu de données dans Osmose ?
Je ne trouve pas de documentation à ce sujet.

Je vais aussi regarder du côté du greffon todolist.

Antonin

On 19/05/2020 22:35, osm.sanspourr...@spamgourmet.com wrote:
> Tu vas polluer, c'est sûr.
> 
> C'est pourquoi en France on préfère passer par Osmose pour que les gens
> repositionnent.
> 
> Tu peux aussi exclure les points qui tombent sur du bâti et par exemple
> utiliser le greffon todolist de JOSM pour les importer à un endroit plus
> réaliste.
> 
> Tu peux aussi ajouter un fixme=repositionner, précision X m
> 
> si tu ne sais pas le faire mais que tu as une bonne estimation de X avec
> le jeu de données (à intégrer par département/caserne si c'est le
> critère pour expliquer la précision).
> 
> Mes 2 c€.
> 
> Jean-Yvon
> 
> Le 19/05/2020 à 21:16, Antonin Delpeuch lists -
> li...@antonin.delpeuch.eu a écrit :
>> Ou
>> est-ce que je vais polluer la carte avec des points imprécis dont tout
>> le monde se fiche ? C'est pas clair pour moi…
>>
>> Antonin
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire

[Antonin Delpeuch (lists)]

On 19/05/2020 23:37, Yves P. wrote:
>> Mon habitude de dire "pilier" vient probablement du fait que c'est le
>> terme utilisé par iD en version française (pour traduire la valeur
>> "pillar") - ça vaudrait le coup d'être corrigé. Si tu sais comment
>> résoudre ça (et probablement d'autres problèmes de terminologie)
>> n'hésite pas !
> Il faut utiliser Transifex
> : https://www.transifex.com/openstreetmap/id-editor/
> 
> Pour plus d'infos :
> https://github.com/openstreetmap/iD/blob/develop/CONTRIBUTING.md#translating

Super! Je te laisse t'en occuper ? Personellement je n'ai pas de
préférence particulière sur les termes à utiliser.

Antonin

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

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire

[Antonin Delpeuch (lists)]

On 19/05/2020 22:16, Yves P. wrote:
> Préalable : utiliser les bons termes :)

Mon habitude de dire "pilier" vient probablement du fait que c'est le
terme utilisé par iD en version française (pour traduire la valeur
"pillar") - ça vaudrait le coup d'être corrigé. Si tu sais comment
résoudre ça (et probablement d'autres problèmes de terminologie)
n'hésite pas !

> 
> Sources :
> Référentiel national de la défense extérieure contre l’incendie
> 
> En cherchant des documents avec le terme DECI, on trouve les
> réglementations départementales avec les usages locaux.
> (La problématique étant différente au nord et au sud de la France, dans
> les DOM…)
> 
>> Ceci dit j'ai trouvé un pilier incendie qui n'est pas
>> dans leur jeu de données.
> Dans mon département, le SIG ne référence pas les PEI désaffectés.
> Les poteaux sont souvent repeint en verts pour symboliser une borne de
> puisage (arrosage des espaces verts).
> Mais ça dépend des communes et de leurs moyens.

Ok, dans mon cas le poteau a l'air tout à fait en état de "marche" au
même titre que n'importe quel autre, mais je ne suis clairement pas un
expert…

> 
>> (il
>> y a aussi des endroits louches dans OSM, comme deux piliers très proches
>> par exemple).
> Peut-être un doublon dû à un import ?
> Sur le terrain j'ai trouvé un poteau désaffecté (non référencé) à 1 m
> d'un autre "moderne" (référencé).
> 
>> Ce qui m'inquiète plus c'est qu'avec un import automatique, des points
>> vont forcément se retrouver dans du bâti, du mauvais côté d'une route,
>> ou ce genre d'imprécision. 
> Oui. Pour éviter ça, il faut privilégier l'intégration :
> Un outil semi-automatique propose un PEI (osmose en ligne, JOSM en local
> avec un fichier GeoJSON…).
> Le(s) contributeur(s) l'ajoute "manuellement" dans OSM vérifiant sa
> position sur BDOrthoIGN, Mapillary, ou sur le terrain.
> Idem pour ses caractéristiques (diamètre maxi, poteau/bouche…).

Sur JOSM ça m'a l'air faisable dans mon coin pour quelques communes.
Pour Osmose en ligne, je ne sais pas comment mettre ça en place: est-ce
que tu aurais de la documentation à recommander ?

Antonin

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

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire

[Antonin Delpeuch (lists)]

Merci pour toutes ces réponses très rapides !

On 19/05/2020 15:19, Marc M. wrote:
> 
> - tester le jeu de données avec les 700 objets existants dans osm.
> le plugin josm conflate te permet facilement de trouver la distance
> max entre osm et l'opendata.

Pour les piliers que j'ai repéré moi même (une cinquantaine, dans une
zone couverte par une seule caserne), la correspondance est bonne (10m
de distance maxi). Ceci dit j'ai trouvé un pilier incendie qui n'est pas
dans leur jeu de données.

Sur l'ensemble du département il y a à boire et à manger: même avec un
diamètre maximal de 100m dans Conflation, il reste encore 42 points OSM
qui ne sont pas en correspondance avec le jeu de données. J'imagine
qu'il s'agit surtout de piliers qui ont été oubliés lors du repérage
(comme le "mien"), ou qui ont été supprimés/désaffectés entre temps (il
y a aussi des endroits louches dans OSM, comme deux piliers très proches
par exemple).

Dans l'ensemble, quand la distance diffère beaucoup entre OSM et le jeu
de données, le vecteur entre les deux suit généralement la direction
d'une route, donc imputable à une imprécision de repérage pendant qu'on
se déplace dans l'axe en question, ce qui ne me semble pas
catastrophique: la localisation des points n'est pas aberrante.

Ce qui m'inquiète plus c'est qu'avec un import automatique, des points
vont forcément se retrouver dans du bâti, du mauvais côté d'une route,
ou ce genre d'imprécision. Je ne sais pas dans quelle mesure c'est un
problème: évidemment, comme ces POI ne sont pas rendus sur la plupart
des fonds de carte, ça ne devrait pas gêner grand monde à part les
contributeurs qui découvrent les points en modifiant la carte. Est-ce
que c'est justement une opportunité pour nous de repositionner ces nœuds
à des emplacements cohérents à l'occasion d'autres modifications ? Ou
est-ce que je vais polluer la carte avec des points imprécis dont tout
le monde se fiche ? C'est pas clair pour moi…

Antonin

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

[OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire

[Antonin Delpeuch (lists)]

Bonjour,

Je souhaiterais importer dans OpenStreetMap des points d'eau incendie
(piliers, bouches et autres) à partir d'un jeu de données publié le mois
dernier par le SDIS de Saône-et-Loire (sous Licence Ouverte).

https://trouver.ternum-bfc.fr/dataset/points-deau-incendie-repertories-en-saone-et-loire

Je compte évidemment dédoublonner ces points avec ceux qui sont déjà
présents (environ 700 sur 12851):

https://overpass-turbo.eu/s/U9C

L'import suivrait les conventions décrites ici:

https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dfire_hydrant

Qu'en pensez-vous ? Quels sont les pièges à éviter ?

Merci pour vos retours sur ce projet !

Antonin



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

Re: [Talk-GB] PRoW archive

[Robert Whittaker (OSM lists)]

On Mon, 11 May 2020 at 20:30, Philip Barnes  wrote:
> On Mon, 2020-05-11 at 20:50 +0200, BD wrote:
>> I was looking at the discussion about PRoW and how to request the 
>> information from local council. I wonder if there is a comprehensive 
>> list/central location where we have stored information regarding which 
>> council has been approached and what was the answer (if any).
>>
>> It would make sense to save time (ours and councils) by not duplicating 
>> requests for information which might be already released.
>
> Have a look at https://rowmaps.com

That site is an excellent collection of all the data that's available,
with the added benefit of having it conveniently transformed into a
common format for downstream use. As far as OSM use is concerned  are
some licensing issues with some of the datasets there though, so you
need to be careful. Perhaps closer to what Bart was looking for is the
list I maintain:

https://osm.mathmos.net/prow/open-data/

Any corrections and additions to that page would be most welcome.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Lancashire prow_ref format (Was: Public Rights of Way - legal vs reality)

[Robert Whittaker (OSM lists)]

On Mon, 11 May 2020 at 14:12, nathan case  wrote:
> Thanks Tony and Adam for your responses. It is good to know that LCC have 
> released the parish IDs in the data as well. Makes a lookup table easy to 
> produce.
>
> It still remains that if I were a casual mapper and wanted to add an unmapped 
> path to OSM, the primary source for the prow_ref is the council’s map.

Unless you've been given permission by the copyright holder to make
use of a map like that, then it's off-limits for use in OSM. The map
at 
https://www.lancashire.gov.uk/roads-parking-and-travel/public-rights-of-way/public-rights-of-way-map/
is currently not working for me, but is does say "(c) Crown copyright
and database rights 2020 Ordnance Survey 100023320" below it. It's
likely that it was showing lines for Rights of Way on top of an
Ordnance Survey base map -- in which case it certainly couldn't be
used for OSM mapping. You might be able to get permission to use the
overlay lines, but you'd have to detach them from the base map before
using them. Otherwise you might be inferring location details from the
OS base map. Ordnance Survey are quite strict on what they consider to
be derived data from their maps, so OSM needs to be very careful
around them.

What we do have permission to use in OSM is the raw GIS files from
Lancashire. As already noted, these contain both the parish IDs and
names. It's up to whoever renders them what to show as labels.
Hopefully we can agree on a prow_ref format here, and then any tool
authors will follow that in what they display to mappers.

> It is then complicated that other sources use an mix of formats. (Even for 
> me, parish IDs are the most straightforward way of adding prow_ref data to 
> OSM.)

Both myself (who runs PRoW Comparison tools) and Nick (who runs MapThe
Paths) intend to ensure our tools show whatever prow_ref format is
agreed. So that should be two common sources of data for mappers to
use.

Best wishes,

Robert.

-- 
Robert Whittaker

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

[Talk-GB] Lancashire prow_ref format (Was: Public Rights of Way - legal vs reality)

[Robert Whittaker (OSM lists)]

This may have got lost in the discussion about highway=no, but I'd
like to get some feedback on what prow_ref format is best to use in
Lancashire. See my previous message below:

On Mon, 4 May 2020 at 19:23, Robert Whittaker (OSM lists)
 wrote:
> The format of the Right of Way numbers seems to depend on what
> map/data you look at. I think it would be highly desirable if we could
> agree on a single format to use throughout the whole of Lancashire in
> OpenStreetMap.
>
> I think the Lancashire online map at
> https://www.lancashire.gov.uk/roads-parking-and-travel/public-rights-of-way/public-rights-of-way-map/
> is a relatively recent innovation. (By the way, you shouldn't use that
> map for OSM mapping, as there's an OS-copyrighted backdrop, which you
> might inadvertently take information from, or use relative positioning
> information from.) The Council's online map uses "1-2-FP 3", while
> mapthepaths uses "1-2 3" (which comes from older GIS data Lancashire
> released and was given to rowmaps.com). On my tool, I've currently
> adopted the "[parish name] [type] [number]" format, which is the
> default if I don't select anything else.
>
> So what to standardise on? The "1-2" part in the numbers above is a
> parish code, which I think is probably an internal GIS thing within
> the council, rather than what the official legal documents use to
> refer to the paths. If you look at how they actually refer to the
> paths, e.g. in the DMMO register at
> http://www3.lancashire.gov.uk/corporate/dmmoview/index.asp you'll see
> they almost always refer to them by the parish name, type and number.
> There's some discrepancy over whether a Public Footpath is PF or FP
> (or occasionally PFP). But on the computer-generated order maps, it's
> always FP, with BW used for Bridleway and BOAT for Byways Open to All
> Traffic. I couldn't find a Restricted Byway on a map. The parish names
> (rather than ID numbers) are also a lot easier for humans to deal with
> when mapping.
>
> Based on the above, my preference would be to agree to use the
> "[parish name] [type] [number]" format. But if it's decided to use
> something else, I'll happily change my tool to whatever is decided.
> (Although I can only set one format per county, so it will need to be
> county-wide.) Hopefully Nick will be able / willing to do the same on
> mapthepaths.

(I've since been in touch with Nick, and he's keen to work together so
we have use the same format for each county in our two tools.)

Many thanks,

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Public Rights of Way - legal vs reality

[Robert Whittaker (OSM lists)]

On Tue, 5 May 2020 at 19:33, Mike Baggaley via Talk-GB
 wrote:
> >Highway=no seems acceptable to me where a path is permanently physically
> >blocked by a building or such-like. We're not serving anyone by directing
> >people into wals. I do, however, disagree with its use to tag definitive
> >rights of way which are useable but which merely deviate from the route a
> >mapper mapped on the ground. Eg. I don't think a highway=no tag should be
> >added to a cross field definitive footpath just because a path round the
> >field has been mapped.
>
> In the case where a path has been permanently blocked, I would suggest 
> disused:highway=footway/bridleway, abandonded:highway=footway  or 
> removed:highway=footway, depending on whether the path is still visible and 
> whether the blockage would be relatively easy or difficult to remove. This 
> seems to me to be much better than highway=no.

That's a good suggestion. I wouldn't completely rule out using
highway=no, but if one of your other suggestions fits it would be good
to use it. I've now added those options to the "missing highway"
checks my PRoW tool does, so if one of them have been used, it won't
complain about the lack of a highway=* tag on a Right of Way.

Robert.

-- 
Robert Whittaker

-- 
Robert Whittaker

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

Re: [Talk-GB] Public Rights of Way - legal vs reality

[Robert Whittaker (OSM lists)]

On Tue, 5 May 2020 at 11:54, Adam Snape  wrote:
> I'd consider this particular proposed use of highway=no to mean "there is a 
> public highway here but there's no visible path on the ground" to be a 
> somewhat country-specific and counter-intuitive tagging practice. It's 
> certainly being suggested here as a solution to a country-specific issue 
> regarding the mapping of England and Wales' rights of way network.

That's not precisely how I've been using highway=no or would advocate
others to use it. I would only use highway=no in the case where there
is a legal right of way that either is not or cannot be used on the
ground. The "is not" might be a case where there is a regularly
ploughed or cropped field and the cross-field path is never
reinstated, so everyone always walks around the edge of the field
instead. (Though if the cross-field line is usually passable, I'd
possibly still use highway=path there.) The "cannot" might be a case
where there's an impassible ditch or a house blocking the legal line
(where higwhay=path would certainly not be appropriate).

I'd be quite happy adding a highway=footway to e.g. a cross-field path
even if there's no physical sign of it on the ground, as long as I'm
confident it will be walked by users of the public footpath.

In terms of how highway=no should be interpreted by data users, I
would say highway=no means no more and no less than "there is not a
(physical) highway here". I think the tagging is needed on objects
(e.g. ways with designation=public_footpath) where you'd normally
expect to find a highway=* tag, in order to distinguish this case from
the case where it hasn't been established whether or what type of
highway is present. (Some people will add rights of way lines to the
map, and omit the highway tag until they've done a ground survey to
determine what is there on the ground.)

The main point I think, is that if you've tagged the definitive line
of a Right of Way, and there's no suitable highway=* type for it, it's
good to add highway=no, to confirm that's the case. This distinguishes
that case from the case where the correct highway=* type still needs
to be determined and added.

Robert.

-- 
Robert Whittaker

-- 
Robert Whittaker

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

Re: [Talk-GB] Public Rights of Way - legal vs reality

[Robert Whittaker (OSM lists)]

On Mon, 4 May 2020 at 14:13, nathan case  wrote:
> Thanks for your input Robert, the approach taken for routes not following the 
> definitive line makes sense - though does this lead to two paths being 
> rendered? Or does highway=no prevent this? I will also add the fixme as Tony 
> suggests.

I'd be surprised if any map renders this as a highway. But the
presence of a designation tag may result in a UK outdoor style adding
some indication of the right of way there (perhaps like the green or
pink dashes that OS uses on its maps).

> > are you adding prow_ref=* tags to the Rights of Way, and if so what format 
> > are you using?
>
> I am. However, I can spot two issues:
>
> 1. (my fault) I'd not been including "LA" prefix to the prow_ref number. I 
> had assumed it stood for Lancashire but now realise it is actually for 
> Lancaster. I will do so from now on and will try and go back and edit my 
> edits (though there are a lot of them), unless there is another way?

I think you were probably right about the "LA" the first time. It
could well be the "LA" that's used by rowmaps.com as its county prefix
for Lancashire. If any bulk corrections are needed, I may have some
tools to be able to do them more efficiently -- do ask before spending
lots of time on repetitive stuff like that.

> 2. (kinda my fault) the map data I'd been using (the Mapbox overlay) does not 
> contain the public right of way type (i.e. the prow ref is simply given as LA 
> |1-2| 3). Tony's email has pointed me to the county's right of way map which 
> does contain this information (i.e 1-2-FP 3) so I will have to cross check 
> the data as I copy it over (an annoying additional step!).

The format of the Right of Way numbers seems to depend on what
map/data you look at. I think it would be highly desirable if we could
agree on a single format to use throughout the whole of Lancashire in
OpenStreetMap.

I think the Lancashire online map at
https://www.lancashire.gov.uk/roads-parking-and-travel/public-rights-of-way/public-rights-of-way-map/
is a relatively recent innovation. (By the way, you shouldn't use that
map for OSM mapping, as there's an OS-copyrighted backdrop, which you
might inadvertently take information from, or use relative positioning
information from.) The Council's online map uses "1-2-FP 3", while
mapthepaths uses "1-2 3" (which comes from older GIS data Lancashire
released and was given to rowmaps.com). On my tool, I've currently
adopted the "[parish name] [type] [number]" format, which is the
default if I don't select anything else.

So what to standardise on? The "1-2" part in the numbers above is a
parish code, which I think is probably an internal GIS thing within
the council, rather than what the official legal documents use to
refer to the paths. If you look at how they actually refer to the
paths, e.g. in the DMMO register at
http://www3.lancashire.gov.uk/corporate/dmmoview/index.asp you'll see
they almost always refer to them by the parish name, type and number.
There's some discrepancy over whether a Public Footpath is PF or FP
(or occasionally PFP). But on the computer-generated order maps, it's
always FP, with BW used for Bridleway and BOAT for Byways Open to All
Traffic. I couldn't find a Restricted Byway on a map. The parish names
(rather than ID numbers) are also a lot easier for humans to deal with
when mapping.

Based on the above, my preference would be to agree to use the
"[parish name] [type] [number]" format. But if it's decided to use
something else, I'll happily change my tool to whatever is decided.
(Although I can only set one format per county, so it will need to be
county-wide.) Hopefully Nick will be able / willing to do the same on
mapthepaths.

Best wishes,

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Public Rights of Way - legal vs reality

[Robert Whittaker (OSM lists)]

As a general principle, I think we should certainly map both (a) any
physical paths on the ground and (b) the legal Definitive Line (though
not necessarily as a highway if it isn't one). These might be separate
ways if the two line differ, though they'd normally be one and the
same. It would also be useful to map (c) any required deviations from
the definitive line in order to use a Right of Way, whether or not
there's a physical path in evidence there, in order to maintain a
route-able network or ways.

Further details of the tagging I use in various cases can be found at
https://wiki.openstreetmap.org/wiki/User:Rjw62/PRoW_Tagging#Routes_not_following_the_Definitive_Line

By the way Nathan, are you adding prow_ref=* tags to the Rights of
Way, and if so what format are you using? If you're mapping Rights of
Way in Lancashire, you might be interested in my tools at
https://osm.mathmos.net/prow/progress/lancs/

Best wishes,

Robert.

On Mon, 4 May 2020 at 11:29, nathan case  wrote:
> I’m using the very helpful work Mapbox tiles (from Rob Nickerson’s email on 
> 11 Nov 2019) to map Lancashire’s public rights of way (PROW) under the 
> council’s open data licence.
[snip]
> In cases where the mapped route deviates substantially from the PROW – should 
> I keep the mapped route or edit to fit the PROW?
>
> The mapped route could be an error (even with GPS trails) as the original 
> mapper may have taken the incorrect route. Quite often this is the original 
> mapper being polite and walking around the edge of a farmer’s field even when 
> the PROW is straight through the field. Legally, the route is through the 
> field and not around it. Or it could be that the way is not well signposted 
> and the mapper has had to guess the way (a big issue across Lancashire’s 
> moorlands/heathlands for the not so well trodden paths).
>
> Equally, the mapped route could represent the actual “on the ground” route 
> i.e. the route shown by PROW vector may be impassable. It’s also not 
> guaranteed that the vector files are correct (as they’re only copies from the 
> definitive map).
>
> Where the PROW goes through a building/object – should I map the route as 
> defined in the PROW, or re-route the PROW around the object?
>
> Unless there is an error in the PROW vectors, the building shouldn’t be built 
> on the PROW – though it does seem to happen a lot, especially with farm 
> buildings. Obviously the path can no longer run through the building – 
> despite it’s legal status. When arm chair mapping (as is only practical with 
> such a large data set) should we instead show the best alternative route? Or 
> go with the legal route and allow people following the route on the ground to 
> find the best route and edit in future?

-- 
Robert Whittaker

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

Re: [OSM-talk] Let's talk Attribution

[Robert Whittaker (OSM lists)]

On Sun, 3 May 2020 at 23:01, Kathleen Lu via talk
 wrote:
> OSM has imported sources that are ODbL. The attribution to those sources does 
> not appear on the map, but rather after several clicks (usually first to the 
> copyright page, then the contributors page). If that's not acceptable under 
> ODbL for a map that has multiple data sources, then OSM would be violating 
> others' ODbL licenses.

In clause 4.3, the ODbL explicitly does not actually require any
copyright notices (which I guess includes attribution statements) on
produced works. Instead the notice that must be included (reasonably
calculated to ensure that everyone viewing the produced work aware of
it) is to say that the work has been made using an ODbL database, with
details of how it can be obtained. So in this sense OSM is failing to
comply with the ODbL on the main map, but it's not through lack of
attribution of sources.

What we actually *need* to include on the map is a mention of the
"OpenStreetMap" database, that the data is available under the ODbL,
and a link to where it can be obtained. I'd suggest we should be using
something like "Map data (c) OpenStreetMap, ODbL." Downstream users of
OSM need to do the same (or equivalently reference their own
ODbL-or-equivalent-licensed Derivative Database). This text on
produced works cannot be hidden behind other links.

(Presumably, the way the ODbL was envisaged working with produced
works, is that people viewing them are made away that that underlying
data is re-usable and how to get hold of it. The copyright notices,
attribution etc. then must be delivered if/when they try to access the
raw data.)

Robert.

-- 
Robert Whittaker

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

Re: [OSM-talk] Let's talk Attribution

[Robert Whittaker (OSM lists)]

On Wed, 29 Apr 2020 at 11:22, Christoph Hormann  wrote:
> And what i have also said several times before is that the only way you
> can consistently interpret the ODbL attribution requirement - what
> Martin quoted as:
>
> „You must include a notice associated with the Produced Work reasonably
> calculated to make any Person that uses, views, accesses, interacts
> with, or is otherwise exposed to the Produced Work aware that Content
> was obtained from the Database,...“
>
> is in the way that the determination if any Person that uses, views,
> accesses, interacts with, or is otherwise exposed to the Produced
> Work becomes aware that Content was obtained from the Database from the
> attribution provided needs to *be based on reason*.  So far no one has
> even attempted to explain the reasoning behind the expectation that a
> user of an application with hidden attribution becomes aware that
> Content was obtained from the Database.

Indeed. To put this another way -- and a lot of people seem to be
mis-understanding this -- whatever attribution an OSM licensee chooses
to employ, the licensee needs to be able to make a reasonable argument
that *every* user who views, interacts with, etc the produced work
will become aware that the content has come from OSM. Not just some
users, or those that choose to go looking for the data source, but
every user. The "reasonable" does not refer to how good the
attribution needs to be, or the expectation/ease of each user finding
it, or the space it takes up on the screen. It refers to the
calculation made by the licensee. The attribution must ensure -- in
the reasonable view of the licensee -- that every user will see it.

I fail to see how not showing a visible attribution to every user in
the normal course of their interaction with a produced work could
possibly be "reasonably calculated" to make everyone aware of the OSM
provenance. Hiding the attribution behind an "(i)" that you know most
users won't click on, or putting in on a splash screen that disappears
so quickly people won't get a chance to read it does not comply with
the ODbL in my opinion. I think we need to accept that this is what
our licence says, and take better steps to ensure licensees understand
this.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] prow_ref format for Dorset Public Rights of Way

[Robert Whittaker (OSM lists)]

On Thu, 16 Apr 2020 at 15:34, Nick Whitelegg
 wrote:
> I wasn't familiar with the situation in Dorset but MapThePaths uses the 'SE 
> 4/22' scheme (actually it appears as 'SE 4 22') so if people want to use MTP 
> as a source for prow_refs, then that would be the format to use.

In general, I think that tools (mine included) should follow agree
tagging, rather than the tagging following the tools.

> In terms of how I arrive at the references, I sourced the data from the 
> rowmaps site and applied a script which looked for a particular field (I 
> forget its name) in the rowmaps data. This is done consistently across all 
> counties.

Unfortunately, my experience of the rowmaps data itself is that it's
not really consistent in what it puts in its fields. (That's not
rowmap's fault though -- Barry is just using whatever formats arrive
in the data his tool consumes.

> I don't really mind too much what people use to be honest, obviously 
> something like 'Studland FP 1' or similar would be more descriptive, but 
> would require an extra step to look up the parish name.
>
> Maybe we should develop some sort of (crowd-sourced?) service which looks up 
> parishes based on parish codes to allow easy contribution of descriptive 
> prow_refs?

I've started an effort in that direction at
https://osm.mathmos.net/prow/ref-formats/ . For each county in the
list there's a regular expression for parsing the prow_ref tag, and a
printf format for outputting a prow_ref tag from structured data. This
is then what my PRoW tool uses internally. I'm in the process of
adding the parish name/id lookup tables that I've collected to this
page. There's a JSON feed with the data to make it easier for others
to use it too.

> On the other hand some counties do not use parish refs at all in hhe number, 
> though they do mention them in the full ref (e.g. FERNHURST 1254). The 
> Chichester district of West Sussex (not OGL, by the way - unfortunately from 
> my POV as it's an area I'm interested in) appears to use a simple number for 
> all PROW refs, ranging from about 1-3500. This is not consistent in a given 
> parish, e.g. numbers between 1200-1299 appear to be spread between Fernhurst, 
> Lynchmere and Milland parishes.

Warwickshire is a bit like this too. It seems they numbered their
Rights of Way within each former district/borough. When this happens,
in my tool I treat these areas as "parishes". See e.g.
https://osm.mathmos.net/prow/progress/warks/north-warks/atherstone-rural-district/

Best wishes,

Robert.

-- 
Robert Whittaker

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

[Talk-GB] prow_ref format for Dorset Public Rights of Way

[Robert Whittaker (OSM lists)]

I've recently been looking at increasing the coverage of my PRoW
comparison tool https://osm.mathmos.net/prow/progress/ by adding new
counties. In particular, I've been looking at the data from Dorset.
I've hit a small issue though, in that the council uses two different
formats for their Right of Way Numbers. We really need to just select
one for the county in order to be consistent in OSM.

One format has a parish code followed by a slash and then the route
number within the parish (e.g. "SE4/22" for path number 22 in
Affpuddle and Turnerspuddle parish). The other would be to use the
full parish name, right of way type, and number. I asked their
Definitive Map officer about this and got the response:

"Both systems are used in parallel. For mapping (where the status and
parish are obvious) and for internal use, we use the numbering system,
but when reporting to Committee members or members of the public who
will not be familiar with the numbering system, we name the parish and
describe the status. Our sealed statements are listed by named parish,
status and route number. Our working statement spreadsheet uses parish
number, status and route number."

The "SE4/22" style numbers are what are used on Dorset Council's own
online map at 
https://www.dorsetcouncil.gov.uk/countryside-coast-parks/rights-of-way/rights-of-way-map-where-to-walk-ride-or-cycle.aspx
. Currently in OSM we have about 394km of routes in Dorset using this
style in the prow_ref tag, and another 98km using this style with a
space instead of the slash. That a total of around 492km based on the
parish codes and numbers. Conversely, there's only around 125km of
routes in Dorset that have a prow_ref tag that includes a parish name.

Based on this, my preference would be to standardise on the "SE4/22"
style format for the prow_ref in Dorset, and convert any other
instances found to this. What does everyone else think? I'll invite
Nick Whitelegg (who developed the "map the paths" site) and also a few
mappers who've made significant contributions to Dorset PRoW's in OSM
to this thread to get their input too.

Best wishes,
Robert.

-- 
Robert Whittaker

___
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

[Robert Whittaker (OSM lists)]

On Thu, 16 Apr 2020 at 12:27, Peter Neale  wrote:
> I tried following the link to your proposed new source of “official” data, 
> but none of the 3 links to the data worked very well for me.
>
> Link 1:  (API format) led to http 404 error.
> Link 2  (CSV(TSV) format – led to http 404 error
> Link 3  (XSV format) downloaded a file with a “.csv” file extension that 
> seemed to be tab-separated, rather than comma-separated.  I took that into a 
> text editor and did a global Find and Replace of Tab with Comma.  The 
> resultant .csv file loaded into Excel just fine, but it has over 11,000 lines 
> and many of them must now have additional commas, because a number of fields 
> are right-shifted (Post Code in the Latitude Column, Latitude in the 
> Longitude Column, etc.)  Also, over 700 have Blank in the Address1 Field, 
> with the whole address in Address 2, Address 3, etc.  Then quite a few (from 
> my sample in the first 30) have County values in the ParentName Field.  So I 
> fear that, unless you can do a better conversion than I did (and you almost 
> certainly could, I know!) you will have a lot of manual cleaning up to do, 
> before you can use this data.

Yes, the first two links at
https://data.gov.uk/dataset/e373eb6a-fffd-48e5-b306-71eb17f97af2/pharmacies
are broken for me as well. For the third link, it looks like they
tried to do CSV, but didn't understand how to escape commas within the
fields, and so opted to use a different character "¬" instead. If you
import this into a spreadsheet, and tell it to use just "¬" as the
column separator, I think it works out fine, with all the entries in
the right place. (You can certainly do this with LibreOffice; I'm not
sure about Excel.) The address lines seem to be used inconsistently,
but everything is back aligned when you get to the postcode field.

Best wishes,

Robert.

-- 
Robert Whittaker

___
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

[Robert Whittaker (OSM lists)]

On Sun, 12 Apr 2020 at 20:40, Peter Neale  wrote:
> I looked up my 2 "wholesale" pharmacies on the list.  Unfortunately, they are 
> both classed as "community", so will continue to be included in your checking 
> tool.
>
> So... ...should we:
> a.  Continue as we are: Plot them in OSM, tag them as pharmacies, but give 
> them a name that makes it clear that they are not publicly accessible?
> b.  Delete them from OSM, so that consumers don't think they are publicly 
> accessible.  (But they do exist and who knows what consumers will really want 
> to find?)  Then we could ask you to manually delete them from the checking 
> tool (but you probably won't want to keep doing that).
> c.  Do something else?

I certainly wouldn't advocate any inappropriate tagging just to keep
my tool happy! So if we don't think they should be amenity=pharmacy,
then we shouldn't tag them like that. While they may technically be
pharmacies, I would think that amenity=pharmacy is best reserved for
places that are amenities for the general public to use, which would
rule out option (a). As for (b), I wouldn't necessarily delete the
objects completely from OSM: if there's a business presence on the
ground, that could still be tagged. The question then is whether it's
worth tweaking my tool to remove these false positives. You could just
ignore the "missing pharmacy" markers local to you that you know are
wrong. As you say, I would have a manually maintained "ignore" list,
but that would be more effort for me.

What I'd prefer to to is to switch to a better data source for my
pharmacy list. There is a list of NHS-contracted pharmacies at
https://data.gov.uk/dataset/e373eb6a-fffd-48e5-b306-71eb17f97af2/pharmacies
which I think would closer match what we want for amenity=pharmacy,
but unfortunately that list appears to be England only. So I'd need to
find corresponding lists for Wales and Scotland. (NI isn't in the data
I'm currently using. I've found
https://www.psni.org.uk/registration/premises-registration/changes-to-the-premises-register/
but the data is all locked up in PDFs.) Can anyone help out here?

Robert.

-- 
Robert Whittaker

___
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

[Robert Whittaker (OSM lists)]

On Sun, 12 Apr 2020 at 18:08, Peter Neale  wrote:
> As Boots' stores don't ALL have a pharmacy counter, IMHO they should be 
> tagged as "shop=chemist".  Those that DO have a pharmacy (dispensing 
> prescriptions) should be additionally tagged, either with "pharmacy=yes", or 
> with a separate node for the pharmacy.  I think that would fit with the 
> checking that you describe for your tool.

Both of those will get picked up by my tool. You could also do
shop=chemist and amenity=pharmacy together, or just amenity=pharmacy
on it's own. The best choice will probably depend on the nature of the
Boots branch. Some may essentially just be a pharmacy counter with a
small range of other medicines also available. Others branches will be
a much larger store, where the pharmacy counter is more incidental.

> As regards "pharmacy type", does your data identify what I would call 
> "wholesale pharmacies", who have no public access, but supply medicines to 
> hospitals, care homes and individual customers in their homes?  I know of 2 
> in my area.  In one case, I changed the name to "Jardines (on line)" (Node: 
> 6409354480) and in the other to "Mediva Private Pharmacy" (Node: 6443190532), 
> in an attempt to make it clear that there is no public access.
> Could these be excluded in future?

The data I use can be downloaded from
https://www.pharmacyregulation.org/registers -- it's the "list of
registered pharmacies". As of today, I'm now just keeping those with a
Type (the last column) of either "Community" or "Temporary -
Community/Portacabin". I think doing this corresponds most closely to
what we'd want to tag as amenity=pharmacy in OSM. For internal
hospital and prison pharmacies, and for internet-only pharmacies that
you can't get prescriptions from as a walk-in customer, I don't think
they should be tagged as amenity=pharmacy.

Best wishes,
Robert.

-- 
Robert Whittaker

___
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

[Robert Whittaker (OSM lists)]

On Sat, 11 Apr 2020 at 18:39, Dave Love  wrote:
>
> On Thu, 2020-04-09 at 12:08 +0100, SK53 wrote:
> > Robert Whittaker has a Pharmacy QA  > > site
>
> That shows a Boots missing which I tagged as the brand from the
> correction iD wanted (brand=Boots shop=chemist).  How should Boots be
> tagged, and does iD need a fix?  (I assume all Boots have pharmacies,
> but maybe not.)

As far as my tool at https://osm.mathmos.net/pharmacy/progress/ is
concerned, pharmacies are recognised as OSM objects tagged with either
amenity=pharmacy or pharmacy=yes*. (The latter can be used on things
like supermarkets and doctors surgeries, when things aren't mapped in
enough detail to have a separate amenity=pharmacy node.)

As for whether all Boots stores have pharmacies, I think most do, but
some don't: 
https://www.boots-uk.com/about-boots-uk/about-boots/boots-in-numbers/
says there are 2,465 Boots stores, but in the General Pharmaceutical
Council register of Pharmacies, there are only 2304 premises
registered to 'Boots UK Limited'.

Robert

PS: I've just noticed that the data I'm using for my tool now contains
a "Pharmacy Type" field. This means I can exclude internet only
pharmacies, temporary locations (e.g. for events) and internal
hospital and prisons pharmacies. This will hopefully make the
comparison shown by the tool must more useful.

* Because of the change to exclude hospital and prison pharmacies from
the GPhC data, OSM objects with pharmacy=yes will only be picked up in
my tool if they do not also have amenity=hospital or amenity=prison
too.

--
Robert Whittaker

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

Re: [Talk-GB] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

[Robert Whittaker (OSM lists)]

On Thu, 9 Apr 2020 at 14:26, Robert Whittaker (OSM lists)
 wrote:
> On Thu, 9 Apr 2020 at 09:21, Tony OSM  wrote:
> > If the data is to be in the public domain the next step has to be tagging.
> > Do we need country specific tags for these two pieces of data?
> > What should they be?
>
[snip]
>
> So I'd propose that we use either ref:uprn and ref:usrn, or
> ref:UK:uprn and ref:UK:usrn. What does everyone else think?

Oops. If we were to use the ISO Alpha-2 country codes, it should of
course be GB rather then UK. So that would make the keys ref:GB:uprn
and ref:GB:usrn .

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

[Robert Whittaker (OSM lists)]

On Thu, 9 Apr 2020 at 09:21, Tony OSM  wrote:
> If the data is to be in the public domain the next step has to be tagging.
> Do we need country specific tags for these two pieces of data?
> What should they be?

Looking at taginfo, there are a number of different tags in use for
UPRN values (see https://taginfo.openstreetmap.org.uk/search?q=uprn
where ref:NPLG:UPRN:1 is the most popular). I think it would be good
to agree on a standard key to use before too many more are added. USRN
values are more standardised:
https://taginfo.openstreetmap.org.uk/search?q=usrn with ref:usrn and
NPLG:USRN:1 being the only two keys in use. (NPLG presumably refers to
the National Land and Property Gazetteer -- see
https://en.wikipedia.org/wiki/National_Land_and_Property_Gazetteer --
but the middle two letters are the wrong way round.)

I would have said that ref:uprn and ref:usrn are the natural choices
for use to use. However, I've seen some calls for country codes to be
added to 3rd-party ref values, so we might consider ref:UK:uprn and
ref:UK:usrn instead. This isn't explicitly documented in the wiki at
https://wiki.openstreetmap.org/wiki/Key:ref though the French
community seems to be using it, as can be seen at
https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales
, and I think it might make sense.

I don't see any value in adding NLPG (or it's incorrectly ordered
variant NPLG). Although the National Land and Property Gazetteer is
where the UPRN values originate from, if they're being used as core
identifiers by the government, they're no longer just NLPG values.

I also don't see any benefit in adding a :1 :2 etc suffix to the key
in anticipation of multiple values (which seems to have been done in
several existing UPRN keys). I think this will actually make it harder
for data-users than having a single key name and separating multiple
values with semi-colons. (You would suddenly need to search multiple
different keys to get all possible UPRN-tagged objects.)

So I'd propose that we use either ref:uprn and ref:usrn, or
ref:UK:uprn and ref:UK:usrn. What does everyone else think?

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Town Greens

[Robert Whittaker (OSM lists)]

On Fri, 3 Apr 2020 at 15:20, nathan case  wrote:
> The two main components of the green, a wood and a grass area, are separately 
> mapped as such.
>
> Where would you add the designation tag? To the boundary or to the two main 
> landuse components? Or would you create a relation so that the designation 
> tag and name (etc.) can be shared across the separate land uses?

Following https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
if there's a single legal "Town Green" entity, then there should be
one OSM element for the Town Green with designation=town_green. (You
can of course have other OSM elements for things within it, like the
separate wood and grass areas.) The "Town Green" object should follow
the legal boundaries of the town green. If it's all in one connected
piece, then you could have a single way following the edge of the
boundary sharing nodes with the edges of the wood and grass areas. (I
think this is what you've done with
https://www.openstreetmap.org/way/181597678 .) If there are multiple
disconnected pieces (e.g. two patches on either side of a road) then
you could use a multi-polygon relation to have a single object
covering all the areas.

You may also see a mapping style around where people try to avoid ways
sharing nodes, by having lots of line segments without tags, and then
grouping them together with multipolygons. In your example, they would
have three ways -- one for the part of the outer boundary next to the
wood, one for the part of the outer boundary next to the grass, and
one for the wood-grass joining line -- and then three multi-polygons
-- one containing the two outer boundary ways for the "Town Green"
object, one containing the two ways bounding the wood for the "wood"
object, and one containing the two ways bounding the grass for the
"grass" object. While conceptually neat, and not incorrect, I think
this over-complicates things and makes everything a pain to edit. I'd
just stick with three closed ways, sharing nodes round the boundary.

There's also a style in which you'd have one closed way for the wood,
and one for the grass, and then have a multi-polygon containing the
two closed ways. However, the fact that the two outer closed ways
share common line segments, violates the requirements at
https://wiki.openstreetmap.org/wiki/Relation:multipolygon .

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Town Greens

[Robert Whittaker (OSM lists)]

On Fri, 3 Apr 2020 at 11:49, nathan case  wrote:
> I made a recent edit to a local area that has recently been designated a 
> “Town Green”.
>
> Edit: https://www.openstreetmap.org/changeset/82973329

What I would do with these is to separate the legal status from the
physical and usage characteristics. First I would tag the legal
status, using the designation=* tag (which was set up for such
purposes) i.e. designation=town_green. Once that's done you can add
whatever other tags you think best describe the actual land and the
way it is used. That might be leisure=park, landuse=recreation_ground,
or whatever, depending on the nature of the Town Green in question. By
using two (or more tags) you can correctly capture the UK legal
status, while also ensuring the area renders in an appropriate way
based on it's on-the-ground characteristics.

Hope that helps,

Robert.

> For those that are unfamiliar with a Town Green – it is, legally, the same as 
> a village green. It is a legally protected area of land that is for the 
> enjoyment of the public (Commons Act 2006 and the Commons Registration Act 
> 1965).

-- 
Robert Whittaker

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

Re: [Talk-GB] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

[Robert Whittaker (OSM lists)]

On Thu, 2 Apr 2020 at 22:19, RobJN  wrote:
> It's all a bit unclear but from what I've read it sounds like there will be
> a release of the UPRN / UPSN identifiers and their associated geometries
> ("coordinates" in some text). I see no reference to address data being part
> of the release.

There will presumably be a drive in government circles to store
addresses as UPRN's, and then fetch the associated location and
address data from AddressBase. Assuming Rob's interpretation is
correct (I think it probably is) then this could be bad new for
sources of addresses and postcodes for OSM. While we'll be more easily
able to geo-locate objects from their URPN's, the actual addresses in
any datasets will become more likely to be contaminated by OS's IP
rights in AddressBase.

So this news could be a bit of a double-edged sword I think. e.g. if
the FHRS data switched to using UPRNs and AddressBase-derived
addresses, we would lose the ability to make use of addresses and
postcodes from the FHRS data, but then we'd have accurate locations we
could rely on to directly add establishments to the map from their
FHRS entry.

Robert.

-- 
Robert Whittaker

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

[Talk-GB] Stale Developments

[Robert Whittaker (OSM lists)]

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

Re: [OSM-legal-talk] use OSM data to select proprietary data

[Robert Whittaker (OSM lists)]

On Thu, 12 Dec 2019 22:41 Kathleen Lu via legal-talk, <
legal-talk@openstreetmap.org> wrote:

> No, ODbL does not apply to any database that does not include OSM data.
> There are two reasons.
>

I would argue that the dataset here does include some OSM data, as it includes
(albeit limited) information about the regions enclosed by certain features
in OSM. Regardless of that though, I would use the following reasoning,
involving a chain of derivative databases, to argue that final databases
could be subject to ODbL even if they don't directly contain any OSM data,
if OSM data has been used in their creation.

At some point in the process of deriving the new dataset here, an OSM extract
and some proprietary data were combined into a database. To start with,
these would be independent parts, and so the combined database would be a
Collective Database, and so not subject to ODbL.
However, I would argue that the moment you run a query that combines both
parts of the database in a non-trivial way, those parts can no longer be
said to be "independent", and hence they cannot be part of a
Collective Database. The combined OSM extract, proprietary data, and the
output from the query are now a derivative database, and hence subject to
ODbL, thanks to the presence of the OSM data. The data published is then a
substantial extract from this derivative database,
and is thus is a derivative of the derivative. This makes it also subject
to ODbL.

Robert.

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

Re: [Talk-GB] Lancashire prow_ref reference table

[Robert Whittaker (OSM lists)]

On Tue, 26 Nov 2019 at 14:32, Dave F via Talk-GB
 wrote:
>
> On 26/11/2019 12:01, Tony OSM wrote:
> >  to the preferred prow_ref format  Adlington FP 5.
>
> As previous, this is not the preferred format. The format should be as
> supplied by the LA, the organisation which has the *authority* to name
> PROWs.

My reading of the original post is that Tony is saying that the
Council themselves are inconsistent in how they refer to their PRoWs.
In which case, I think we should use the format that is most prevalent
on the underlying legal documents (i.e. the Definitive Map and
Statement) rather than any electronic working datasets that are
produced from these. The onilne map at
https://www.lancashire.gov.uk/roads-parking-and-travel/public-rights-of-way/public-rights-of-way-map/
uses the "9-5-FP 23" style numbers, but probably doesn't have any
legal force. I can't find any actual Definitive Statements online for
Lancashire, but there are what seem to be some Definitive Map extracts
in their DMMO register at
http://www3.lancashire.gov.uk/corporate/dmmoview/ . These mostly look
to just use the "FP 34", "BW 45" numbers, without an explicit parish.
My guess would be that the parishes are named in the Definitive Map
and Statement, rather than using reference numbers (which are probably
an artefact of digitisation). So unless the council has officially
adopted the electronic version with the "9-5-FP 23" style numbers as
it's legal Definitive Map, we should be looking at accepting parish
names in the official reference numbers. The question then is how does
the council itself refer to the Rights of Way when using named
parishes rather than IDs. What is *their* preferred format?

If we can agree on the appropriate prow_ref format to use in OSM, then
I can load the GIS data into my tool at
https://osm.mathmos.net/prow/progress/ and have it display the refs in
the agreed format. Tony, if you've got a CSV file that converts
between the ID numbers and named districts/parishes that you could
send me, that would be really helpful, whichever format we end up
agreeing to use in OSM. It will also automatically produce a table
like https://osm.mathmos.net/prow/progress/essex/parishes with the
parish names and numbers for anyone to reference.

Best wishes,

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] OSM-UK misunderstands the British Isles

[Robert Whittaker (OSM lists)]

On Wed, 13 Nov 2019 at 16:35, Mateusz Konieczny  wrote:
> This message seems to complain
> about something, but it is unclear
> what is the problem.

Having looked at https://wiki.openstreetmap.org/wiki/United_Kingdom I
assume the problem was that in the opening sentence under the map, the
page erroneously said that the UK included the Crown Dependencies and
the British Overseas Territories. I've now (hopefully) fixed that, and
also explained what the "British Isles" is.

As far as OSMUK is concerned, I think the Community Interest Company
formally has the UK as it's scope, although as an OSMF local chapter
it officially covers the UK (including Northern Ireland) and the three
Crown Dependencies (Isle of Man, Jersey and Guernsey). We're happy to
overlap with the OSMIE local chapter, who cover the whole of the
island of Ireland (so also including Northern Ireland).

Re the size of OSMUK's membership, the annual report at
https://osmuk.org/wp-content/uploads/2017/09/Annual_Report_of_the_Directors_OSMUK_CIC_for_Year_Ending_March_31_2019.pdf
says there were 95 regular and 4 corporate members.

Hope that helps,

Robert.

> 13 Nov 2019, 16:08 by talk-gb@openstreetmap.org:
>
> Someone involved with OSM-UK may wish to check the definition of The British 
> Isles:
> https://www.britannica.com/place/British-Isles
>
> They may also wish to have a read of this:
> https://www.gov.im/about-the-government/departments/cabinet-office/external-relations/constitution/
>
>
> What is the size of OSM-UK's membership?




-- 
Robert Whittaker

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

Re: [Talk-GB] Name Suggestion Index

[Robert Whittaker (OSM lists)]

On Tue, 5 Nov 2019 at 08:24, Jez Nicholson  wrote:
> I was wondering how iD (and Vespucci) decides what to offer as brands when I 
> create a new feature, or when it suggests something like "Ibis looks like a 
> brand with incomplete tags". The answer is the 
> https://wiki.openstreetmap.org/wiki/Name_Suggestion_Index (NSI) ...now 
> detailed on a wiki page that I created.
>
> The NSI is a github repository, so updates and editions can be suggested. 
> This can be done via your own fork or on the OSMUK fork. I'm not sure what 
> will work best for us yet.

I stumbled across the NSI myself a couple of months ago, while looking
to add brand tags to shops in my local area though iD. I've been
collecting a list of missing UK brands (or at least ones that iD
didn't suggest) and also some potential errors (e.g. where it's
assumed all shops of a certain brand have a specific shop tag, when in
reality there can be some variation in the types of outlets). What I
haven't looked into yet is the mechanics of how to suggest
adding/correcting entries and what other info is needed for each one.
(Submitting github issues and pull requests for each individual brand
seems like a lot of effort on the face of it -- but maybe that's what
you need to do.)

In case anyone is interested in adding these, or providing details of
how to do it, here's the list of missing brands that I've collected so
far (some may have been added since I started collecting):

  Animal (Clothes)
  Barnado's (charity)
  Bill's (retaurant)
  Bon Marché (clothes)
  Byron (restaurant/burgers)
  Café Rouge (restaurant)
  Card Factory (cards)
  Fred Olsen Travel (travel_agent)
  Hughes (electrical goods)
  Johnsons (dry_cleaning)
  Jones the Bootmaker (shoes)
  Mr. Shoes (shoes)
  Muffin Break (Cafe)
  Scrivens (optician)
  Timpson (key-cutting / shoe_repair)
  The Perfume Shop (perfumery)
  Topman / Topshop (clothes)
  TUI (travel_agency)
  William H Brown (estate_agent)
  YMCA (charity shop)
  Yours (clothes)

And here are the one I think there are problems with:

  Greggs (allow amenity=cafe or shop=bakery or both)
  Clintons (should recognise shop=cards as well as shop=gift when
suggesting 'upgrades' in iD)

Best wishes,

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] OS Map Rules

[Robert Whittaker (OSM lists)]

On Mon, 4 Nov 2019 at 23:38, Andrew J  wrote:
> I was thinking of using a paper OS map to identify public footpaths
> which are not currently on OSM, and use it to plan and navigate (map and
> compass) a route along those paths.
>
> If I get a GPS trace (e.g. with OSMTracker) while I walk that route, is
> it acceptable to use this GPS data to update OSM, or would it be
> considered a derivative of OS data?

It depends on exactly what you do. If you're slavishly following the
line on the OSM map and collecting a GPS trace of that line, then all
you're really doing is copying (in a somewhat roundabout way) the
coordinates of points along OS's line into OSM, and I think that would
violate OS's copyright. On the other hand if you use the OS map to
determine that there's a Right of Way that needs mapping in a certain
locality, and then collect a GPS trace by following signs and trodden
paths on the ground, that would be fine.

Depending on which part of the country you're in, there might already
be an open dataset of Rights of Way that you can use, which isn't
encumbered by OS's copyright. See the list I maintain at
https://osm.mathmos.net/prow/open-data/ . In theory, Freedom of
Information legislation means any currently-non-available datasets can
be obtained. It can take a bit of effort to do this, but I'm happy to
oblige if someone wants the data opened up for use in OSM.

Best wishes,

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Zebra crossings being lost in iD - how to respond

[Robert Whittaker (OSM lists)]

On Fri, 25 Oct 2019 at 11:45, Jez Nicholson  wrote:
> +1 for a bot edit

My initial instinct was to say this too. But if most of these
crossing=zebra tags were added by iD users who selected "Marked
Crossing" and never saw the zebra tag, then how sure are we that
almost all Marked Crossings in the UK will be zebras?

Perhaps a Maproulett challenge would be a better way, if aerial
imagery is usually good enough to identify zebra crossings.

> are you suggesting to just add crossing_ref=zebra, or to convert 
> crossing=zebra into highway=crossing + crossing=uncontrolled too?

If edits are made, we should convert the crossing=* tag too. But we
should probably decide what value that should take. iD seems to be
suggesting crossing=marked rather than crossing=uncontrolled. However,
the former is not documented in the wiki:
https://wiki.openstreetmap.org/wiki/Key:crossing .

It would also be really good if we could get the standard UK crossing
types (zebra, pelican, toucan, pegasus) added to the iD presets to
help UK editors add that information. Currently typing those names in
iD doesn't give anything helpful (apart from zebra that returns
"Marked Crossing") and there are only the marked and unmarked crossing
options if you type "crossing" in.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-at] Fwd: Mittersill: gelöschte Schule wiederherstellen

[nine-osm . org-lists]

Hallo Andereas,

vari...@mailbox.org wrote on 9/18/19 8:53 AM:
[...]

> Wenn es sonst keine Einwände gibt, würde ich den User
> https://www.openstreetmap.org/user/Maci255  in einem Changeset kurz
> informieren, dass solche Tests nicht im Live-System gemacht werden
> sollten und, dass ich seine ganzen Changesets zurücksetzen werde.

Vielen Dank, dass du dich um diesen Revert und die Information von
Maci255 kümmerst.

Guten Tag
Erwin

>> andreas wecer  hat am 18. September 2019 um
>> 08:26 geschrieben:
>>
>> Am Mi., 18. Sept. 2019 um 07:45 Uhr schrieb <
>> nine-osm.org-li...@sunch.at >:
>>
>> Wie kann man in der History eines Ausschnittes sehen was gelöscht
>> wurde?
>> Bzw. wie kann man gelöschte Objekte wieder herstellen? 
>>
>>
>> Wenn man genau weiß, wo und was man sucht, ist das einfachste, was ich
>> kenne, immer noch Potlatch 1: 
>> https://help.openstreetmap.org/questions/23631/how-do-i-find-and-recover-a-deleted-way
>>
>>
>> Du kannst es auch über Tools wie  https://osmcha.mapbox.com/ oder 
>> https://overpass-api.de/achavi/ finden und in JOSM per Datei->Objekt
>> wiederherstellen, wenn du die ID des Objekts kennst
>>
>> Die Schule wurde offenbar durch dieses Changeset (oder eines der
>> anderen des Users) gelöscht: 
>> https://www.openstreetmap.org/changeset/68139322
>>
>> LG
>> Andreas
>> ___
>> Talk-at mailing list
>> Talk-at@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-at
> 
>  
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
> 


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

[Talk-at] Fwd: Mittersill: gelöschte Schule wiederherstellen

[nine-osm . org-lists]

Hallo,

in Mittersill ist die Schule von der Karte verschwunden:

https://www.openstreetmap.org/#map=19/47.28149/12.48566
https://www.google.at/maps/@47.2813061,12.4845245,331m/data=!3m1!1e3

Wie kann man in der History eines Ausschnittes sehen was gelöscht wurde?
Bzw. wie kann man gelöschte Objekte wieder herstellen?

LG
Erwin


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

Re: [Talk-GB] UK Licences

[Robert Whittaker (OSM lists)]

On Tue, 10 Sep 2019 at 13:49, Stephen Colebourne  wrote:
> I'd like to see some guidance on whether data can be taken directly
> from a business's website and entered directly into OSM. eg. on the
> "contact us" page there is often address, postcode, phone number,
> opening hours. This page
> https://wiki.openstreetmap.org/wiki/Key:postal_code says "You can even
> look them up on the official website of the place" which suggests you
> can, but normal copyright of websites would suggest you can't.

My take is that if it's an independent store with a single site, or a
small group -- say up to about half a dozen premises -- then you can
use the address(es) listed on their official website, as they're
un-copyrightable facts. For chains with more stores, the addresses of
each branch will form part of a database, and then database rights put
them off-limits for OSM, unless you get specific permission from the
business.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Fixing shop=yes, now it no longer renders on the default

[Robert Whittaker (OSM lists)]

On Thu, 5 Sep 2019 at 21:35, Mike Baggaley  wrote:
> Hi Robert, Looks interesting. I've signed in and had a look. However, the 
> first one I looked at is a petrol station, and the wiki indicates that 
> shop=yes is the correct tagging as an additional tag for amenity=fuel. Hence 
> I suggest that these be omitted from the list requiring replacement.

I'd say that it's no more or less correct to use shop=yes there than
any other instance of shop=yes, as it still indicates a generic shop
of unspecified type. As it suggests at
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel , shops at
petrol stations can also be mapped with a more specific type, such as
shop=convenience or shop=kiosk. I think this is preferable, so I'd
like to leave them in the list. That said, changing them is perhaps
less important than other instances, so they're set as low priority in
the Maproulette challenge. I think that means if you're getting new
tasks randomly, they should be less likely to come up.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Fixing shop=yes, now it no longer renders on the default OSM map

[Robert Whittaker (OSM lists)]

On Tue, 3 Sep 2019 at 12:40, Silent Spike  wrote:
> Perhaps a https://maproulette.org challenge would be a good way to track the 
> progress of this?

I've never really used Maproulette before, but I thought this would be
a good opportunity to have a go. So here's my attempt at a challenge,
for anyone who is interested in using it:
https://maproulette.org/browse/challenges/9051 .

Robert.

--
Robert Whittaker
https://osm.mathmos.net/

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

Re: [Talk-GB] Copyright in OS-derived maps

[Robert Whittaker (OSM lists)]

On Tue, 3 Sep 2019 at 12:34, Edward Bainton  wrote:
> I've been sent a map by a local charity that looks after large swathes of 
> countryside near Peterborough. It's for their own internal use, showing the 
> extent of their estate. It's based on an OS map, and comes with flags 
> indicating Crown copyright
[snip]
> The bit I'm interested in is a red line picking out the boundary of the 
> charity's territory - I asked if I could put these into OSM. That line was 
> presumably drawn by the charity, albeit over an OS base. (Tho I suppose just 
> possibly OS drew the red line under commission, and then I think the default 
> is that they have the copyright.)
>
> Where do I go with the legal side of things? Is this a complete dead end as 
> the wiki on copyright suggests? Or, if further enquiries reveal that the red 
> line is of the charity's own production, can the charity grant me (OSM) a 
> licence to reproduce the red line (and only the red line) on OSM?

If the line has been drawn on the OS basemap by reference to features
on the base map, then OS regards the line as "Derived Data" and claims
IP rights in it. (The alternative would be if the line was
independently surveyed (e.g. from a GPS trace), and then just layed on
top of the OS map. In which case OS wouldn't claim any rights in the
line itself.) See
https://www.ordnancesurvey.co.uk/business-and-government/help-and-support/public-sector/guidance/derived-data.html

There is a mechanism for OS licensees to release derived data under
the Open Government Licence. But reading
https://www.ordnancesurvey.co.uk/business-and-government/help-and-support/public-sector/licensing-using-os-data.html
it's not clear to me if this only applies to Public Sector Bodies that
are part of the Public Sector Mapping Agreement (PSMA). If the charity
isn't a PSMA member, I think they would have to contact OS to find out
what is allowed. A slight complicating factor if we were to be able to
use the line in OSM is that we'd have to remove the OS base map from
it before using it.

Assuming you have a friendly contact at the charity and the region
isn't too large/complicated, a more pragmatic approach might be to see
if someone there has enough personal knowledge of the area they cover,
*without* needing to refer to the OS-derived map, to be able to draw
the boundary on an OSM base map for you. You could then use that map
in OSM with just their permission.

Robert.

-- 
Robert Whittaker
https://osm.mathmos.net/

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

[Talk-GB] Fixing shop=yes, now it no longer renders on the default OSM map

[Robert Whittaker (OSM lists)]

Since version 4.22 of the Carto map style (which was deployed a few
days ago), the generic shop=yes tag is no longer rendered on the
default OSM-Carto map at https://www.openstreetmap.org/ . For details
of the decision see
https://github.com/gravitystorm/openstreetmap-carto/issues/3697 .

In Great Britain,
https://taginfo.openstreetmap.org.uk/keys/shop#values shows we
currently have 7,772 objects tagged with shop=yes, which represents
4.18% of our total shop=* objects. These objects will no longer appear
on the default map (unless they have other renderable tags). To have
the objects display again, we need to give them more specific shop=*
tags. Often, an appropriate shop value can be deduced from the shop
name, its website, or other existing tagging on OSM, without needing a
ground survey.

Any mappers with a few minutes to spare might like to have a look at
their local area, and see if there are any shop=yes objects they could
re-tag with a more specific value. Some resources to help:

* Overpass Turbo query to find shop=yes objects:
http://overpass-turbo.eu/s/M0w (Pan/zoom to the area of interest, then
click on run. Try a smaller area if the query times out.)

* OSM WIki Key:Shop page, with values for common shop types:
https://wiki.openstreetmap.org/wiki/Key:shop

* Taginfo GB shop values:
https://taginfo.openstreetmap.org.uk/keys/shop#values (Use the search
box at the top right of the *table* to get suggestions for the common
tag for a particular shop type.)

Best wishes,

Robert.

-- 
Robert Whittaker
https://osm.mathmos.net/

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

Re: [Talk-GB] Rowmaps importing in South Gloucestershire

[Robert Whittaker (OSM lists)]

On Fri, 9 Aug 2019 11:59 Dave F via Talk-GB, 
wrote:

>
> >
> https://wiki.openstreetmap.org/wiki/Contributors#Public_Rights_of_Way_Data_from_local_councils
> > . While there's nothing listed there, it's definitely not ok to use
> > the data in OSM.
>
> Rubbish.
>
> Just because one person isn't aware of a fact, it doesn't make it untrue.
> No one person has authority over other OSM contributors.
>

I'm not sure I follow what you're saying here. My point was that if any
mapper is using data under a licence that requires attribution, then they
can only do so if the required attribution is given on either
https://www.openstreetmap.org/copyright or
https://wiki.openstreetmap.org/wiki/Contributors . Otherwise OSM would be
violating that licence by distributing a derived work without the
attribution.

So assuming permission to use the South Gloucestershire data is conditional
on some attribution (which is the case for e.g. the OGL) then it needs to
be listed as a source on the contributors page, with the appropriate
attribution given.

(Separately, I think it's also important from a community verification
point of view that sources and licences are documented, so other mappers
can check we have the necessary rights to use any claimed sources, and
there is evidence if anyone challenges our use of particular data.)

Robert.

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

Re: [Talk-GB] Rowmaps importing in South Gloucestershire

[Robert Whittaker (OSM lists)]

On Thu, 8 Aug 2019 at 23:06, Neil Matthews  wrote:
> In light of some recent edits in South Gloucestershire -- is it ok to
> import unsurveyed footpaths based simply on rowmaps data?

Based on the licensing information at
http://www.rowmaps.com/datasets/SG/ my view would be "no". According
to what's written there,the data on Rowmaps was only licensed by South
Gloucestershire Council under the (old) OS OpenData Licence. This
licence is not compatible with the ODbL used by OSM, due to the viral
attribution that would be required even in produced works. I believe
that what's written on the Rowmaps page is misleading, as to be used
under a different licence (e.g. the OGL v3) the rights holder (i.e.
the Council) would need to explicitly re-license their data -- OS
cannot unilaterally do it for them. (I guess it's possible that
whoever is doing the editing has contacted the council directly and
got permission to use the data under the OGL, although I don't see
this documented anywhere.)

There's also the separate question of whether it's a good idea to
import PRoW routes solely from (correctly licensed) external data. I
don't think this is a good idea, since we want to capture the actual
route on the ground as well as the definitive line. Without a ground
survey, local knowledge, or the use of aerial imagery (e.g. for
visible tracks) you won't be able to know the former. The data on
Rowmaps is also somewhat old -- it would be better to request an up to
date copy from the Council.

Finally on a practical level, any license to use the data will almost
certainly require some attribution from OSM if it's used. I can't see
anything related to South Gloucestershire on the contributors page at
https://wiki.openstreetmap.org/wiki/Contributors#Public_Rights_of_Way_Data_from_local_councils
. While there's nothing listed there, it's definitely not ok to use
the data in OSM.

Robert.

PS: I've got a list of licences and availability of PRoW data for
different councils at https://osm.mathmos.net/prow/open-data/ , which
I try to keep up to date. Please let me know of any corrections you
spot that need making.

-- 
Robert Whittaker

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

Re: [Talk-at] mapwith.ai

[nine-osm . org-lists]

vari...@mailbox.org wrote on 7/25/19 11:26 PM:
> Die Thailänder und die sind nicht sehr begeistert, wie es aussieht. 
> https://forum.openstreetmap.org/viewtopic.php?id=66900 oder 
> https://forum.openstreetmap.org/viewtopic.php?id=63456 und das liest sich 
> ziemlich fatal. 
> 
> Ich dachte mir erst in Thailand oder Afrika könnte ich mir das schon 
> vorstellen, wo die Ratio Mapper/"zu mappende Sachen" sehr groß ist, nach dem 
> lesen der Threads sieht das nicht so aus.
> 
> Sehr skeptisch.  

Danke fürs Teilen deiner Eindrücke!
LG
Erwin

>> nine-osm.org-li...@sunch.at hat am 25. Juli 2019 um 21:49 geschrieben:
>>
>>
>>
>> Hallo OSM Comunity,
>>
>> FB veröffentlicht AI unterstütztes Map-Tooling via https://mapwith.ai/
>> Heise schrieb gestern darüber:
>> https://www.heise.de/newsticker/meldung/Map-With-AI-Facebook-unterstuetzt-OpenStreetMap-Community-4478433.html
>>
>> Schon jemand Erfahrungen damit?
>>
>> LG
>> Erwin
>>
>> ___
>> Talk-at mailing list
>> Talk-at@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-at
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
> 


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

[Talk-at] mapwith.ai

[nine-osm . org-lists]

Hallo OSM Comunity,

FB veröffentlicht AI unterstütztes Map-Tooling via https://mapwith.ai/
Heise schrieb gestern darüber:
https://www.heise.de/newsticker/meldung/Map-With-AI-Facebook-unterstuetzt-OpenStreetMap-Community-4478433.html

Schon jemand Erfahrungen damit?

LG
Erwin

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

Re: [Talk-GB] Automated Code-Point Open postcode editing (simple cases only)

[Robert Whittaker (OSM lists)]

On Tue, 16 Jul 2019 at 22:20, ndrw6  wrote:
> Over past several months I've been adding postcodes from Code-Point
> Open. I've streamlined the procedure a bit, so I can now add the tags
> without spelling out every single one of them, but it is still a manual
> and labour intensive process:
>
> https://github.com/ndrw6/import_postcodes/
>
> While working on that, I've noticed there are a lot of simple cases
> where automatic collation would have produced very similar results. For
> example, in case of existing OSM buildings without an addr:postcode tag
> located at or very near to a Code-Point Open centroid.
>
> Therefore I'm requesting permission to use the following automated edit
> procedure:

I'm afraid I think this new suggestion will be too prone to errors to
outweigh the benefits, so I have to oppose it, unless there's
significant manual curation. In which case though, you might as well
not bother with the 15m limit and instead look to find the true
extents of the postcode unit. I'm also not convinced that the previous
work on adding postcodes to single buildings in isolation is that
beneficial. In particular, the new proposal has the following issues:

* Not all buildings are addressable properties, and so some (e.g.
garages, outbuildings) shouldn't have a postcode. How would you avoid
accidentally adding postcodes to these?

* Large-user postcodes only belong to a single building, and shouldn't
be added to any nearby buildings, however close. It's not clear how
you would avoid these with the proposed method. (For example it's
common for a bank to have its own postcode, but the buildings either
side along the high street will all share a different postcode.)

* Often the two sides of a street will have different postcodes. So in
the case of terraced houses, you may have an opposite property within
15m belonging to a different postcode unit.

There are also some problems with the existing method:

* Sometimes OSM building polygons encompass several joined properties
(e.g. a terrace or a row of shops). Adding a single postcode to such a
building polygon might be incorrect, as the properties may not all
share the same postcode.

* Adding postcodes in this way removes a convenient way for other
mappers to work on adding more detail, by looking for postcodes that
are not yet in OSM.

I would argue that the benefits of adding just a postcode to a
building corresponding to the centroid are pretty small -- any users
can already use code-point open to obtain this information. The real
value in adding postcodes to OSM is when they combined with other
address information (e.g. street names and house numbers to give a
full address) and when human extrapolation is used to infer the full
set of properties that have the same postcode.

I thus have to object not just to the new proposal but also any
continuation of the previous work to add single postcodes to buildings
under the centroid. Instead I would suggest it would be better to
proceed more slowly and take the time to add addr:street (and other
addr tags) tags when adding postcodes, and also try to add the
postcode to the full set of properties for each unit where this can be
deduced. See the discussion at
http://sk53-osm.blogspot.com/2013/12/british-postcodes-on-openstreetmap.html
. For instance at http://overpass-turbo.eu/s/KRf only the highlighted
buildings have postcodes and none have streets. It should be possible
to infer the postcodes of most of the houses from the centroid
locations, and also add the addr:street tags in that area. A tool that
finds postcode units whose centroid lies on top of an existing OSM
building would still be a good way of finding instances to apply this
procedure to though. Better still if it could prioritise areas with a
high density of small buildings (i.e. a systematic import/ tracing of
buildings) that also lack postcodes.

Best wishes,

Robert.

> 1. Open an osm file containing missing postcodes (from the above
> website) in jOSM
>
> 1a. Select all points from the above dataset
>
> 2. Download OSM data in the area of interest
>
> 2a. Select all ways with a "building" tag of typical residential house
> size and without an "addr:postcode" tag (search phrase: 'building
> -"addr:postcode" type:way areasize:50-1000')
>
> 3. Use a collation plugin to collate both datasets with "centroid
> distance" set to "< 15m". The condition is there to apply postcodes only
> to small buildings in direct vicinity of the codepoint centroid.
>
> There are some caveats I've noticed, often not different from manual
> editing:
>
> a) Some buildings have addresses added as separate points rather than
> tags (automated edit will add addr:postcode tags directly to the
> building, this is what I chose to do manually as well)
>
> b) Collation plugin doesn't support relations (these postcodes will get
> ignored and can be added later manually)
>
> c) Often OSM buildings contain multiple addresses or postcodes and
> should be split into several 

Re: [OSM-legal-talk] Copy information from official business website (WAS: Proposal for a revision of JA:Available Data)

[Robert Whittaker (OSM lists)]

On Fri, 5 Jul 2019 at 21:18, tomoya muramoto  wrote:
> I ask a simple question. May I copy the information of the TESCO Boston 
> Superstore to OSM?
> https://www.tesco.com/store-locator/uk/?bid=2108
>
> This website contains information such as
> - addr=*
> - phone=*
> - opening_hours=*
> - branch=*
>
> The OSM data for this store does not yet contain `phone=*` nor 
> `opening_hours=*`. Can I copy them to OSM?
> https://www.openstreetmap.org/way/61998754

For a single store I believe the answer is yes, since you're
extracting un-copyrightable facts. But if there are a significant
number of stores (as in this case), then the information becomes part
of a database, which is by default protected by database rights (at
least in the EU). You then can't use a significant amount of the
information without an appropriate licence. Moreover, you can't safely
take details from a single store from a chain's website, as there's a
danger that lots of other mappers might do that independently for
different stores, resulting in an infringement for OSM as a whole.

So for practical, use in OSM, I'd say it's ok to take information from
the public website of an independent store, or a group with up to
around half a dozen outlets. But anything larger, and you'd need to
get permission from the company first.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Adjacent nature reserves

[Robert Whittaker (OSM lists)]

On Wed, 26 Jun 2019 at 21:08, Brian Prangle  wrote:
> The whole area needs simplification to replace multiple overlaid ways with 
> multipolygon relations.

I'm curious about what you mean here. Are you referring to replacing
(in a simple example) two square closed ways that share a common edge,
with three non-closed ways (two with three segments, and one with one)
and two relations to represent the original two squares? If so, I've
seen this done in various places, but I've never understood the point
it. The two representations are identical in terms of the data, but
the latter requires 2.5 times as many objects and is much more of a
pain to work with in the editors. All to avoid having a common line
segment between two areas -- which doesn't seem to be a particular
problem to me. Are there some advantages that I'm missing?

Thanks,

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] OS Open Greenspace tileset

[Robert Whittaker (OSM lists)]

On Fri, 14 Jun 2019 at 10:24, Richard Fairhurst  wrote:
> I've put together a simple tileset showing greenspace areas from Ordnance 
> Survey's recent OS Open Greenspace release. The data is released under the 
> standard OS open licence therefore suitable for tracing in OSM.
>
> Many features are already in OSM, but not all, and in addition the names 
> might be helpful.
>
> The tiles also include a few greenspace-related features from OSM and the 
> basic OSM road/path network.
>
> You can add the tiles to your favourite editor using this URL:
> http://osm.cycle.travel/greenspace/{z}/{x}/{y}.png

That's great -- many thanks Richard. A related existing service is
https://openover.raggedred.net/ , which shows OS Greenspace and also
Access Land polygons.

By the way, if anyone is in to tileservers for helping OSM, some tiles
with a rendering of OS Open Roads (with their names) would be really
useful I think:
https://www.ordnancesurvey.co.uk/business-and-government/products/os-open-roads.html
.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Preston Park, Brighton

[Robert Whittaker (OSM lists)]

On Tue, 4 Jun 2019 at 11:15, Jez Nicholson  wrote:
> I have to admit that Preston Park is my personal micromapping playground. I 
> walk the hound there nearly every day and I can capture excruciating detail 
> (so shoot me!). 
> https://www.openstreetmap.org/note/1800140#map=18/50.83914/-0.14432=N
[snip]
> Could I add the Parkrun route as a relation?

I think mapping parkrun routes is a good thing. They take place
regularly almost every Saturday morning and are certainly verifiable
on the ground during those times. Most routes are the same each week,
though some events have an alternative version for the winter, or to
avoid flooding or other events in the park.

Parkrun's own website has route maps drawn over Google Aerial Maps,
which (from experience) aren't always very good. The routes can be
inaccurate and it's not always easy to see paths on the ground in the
imagery. It's also not always easy to see the direction and
progression of multi-lap routes. It would be great if we could get
better coverage and then persuade parkrun to use a rendering based on
OSM. I think the difficult thing to do would be to off-set parts of
the route that are covered more than once (like you do on bus route
maps when more than one route follows the same road), so the entire
route can be traced. Does anyone know if there are any libraries or
leaflet extensions that do this already?

Robert.

PS: Full disclosure: I'm a run director at Thetford parkrun, and have
mapped a number of events I've run in OSM. e.g.
https://www.openstreetmap.org/relation/2812625 for
https://www.parkrun.org.uk/thetford/course/

-- 
Robert Whittaker

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

Re: [Talk-GB] Electric car charging points

[Robert Whittaker (OSM lists)]

On Thu, 16 May 2019 at 21:31, BD  wrote:
> Some time ago I came across "National Charge Point Registry", which can be 
> found here:
> https://data.gov.uk/dataset/1ce239a6-d720-4305-ab52-17793fedfac3/national-charge-point-registry
>
> I wonder if we could import that data into OSM? I'm sure that it would be 
> useful to the greater community and general public.

As it happens, I've just started having a play with this data. I
haven't got a full comparison tool working yet, but you can get an
idea of how the NCR data compares to what we currently have in OSM at
https://osm.mathmos.net/chargepoint/progress/ (click on one of the
postal areas on the map to see that data for it).

It appears that the NCR data is not all that complete, and I'm also
not sure the locations are accurate enough for a direct import. Given
other micro-mapped features near charging points, we'd want to get the
locations relative to them correct. There are also charge-point
locations in the NCR that are 10's of meters away from where they
actually are on the ground. (Some examples at
https://osm.mathmos.net/chargepoint/progress/NR/#15/52.6253/1.2994 . )
There is certainly scope for using the data to improve coverage and
detail in OSM though.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] OSMappers meeting in Norfolk

[Robert Whittaker (OSM lists)]

On Sun, 12 May 2019 at 20:31, Rob Nickerson  wrote:
> I hope the Norfolk event went well yesterday. I hope to see some more in the 
> future.

Yes, I think it went well, and many thanks to Nora for taking the
initiative and organising it. I've put together a quick wiki page for
what will hopefully be a series of Norfolk meetups, along with some
notes and links about the things we discussed:
https://wiki.openstreetmap.org/wiki/Norfolk/Meetups . I'd encourage
others to add anything I've missed, and put links to their user pages
if they want.

Robert.

-- 
Robert Whittaker

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

[Talk-GB] Use of amenity=university within the University of Cambridge

[Robert Whittaker (OSM lists)]

I've noticed that there are rather a lot of amenity=university objects
in Cambridge, most of which seem to be on individual buildings rather
than actual universities or even university sites.
http://overpass-turbo.eu/s/HLV This seems to be in line with the
tagging scheme described at
https://wiki.openstreetmap.org/wiki/Cambridge/University_of_Cambridge
, but doesn't follow what it says at
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Duniversity
"Individual elements of the university should not be tagged with
amenity=university but can be mapped with operator=* and the name of
the university".

The latter suggests that there should only be one amenity=university
object per institution, with individual sites combined via a
multi-polygon. I'm not sure I'd go quite that far, and I would be ok
with using using amenity=university on the outline polygon of each
site occupied by a university. At any rate I think it's wrong to
classify individual internal buildings/features within each site as
amenity=university.

What do other people think? Could we get an agreement to at least
remove the amenity=university tags from buildings etc within each
larger university site? How best to tag university sites/campuses is
perhaps a larger discussion, that it may take longer to reach a
consensus on.

Robert.

PS: I'll invite David Earl to comment here, as he was behind the
Project Drake work that did a lot of the mapping of University
buildings.

-- 
Robert Whittaker
https://osm.mathmos.net/

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

Re: [Talk-GB] Common Land has stopped rendering

[Robert Whittaker (OSM lists)]

On Sat, 16 Mar 2019 at 12:55, Edward Catmur via Talk-GB
 wrote:
> Any conclusion on how to tag them now?
>
> Perhaps leisure=park, park=common?

For places in the UK that are actually registered common land, then
I'd suggest using designation=common_land to denote that fact, as it's
an official designation. (Similarly we can use
designation=village_green for areas that are recorded as Village
Greens. See https://www.gov.uk/common-land-village-greens for the
legal definitions.) Public access can be tagged using access=* tags in
the usual way. That just leaves the question of how to tag the
physical nature of the land. I'd have thought in most cases one of
leisure=park (which can be interpreted quite widely I think, given
what's on the Wiki page), leisure=recreation_ground, natural=heath,
natural=scrub and natural=meadow would probably be appropriate.

Robert.

> On Sat, 16 Mar 2019, 12:51 SK53,  wrote:
>> Yup, it's gone. I think the standard thing is use Andy's (SomeoneElse) map 
>> which is likely to retain features of value & relevance to British & Irish 
>> map users.
>>
>> On Sat, 16 Mar 2019 at 12:35, Ian Caldwell via Talk-GB 
>>  wrote:
>>> In the last day or two the standard renderer as stop rendering  common land 
>>> (leisure=common) see https://www.openstreetmap.org/way/311973831



-- 
Robert Whittaker

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

[Talk-GB] OSM Tool Updates

[Robert Whittaker (OSM lists)]

Just a quick message to let people know about a few recent updates to
my OSM UK tools:

* I've added a new class of objects to "Survey Me!" -- a tool to help
mappers find local issues in need of a ground survey. OSM objects with
no name=* tag where one would be expected are now shown with deep blue
markers at https://osm.mathmos.net/survey/ . Details of the criteria
used (currently I'm only searching shop=* and some amenity=* objects)
and a summary of the objects found is at
https://osm.mathmos.net/nameless/ .

* Three new sets have been added to "Ghosts" -- a tool to flag up
closed or renamed shops/services: "Phones 4U" (closed but 47 remain in
OSM), "Orange and T-Mobile" (merged to become EE, but 20 remain in
OSM) and "That's Entertainment" (closed but 8 remain in OSM). More
details at https://osm.mathmos.net/ghosts/ and the objects also appear
on "Survey Me!". Thanks to mapper "lakedistrict" for the suggestions
here.

* I've recently got an updated list of the AEDs (Defibrillators) in
the East Midlands Ambulance Service region. The new data is now in my
comparison tool at https://osm.mathmos.net/defib/progress/ .

I hope some other people find these tools useful. Please let me know
if you've got any suggestions for improvements.

Robert.

-- 
Robert Whittaker
https://osm.mathmos.net/

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

Re: [Talk-GB] OSM Hi-vis

[Robert Whittaker (OSM lists)]

On Mon, 7 Jan 2019 at 23:46, Rob Nickerson  wrote:
> OSM UK are now taking orders for high-vis vests. Show your support for 
> OpenStreetMap by ordering one or more today at:
>
> https://osmuk.org/product/osm-uk-hi-vis-vest/

Based on the sample you have, do you have any advice over the sizes?
Presumably most people will want their hi-viz to fit over a coat, so
should we go up a size from our normal? How does the (presumably)
chest size quoted related to the actual circumference of the jacket
when done up?

Thanks,

Robert.

-- 
Robert Whittaker

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