[Talk-GB] Multiple coincident boundary nodes. Data quality issue ?

[Mike Parfitt]

If I put Drimnin in the centre of my tablet's screen in an area of 780m EW and 
515m NS (landscape) the land/sea boundary is marked (not always accurately) by 
a number of coincident way/relation/multipolygon items all of which pass 
through 49 things that look like nodes.

There are actually 71 individual nodes (see caveat) of which :-
27 nodes are on all of the way/relation/multipolygon items
44 nodes are arranged in 22 coincident pairs, each on a subset of the 
way/relation/multipolygon items

At least one of the nodes in each coincident pair has a tag, but the 27 nodes 
that are on all of the way/relation/multipolygon items do not have any tags.

CAVEAT : I haven't checked every one of the 49 things that look like nodes, so 
it is possible that some may be composed of more than 2 coincident nodes.  Even 
if they are all just pairs of nodes, I don't know if the same subset of the 
way/relation/multipolygon items occurs throughout.

I am limited to contributing updates via an Android tablet - using Vespucci, as 
iD is unuseable on my touch screen.

I can easily move the 27 nodes that are on all of the way/relation/multipolygon 
items, but for the others, I have to select and move each of the coincident 
nodes individually - to the same location !

My opinion is that  :-

a) boundaries should have their properties defined at the 
way/relation/multipolygon level
b) individual nodes on such boundaries should not have any tags
c) coincident nodes on such boundaries should be combined into one

What does everyone else think ?
How should the right solution be implemented ?
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Multiple coincident boundary nodes. Data quality issue ?

[Mike Parfitt]

Then the authority/accuracy of the souce attributed to some of the ways in that 
area is even worse than I thought.

Where we agree, is that none of the nodes defining these boundaries should be 
INLAND of the spring tide high-water mark.

In summary (except for certain places) the nodes of the administrative/MPA 
boundaries should be coincident and all should be situated at the spring tide 
low-water mark - i.e. all are normally underwater, except for one moment in 
Spring.

If the GB multipolygon should follow the high tide line, then the vast majority 
of the nodes will be situated inshore of those for the administrative/MPA 
boundaries - i.e. all are normally above the water, except for one moment in 
Spring.

So the only coincident nodes across all of the above boundaries will be those 
at vertical, or very steep rock faces.

It looks like the linking of the nodes for the GB multipolygon with those for 
the administrative/MPA boundaries has been done for pragmatic reasons.

From: Colin Smale <colin.sm...@xs4all.nl>
Sent: 21 August 2017 10:19:45
To: talk-gb@openstreetmap.org
Subject: Re: [Talk-GB] Multiple coincident boundary nodes. Data quality issue ?


Admin boundaries (jurisdiction of local authorities) extend to the low water 
mark (MLWS) unless otherwise extended by law (there are a few of these cases: 
Bristol, Torbay, Brighton Marina...). High water and low water may be very 
close where there are steep cliffs, or even coincident where the "wall" is 
vertical.

The "GB multipolygon" is I believe defined as the "coastline" which should be 
following the high water line.

The designation order for the MPA says it covers "any area of seabed or other 
land (whether or not covered by water) seaward of the mean low water spring 
tide within that area". So its boundary it linked to the admin boundary "by 
definition" as they are both linked to the low water line, but NOT linked to 
the "GB multipolygon" by definition as the latter is linked to high water.

--colin

On 2017-08-21 11:06, Mike Parfitt wrote:

Fair point, Fords, Gates, Crossings etc should be tags on way nodes where 
appropriate, but in this case, having an Administrative tag on a subset of the 
nodes defining an Administrative boundary is pointless and bloats the database 
without adding value.

No matter what the authority of the source, errors happen.

In this case, the nodes defining the Highland admin boundary and the GB 
multipolygon exclude small chunks of land.  These chunks of land appear to be 
part of the Marine Protected Area.

Whilst other cases may not be so simple, I think that the high-tide line is 
probably where all three should lie - with the caveat that some blurring will 
occur, depending on the number of nodes used, cloud cover, tile alignment 
errors and eye/judgement/finger problems.

From: Warin <61sundow...@gmail.com>
Sent: 12 August 2017 00:46:03
To: talk-gb@openstreetmap.org
Subject: Re: [Talk-GB] Multiple coincident boundary nodes. Data quality issue ?

Basic agreement with Colin.

The 'problem' is better described as 'data bloat' rather than 'quality' which 
implies inaccuracy.

I add the following observation  
 I am beginning to see that the ways should have a source tag.
