Re: [OSM-talk] recommendation for JSON to CSV converter

[Colin Smale]

> On 28/02/2024 17:30 CET Martin Trautmann via talk  
> wrote:
> 
>  
> On 28.02.24 16:43, Mike Thompson wrote:
> > Hi Martin,
> > 
> > Could you provide some more detail on what specifically you are
> > attempting to achieve? Converting a geojson file of points to CSV is
> > pretty easy, but once you get to linestrings, multi-linestrings,
> > polygons, etc. it gets difficult because in those cases the geometry
> > objects have a variable number of components.  
> 
> Hi Mike,
> 
> what I need is
> 
> Strassenna;HsNr_Zus;StrSchlues
> Stinnesstr.;8;02968
> 
> ..which I could grep easily, but I would also need to know in which
> "Gemeinde" that is, including their "Amtlicher Gemeindeschlüssel (AGS)"

Have you looked at "jq"?
Some tips here:
https://qmacro.org/blog/posts/2022/05/19/json-object-values-into-csv-with-jq/
https://richrose.dev/posts/linux/jq/jq-json2csv/

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

Re: [OSM-talk] razed railways and other things that don't exist today

[Colin Smale]

 

> On 25/10/2022 19:18 CEST Brian M. Sperlongano  wrote:
>  
>  
>  
> On Tue, Oct 25, 2022 at 4:37 AM Frederik Ramm  mailto:frede...@remote.org> wrote:
> 
> > in the spirit of friendly collaboration I would say that a limited amount of
> > stuff-that-should-not-be-in-OSM can be *tolerated*. If someone does a
> > lot of good work for OSM otherwise and would really like to record an
> > ancient former railroad that ran through where their house now sits - I
> > shrug and let them do it.
> > 
>  
> In my experience, it is more often the opposite situation that happens.  A 
> mapper, unaware of the lengthy debates on the topic of former railroads, is 
> mapping her house and removes the bit of abandoned rail currently on the map 
> in that spot, assuming it is a data error or poor import.  After all. she's 
> quite aware that there is a house and not a railway at that location as she 
> has personally surveyed it.  Sometime later, an abandoned railway enthusiast 
> comes along and angrily harasses the mapper for removing the bit of railway 
> that quite rightly isn't there. It's been my experience that allowing 
> enthusiasts to map phantom railways causes far more grief and contention 
> between mappers than simply drawing a line and saying "we don't map things 
> that aren't there."
> 
I expect pages with "This page intentionally left blank" save quite a few calls 
to customer service. I.e. if you draw a line and label it somehow "this line 
should not be here" you might defuse the argument and to a point where 
live-and-let-live counts again. Putting an end-date on it might be a start.
 
Are underground pipelines and electricity transmission cables just as 
controversial? They are covered over, built on, and completely unobservable 
from the surface. They may also have been taken out of service many decades ago.
 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-nl] Bot Phone Number Formatting Proposal

[Colin Smale]

You will need to be careful with (most) 08/09 numbers in the length check as 
you cannot determine algorithmically what the length should be. Although these 
numbers are not (normally) dialable from outside the country it's still a good 
idea to put them in E.164 international format. Like that, if you try to dial 
the number while you are in France for example you will get an error tone 
rather than a random French person.


The number '+31 01620 456 790’ could IMHO be safely corrected automatically - 
the extra "0" is a common mistake, the intention is pretty clear and ignoring 
the "0" yields a valid number.
Are you able to distinguish between 2-digit and 3-digit area codes?



> On 07/06/2022 09:45 Marc Zhou Toneu via Talk-nl  
> wrote:
> 
> 
> 
> 
> Morning,
> 
> 
> Here is a list of some of the nodes that would require a manual correction:
> 
> * 2796279335: '+31 499 475415;toets 1 voor spoed'
> * 2818035695: '+31 6 165 567 969’
> * 2818064864: '+31 65397447’
> * 2824141858: '+31 13 522 09 72 "emergency”'
> * 2824141869: '+31 13 522 09 72 "emergency”'
> * 2824142102: '+31 13 528 6060 "Algemene spoedljn OisterwijkKliniek"’
> * 2853116449: '+31 0162 – 242 006 of +31 06 – 421 27 994.’
> * 2853564877: '+31 01620 456 790’
> * 6176636305
> * 2862917377
> * 2724284582
> * 34206650: '09002357275 13ct/m’
> 
> 
> One question regarding to have phone number description in the phone tag 
> though, are we allowed to have description in the phone tag other than the 
> actual phone number? I couldn’t find any conventions about it.
> 
> 
> Vast majority of bad phone tag values are either not following the proper 
> syntax of separation of multiple values in one tag 
> , invalid 
> phone tag value such as invalid number or having the contact:website value as 
> the phone number.
> 
> 
> 
> Example of nodes that would need format correction (there are thousands of 
> nodes that would require format correction):
> 
> * 1653511382: '+31 (222) 319 309'  ==>  '+31 222 319 309'
> * 821734360: '+31 297 324548;+31 172 508360'  ==>  '+31 297 324 548; +31 172 
> 508 360’
> * 520290181: '0204276833'  ==>  '+31 20 427 6833’
> 
> 
> 
> 
> I am still working on the script, it’s expected that I will be done with it 
> later today or tomorrow. I’ll let you know when I’ve created a repo for it.
> 
> 
> Regards,
> Marc
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > On Jun 7, 2022, at 09:15, Maarten Deen  > > wrote:
> > 
> > 
> > Do you have a link to your script and maybe some examples of phone numbers 
> > that need correcting?
> > 
> > 
> > 
> > Regards,
> > 
> > Maarten
> > > Op 06-06-2022 21:11 schreef Marc Zhou Toneu via Talk-nl 
> > > mailto:talk-nl@openstreetmap.org>>:
> > > 
> > > 
> > > 
> > > To whom it may concern,
> > > 
> > > 
> > > I’ve recently written a pythons script that would automatically format 
> > > the phone numbers in NL should it be wrongly formatted, and I would like 
> > > to hear your opinion about it.
> > > 
> > > 
> > > So far I am proposing to do the following:
> > > 
> > > * Formatting phone numbers according to the ITU-T E.123 format pattern
> > > * Phone numbers that were not parsable would be left untouched
> > > * Phone numbers that do not need formatting would be left untouched
> > > 
> > > 
> > > There were some edge cases that I’ve seen so far such as:
> > > 
> > > * Having URL links or opening times as phone numbers
> > > * Having ‘/‘ for indicating multi value tag
> > > * Phone numbers but with description as part of it, such as ‘10ct/m’ or 
> > > ‘emergency’
> > > 
> > > 
> > > Phone numbers that would require manual inspection/correction such as the 
> > > following will be send to map roulette:
> > > 
> > > * Phone numbers belonging to other countries
> > > * Phone number values that is just completely wrong
> > > 
> > > 
> > > Please let me know if you have any concern or objections about it, and 
> > > I’ll gladly take your feedback into account.
> > > 
> > > 
> > > Kind regards,
> > > Marc ___
> > > Talk-nl mailing list
> > > Talk-nl@openstreetmap.org 
> > > https://lists.openstreetmap.org/listinfo/talk-nl
> > ___
> > Talk-nl mailing list
> > Talk-nl@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-nl
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [Talk-gb-london] Anyone up for the task of mapping the new Lambeth electoral ward boundaries?

[Colin Smale]

If the position of the boundary is imported from a source that ultimately has a 
very high precision, for example Ordnance Survey or a Council's GIS system 
through a shapefile or similar, then the location as recorded in OSM will 
likely be more accurate than what would be obtained from tracing from aerial 
photos. In other words, if a boundary and a road/railway/etc *almost* coincide, 
more consideration should be given to moving the road to match the imported 
boundary than the other way around.

Having said that, the exact line of a boundary tends to get frozen at the 
moment the Order is made, even if the road/railway/etc is subsequently 
realigned. I strongly recommend that boundaries and other features do *not* get 
combined or even share nodes, unless it can be demonstrated that the link 
between them is dynamic, i.e. a change to one necessarily means a change to the 
other.

> On 02/17/2022 3:41 PM David Davis via Talk-gb-london 
>  wrote:
> 
> 
> 
> Yeah Tom,
> this is conclusion I reached too:
> if a ward boundary is legally defined as being a particular geographical 
> feature (e.g. centre line of a road) then it is better to have that way on 
> OSM tagged with a relation (even if its position is a metre or two off 
> perfect) rather than have another line imported and tagged as the boundary.
> And probably even worse: if the road *is* in precisely the right position, 
> neither is it helpful to have another imported line superimposed right on top 
> of it, as it makes it very fiddly to try and edit them subsequently.
> So, slightly timeconsuming as it is, I think it's probably best to set them 
> up manually.
> 
> On Thu, Feb 17, 2022 at 1:55 PM Tom Chance  mailto:t...@acrewoods.net > wrote:
> 
> > I've previously found it valuable to have the ward boundaries in OSM, and 
> > am responsible for all the Southwark (not Lambeth) ward boundaries, plus a 
> > few Lambeth, Croydon and Bromley. Sometimes the misalignment of open data 
> > and OSM data can lead to mistakes. It's not a big deal if they aren't in, 
> > but I don't see any reason to say they shouldn't be.
> > 
> > If you're going to update them (great!) I think they work better as 
> > relations using - where relevant - existing objects like roads where they 
> > go down the middle of a road. Otherwise, again, things can get misaligned 
> > and otherwise go wrong. So a straight import isn't as good an option as the 
> > rather more painstaking manual approach.
> > 
> > Tom
> > 
> > m: 07866 447 075
> > w: http://tomchance.org/
> > 
> > 
> > On Wed, 16 Feb 2022 at 11:46, Russ Garrett  > mailto:r...@garrett.co.uk > wrote:
> > 
> > > My controversial opinion is that these shouldn't be in OSM.
> > > 
> > > The definitive boundaries are freely available as open data in OS
> > > Boundary Line (although they won't usually appear there until after
> > > the boundaries take effect). The current UK-wide coverage of ward
> > > boundaries in OSM is pretty minimal, although it looks like most of
> > > the old Lambeth wards are in OSM:
> > > 
> > > http://overpass-turbo.eu/?q=W291dDpqc29uXVt0aW1lxIHEgzI1XTsKKAogIG53clsiYsSBbmRhcnkiPSJwb2xpxItjYWwixInEqMSqxKxpxK5sX2RpdmlzacSHxKYid8SjZMSxKHt7YsSfeH19KcSUxY8KxI8gxJ9kecSUPsSUxZNza2VsIHF0Ow=BJp6-ioHTL
> > > 
> > > As someone who uses this boundary data relatively frequently, there's
> > > no reason why I should use OSM when the data is incomplete, and
> > > boundaries in OSM may have been altered (accidentally or otherwise).
> > > They're not surveyable, the data is freely available elsewhere - I
> > > don't see why it's worth spending our time making sure it's replicated
> > > in OSM.
> > > 
> > > Cheers,
> > > 
> > > Russ
> > > 
> > > On Wed, 16 Feb 2022 at 11:27, David Davis via Talk-gb-london
> > > mailto:talk-gb-london@openstreetmap.org 
> > > > wrote:
> > > >
> > > > Hello,
> > > > a complete revamp of the electoral wards in Lambeth borough comes into 
> > > > effect in May 2022, with 25 new wards.
> > > > (See 
> > > > https://love.lambeth.gov.uk/a-new-political-map-for-the-2022-lambeth-borough-council-elections/
> > > >  for info).
> > > >
> > > > I'm guessing the boundaries are available as open data,
> > > > and some bright spark on this list will know how to import it into OSM 
> > > > in a hugely more efficient way that me trying to manually draw and tag 
> > > > the new boundaries...?
> > > > (Amusingly, on the map on Lambeth Council's page about it, someone 
> > > > literally has just drawn the boundaries by hand on top of a screengrab 
> > > > from OSM!)
> > > >
> > > > Anyone interested this task?
> > > >
> > > > (A few of the existing Lambeth wards were tagged on OSM already, but 
> > > > the majority actually weren't. But every existing ward boundary is 
> > > > changing in any case...)
> > > > ___
> > > > Talk-gb-london mailing list
> > > > Talk-gb-london@openstreetmap.org mailto:Talk-gb-london@openstreetmap.org
> > > > 

Re: [Talk-GB] UK street addressing

[Colin Smale]

I agree. I suspect that the post town / dependent locality are
correlated against the post code by the OCR processing. If there was no
post town it would seriously degrade the scanning accuracy as the
postcode OCR would need to be 100% accurate, which is not going to
happen given the number of handwritten addresses. 

On 2020-12-21 16:59, Adam Snape wrote:

> Hi, 
> 
> Post towns may be somewhat arbitrary, but they are at least a verifiable 
> national scheme which we can use for addressing every location in the 
> country. That has to have some benefits compared to each individual mapper 
> deciding where they believe each address falls  - easy for many places, 
> likely contentious for others. The other consistent scheme we could use is 
> tagging by local authority but that's likely to annoy just as many people. 
> 
> I also disagree with the assertion that post towns are no longer used or only 
> of use to RM. Whilst a street address and postcode should suffice, there is 
> an expectation that post is fully addressed. By including the full address, 
> post can still arrive at the correct address despite an obscured, incorrect 
> or illegible postcode. The advantage of a consistent national scheme of 
> addressing is as useful to other couriers in this regard as it is to RM. If 
> you should use parcel labels supplied by the couriers I have usually found 
> them to follow RM's addressing scheme including the relevant post town. 
> 
> Kind regards, 
> 
> Adam 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK street addressing

[Colin Smale]

On 2020-12-21 17:11, Ken Kilfedder wrote:

