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