How to solve the problem with relation overload?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

How to solve the problem with relation overload?

Martin Vonwald (Imagic)
Hi!

I'm a little desperate now. The increasing number of relations -
especially those for public transport - make it harder and harder to
make simple edits.

Example: http://www.openstreetmap.org/browse/way/146170815

I avoid to edit the "Süd Autobahn" because I'm aware that it is nearly
impossible to do so because of the relations attached to it. But
sometimes I have to. Right now I downloaded that area, had a look what
to do, updated the data again, split one(!) way and uploaded the data.
The timespan between data update and upload was about ten seconds(!).
Result: nine(!) conflicts.

Are we sure that those relations provide more information than they
prevent to be provided?

regards,
Martin

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

Richard Mann-2
Try using Potlatch


On Fri, Nov 30, 2012 at 9:59 AM, Martin Vonwald <[hidden email]> wrote:
Hi!

I'm a little desperate now. The increasing number of relations -
especially those for public transport - make it harder and harder to
make simple edits.

Example: http://www.openstreetmap.org/browse/way/146170815

I avoid to edit the "Süd Autobahn" because I'm aware that it is nearly
impossible to do so because of the relations attached to it. But
sometimes I have to. Right now I downloaded that area, had a look what
to do, updated the data again, split one(!) way and uploaded the data.
The timespan between data update and upload was about ten seconds(!).
Result: nine(!) conflicts.

Are we sure that those relations provide more information than they
prevent to be provided?

regards,
Martin

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

Pieren
In reply to this post by Martin Vonwald (Imagic)
On Fri, Nov 30, 2012 at 10:59 AM, Martin Vonwald <[hidden email]> wrote:

> Are we sure that those relations provide more information than they
> prevent to be provided?

In the example you are pointing, 6 of the 9 relations are for the Bus
311. I never map public transport relations but I've seen its modeling
expanding very far in complexity in recent time (fault is also because
some routes are complexe anyway). The amount of route relations will
increase in the future, this is unavoidable. I personally don't care
about such relations until they make our normal edits unmanageable.
One solution could be to bring super-relations in general use. Or find
another modeling for routes (e.g. with intersection nodes only).

Pieren

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

Philip Barnes
In reply to this post by Richard Mann-2

Does anyone else find that editing ways with relations slows potlatch to a crawl? I find that there is a long delay when ever I do anything to them?

 

Phil

--

 

Sent from my Nokia N9

 


On 30/11/2012 10:02 Richard Mann wrote:

Try using Potlatch


On Fri, Nov 30, 2012 at 9:59 AM, Martin Vonwald <[hidden email]> wrote:
Hi!

I'm a little desperate now. The increasing number of relations -
especially those for public transport - make it harder and harder to
make simple edits.

Example: http://www.openstreetmap.org/browse/way/146170815

I avoid to edit the "Süd Autobahn" because I'm aware that it is nearly
impossible to do so because of the relations attached to it. But
sometimes I have to. Right now I downloaded that area, had a look what
to do, updated the data again, split one(!) way and uploaded the data.
The timespan between data update and upload was about ten seconds(!).
Result: nine(!) conflicts.

Are we sure that those relations provide more information than they
prevent to be provided?

regards,
Martin

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging



_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

Jo-2
In reply to this post by Pieren
2012/11/30 Pieren <[hidden email]>
On Fri, Nov 30, 2012 at 10:59 AM, Martin Vonwald <[hidden email]> wrote:

> Are we sure that those relations provide more information than they
> prevent to be provided?

In the example you are pointing, 6 of the 9 relations are for the Bus
311. I never map public transport relations but I've seen its modeling
expanding very far in complexity in recent time (fault is also because
some routes are complexe anyway). The amount of route relations will
increase in the future, this is unavoidable. I personally don't care
about such relations until they make our normal edits unmanageable.
One solution could be to bring super-relations in general use. Or find
another modeling for routes (e.g. with intersection nodes only).

I think we should go to route relations consisting of route sections, as described here:


which I tried to apply to this relation:


Polyglot

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

dieterdreist
In reply to this post by Pieren
2012/11/30 Pieren <[hidden email]>:
> In the example you are pointing, 6 of the 9 relations are for the Bus
> 311. I never map public transport relations but I've seen its modeling
> expanding very far in complexity in recent time (fault is also because
> some routes are complexe anyway). The amount of route relations will
> increase in the future, this is unavoidable. I personally don't care
> about such relations until they make our normal edits unmanageable.


every (route) relation makes highway editing more complicated, e.g.
when you have to split a single highway into a dual carriageway you
will have to know on which of the ways you have to put the route
relation, and maybe you will also have to split the relation into 2
(forward, backward). You might do this with little interruption with 1
route, but when there are 10 of them, many mappers will most likely
move on and not split the highway.


