Re: [Talk-GB] Heads up: Please check recent edits by this user...

[Colin Smale]

The inquest can come later. Right now it is about mitigation and
recovery.

On 2018-01-13 18:38, David Woolley wrote:

> Splitting with JOSM shouldn't break the relations.  I think there may have 
> been a technique error here, e.g. some form of delete and re-add.
> 
> On 13/01/18 17:15, Colin Smale wrote: 
> 
>> Things are starting to get messy. The original user has been reverting many 
>> changes (which is good) but some apparently got missed, and another user 
>> (FvGordon) has started patching up the admin boundaries at least. Not sure 
>> what source they use to fill in the gaps in the boundaries though. Also, 
>> other relations may have been affected and they will now be broken unless 
>> FvGordon fixes them all as well.
>> 
>> I spend a lot of time maintaining the admin boundaries and it is very 
>> disheartening to see so much damage and extra work being caused in this way.
> 
> ___
> 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] Heads up: Please check recent edits by this user...

[David Woolley]

Splitting with JOSM shouldn't break the relations.  I think there may 
have been a technique error here, e.g. some form of delete and re-add.


On 13/01/18 17:15, Colin Smale wrote:
Things are starting to get messy. The original user has been reverting 
many changes (which is good) but some apparently got missed, and another 
user (FvGordon) has started patching up the admin boundaries at least. 
Not sure what source they use to fill in the gaps in the boundaries 
though. Also, other relations may have been affected and they will now 
be broken unless FvGordon fixes them all as well.


I spend a lot of time maintaining the admin boundaries and it is very 
disheartening to see so much damage and extra work being caused in this way.





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

Re: [Talk-GB] Heads up: Please check recent edits by this user...

[Colin Smale]

Things are starting to get messy. The original user has been reverting
many changes (which is good) but some apparently got missed, and another
user (FvGordon) has started patching up the admin boundaries at least.
Not sure what source they use to fill in the gaps in the boundaries
though. Also, other relations may have been affected and they will now
be broken unless FvGordon fixes them all as well.

I spend a lot of time maintaining the admin boundaries and it is very
disheartening to see so much damage and extra work being caused in this
way. 

On 2018-01-12 17:08, Colin Smale wrote:

> User hornbydd2 has been making large numbers of edits to waterways in the UK 
> which have created loads of problems in relations, including admin 
> boundaries. 
> 
> I haven't yet heard what the intention of these edits is. It seems to be to 
> split waterways at all junctions with other waterways, e.g. where a stream 
> joins a main flow. In any case the splits are causing the problem: the tags 
> on the way get copied over, but the relation memberships are not. Net result 
> is a whole bunch of broken relations. I think they are considering how to fix 
> up the damage, but I feel a revert may be the path of least resistance... 
> 
> I started a discussion about one changeset, but I now see the issue goes much 
> further, both geographically and in terms of the types of objects which may 
> be impacted: 
> 
> https://www.openstreetmap.org/changeset/55377588# 
> 
> Regards, 
> 
> Colin 
> ___
> 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] Heads up: Please check recent edits by this user...

[Colin Smale]

Routers will all do pre-processing on the network, to a) eliminate edges
(ways) that are irrelevant for routing, b) combine consecutive segments
wherever possible and c) precalculate the cost (usually journey time) of
each edge. 

Dijkstra has been improved upon by e.g. the A* algorithm:
https://en.wikipedia.org/wiki/A*_search_algorithm

If a way NEEDS to be split, because different segments have different
tagging and/or relation memberships, then that's fine because there is
no alternative. But to split ways at every junction under the
misapprehension that this helps a "router" or other data consumer, is
just wrong. 

On 2018-01-13 15:58, David Woolley wrote:

> On 13/01/18 14:42, Dave F wrote: 
> 
>> When a router traversing a way encounters a node it does a check to see if 
>> other ways are connected, If they are, it analyses the tags on those ways & 
>> decides if needs to go down one of them or continue to the next node. 
>> There's no requirement to split.
> 
> Whilst I don't know the specific algorithms used by current routers, the 
> standard algorithms for the shortest path through a network 
>  requires a list of 
> nodes and edges, and creates the full tree of possible routes out from that 
> endpoint, assigning costs to reach each node.
> 
> Whilst it might be possible to deduce edges and assign costs to the edges on 
> the fly, that is likely to result in more processing, and mean one has to 
> customise the standard algorithm.
> 
> On the other hand, one could argue that this is almost a case of tagging for 
> the renderer.  I'd certainly say it was a misuse of the map database.
> 
> (I suspect routers use some heuristics to avoid searching too many edges.)
> 
> ___
> 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] Heads up: Please check recent edits by this user...

[David Woolley]

On 13/01/18 14:42, Dave F wrote:
When a router traversing a way encounters a node it does a check to see 
if other ways are connected, If they are, it analyses the tags on those 
ways & decides if needs to go down one of them or continue to the next 
node. There's no requirement to split.


Whilst I don't know the specific algorithms used by current routers, the 
standard algorithms for the shortest path through a network 
 requires a list 
of nodes and edges, and creates the full tree of possible routes out 
from that endpoint, assigning costs to reach each node.


Whilst it might be possible to deduce edges and assign costs to the 
edges on the fly, that is likely to result in more processing, and mean 
one has to customise the standard algorithm.


On the other hand, one could argue that this is almost a case of tagging 
for the renderer.  I'd certainly say it was a misuse of the map database.


(I suspect routers use some heuristics to avoid searching too many edges.)

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

Re: [Talk-GB] Heads up: Please check recent edits by this user...

[Dave F]

On 12/01/2018 18:07, Frederik Ramm wrote:

This is something that any routing engine for a road network must do


Never quite understood the logic for this splitting.

When a router traversing a way encounters a node it does a check to see 
if other ways are connected, If they are, it analyses the tags on those 
ways & decides if needs to go down one of them or continue to the next 
node. There's no requirement to split.


DaveF

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

Re: [Talk-GB] Heads up: Please check recent edits by this user...

[Frederik Ramm]

Hi,

On 01/12/2018 05:08 PM, Colin Smale wrote:
> I haven't yet heard what the intention of these edits is. It seems to be
> to split waterways at all junctions with other waterways, 

This is something that any routing engine for a road network must do -
and thankfully it is usually done in the prepare-data-for-routing step
and not on OSM! Maybe whatever the use case is here, the user can take a
cue (or even code) from such preprocessing.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Talk-GB] Heads up: Please check recent edits by this user...

[Jez Nicholson]

"Improve river network topology"... That would be for water flow modelling.

On Fri, 12 Jan 2018 16:10 Colin Smale,  wrote:

> User hornbydd2 has been making large numbers of edits to waterways in the
> UK which have created loads of problems in relations, including admin
> boundaries.
>
> I haven't yet heard what the intention of these edits is. It seems to be
> to split waterways at all junctions with other waterways, e.g. where a
> stream joins a main flow. In any case the splits are causing the problem:
> the tags on the way get copied over, but the relation memberships are not.
> Net result is a whole bunch of broken relations. I think they are
> considering how to fix up the damage, but I feel a revert may be the path
> of least resistance...
>
> I started a discussion about one changeset, but I now see the issue goes
> much further, both geographically and in terms of the types of objects
> which may be impacted:
>
> https://www.openstreetmap.org/changeset/55377588#
>
> Regards,
>
> Colin
> ___
> 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] Heads up: Please check recent edits by this user...

[Colin Smale]

User hornbydd2 has been making large numbers of edits to waterways in
the UK which have created loads of problems in relations, including
admin boundaries. 

I haven't yet heard what the intention of these edits is. It seems to be
to split waterways at all junctions with other waterways, e.g. where a
stream joins a main flow. In any case the splits are causing the
problem: the tags on the way get copied over, but the relation
memberships are not. Net result is a whole bunch of broken relations. I
think they are considering how to fix up the damage, but I feel a revert
may be the path of least resistance... 

I started a discussion about one changeset, but I now see the issue goes
much further, both geographically and in terms of the types of objects
which may be impacted: 

https://www.openstreetmap.org/changeset/55377588# 

Regards, 

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