This then means that where ways are coincident that the sources can be easily 
compared .. if the ways can be combined into one way then the source is both of 
the previous ways sources unless there is an addition?
The inclusion of the source on the way helps others with a comprehension of the 
accuracy of that way.
It also means that a relation can have ways from several sources and that any 
editing of a way in that relation can easily have that editing source added to 
the relevant way without mucking around with other relevant source tags.



 On 12-Aug-17 07:04 AM, Colin Smale wrote:

Mike,

not sure I would call it a real data quality issue, but it "could be better".

There are two coincident lines, which share some nodes but do not share the 
majority of nodes, despite the fact they are coincident.

One line represents the boundary of Great Britain, and the admin boundary of 
Highland.

The other line is the boundary of "Loch Sunart to the Sound of Jura Marine 
Protected Area"

If the nodes are coincident by design, then they should be shared. If they are 
only coincident by accident, then not. In this case it is likely (but I don't 
know for sure) that the MPA boundary is effectively defined in this area as 
"the boundary of Highland Council" so the nodes could/should be shared.

Nodes contained in a way do not normally have, or need, tags. However, where a 
point feature occurs in the course of a way, then the "by accident/by design" 
distinction applies again. A pedestrian crossing is often a node in a highway: 
this is "by design" becau

Re: [Talk-GB] Multiple coincident boundary nodes. Data quality issue ?

[Mike Parfitt]

How (or who) do we ask for a definition of what the GB Multipolygon is supposed 
to represent within the OpenStreetMap universe ?

From: Stuart Reynolds <stu...@travelinesoutheast.org.uk>
Sent: 23 August 2017 12:05:24
To: Colin Smale
Cc: talk-gb@openstreetmap.org
Subject: Re: [Talk-GB] Multiple coincident boundary nodes. Data quality issue ?

Indeed. I just wanted to ensure that there wasn’t a rush to “define” the GB 
multipolygon strictly according to MHW everywhere.

Cheers
Stuart



On 23 Aug 2017, at 10:56, Colin Smale 
<colin.sm...@xs4all.nl<mailto:colin.sm...@xs4all.nl>> wrote:


Estuaries are a bit of a special case for the coastline. It is quite normal for 
there to be a straight line across the river mouth for some purposes, but this 
does not imply that waters above that line are not tidal of course.

I think what you are querying, is the link/relationship between:

a) the high-water line

b) the coastline

c) the maritime baselines

d) the "GB multipolygon"



There are of course many possible definitions of the boundary of GB. Coastline? 
(Local) government jurisdiction? Territorial waters? EEZ? AFAIK this polygon in 
OSM is based on the coastline, but I might be wrong...

--colin

On 2017-08-23 10:22, Stuart Reynolds wrote:

On 23 Aug 2017, at 09:00, Mike Parfitt 
<m_parf...@hotmail.com<mailto:m_parf...@hotmail.com>> wrote:

If the GB multipolygon should follow the high tide line, then the vast majority 
of the nodes will be situated inshore of those for the administrative/MPA 
boundaries - i.e. all are normally above the water, except for one moment in 
Spring.

The River Thames is tidal as far as Teddington Lock in London. It therefore has 
high and low water marks, and the high water mark is up against the river walls 
in London and, even in Southend where I reside at the other end of the river, 
the mean high tide level is only about 10-20 feet away from the sea wall. Are 
we honestly suggesting that it is correct that the river is not within the GB 
boundary? Or, indeed, Southend Pier. Because that would be the effect of the GB 
boundary religiously following the high water mark!

The usual policy (as per OS) is to draw a north south line across the Thames 
Estuary, which irritates me for other reasons because it is a) artificial and 
b) frequently rendered, but it is better than a blanket assumption that the 
boundary must follow the high water mark.

Regards,
Stuart Reynolds
for traveline south east & anglia



___
Talk-GB mailing list
Talk-GB@openstreetmap.org<mailto:Talk-GB@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org<mailto: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] Multiple coincident boundary nodes. Data quality issue ?

[Mike Parfitt]

Fair point, Fords, Gates, Crossings etc should be tags on way nodes where 
appropriate, but in this case, having an Administrative tag on a subset of the 
nodes defining an Administrative boundary is pointless and bloats the database 
without adding value.

No matter what the authority of the source, errors happen.

In this case, the nodes defining the Highland admin boundary and the GB 
multipolygon exclude small chunks of land.  These chunks of land appear to be 
part of the Marine Protected Area.

Whilst other cases may not be so simple, I think that the high-tide line is 
probably where all three should lie - with the caveat that some blurring will 
occur, depending on the number of nodes used, cloud cover, tile alignment 
errors and eye/judgement/finger problems.