> If you search for an address on the RM website, I find that (at least in 
> London) it does not suggest the post town is used at all, just "London", not 
> "Stratford" or "West Kensington" or whatever.   (I mean here- 
> https://www.royalmail.com/find-a-postcode )

London is the Post Town. Stratford and West Kensington are not relevant
for the delivery of post, apparently.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK street addressing

[Colin Smale]

On 2020-12-21 16:07, Andy Mabbett wrote:

> On Mon, 21 Dec 2020 at 12:50, Colin Smale  wrote:
> 
>> Royal Mail say that a house number must be numeric, and anything else
>> (like Rose Cottage, 7A, 3-7, 11/13 etc) should go in the house name field.
> 
> So in  a row of three adjacent, identical houses, known as 11, 11A,
> and 15, two have numbers and one has a name? That's not logical.

Hey, this is Royal Mail we are talking about here... 

Building Number must be numeric, max length=4 

https://www.poweredbypaf.com/wp-content/uploads/2017/07/Latest-Programmers_guide_Edition-7-Version-6.pdf___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK street addressing

[Colin Smale]

On 2020-12-21 13:01, 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. 
> 
> The closest existing tag seems to be add:housename=, but I 
> don't know if that stretches the definition too much.

That will cause problems if the constituent parts (flats, houses in a
terrace etc) have a "name" instead of a number. Royal Mail say that a
house number must be numeric, and anything else (like Rose Cottage, 7A,
3-7, 11/13 etc) should go in the house name field. The OSM Wiki allows
non-numeric values though for some cases. 

> On Mon, 21 Dec 2020 at 06:41, Peter Neale via Talk-GB 
>  wrote: 
> 
>> At the risk of throwing another edge case into the pot (and mixing 
>> metaphors), can I ask how I should tag our flat? 
>> 
>> The Post Office Official postcode checker renders it as: 
>> 
>> Flat  
>>  
>>   
>>  
>>  
>> 
>> where  refers to the whole block and is common to all the 
>> flats. 
>> 
>> I cannot see what the Post Office is calling the various data fields, but I 
>> assume OSM would be happy with (taking elements from above)  
>> 
>> addr:housenumber= 
>> 
>> addr:street= 
>> addr:city= 
>> addr:postcode= 
>> 
>> That just leaves me to deal with the "Flat" element. 
>> 
>> Consulting the Wiki, I THINK I can cover that with: 
>> 
>> add:flats=  (for one specific flat) 
>> 
>> ...or addr:flats= (for the whole block) 
>> 
>> However, I unsure whether to include the word "Flat" in the value field of 
>> "addr:flats=*", or not.  The Wiki page for Key:addr includes, as an example, 
>> "addr:flats=Suite 110A", which seems fine for a single living space unit.  
>> It could be called "Flat 110A", "Suite 110A", "Apartment 110A", etc., so 
>> including the descriptor word could be useful to the data consumer.  
>> However, the Wiki page for Key:addr:flats shows only numeric values.  
>> 
>> TagInfo shows 203.5k uses of "addr:flats", but only 38 uses of 
>> "addr:flats=*flat*" and 42 uses of "addr:flats=*suite*", again suggesting 
>> that only the unique value(s) (e.g. "1", "2", "13B", etc.)  are sufficiently 
>> used to warrant data consumers catering for them.  
>> 
>> So, should I omit the word "Flat", "Suite", "Apartment" etc., leaving the 
>> data consumer to guess (or to default to "Flat...")? 
>> 
>> Regards, 
>> Peter 
>> 
>> On Monday, 21 December 2020, 09:30:37 GMT, Robert Whittaker (OSM lists) 
>>  wrote: 
>> 
>> 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 

Re: [Talk-GB] UK street addressing

[Colin Smale]

That's why RM have a Dependent Locality, to distinguish between cases
like this. If the OSM addr:* tags are to represent postal addresses (and
that seems to be the consensus) then OSM should offer a place for the
Dependent Locality. RM say the Post Town is a mandatory component; why
do you disagree with them? 

If you are sending post to someone, you will most likely have got their
address from them, and not got it by reverse geocoding. They, in turn,
will have been told their postal address by Royal Mail. Your correct
postal address is ".., Charlbury, Chipping Norton, .." whether you like
it or not... Is OSM to record the "postal address" or "people's
perception of a postal address"? Or should OSM not define that, and
allow "any old definition of an address"?

You seem very anti-RM because they are commercial; however they also
have statutory roles, whether we like it or not. One of those is
"guardian of postal addresses". In your references to other carriers do
you really expect a house to have multiple addresses according to the
carrier? If I order something online for example, I fill in my (only)
address. I don't want to have a list of addresses, depending on the
carrier chosen by the webshop (which is actually none of my business
anyway). I would say that alternatives to the PAF give alternative
sources of information, not alternative addresses. 

On 2020-12-21 12:14, Richard Fairhurst wrote:

> Robert Whittaker wrote:
>> 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. 
> 
> I quite strongly disagree with this.
> 
> My address is x Market Street, Charlbury, Oxfordshire. My addr:city is 
> therefore Charlbury.
> 
> This suggestion would see my house tagged with addr:street=Market Street, 
> addr:city=Chipping Norton, because Chipping Norton is the Royal Mail post 
> town.
> 
> If a letter is addressed to x Market Street, Chipping Norton, it will end up 
> at x Market Street, Chipping Norton (and yes, there is one). Not x Market 
> Street, Charlbury. You suggest using addr:town to get around this, but that 
> seems to fall foul of your "ignored by most data consumers" point.
> 
> A post town isn't a required part of an address. It's an occasionally 
> suggested part of an address for customers of Royal Mail, useful only in 
> circumstances where the postcode is omitted. Royal Mail themselves don't make 
> any reference to it in their own consumer-facing recommendations, they just 
> say "the town" 
> (https://personal.help.royalmail.com/app/answers/detail/a_id/81/~/how-to-address-your-mail-%28clear-addressing%29).
> 
> Royal Mail is one privately-owned delivery business which is heading rapidly 
> towards being a minority provider, and by some measures already is. Other 
> providers are not beholden to PAF and are increasingly looking outside it to 
> their own datasets. Post towns are in any case superfluous for addresses 
> derived directly from PAF (e.g. via an autocomplete mechanism on a website), 
> because you have the postcode in that case. And that's just the delivery 
> market - addresses serve other purposes, principally around 
> geocoding/routing, for which post towns are irrelevant.
> 
> More philosophically, post towns violate the "on the ground" principle. No 
> one here writes their address as Chipping Norton unless PAF autocompletes it 
> for them. No one has Chipping Norton on their letterhead. Trusting some 
> remote third-party database in preference to local knowledge is not what OSM 
> does, and particularly not OSM in the UK.
> 
> By all means namespace it (royal_mail:addr:city) or use a bespoke tag for 
> what is a bespoke concept (addr:post_town). But let's not remove useful 
> information (the actual town/city) in favour of it, and let's not tag as if 
> post towns are an intrinsic part of UK addresses, because they're not.
> 
> Richard 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK street addressing

[Colin Smale]

On 2020-12-21 10:27, Robert Whittaker (OSM lists) wrote:

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

Indeed, exactly that, Royal Mail say if you don't have space for both
the Thoroughfare and the Dependent Thoroughfare, use the Dependent
Thoroughfare (sub-street) and leave out the Thoroughfare (main street);
the post town / dependent locality / postcode will do the rest. 

Using addr:housename for the substreet is definitely a bad idea, as an
address could actually need both: "Mon Repos, Rose Cottages, Green Lane"
etc.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK street addressing

[Colin Smale]

I don't think you can *deduce* the post town from the postcode, but you
can look it up, using the (non-open) PAF. You will need to use the full
postcode though, as sectors can be split amongst multiple post towns. 

Let's not drift too far from the original topic of how to represent
addresses. How to tag terraces and parts thereof is a different (though
related) subject. 

On 2020-12-21 00:21, SK53 wrote:

> Personally, I think this is still a sort of kludge, although no worse than 
> the ones I discussed in my blog pos [1]t. 
> 
> I'm aware of a number of terraces which are discontinuous, demonstrating that 
> individual houses in a terrace are not building:part. A typical example would 
> be a terrace bombed in the war where the bombed out houses were not replaced. 
> There is a "terrace" in Richings Park, Iver which looks just as if such a 
> scenario had occurred, however, the owner of the end house explained that the 
> developer ran out of money and never completed the terrace (the end houses 
> were planned to be fancier). 
> 
> At one stage I terraced buildings and left the outline of the terrace as well 
> as the individual houses which was a similar solution, but that will now lead 
> to lots of error messages. For S3DB (simple 3D buildings) describing the 
> entire terrace in terms of roof shape etc is often far easier than doing it 
> for individual houses, so there are other advantages. My main objection is 
> that it is not semantically accurate. 
> 
> The use of building=terrace both for entire terraces and individual houses in 
> the terrace also is something I would like to disambiguate. For instance use 
> building=terrace for the entire terrace & building=terraced_house for 
> individual houses in a terrace (this latter value may also work with 
> building:part in ways that give data consumers flexibility with the data). 
> Generic building=house is preferably avoided for something more precise 
> (detached, semidetached_house etc). I'd like to mark bungalows separately as, 
> at least in Britain, they tend to be a very distinct housing type which 
> building:levels=1 does not guarantee, but in various places, notably 
> Southend, there are masses of semidetached bungalows. 
> 
> On the topic of the OP, I'm broadly with Chris on this, pretty much as I set 
> out [2]7 years ago! I also think it's important that, for me at least, we're 
> not adding addresses in OSM just to create an open replica of PAF. There are 
> numerous other important uses of addresses over and above this and routing. 
> At the Open Addresses meeting [3] back in 2014 I participated in a discussion 
> on this very point, and a number of people from large well-known 
> organisations provided a good number of significant examples. I can't be more 
> explicit because the meeting was held under Chatham House rules. If we do 
> need to add postal towns, which I suspect we don't, then I would advocate for 
> a specific tag addr:postal_town or even addr:rm_postal_town. In practice I 
> would think postal towns can be deduced from post codes (i.e. externally to 
> OSM): wikipedia certainly have lists for many postcode areas. 
> 
> Jerry 
> 
> On Sun, 20 Dec 2020 at 19:23, ndrw  wrote: 
> 
>> On 20/12/2020 18:44, ipswichmapper--- via Talk-GB wrote:
>>> What you do is give the outline way "buildong=terrace" and 
>>> "name=" and all the houses with 
>>> "building:part=house". The software can then tell that all those 
>>> houses are part of the terrace called 
>> 
>> This is a good solution. I usually resort to simply not terracing the 
>> building and adding addresses as points and/or an addr:interpolation line.
>> 
>> In either case, if the name of the building is a part of the address 
>> ("dependent thoroughfare") there is currently no suitable OSM tag for 
>> it. I've seen cases of addr:place, addr:substreet or addr:parentstreet 
>> but there is no established consensus yet.
>> 
>> ndrw6
>> 
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
 

Links:
--
[1]
http://sk53-osm.blogspot.com/2020/06/housing-terraces-in-wales-minor.html
[2]
http://sk53-osm.blogspot.com/2013/08/pfafing-about-opening-uk-address-data.html
[3]
http://sk53-osm.blogspot.com/2014/09/openstreetmap-at-uk-open-addresses.html___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK street addressing

[Colin Smale]

On 2020-12-20 20:24, ipswichmap...@tutanota.com wrote:

> The housenumber and street would be tagged on the "building:part=house" 
> 
> Is this housrnumber belonging to the terrace or is it belonging to the 
> street? If it belongs to the terrace, I think even with this tagging software 
> wouldnt recognise this. 
> 
> In that case, this is the tagging O use (its not that good however): 
> 
> addr:housenumber=2 
> addr:place=Orchard Gardens 
> addr2:street=Green Lane 
> 
> I use addr2:street (this is accepted tagging, by the way) to indicate that 
> the street is a seperate address. 
> 
> This isnt ideal, of course

Put yourself in the place of a bit of software looking at OSM data and
trying to answer the questions: 
1) What is the (postal) address of these premises (being 2 Orchard
Cottages) 
=> correct answer is "2, Orchard Cottages, Green Lane" 
2) Where can I find "2 Orchard Cottages, Green Lane"? 
=> correct answer is the premises we started with 

Instead of looking for the ideal system, let's find something that is
good enough. I doubt we will ever find an ideal system that will fit all
the addressing systems in the world, or even in the UK (bilingual
addresses are another can of worms). 

If, looking only at the OSM data, a (reasonable) algorithm can be found
that leads reliably to the correct answer, then it is "good enough" 
If such an algorithm cannot be found, then the OSM data is "not good
enough" 
By "algorithm" I mean here a deterministic interpretation of OSM
tagging, including (where really necessary) the geometry (within
particular types of polygon for example).___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK street addressing

[Colin Smale]

On 2020-12-20 19:44, ipswichmap...@tutanota.com wrote:

> What you do is give the outline way "buildong=terrace" and 
> "name=" and all the houses with "building:part=house". The 
> software can then tell that all those houses are part of the terrace called 
> 

So in the case like I referred to earlier, "2, Orchard Cottages, Green
Lane" would be tagged with addr:housenumber=2, and addr:street=Green
Lane? And then enclosed within "building=terrace, name=Orchard
Cottages". Is the tag building:part=house enough to indicate that the
address is "2, Orchard Cottages, Green Lane" and not "2, Green Lane"?___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK street addressing

[Colin Smale]

On 2020-12-20 18:21, ipswichmapper--- via Talk-GB wrote:

> Tag the houses with addr:place maybe?

IMHO a house is not a place 

> Or, better method is to use the alternative terrace taggong scheme where each 
> house is tagged as building:part=house within a larger building=terrace.  
> (Terracer plugin lets you do this if you check "keep outline way")

That allows the building to be split into parts, but does it tell us how
to put a distinct address on each part?___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK street addressing

[Colin Smale]

On 2020-12-20 17:16, Chris Hill wrote:

> On 20/12/2020 14:57, Colin Smale wrote: 
> 
> On 2020-12-20 15:41, Chris Hill wrote: 
> Addresses in OSM are not the same as Royal Mail's addresses. RM addresses are 
> all about their processes for delivering post to delivery points. The postal 
> town (Largertown in your example) is a convenience for RM that we have all 
> been persuaded is useful, but RM have ceased to use postal towns for many 
> years! 
> Are you not thinking of Postal Counties? They were indeed deprecated many 
> years ago (1996), but the Post Town is AFAIK a mandatory component of a 
> postal address, and Wikipedia agrees: https://en.wikipedia.org/wiki/Post_town

No, Counties are still useful. The only reason RM no longer uses
counties is that they depend on postcodes and street addresses to
deliver. We are not confined to delivering using RM's infrastructure.
Near to York there is a village called Dunnington, near to Hull there is
another small village called Dunnington. Without postcodes the county is
vital to reach the right place. 

What does Royal Mail say in their Postcode lookup tool? They use the
Post Town to distinguish the two (and no sign of the county in either
case):

Flat A 
Cherry Tree Court 
Dunnington 
YORK 
YO19 5QU 

Pear Tree Farm 
Dunnington 
DRIFFIELD 
YO25 8EG 

> Long after RM say they no longer used counties, their PAF list, used across 
> Britain to find addresses in the absence of a proper, Open address 
> database,still has counties in it. People still quote my address as being in 
> North Humberside. North Humberside never existed, Humberside was abolished in 
> 1996! SO it is with postal towns, RM no longer use them but they still appear 
> in their PAF and so get perpetuated in general use, even though they are 
> useless and misleading. 
> 
> Royal mail do not use postal towns and neither should OSM.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK street addressing

[Colin Smale]

On 2020-12-20 17:09, Chris Hill wrote:

> On 20/12/2020 15:30, ndrw wrote: On 20/12/2020 12:45, Dave Abbott wrote: 
> 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
> 
> This is correct, although there is no consensus wrt to the tag used for 
> Smalltown. I'm using one of addr:villlage|suburb|town myself. There was a 
> proposal to switch to addr:locality only, which I argued against in the past, 
> but it would indeed match RM addressing better and often classification of 
> the locality is unclear.

Using the two separate towns is not correct. The house (or whatever) is
not in Largertown,it is in Smalltown.

Postal towns are in invention of Royal Mail. Correct addressing of any
location are set by Local Authorities, not Royal Mail. There are no
postal towns in LA addresses.

In the original example the 'Smalltown' (or indeed village or even
hamlet) translates into addr:city in OSM. I know this may look confusing
as a small villiage is not a city, but that is, IMHO, the correct way
tobuild an OSM UK address.

Adding postal towns is not only redundant, but is misleading. It looks
as though the way to find Smalltown would be first to go to Largertown,
when that is very rarely the case. OSM addresses are hierarchical, RM
addressing is not as postal town is usually a separate place. 

That depends on your paradigm. If the address is the "postal address",
then we should follow (or map to) RM addressing. If the address is "for
navigation purposes" we would need a different model. Many countries
(not the UK) use addresses as (partial) identifiers, and that paradigm
has yet another set of requirements. 

Sometimes the Post Town is not even in the same country - addresses in
Tutshill, Gloucestershire have Chepstow as their Post Town. If that is
not tagged explicitly, what algorithm is going to infer that correctly? 

Are you advocating removing all address elements superior to street, and
forcing users to look up the other elements in PAF? What would otherwise
be the use case for having city/town etc in an address in OSM?___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK street addressing

[Colin Smale]

On 2020-12-20 16:30, ndrw wrote:

> On 20/12/2020 12:45, Dave Abbott wrote: 
> 
>> 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
> This is correct, although there is no consensus wrt to the tag used for 
> Smalltown. I'm using one of addr:villlage|suburb|town myself. There was a 
> proposal to switch to addr:locality only, which I argued against in the past, 
> but it would indeed match RM addressing better and often classification of 
> the locality is unclear.
> 
> This is not the only problem with RM<->OSM address tagging. RM defines 
> following address structure:
> 
> Dependent thoroughfare
> addr:place (?)

This is unlikely to be a good match. An example of a Dependent
Thoroughfare would be "2, Orchard Cottages, Green Lane" where "Orchard
Cottages" is the Dependent Thoroughfare. 

> Thoroughfare
> addr:street
> Double dependent locality
> addr:hamlet|district (?)
> Dependent locality
> addr:town|village|suburb|locality (?)
> Post Town
> addr:city
> Postcode
> addr:postcode
> 
> This often becomes an issue when mapping business parks, hospital/university 
> campuses etc.
> 
> ndrw6
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK street addressing

[Colin Smale]

On 2020-12-20 15:41, Chris Hill wrote:

> Addresses in OSM are not the same as Royal Mail's addresses. RM addresses are 
> all about their processes for delivering post to delivery points. The postal 
> town (Largertown in your example) is a convenience for RM that we have all 
> been persuaded is useful, but RM have ceased to use postal towns for many 
> years!

Are you not thinking of Postal Counties? They were indeed deprecated
many years ago (1996), but the Post Town is AFAIK a mandatory component
of a postal address, and Wikipedia agrees:
https://en.wikipedia.org/wiki/Post_town___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK street addressing

[Colin Smale]

On 2020-12-20 14:39, ipswichmap...@tutanota.com wrote:

> It's not just administrative boundaries. If you mark points with 
> "place=suburb", "place=town" etc. that will also be used. 
> 
> In this case it is clearly difficult to tell which tags to use, so I would 
> just not use them and let nominatim figure out. Unless someone else a clearer 
> solution, that is.

First of all - are you sure that an address in OSM (addr:* tags) is
intended to represent a postal address, and not something else like a
location? 

If it IS supposed to be a postal address, then its data model needs to
be suitable, which in the UK means it can somehow accommodate all the
fields that can occur in a valid postal address. Fill your boots here:
https://ideal-postcodes.co.uk/documentation/paf-data 

Nominatim is known to produce bad output for UK addresses (at least, on
the OSM website), because it is based around compromises and assumptions
that fits some countries better than others. It ignores some useful
polygons, "invents" towns by proximity and gets the priority wrong
(place=village is higher than admin_level=10) It includes
districts/boroughs and administrative counties, none of which are
relevant for postal addresses.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK street addressing

[Colin Smale]

On 2020-12-20 14:13, ipswichmapper--- via Talk-GB wrote:

> Marking city, town etc is not necessary in UK because Geocoders like 
> nominatim can figure those out using afministrative boundaries.

Postal addresses have no relation to administrative boundaries. They are
simply "what you need to put on an envelope so Royal Mail can put it
through the right letter box". 

Boundaries of "post town" areas are not in OSM, nor can they be
considered "administrative". Post Towns, Dependent Localities and
Double-Dependent Localities are not mapped (nor mappable) to Districts
etc or Civil Parishes. 

> What is important is the housenumber and street: 
> "addr:housenumber=99 
> addr:street= Postal Street" 
> 
> And postcode: 
> "addr:postcode=XY9 7GY" 
> 
> Note, all postcodes are available freely: 
> 
> https://raggedred.net/codepoint/ 
> 
> IpswichMapper 
> -- 
> 
> 20 Dec 2020, 12:45 by dave.abb...@pandaemonia.org: 
> 
>> Hi, 
>> 
>> 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___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] "GPS trace" tracking county boundary

[Colin Smale]

On 2020-12-14 20:21, Edward Bainton wrote:

> With plenty of portages... 
> 
> Glad I'm not going mad. Does it say anything useful or interesting that the 
> "GPS trace" is a few metres away from the boundary as marked on the map? 
> (Sorry if this has been answered recently: there was extensive discussion on 
> alignment not long ago, but too technical for me to follow easily.)

If my suspicion is correct that a converted version of the OS
Boundary-Line data was uploaded as GPX, then the small shift just
indicates that the exact parameters used to convert from the OS
coordinate system (Eastings and Northings) to the system used by GPS and
OSM were different.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] "GPS trace" tracking county boundary

[Colin Smale]

I suspect someone has uploaded a GPX version of the boundary from OS
Boundary-Line. It doesn't look like an actual trace from a GPS receiver.


On 2020-12-14 18:27, Edward Bainton wrote:

> Any thoughts on why when I enable "public GPS traces" in iD, I get one that 
> near enough exactly tracks the LA boundary South Kesteven:Peterborough (at 
> Deeping St James)? 
> 
> See https://www.openstreetmap.org/#map=16/52.6543/-0.2655=G 
> 
> It seems unlikey that it really is a GPS trace - or is it? 
> 
> Thanks. 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] Newbie damage alert in West Midlands

[Colin Smale]

A new user, TL5100, is causing a bit of damage in the Midlands, deleting
loads of things for no obvious reason. A couple of their changesets have
comments to this effect already. Could someone have a word? 

https://www.openstreetmap.org/user/TL5100/history#map=11/52.0822/-2.4818___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] different post codes within single block of flats

[Colin Smale]

On 2020-11-01 23:09, Kai Michael Poppe wrote:

