On 12/09/2010 01:31 PM, Michał Borsuk wrote:
On 8 December 2010 20:44, Dominik Mahrer (Teddy) <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
Talk-transit mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-transit
