[Tagging] How to solve the problem with relation overload?

Jo winfixit at gmail.com
Tue Dec 4 10:25:01 GMT 2012


2012/12/4 Martin Vonwald <imagic.osm at gmail.com>

> Hi!
>
> After reading all the responses I have to conclude that we don't
> really have a perfect solution right now. I guess the best would be a
> "cleanup" of the relations: on ways where more than one (or two)
> relations are present, create a new relation only for this part,
> remove those ways from the other relations and instead add the newly
> created relation as part of the public transport relation.
>
> This of course makes everything more complicated for the relations and
> I'm not sure if the creator of those wouldn't object. And then? Happy
> edit fighting?
>
> To cut a long story short: I think we need a solution for this
> situation and we need it before the public transport relations spread
> more.
>

That's exactly what I said before the discussion went off on a tangent of
'route hinting'.

A proposal for this already exists:

http://wiki.openstreetmap.org/wiki/Proposed_features/Route_Segments

which I tried to apply to this relation:

http://www.openstreetmap.org/browse/relation/2336780

Unfortunately it's not rendered, otherwise I'd applied it to all bus routes
I maintain. It's true it does add a little bit of complexity when working
with those route relations and it's not immediately apparent anymore
whether a route is continuous. It has a lot of other advantages though,
like maintainability. Instead of changing 60 relations when something
changes, now only 2 need to be changed (One in each direction).

For some very busy stretches of asphalt I'd create a relation from
stop_position to stop_position.

http://www.openstreetmap.org/?lat=50.87998&lon=4.7045&zoom=17&layers=T

For others the 'segment' could span several stops for common parts between
routes.

http://www.openstreetmap.org/?lat=50.86633&lon=4.73224&zoom=16&layers=T

Polyglot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20121204/e47b8844/attachment.html>


More information about the Tagging mailing list