> Hi Colin, Hi BD, 
> 
> as I live in a country with the maximum "anomality" are different 5-digit 
> postcodes along a street (or sides of said street) I find different codes per 
> building strange to say to least. 
> 
> I'd go for: 
> * Remove addr:postcode= from the building's area and add a note=This building 
> has two postcodes, X and Y 
> * Add two new nodes within the area of the building (not connecting to the 
> area), add all addr:*= with the respective postcodes and add a note=This 
> building (link to way/area of building) has two postcodes, this node is for 
> levels A thru B. 
> * Change the Note in the area to display the links to the Postcode Nodes.

I would recommend leaving this to UK mappers who understand the UK
postcode system Postcodes don't indicate buildings in the UK - they
indicate postal delivery points. Don't try and find logic where none
exists... 

The relationship is n:m. You cannot ask "what is the postcode for this
building" - you have to ask "what postcodes have a delivery point in
this building". You cannot ask "which building does this postcode
indicate", you have to ask "which buildings have a delivery point with
this postcode."___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] different post codes within single block of flats

[Colin Smale]

UK postcodes are for the delivery of mail and not intended to identify
buildings or parts of buildings. There will be loads of "anomalies" like
this. It's not crazy, it's just not what you are used to. 

On 2020-11-01 22:16, BD wrote:

> Hi all, 
> 
> came across this quite strange arrangement: 
> https://www.openstreetmap.org/changeset/93291383 
> 
> As per comment in this changeset it seems that two postcodes are dividing 
> this building in half but not as I would expect. 
> 
> Three floors with one postcode, three with another!? Crazy! 
> 
> I wanted to re-draw the whole thing with underground car park and two 
> separate apartment blocks, expecting that postcodes would be for left and 
> right side of the building. 
> 
> Stacking identical building parts one on another doesn't make too much sense, 
> is there an alternative postcode tag? 
> Any suggestions how to map this? 
> 
> Cheers, 
> dzidek23 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] Doocracy | Re: Idea for improving mapping system

[Colin Smale]

On 2020-10-18 15:04, Simon Poole wrote:

> Am 18.10.2020 um 11:07 schrieb Rory McCann: 
> 
>> Like mnany things in OSM, the reason it hasn't been done is because no-one 
>> has actually done it yet. It looks like other people find your idea of 
>> "levels" and "badges" interesting, so you should try attempt it yourself.
> 
> Like many things in OSM, the reason that it isn't being done, is because it 
> has been tried and has failed. It looks like that other people don't find the 
> idea of "levels" and "badges" interesting, so you shouldn't attempt it again.

...unless either the proposal, or the circumstances, have changed in
some significant way, or unless a substantial period of time has passed.
Never say never.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] Turn Restrictions at roundabouts

[Colin Smale]

On 2020-10-03 18:16, Tom Hughes via Talk-GB wrote:

> On 03/10/2020 16:57, Philip Barnes wrote:
> 
>> They are intended to stop this type of routing
>> https://www.openstreetmap.org/directions?engine=graphhopper_car=52.64994%2C-1.20491%3B52.64983%2C-1.2049
>> 
>> Which is techincally not illegal and in real world usage is not going to 
>> happen.
> 
> But unless the start or end point is on the flare why would a
> router do that over the shorter route on the roundabout... I mean
> maybe there are a few cases where the flare is shorter somehow?

If you take that exit by accident, a fast router may tell you to take
the sharp turn back to the roundabout. Some flares are longer than
others, and some routers take longer than others to trigger the
"off-route" stuff.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Flatholm Island Boundary Problem

[Colin Smale]

On 2020-09-12 23:53, Russ Garrett wrote:

> Yeah, I assume what happened is that the City of Bristol ended up, at
> some point, as a statutory port authority (which I think they were
> until 1991), and somehow the boundary from that has remained as their
> local authority boundary. But it's still a fairly unique situation as
> there are many other harbours with statutory port authorities where
> this anomaly doesn't exist.
> 
> I'm fairly sure that Bristol boundary does not coincide with the
> current limits of the Port of Bristol. Aberdeen has a small seaward
> extension which also doesn't appear to coincide with their current
> port authority limits either. So it's not clear what these seaward
> extensions currently achieve.
> 
> I'd love to find the actual legislation which created this...

There are seaward extensions not linked to a port as well. I wonder what
the background is to Torbay (Devon) for example.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Flatholm Island Boundary Problem

[Colin Smale]

On 2020-09-12 22:23, Russ Garrett wrote:

> Incidentally, the OSM wiki page for Wales claims that the sea boundary
> between Wales and England is not well-defined:
> https://wiki.openstreetmap.org/wiki/Wales#Boundary

Then the wiki is wrong. The "Welsh Zone" was most recently defined by
the: 

THE WELSH ZONE (BOUNDARIES AND TRANSFER OF FUNCTIONS) ORDER 2010

https://www.legislation.gov.uk/uksi/2010/760/schedule/made___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Flatholm Island Boundary Problem

[Colin Smale]

This anomaly gives rise to the situation that there is a triangle (more
or less) of water near Flat Holm which is simultaneously within the
jurisdiction of  Wales and the City of Bristol. It probably only matters
for things like fishing, as that was basically the reason to define
clearly the maritime boundary between England and Wales, fishing and the
marine environment (up to 12nm) being Devolved Powers. The City of
Bristol is probably the only cross-border local authority in the UK 

On 2020-09-12 19:53, Russ Garrett wrote:

> Oh wait, I remember now. This is correct for extremely stupid reasons
> relating to the boundaries of the county of Bristol including a large
> chunk of the Bristol Channel.
> 
> I can confirm the boundary in OSM matches the one in OS Boundary Line.
> That relation could probably do with a note tag on it, though.
> 
> Cheers,
> 
> Russ
> 
> On Sat, 12 Sep 2020 at 18:48, Russ Garrett  wrote: 
> I'm pretty sure Flat Holm is part of Cardiff - Steep Holm is in
> England but it also isn't in Bristol as far as I know. There's
> definitely something weird going on with the boundaries there but it
> also looks like nothing has changed around there in a while. Curious.
> 
> On Sat, 12 Sep 2020 at 18:39, Brian Prangle  wrote: 
> This island, in the bristol Channel between Weston super Mare and Barry seems 
> to be in two countries  at once. It's on the Welsh side of the national 
> boundary but also in South West England City of Bristol. This is either a map 
> error with the Welsh boundary or a legal anomaly I don't know which.  If it's 
> one of those legal quirks then wouldn't it be better as an exclave of England 
> in Wales?
> 
> Apologies if this has come up before.
> 
> Regards
> 
> Brian
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb 
> 
> --
> Russ Garrett
> r...@garrett.co.uk___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] New Bing Imagery

[Colin Smale]

On 2020-08-19 17:21, Russ Garrett wrote:

> On Wed, 19 Aug 2020 at 16:00, Colin Smale  wrote: 
> 
>> At least it sounds soluble. Given the right transform and corrections a 
>> "definitive" OS point in Easting/Northing format can be translated 
>> accurately to WGS84 lat/long. However you look at it, I would expect a 
>> purely mathematical transformation should have less error than a 
>> transformation involving "tracing" from imagery whose rectification has 
>> probably also involved some of these transformations each with their own 
>> error terms. But I suppose that it at least partly depends on your 
>> definition of "perfection."
> 
> Well, that assumes that OS's locations are perfect, and that their
> data isn't subject to orthorectification errors and the like. It's
> still likely to be better than any other source, but I'd be surprised
> if there weren't similar errors in some of the OS data, especially in
> more rural & hilly areas.

Agree with this. 

Here's a thought: I doubt the OS use equipment that reads out directly
in OSGB36. I would think it it more likely that their equipment provides
(e.g.) WGS84 data which is then converted to OSGB36 before storing it in
the MasterMap database? I wonder what transformation errors are
introduced at that stage. If we reverse that transformation exactly, we
should arrive at the data as originally captured. 

> In my experience, once you start trying to go below 5m accuracy you
> swiftly learn not to trust anyone.

I can understand that, but it is not helping us forward... We need to
trust someone/something unless we think we can do better ourselves. I
tend to regard the OS as "sufficiently trustworthy" from my perspective
as a reasonably technically, mathematically competent person without any
specific inside knowledge of the OS. So if the OS say it's at {x,y} and
some other source says {x',y'} then I would presume that the OS is more
likely to be correct, and the other source would have to show me a damn
good provenance if it wants me to consider it better than the OS (and
thereby prompt me to move some feature in OSM).___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] New Bing Imagery

[Colin Smale]

At least it sounds soluble. Given the right transform and corrections a
"definitive" OS point in Easting/Northing format can be translated
accurately to WGS84 lat/long. However you look at it, I would expect a
purely mathematical transformation should have less error than a
transformation involving "tracing" from imagery whose rectification has
probably also involved some of these transformations each with their own
error terms. But I suppose that it at least partly depends on your
definition of "perfection."

On 2020-08-19 16:34, 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. 
> 
> Like Jass I've been looking at various data sets which can be pulled into 
> editors to help with alignment. I initially used OS Open Roads, but this is 
> just too generalised to be usable in many areas. Larger buildings from OS 
> Open Local, although generalised, will often have corners in the right place. 
> Perhaps what we need is an equivalent of TIGER Line as a GB specific overlay 
> layer showing selected alignment friendly features from either OS Local or 
> Vector Map. If we could borrow styling from either TIGER Line or the US 
> Forest roads it might be feasible to make such a layer. 
> 
> Jerry 
> 
> On Wed, 19 Aug 2020 at 13:58, Colin Smale  wrote: 
> 
> On 2020-08-19 12:17, Andy Townsend wrote: 
> On 19/08/2020 10:11, Stephen Colebourne wrote:And now I can see Amazon 
> mappers using an iD variant
> that doesn't have the offset and moving all the roads as a result:
> https://osmcha.org/changesets/89549551?aoi=758c7f2b-faca-44e5-acd2-0cb8c33034bd
> https://www.openstreetmap.org/changeset/89549551
> If that's happening at all, please comment on the changeset explaining the 
> problem.  In English urban areas OS OpenData StreetView is a pretty good 
> guide for alignment and if people (especially people doing a lot of editing) 
> are not taking into account different imagery offsets then that's just wrong. 
> Possibly even better that StreetView imagery is data that has been imported 
> directly from OS, such as OS Boundary-Line for the admin boundaries. This is 
> probably the closest we can get to cm-level accuracy - even though they don't 
> give us the full resolution, the base points such as tripoints where 
> boundaries meet are likely to be pretty damn accurate. I would recommend 
> using these as a kind of calibration point to sanity-check imagery alignment 
> and other data based on less accurate GPS positioning (e.g. from any 
> consumer-grade GPS kit). 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] New Bing Imagery

[Colin Smale]

On 2020-08-19 12:17, Andy Townsend wrote:

> On 19/08/2020 10:11, Stephen Colebourne wrote:And now I can see Amazon 
> mappers using an iD variant
> that doesn't have the offset and moving all the roads as a result:
> https://osmcha.org/changesets/89549551?aoi=758c7f2b-faca-44e5-acd2-0cb8c33034bd
> https://www.openstreetmap.org/changeset/89549551
> If that's happening at all, please comment on the changeset explaining the 
> problem.  In English urban areas OS OpenData StreetView is a pretty good 
> guide for alignment and if people (especially people doing a lot of editing) 
> are not taking into account different imagery offsets then that's just wrong.

Possibly even better that StreetView imagery is data that has been
imported directly from OS, such as OS Boundary-Line for the admin
boundaries. This is probably the closest we can get to cm-level accuracy
- even though they don't give us the full resolution, the base points
such as tripoints where boundaries meet are likely to be pretty damn
accurate. I would recommend using these as a kind of calibration point
to sanity-check imagery alignment and other data based on less accurate
GPS positioning (e.g. from any consumer-grade GPS kit).___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Street-name toids

[Colin Smale]

On 2020-08-13 12:25, Robert Whittaker (OSM lists) wrote:

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

That is apparently not how OS are positioning TOIDs, according to
Wikipedia 
https://en.wikipedia.org/wiki/TOID 

TOIDs are intended to be persistent, and aimed at integration between
databases. OSM would be one such database, wouldn't it?___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] [Osmf-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Colin Smale]

On 2020-08-06 11:47, Martin Koppenhoefer wrote:

> Am Do., 6. Aug. 2020 um 11:26 Uhr schrieb Lukasz Kruk 
> : 
> 
>> I'm not sure what rules govern this: "Londn" does find the capital of the 
>> UK, but "Warszaw" does not find the capital of Poland...?), which is only a 
>> little inconvenient when compared to the second-best online map.
> 
> this is because Londn is apparently the name in West Flemish 
> Londn (name:vls) 
> https://nominatim.openstreetmap.org/ui/details.html?osmtype=R=65606

And which language is "Warszaw" supposed to be? It doesn't seem to match
any of the name strings in OSM. 
https://www.openstreetmap.org/relation/336074___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Colin Smale]

On 2020-08-02 16:41, Sören Reinecke via talk wrote:

> Also Linux is the future. Every application that cannot run under Linux will 
> fail in the long run. Remember that Windows shouldn't be the main target 
> platform anymore because it is dying and the society is to blame that they 
> don't get it.

Linux is a big part of the future for server platforms, but in its pure
form it has lost the battle for the desktop. Windows and MacOS as
platforms capable of enterprise-level management are not going anywhere
soon. Don't ignore ChromeOS and Android for local "desktops" either -
both are Linux-based of course. 

The biggest dependencies should not be the OS but the runtime
frameworks. This world used to be java-based; these days .NET Core is a
viable competitor, as is Node.js. As a server-side application supplier,
if your product doesn't run in a container, it doesn't exist. Containers
basically mean Linux and Windows. Actual host OS is irrelevant - only
the container environment matters.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-GB] Fwd: Re: Admin Boundaries and Combined Authorities

[Colin Smale]

I think I replied privately by mistake, so copying to the list now...

On 2020-07-28 11:45, Ed Loach wrote:

> Colin wrote:
> 
>> Thanks for your message. I would like to challenge one point - your 
>> assertion that the Regions 
>> at admin_level=5 are in "widespread popular use". It is true that many 
>> people talk about 
>> geographical regions like "the South-East" or "the North-West". But these 
>> are ill-defined 
>> vernacular phrases and do not refer to the sharply-defined regions that are 
>> only occasionally 
>> used in governmental areas. If you asked people "is Essex in the South-East" 
>> I expect 99% would 
>> say "yes"
> 
> I must be in that 1% being an Essex resident who lives in the East of England 
> (and gets "Look East" as the local news).

No offence intended of course! It sounds like you are towards the north
of Essex then. But yes, you are right, my use of "99%" was hyperbole to
make a point. Boundaries of TV regions, both BBC and ITV, can also often
appear a bit random to the naked eye and depend to no small degree on
the locations and coverage of transmitters, meaning that my part of Kent
can basically only get London programs unless you have a high-gain
aerial on a pole to get the Kent programs from Bluebell Hill. 

> Admin level 5 is the NUTS 1 regions which as far as I know we are still using 
> to keep statistics from one year to the next even though we have now left the 
> EU. As such it is a meaningful admin level as much as say UPRNs on 
> properties, or references on A roads, or fhrs ids. 
> 
> There is some argument I suppose for changing from boundary=administrative 
> admin_level=5 to boundary=statistical and something to indicate NUTS 1 though 
> (type will have already been used for type=boundary).

That sounds like a good plan to me.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Admin Boundaries and Combined Authorities

[Colin Smale]

On 2020-07-28 14:41, Dan Glover wrote:

> Other observations, if I may?
> 
> Levels 4 and 6 give UK-wide coverage and level has complete coverage of 
> England. The Combined Authorities are relatively sparse in their coverage (by 
> area - by population is a different matter) so there would be significant 
> gaps in Level 5 under this proposal. Unused Level 7 would "work" in the case 
> of the Greater London Authority - which otherwise doesn't seem to exist 
> except at Level 5 - it has always been a special case. I've not looked at the 
> detailed composition of the Combined Authorities but the problem seems to be 
> they're groupings of entities currently in Levels 6 and 8 (and might straddle 
> boundaries in the current Level 5?) so the hierarchical aspect perhaps cannot 
> be preserved.

I don't believe they currently straddle Region boundaries, but that may
be more by accident than design. They certainly contain mixtures of UAs
and Districts, and sometimes straddle "ceremonial county" boundaries.
This makes it a challenge to fit them into a true hierarchy. 

The GLA is legally a special case, but in practical terms it is very
like a Metropolitan County (now abolished) with Metropolitan Districts
as constituent parts. The London Boroughs are at level 8, so in that
respect the GLA would slot right in at level 6; but the GLA also covers
the City of London, which is currently also at level 6. 

> Stepping back: how is the map data being used? Is a way to identify the 
> Combined Authorities now more relevant than the (English) Government Regions? 
> Should this be handled in some other way than admin_level, which looks as 
> though it's intended for countries where everything is in a strict and 
> consistent hierarchy?

My thought is that the Government Regions can safely be migrated to
boundary=statistical as someone has already mentioned (sorry I forget
exactly who). 

An alternative approach for CAs is to model them as collections of other
objects - in OSM terms, a relation with the constituent area relations
as members. This would allow the individual relations to be given roles
within the CA, thus creating a possibility to include "associate
members" and non-local-authority members (such as fire services which
have their own relations in OSM) that are sometimes legally represented
in the CA governance.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Admin Boundaries and Combined Authorities

[Colin Smale]

On 2020-07-28 11:45, Ed Loach wrote:

> Colin wrote:
> 
>> Thanks for your message. I would like to challenge one point - your 
>> assertion that the Regions 
>> at admin_level=5 are in "widespread popular use". It is true that many 
>> people talk about 
>> geographical regions like "the South-East" or "the North-West". But these 
>> are ill-defined 
>> vernacular phrases and do not refer to the sharply-defined regions that are 
>> only occasionally 
>> used in governmental areas. If you asked people "is Essex in the South-East" 
>> I expect 99% would 
>> say "yes"
> 
> I must be in that 1% being an Essex resident who lives in the East of England 
> (and gets "Look East" as the local news).

