On 09.02.2011 23:12, Michał Borsuk wrote:
On 02/02/2011 03:14 PM, Dominik Mahrer (Teddy) wrote:
On 02.02.2011 13:04, Michał Borsuk wrote:
Let's just get down to differences, I say your proposal is too
difficult. I've already spoken well about its data integrity, but new
users don't care about it. We need something that is as good as yours in
data integrity, and as easy to grasp as my proposals.
Yours is good for beginners. And yours is also good for a white area
mapper.
Advanced mappers are not happy with it.
Enter scalability. Those two proposals mixed and *ordered* in a sensible
manner can provide ease of use, as well as sufficient coverage of more
advanced issues. For beginners level 1, for advanced users with big
needs level three.
In other words, with very little cutting we'd simply need to order
jobs/tasks for mappers from easy to advanced, write a wiki page, and
there you go.
This sorting-and-ordering would be a major task, so it needs to be done
in a quiet atmosphere.
Basically I call your request "good", but I'm not sure about the levels.
For a bus stop, what would be level 1 for you, what level 2 and 3?
If I visit a bus stop by foot I can manage to map the pole/platform. So
this could be level 1. But when I visit within the bus, I can only
manage to map the stop position. So this would be level 1. What should
be level 1 then?
I tried to reduce my proposal to allow simpler cases. stop_area_group
has been completely removed. A lot is now optional (stop_position,
platform, stop_area, route_master). So it should be possible for
beginners to learn step-by-step what they want/need.
Genau.
Unfortunately, bad documentation seems to be a standard among FSF
projects. I see few volunteers to do that work.
Perhaps I misunderstood something. I wrote a proposal that should cover
all what is technically needed to map on an advanced level and also
permits beginner level mapping. But I did not write a beginners howto or
a public transport tutorial. I thought such a tutorial would be based on
an approved proposal.
Based on the point of view that you see the proposal as a tutorial, I
understand now many (if not all) of your criticism! If you see my
proposal as a tutorial, it is bad. Very bad.
As I have written I do not see my proposal as tutorial, I see it as
description of the technically needed that fulfills data integrity. The
tutorial is the next step after the proposal is approved.
And one relation per direction is easier to explain then
forward/backward roles.
Yes, but it has a steeper curve if one relation per direction is
obligatory.
Still, what about variations (like a,b,c,d, but under one line?)
I do not want and I can not forbid using one relation for both
directions. One relation per service is IMHO better then none. And one
relation per direction is better then one per service. In the tutorial I
would explain this. If anyone thinks one relation is sufficient then
he/she should only use one relation. I know services in Switzerland
where this is the case and I by myself would not create two
direction-relations (especially single track, rail-bounded and
bidirectional vehicles that has its platform on only one side). But if a
tram line has mapped every track separate instead of only one way or a
bus line that has plenty of one way streets, it would make sense to also
create two relations for the two directions.
And I do not think we (mappers) can replace an existing public transport
routing solution like hafas (too complex and too dynamic).
There have been calls for this. IMO it is feasible, but as a layer on
OSM, not within.
Maybe, you are right. But then the next question that pops up is: Do we
then need the bus routes within OSM at all? Wouldn't it make more sense
to move them to this new layer?
By the way, what do you mean "dynamic"? I don't have a very good opinion
of HAFAS, it does its job, but is very old, and IMHO at its edge of
development due to silly data structures.
With too dynamic I mean that the timetables can change every year.
The maximum
possible in my opinion is to import this data into OSM.
That has been done.
Partially, yes.
But with a single route relation solution I do not see such a solution.
Neither with one route per relation, but I've already covered the topic,
exactly in this thread. You name a line in ZVV area, I provide you (if
time permits) with routes and bus stops under that line.
In other words, automatic import of HAFAS route data to OSM is not
possible, because under each line sits a collection of routes, minimum 4
(unless the terminus is also the depot). Those less used must be removed
from the import.
Yes, of course, if you import the whole data from Hafas you end up with
a huge number of relations. But if you import and maintain it
automatically, do we have to care about the number of relations?
If we map it by hand, we can reduce it to what makes sense. For example
leave away all the relations that end earlier.
Teddych
_______________________________________________
Talk-transit mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-transit
