[Talk-transit] Proposed Feature - RFC - Public Transport

Michael von Glasow michael at vonglasow.com
Thu Dec 9 22:40:10 GMT 2010


On 12/09/2010 01:31 PM, Michał Borsuk wrote:
>
>
> On 8 December 2010 20:44, Dominik Mahrer (Teddy) <teddy at teddy.ch 
> <mailto:teddy at teddy.ch>> wrote:
>
>     Hello
>
>     Yes, the Public Transport proposal is basically based on Oxomoa,
>     but in some details different.
>
>
>     I do not care about which of the two proposals will be approved.
>     But I think it is time to get a more exact schema approved then
>     the fuzzy/non-existing schema (A railway station of 400m length
>     and 20 platforms or a bus stop for 3 buses per direction of 50m
>     length is reduced to one node) we have now.
>
>
> There is the issue of "multiple relations per line" in oxomoa, which 
> in my opinion is a total misfit. There are "roles" in relations, and 
> different variants of a route can be put there. 
My previous post to this list contains an example of what you may 
encounter in real life. The case of a telescope line may be 
representable in a single relation, but I really do not know how to 
express in a single relation that some courses skip part of the route 
(the market example) and follow another (including some different stops) 
instead. If you have a decent way of expressing that in a single 
relation, please do share it here - I'd happily adopt that if only 
someone suggests a satisfactory solution to the issue.
> Two, or more, relations per line is not only "illegal" (clearly 
> against the principle, as it was stated by its creators), but also 
> hell to administer, and JOSM-limited.
Are you referring to the master relation which contains the relations 
for the route variants? In fact I don't use them in Milan (in Munich it 
seems common practice and I follow that), and as of today renderers seem 
to be fine even without it. Take the following example:

http://78.46.81.38/api/sketch-line?network=SITAM&ref=69&style=padua

This line is made up of four relations (two variants with one relation 
for each direction), and OSM Server Side Script manages to put them 
together based on their ref and network tags. Obviously, the individual 
relations must have all the tags that would otherwise go into the master 
relation.

Or do you mean the fact that there are two (or more) relations per line? 
It is true that it means more effort, which is why I would happily 
consolidate the information into a single route if this were doable 
without losing information.

Editor support, as Dominik writes, I would not overestimate. JOSM may be 
complex, but maintaining public transportation routes is complex on 
itself - someone doing that is quite likely to use JOSM anyway. I don't 
really see a reason against using JOSM - Potlatch in my opinion is for 
the occasional mapper or for very quick edits; Merkaartor may have some 
performance benefits (being a native application) but JOSM still has 
satisfactory performance.
> Potlatch and Merkaartor account for 2/3 edits together.
Now this does surprise me - I would have expected a higher "market 
share" for JOSM. If you have the figures at hand, it would be 
interesting to find out how many of the people who edit public 
transportation data use JOSM vs. other editors.

Then again - if other editors do not support all that's possible, we 
should also consider adapting the editors to support the tagging scheme 
we have in mind rather than adapting the tagging scheme to what is 
supported by all editors.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20101209/ce422bf0/attachment.html>


More information about the Talk-transit mailing list