No offence intended of course! It sounds like you are towards the north
of Essex then. But yes, you are right, my use of "99%" was hyperbole to
make a point. Boundaries of TV regions, both BBC and ITV, can also often
appear a bit random to the naked eye and depend to no small degree on
the locations and coverage of transmitters, meaning that my part of Kent
can basically only get London programs unless you have a high-gain
aerial on a pole to get the Kent programs from Bluebell Hill. 

> Admin level 5 is the NUTS 1 regions which as far as I know we are still using 
> to keep statistics from one year to the next even though we have now left the 
> EU. As such it is a meaningful admin level as much as say UPRNs on 
> properties, or references on A roads, or fhrs ids. 
> 
> There is some argument I suppose for changing from boundary=administrative 
> admin_level=5 to boundary=statistical and something to indicate NUTS 1 though 
> (type will have already been used for type=boundary).

That sounds like a good plan to me.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Admin Boundaries and Combined Authorities

[Colin Smale]

Hi Sarah, 

Thanks for your message. I would like to challenge one point - your
assertion that the Regions at admin_level=5 are in "widespread popular
use". It is true that many people talk about geographical regions like
"the South-East" or "the North-West". But these are ill-defined
vernacular phrases and do not refer to the sharply-defined regions that
are only occasionally used in governmental areas. If you asked people
"is Essex in the South-East" I expect 99% would say "yes", and asking
people to locate the Isle of Wight in either South-East or South-West
would yield, at best, an inconclusive result. 

Hence my suggestion that admin level 5 for government regions is no
longer in active use, and is therefore available for adoption by the
Combined Authorities. 

I am sure I don't need to remind you of the disconnect in the UK between
a) administrative areas, b) postal addressing and c) people's perception
of "locations"...

Best regards, 

Colin 

On 2020-07-28 09:48, Sarah Hoffmann wrote:

> Hi,
> 
> I'm the one who caused this discussion by editing West Yorkshire. I was 
> looking
> into admin boundaries for Nominatim (the search engine) who uses them to
> determine the place description or address of a place. As part of this I had
> noticed a hole in the admin level 6 coverage and 'fixed' it.
> 
> I have to say that this discussion reflects a paradigm shift in the 
> interpretation
> of boundary=administrative that I find concerning. boundary=administrative 
> used
> to reflect the hierarchical structure of a country as viewed by popular use. 
> That
> is quite practical because it makes it possible to determine reasonable 
> subdivisions
> from the OSM data without having to know how exactly a country is governed.
> 
> Since a few months I notice more and more that people start to interpret
> boundary=administrative in a literal sense and argue that all those where 
> there is
> no direct governmental function have to go away or retagged with something 
> else.
> This 'something else' is often locally chosen without any coordination with 
> the
> international community or any documentation what so ever (try finding out 
> about
> boundary=ceremonial in the wiki if you don't believe me). I fear that we
> end up with a fragmentation in tagging that makes it seriously difficult to 
> use the
> data in a meaningful way.
> 
> Coming back to the issue at hand: the regions on admin level 5 may not 
> exactly have
> an administrative function but my impression is that they are in wide-spread
> popular use. I don't visit the UK often but even I am aware of them. That's a
> good reason to include them in the boundary=administrative hierarchy. Moving 
> them
> to some other tagging schema makes them practically invisible.
> 
> Mixing regions and CAs in admin_level=5 is not a good idea either because it
> breaks the global assumption that the admin_levels create a proper hierarchy.
> Same goes for admin_level=5.5. This would be really unexpected and likely just
> ignored by most consumers.
> 
> Sarah
> 
> On Tue, Jul 28, 2020 at 06:41:02AM +0100, Steve Doerr wrote: 
> 
>> Could they perhaps be 5.5 to distinguish them from regions?
>> 
>> Steve
>> 
>> From: Brian Prangle [mailto:bpran...@gmail.com]
>> 
>> I favour admin  level 5 too.
>> 
>> On Sun, 26 Jul 2020 at 23:52, Colin Smale > <mailto:colin.sm...@xs4all.nl> > wrote:
>> 
>> The LAs of which the CAs are composed are sometimes Metropolitan Boroughs 
>> with admin_level=8, and sometimes Unitary Authorities with admin_level=6. I 
>> am tending towards admin_level=5; this value is/was in use for the Regions, 
>> but they no longer have an admin function (if they ever had one) so I 
>> consider admin level 5 as "available" for use by Combined Authorities.
>> 
>> --
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
> 
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Admin Boundaries and Combined Authorities

[Colin Smale]

For England (i.e. not Wales, Scotland or Northern Ireland): 

* at admin level 6, there should be full coverage, either as an
administrative county or a unitary authority
* at admin level 8, partial coverage - full within administrative
counties, none within unitary authorities
* at admin level 10, partial coverage - complex situation with many
"unparished areas" and "lands common"

In the case of West Yorkshire, the constituent councils used to be
Metropolitan Boroughs at AL8 when West Yorkshire was an administrative
county. These days the constituent councils are Unitary Authorities and
should therefore be at AL6 themselves for consistency with other UAs.
Tagging West Yorkshire at AL6 as well would currently break the model. 

On 2020-07-27 08:55, Frederik Ramm wrote:

> Hi,
> 
> On 7/27/20 00:50, Colin Smale wrote: 
> 
>> If they are accepted as boundary=administrative, what admin level should
>> be used? The LAs of which the CAs are composed are sometimes
>> Metropolitan Boroughs with admin_level=8, and sometimes Unitary
>> Authorities with admin_level=6. I am tending towards admin_level=5; this
>> value is/was in use for the Regions, but they no longer have an admin
>> function (if they ever had one) so I consider admin level 5 as
>> "available" for use by Combined Authorities.
> 
> A question that should be considered together with this is: Does/should
> England have full coverage (i.e. no "holes") on boundary=administrative
> with any admin level above 4?
> 
> Situation in many countries is that they "mostly" do on 6, with some
> exceptions for city states, capital districts and the like. I have
> absolutely no idea how this is in England and won't offer any - just
> saying it is worth thinking about. For example, the edit that prompted
> this discussion added a boundary=adminsistrative to West Yorkshire,
> which until then was a "hole" in the AL6 map.
> 
> Bye
> Frederik___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] Admin Boundaries and Combined Authorities

[Colin Smale]

Hi, 

I think we need to discuss tagging of Combined Authorities. I spotted an
edit that changed the tagging on West Yorkshire Combined Authority, and
it was pointed out to me that there were already other instances of
similar tagging for Combined Authorities (Greater Manchester for
example). 

CAs have basically zero interaction with the public, except for the
directly elected Mayor; although they have certain statutory tasks
(public transport etc). They can be seen as a grouping of local
authorities, as opposed to a LA in their own right. Should they really
be tagged as boundary=administrative at all? Or should they have a
parallel hierarchy as is used for police areas for example? 

If they are accepted as boundary=administrative, what admin level should
be used? The LAs of which the CAs are composed are sometimes
Metropolitan Boroughs with admin_level=8, and sometimes Unitary
Authorities with admin_level=6. I am tending towards admin_level=5; this
value is/was in use for the Regions, but they no longer have an admin
function (if they ever had one) so I consider admin level 5 as
"available" for use by Combined Authorities. 

An alternative may be to represent them as relations containing as
members the constituent authorities. This would have the advantage of
the ability (through the use of roles) to distinguish between
"constituent councils" which are full members and "non-constituent
councils" which only participate in certain committees. 

Any thoughts or comments?___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Electric vehicle charging points

[Colin Smale]

On 2020-07-21 22:54, Mark Goodge wrote:

> It's the errors which are more of a problem, because it's generally better 
> not to map something than to map it wrongly.

This is a difficult point. Data is never 100% complete, and frequently
not 100% accurate. At what point it becomes better not to have the thing
in OSM at all, is rather subjective. 

If the location was only accurate to ±50m, would it still be good
enough? 
If the operator was not tagged, would it still be good enough? 

Is an "imperfect" object in OSM more likely to get corrected than a
missing object is to get added? Should I not add a missing object
because I cannot be sure of the "operator" for example? Talking about
the charging points data set, how can one detect what is an error? 

I would say, get the data out there, and let the world feed back any
inaccuracies to the source for inclusion in the next version.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Paths on Wimbledon Common

[Colin Smale]

What does "legally accessible" mean? Are they Public Footpaths? Do we
tag all Public Footpaths with an explicit "foot=yes" or is
"designation=public_footpath" enough?

On 2020-07-10 13:54, Andrew Hain wrote:

> I have been doing some tidying based on Osmose, including the warning for 
> highway=footway foot=yes, which is often left over from a preset in Potlatch 
> 1. 
> 
> https://www.openstreetmap.org/changeset/87672607 
> 
> I got a changeset comment querying the edit.
> 
> * I note you have removed foot=yes from highway=footway. My understanding is 
> that the default for a footway is foot=designated, but designated requires an 
> explicit sign. the paths on Wimbledon Common do not have an explicit sign, 
> but are legally accessible, hence foot=yes. Perhaps osmose is wrong.
> * Any comments?
> * --
> * Andrew
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] "secret" site

[Colin Smale]

It was completed in 1964 as the GPO Tower. The GPO became the Post
Office in 1969, at which time the tower was also renamed. 

https://en.wikipedia.org/wiki/General_Post_Office 

https://en.wikipedia.org/wiki/BT_Tower

On 2020-06-29 23:40, Steve Doerr wrote:

> On 29/06/2020 08:20, Ken Kilfedder wrote: 
> 
>> The GPO Tower (AKA Telecom Tower AKA BT Tower) only started to appear in 
>> public maps in 1984
> 
> I don't remember it ever being called the GPO Tower. It was always the Post 
> Office Tower.
> 
> --
> Steve___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Rockall

[Colin Smale]

On 2020-06-15 23:14, barry b wrote:

> Hi Folks, I made the below changes to rockall.

Thanks for engaging! 

> The changes i've made are 
> 1) Changed Rockall from Island to Rock 
> 2) Removed the Administration boundary 
> 
> 1) Rockall is not a island.  You could debate its a rock or islet but it cant 
> sustain human life. 
> References: 
> 1) Wikipedia calls it a islet 
> 2 https://www.kildarestreet.com/wrans/?id=2011-03-24.365.0 [1] Irish 
> Government call it a rock 
> 3)https://www.whatdotheyknow.com/request/97923/response/262438/attach/html/3/0109%2012.pdf.html
>  - Uk Government call it a islet  
> 4) The hint is in its name 

OSM knows about islets - tagged as place=islet (as opposed to
place=island) 

> 2) The reason for removing the administration boundary is i wanted to remove 
> the EEZ around rockall.( The big circle) 
> From a visual point of view this looks off. it implies there is an island or 
> county there. But more importantly it is incorrect

Changing the data "incorrectly" to achieve a desired appearance on a
particular map is rather frowned upon in OSM; we call it "tagging for
the renderer". So any arguments that it "looks off" tend to be declared
null and void... The underlying data needs to be correct, and if it
still "looks off", then it's the visualisation that needs fixing. It
even has its own wiki page:
https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer 

> Firstly even according the the UK. The EEZ wouldn't be 200nm, it would be 12 
> - 
> https://www.whatdotheyknow.com/request/97923/response/262438/attach/html/3/0109%2012.pdf.html
>  [2]

As I read it, it makes it clear that the territorial waters extend to
12nm, and the EEZ to 200nm from the baseline; for this latter purpose
Rockall is ignored as it "cannot sustain life" etc (although it is
covered by that 200nm EEZ) but Rockall itself and the 12nm territorial
sea around Rockall are claimed as UK territory. 

> Secondly. No country accepts the EEZ and is considered international waters. 
> Several countries claim it Iceland, Denmark , UK and Ireland. 
> 
> In the coming months this rock in the middle of nowhere could potentially 
> turn into a larger issue with the UK exit from the EU as Iceland, Ireland and 
> other EU country all fish here 
> Last summer there was a standoff with the UK Navy and fishing boats. The 
> Irish Navy have also regularly patrol the area in protection of fishery 
> 
> I can give a list of references to show the EEZ recognized, but i don't think 
> that helpful 
> 
> I don't know the exact procedure here. I feel i didn't do it right.

Don't worry too much about "not doing it right", just about everybody
here has "been there done that got the t-shirt". 

It's exactly because this is/could be controversial that we need to
tread carefully. We did this recently with Crimea for example. OSM needs
to remain strictly neutral and tends to follow the international
consensus and/or the actual, verifiable status "on the ground". 

Colin 
  

Links:
--
[1] https://www.kildarestreet.com/wrans/?id=2011-03-24.365.0
[2]
https://www.whatdotheyknow.com/request/97923/response/262438/attach/html/3/0109%2012.pdf.html___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Rockall

[Colin Smale]

I just pointed the user concerned to the signup page to this mailing
list, so he should be here soon! Further to my earlier message I will
not make any changes to Rockall until we have had the discussion. 

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

Re: [Talk-GB] Rockall

[Colin Smale]

On 2020-06-15 15:36, Mark Goodge wrote:

> I'd just revert it.

I'll give them until tomorrow to see if there is any further engagement.
Otherwise I will fix it up as place=islet and resurrecting the coastline
and admin boundaries. 

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

[Talk-GB] Rockall

[Colin Smale]

A new mapper has changed the status of Rockall, removing it from the UK
admin boundaries. As I understand it Rockall is accepted as UK territory
although it can't be used as a baseline to extend the EEZ. I contacted
the mapper with a changeset comment and their motivation is based on
"fixing the EEZ". 

Wikipedia suggests that Rockall is considered (administratively
speaking) part of the isle of Harris, in the Western Isles. 

As Rockall has from time to time been the subject of a territorial
dispute with Ireland, should we use the "disputed territories" process
for Rockall? 

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

Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?

[Colin Smale]

On 2020-06-12 13:00, Frederik Ramm wrote:

> Hi,
> 
> I wonder if it would be feasible or desirable for editors to warn users
> if they are at risk of creating country/world-spanning changesets.
> Something like "you have unsaved edits more than 500km away from where
> you are editing at the moment, please upload those before you continue"
> or so.
> 
> World-spanning changesets are a constant source of irritation, and very
> rarely intentional.

But sometimes they are intentional, so they should not be prevented
entirely, but possibly just challenged. Admin boundaries may need to be
exempted? 

I am not sure how the bounding box for the changeset is calculated at
present, but for these purposes it should possibly be limited to the
nodes that have changed, and not automatically expanded to the entire
way or relation that the change impacts. Moving one node on a country
boundary should not classify the changeset as covering the whole
country. 

There are probably farms in Texas bigger than Luxembourg... Where do you
draw the line?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Should we map things that do not exist?

[Colin Smale]

On 2020-05-25 18:52, Mateusz Konieczny wrote:

> Even if "Nothing is "approved"" is true it does not mean that nothing is 
> forbidden. 
> Can you name one tag that is "forbidden"? Does that mean a standing 
> instruction to all mappers to remove it whenever it is found, or a license to 
> do a seek-and-destroy across the whole database? Or does "forbidden" not 
> quite mean "may not appear in OSM"? "Frowned upon" possibly.

I would say that 

"Does that mean a standing instruction to all mappers to remove it
whenever it is found, 
or a license to do a seek-and-destroy across the whole database?" 

applies to several things (listed below). 

>> Is there any case of a whole class of objects being removed from OSM on the 
>> grounds  
>> that they "do not belong"? Who would burn their fingers on that? 
>> Depends on what you mean by "whole class of objects".
> 
> Class, category, whatever... A subset of the objects in the OSM data with 
> common characteristics. 
> 
>> If we are looking to set a precedent for that it would probably be wiser to 
>> pick on a less controversial and emotive subject. 
>> 
>> We have precedent that entire classes and types of things are 
>> out of scope.
> 
> Where is that written down? What classes and types of things have been 
> declared out of scope?

For example things that I immediately remember 

- fictional objects 
- blatantly subjective things like reviews, ratings 
- mapping of private objects (location of my bed) 
- mapping of moving objects (location of myself or a moving ship or
plane) 
- completely gone objects (for railways the question is when railway is
fully gone) 
- personal detail (ties into subjective ones) like "my favorite trees",
or "towns I visited" 
- objects on Moon/Mars and other locations outside Earth 

Objects with these characteristics cannot be (easily) identified in the
data - they would need a human to judge on a case-by-case basis (except
for the extra-terrestrial things, but you might have trouble defining
their location in terms of WGS84 lat/lon anyway...) 

Subjective data is by definition not independently verifiable, so that
can go. Ratings are sometimes awarded by a recognised body (rather than
by customers), and those ratings would IMHO qualify as independently
verifiable.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Should we map things that do not exist?

[Colin Smale]

On 2020-05-25 17:08, Mateusz Konieczny via talk wrote:

> May 25, 2020, 16:48 by colin.sm...@xs4all.nl: 
> 
> On 2020-05-25 16:20, Jack Armstrong wrote: 
> 
> Why are railways given a special status? 
> 
> Nobody gives anything a status in OSM. Nothing is "approved" so nothing is 
> "forbidden" either.

It is not really accurate - there is plenty of forbidden things (like
running 
imports without discussion, we have tags that are silently removed by 
editors like iD and JOSM). 
Doing imports without discussion more about the process, and less about
the details of the result. An import can be declared "bad" for many
reasons. 

If iD and JOSM remove certain tags when they are encountered, that is
different from removing whole objects. 

> We have voted on tags that are described as "approved". 
> 
> Even if "Nothing is "approved"" is true it does not mean that nothing is 
> forbidden.

Can you name one tag that is "forbidden"? Does that mean a standing
instruction to all mappers to remove it whenever it is found, or a
license to do a seek-and-destroy across the whole database? Or does
"forbidden" not quite mean "may not appear in OSM"? "Frowned upon"
possibly. 

> Is there any case of a whole class of objects being removed from OSM on the 
> grounds  
> that they "do not belong"? Who would burn their fingers on that? 
> Depends on what you mean by "whole class of objects".

Class, category, whatever... A subset of the objects in the OSM data
with common characteristics. 

> If we are looking to set a precedent for that it would probably be wiser to 
> pick on a less controversial and emotive subject. 
> 
> We have precedent that entire classes and types of things are 
> out of scope.

Where is that written down? What classes and types of things have been
declared out of scope? Any record of a transparent process that led to
that?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Should we map things that do not exist?