From: Warin <61sundow...@gmail.com>
Sent: 12 August 2017 00:46:03
To: talk-gb@openstreetmap.org
Subject: Re: [Talk-GB] Multiple coincident boundary nodes. Data quality issue ?

Basic agreement with Colin.

The 'problem' is better described as 'data bloat' rather than 'quality' which 
implies inaccuracy.

I add the following observation  
 I am beginning to see that the ways should have a source tag.
This then means that where ways are coincident that the sources can be easily 
compared .. if the ways can be combined into one way then the source is both of 
the previous ways sources unless there is an addition?
The inclusion of the source on the way helps others with a comprehension of the 
accuracy of that way.
It also means that a relation can have ways from several sources and that any 
editing of a way in that relation can easily have that editing source added to 
the relevant way without mucking around with other relevant source tags.



 On 12-Aug-17 07:04 AM, Colin Smale wrote:

Mike,

not sure I would call it a real data quality issue, but it "could be better".

There are two coincident lines, which share some nodes but do not share the 
majority of nodes, despite the fact they are coincident.

One line represents the boundary of Great Britain, and the admin boundary of 
Highland.

The other line is the boundary of "Loch Sunart to the Sound of Jura Marine 
Protected Area"

If the nodes are coincident by design, then they should be shared. If they are 
only coincident by accident, then not. In this case it is likely (but I don't 
know for sure) that the MPA boundary is effectively defined in this area as 
"the boundary of Highland Council" so the nodes could/should be shared.

Nodes contained in a way do not normally have, or need, tags. However, where a 
point feature occurs in the course of a way, then the "by accident/by design" 
distinction applies again. A pedestrian crossing is often a node in a highway: 
this is "by design" because the position of the crossing is irrevocably linked 
to the position of the highway. But sometimes nodes for things like monuments 
could be added without having zoomed in properly, with the editor choosing to 
re-use an existing node instead of creating a new one. So my reaction to your 
statements b and c is "it depends".



//colin

On 2017-08-11 22:07, Mike Parfitt wrote:

If I put Drimnin in the centre of my tablet's screen in an area of 780m EW and 
515m NS (landscape) the land/sea boundary is marked (not always accurately) by 
a number of coincident way/relation/multipolygon items all of which pass 
through 49 things that look like nodes.

There are actually 71 individual nodes (see caveat) of which :-
27 nodes are on all of the way/relation/multipolygon items
44 nodes are arranged in 22 coincident pairs, each on a subset of the 
way/relation/multipolygon items

At least one of the nodes in each coincident pair has a tag, but the 27 nodes 
that are on all of the way/relation/multipolygon items do not have any tags.

CAVEAT : I haven't checked every one of the 49 things that look like nodes, so 
it is possible that some may be composed of more than 2 coincident nodes.  Even 
if they are all just pairs of nodes, I don't know if the same subset of the 
way/relation/multipolygon items occurs throughout.

I am limited to contributing updates via an Android tablet - using Vespucci, as 
iD is unuseable on my touch screen.

I can easily move the 27 nodes that are on all of the way/relation/multipolygon 
items, but for the others, I have to select and move each of the coincident 
nodes individually - to the same location !

My opinion is that  :-

a) boundaries should have their properties defined at the 
way/relation/multipolygon level
b) individual nodes on such boundaries should not have any tags
c) coincident nodes on such boundaries should be combined into one

What does everyone else think ?
How should the right solution be implemented ?
___
Talk-GB mailing list
Talk-GB@openstreetmap.org<mailto:Talk-G

Re: [Talk-GB] Motorway junctions where the slow lane seperates from the through lanes

[Mike Parfitt]

Have a look at www.openstreetmap.org/changeset/79582073

On my Samsung Tablet I have been using Bing satellite images with the Vespucci 
editor, but other images also show the road markings quite clearly.

From: Ed Loach 
Sent: 14 January 2020 13:45:34
To: 'Paul Berry' ; 'Mike Parfitt' 
Cc: talk-gb@openstreetmap.org 
Subject: RE: [Talk-GB] Motorway junctions where the slow lane seperates from 
the through lanes


See also

https://wiki.openstreetmap.org/wiki/Lanes

which has some quite good notes on how to map lanes. I suspect this is how 
OsmAnd knows to give me lane guidance (can’t think how else it could know).



I suspect based on that you’d want to begin your new way for the drop lane 
where the lane splits away from the main carriageway, with an earlier split for 
lanes=3, turn:lanes=slight_left|through|through with lanes=1 on the new way and 
lanes=2 on the main way after the split.



Ed



