[Talk-transit] Proposed changes to oxomoa schema [part 1]

Michał Borsuk michal.borsuk at gmail.com
Mon Jun 28 18:54:07 BST 2010


Hello everybody,

As I have stated before, I am grateful that somebody has done the difficult
work of codifying the mess of public transport, but IMHO forgetting
scalability and usability.

My intention is to rework the schema introducing scalability, that is
allowing users with minimal knowledge to participate in the creation of
public transport routes, while minimizing the workload, unnecessary
overhead, and at the some time to keep as much compatibility as possible
(but not 100%).

Also, management by the most simple tools is the aim.

This email will go in parts, so that it is possible to sensibly comment on
each point separately.

--------------------------------------------------------------------------------------------------

*ISSUE RAISED:
* change to the way more complex lines are mapped, that is the introduction
of tags or roles instead of nested collections*

Present status: For lines with variants, each variant needs a separate
relation

Problems:
* Nested relations are difficult to impossible to manage in potlatch,
* They are difficult to understand
* Creating a variant requires the entire route to be duplicated:  impossible
in potlatch
* Extending or rerouting such lines can be hell
* High risk of introducing a mess by inexperienced users (I think). I
actually think my proposal is more error-resistant.
* It's time-consuming! It's easy to duplicate a line once one knows JOSM,
but how much time does it take to get JOSM running, from downloading to
having results? A lot.

*Proposed change: introduction of a "core line", that is shared by all
variants in all directions, and having the branches or exceptions in one
direction tagged appropriately. Core line would have no tags, branch lines
would be tagged arbitrarily. *

Result: lower consistency of the data entered, but much less time needed to
enter and manage lines. The "mess" can be easily dealt with by server-side
software presenting data to users. If one wants a route from one's side
branch of a line, one looks down the tagged branch up to the main branch,
and then up to the stop needed. Nothing hard to implement. It's the 21st
century, I believe that we don't have to rely on simple parsers that take
nothing else but point-to-point connections.




-- 
Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia,

Michał Borsuk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20100628/0662b779/attachment.html>


More information about the Talk-transit mailing list