[Colin Smale]

On 2020-05-25 16:20, Jack Armstrong wrote:

> Why are railways given a special status?

Nobody gives anything a status in OSM. Nothing is "approved" so nothing
is "forbidden" either. It is either used, or it is not used. It is not
even "forbidden" to use tags that someone has declared "deprecated". 

Is there any case of a whole class of objects being removed from OSM on
the grounds that they "do not belong"? Who would burn their fingers on
that? 

If we are looking to set a precedent for that it would probably be wiser
to pick on a less controversial and emotive subject.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access

[Colin Smale]

On 2020-05-25 10:27, Florian Lohoff wrote:

> A small and very vocal part of the German community proposes to tag
> EVERY driveway - no matter if it has a gate or sign with access=private.
> Somebody slipped stuff into the German access=private page which i
> removed a while back as it had no consensus. Still some continue with
> this practice and for me they break the delivery use-case and a lot of
> other stuff (You cant to blind navigation to the front door as private
> has to be honored)
> 
> You cant tell whether this access=private is okay to break, and the
> other not.

"private" is not the same as "no". It simply means that the owner has
the right to decide who to admit, and the default is "no access" unless
you have explicit or implicit permission from the owner. 

With respect to private driveways, they are simply private. The owner
will tolerate friends and neighbours, postmen, delivery drivers etc
coming to the door - you could say they have implicit permission. A
random person however has no implicit permission and must keep out. 

In Germany it sounds like it is the same as it is here in the
Netherlands. If you don't put up a sign saying "keep out" or equivalent,
no actual offence is committed by passing the sign onto your land.
However you, as the land owner, have the sole right to erect such a sign
at your discretion and to make the rules as you see fit. 

There is also the category "access=permissive" which is in the middle.
You have no statutory right to access the land, however the owner has
clearly decided to allow the public access (i.e. everybody has implicit
permission). The owner can (in theory at least) rescind that implied
easement at any time or otherwise restrict access.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access

[Colin Smale]

On 2020-05-25 00:16, Florian Lohoff wrote:

> On Sun, May 24, 2020 at 11:54:02PM +0200, Colin Smale wrote: On 2020-05-24 
> 23:16, Mateusz Konieczny via talk wrote:
> 
> Can you give an example of such untaggable restriction? 
> In the UK there are many small roads signed as "Unsuitable for HGVs."
> Legally you are allowed to drive your 44T truck down there, but you will
> almost certainly get stuck. How do we tell the router?

width? maxwidth? 

It needs to be a physical attribute, not a purely legal one. It could be
a combination of road width and bends, or undulations giving a risk of
grounding. For the former, the router would need accurate geometry info
(centre line and width) which is often not present or not reliable in
OSM. For the latter, do we have anything for "risk of grounding due to
dips and humps"? 

> It a different attribute than legalese which makes it unsuitable - so
> tag it appropriate.
> 
> There are also many roads signed as "No HGVs except for access." It is
> tempting to tag them as "hgv=destination" but that doesn't cover the
> case where you are allowed to follow that route for many miles and make
> several turnoffs IF you "need access". The current definition of
> "access=destination" doesn't allow routers to distinguish between truly
> "first/last segment only" and "its fine if you are going to/from this
> general area". 
> Discussion here shows the  
> http://www.trucknetuk.com/phpBB/viewtopic.php?f=5=140446
> Thats a technical difficulty in the OSM Data model which may fill pages.
> 
> At least in Germany a restriction sign is not a "linear restriction"
> e.g. is restricting the whole way. Instead you may not traverse the
> point of the sign. We are currently unable to put this into OSM.
> 
> A workaround is to put 2 short oneways on top of each other - one of
> them carrying the restriction - which is in itself a pretty ugly
> solution - and - this does not work for destination.
> 
> There are other problems. A destination technically is currently solved
> by increasing the "cost" in the routing graph. So for example for
> every meter on a destination road you may travel 20m on others. Which
> most of the time works pretty well in avoiding the destination roads.
> It has pretty bad side effects which causes the router to try to send
> you out of the destination area with the shortest way even producing
> very long diverts around.

You talk as if all routers are the same I accept that such
heuristics are inevitable to choose between multiple possibilities, but
proposing a route that would actually be considered illegal should not
ever happen (subject to data currency considerations). 

But still, access=destination does not permit the router to apply
different penalties to the two cases I mentioned. 

> Legally this is broken. Legally you may not enter the zone when
> your destination is not within that zone and there nothing like a 
> distance based penalty within that area.
> 
> So yes - there is a problem - But not within tagging. Its something
> routers need to solve.

Routers cannot work alone, they have to work together with the tagging.
It's not fair to claim it's all their problem. If the tagging does not
represent the nuances required, the router should not be expected to
just guess (at least where the difference is between legal and illegal).___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access

[Colin Smale]

On 2020-05-24 23:16, Mateusz Konieczny via talk wrote:

> Can you give an example of such untaggable restriction?

In the UK there are many small roads signed as "Unsuitable for HGVs."
Legally you are allowed to drive your 44T truck down there, but you will
almost certainly get stuck. How do we tell the router? 

There are also many roads signed as "No HGVs except for access." It is
tempting to tag them as "hgv=destination" but that doesn't cover the
case where you are allowed to follow that route for many miles and make
several turnoffs IF you "need access". The current definition of
"access=destination" doesn't allow routers to distinguish between truly
"first/last segment only" and "its fine if you are going to/from this
general area". 
Discussion here shows the  
http://www.trucknetuk.com/phpBB/viewtopic.php?f=5=140446 

And then there are all the subtle differences in the semantics of the
vehicle classes, but that's a whole different can of worms...___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access

[Colin Smale]

On 2020-05-24 20:47, Florian Lohoff wrote:

> - The "Ground truth" we tag restrictions only when visibly assigned and
> verifyable.

It is sufficient to say "verifiable". It does not always need to be
evidenced by a visible sign - as long as another independent mapper
could (easily) verify its truth. The fact that (in many countries) speed
limits and parking rules change when you enter a settlement means that
these attributes are verifiable without there needing to be an explicit
sign. 

> So - people try to overload the meaning of access=private
> with something more like ownership=private.

Access=private always means you have no "right" of access, and must keep
out unless you have permission from the appropriate authority (be that
the owner of a driveway or the operator of a nuclear power station).
That permission can be explicit (a permit or invitation) or implicit
(delivery drivers etc). Routers frequently apply different rules for the
first and last segments of a route, blocking routing over "private"
roads in the body of the route but not hesitating to use them if they
are the only way to access the start and destination locations.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Quality and the Openstreetmap value chain

[Colin Smale]

On 2020-05-12 15:28, Jean-Marc Liotier wrote:

> On 5/12/20 2:52 PM, Colin Smale wrote: 
> 
>> As you and many others frequently remind us: OSM is first and foremost about 
>> the data and not any specific use-case or rendering thereof.
> Yes - but a data model is not a neutral representation of reality: it is a 
> projection through a use-case, mapping reality to a construct fit for 
> specific purposes. In the relational database world, we cannot produce a 
> satisfactory schema without knowledge of what sort of queries are intended. 
> Flattening the highly dimensional reality into any data model involves such 
> choices. Closer to the daily preoccupations of Openstreetmap, even lists of 
> attribute values are reductionist and finding the appropriate tradeoff cannot 
> be achieved isolatedly: it requires input from those who will deal with the 
> consequences of the choices - the data-consuming users.

Absolutely, well put. Any kind of modelling requires reductions of
complexity, trade-offs and compromises. Which nuances are we going to
include, and which are we going to consciously choose to leave out? If
we don't leave anything out, we have not modelled reality, we have
duplicated it. 

The role I expect of the data consumers is to articulate how they would
like to view the data (including what attributes they are expecting),
and not to dictate how that data is stored/represented internally.
Cartography, geography, statistics etc are very different skills to data
modelling and database design.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Quality and the Openstreetmap value chain

[Colin Smale]

On 2020-05-12 14:06, Frederik Ramm wrote:

> Colin,
> 
> you're lumping in a few different things together I think.
> 
> The scarce resource in this project are still mappers, not consumers.
> The mappers certainly want to make a good and usable map; but if you are
> faced with a choice of either making mapping more difficult or making
> using more difficult, I would still argue for ease of mapping any time -
> especially as, for reasons of diversity, we're trying to extend the
> "long tail" of mappers who might not be willing and able to learn the
> ins and outs of public transport relation mapping.
> 
> So yes, let's give mappers the tools they need and let us have a
> dialogue with users about what they find useful, but if anything the
> users want means more complexity for mappers, I'm skeptical.

Thanks for the reply Frederik. It can't be impossible to have a
well-engineered internal setup, combined with a user-friendly external
interface. I.e., do the Right Thing in terms of data structures, tagging
models etc etc and present that to the user (through editors, primarily)
in a user-friendly way. I know it can be done, I have been doing just
that for 30 years. 

But it does require a level of meta-modelling. Real-world objects
(recognisable to mappers) need to be mapped onto internal concepts. At
present we have only nodes, ways and relations. Let's expand that
upwards to include simple polygons, complex polygons, fuzzy areas,
polylines etc (curved lines anyone?) Multipolygons and their alter ego
boundary relations are a step in the right direction, but why is a
boundary relation not simply defined as a "subclass" of a multipolygon
for example? 

And then a layer of high-level "constraints" such as coastline needing
to go anticlockwise. Is a relation an ordered list or not? The
documentation says it is, but why dp editors not make it very easy to
sort/re-order the members, or do it automatically? 

Next level would involve tagging: for each object type, which fields are
mandatory, recommended, optional, prohibited? What about regional
applicability? What is mandatory in one place may be optional somewhere
else. 

Editors can be coded to know about the metamodel, and then the
constraints; a config file (JSON, XML, whatever) can provide the tagging
schemas for the individual object classes. So we are not accused of
imposing stuff from above: let's merge in an unmanaged config file on
top of that so users can have their pet tags. 

As you and many others frequently remind us: OSM is first and foremost
about the data and not any specific use-case or rendering thereof. We
should take care to follow our own advice and nurture the data
(quality), while at the same time not being afraid to revisit the data
model and/or underlying metamodel. 

The community model of peers, with (by design) no real governance, has
led to a lot of frustration, wheelspin and stagnation when it comes to
making real progress on many fronts. We need to work on defining what we
mean by "data quality", making it objectively measurable (if you can't
measure it, you can't manage it), and taking steps to improve it. But
any definition of quality depends on articulating what is
good/right/expected vs bad/wrong/unexpected, and this is where we are
far too timid!___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Quality and the Openstreetmap value chain

[Colin Smale]

On 2020-05-12 12:34, Jean-Marc Liotier wrote:

> On 5/12/20 11:42 AM, Richard Fairhurst wrote: 
> 
>> I love the fact that we are now 50 messages into discussing, for the second
>> time, a change that would be made ostensibly for the benefit of data
>> consumers, and yet no one has asked any actual data consumers.
> 
> Yes. Users are the ultimate measure of quality, yet they are most often 
> absent from our discussions. Our history explains why: in the beginning, we 
> had a blank map, which we set upon filling with whatever we could, to get the 
> stone soup started. There were no consumers at all - so naturally our 
> universe was supply-side entirely: the availability of data inspired usage, 
> which came second. Nowadays, Openstreetmap is used - let's take advantage of 
> that to improve ! Looking at the world and thinking about how we should model 
> it should be done with an understanding of how users want it. This is 
> difficult when we have few users around and very little feedback from 
> downstream. So, if one has opportunities to bring that to our knowledge, 
> please do: it is valuable information to the Openstreetmap project, 
> information without which we cannot allocate our efforts optimally.

+1000 

If I had a «currency unit» for every time "ease of mapping" has trumped
"quality and usability of data" I would be pretty rich now. We have
always shied away from anything that would define data quality, as such
discussions inevitably involve the definition of "good" and "bad", and
"right" and "wrong". These discussions get killed stone dead as soon as
someone says "we can't change the data", "it would be too difficult for
mappers to understand", "applications expect the old way" etc.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] CWGC: worldwide, war graves

[Colin Smale]

On 2020-04-26 14:26, Tony OSM wrote:

> If we generate a tag schema it clearly needs to be applicable to other grave 
> organisations - e.g. German War Graves Commission - _Volksbund Deutsche 
> Kriegsgräberfürsorge_ in German.

So we need a more abstract concept like "War Cemetery": 

war_cemetery=cwgc 

or 

war_cemetery:cwgc=yes 

I suspect the CWGC don't "own" or "operate" many of these (shared)
locations or graves - they would just be cataloguing the facts.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] CWGC: worldwide, war graves

[Colin Smale]

=yes would flag its existence and someone could add the actual id number
later. I assume you consider the presence of the sign as sufficient
evidence that the site actually exists. It may refer to specific graves
in a general cemetery (so it would be an additional attribute of the
cemetery object) but it may also be a dedicated cemetery in its own
right.

On 2020-04-26 14:16, Andy Townsend wrote:

> That'd work when if I know the reference, but what if I've only seen the sign?
> 
> On 26/04/2020 13:09, Colin Smale wrote: 
> 
> ref:cwgc=* would kill two birds with one stone, would it not? 
> 
> On 2020-04-26 13:44, Andy Townsend wrote: 
> Hello,
> 
> How is it suggested to tag "there are commonwealth war graves here"?
> 
> At least near me, there's usually a fairly large white on green sign near the 
> entrance, so even if it's not something you'd explicitly go out to map, it's 
> often something that you'd notice.
> 
> Best Regards,
> 
> Andy
> 
> On 25/04/2020 22:20, Daniel Pocock wrote: 
> On 25/04/2020 22:55, Michael Booth wrote: This seems to be it:
> https://lists.openstreetmap.org/pipermail/talk-gb/2010-August/010110.html
> 
> Found via a search for: site:lists.openstreetmap.org "talk-gb"
> "Commonwealth" Thanks for finding that so quickly
> 
> Daniel, what is actually being proposed to be added to OSM? Is it a list
> of CWG cemeteries that could then be checked against the data we have in
> OSM? I remember seeing a maproulette for cemeteries in Texas, perhaps
> something similar could be done to find missing CWG cemeteries. Please see 
> the CWGC and TracesOfWar lists on this page:
> 
> https://anzacathon.com/data-sources.shtml
> 
> They simply have the name of the cemetery or monument, the latitude and
> the longitude
> 
> CWGC has 20,000 records, TracesOfWar has 120,000 records
> 
> AWM also has about 14,000 records for places but they are not in the
> IPFS world yet.
> 
> Regards,
> 
> Daniel
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

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

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

Re: [Talk-GB] CWGC: worldwide, war graves

[Colin Smale]

ref:cwgc=* would kill two birds with one stone, would it not? 

On 2020-04-26 13:44, Andy Townsend wrote:

> Hello,
> 
> How is it suggested to tag "there are commonwealth war graves here"?
> 
> At least near me, there's usually a fairly large white on green sign near the 
> entrance, so even if it's not something you'd explicitly go out to map, it's 
> often something that you'd notice.
> 
> Best Regards,
> 
> Andy
> 
> On 25/04/2020 22:20, Daniel Pocock wrote: 
> On 25/04/2020 22:55, Michael Booth wrote: This seems to be it:
> https://lists.openstreetmap.org/pipermail/talk-gb/2010-August/010110.html
> 
> Found via a search for: site:lists.openstreetmap.org "talk-gb"
> "Commonwealth" Thanks for finding that so quickly
> 
> Daniel, what is actually being proposed to be added to OSM? Is it a list
> of CWG cemeteries that could then be checked against the data we have in
> OSM? I remember seeing a maproulette for cemeteries in Texas, perhaps
> something similar could be done to find missing CWG cemeteries. Please see 
> the CWGC and TracesOfWar lists on this page:
> 
> https://anzacathon.com/data-sources.shtml
> 
> They simply have the name of the cemetery or monument, the latitude and
> the longitude
> 
> CWGC has 20,000 records, TracesOfWar has 120,000 records
> 
> AWM also has about 14,000 records for places but they are not in the
> IPFS world yet.
> 
> Regards,
> 
> Daniel
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [OSM-talk-nl] BAG straatnamen (ook?) in OSM

[Colin Smale]

On 2020-04-14 18:52, g.id...@zonnet.nl wrote:

> Hoi Richard,
> 
> De adressen in OSM worden bijgewerkt op basis van de BAG WFS. Daarin staan 
> echter geen BAG adres id's, maar BAG verblijfsobject id's. Dat is de reden 
> dat geen BAG id's op de adressen in OSM zitten. Wat ik zelf overigen ook een 
> groot gemis vind.
> Op de panden zitten wel BAG id's. Op de straten weer niet.
> 
> Voor de straten is er de optie om de tag alt_name te gebruiken voor de BAG 
> naam, als deze afwijkt van de uitgeschreven naam. Dit zie je bijvoorbeeld in 
> Bunnik en Odijk. Dan zijn echter de namen op de straten en niet op de 
> adressen. Een tag voor de officiele straatnaam op een adress heb ik niet 
> kunnen vinden. Dat zou iets als addr:street:official of zo moeten worden.

Dit gaat niet echt over straatnamen, maar over de schrijfwijze ervan. Er
is maar één bron van de officiële volledige schrijfwijze: het
gemeentebesluit waarin de naam wordt toegekend. Daarnaast zijn er
verschillende erkende schrijfwijzen in gebruik, met eigen regels voor
afkortingen, leestekens, accenten, hoofdletters, numerieke delen, enz. 

https://www.digitaleoverheid.nl/overzicht-van-alle-onderwerpen/basisregistraties-en-afsprakenstelsels/stelsel-van-basisregistraties/schrijfwijze-registreren-en-presenteren-adressen-stelsel-basisregistraties/


De straatnaam zoals die in de BAG staat, is misschien niet helemaal
gelijk aan het gemeentebesluit - en dan heb je altijd de mogelijkheid
van een typefout. 

Of een straatnaam (bijvoorbeeld) met puntjes of zonder geschreven wordt,
verandert niets aan de eigenlijke straatnaam; een mens ziet misschien
makkelijker dan een computer dat het om dezelfde straat gaat. 

