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

Warin 61sundowner at gmail.com
Sat Aug 12 00:46:03 UTC 2017

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 <mailto: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/20170812/37980ea4/attachment.html>

More information about the Talk-GB mailing list