From: Paul Berry
Sent: 14 January 2020 13:15
To: Mike Parfitt 
Cc: talk-gb@openstreetmap.org
Subject: Re: [Talk-GB] Motorway junctions where the slow lane seperates from 
the through lanes



Hi Mike,



Interesting points and no easy answer I fear.



I think in mapping terms the midlines of each carriageway after the diverge 
will look more like a upside-down Y and I tend to do a bit of smoothing to make 
it look less abrupt. I think this is what you're getting at (apologies if not). 
It's not dissimilar to the situation where a single-carriageway road splits 
around an island: because the way is drawn as a line—not an area—the 
carriageway split is always going to look more dramatic drawn that way compared 
to the smooth continuous reality of what's on the ground.



In the situation of a lane drop don't forget to keep track of the lanes= 
in the keys.



It might be easier if you just go ahead and map as you see fit then post the 
changeset link if you want further commentary.



Regards,

Paul



On Tue, 14 Jan 2020 at 08:26, Mike Parfitt 
mailto:m_parf...@hotmail.com>> wrote:

The technical term is a drop lane.  This might later intersect with a 
roundabout, join with another motorway or primary road etc.  Between junctions, 
a single way for each direction is commonplace.  At junctions, there are ways 
for the through lanes and for traffic exiting and entering the motorway.

For example, on a 3-lane motorway with 3 lanes going in one direction and no 
junction anywhere near, the way would typically be placed along the centre of 
lane 2.

However, when lane 1 is designated as a drop lane, what was being mapped as 1 
way needs to split into 2 ways.

The question is where ?

There are various anticipatory changes in road markings well ahead of the 
physical separation of the asphalt, together with blue and white signs, some of 
which precede the first of the changes in road markings.

In the case described above, my convention is to pick the start of the shorter 
dashes between the drop lane (1) and the through lanes (2 and 3).  From then 
onwards, the way for the through lanes is mapped along the longer dashes 
dividing lanes 2 and 3, while the way for the drop lane is mapped along the 
centre of lane 1.

Others do it differently.

See "https://www.gov.uk/government/publications/traffic-signs-manual; from 
where you can download "Traffic signs manual chapter 5 road markings (2019)" 
which is a PDF.  Page 82 contains figure 7.7 and text documenting drop lane 
road markings.

___
Talk-GB mailing list
Talk-GB@openstreetmap.org<mailto: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] Motorway junctions where the slow lane seperates from the through lanes

[Mike Parfitt]

The technical term is a drop lane.  This might later intersect with a 
roundabout, join with another motorway or primary road etc.  Between junctions, 
a single way for each direction is commonplace.  At junctions, there are ways 
for the through lanes and for traffic exiting and entering the motorway.

For example, on a 3-lane motorway with 3 lanes going in one direction and no 
junction anywhere near, the way would typically be placed along the centre of 
lane 2.

However, when lane 1 is designated as a drop lane, what was being mapped as 1 
way needs to split into 2 ways.

The question is where ?

There are various anticipatory changes in road markings well ahead of the 
physical separation of the asphalt, together with blue and white signs, some of 
which precede the first of the changes in road markings.

In the case described above, my convention is to pick the start of the shorter 
dashes between the drop lane (1) and the through lanes (2 and 3).  From then 
onwards, the way for the through lanes is mapped along the longer dashes 
dividing lanes 2 and 3, while the way for the drop lane is mapped along the 
centre of lane 1.

Others do it differently.

See "https://www.gov.uk/government/publications/traffic-signs-manual; from 
where you can download "Traffic signs manual chapter 5 road markings (2019)" 
which is a PDF.  Page 82 contains figure 7.7 and text documenting drop lane 
road markings.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] underfoot art

[Mike Parfitt]

There may be some merit in tagging permanent artwork on the sides of buildings.

But tagging pavement/street art that will vanish after a couple of showers 
seems pointless.

From: Peter Neale via Talk-GB 
Sent: 26 April 2020 18:38:06
To: mar...@templot.com 
Cc: Talk-gb OSM List 
Subject: Re: [Talk-GB] underfoot art

Pavement art, or perhaps street painting?


Street painting - Wikipedia

Street painting - Wikipedia


Regards,
Peter


Sent from Yahoo Mail on 
Android

On Sun, 26 Apr 2020 at 15:32, Martin Wynne
 wrote:
What is this stuff called?

  https://goo.gl/maps/uVVfLbicFhT25TM5A

  https://goo.gl/maps/5g1yJnsAGEHzpqqY6

I got as far as tourism=artwork but then

  artwork_type= ?

thanks,

Martin.

___
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