> Ik kan op dit moment eenvoudige oplossing bedenken. Dan kom je toch geo 
> oplossingen zoals die van Bas, of koppelingen op basis van 
> postcode-huisnummer. In het verleden (2015) heb ik wel eens een vergelijking 
> gemaakt tussen OSM en BAG straten (zie bijlage). Misschien heb je daar iets 
> aan.
> 
> Nu er een prijskaartje aan de BAG hangt, is de drempel voor dat soort hobby 
> projectjes toch wat hoger.

Als je op GitHub kijkt, zijn de extracten (gratis) per gemeente te
downloaden. Heb je daar wat aan? 
https://github.com/lvbag/BAG-2.0-Extract/tree/master/BAG%202.0%20gemeente%20extracten%20productie___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [Talk-GB] Town Greens

[Colin Smale]

Considering that it is legally and functionally the same as a Village
Green, I would say use the same tag i.e. landuse=village_green. It may
be *called* a town green because it belongs to a settlement that is a
town (who decides that is a whole other discussion) and/or has a Town
Council (which is, again, legally and functionally the same as a Parish
Council with the addition of a Town Mayor). 

Village greens, town greens, designated commons etc all suffer from the
same problem in OSM: they have a certain legal status, but both the
landuse to which they are actually put, and the landcover (grass etc),
vary. So actually landuse=village_green is a misclassification in the
taxonomy because it is not (always or by definition) "the use to which
the land is put".

On 2020-04-03 12:48, nathan case wrote:

> Hi all, 
> 
> I made a recent edit to a local area that has recently been designated a 
> "Town Green". 
> 
> Edit: https://www.openstreetmap.org/changeset/82973329 [1] 
> 
> News: 
> https://www.lancasterguardian.co.uk/news/lancasters-freemans-wood-looks-set-become-town-green-after-eight-year-battle-1357617
>  [2] 
> 
> 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). 
> 
> But I ran into some problems mapping it. 
> 
> The "village green" landuse tag doesn't seem appropriate (as it doesn't fit 
> the characterises described) - despite being legally the same. 
> 
> Park and/or recreation landuse tags don't seem appropriate either - it isn't 
> either of those, despite the leisure connotations the land holds. 
> 
> Nature reserve didn't seem appropriate as, although the land is now 
> protected, it isn't formally a reserve. 
> 
> So I've opted for the boundary=protected_area schema. From the protect_class 
> options, 21 seemed like the most relevant: "Community life: religious, sacred 
> areas, associative locations, recreation". 
> 
> Unfortunately, this now means the land (specifically its boundary and name) 
> is not being rendered. Of course I know not to tag for the renderer but I 
> wanted to check the validity of my approach. 
> 
> Is there an agreed upon approach for town greens in the UK? Is there anything 
> I could do, within the correct schema, to show this important local area on 
> the default map? 
> 
> Cheers! 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
 

Links:
--
[1] https://www.openstreetmap.org/changeset/82973329
[2]
https://www.lancasterguardian.co.uk/news/lancasters-freemans-wood-looks-set-become-town-green-after-eight-year-battle-1357617___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Anyone in South-West London?

[Colin Smale]

I have commented on a major change to the admin boundary between
Richmond and Hounslow, but there are a number of other changes in the
same area including a rather suspicious "kink" in the Chertsey Road.

https://www.openstreetmap.org/#map=18/51.44262/-0.36386 

The "Lincoln Arena" seems to have disappeared (still visible on old
tiles) - no idea if this is part of the same edit, or whether it's
correct. 

On 2020-03-30 19:58, Andy Townsend wrote:

> I've sent another "message to be read before continuing to edit" 
> https://www.openstreetmap.org/user_blocks/3592 . 
> 
> It'd be good if everyone could have a look at 
> https://www.openstreetmap.org/changeset/82834995 and comment there if there 
> are further problems (I've added the first obvious question).  I've 
> explicitly said at the current block that they should answer questions that 
> have been asked before any more editing. 
> 
> Best Regards, 
> 
> Andy
> 
> On 30/03/2020 18:35, Colin Smale wrote: 
> 
> He's back, and he's unimpressed... 
> 
> https://www.openstreetmap.org/changeset/82834995 
> 
> "Reverted edits as many of mine were falsely removed"
> 
> On 2020-03-25 21:54, Andy Townsend wrote: 
> On 25/03/2020 16:02, Jez Nicholson wrote: 
> Heh, none of the references on the Wikipedia page link to anything mentioning 
> that it exists. I call bullsh/t 
> 
> Indeed - https://en.wikipedia.org/wiki/User_talk:Tfondie does not look 
> promising. 
> 
> On Wed, Mar 25, 2020 at 2:34 PM Andrew Hain  
> wrote: 
> 
> I wonder if Tfondie who created the Wikipedia page may be the same person.

I've "sent them a message that they have to read before continuing to
edit" at https://www.openstreetmap.org/user_blocks/3585 . 

We'll see what happens next; if there's no reply after a week or so I'll
revert their remaining edits that haven't since been edited by other
users; most have been reverted already but some (such as
https://www.openstreetmap.org/way/783299940 ) remain and look somewhat
implausible. 

Best Regards, 

Andy (from the DWG) 

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

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

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

Re: [Talk-GB] Anyone in South-West London?

[Colin Smale]

He's back, and he's unimpressed... 

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

"Reverted edits as many of mine were falsely removed"

On 2020-03-25 21:54, Andy Townsend wrote:

> On 25/03/2020 16:02, Jez Nicholson wrote: 
> 
>> Heh, none of the references on the Wikipedia page link to anything 
>> mentioning that it exists. I call bullsh/t
> 
> Indeed - https://en.wikipedia.org/wiki/User_talk:Tfondie does not look 
> promising. 
> 
> On Wed, Mar 25, 2020 at 2:34 PM Andrew Hain  
> wrote: 
> 
> I wonder if Tfondie who created the Wikipedia page may be the same person.

I've "sent them a message that they have to read before continuing to
edit" at https://www.openstreetmap.org/user_blocks/3585 . 

We'll see what happens next; if there's no reply after a week or so I'll
revert their remaining edits that haven't since been edited by other
users; most have been reverted already but some (such as
https://www.openstreetmap.org/way/783299940 ) remain and look somewhat
implausible. 

Best Regards, 

Andy (from the DWG) 

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

Re: [Talk-GB] Adding Leeds Bins to OpenStreetMaps

[Colin Smale]

Having both ref and id in the key seems a bit like overkill to me...
ref:UK:leedscc:bin ?

On 2020-03-26 13:13, Patrick Lake wrote:

> Hi, 
> 
> The ID is only used for bins, so by the sounds of it we may as well go for 
> ref:UK:leedscc:bin:id so hopefully we won't have to change it in the future. 
> Then if we end up adding more of LCC's assets (which we might do in the 
> future, if we can persuade LCC to rely on OSM more) we can use a similar 
> convention. 
> 
> Re the waste_basket:defects tag - you are right that it should be quite 
> transient, but it seemed like a useful thing to include for LCC's sake. The 
> problem is whether they'd bother to edit it after repairs etc. Happy to leave 
> it out if it doesn't really fit. 
> 
> The operator tag makes more sense too, cheers. 
> 
> Patrick
> 
> From: Jez Nicholson 
> Date: Thursday, 26 March 2020 at 11:54
> To: Andy Mabbett 
> Cc: "talk-gb@openstreetmap.org" 
> Subject: Re: [Talk-GB] Adding Leeds Bins to OpenStreetMaps 
> 
> I've seen requests (from the French) for refs to be country namespaced, e.g. 
> ref:UK:leedscc:id or ref:UK:leedscc:bin:id Seems like overkill to start with, 
> but then it does prevent duplication. 
> 
> Is the LLC id a number used for bins only, or for all types of asset? 
> 
> On Thu, Mar 26, 2020 at 11:37 AM Andy Mabbett  
> wrote: 
> 
>> On Thu, 26 Mar 2020 at 10:10, Patrick Lake  wrote:
>> 
>>> I thought of just tagging the LCC ID as lcc:id as I assume it will be 
>>> meaningless to anyone not from the council.
>> 
>> To avoid conflicts with Liverpool, or Lima, please consider using
>> leedscc:id etc.
>> 
>>> Here's the rest of the tags we planned to use
>> 
>>> waste_basket:defects=loose
>> 
>> That seems rather transient (or should be).
>> 
>>> lcc:comments="under city centre team management"
>> 
>> operator:"Leeds CC city centre team" ?
>> 
>> -- 
>> Andy Mabbett
>> @pigsonthewing
>> http://pigsonthewing.org.uk
>> 
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] FW: Adding Leeds Bins to OpenStreetMaps

[Colin Smale]

ref:lcc=* would probably be best, or even ref:lcc:bins=*. There is an
activity going on at present to get these external IDs documented to
some extent, in the context of IDs that are used for correlation during
data imports and subsequent maintenance. It would fit nicely in this
list: 

https://wiki.openstreetmap.org/wiki/Category:Key_descriptions_with_status_%22import%22

Discussion can be read here: 

https://lists.openstreetmap.org/pipermail/talk/2020-March/084404.html 

On 2020-03-26 11:48, Patrick Lake wrote:

> Thanks for the suggestion Peter, I think ref is probably more appropriate 
> then. I'm fairly new to this as well, so I'm trying to get as much feedback 
> as possible. 
> 
> Patrick 
> 
> From: Peter Neale 
> Reply to: Peter Neale 
> Date: Thursday, 26 March 2020 at 10:40
> To: Jez Nicholson , "talk-gb@openstreetmap.org" 
> , Patrick Lake 
> Subject: Re: [Talk-GB] Adding Leeds Bins to OpenStreetMaps 
> 
> I commend your efforts, but can I suggest a small change to your proposal? 
> 
> (I am still a bit of a novice on OSM, so please feel free to tell me I am 
> totally wrong) 
> 
> Rather than "lcc:id=1849" should you not use, "id=lcc1849", or perhaps 
> "ref=lcc1849", or even "ref:lcc=1849". 
> 
> I am not sure which (if any) would be most correct, but I feel that what you 
> are trying to record is a type of reference or identity, not a type of lcc. 
> 
> I also note that Taginfo shows 91,800 uses of "id=*", but over 10.3 million 
> uses of "ref=*", so "ref =nnn"would seem by far the most popular tag for a 
> reference number.  
> 
> Also, I do not see the need to "hide" the comment as "lcc:comments="; why not 
> just use "note=under city centre team management"? 
> 
> As I said, please feel free to tell me I am wrong; I am engaging here as part 
> of my education in OSM. 
> 
> Regards, 
> 
> Peter 
> 
> On Thursday, 26 March 2020, 10:12:56 GMT, Patrick Lake 
>  wrote: 
> 
> Hi Jez, 
> 
> I agree, we are going to encourage them to rely on OSM as their main source 
> of data in the future, but whether they'll use it for essential stuff like 
> planning collection routes I don't know. We (ODI Leeds), however, will be 
> relying on OSM data, as this is all part of a wider project we're doing for 
> LCC involving analysis on how much waste is collected from these bins and 
> where the optimum location for additional litter bins and recycling points 
> would be. So we're keen for it to be accurate. 
> 
> I thought of just tagging the LCC ID as lcc:id as I assume it will be 
> meaningless to anyone not from the council. Here's the rest of the tags we 
> planned to use with examples from the data we're importing (obviously we can 
> change these): 
> 
> amenity=waste_basket 
> 
> * waste_basket:model="metal square twin"
> * condition=good/fair/poor
> * waste_basket:defects=loose
> * waste_basket:collection_days=mon/fri (or lcc:collection_days ?)
> * lcc:id=1849
> * lcc:comments="under city centre team management"
> 
> What do you think? 
> 
> Cheers, 
> 
> Patrick 
> 
> o/talk-gb [1] 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
 

Links:
--
[1] https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Anyone in South-West London?

[Colin Smale]

On 2020-03-20 19:36, Andrew Hain wrote:

> Also changing the name tag for Eel Pie Island.

Yeah, that was the first thing I noticed. I changed that one back, and
left comments on a couple of other changes, but when I saw the rest I
gave up.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] Anyone in South-West London?

[Colin Smale]

If there is anyone who keeps a weather eye on South-West London, in
particular the Twickenham area, would they like to cast their eye over
the changesets of a brand-new user "tommyf5"? He has been busy today
making many changes that I would class as "fiddling" and don't look
right, but a local eye would be beneficial. Examples are demoting St
Margarets from suburb to neighbourhood, and renaming ways adjacent to a
junction as "Whitton Road Intersection". 

https://www.openstreetmap.org/user/Tommyf5 

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

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Colin Smale]

"unmaintained"? 

On 17 March 2020 10:52:39 CET, Warin <61sundow...@gmail.com> wrote:
>On 17/3/20 8:22 pm, Marc M. wrote:
>> Hello Joseph,
>>
>> it may give the impression that this is the way it should be done.
>> I agree to identify these "Noise" or poor quality tags, but with a
>> keyword to show that it's a problem. e.g. status=bad, disputed,
>error, ...
>> it would be necessary to find a word that is not as strong as error,
>> but which nevertheless clearly indicates that this is not an example
>to
>> follow.
>>
>
>Agree with both.
>
>Possible values?
>
>obsolete
>
>abandoned
>
>discarded
>
>
>
>archaic
>
>passe
>
>stale
>
>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] European Water Project - Introduction

[Colin Smale]

Daniel, that is completely uncalled for. If you can't live and let live,
take your own advice and go procreate somewhere else. 

On 2020-03-13 12:27, Daniel Holsey wrote:

> Fuck Off 
> 
> On Fri, 13 Mar 2020 at 10:31, European Water Project 
>  wrote: 
> 
> Hello, 
> 
> My name is Stuart Rapoport. This my first message on the UK OSM forum, so I 
> decided to give an introduction to our project before jumping into the thread 
> regarding the tag drinking_water:refill = yes.  
> 
> A small group of us have recently started a project called European Water 
> Project. Our project is 100% collaborative and 100% open data, powered by OSM 
> and wikidata. Our goal is to help empower individuals to reduce single use 
> waste in their lives. With the help of many (including OSM members in Italy, 
> Switzerland, France, and Spain), we have written a set of instructions 
> available in 7 languages for adding new water fountains to OSM and as well as 
> instructions on how to add photos to Wikimedia Commons and link them back :  
> https://meta.wikimedia.org/wiki/Wikimedia_CH/Project/European_Water_Project 
> 
> We have developed a Progressive Web Application which allows individuals to 
> find nearby locations where they can refill their sustainable water bottle 
> for free anywhere in Europe.
> We strive to contribute to the builiding of a collaborative network of 
> foutains, cafes, restaurants and other establishments which are willing to 
> allow individuals to fill up their water bottle as part of the battle agains 
> single-use waste.  There are currently over 235,000 fountains and 70 cafés 
> available on the App. 
> 
> Our web App is available directly at https://europeanwaterproject.org  
> (installation instructions are in the hamburger menu).  
> 
> A description of the project and the project genesis : 
> https://drive.google.com/open?id=1f0dts-RErPepgrEnddSAOh1rDqpxMYC3 
> 
> Best regards,
> 
> Stuart Rapoport
 ___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb 
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-14 10:18, Martin Koppenhoefer wrote:

> Am Do., 13. Feb. 2020 um 08:41 Uhr schrieb Colin Smale 
> : 
> Locations are stored in OSM as pairs of {lat,lon} and I assume these are both 
> 64-bit floats in the database. 
> 
> AFAIK they are stored as integers (shifting the decimals)
> 
> If so then then my comments about preserving precision still apply to all 
> "client" software and I bet the majority uses float. Then an innocent update 
> to a tag on a node can end up unintentionally moving the location slightly, 
> losing precision.

My comment about precision lost through conversion was not about missing
floating point digits, but about conversions from one CRS to another,
where you may need additional (proprietary) grid parameters to do a high
precision conversion. 

Yes I realise that but attention must be paid to all possible sources of
precision leakage. 

What use would proprietary parameters be? If they were used, are
relevant and kept private, this would impede the consumption of the data
by any clients. All GIS files must include, by value or by reference,
the relevant CRS, otherwise the contents can not be interpreted
properly, can they? Or are you thinking of the situation in China where
they have a state-controlled/licenced transformation?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-13 00:15, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> Il giorno 13 feb 2020, alle ore 00:05, Colin Smale  
>> ha scritto:
>> 
>> Locations are stored in OSM as pairs of {lat,lon} and I assume these are 
>> both 64-bit floats in the database.
> 
> AFAIK they are stored as integers (shifting the decimals)

If so then then my comments about preserving precision still apply to
all "client" software and I bet the majority uses float. Then an
innocent update to a tag on a node can end up unintentionally moving the
location slightly, losing precision.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-12 23:34, Martin Koppenhoefer wrote:

> sent from a phone
> 
> Il giorno 12 feb 2020, alle ore 14:06, Colin Smale  ha 
> scritto:
> 
> Exactly this. A hobbyist or volunteer CAN verify an admin boundary (where it 
> is available as open data) - it is independently verifiable. It is 
> objectively of better quality than an OTG observation with a phone.
> 
> this will obviously depend on the individual case, but in some instances in 
> Europe I have seen the published open data boundaries were simplified 
> geometries. Just because the original datum was precisely acquired doesn't 
> necessarily imply that the published open data (often derivative data) is 
> super accurate as well (our own errors in the transformation of the data 
> during the import aside).

Good point about the simplification. If they do that by Douglas Peuker
then no points will be moved, but some points can be deleted. So any
points that make it through to the simplified data are accurate and
actually appear in the input. If the boundary, road or whatever is
actually curved, then we can subjectively improve on the published data
by inserting additional points, but we should use the accurate points as
a frame of reference and *leave them alone*. They are most likely to be
the very best data we can get our hands on, even if they are not 100%. 