> One solution could be to bring super-relations in general use.


+1, they are already in use, and I think in a case where 6 variants of
the same route are on the same single piece of way the use of
superrelations (route part relations, with which we could assemble the
route variants) could simplify the editing.


> Or find
> another modeling for routes (e.g. with intersection nodes only).


not a good idea IMHO, as it makes editing far more complex (you will
have to understand from just a collection of nodes which ways are
effectively part of a route relation).

cheers,
Martin

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

Pieren
On Fri, Nov 30, 2012 at 11:41 AM, Martin Koppenhoefer
<[hidden email]> wrote:

> not a good idea IMHO, as it makes editing far more complex (you will
> have to understand from just a collection of nodes which ways are
> effectively part of a route relation).

Not necessarily. Creating routes will be more or less the same if your
editor highlights the ways between the nodes. But their are three
advantages : intersection nodes are quite stable in OSM, more than
single nodes or ways. Adding hundreds routes will not disturbe normal
edits. And last but not least, routes will not have to split ways just
because a bus is turning left or right at intersection.

Pieren

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

Ilpo Järvinen
In reply to this post by dieterdreist
On Fri, 30 Nov 2012, Martin Koppenhoefer wrote:

> 2012/11/30 Pieren <[hidden email]>:
> > In the example you are pointing, 6 of the 9 relations are for the Bus
> > 311. I never map public transport relations but I've seen its modeling
> > expanding very far in complexity in recent time (fault is also because
> > some routes are complexe anyway). The amount of route relations will
> > increase in the future, this is unavoidable. I personally don't care
> > about such relations until they make our normal edits unmanageable.
>
>
> every (route) relation makes highway editing more complicated, e.g.
> when you have to split a single highway into a dual carriageway you
> will have to know on which of the ways you have to put the route
> relation, and maybe you will also have to split the relation into 2
> (forward, backward).

You could try with this:

  http://www.cs.helsinki.fi/u/ijjarvin/osm/git/onewayer.git

