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

Colin Smale colin.smale at xs4all.nl
Mon Aug 21 10:19:45 UTC 2017


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 <61sundowner at gmail.com>
> SENT: 12 August 2017 00:46:03
> TO: talk-gb at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb 
> 
> _______________________________________________
> Talk-GB mailing list
> Talk-GB at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

_______________________________________________
Talk-GB mailing list
Talk-GB at openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-gb/attachments/20170821/10bc1d5c/attachment-0001.html>


More information about the Talk-GB mailing list