Concerning data quality and its definition: 
Locations are stored in OSM as pairs of {lat,lon} and I assume these are
both 64-bit floats in the database. Any processing that we do on any
location should be done so as to minimise the error, so the
transformation parameters should be as accurate as possible and all
operations should be done at maximum precision - 64-bit floats ("double
precision" for the old guard) or, even better, 128-bit. When processing
this kind of data you need to be aware of these things, and principles
like these should also be considered "best practices". Results from
higher-precision inputs using higher-precision operations can be
considered to be *of a higher quality* than when a lower precision is
used. And when we "export" the data by translating the binary
representation to text (including XML), that should also be at a
sufficiently high precision, such that re-importing the data would lead
to the same binary representation. Every time data is loaded into an
editor, it is translated to a string, and when it is stored, it
translated back. This process must not lead to a loss of data precision!___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-12 10:42, Frederik Ramm wrote:

> Hi,
> 
> On 2020-02-12 10:28, Colin Smale wrote: 
> 
>> Where a boundary coincides with the centre line of
>> a road for example, and there is a discrepancy in OSM between the
>> locations of the two, there should be a recognition that the
>> professionally surveyed locations are more likely to be correct
> 
> I disagree.
> 
> What you are requesting here is that we blindly defer to authorities. "I
> cannot verify this - but a professional surveyor with his $10k equipment
> claims it is so - hence I guess I have to believe it."

Indeed, that is exactly what I am suggesting (without the "blindly"
bit). You can verify it, just not there and then with your cheap GPS.
OSM is built on trust, not mistrust. 

> I think this is not how OpenStreetMap should be operating. I can see how
> to a professional surveyor the idea must be painful that someone comes
> along with their rubbish equipment and makes a change, but we *are* a
> project of hobbyists and volunteers, and something that a hobbyist and
> volunteer cannot verify ("don't touch this unless you invest $10k in
> equipment first!!!") should not be in OSM, and we should not worship
> precision that we cannot create ourselves.

Exactly this. A hobbyist or volunteer CAN verify an admin boundary
(where it is available as open data) - it is independently verifiable.
It is objectively of better quality than an OTG observation with a
phone. 

The professional surveyor probably couldn't care less. I am thinking of
our downstream consumers.  Sounds a bit like Brexit... 

But some awareness amongst these hobbyists that some sources are better
than others, and their own measurements, even if they are more recent
than the contents of OSM, are not necessarily better, would surely not
be a bad thing.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-12 09:28, Martin Koppenhoefer wrote:

> I believe it is a misconception to think it must be "visible" on the ground, 
> rather it must be determinable on the ground / "in loco". There might well be 
> nothing to "see", but you could still check on the ground, by talking to the 
> local people, how to map something (particularly, how to call it). 
> 
>> Start with "If A, then B" where A is "it is on the ground" and B is "you may 
>> map it."  Now, try the contrapositive "If not B, then not A" (in logic 
>> notation:  ¬B -> ¬A).
> 
> this is not how complex situations work. "If its black it is not colored" 
> does not mean that if its not colored it must be black (could be white, gray, 
> etc.).

 And this is why we should not try to map a continuum of possibilities
onto a binary model. The OTG rule/guideline needs to accommodate these
shades of grey. A rule that leads to so much discussion and so many
exceptions is clearly not a good rule in its current form. Lets do some
process improvement here! 

I want to come back to a point I made a few days ago as well, concerning
location accuracy. If a point (possibly on an admin boundary) is
imported into OSM from a source which has used cm-level surveying
equipment, it is nothing short of WRONG if Joe Bloggs comes along with
his $100 smartphone and moves that point based on a 3-satellite 2D GPS
fix with a 100m GDOP. Where a boundary coincides with the centre line of
a road for example, and there is a discrepancy in OSM between the
locations of the two, there should be a recognition that the
professionally surveyed locations are more likely to be correct - so in
this example the highway should be moved to fit the boundary, and not
the other way around! This professional data provides an extremely
important collection of reference points, to which other data should be
aligned - just like the trig points of older survey systems. OTG IS NOT
ALWAYS BETTER! 

Elevations suffer from the same issues - except that the accuracy from
GPS is even worse. Don't get me started on the differing definitions of
"sea level" leading to meaningless elevations in OSM (because they don't
specify to which datum they are relative).___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-09 04:26, Joseph Eisenberg wrote:

>> Re: "on a government map, by legal / statutory decree, from data 
>> authoritatively published on a website"
> 
> These examples are not "good practice" sources for openstreetmap.
> While many mappers import data from such sources, there is no "value
> added" in the case that mappers are unable to confirm if the
> government or "authoritative" data is accurate or inaccurate. Since
> the data in Openstreetmap can be changed at any time, and often by
> mistakes caused by new mappers, the authoritative database or source
> will always be better for database users to consult directly, unless
> openstreetmap can improve the originally imported data by checking it
> against reality.

I beg to differ. Importing positions of accurately and authoritatively
surveyed objects gives us calibration points for our more manual work.
We are all warned about distortions and offsets in aerial imagery, and
99% of our on-the-ground mappers will be using consumer-grade GPS. If
the location of an admin boundary has been surveyed to centimetre
accuracy as lat X / lon Y, the presence of this in the OSM database,
plus an indication of its authoritative source, gives an invaluable
frame of reference. If Joe Bloggs comes along with his smartphone and
locates it at X+dX,Y+dY he needs to understand that it is he who has the
inferior data, and he should refrain from "improving" OSM by changing
the location of the boundary. If other objects like rivers, highways etc
should probably coincide with the admin boundary but don't, Joe Bloggs
needs to consider that the professionally surveyed data is more likely
to be correct before moving the admin boundary in OSM to fit his
imperfect data. 

Besides, OSM strives not only to be "complete" but also "useful". If
imports can increase the usefulness of OSM, it is likely to positively
impact its adoption. So what's not to like? 

A subject often ignored in OSM is defining what me mean by "data
quality." Quality is always relative to some definition of perfection.
Is a point entered by an "OTG mapper" with a smartphone, of higher
quality than a definitive, authoritative survey? 

> Remember, this is the "good practice" page we are talking about
> editing, not the "how things really are done" page: we want to focuse
> on the "Gold Standard", best practices.

Irrespective of the discussion above, Best Practises and Gold Standards
can often usefully be illustrated by negative examples. Standards have
quality too! A good standard will be unambiguous; one that is vague and
open to a lot of interpretation is not a good standard.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-08 18:03, stevea wrote:

> See, "the on the ground rule," to the best of my ability to determine it (an 
> exception is your opinion as you explicitly express here, and that's part of 
> the problem with it), isn't clearly defined and it needs the elasticity of 
> such ad hoc exceptions.  It doesn't say (explicitly, anywhere, except in your 
> exception) "we ask people there and look at books, other maps, Wikipedia, 
> travel books, organizations...if the name is used in reality."  You do (here, 
> as an "exception," by way of clarifying your understanding of OTG) but if all 
> of that is true, OSM should say so:  formally and as fully as possible.

The most important aspect of the "on the ground" rule is that things are
independently verifiable, i.e. given the evidence, anybody would come to
the same conclusion. Physical evidence is obviously very useful - for
example, either a highway is present, or it is not. But other sources,
provided they are freely accessible, can also provide facts that are
sufficiently verifiable. In the case of the US-CA border, I guess the
treaty or whatever is publicly accessible, so there can be no arguments
about where the border is in a legal sense. Of course not all boundaries
are fully specified in treaties, but I suspect this one is. 

So I suggest the "On The Ground" rule should be replaced by a
requirement for independent verifiability; our traditional definition of
OTG is sufficient but not necessary for compliance. 

Independent viability means (to me) a random member of the public, with
no special privileges, and without payment, and at any time, should be
able to "consult the source".___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Crimea situation - on the ground

[Colin Smale]

On 2020-02-08 11:48, Rory McCann wrote:

> It is true that government A might have one opinion, and government B might 
> have another, and Provisional Autonomous Republic of C might have another 
> opinion.
> 
> But there can be another way. We go there, and we see what nearly everyone 
> there calls it. We look at the words on the signs. We look at the name of the 
> organisations based there ("Transport for London"). We walk down the street 
> and ask 100 people what the name of this city is. We listen into 
> conversations there, and see if there's a majority name that people use when 
> they talk to each other about the city
> 
> And the answer to that is "London".
> 
> In OSM, we could tag that "the opinion of the UK government is that this city 
> is called London", and "the opinion of the French government is that this 
> this city is called Londres", and "the commonly used name for this city by 
> the vast majority of people who live there is London".
> 
> We should map the third option with the `name` tag.

Absolutely. But we should document our sources! Basic rule of research.
And if we choose to promote one alternative above the others, we are
skating on thin ice. Have we actually asked the people of Crimea
first-hand what they think? No=>it's someones opinion. Can we base our
choice on someone else's research? Which research is that? No=>it's
someone's opinion. Unless we can point to it being "in someone else's
opinion", we must take responsibility for our own conclusions. If that's
too hard, better to not have an opinion i.e. don't promote anything as
"more equal than others".___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Crimea situation - on the ground

[Colin Smale]

Many things we think of as "facts" are in fact somewhat subjective.
Things have a name or some attribute "according to" some authority.
London "is not" London, it is "called" London according to local people,
government etc. But the same place is "called" Londres, according to a
different authority, namely French-speakers; both points of view are
equally valid, but only within their intended context. 

In the case of Crimea, two different authorities have different views of
the jurisdiction to which it belongs. That is a fact, that we can safely
map. We can represent the border in one place "according to Russia" and
in another place "according to Ukraine" without taking sides. It is then
down to the renderer/consumer which source is preferred. If we don't
stop taking sides, well, we are taking sides - whatever our arguments to
support our choice. We will never "win" that one. 

I am applying a bit of data management here; every data item should have
a provenance, value domain, validity period etc. The "truth" is always
only relative to a particular frame of reference.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Old maps from Royal Collection UK

[Colin Smale]

On 2020-02-06 21:10, Andy Mabbett wrote:

> The UK's Royal Collection [1 [1]] have placed online [2 [2]] George III's
> collection of military maps which, they say:
> 
> comprises some 3,000 maps, views and prints
> ranging from the disposition of Charles V's armies
> at Vienna in 1532 to the Battle of Waterloo (1815).
> 
> I'm sure these will be of interest to many OSM mappers.
> 
> Remarkably, though, they are claiming copyright over these maps.

As I read it, they are claiming copyright in the images on the website,
which is probably fair enough. I cannot see where they claim copyright
in the maps themselves. But they do have ownership on their side; can
they be forced to make the original maps available for someone else to
photograph/scan? 
  

Links:
--
[1] https://en.wikipedia.org/wiki/Royal_Collection
[2] https://militarymaps.rct.uk/___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] weeklyOSM #497 2020-01-21-2020-01-27

[Colin Smale]

On 2020-02-04 13:36, Frederik Ramm wrote:

> Hi,
> 
> On 04.02.20 13:22, Colin Smale wrote: 
> 
>> Correct me if I am wrong, but I don't remember ever seeing
>> regional full history files.
> 
> The Geofabrik download server has full history files for every region it
> offers. Unlike the non-history extracts. these files are only available
> for users who log in with their OSM user name.

Aah, thanks Frederik, I didn't know about this. But the text on the site
seems to imply that it is only for "internal use" and I cannot use this
data for a public service, e.g. a website to animate changes in admin
boundaries. Can I get round that by cleaning out certain data? 

> that will be millions of API calls to get the full history
> of every node, way and relation involved. If it has to be, then it has
> to be.
> Famous last words before being blocked on the API ;)

At least I would only have to do it once, throttle the rate and leave it
running for a few days, and then keep it updated with the periodical
diffs.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] weeklyOSM #497 2020-01-21-2020-01-27

[Colin Smale]

I wonder how many users actually need a planet-wide planet file. Surely
there are loads of cases where a regional extract would suffice for the
use case in hand. How about encouraging people to consider using a
regional download? 

Something else, only slightly off-topic: I have often had ideas in my
head about looking at the dynamics of particular bits of data - i.e. OSM
histories. Correct me if I am wrong, but I don't remember ever seeing
regional full history files. I think there is a download available for
the entire planet with full history, but that is going to be a monster
and a real challenge to keep up-to-date. But it's the only way to get
historical data, except through the API. If I want to trace for example
the history of changes to county boundaries in the UK, or the alignment
of motorways, that will be millions of API calls to get the full history
of every node, way and relation involved. If it has to be, then it has
to be.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] Old and current GPS tracks

[Colin Smale]

I have also wondered about this. The date the track was recorded may
anonymised/obfuscated for privacy reasons. We always have the date of
upload, which is better than nothing I suppose.

On 2019-12-22 12:03, BD wrote:

> Hi, 
> couple of days ago I had a chance to drive on the new section of A14 (between 
> Brampton and Swavesey junction). I recorder my journey GPS track and now 
> would want to upload it the map. However, I've noticed there are plenty of 
> old traces present and here is my question: 
> 
> Over the last few years since I joined this list there were several 
> discussions about mapping "current" state of affairs. Latest being the 
> disused apartment block. How do we go about GPS traces? 
> 
> https://www.openstreetmap.org/#map=16/52.3103/-0.2416=G 
> 
> The above is no longer fully accurate as the traffic has moved to the new 
> A14. If I add my latest trace this will only add to the confusion as there is 
> no way to separate the GPS info by date (or is there?). Do "we"/OSM manage 
> the GPS data so it can be updated when roads change? 
> 
> Also, looking at the GPS data I found this: 
> https://www.openstreetmap.org/#map=13/52.3929/-0.6807=G 
> surely, this must be a broken trace which brings no value to the project, is 
> there a way to mark/report such errors? 
> 
> Many thanks, 
> dzidek23 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] Metropolitan France : what todo with all "supossed to be wrong" name:xx ?

[Colin Smale via talk]

On 2019-11-19 16:40, Jóhannes Birgir Jensson wrote:

> Not all languages make, or care about making, a distinction of France 
> (including non-Europe) and France (only Europe).

This is not a question of language. They are different concepts, and
irrespective of the language you are speaking, it must be possible to
distinguish between the two. Of course it is possible that you need more
than two words for one or the other, using more descriptive terminology
instead of an accepted Proper Noun. 

If a language doesn't have a term for "Metropolitan France" then there
shouldn't be a name:xx in OSM.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] Tagging Mill Races / Leats / Lades

[Colin Smale]

On 2019-11-14 13:22, Martin Wynne wrote:

> "Canal" should surely be restricted to transport functions? Boating apps 
> presumably treat "canal" as a route unless navigation restrictions are added.

Canal indicates a form of construction - man-made. Unlike natural
watercourses they were constructed because someone had a purpose in
mind, which might have been anything... Transport (using boats/barges),
moving water about, decoration, powering watermills, providing a relief
route to a river, improving the navigability of a river...___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Parish Councils needs

[Colin Smale]

On 2019-10-26 09:58, Edward Bainton wrote:

> (copying the list in again) 
> Thank you. My understanding is that this parish council has had *all* street 
> assets devolved to it: see here [1].

Where do you read that in the attached document? W.r.t. the public
highway as an asset, paragraph 8 basically rules out transfer, as
Wiltshire Council has a statutory role as Highways Authority. This
document relates to a Draft Policy, so it may or not actually happen
(dated Nov 2017). The letter refers to an asset transfer that has
already happened, from Wiltshire to Salisbury City Council, but that was
quite limited in its scope:
https://www.salisburycitycouncil.gov.uk/responsibilities/asset-transfer 

Dangerous paragraph 21 about funding for delegated services: the parish
council gets responsibility, without any additional money. They might be
lucky and get the freehold of a swimming pool (operated by a third
party) for example by way of compensation... 

  

Links:
--
[1]
https://cms.wiltshire.gov.uk/documents/s135418/Service%20Devolution%20and%20Asset%20Transfer%20Cabinet%20Report.pdf___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Reference numbers for UK admin areas?

[Colin Smale]

The London Borough of Sutton has admin_level=8. Admin_level=10 is for civil 
(not ecclesiastical) parishes, or community councils in Wales and Scotland. The 
GSS code refers to the geometry of the area; if the boundary is modified (by 
law) a new code is assigned. 

On 23 October 2019 16:49:07 CEST, Edward Bainton  wrote:
>Hi all
>On the forum marczoutendijk gave me an Overpass query to find grit-bins
>in
>Sutton.
>
>He added an admin-level to distinguish the parish of Sutton from the
>London
>borough.
>
>The only issue is, there are at least three Suttons at admin_level=10
>(as
>it happens, not far from each other).
>
>They have ref numbers thus: ref:gss=E04001120 (for example)
>
>Does anyone know what these are? There is a webpage in the wiki here,
>but I
>can't make sense of it.
>https://wiki.openstreetmap.org/wiki/Item:Q2647
>
>Thanks,
>
>Edward
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Georeferencing / zeroing imagery

[Colin Smale]

On 2019-09-14 17:14, SK53 wrote:

> Hi Edward, 
> 
> In general the GPS rule is still the best way of doing it, we used to have 
> access to Strava heatmap which was very good, but no longer. 
> 
> Other viable alternatives are:  
> 
> * OS OpenData road centrelines. Of course if you use a crude OSGB->WGS84 
> based on OSGB36 this may be upto 5 m out anyway (maximum error of the 
> straight conversion). 
> * Open Data sets which have probably been very accurately located (Nottingham 
> Streetlights, trees in Bristol, Birmingham etc). I presume councils use some 
> kind of differential GPS to locate assets.
> * OS StreetView layer was rectified by Grant using OSGB-02 and is good to 
> crosscheck across layers for shifts.
> * Lidar data from Enivornment Agency/SEPA etc doesn't suffer from parallax 
> errors and can be useful for identifying shifts also.

Admin boundaries imported from OS Boundary-Line should also be accurate,
provided they haven't been moved or otherwise "improved" during / after
the initial import. If the ways are source=OS_OpenData_Boundary-Line and
the nodes are still at version 1, I would think they should be reliable.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Boundary_line at the coast

[Colin Smale]

On 2019-09-08 00:09, Colin Smale wrote:

> On 2019-09-07 23:06, Edward Bainton wrote: 
> 
> 3. Also, there are two walls visible on aerial imagery that all but match the 
> doglegged county boundary as it crosses the isthmus. Is it safe to assume 
> that these mark the actual boundary, and can I tug the boundary to match 
> them? Or maybe assume the boundary is definitive, and the imagery is 
> misaligned, so I should move the walls? Or leave well alone?

>> West side: https://osm.org/go/e7tUHqdxn?m==669235281 
>> East side: https://osm.org/go/e7tUHrpqY?m==669235281

Looking a bit closer, the boundary that "almost" aligns with these walls
is an admin_level=10 boundary, which is not based on OS Open Data. I
have no idea where it came from. This admin level is used in Scotland
for Community Councils, and there is indeed one called Northmavine in
this location. The boundary across the isthmus appears to be a straight
line, without the wiggle we can see in OSM. I will see if I can import
the official boundary soon. 