...It's far from perfect but handles forward/backward roles currently
very quite ok and :forward/:backward tags too (iirc, those without role
won't get handled right though). And in T-junctions some minor cleanup
might be needed afterwards but once you get used to that it's quite
trivial to do that efficiently manually too. I'm almost done with
my area dual carriage splits so implementing more functionality just for
myself is not worth it anymore but ideally it would also be capable of
handling full T/+ junctions instead of only straight segments it currently
does (more complex junctions needs to be split in stages).


--
 i.

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

Richard Fairhurst
In reply to this post by Philip Barnes
Philip Barnes wrote:
> Does anyone else find that editing ways with relations
> slows potlatch to a crawl? I find that there is a long
> delay when ever I do anything to them?

It shouidn't do (and hasn't done on any system I've seen), but I did see a trac ticket that reported something similar. If you can post steps to reproduce on trac, together with your system details (OS, browser and version, Flash Player version) that might help.

cheers
Richard

Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

dieterdreist
In reply to this post by Pieren
2012/11/30 Pieren <[hidden email]>:
> On Fri, Nov 30, 2012 at 11:41 AM, Martin Koppenhoefer
> <[hidden email]> wrote:
>>> [only nodes for routes]
>> not a good idea IMHO, as it makes editing far more complex (you will
>> have to understand from just a collection of nodes which ways are
>> effectively part of a route relation).
>
> Not necessarily. Creating routes will be more or less the same if your
> editor highlights the ways between the nodes.


the editor will have to do routing (for psv) and therefor will be
depending besides the nodes also on correct psv-access-tagging.
Imagine a railway route over a long distance, how would you even
download the relation if you had only some occassional nodes?
Dependent on the following edits the routes might still become
ambigous (alternatives and it is not clear which road exactly the bus
takes).


> But their are three
> advantages : intersection nodes are quite stable in OSM, more than
> single nodes or ways.


probably true, yes, but IF someone deletes the intersection (or
unglues and the original intersection node gets moved to a position
where it is not on the route any more) instead of a small and simple
to fill hole in the route you might come to a situation where it is
not clear any more which way the bus takes, or where it simply becomes
valid but wrong (and much harder to detect).


> And last but not least, routes will not have to split ways just
> because a bus is turning left or right at intersection.


that is a plus, I agree.

I am still very sceptical towards moving from an explicit (unambigous)
mapping style to an implicit one, that requires intensive calculations
(routing for psv) to simply get the route, and that will break in a
way that it would mostly remain valid (so it's hard to find) but
probably not correct.

cheers,
Martin

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

osm-8
In reply to this post by Pieren
Am 30.11.2012 11:57, schrieb Pieren:

> On Fri, Nov 30, 2012 at 11:41 AM, Martin Koppenhoefer
> <[hidden email]> wrote:
>
>> not a good idea IMHO, as it makes editing far more complex (you will
>> have to understand from just a collection of nodes which ways are
>> effectively part of a route relation).
> Not necessarily. Creating routes will be more or less the same if your
> editor highlights the ways between the nodes. But their are three
> advantages : intersection nodes are quite stable in OSM, more than
> single nodes or ways. Adding hundreds routes will not disturbe normal
> edits. And last but not least, routes will not have to split ways just
> because a bus is turning left or right at intersection.
There are several problems. To draw the route in editor you need at
least two nodes in your downloaded data. Then editor have to guess,
which ways are should used for the route.
Eg.:
     ___D___
    /       \
    |       |
---A---C---B----

Which way should editor display? Direct one or longer one?

If some adds a way between D and C and doesn't care about all relation
(editor cant display every route), it gets even unclearer, which way
belong to the route. In actual schema there will be at least A-C, C-B,
A-D or D-B and it's possible to fix the route quite easy.

Implications aren't a better way, it's mainly guessing.

Henning


_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

Richard Welty-2
In reply to this post by Martin Vonwald (Imagic)
i'm going to ask a question that occurred to me the other day.

why model the ways a bus route takes? why not just have an ordered
list of the stops it makes? what data consumers need to know the ways
a bus takes?

richard


_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

osm-8
Am 30.11.2012 14:37, schrieb Richard Welty:
> i'm going to ask a question that occurred to me the other day.
>
> why model the ways a bus route takes? why not just have an ordered
> list of the stops it makes? what data consumers need to know the ways
> a bus takes?
Hmm...maybe they wants to display it in a map? Same as cycle-routes,
hiking-routes, ... ;)

Henning


_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

dieterdreist
In reply to this post by Richard Welty-2
2012/11/30 Richard Welty <[hidden email]>:
> i'm going to ask a question that occurred to me the other day.
>
> why model the ways a bus route takes? why not just have an ordered
> list of the stops it makes? what data consumers need to know the ways
> a bus takes?


There are lots of interesting applications, for instance when getting
realtime position information from the vehicles it allows you to
better predict the arrival at the next stops if you know which way the
vehicle is going to take.

cheers,
Martin

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

Pieren
In reply to this post by osm-8
On Fri, Nov 30, 2012 at 2:21 PM, Henning Scholland <[hidden email]> wrote:
> Eg.:
>     ___D___
>    /       \
>    |       |
> ---A---C---B----

I'm not sure to understand your problems here. If your route goes
through A->D then select A and D. If your route is A->C->D, then
select A, C & D. The only possible (theoritical) issue migh be a two
possible ways between two near intersections. This could be solved by
adding an intermediate node for instance (or the way itself in such
exceptional case).

> Which way should editor display? Direct one or longer one?

Always the direct one. The longer means that you missed an
intersection in your route definition. It's a mistake. Routes defined
by ways also contain mistakes (not continuous, dead ends, duplicates,
etc).

> If some adds a way between D and C and doesn't care about all relation
> (editor cant display every route), it gets even unclearer, which way belong
> to the route.

If you split the way in the current model, the new way is placed into
the relation automagically by the editor. Such feature could be
implemented as well for the other modeling.

Pieren

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

osm-8
Am 30.11.2012 15:11, schrieb Pieren:
> On Fri, Nov 30, 2012 at 2:21 PM, Henning Scholland <[hidden email]> wrote:
>> Eg.:
>>      ___D___
>>     /       \
>>     |       |
>> ---A---C---B----
Think about there is only -A-D-B- , where A and B are a node in such a
relation. Everything is fine.
Now someone adds a way A-C-B. This mapper have to do several things now:
Check, if he make a way of a relation more directer as it was before.
Problem1: Find all affected relation.
Problem2: If he adds a footway, he can skip bus-relations, but what to
do if access is unclear?
Problem3: Editing the route will end in a try'n'error: Does josm
"routes" correct if I add this node?
Problem4: No mapper will know about to do these checks, because it was
never ever a problem adding a simple way or changing highway=* or access

Same if a mapper changes the access of any way. Maybe its easy in
Cities, if necessary nodes are pretty close. But in rural areas it could
happen that you edit/add a way somewhere and you destroy a relation
which has one node 1km left of your mappnig area and the next one 5km in
the right. This isn't really practicable.

Henning


_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

jaakkoh
In reply to this post by Martin Vonwald (Imagic)
+1
This was exactly what I was about to comment.
I'd add that things might look relatively ok in areas where the map data is pretty complete -- but it totally tanks in areas where it's not. I didn't come to think of the access-/practicability-related, which make it even more complicated.

As per the notion of "intersection nodes are quite stable in OSM".
Again, might b true for intersection nodes but it's the additions of "shortcuts" that makes it especially complicated, I think.

Cheers,
-Jaakko

------Original Message------
From: Henning Scholland
To: Tag discussion, strategy and related tools
ReplyTo: Tag discussion, strategy and related tools
Subject: Re: [Tagging] How to solve the problem with relation overload?
Sent: Nov 30, 2012 09:31

Am 30.11.2012 15:11, schrieb Pieren:
> On Fri, Nov 30, 2012 at 2:21 PM, Henning Scholland <[hidden email]> wrote:
>> Eg.:
>>      ___D___
>>     /       \
>>     |       |
>> ---A---C---B----
Think about there is only -A-D-B- , where A and B are a node in such a
relation. Everything is fine.
Now someone adds a way A-C-B. This mapper have to do several things now:
Check, if he make a way of a relation more directer as it was before.
Problem1: Find all affected relation.
Problem2: If he adds a footway, he can skip bus-relations, but what to
do if access is unclear?
Problem3: Editing the route will end in a try'n'error: Does josm
"routes" correct if I add this node?
Problem4: No mapper will know about to do these checks, because it was
never ever a problem adding a simple way or changing highway=* or access

Same if a mapper changes the access of any way. Maybe its easy in
Cities, if necessary nodes are pretty close. But in rural areas it could
happen that you edit/add a way somewhere and you destroy a relation
which has one node 1km left of your mappnig area and the next one 5km in
the right. This isn't really practicable.

Henning


_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging


Sent from my BlackBerry® device from Digicel
--
Mobile: +509-37-26 91 54, Skype/GoogleTalk: jhelleranta
_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

jaakkoh
In reply to this post by Martin Vonwald (Imagic)
"why not just have an ordered
list of the stops it makes?"

Eg. Because public transportation systems don't always have fixed stops. + the other reasons mentioned.

-Jaakko

------Original Message------
From: Richard Welty
To: [hidden email]
ReplyTo: Tag discussion, strategy and related tools
Subject: Re: [Tagging] How to solve the problem with relation overload?
Sent: Nov 30, 2012 08:37

i'm going to ask a question that occurred to me the other day.

why model the ways a bus route takes? why not just have an ordered
list of the stops it makes? what data consumers need to know the ways
a bus takes?

richard


_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging


Sent from my BlackBerry® device from Digicel
--
Mobile: +509-37-26 91 54, Skype/GoogleTalk: jhelleranta
_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

Pieren
In reply to this post by osm-8
On Fri, Nov 30, 2012 at 3:31 PM, Henning Scholland <[hidden email]> wrote:

> Think about there is only -A-D-B- , where A and B are a node in such a
> relation. Everything is fine.

Still not sure to understand what is specific to a route modeling with
waypoints instead of segment list. In your example, A and B are not
intersections bfeore the A-D-B creation. But let say, they are
intersections. What you propose has been already discussed: you might
have 2 possible ways between two intersections (A and B) and I already
suggested some solutions. If the route is A-D-B, then nothing change
in the relation. If the route is A-C-B, then put C in the relation (or
the way itself in such exceptional case).

> This isn't really practicable.
I could say the same with the current model. Route relations are hard
to maintain because they are often broken by contributors unaware
about relations. Then, some people even suggest to make ways edition
harder once they belong to a relation, a kind of "protection against
newcomers". And this is now happening when your read the OP. But I
would say the opposite : streets edition should be the simplest as
possible. Bus routes are just tolerated in OSM and should be withdrawn
if they make street edition too difficult and moved to another
database.

Pieren

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: How to solve the problem with relation overload?

osm-8
See picture ( http://www.aighes.de/data/routes.png ). Hope it makes it
more clear.

Green points are your route-nodes, black lines are given OSM-ways (which
would actually in route-relation), red line is the route, blue line is
an added OSM-way or an OSM-way which changes access-Tags.

If a mapper adds this blue way or changes the access-Tags of this way,
the mapper have to add a node to route-relation somewhere in the upper
arc. If he doesn't do so, he will break the route-relation, without
touching any part of this relation. If the mapper uses orange point, the
shortest distance between all green and orange point will be orange
line, which is a broken relation, too. So better use light-green point.
Ok last point could be solved with other routing-algorithm.

The main problem I see is, that mappers had never care about relations
doing above things. Noone will care about a relation, if he changes an
access-Tag, a highway-Tag or adding/modifying a highway.

If there are gaps in an actual route, you can spot them out very easy,
because you see this gap. In a node-based model, there wont be a gap.
Only if there is no connection between two nodes. If I change a
route-node or add OSM-ways (see above) the route will just change the
route. You can only figure out the fault, if you compare it to reality.

In my example (picture) its quite easy to detect, that you are breaking
a relation. But reality is in many cases harder.

In my opinion it's better to give editor more AI, that he can assist the
mapper in handling ways with many relations.

Henning

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging

routes.png (23K) Download Attachment
12