Re: [Talk-us] [OSM-dev] Super-relations or not

2010-11-01 Thread Peter Budny
Marcus Wolschon mar...@wolschon.biz writes:

 I'm using routes in way-simplification to generate simplified maps for
 realtime rendering of larger areas when zooming out.

 It's quite a lot of work with LOTS of cases to try to sort
 route-relations that are randomly sorted with parts
 being other relations instead of ways, parts being contained twice,
 parts missing in the relation but having a
 ref= -tag or a ref_nat= -tag or ... , parts having a ref= -tag with
 the wrong road-number that should NOT be
 made a part of this simplified way,...

In fairness, much of that sounds like errors.  A route relation ought to
contain exactly the things that are part of it, no more no less.  The
ref=* tag on ways is irrelevant for a route relation.

What would you prefer to see the structure of the relation be, given
your druthers?  Should both directions of a road be in one relation,
tagged with roles?  Should a oneway=no way have a role?  Should it be in
the relation twice with different roles?  Should there be separate
relations for each direction with a super-relation to hold them both?
If super-relations are used, does it still make sense to use
forward/backward tags as appropriate?


As far as I'm concerned, the difference in what's required to tag things
is minimal between these concerns.  Therefore, wouldn't it make the most
sense to choose whichever is programmatically the easiest and most
flexible to deal with?
-- 
Peter Budny  \
Georgia Tech  \
CS PhD student \

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] [OSM-dev] Super-relations or not

2010-10-29 Thread Peter Budny
Andy Allan gravityst...@gmail.com writes:

 On Fri, Oct 29, 2010 at 2:45 AM, Peter Budny pet...@gatech.edu wrote:

 That doesn't work; there are cases where it's ambiguous.  If you look at
 [1], US-278 runs along North Avenue (bottom) and Ponce de Leon Avenue
 (top), connected by Monroe Drive (left) and Piedmont Avenue (right).

 The problem is that North Ave and Ponce de Leon are both oneway=no,
 while Monroe and Piedmont are oneway=yes.  So unless you run a routing
 algorithm over the relation, you can't figure out just from the oneway
 tags that US-278 westbound doesn't include North Avenue (which you would
 otherwise assume from it being oneway=no).

 Someone, somewhere, has messed this up good an proper. I can't find
 the origins of this discussion to figure out where it's arisen from
 though.

 The situation you describe is easily dealt with using Route Relation
 roles forward and backward as per cycle routes, or bus routes, or
 every other route relation. See for example

 http://www.openstreetmap.org/?lat=51.8lon=0.89395zoom=17layers=00B0FTF

 It's clearly documented here:
 http://wiki.openstreetmap.org/wiki/Relation:route#Members and rendered
 on multiple maps. However, I see from elsewhere that people are making
 route relations in the US and filling the memberships with west and
 south and suchlike and then finding this causes problems. My advice
 is to stick to the route relation member roles that work for every
 other type of route, and if people ray want to have
 separate routes for I5 East and I5 West then feel free (something that
 hasn't seemed necessary elsewhere) - but don't put the words east or
 west in the ref, add an additional tag to the relation for overall
 direction or something.

 But please, stick with the forward/backward stuff for route relations
 roles, it works well.

Okay, let's presume for a minute that blank/forward/backward is the
correct method.  I'll grant that it does have its advantages, such as
for the scenario I described.

However, when I look at
http://ra.osmsurround.org/analyze.jsp?relationId=78041 (in Belarus)
or
http://ra.osmsurround.org/analyze.jsp?relationId=93920 (in Canada),
the display is meaningless.  It hasn't bothered to connect the
forward/backward ways to the ways with no role, so it's totally unclear
what's going on.

If you want this to be the standard way of tagging things, then we NEED
to get the tools up to spec.  I also noticed that Potlatch doesn't
change the role from forward to backward when you reverse a way.  (JOSM
does the right thing, though.)

My argument for super-relations is that they pretty much work NOW.  You
don't have to look at the roles... one relation contains one direction,
end-to-end.


P.S. I don't know why people haven't complained about this more.  Maybe
because most of the route relations are on motorways, which are almost
universally dual-carriageway.  In the US where lots of minor roads are
signed as routes, and routes are sometimes discontiguous, I think the
issues [will] stand out a little more.

P.P.S. Why do I see so many route relations where a way has been added
more than once, sometimes up to 5 times, with the same role?  What is
that supposed to mean?
-- 
Peter Budny  \
Georgia Tech  \
CS PhD student \

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] [OSM-dev] Super-relations or not

2010-10-29 Thread Apollinaris Schoell

On 29 Oct 2010, at 9:05 , Peter Budny wrote:
 
 P.P.S. Why do I see so many route relations where a way has been added
 more than once, sometimes up to 5 times, with the same role?  What is
 that supposed to mean?

typically an error. only use case where it makes sense is a bus route which 
sometimes uses some segments of a road multiple times 

 -- 
 Peter Budny  \
 Georgia Tech  \
 CS PhD student \
 
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] [OSM-dev] Super-relations or not

2010-10-28 Thread Frederik Ramm

Hi,

Peter Budny wrote:

1) The common way, up to now, for storing routes that alternate between
single- and dual-carriageway has been to leave the single-carriageway
parts without a role, or with the role north/south.  This makes the 
order of the members of the relation meaningless, since you

can't traverse the ways end-to-end in the specified order.


There is no requirement for the order to have meaning; it is just a tool 
the server offers you, and you can use it or not.


The way I view route relations, it is less about traversal and more 
about simply stating that a certain way belongs to a certain route. The 
route relation doesn't lose its usefulness if a little bit in the middle 
is missing.


I would simply group all bits together in the route relation, including 
the dual carriageway pieces, and not worry about roles etc. - this can 
all be deducted from the oneway tags.



This could be solved by adding the single-carriageway sections twice
(once with north and once with south)


Please no.


2) If the direction of a road (e.g. north/south) is indicated by roles,


I recommend not to do that.


If anyone has a compelling argument against super-relations, or for
single relations, I'd like to hear it.  Supporting both seems really
pointless


No, supporting them both is quite probably the best way forward. You can 
start with doing a simple relation, and when you find that there's 
something more complex to it you can still use a super-relation.


I always preach that you should write your code such that wherever you 
expect a way, you also accept a relation that groups a number of ways. 
If that were done throughout, then a super-relation would just be a 
normal relation with one or two sub-relations thrown in as required. No 
need to go up the tree and demand that super-relations exclusively 
contain relations etc.


Bye
Frederik

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

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us