Bottom line: probably best to leave the walls alone as it looks like
they are not intended to align with the community council boundary.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Boundary_line at the coast

[Colin Smale]

On 2019-09-07 23:06, Edward Bainton wrote:

> I'm interested in boundaries marked at Mavis Grind [1] (thanks to SK53 for 
> the waterway=portage [2] tag - Mavis Grind is an old Norse portage, still in 
> use by Shetland Canoe Club). 
> 
> 1. Does anyone know if county boundary lines at the coast are set at mean low 
> water? There's a gap between coastline (which I understand is MHW) and the 
> county boundary: https://osm.org/go/e7tUHoc5F--?m==669235281

Indeed, GB administrative boundaries are set to MLW(S) and the coastline
is defined in OSM as MHW(S). So normally the coastline should be
"inland" relative to the admin boundary, although in areas with steep
cliffs, harbour walls etc they are shown as coincident. 

> 2. "coastline" is very coarse - is it ok to make it follow the coast more 
> finely, or is it some important legal line where it stands? (I've already 
> done this on the east side of the portage, but then thought perhaps that was 
> a no-no: https://osm.org/go/e7tUNAM7G?layers=D==669235281)

The coastline is in most cases (source=PGS) derived from very old aerial
imagery. A better source is OS Open Data but it is a lot of workI
have done bits and pieces around Scotland, but not this bit of Shetland
yet. The actual physical coastline doesn't have any particular
administrative significance, AFAIK. 

> 3. Also, there are two walls visible on aerial imagery that all but match the 
> doglegged county boundary as it crosses the isthmus. Is it safe to assume 
> that these mark the actual boundary, and can I tug the boundary to match 
> them? Or maybe assume the boundary is definitive, and the imagery is 
> misaligned, so I should move the walls? Or leave well alone? 
> West side: https://osm.org/go/e7tUHqdxn?m==669235281 
> East side: https://osm.org/go/e7tUHrpqY?m==669235281

Note that the OS data was mostly surveyed using high-precision GPS
equipment (±1cm or so); its lat/lon positioning is going to be far more
accurate than what we can get from either aerial imagery (±5m
sometimes?) or consumer GPS (can be ±10m or more). So I tend to accept
that Boundary-Line is pretty much correct, and sometimes things have to
move to fit that. In this case, if it can be established that the walls
are supposed to on the boundary, then I would consider moving the walls
to fit the boundary, and not the other way round. 

Having said that, when it comes to high water / low water marks, I
believe OS re-survey the coast every few years, and make a lot of use of
aerial imagery for this. Don't forget when looking at Bing etc that you
don't know what the state of the tide was at that time, and with a
shallow slope or sandbank it might be difficult to say with any
certainty where the water stops as even sea water is fairly transparent
through short distances. 
  

Links:
--
[1] https://osm.org/go/e7tUHqY_g-
[2] https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dportage___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] National Trust Paths organised edit page

[Colin Smale]

On 2019-09-02 16:40, Mark Goodge wrote:

> One of the issues with relying on sat-nav is that the device data often isn't 
> updated very often. Unless the government can impose some kind of legally 
> binding SLA on the device manufacturers to ensure that all data updates are 
> performed within a specified period of time, then you can't rely on people 
> having current information. If a road is closed, then people need to know 
> it's closed from the moment it's closed - waiting for their navigation 
> software to update isn't good enough!

For HGVs there is another issue in play. Specialised devices using
specialised maps are required, to give routing appropriate to the
vehicle, its mass, length, height, width etc. These devices can be a lot
more expensive, and harder to find, than consumer devices which are only
suitable for cars, motorcycles, cycles etc. If a truck driver is
allowing himself to be directed by Google Maps on his phone for example,
it will end in tears... 

Now, if THIS device sends a truck along an unsuitable road, there is a
real problem to be fixed: 
https://www.tomtom.com/en_gb/sat-nav/truck-sat-nav/___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] OSNI Open Data

[Colin Smale]

That sounds like great news, Owen. Thanks for your help!

Colin 

On 2019-08-21 15:10, Owen Boswarva wrote:

> OSNI have said in a Twitter discussion today that they will remove the link 
> to the LPS licence, to make it clear that normal OGL terms apply to this 
> data: 
> 
> https://twitter.com/owenboswarva/status/1164159795622043648 
> 
> If you source the NI administrative boundaries from the Open Data NI site 
> (instead of the OSNI site) it already says the plain OGL applies, e.g. 
> https://www.opendatani.gov.uk/dataset/osni-open-data-largescale-boundaries-county-boundaries1
>  
> 
> Owen 
> 
> On Tue, 20 Aug 2019 at 21:16, SK53  wrote: 
> 
> This query would actually be better directed at talk-ie as the Irish OSM 
> local chapter have been having discussions with OSNI (and OSI). 
> 
> However, I think it's safe to say that the relevant licence is not (yet) 
> compatible with OSM: I did briefly discuss this point with one of the Open 
> Data NI people who organised OpenData Camp #5 in Belfast, and she was 
> certainly of the view that OSNI data (or any LPS data) was not very open. 
> Many of these datasets would be very useful, for instance there is a point 
> data set of streetnames (e.g., when the name of this bit [1] of street was 
> being questioned, or just to do streetnames which are perhaps 10% completed). 
> 
> It is for this reason why there are no local authority boundaries in NI. 
> However, at some point I used FHRS data to produce concave hulls which would 
> be a first approximation (and no worse than things like the Limerick boundary 
> 3-4 years ago). Also KDDA has some open data for the old Fermanagh district  
> (on umap here [2]) which may assist in working out the boundaries (as will 
> townland and other boundaries). But do check with talk-ie before leaping in. 
> 
> At one point maps.openstreetmap.ie [3] had a number of overlay layers sourced 
> from the OSI/OSNI data, but I think these never got restored after the server 
> move. I used OSNI townland boundaries to compare with OSM ones back in 2015. 
> 
> Jerry 
> 
> On Tue, 20 Aug 2019 at 18:42, Colin Smale  wrote: 
> 
> Has anyone investigated if the data covering Northern Ireland which OSNI make 
> available under OGL V3, is licence-compatible with OSM in the same way as the 
> OSGB open data? I am particularly interested in admin boundaries, e.g. 
> http://osni-spatial-ni.opendata.arcgis.com/datasets/a55726475f1b460c927d1816ffde6c72_2
>  
> 
> The website says: "Open Government Data Licence applies.Land & Property 
> Services (LPS) has made a number of Ordnance Survey of Northern Ireland(R) 
> (OSNI(R)) branded datasets available free of charge under the terms of the 
> current Open Government Licence (OGL). These datasets - which include raster 
> and vector mapping, boundary, gazetteer, height, street and townland products 
> - are available for download.  Each dataset is clearly marked with the OGL 
> symbol. The OGL allows you to: copy, distribute and transmit the data; adapt 
> the data; and exploit the data commercially, whether by sub-licensing it, 
> combining it with other data, or including it in your own product or 
> application. You are therefore able to use the LPS datasets in any way and 
> for any purpose. We simply ask that you acknowledge the copyright and the 
> source of the data by including the following attribution statement: Contains 
> LPS Intellectual Property (c) Crown copyright and database right (year)  This 
> information is
licensed under the terms of the Open Government Licence 
(http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3). You 
must also: include the same acknowledgement requirement in any sub-licences of 
the data that you grant, and a requirement that any further sub-licences do the 
same; ensure that you do not use the data in a way that suggests LPS endorses 
you or your use of the data; and make sure you do not misrepresent the data or 
its source. N.B. Any dataset that does not expressly state that it has been 
released under OGL will require a licence from LPS and the appropriate licence 
fee will be applied." 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
 

Links:
--
[1] https://www.openstreetmap.org/way/392283077
[2]
https://umap.openstreetmap.fr/en/map/fermanagh-road-signs_290510#9/54.3614/-7.5142
[3] http://maps.openstreetmap.ie___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] OSNI Open Data

[Colin Smale]

Thanks Jerry, I had forgotten that NI comes under Ireland ;-) 

I will have a browse through the talk-ie archives and see if I can pick
it up there. 

Colin

On 2019-08-20 22:15, SK53 wrote:

> This query would actually be better directed at talk-ie as the Irish OSM 
> local chapter have been having discussions with OSNI (and OSI). 
> 
> However, I think it's safe to say that the relevant licence is not (yet) 
> compatible with OSM: I did briefly discuss this point with one of the Open 
> Data NI people who organised OpenData Camp #5 in Belfast, and she was 
> certainly of the view that OSNI data (or any LPS data) was not very open. 
> Many of these datasets would be very useful, for instance there is a point 
> data set of streetnames (e.g., when the name of this bit [1] of street was 
> being questioned, or just to do streetnames which are perhaps 10% completed). 
> 
> It is for this reason why there are no local authority boundaries in NI. 
> However, at some point I used FHRS data to produce concave hulls which would 
> be a first approximation (and no worse than things like the Limerick boundary 
> 3-4 years ago). Also KDDA has some open data for the old Fermanagh district  
> (on umap here [2]) which may assist in working out the boundaries (as will 
> townland and other boundaries). But do check with talk-ie before leaping in. 
> 
> At one point maps.openstreetmap.ie [3] had a number of overlay layers sourced 
> from the OSI/OSNI data, but I think these never got restored after the server 
> move. I used OSNI townland boundaries to compare with OSM ones back in 2015. 
> 
> Jerry 
> 
> On Tue, 20 Aug 2019 at 18:42, Colin Smale  wrote: 
> 
>> Has anyone investigated if the data covering Northern Ireland which OSNI 
>> make available under OGL V3, is licence-compatible with OSM in the same way 
>> as the OSGB open data? I am particularly interested in admin boundaries, 
>> e.g. 
>> http://osni-spatial-ni.opendata.arcgis.com/datasets/a55726475f1b460c927d1816ffde6c72_2
>>  
>> 
>> The website says: "Open Government Data Licence applies.Land & Property 
>> Services (LPS) has made a number of Ordnance Survey of Northern Ireland(R) 
>> (OSNI(R)) branded datasets available free of charge under the terms of the 
>> current Open Government Licence (OGL). These datasets - which include raster 
>> and vector mapping, boundary, gazetteer, height, street and townland 
>> products - are available for download.  Each dataset is clearly marked with 
>> the OGL symbol. The OGL allows you to: copy, distribute and transmit the 
>> data; adapt the data; and exploit the data commercially, whether by 
>> sub-licensing it, combining it with other data, or including it in your own 
>> product or application. You are therefore able to use the LPS datasets in 
>> any way and for any purpose. We simply ask that you acknowledge the 
>> copyright and the source of the data by including the following attribution 
>> statement: Contains LPS Intellectual Property (c) Crown copyright and 
>> database right (year)  This information is
licensed under the terms of the Open Government Licence 
(http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3). You 
must also: include the same acknowledgement requirement in any sub-licences of 
the data that you grant, and a requirement that any further sub-licences do the 
same; ensure that you do not use the data in a way that suggests LPS endorses 
you or your use of the data; and make sure you do not misrepresent the data or 
its source. N.B. Any dataset that does not expressly state that it has been 
released under OGL will require a licence from LPS and the appropriate licence 
fee will be applied." 
>> 
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
 

Links:
--
[1] https://www.openstreetmap.org/way/392283077
[2]
https://umap.openstreetmap.fr/en/map/fermanagh-road-signs_290510#9/54.3614/-7.5142
[3] http://maps.openstreetmap.ie___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] OSNI Open Data

[Colin Smale]

Has anyone investigated if the data covering Northern Ireland which OSNI
make available under OGL V3, is licence-compatible with OSM in the same
way as the OSGB open data? I am particularly interested in admin
boundaries, e.g.
http://osni-spatial-ni.opendata.arcgis.com/datasets/a55726475f1b460c927d1816ffde6c72_2


The website says: "Open Government Data Licence applies.Land &
Property Services (LPS) has made a number of Ordnance Survey of Northern
Ireland(R) (OSNI(R)) branded datasets available free of charge under the
terms of the current Open Government Licence (OGL). These datasets -
which include raster and vector mapping, boundary, gazetteer, height,
street and townland products - are available for download.  Each dataset
is clearly marked with the OGL symbol. The OGL allows you to: copy,
distribute and transmit the data; adapt the data; and exploit the data
commercially, whether by sub-licensing it, combining it with other data,
or including it in your own product or application. You are therefore
able to use the LPS datasets in any way and for any purpose. We simply
ask that you acknowledge the copyright and the source of the data by
including the following attribution statement: Contains LPS Intellectual
Property (c) Crown copyright and database right (year)  This information
is licensed under the terms of the Open Government Licence
(http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3).
You must also: include the same acknowledgement requirement in any
sub-licences of the data that you grant, and a requirement that any
further sub-licences do the same; ensure that you do not use the data in
a way that suggests LPS endorses you or your use of the data; and make
sure you do not misrepresent the data or its source. N.B. Any dataset
that does not expressly state that it has been released under OGL will
require a licence from LPS and the appropriate licence fee will be
applied."___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Gates open/closed by default

[Colin Smale]

On 2019-07-26 15:47, Andy Townsend wrote:

> On 26/07/2019 13:28, David Woolley wrote: On 26/07/2019 12:57, Stephen 
> Colebourne wrote: unless there is an explicit "private" sign 
> There is no legal need for "private" signs.  The default assumption should be 
> that everything is private

... in England and Wales. 

...unless it's "Access Land". 

https://www.gov.uk/right-of-way-open-access-land/use-your-right-to-roam___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Gates open/closed by default

[Colin Smale]

I guess what we are trying to get out of this, is: 

a) as a router, can i feel free to route "Joe Public" through here? 

b) as a router, how much time penalty should i factor in for passing
this gate? 

Anything else?

On 2019-07-26 12:58, Warin wrote:

> To bring a little international perspective to this.
> 
> In outback Australia the convention is "leave the gate as you found it". 
> Unfortunately there are some who don't.
> To cope with this problem some gates are hung so that they close under 
> gravity. 
> To keep these open the farmer locks the gate open. Few people stop and try to 
> close the gate, and are defeated by the lock anyway. 
> 
> So indicating that a gate is locked .. says little as to if it is open or 
> closed to me. 
> 
> I think the 2 conditions need to be separated and not assumed;
> 
> locked = yes/no
> 
> closed = yes/no 
> Not certain how to handle automatic - I think they are mostly automatically 
> closing only, some do both closing and opening and there is the possibility 
> of automatically opening only. Err some may have automatic lock features 
> too... 
> 
> In addition some gates are fastened, but can be manually opened if you figure 
> out the mechanism (some are quite inventive!). A problem I have found is on 
> re-fastening these inventive mechanisms .. can take some time to remember it 
> or reinvent it. Perhaps these should be called 'locked' and the above 
> 'key_locked'??? 
> 
> On 26/07/19 20:26, Gareth L wrote: 
> 
>> This was discussed on the wiki 
>> https://wiki.openstreetmap.org/wiki/Talk:Tag:barrier%3Dgate [1] with the 
>> suggestion of using a status tag. And was also discussed (9 years ago?!) 
>> https://lists.openstreetmap.org/pipermail/talk-gb/2010-May/thread.html [2] 
>> 
>> Tagging things as access=private does impact routing a lot, so I'd evaluate 
>> that use carefully. 
>> 
>> Gareth 
>> 
>> -
>> 
>> FROM: Andy Robinson 
>> SENT: Friday, July 26, 2019 10:55:37 AM
>> TO: 'Stephen Colebourne' ; 'talk-gb OSM List' 
>> 
>> SUBJECT: Re: [Talk-GB] Gates open/closed by default 
>> 
>> If a gate opens automatically I would say it's an access=yes regardless of 
>> how the way is tagged.
>> 
>> Cheers
>> Andy
>> 
>> -Original Message-
>> From: Stephen Colebourne [mailto:scolebou...@joda.org] 
>> Sent: 26 July 2019 10:47
>> To: talk-gb OSM List
>> Subject: [Talk-GB] Gates open/closed by default
>> 
>> I'd like to distinguish between two kinds of gate on private roads:
>> 
>> - those where the gate is closed by default (eg automatic closing)
>> - those where the gate is open by default (the gate exists, but is
>> rarely if ever closed)
>> 
>> Currently I'm marking both as barrier=gate & access=private, but I
>> can't see an obvoius way to mark the open/closed by default aspect.
>> One thought was to use access=permissive on those that are open (with
>> the highway still access=private).
>> 
>> Any suggestions?
>> 
>> Stephen
>> PS, I do want to mark the gate on the map even if it is always open
>> 
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>> 
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb 
>> 
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
 

Links:
--
[1] https://wiki.openstreetmap.org/wiki/Talk:Tag:barrier%3Dgate
[2]
https://lists.openstreetmap.org/pipermail/talk-gb/2010-May/thread.html___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Gates open/closed by default

[Colin Smale]

On 2019-07-26 12:26, Gareth L wrote:

> This was discussed on the wiki 
> https://wiki.openstreetmap.org/wiki/Talk:Tag:barrier%3Dgate [1] with the 
> suggestion of using a status tag. And was also discussed (9 years ago?!) 
> https://lists.openstreetmap.org/pipermail/talk-gb/2010-May/thread.html [2] 
> 
> Tagging things as access=private does impact routing a lot, so I'd evaluate 
> that use carefully.

Access=* denotes the legal position, not the presence or absence of
physical obstacles. Access=permissive is just as wrong as access=private
as a proxy for gate=normally_open etc. Don't tag incorrectly for the
renderer (or router!) 

The state of openness can vary more widely: when it is shut, it may or
may not be locked (perhaps you can open it yourself if required) and may
consist of multiple gates with different rules - like one half open to
allow you to leave the premises, but the other half shut; or the big
gate shut to keep vehicles, and a small gate open for pedestrians. In
these cases mapping a single gate is not going to allow the fine-grained
information to be added easily. 

  

Links:
--
[1] https://wiki.openstreetmap.org/wiki/Talk:Tag:barrier%3Dgate
[2]
https://lists.openstreetmap.org/pipermail/talk-gb/2010-May/thread.html___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb