Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Cartinus]

On Friday 14 January 2011 12:42:40 Oleksandr Vlasov wrote:
> What's the status of unified_stoparea, btw? It's in RFC stage for almost 2
> years, wikipage not being actively edited for year and a half.

If any proposal is dormant for such a long time you have to look at the actual 
usage.

If it is widely used, then it has become a accepted and the wiki simply 
is "out of date".

If it is not widely used then, there is probably something wrong with it.


-- 
m.v.g.,
Cartinus

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Oleksandr Vlasov]

Richard Mann  gmail.com> writes:

> http://wiki.openstreetmap.org/wiki/Buses
> I've tidied it up a bit (moved the simpler stuff to the top, given a
> basic specification on using relations, put unified_stoparea as an
> elaboration rather than an alternative; I hope it doesn't spark an
> edit war).

What's the status of unified_stoparea, btw? It's in RFC stage for almost 2
years, wikipage not being actively edited for year and a half. Is the proposal's
author here, is s/he still interested in the proposal?



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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Richard Mann]

On Fri, Jan 14, 2011 at 9:25 AM, Claudius Henrichs  wrote:
>
> +1
> I don't think the stop_area-relation for the vast majority of simple bus,
> tram or train stops is necessary. öpnvkarte.de and other sites working with
> the data prove that you can reliably determine nodes belonging to one stop
> via easy algorithms/preprocessing.
>
> Claudius

Agree. However I think it would help renderers (and anyone who doesn't
have access to a modest level of pre-processing) if there was a clear
way of:
1) identifying the boarding location
2) identifying a good place for a single symbol/label for a group of
stops (particularly at lower zooms)

I would suggest a much simpler scheme, adding just two new values:

highway=bus_stop_group
railway=tram_stop_group

to provide for explicitly identifying a good place for a single
symbol/label, leaving highway=bus_stop and railway=tram_stop to
identify the boarding locations (yes that means changing the meaning
of railway=tram_stop, but the old meaning would still be valid).

Renderers would then have the option of attaching symbols/labels as
they see fit to:
a) railway=tram_stop, node on a railway=tram way (ie the established approach)
b) railway=tram_stop, node not on a railway=tram way (eg Helsinki)
c) railway=tram_stop_group

{similar for buses}

And before anybody says "tagging for the renderers", I suggest they go
and read the relevant wiki page:
http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer

Richard

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Claudius Henrichs]

Am 14.01.2011 02:16, Tobias Knerr:

Dominik Mahrer wrote:

One month ago I already posted an RFC on this proposal. In the meantime
I got plenty of comments and I have extended/corrected/rewritten nearly
the whole proposal.

I'm not very happy with the extensive use of relations. Especially
nested relations strongly suggest that the level of complexity is beyond
what's appropriate for a crowd-sourced project like OSM.

The most prominent issue are stop area groups. The necessity of these
has already been questioned. I, too, tend to think that determining them
algorithmically would ultimately be a better choice. Removing the nested
relations for stop area groups would eliminate one of the most complex
concepts from the proposal, making it more accessible to mappers.

Additionally, I suggest to reconsider the requirement to use stop area
relations even in simple cases Many bus stops are very straightforward:
They consist of usually two platforms with a common name. This name is
usually unique within a range of several kilometres and, if tagged to
the platform elements, could therefore be used instead of a relation to
identify the components of the stop area.

+1
I don't think the stop_area-relation for the vast majority of simple 
bus, tram or train stops is necessary. öpnvkarte.de and other sites 
working with the data prove that you can reliably determine nodes 
belonging to one stop via easy algorithms/preprocessing.


Claudius

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Tobias Knerr]

Dominik Mahrer wrote:
> One month ago I already posted an RFC on this proposal. In the meantime
> I got plenty of comments and I have extended/corrected/rewritten nearly
> the whole proposal.

I'm not very happy with the extensive use of relations. Especially
nested relations strongly suggest that the level of complexity is beyond
what's appropriate for a crowd-sourced project like OSM.

The most prominent issue are stop area groups. The necessity of these
has already been questioned. I, too, tend to think that determining them
algorithmically would ultimately be a better choice. Removing the nested
relations for stop area groups would eliminate one of the most complex
concepts from the proposal, making it more accessible to mappers.

Additionally, I suggest to reconsider the requirement to use stop area
relations even in simple cases Many bus stops are very straightforward:
They consist of usually two platforms with a common name. This name is
usually unique within a range of several kilometres and, if tagged to
the platform elements, could therefore be used instead of a relation to
identify the components of the stop area.

Tobias Knerr

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

On 01/12/2011 06:34 PM, ant wrote:

On 12.01.2011 17:27, Richard Mann wrote:



I think there is some misunderstanding. I'm talking about the use of
relations to group stop positions and platforms together that are
considered a stop or station where one can change vehicles.



Again, why enter it by hand (expensive!), when OSM already contains all 
the necessary data (stop coordinates, obstacles between them)?


We do not need "stop areas", at least not for that purpose. The 
"transferability" between stops can be calculated by a very simple 
script checking the distance (foot route) and obstacles between the two 
stops. The distance is then added to the cost of the route.


(Cost: each transfer is a cost, travel time is a cost, walk as well, 
etc. The connection with the smallest cost is presented to the user).



Greetings,

LMB


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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

On 01/12/2011 05:07 PM, ant wrote:



A node in this context means "a
place where i can change from one bus (tram) line to another without
having to walk more than a few metres".In the proposed scheme a stop
area is exactly this.



Sorry, but this is absolutely pointless. First of all, modern routing 
software can calculate a route finding the nodes from stops' coordinates 
(Hafas and Google Transit). It will consider two stops to be a node if a 
distance between them is lower than a certain constant. So those can be 
created dynamically, humans are not necessary. For speed, popular pairs 
of stops are stored in a static table.



Secondly, if you insist on "stop area", then you create a weak point for 
the routing program, because it would rely on human input creating those 
areas. One area missing, and the entire routing algorithm goes to hell, 
because the program would send you through another "stop area".  Such 
errors would be very visible, and the users would be disappointed. Who 
wants to be taken for a ride all over the town because of one missing 
"stop area"?



I mean no offence, but please understand that this is the 21st century. 
Your suggestions are indeed correct, but are applicable to software 
standards that were there 10 or 15 years ago. Much more can be done now.


Point: Leave it to the algorithm instead of asking humans to do it.



So the point of stop area relations is to prepare
the data to be interpreted as a network and thus to make routing... easy.


Programs such as Hafas are some years of age, and already they do it 
easier than you propose. They do it the way I described above: finding 
connections by distance between stops, and calculating the "price" to 
walk. A connection with a shorter walk is of course preferred, as is a 
connection without transfers.



Greetings,
LMB


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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Carsten Schönert]

Hello,

Am 12.01.2011 15:22, schrieb Vincent Pottier:

Le 12/01/2011 11:10, Albin Michlmayr a écrit :

I pretty much came the same way Dominik did. I am also a public
transport fanatic. And I like to map small details and it makes me joy
to when a bus route crossing a roundabout uses one half of the
roundabout in one direction and the other half in the other direction.

I like precision too. But on that point I think it's a mistake to cut
roundabouts for routing.
Included in a route, a roundabout has an entry point, a outgoing point
and a oneway circulation.


Of course has a roundabout a start and finishing point, and this points 
are the same. For me is it not visible there this point is, but this 
also does not intereset me.


For the renderer is this one way, even the whole roundabout. Look 
further! For every routing the routerer have know there the roundabout 
has to be left. How should this going if the end of this way is also the 
starting point? Your nice OSM based navi is send thrue the roundabout 
again and again and again ... :-)



So it is very easy to comput the part of the
roundabout used by the route without cuting it.
A roundabout is to be considered as a cross, just a big cross.


Once again, from where should the navi know there to leave the roundabout?


I have stopped cutting them when someone explained this easy comput.
I think roundabouts would be cut only when part of them are bridges.


Whats so differend to bridges in refrence to a relation, or road over 
half europe? I think it's only correct to split the roundabout into peaces.


With not splitted roundabout will every check of the relation in order 
of the correct order of the elements fail! That whould make my life not 
realy easier.


for example
http://ra.osmsurround.org/osm.jsp?relationId=93622
or
http://ra.osmsurround.org/analyze.jsp?relationId=302441


--
FrViPofm

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


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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[ant]

On 12.01.2011 17:27, Richard Mann wrote:

On Wed, Jan 12, 2011 at 4:07 PM, ant  wrote:

So the point of stop area relations is to prepare the data to be interpreted as
a network and thus to make routing... easy.


Stop areas are about linking the stop (notionally on the footway) to
the road. Or they are about linking platforms with the same name. You
can do that as you go along. The stopping_position and stop_area
relation are just clutter.

If you know the latlons of two stop areas, you can work out how to get
between them by running your pedestrian routing algorithm. Marking
footways between stops (other than the ones you can assume are
adjacent to any roads not marked with footway=no) is more useful than
linking the stop areas into a group and implying there is free access
between any stop area within it.

Basically you use relations to link objects which have a geographical
relationship - not just a geographical proximity.


I think there is some misunderstanding. I'm talking about the use of 
relations to group stop positions and platforms together that are 
considered a stop or station where one can change vehicles. These could, 
for example, consist of two separate tram stops and four different bus 
stops and could serve several bus and tram lines (or even metro). Maybe 
this should be tagged "stop_area_group" rather than "stop_area". In any 
case these objects certainly have a relationship - they serve as 
interchange nodes in a public transport network.


I'm not defending the use of stop area relations on singular stops that 
have only one platform on each side of the road... that would be clutter 
indeed.




There's sense in adding "group" objects if data relates to the group
(eg to a station and not to it's individual platforms), but I'd find a
convenient node or area to hold the info, not put it on an unnecessary
relation. And if the information is relatively simple (eg a name), I'd
settle for putting it on all the nodes, rather than create an
artificial single object to hold it.


As I said, it depends on the scale of the stop (area (group)).

cheers
ant

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Richard Mann]

On Wed, Jan 12, 2011 at 4:07 PM, ant  wrote:
> So the point of stop area relations is to prepare the data to be interpreted 
> as
> a network and thus to make routing... easy.

Stop areas are about linking the stop (notionally on the footway) to
the road. Or they are about linking platforms with the same name. You
can do that as you go along. The stopping_position and stop_area
relation are just clutter.

If you know the latlons of two stop areas, you can work out how to get
between them by running your pedestrian routing algorithm. Marking
footways between stops (other than the ones you can assume are
adjacent to any roads not marked with footway=no) is more useful than
linking the stop areas into a group and implying there is free access
between any stop area within it.

Basically you use relations to link objects which have a geographical
relationship - not just a geographical proximity.

There's sense in adding "group" objects if data relates to the group
(eg to a station and not to it's individual platforms), but I'd find a
convenient node or area to hold the info, not put it on an unnecessary
relation. And if the information is relatively simple (eg a name), I'd
settle for putting it on all the nodes, rather than create an
artificial single object to hold it.

Richard

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[ant]

On 12.01.2011 16:40, Michał Borsuk wrote:

Am 12.01.2011 16:30, schrieb ant:

Consider an application that takes a start and an end address, maybe
other options such as night lines only, and that shall calculate the
shortest PT connection including number of stops etc. How would you
accomplish that with the old tagging scheme?


By introducing an abstract interface layer with your own objects, that
is your own internal standard, into which all the "messy" present
standards would be translated. This is easy. Then you play with *your*
objects, your program is not directly dependent on the OSM PT standards.
Any changes to the standards will require only a few lines of code to
the abstract interface layer.


There are some minimum requirements that the data should meet in order 
to make it easy. In particular, it should resemble the network structure 
of a PT network, i.e. bus and tram stops acting as nodes that connect 
bus and tram lines with each other. A node in this context means "a 
place where i can change from one bus (tram) line to another without 
having to walk more than a few metres". In the proposed scheme a stop 
area is exactly this. So the point of stop area relations is to prepare 
the data to be interpreted as a network and thus to make routing... easy.


cheers
ant


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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

Am 12.01.2011 16:30, schrieb ant:
Consider an application that takes a start and an end address, maybe 
other options such as night lines only, and that shall calculate the 
shortest PT connection including number of stops etc. How would you 
accomplish that with the old tagging scheme?


By introducing an abstract interface layer with your own objects, that 
is your own internal standard, into which all the "messy" present 
standards would be translated. This is easy. Then you play with *your* 
objects, your program is not directly dependent on the OSM PT standards. 
Any changes to the standards will require only a few lines of code to 
the abstract interface layer.



BTW Data consistency is not as important as it used to be 15 years ago. 
We primarily have to make sure that no contradicting standards exists. 
Of course, this conversation still does make sense, because we want to 
have a clear standard for beginners, and for our own ease of use (and fun).


Greetings,

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

Michał Borsuk


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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[ant]

On 12.01.2011 16:00, Richard Mann wrote:

On Wed, Jan 12, 2011 at 2:50 PM, ant  wrote:

Ok, nobody is forced into a complicated tagging scheme. Anybody who is
uncomfortable with relations, advanced editors or whatever should just put a
node to each bus stop. That's fine. Another mapper will come and turn it
into a stop area and update the route relations.


But if applications can cope with only having an unordered relation
and bus stop pole nodes (or indeed just tram_stop centroids), then why
clutter the map with lots more tags and info that the applications can
perfectly well derive for themselves 99.9% of the time? You should
only supply the extra info for the 0.1% of the time when it can't
readily be derived.


I don't know what applications you have in mind, but if they can do more 
than draw some lines on a map, this sounds like black magic to me. 
Consider an application that takes a start and an end address, maybe 
other options such as night lines only, and that shall calculate the 
shortest PT connection including number of stops etc. How would you 
accomplish that with the old tagging scheme?


cheers
ant

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

Am 12.01.2011 15:50, schrieb ant:

Hi,


Ok, nobody is forced into a complicated tagging scheme. Anybody who is 
uncomfortable with relations, advanced editors or whatever should just 
put a node to each bus stop. That's fine. 

And that's what we're about to standarize.

Another mapper will come and turn it into a stop area and update the 
route relations.
Exactly. But this entire process needs a website, hence this discussion 
here.
[...] People will develop standalone OSM routing applications for 
public transport and won't accept any dependency on external websites...
No, they won't. It's too complicated, and too expensive to maintain. I 
can bet on it (sadly). Those who claim otherwise have not seen the real 
data, or they think that a bus starts from a terminus, ends at another 
terminus, and does it N times a day. It's not at all that easy. (Some 
people may want to simply copy Google Transit data, but again, Google 
Transit at present covers very small area.)



Greetngs,

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

Michał Borsuk


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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Richard Mann]

On Wed, Jan 12, 2011 at 2:50 PM, ant  wrote:
> Ok, nobody is forced into a complicated tagging scheme. Anybody who is
> uncomfortable with relations, advanced editors or whatever should just put a
> node to each bus stop. That's fine. Another mapper will come and turn it
> into a stop area and update the route relations.

But if applications can cope with only having an unordered relation
and bus stop pole nodes (or indeed just tram_stop centroids), then why
clutter the map with lots more tags and info that the applications can
perfectly well derive for themselves 99.9% of the time? You should
only supply the extra info for the 0.1% of the time when it can't
readily be derived.

Richard

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[ant]

Hi,

On 12.01.2011 13:40, Michał Borsuk wrote:

Yes, we are - at the cost of (sorry to repeat the mantra) "efficiency,
compatibility with the existing software and easier learning curve".
 From our point of view (or mine, depends how you see it), the quality
of the final product is a mathematical product of quite a few parameters
(including the mantra above), NOT the quality of the data alone.


Ok, nobody is forced into a complicated tagging scheme. Anybody who is 
uncomfortable with relations, advanced editors or whatever should just 
put a node to each bus stop. That's fine. Another mapper will come and 
turn it into a stop area and update the route relations.



I'm not saying everybody should do it now and everywhere. But the
proposed public transport scheme is a solid basis to work with and one
that is scalable enough to meet requirements we might not yet be
thinking about.


I've already provided my criticism to the proposed schema, so not to
repeat myself, on another topic:

I have been sort of thinking along the same lines as you are here
(assistance to the users of public transport). I came to the conclusion
that the easiest thing would be to take the bus stop code and combine it
with the link to the local timetable online. For example, to cover
entire area of Germany one would need to import stop codes as the
"stop_id" tag, and then have a list of online timetables combined with
geographical location those timetables cover. As some people (myself
included) have already imported stop_id's, the last step - the mapping
of public transport authorities to the geographical area, and providing
a link to the online timetable is relatively banal. An overlay would
then take the stop_id, combine it with the URL, and here opens your
timetable website.


I don't think that this is sufficient. People will develop standalone 
OSM routing applications for public transport and won't accept any 
dependency on external websites...


cheers
ant


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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Vincent Pottier]

Le 12/01/2011 11:10, Albin Michlmayr a écrit :

I pretty much came the same way Dominik did. I am also a public
transport fanatic. And I like to map small details and it makes me joy
to when a bus route crossing a roundabout uses one half of the
roundabout in one direction and the other half in the other direction.
I like precision too. But on that point I think it's a mistake to cut 
roundabouts for routing.
Included in a route, a roundabout has an entry point, a outgoing point 
and a oneway circulation. So it is very easy to comput the part of the 
roundabout used by the route without cuting it.

A roundabout is to be considered as a cross, just a big cross.
I have stopped cutting them when someone explained this easy comput.
I think roundabouts would be cut only when part of them are bridges.
--
FrViPofm

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Richard Mann]

On Wed, Jan 12, 2011 at 12:21 PM, Ed Loach  wrote:
> Unified_stoparea is flawed in that it isn't backwards compatible as it 
> contradicts the documentation for highway=bus_stop (node beside way) to use 
> it for the stopping position (rather than the platform). This is why the 
> proposals that use public_transport tags are immediately better.

You have to make sense of all the main existing schemas already (since
they are unlikely to disappear). The main requirement is understanding
what they are and how to tell them apart, not to try to standardise
them (and especially not to standardise by multiplying the number of
tags several-fold).

Richard

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

Am 12.01.2011 12:59, schrieb ant:

Hi Michał,


Certainly it doesn't make sense to talk about bus stops when the road 
network isn't even finished yet. Totally agree.


The point is, we are in the process of establishing a kind-of-standard 
about public transport network. There has been lots of struggle about 
this topic, and therefore it's quite an important process.
Since I am working on a project that deals with navigation for the 
blind and visually impaired, I know how important these mapping 
standards (if you can call anything in OSM a "standard" at all) are. 
If we continue to stick to the old scheme, or any extremely simplistic 
scheme, we are simply missing the basis for future development in the 
area of blind people's navigation (and probably many other areas as 
well).
Yes, we are - at the cost of (sorry to repeat the mantra) "efficiency, 
compatibility with the existing software and easier learning curve". 
From our point of view (or mine, depends how you see it), the quality 
of the final product is a mathematical product of quite a few parameters 
(including the mantra above), NOT the quality of the data alone.


I'm not saying everybody should do it now and everywhere. But the 
proposed public transport scheme is a solid basis to work with and one 
that is scalable enough to meet requirements we might not yet be 
thinking about.


I've already provided my criticism to the proposed schema, so not to 
repeat myself, on another topic:


I have been sort of thinking along the same lines as you are here 
(assistance to the users of public transport). I came to the conclusion 
that the easiest thing would be to take the bus stop code and combine it 
with the link to the local timetable online. For example, to cover 
entire area of Germany one would need to import stop codes as the 
"stop_id" tag, and then have a list of online timetables combined with 
geographical location those timetables cover. As some people (myself 
included) have already imported stop_id's, the last step - the mapping 
of public transport authorities to the geographical area, and providing 
a link to the online timetable is relatively banal. An overlay would 
then take the stop_id, combine it with the URL, and here opens your 
timetable website.


I am writing this, because I have heard of NAPTAN, and I am sure a 
similar plan could be applied in the UK. My point is not to reinvent the 
wheel, no matter how much one likes programming.



cheers

also,

ant


michal

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

Michał Borsuk


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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Ed Loach]

Richard wrote:

> put unified_stoparea as an
> elaboration rather than an alternative; I hope it doesn't spark an
> edit war).

It might. Unified_stoparea is flawed in that it isn't backwards compatible as 
it contradicts the documentation for highway=bus_stop (node beside way) to use 
it for the stopping position (rather than the platform). This is why the 
proposals that use public_transport tags are immediately better. Adding bus 
stop nodes is one of the simple things new mappers can do; more advanced users 
can add them to the appropriate relations later. 

Ed


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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[ant]

Hi Michał,

On 12.01.2011 12:45, Michał Borsuk wrote:

Am 12.01.2011 12:37, schrieb ant:

On 12.01.2011 09:52, Michał Borsuk wrote:


The visually impaired are a very small minority, and clearly OSM has
different, more basic issues to deal with. We should focus on the
mainstream first, to get OSM out of the beta version it is now.


It is not our primary aim to serve some kind of mainstream. It is to
collect any geographical data that could be useful to somebody. And
yes, "somebody" includes blind people, too.


I did not exclude blind people from the pool of users. I simply said
that they are a minority, and should be treated as such. Not with
greater privileges than most of us. Therefore I see no point to spend
great amounts of time mapping lines in a special way so that we could
preserve the fact that line X calls at bus stop Y in each direction. I
simply see no point to focus on this, in the present state of OSM.

Look at this Western European town:

http://www.openstreetmap.org/?lat=49.10581&lon=6.71405&zoom=15&layers=M

I mapped one line through the town, and then simply had to get a level
lower, to first map the streets, because simply there was nothing to
draw the bus lines on. Later somebody added buildings from the French
Cadastre, and the town looks grotesque: now I can guess where the
streets should be between thebuildings. But still, there is no point to
map more lines before the street network exists.

In such a situation should we really think about the blind, or should we
focus on the very basic: to put the lines on the map?



Certainly it doesn't make sense to talk about bus stops when the road 
network isn't even finished yet. Totally agree.


The point is, we are in the process of establishing a kind-of-standard 
about public transport network. There has been lots of struggle about 
this topic, and therefore it's quite an important process.
Since I am working on a project that deals with navigation for the blind 
and visually impaired, I know how important these mapping standards (if 
you can call anything in OSM a "standard" at all) are. If we continue to 
stick to the old scheme, or any extremely simplistic scheme, we are 
simply missing the basis for future development in the area of blind 
people's navigation (and probably many other areas as well).
I'm not saying everybody should do it now and everywhere. But the 
proposed public transport scheme is a solid basis to work with and one 
that is scalable enough to meet requirements we might not yet be 
thinking about.


cheers
ant

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

Am 12.01.2011 12:37, schrieb ant:

On 12.01.2011 09:52, Michał Borsuk wrote:


The visually impaired are a very small minority, and clearly OSM has
different, more basic issues to deal with. We should focus on the
mainstream first, to get OSM out of the beta version it is now.


It is not our primary aim to serve some kind of mainstream. It is to 
collect any geographical data that could be useful to somebody. And 
yes, "somebody" includes blind people, too.


I did not exclude blind people from the pool of users. I simply said 
that they are a minority, and should be treated as such. Not with 
greater privileges than most of us. Therefore I see no point to spend 
great amounts of time mapping lines in a special way so that we could 
preserve the fact that line X calls at bus stop Y in each direction. I 
simply see no point to focus on this, in the present state of OSM.


Look at this Western European town:

http://www.openstreetmap.org/?lat=49.10581&lon=6.71405&zoom=15&layers=M

I mapped one line through the town, and then simply had to get a level 
lower, to first map the streets, because simply there was nothing to 
draw the bus lines on. Later somebody added buildings from the French 
Cadastre, and the town looks grotesque: now I can guess where the 
streets should be between thebuildings. But still, there is no point to 
map more lines before the street network exists.


In such a situation should we really think about the blind, or should we 
focus on the very basic: to put the lines on the map?


--

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

Michał Borsuk


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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Richard Mann]

On Wed, Jan 12, 2011 at 11:12 AM, Michał Borsuk  wrote:
> So, who's volunteering to prepare yet another wiki page that would explain
> the situation?

http://wiki.openstreetmap.org/wiki/Buses

I've tidied it up a bit (moved the simpler stuff to the top, given a
basic specification on using relations, put unified_stoparea as an
elaboration rather than an alternative; I hope it doesn't spark an
edit war).

I might get on to trams in due course.

Richard

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[ant]

On 12.01.2011 09:52, Michał Borsuk wrote:

Am 12.01.2011 07:50, schrieb André Joost:

Am 11.01.11 17:01, schrieb Michał Borsuk: You do get that information
when you are at the spot. It is written on

the timetable.


If you are able to see, yes. But disabled (that is everyone who has to
use public transport because he/she is not able to drive a car) not.



The visually impaired are a very small minority, and clearly OSM has
different, more basic issues to deal with. We should focus on the
mainstream first, to get OSM out of the beta version it is now.


It is not our primary aim to serve some kind of mainstream. It is to 
collect any geographical data that could be useful to somebody. And yes, 
"somebody" includes blind people, too.


cheers
ant

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[ant]

Hi,

On 12.01.2011 11:16, Richard Mann wrote:

3) It doesn't matter whether people use one relation per direction or
two. Both are readily parsable. However, "forward"/"backward" must
refer to the direction of the way, not the direction of the route,
otherwise you are cutting across other uses of those roles.


I've been using the public transport scheme with separate relations for 
each direction for quite a while. It's true it's a bit more work, but 
one of the advantages is that the confusing roles "forward" and 
"backward" are *not* necessary in that case.


And keeping in mind that the road network is growing in detail, i.e. 
mapping of double carriageways, at some point maybe even individual 
lanes, the benefit of the "simplicity" of single relations is always 
traded off against the downside of inner complexity.


cheers
ant

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

Am 12.01.2011 11:16, schrieb Richard Mann:

1) We need to see a proposal that is explicitly scalable. No more than
one page to describe how to map a basic bus or tram line in a way that
is consistent with existing usage (ie if you look around you will see
lots of examples to reinforce your understanding).

2) There is no clear case for a new public_transport key. If existing
usage of existing tags works ok for basic situations, that should be
enough.
That seems to be a sensible proposal, but do we put it into the 
standard? If so, then the one-relation version should be accompanied by 
a comment on roles.



3) It doesn't matter whether people use one relation per direction or
two. Both are readily parsable. However, "forward"/"backward" must
refer to the direction of the way, not the direction of the route,
otherwise you are cutting across other uses of those roles.



So, who's volunteering to prepare yet another wiki page that would 
explain the situation?


And, personal request hereby. If you provide examples how to map (also 
how not to map would be good), please do not only provide your own 
examples.



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

Michał Borsuk


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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

Am 12.01.2011 11:10, schrieb Albin Michlmayr:

Am Tue, 11 Jan 2011 20:21:41 +0100
schrieb Michał Borsuk:


On 11 January 2011 18:59, Dominik Mahrer (Teddy)
wrote:


I began searching for alternatives and found Oxomoa, unified
stoparea, stop place and others. All are created because the
current schema is not able to represent all eventualities.

It doesn't have to. It is an S-function, reaching 100% costs much
more than reaching 99%.

I pretty much came the same way Dominik did. I am also a public
transport fanatic.

So am I.

And I like to map small details and it makes me joy
to when a bus route crossing a roundabout uses one half of the
roundabout in one direction and the other half in the other direction.
Till now I had the impression that openstreetmap follows the philosophy
"Everybody maps as detailed as he likes". And for enthusiasts it is not
only a question of efficency and costs but also of joy, and isn't it
because of enthusiasts that openstreetmap exist?
It's a Pareto-principle distribution: 80% of edits are done by 20% of 
contributors. Still, this does not mean that we can't have more 
contributors. And new guys are not going to map half a roundabout, at 
least not immediately.


Personally I've done the same as you did, until I realized that my area 
(2500km²) will never get done if I am to be so slow. Thereafter I 
imported *all* the bus stops, added more lines, and miraculously more 
contributors appeared! So people were encouraged to join when they saw 
another person do something in their area. So the learning curve was 
important after all: they all copied from me, instead of discovering 
(like I did) how it should be done.


And that's my main point: we need more of those "small time contributors".

If not and if this detailed public transport mapping is not preferred
in osm please tell me, then I will find my joy somewhere else.

This is a proposal, nobody is telling you to go. Or even to change your 
ways. Enjoy it as you did. I am just appealing to your common sense: the 
standard is not only for us, but for the community. The community is 
often  *very* different than us. Most of them will never reach our 
levels of proficiency, but if they map a line or two, it's very good!


And, I don't know where you people  get the idea that I am any different 
than you. I've ridden public transport in many countries, both on the 
right and on the left side of the street, and on two continents. I map 
not only German lines, but also French, and local international (yes, we 
do have those!). Presently I don't have a car, but I have an almost free 
monthly ticket to my large public transport area. I've been to more 
places in that PT area (VerkehrsVerbund) than any local inhabitant in 
his whole life.


What I clearly oppose is turning OSM PT mapping into our playground. I 
am an idealist, ready to defend the principle that OSM is a public 
service, not only our personal fun. I am not aiming to take the fun from 
us. All I want is to have an open door for new people. More on this 
should actually follow in the other thread I started, about principles 
to follow.



  Michał, please feel free to tell me what to
change to improve the proposal. To say this proposal has a "bad
learning curve" may be correct, but it does not help further.

In another topic.

I am looking forward to that!


I've posted it yesterday. Can't cite the title, because I don't see my 
own posts. You're very welcome to argue with the five principles I 
posted there, and my comparison of the proposal in the light of the 
principles.


Greetings,

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

Michał Borsuk


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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Richard Mann]

1) We need to see a proposal that is explicitly scalable. No more than
one page to describe how to map a basic bus or tram line in a way that
is consistent with existing usage (ie if you look around you will see
lots of examples to reinforce your understanding).

2) There is no clear case for a new public_transport key. If existing
usage of existing tags works ok for basic situations, that should be
enough.

3) It doesn't matter whether people use one relation per direction or
two. Both are readily parsable. However, "forward"/"backward" must
refer to the direction of the way, not the direction of the route,
otherwise you are cutting across other uses of those roles.

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Albin Michlmayr]

Am Tue, 11 Jan 2011 20:21:41 +0100
schrieb Michał Borsuk :

> On 11 January 2011 18:59, Dominik Mahrer (Teddy) 
> wrote:
> 
> > I began searching for alternatives and found Oxomoa, unified
> > stoparea, stop place and others. All are created because the
> > current schema is not able to represent all eventualities.
> 
> It doesn't have to. It is an S-function, reaching 100% costs much
> more than reaching 99%.

I pretty much came the same way Dominik did. I am also a public
transport fanatic. And I like to map small details and it makes me joy
to when a bus route crossing a roundabout uses one half of the
roundabout in one direction and the other half in the other direction.
Till now I had the impression that openstreetmap follows the philosophy
"Everybody maps as detailed as he likes". And for enthusiasts it is not
only a question of efficency and costs but also of joy, and isn't it
because of enthusiasts that openstreetmap exist?

If not and if this detailed public transport mapping is not preferred
in osm please tell me, then I will find my joy somewhere else.

> I am open to change my proposal. I am also open to approve a
> completely
> > different schema. Michał, please feel free to tell me what to
> > change to improve the proposal. To say this proposal has a "bad
> > learning curve" may be correct, but it does not help further.
> 
> In another topic.

I am looking forward to that!

Albin (Almich)

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

Am 12.01.2011 07:50, schrieb André Joost:
Am 11.01.11 17:01, schrieb Michał Borsuk: You do get that information 
when you are at the spot. It is written on

the timetable.


If you are able to see, yes. But disabled (that is everyone who has to 
use public transport because he/she is not able to drive a car) not. 


A lot of the disabled are perfectly able to drive cars (which have been 
adjusted for that purpose). My father was severely disabled after an 
accident, and he did so.
And on the time-table you wont find a hint *where* the right platform is. 
It is clearly printed at each bus stop, at least in Europe. In North 
America  phone number is provided.
A public transport router with audio output would do, if it has the 
data. We could work towards this aim.
The visually impaired are a very small minority, and clearly OSM has 
different, more basic issues to deal with. We should focus on the 
mainstream first, to get OSM out of the beta version it is now.


Greetings,

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

Michał Borsuk


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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

Am 12.01.2011 00:54, schrieb Vincent Pottier:

Le 11/01/2011 18:25, Michał Borsuk a écrit :


I totally agree! For me it was a very timeconsuming search when I
tried to figure out how to set the role of an element in the route. I
found contradicting wiki pages 



YES! that's the point, and that's been said before. Make the wiki 
pages clear, call it "standard", and there you go.
When a new comer is mapping on JOSM, 

You put "newcomer" and "JOSM" in one sentence?

with a good interface, 


cough cough. JOSM and good interface? I beg your pardon? You clearly 
forgot your beginnings. JOSM is the essential tol for the advanced user, 
but it's the least friendly (and ugliest) piece of software out of the 
three.



he has not his eyes in the wiki.
It is easier for him to manage a one way relation, and an other one 
way relation.

We are clearly talking about two different things.


an when I found the Oxomoa scheme with
different relations for each direction I thought this is a quite
simple
solution for the confutision.


Again, how do you implement it in Potlatch?
It is an other matter. We don't map for the editors. And Potlatch 
evolves. JOSM did it.

You didn't answer my question.
How about changing the route temporarily? How about Paris RER, which 
has several trains with different destinations? Do we produce 12 
relations for line X, which has 6 variants? Possible, but crazy.

OK, the new comer will do maintenance on potlatch for the French RER ?
No, not a newcomer. Let me quote the question again, because you may 
have lost it in the text: /"How about Paris RER, which has several 
trains with different destinations? Do we produce 12 relations for line 
X, which has 6 variants?"

/
How non-time-consuming is this for an advanced user, and how do you 
perform this without installing Java?

/
/

They are people with more skill, and other tools for that.


You don't get it. The route to become a pro is to be a beginner first. 
But I am not going to repeat what I wrote three times again.




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

Michał Borsuk

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[André Joost]

Am 11.01.11 17:01, schrieb Michał Borsuk:

Am 11.01.2011 15:15, schrieb André Joost:



Furthermore. The Platforms are different for the two directions.
If you take this node:
http://www.openstreetmap.org/browse/node/428573541
you see that busses to Weststraße, Kelmis Bruch and Uniklinik are
stopping here. if you want the other direction, you have to change the
platform. With one relation for every service, you dont get that
information.

You do get that information when you are at the spot. It is written on
the timetable.


If you are able to see, yes. But disabled (that is everyone who has to 
use public transport because he/she is not able to drive a car) not. And 
on the time-table you wont find a hint *where* the right platform is. A 
public transport router with audio output would do, if it has the data. 
We could work towards this aim.


Greetings,
André Joost



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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Vincent Pottier]

Le 11/01/2011 18:25, Michał Borsuk a écrit :



On 11 January 2011 18:06, Albin Michlmayr > wrote:


Am Tue, 11 Jan 2011 15:15:27 +0100
schrieb André Joost mailto:andre%2bjo...@nurfuerspam.de>>:

> Am 11.01.11 15:00, schrieb Michał Borsuk:
>
> > Questions:
> > * What has been achieved by *three *relations that could have not
> > been achieved by roles? How faster and easier is managing
two/three
> > relations than managing a role on the route?
>
> This role thing is much more complicated than different relations.
> Does forward mean the direction of the bus line, or that of the way
> element in OSM? *That* is what confuses new users.

I totally agree! For me it was a very timeconsuming search when I
tried to figure out how to set the role of an element in the route. I
found contradicting wiki pages 



YES! that's the point, and that's been said before. Make the wiki 
pages clear, call it "standard", and there you go.
When a new comer is mapping on JOSM, with a good interface, he has not 
his eyes in the wiki.
It is easier for him to manage a one way relation, and an other one way 
relation.

For those loving learning curves : the curve is less hard ! ;-)


an when I found the Oxomoa scheme with
different relations for each direction I thought this is a quite
simple
solution for the confutision.


Again, how do you implement it in Potlatch?
It is an other matter. We don't map for the editors. And Potlatch 
evolves. JOSM did it.
How about changing the route temporarily? How about Paris RER, which 
has several trains with different destinations? Do we produce 12 
relations for line X, which has 6 variants? Possible, but crazy.

OK, the new comer will do maintenance on potlatch for the French RER ?
They are people with more skill, and other tools for that.
--
FrViPofm
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Vincent Pottier]

Le 11/01/2011 20:21, Michał Borsuk a écrit :


IMHO it has to be simple and scalable first of all. Scalable in this 
case would mean that an _average_ Joe can learn some parts of it and 
start mapping, then he can learn more (e.g. termini, large transfer 
stations), and proceed from simple to complicated.

I don't understand you.
The scheme is scalable. the new comer will not start mapping platforms, 
stop_areas... He will start mapping a lonely route. He will discover 
that the scheme is richer and his needs deeper, he will discover other 
towns well mapped. He is not stupid... He will learn 'poco a poco' how 
to use the scheme...


How do I knwo this process ? Because they are more and more mappers un 
France, and more and more tonws with bus routes, and the mappers already 
use a scheme that is not so different.


In don't understant why you don't admit that mappers already are able to 
learn a scheme. I see it !

--
FrViPofm

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Dominik Mahrer (Teddy)]

On 01/11/2011 10:42 AM, Sander Deryckere wrote:

Before this becomes standard, could someone please make a script to
transform one tagging scheme in an other? Not for uploading, just
because apps have difficulties to support all the different tagging
schemes. And after all, we want the data to be useful.


In the proposal there is a table that maps all the existing tags to the 
proposed tags. The table can also be used to map from proposed to 
existing. See: 
http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Compatibility_with_well_known_tags


Teddych

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Cartinus]

On Tuesday 11 January 2011 17:01:32 Michał Borsuk wrote:
> > This role thing is much more complicated than different relations.
> > Does forward mean the direction of the bus line, or that of the way
> > element in OSM? *That* is what confuses new users.
>
> Then all we need is to clear that confusion.

Yes, we need to explain it again and again and again and again, because it is 
too difficult to understand for a significant number of new users. So if we 
just dump it we can stop explaining.

-- 
m.v.g.,
Cartinus

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

On 11 January 2011 18:59, Dominik Mahrer (Teddy)  wrote:

>
> I began searching for alternatives and found Oxomoa, unified stoparea, stop
> place and others. All are created because the current schema is not able to
> represent all eventualities.


It doesn't have to. It is an S-function, reaching 100% costs much more than
reaching 99%.


> And many bus routes have their specialities.
>
> As a newbie-public-transport-mapper I did not know which flavor of schema I
> should use to map my special bus route.



You are the third person to say it today. We simply need a good website
telling people how to do it.


> The jungle of possible schema is already densely wooded. But none of the
> schema has an approved status.


OMG, there is no DIN sticker on it? The world has come to an end.


> So everyone uses another schema. In my eyes the absolutely worsted case.
>

Melchior Moos of ÖPNVkarte.de managed to create a useful map out of this
"mess", so this is not such a mess after all. Surely we do need a standard
schema, but oxomoa is IMHO not the right model to base on. If it were, it
would have become a de facto standard already. Clearly it isn't good enough
to become such a thing.

I accepted a lot of criticism and added, changed and extended a lot.


IMHO it has to be simple and scalable first of all. Scalable in this case
would mean that an _average_ Joe can learn some parts of it and start
mapping, then he can learn more (e.g. termini, large transfer stations), and
proceed from simple to complicated.


I am open to change my proposal. I am also open to approve a completely
> different schema. Michał, please feel free to tell me what to change to
> improve the proposal. To say this proposal has a "bad learning curve" may be
> correct, but it does not help further.
>

In another topic.

>
> Teddych




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

Michał Borsuk
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Dominik Mahrer (Teddy)]

Hi Michał

On 01/11/2011 05:10 PM, Michał Borsuk wrote:

Again, I am not criticizing the project from data point of view.
Data-wise it is very good.


OK.


But it's too difficult to learn, and really
unnecessary in many cases.


This is a different problem and basically has nothing to do with the 
proposal itself.


I'm a public transport fanatic. But nearly one year I did not even map 
one simple bus stop. When I tried (and I mean really tried) to map 
public transport I knew relations and roles and I was already familiar 
with subrelations. With the first (pretended simple) bus route I tried 
to map I already was not able to map correctly and complete.


I began searching for alternatives and found Oxomoa, unified stoparea, 
stop place and others. All are created because the current schema is not 
able to represent all eventualities. And many bus routes have their 
specialities.


As a newbie-public-transport-mapper I did not know which flavor of 
schema I should use to map my special bus route. The jungle of possible 
schema is already densely wooded. But none of the schema has an approved 
status. So everyone uses another schema. In my eyes the absolutely 
worsted case.


I accepted a lot of criticism and added, changed and extended a lot. I 
am open to change my proposal. I am also open to approve a completely 
different schema. Michał, please feel free to tell me what to change to 
improve the proposal. To say this proposal has a "bad learning curve" 
may be correct, but it does not help further.


Teddych

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

On 11 January 2011 18:06, Albin Michlmayr  wrote:

> Am Tue, 11 Jan 2011 15:15:27 +0100
> schrieb André Joost 
> >:
>
> > Am 11.01.11 15:00, schrieb Michał Borsuk:
> >
> > > Questions:
> > > * What has been achieved by *three *relations that could have not
> > > been achieved by roles? How faster and easier is managing two/three
> > > relations than managing a role on the route?
> >
> > This role thing is much more complicated than different relations.
> > Does forward mean the direction of the bus line, or that of the way
> > element in OSM? *That* is what confuses new users.
>
> I totally agree! For me it was a very timeconsuming search when I
> tried to figure out how to set the role of an element in the route. I
> found contradicting wiki pages


YES! that's the point, and that's been said before. Make the wiki pages
clear, call it "standard", and there you go.


> an when I found the Oxomoa scheme with
> different relations for each direction I thought this is a quite simple
> solution for the confutision.
>

Again, how do you implement it in Potlatch?  How about changing the route
temporarily? How about Paris RER, which has several trains with different
destinations? Do we produce 12 relations for line X, which has 6 variants?
Possible, but crazy.



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

Michał Borsuk
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

On 11 January 2011 17:20, Sander Deryckere  wrote:

> 2011/1/11 Michał Borsuk 
>
>> Am 11.01.2011 10:42, schrieb Sander Deryckere:
>>
>>
>>> Before this becomes standard, could someone please make a script to
>>> transform one tagging scheme in an other? Not for uploading, just because
>>> apps have difficulties to support all the different tagging schemes. And
>>> after all, we want the data to be useful.
>>>
>>>
>> "Difficulties to support all the tagging schemes" are way easier and
>> cheaper to implement, because they end up being done by a machine.
>> Introducing overblown scheme pots a load on human users. We have a lot of
>> machines and not enough human users.
>>
>> Greetings,
>>
>>
>>
> App makers are human too. If openstreetmap uses for every thing 5 tagging
> schemes, then software devs have 5 times as much work to get the app
> handling all the data.
>

But *once*. Human mappers would have to double *each* bus line they come
across.

Greetings,



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

Michał Borsuk
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Albin Michlmayr]

Am Tue, 11 Jan 2011 15:15:27 +0100
schrieb André Joost :

> Am 11.01.11 15:00, schrieb Michał Borsuk:
> 
> > Questions:
> > * What has been achieved by *three *relations that could have not
> > been achieved by roles? How faster and easier is managing two/three
> > relations than managing a role on the route?
> 
> This role thing is much more complicated than different relations.
> Does forward mean the direction of the bus line, or that of the way 
> element in OSM? *That* is what confuses new users.

I totally agree! For me it was a very timeconsuming search when I
tried to figure out how to set the role of an element in the route. I
found contradicting wiki pages an when I found the Oxomoa scheme with
different relations for each direction I thought this is a quite simple
solution for the confutision.

Albin (User almich)

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Sander Deryckere]

2011/1/11 Michał Borsuk 

> Am 11.01.2011 10:42, schrieb Sander Deryckere:
>
>
>> Before this becomes standard, could someone please make a script to
>> transform one tagging scheme in an other? Not for uploading, just because
>> apps have difficulties to support all the different tagging schemes. And
>> after all, we want the data to be useful.
>>
>>
> "Difficulties to support all the tagging schemes" are way easier and
> cheaper to implement, because they end up being done by a machine.
> Introducing overblown scheme pots a load on human users. We have a lot of
> machines and not enough human users.
>
> Greetings,
>
>
>
> --
> Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia,
>
> Michał Borsuk
>

App makers are human too. If openstreetmap uses for every thing 5 tagging
schemes, then software devs have 5 times as much work to get the app
handling all the data. I don't think this or the original scheme is
overblown, so if the proposal comes through, they will both be used which
make handling the data more difficult.

The same happened with addresses: housenumbers are stored on nodes, on
buildings and in interpolation ways. Street names are given by an
addr:street tag, by an associated_street relation or just the closest
street. City names are given by boundaries, with is_in tags, with addr:city
tags or not which assumes that the closest city is the correct.

Do you see what my point is?

So I ask not to change the tagging scheme if it's not a clear gain for the
editor and there is no easy way to transform between the schemes. And don't
say that transformation between those different ways of tagging is easy, if
you say so, you should be able to give a script which transforms the data to
a uniform notation.

Editing comfort for the openstreetmap users is more important than uniform
data, but if two schemes are roughly equivalent, only one should be used.
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

Am 11.01.2011 16:17, schrieb Vincent Pottier:

Le 11/01/2011 15:00, Michał Borsuk a écrit :
Everybody: please note that I am not stubbornly defending the old 
way. I just want to make sure that *efficiency, ease of use and the 
learning curve* had been taken into account when designing the new 
standard.




My experience is in France where JOSM is very used, because of 
cadastre tools.

Mapping bus route is not easy for new comers.
Good, so making it more complicated is indeed not the right thing to do. 
That's all I want understood, there cadre of experienced users is not 
falling from the sky. It is not growing by itself, but rather getting 
smaller (I mean, people stop mapping at some point, and the only way to 
became a pro is to be a beginner at some point). So the *learning curve 
*is the magic word. It cannot be crazily complicated, because we're 
going to be left with a handful of public transport mappers, discussing 
yet another version of a standard, but for ourselves.


It seems that having one relation per direction, when they differ, is 
easier to manage for newbies, than managing roles. Besause JOSM has a 
good tool to follow continuity of the path.


It seems also that they are enough example well mapped in France for 
new comers to learn this way.

Mapping bus route is not easy, but it is not so hard to learn.


The problem is that the entry level tool that we have, namely Potlatch, 
does not support copying nor nesting of relations.


Again, I am not criticizing the project from data point of view. 
Data-wise it is very good. But it's too difficult to learn, and really 
unnecessary in many cases.




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

Michał Borsuk

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

Am 11.01.2011 13:28, schrieb Christian:

On 11.01.2011 12:15, Michał Borsuk wrote:

Am 11.01.2011 10:34, schrieb Claudius Henrichs:


Arguments for relations in each direction:
- easier to check correctness and completeness (simply select each 
direction's relation in JOSM)
- easier to manage routes where the vehicle takes different routes 
and stops in each direction

...which is very rare in Europe.


Can't comment on anything else in this discussion, but in the part of 
Northern Germany where I live, a lot of buses use different routes 
depending on the direction. I think the main reason is one way roads 
all over the place.


A bus line in a one-way road does need to carry extra information about 
its direction, because it's already in the direction of the road, right?




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

Michał Borsuk


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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

Am 11.01.2011 10:42, schrieb Sander Deryckere:


Before this becomes standard, could someone please make a script to 
transform one tagging scheme in an other? Not for uploading, just 
because apps have difficulties to support all the different tagging 
schemes. And after all, we want the data to be useful.




"Difficulties to support all the tagging schemes" are way easier and 
cheaper to implement, because they end up being done by a machine. 
Introducing overblown scheme pots a load on human users. We have a lot 
of machines and not enough human users.


Greetings,


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

Michał Borsuk


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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

Am 11.01.2011 15:15, schrieb André Joost:

Am 11.01.11 15:00, schrieb Michał Borsuk:


Questions:
* What has been achieved by *three *relations that could have not been
achieved by roles? How faster and easier is managing two/three relations
than managing a role on the route?


This role thing is much more complicated than different relations.
Does forward mean the direction of the bus line, or that of the way 
element in OSM? *That* is what confuses new users.

Then all we need is to clear that confusion.


Furthermore. The Platforms are different for the two directions.
If you take this node:
http://www.openstreetmap.org/browse/node/428573541
you see that busses to Weststraße, Kelmis Bruch and Uniklinik are 
stopping here. if you want the other direction, you have to change the 
platform. With one relation for every service, you dont get that 
information.
You do get that information when you are at the spot. It is written on 
the timetable.



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

Michał Borsuk


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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Vincent Pottier]

Le 11/01/2011 15:00, Michał Borsuk a écrit :
Everybody: please note that I am not stubbornly defending the old way. 
I just want to make sure that *efficiency, ease of use and the 
learning curve* had been taken into account when designing the new 
standard.




My experience is in France where JOSM is very used, because of cadastre 
tools.

Mapping bus route is not easy for new comers.
It seems that having one relation per direction, when they differ, is 
easier to manage for newbies, than managing roles. Besause JOSM has a 
good tool to follow continuity of the path.


It seems also that they are enough example well mapped in France for new 
comers to learn this way.

Mapping bus route is not easy, but it is not so hard to learn.
--
FrViPofm
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Vincent Pottier]

Le 11/01/2011 12:15, Michał Borsuk a écrit :

Am 11.01.2011 10:34, schrieb Claudius Henrichs:


Arguments for relations in each direction:
- easier to check correctness and completeness (simply select each 
direction's relation in JOSM)
- easier to manage routes where the vehicle takes different routes 
and stops in each direction

...which is very rare in Europe.
Hum ! It seems you have not mapped busses in Besançon... where it is 
very rare that a bus come and go by the same way...

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[André Joost]

Am 11.01.11 15:00, schrieb Michał Borsuk:


I have opened line 24 that I seem to remember
(http://www.openstreetmap.org/browse/relation/304105), and there are two
for each direction, seemingly following the same path.


Line 24 has only one relation for each direction.


Questions:
* What has been achieved by *three *relations that could have not been
achieved by roles? How faster and easier is managing two/three relations
than managing a role on the route?


This role thing is much more complicated than different relations.
Does forward mean the direction of the bus line, or that of the way 
element in OSM? *That* is what confuses new users.


Furthermore. The Platforms are different for the two directions.
If you take this node:
http://www.openstreetmap.org/browse/node/428573541
you see that busses to Weststraße, Kelmis Bruch and Uniklinik are 
stopping here. if you want the other direction, you have to change the 
platform. With one relation for every service, you dont get that 
information.


Grrets,
André Joost




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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

Am 11.01.2011 11:55, schrieb André Joost:

Am 11.01.11 08:33, schrieb Michał Borsuk:



Is there anybody else using it? I'd like to see more examples out of
Germany or Switzerland, bitte.


You will find a lot of well-mapped routes here:
http://wiki.openstreetmap.org/wiki/AVV


I have opened line 24 that I seem to remember 
(http://www.openstreetmap.org/browse/relation/304105), and there are two 
for each direction, seemingly following the same path.

Questions:
* What has been achieved by *three *relations that could have not been 
achieved by roles? How faster and easier is managing two/three relations 
than managing a role on the route?
* What is the overall difference in paths, in percent, between the 
directions? Isn't it that only around the Bushof, and the terminus in 
Kelmis that the bus indeed goes into a one-direction loop?


Everybody: please note that I am not stubbornly defending the old way. I 
just want to make sure that *efficiency, ease of use and the learning 
curve* had been taken into account when designing the new standard.


Looking forward to your reply,

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

Michał Borsuk

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

Am 11.01.2011 10:40, schrieb Jo:
For the record: I prefer to have one relation for each direction of 
the bus route, as this allows to indicate 'exactly' where the buses pass. 
Has OpenStreetMap turned into a timetable, or is it still intended to be 
a map?


We are not mapping merely for the ability to draw a map of the bus 
routes, 

Did I miss the moment when it was decided?

but also to allow PT routing eventually.
Have you look into the complexity of the problem? Seriously, are you 
aware what is behind a typical bus timetable program? I know Hafas from 
the inside, I have seen the timetable data. What you see inside is WAY 
more complicated than what you see at the bus stop. Granted, Germans 
tend to complicate things beyond necessity, but even in an American 
version buses make detours, e.g. off peak hours, and often such runs are 
not on the map because they are not regular lines/runs *). To be able to 
put everything on the map would be practically beyond our abilities at 
the moment, and it would require another layer. *I am not at all 
discouraging the development of a layer with a timetable*, surely this 
is a beautiful idea, but please people reassure me that you know what 
you're getting us into.


*) that is my rule: if bus doesn't pass at least four times a day in the 
country, and more often in the city, it is not a regular line, therefore 
not on the map, as there is no use for John Doe with a GPS.


Thus for now - and in my opinion it will be quite a long "now" before 
the timetable layer is anywhere near completion - I vote for something 
far simpler than yet another oxomoa. Something that will allow future 
expansion. Yes, it's difficult, but we aren't stupid. I have already 
written how I see it, but you people are blind set on this new standard 
like there is no alternative. And pardon me, unlike certain other users, 
I am not promoting "my" ideas just because I used them for a long time, 
but I have thought of the efficiency as well.


BTW I have entered some thousands of bus stops, and if I was to follow 
the new schema (and I should, after all it's a proposed standard, and 
I'm not an anarchist), I assume it would take 2 to 4 times as much time.


Let me make my point clear: a standard is needed. But if we develop a 
new standard, let it also meet the following qualities (next to "clarity 
of data"):

*ease of use,
*efficiency,
*sensible learning curve.

Greetings,

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

Michał Borsuk

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

Am 11.01.2011 13:14, schrieb Vincent Privat:


2011/1/11 Michał Borsuk >


Am 11.01.2011 10:34, schrieb Claudius Henrichs:


Arguments for relations in each direction:
- easier to check correctness and completeness (simply select
each direction's relation in JOSM)
- easier to manage routes where the vehicle takes different
routes and stops in each direction

...which is very rare in Europe.


I strongly disagree, it's a very common situation in my city 
(Toulouse, France). And I don't think at all it's a local specifity.


I have no time to analyze the entire network, so I followed line 78. Not 
at all complicated, around Saint-Orens-de-Gameville it does split, 
that's all what I can see. A split into two can be marked as roles, or 
ignored. Please: everybody remember, the aim of this map is not to 
compete with timetables, the map is supposed to show where (in which 
street) the bus passes regularly, not exactly where it goes. It is a 
map, after all.




This has been proposed some time ago as a reply to oxomoa's
messiness with data structures. So somebody suggested a bigger
mess to make order in a smaller mess. Gib's ein Wort für
"efficiency" in deutsche Sprache? Can nobody really see how much
more complicated and time-consuming this is becoming? At the cost
of what, gaining 5% in data structure clarity? For me the gain
isn't really worth the time.


It's a possibility, not an obligation.
Au contraire. This will become an obligation de facto. And that is 
actually good.



I strongly support this proposal which 90% reflect how I'm
currently mapping in Europe and Asia.

Think of new users.


I am a new user. And I'm waiting for this proposal acceptation, 
because the current schema is far too simple, and far too basic, to 
properly modelize the public transport network I'm using every day. A 
"new user" is not always a user who cannot understand this schema.

I have mapped an area of 2500km², with ca. 100 regular bus lines. It works.


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

Michał Borsuk

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Christian]

On 11.01.2011 12:15, Michał Borsuk wrote:

Am 11.01.2011 10:34, schrieb Claudius Henrichs:


Arguments for relations in each direction:
- easier to check correctness and completeness (simply select each 
direction's relation in JOSM)
- easier to manage routes where the vehicle takes different routes 
and stops in each direction

...which is very rare in Europe.


Can't comment on anything else in this discussion, but in the part of 
Northern Germany where I live, a lot of buses use different routes 
depending on the direction. I think the main reason is one way roads all 
over the place.


Christian

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Vincent Privat]

2011/1/11 Michał Borsuk 

>  Am 11.01.2011 10:34, schrieb Claudius Henrichs:
>
>
> Arguments for relations in each direction:
> - easier to check correctness and completeness (simply select each
> direction's relation in JOSM)
> - easier to manage routes where the vehicle takes different routes and
> stops in each direction
>
> ...which is very rare in Europe.
>
>
I strongly disagree, it's a very common situation in my city (Toulouse,
France). And I don't think at all it's a local specifity.


>
> This has been proposed some time ago as a reply to oxomoa's messiness with
> data structures. So somebody suggested a bigger mess to make order in a
> smaller mess. Gib's ein Wort für "efficiency" in deutsche Sprache? Can
> nobody really see how much more complicated and time-consuming this is
> becoming? At the cost of what, gaining 5% in data structure clarity? For me
> the gain isn't really worth the time.
>
>
It's a possibility, not an obligation. The example you gave as overbloated
and "unneccessary complex" says explicitely "if required". And this kind of
complexity is needed in some cases. It's not because some points are
necessarely complicated the whole thing is a "mess".


> I strongly support this proposal which 90% reflect how I'm currently
> mapping in Europe and Asia.
>
> Think of new users.
>

I am a new user. And I'm waiting for this proposal acceptation, because the
current schema is far too simple, and far too basic, to properly modelize
the public transport network I'm using every day. A "new user" is not always
a user who cannot understand this schema.
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[André Joost]

Am 11.01.11 12:15, schrieb Michał Borsuk:



So I vote for a simple solution to the existing problem. "Simple"
already eliminates anything that resembles oxomoa. And what Teddych
proposed is even more complicated.


Ok, put every highway=bus_stop a specific bus service is serving in a 
relation tagged name="Bus xy". Is that simple enough for you?


If not: Only put a note="Bus xy" on those nodes.

Relations *are* complicated, but no one *has* to use them.

Greetings,
André Joost



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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

Am 11.01.2011 10:34, schrieb Claudius Henrichs:


Arguments for relations in each direction:
- easier to check correctness and completeness (simply select each 
direction's relation in JOSM)
- easier to manage routes where the vehicle takes different routes and 
stops in each direction

...which is very rare in Europe.
I already see it's more a question of taste here, but I feel it's more 
elegant to work with seperated relations for each direction. 
So do I. This is an indeed more orderly way. But it hits efficiency very 
much. Administration of two routes when the bus is temporarily rerouted 
is twice the work.


And besides the above, I've seen such a nonsense as an RE train route 
entered as two relations.


And less stressfull when using a 300 members opposed to a 500+ member 
relation.

Don't see the point here, really.
From a short test it seems like P2 does work fine with nested 
relations so that's no counter-argument anymore.


Does P2 allow copying relations so that the opposite relation can be 
done easily? I don't think so.


Again, I dislike the current "standard". It's not a standard. But I am 
against jumping to something new just because we don't like what we 
have. We could find ourselves in deeper trouble by implementing 
something that is not easily understood by the mappers, because they 
will, for example, implement it in a bad way.


So I vote for a simple solution to the existing problem. "Simple" 
already eliminates anything that resembles oxomoa. And what Teddych 
proposed is even more complicated.
The type=route_master thingie is new to me, 
This has been proposed some time ago as a reply to oxomoa's messiness 
with data structures. So somebody suggested a bigger mess to make order 
in a smaller mess. Gib's ein Wort für "efficiency" in deutsche Sprache? 
Can nobody really see how much more complicated and time-consuming this 
is becoming? At the cost of what, gaining 5% in data structure clarity? 
For me the gain isn't really worth the time.


I strongly support this proposal which 90% reflect how I'm currently 
mapping in Europe and Asia.

Think of new users.

Claudius


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



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

Michał Borsuk

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[André Joost]

Am 11.01.11 08:33, schrieb Michał Borsuk:



Is there anybody else using it? I'd like to see more examples out of
Germany or Switzerland, bitte.


You will find a lot of well-mapped routes here:
http://wiki.openstreetmap.org/wiki/AVV

Greetings,
André Joost




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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[André Joost]

Am 11.01.11 10:42, schrieb Sander Deryckere:

Before this becomes standard, could someone please make a script to
transform one tagging scheme in an other? Not for uploading, just because
apps have difficulties to support all the different tagging schemes. And
after all, we want the data to be useful.


We do not map for any specific app. The german öpnvkarte deals with bus 
routes regardless of the scheme they are tagged by; so other apps should 
be able to do this on their own.


Greetings,
André Joost


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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Sander Deryckere]

Before this becomes standard, could someone please make a script to
transform one tagging scheme in an other? Not for uploading, just because
apps have difficulties to support all the different tagging schemes. And
after all, we want the data to be useful.
Op 11-jan.-2011 10:35 schreef "Claudius Henrichs"  het
volgende:
> Am 11.01.2011 08:03, Michał Borsuk:
>>
>>
>> On 11 January 2011 07:24, Dominik Mahrer (Teddy) > > wrote:
>>
>> Hi all
>>
>> One month ago I already posted an RFC on this proposal. In the
>> meantime I got plenty of comments and I have
>> extended/corrected/rewritten nearly the whole proposal.
>>
>> Please visit again
>> http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport
>>
>>
>> This:
>>
>> * The route-Relation
>>  is split
>> up into two separate *direction*-Relation
>> s and
>> separate route *variants*, if required.
>> * The *route master*-Relation
>>  contains
>> all the relations for the route directions and variants
>>
>> ...is a copy of oxomoa, which has been criticized as overbloated. Why
>> was it kept in the new draft? What are the arguments for two relations
>> in each direction?
> I don't feel it to be bloated instead it's necessary, needed and
> practically in use. And especially for the "simple" or new mapper it
> seems way easier to create two relations for each direction than messing
> with forward/backward roles.
> Arguments for relations in each direction:
> - easier to check correctness and completeness (simply select each
> direction's relation in JOSM)
> - easier to manage routes where the vehicle takes different routes and
> stops in each direction
> ...
> I already see it's more a question of taste here, but I feel it's more
> elegant to work with seperated relations for each direction. And less
> stressfull when using a 300 members opposed to a 500+ member relation.
> From a short test it seems like P2 does work fine with nested relations
> so that's no counter-argument anymore.
>
> The type=route_master thingie is new to me, but I prefer it over Oxomoa
> which recycled route=line for the master and it's members and thus mixed
> the two levels.
>
> I strongly support this proposal which 90% reflect how I'm currently
> mapping in Europe and Asia.
> Claudius
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Jo]

For the record: I prefer to have one relation for each direction of the bus
route, as this allows to indicate 'exactly' where the buses pass. We are not
mapping merely for the ability to draw a map of the bus routes, but also to
allow PT routing eventually.

Jo

2011/1/11 Michał Borsuk 

>
>
> On 11 January 2011 07:24, Dominik Mahrer (Teddy)  wrote:
>
>> Hi all
>>
>> One month ago I already posted an RFC on this proposal. In the meantime I
>> got plenty of comments and I have extended/corrected/rewritten nearly the
>> whole proposal.
>>
>> Please visit again
>> http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport
>>
>> Regards
>> Teddych
>>
>>
> Extending my previous post: I've given a quick look to the proposal, and it
> seems to combine what is now used, with what oxomoa had proposed. Oxomoa has
> been criticized as unnecessarily complicated, and you seem not to have
> addresses this issue. What is now proposed is in my opinion worse that what
> was before, exactly because it does not address oxomoa's issues. The
> proposed schema is more complicated, i.e. instead of one point for a bus
> stop, three (!) are proposed: one for the place where the bus stops, and two
> platforms, if they exist.
>
> Moreover, the unnecessary in 99% of cases practice of using two relations
> for each line is kept, two relations (one in each direction), plus there's a
> mother relation, the so-called "route master". A few important issues arise:
>
>
> * First of all, *Potlatch** does not allow the creation of nested
> relations*. Potlatch, when I last looked at statistics, was responsible
> for 1/3 of all edits. How do you plan to address this issue?
>
> * Secondly, the creation of such relations is neither easy, nor quick. It
> may discourage new mappers as *the learning curve would be much more
> difficult*. And it may be perceived as an unnecessary and discouraging.
> Not the way to go if we want to increase the quality of the map, which has
> to be done by humans.
>
> * Thirdly, Please again *elaborate on the efficiency* of such a solution,
> because it seems that the small gain in quality is offset by the huge loss
> in time necessary to achieve this. Also, maintaining lines in *three 
> *relations
> will be hell: any change of the line will require at least *double* work.
> Is there really a good reason for the double work? There have been other
> proposals how to deal with lines that have different trace in each
> direction, and those were easier than one relation in each direction
> (disclosure: one proposal was mine)
>
> As for the examples, all those below seem to be coming from you:
> http://www.openstreetmap.org/browse/relation/1342798/history
> http://www.openstreetmap.org/browse/relation/1244886/history
> http://www.openstreetmap.org/browse/relation/1281532/history
>
> Is there anybody else using it? I'd like to see more examples out of
> Germany or Switzerland, bitte.
>
>
>
> --
> Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia,
>
>
> Michał Borsuk
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit
>
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Claudius Henrichs]

Am 11.01.2011 07:24, Dominik Mahrer (Teddy):

Hi all

One month ago I already posted an RFC on this proposal. In the 
meantime I got plenty of comments and I have 
extended/corrected/rewritten nearly the whole proposal.


Please visit again
http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport

Regards
Teddych
You should add on top of the examples one of the most basic "out on the 
countryside" bus stops that does not require a stop_area relation as 
they probably reflect at least half of all bus stops worldwide. 
Currently it looks like you need a public_transport=stop_area-relation 
everywhere


Claudius

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Claudius Henrichs]

Am 11.01.2011 08:03, Michał Borsuk:



On 11 January 2011 07:24, Dominik Mahrer (Teddy) > wrote:


Hi all

One month ago I already posted an RFC on this proposal. In the
meantime I got plenty of comments and I have
extended/corrected/rewritten nearly the whole proposal.

Please visit again
http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport


This:

* The route-Relation
   is split
  up into two separate *direction*-Relation
  s and
  separate route *variants*, if required.
* The *route master*-Relation
   contains
  all the relations for the route directions and variants

...is a copy of oxomoa, which has been criticized as overbloated. Why 
was it kept in the new draft? What are the arguments for two relations 
in each direction?
I don't feel it to be bloated instead it's necessary, needed and 
practically in use. And especially for the "simple" or new mapper it 
seems way easier to create two relations for each direction than messing 
with forward/backward roles.

Arguments for relations in each direction:
- easier to check correctness and completeness (simply select each 
direction's relation in JOSM)
- easier to manage routes where the vehicle takes different routes and 
stops in each direction

...
I already see it's more a question of taste here, but I feel it's more 
elegant to work with seperated relations for each direction. And less 
stressfull when using a 300 members opposed to a 500+ member relation.
From a short test it seems like P2 does work fine with nested relations 
so that's no counter-argument anymore.


The type=route_master thingie is new to me, but I prefer it over Oxomoa 
which recycled route=line for the master and it's members and thus mixed 
the two levels.


I strongly support this proposal which 90% reflect how I'm currently 
mapping in Europe and Asia.

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

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

On 11 January 2011 07:24, Dominik Mahrer (Teddy)  wrote:

> Hi all
>
> One month ago I already posted an RFC on this proposal. In the meantime I
> got plenty of comments and I have extended/corrected/rewritten nearly the
> whole proposal.
>
> Please visit again
> http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport
>
> Regards
> Teddych
>
>
Extending my previous post: I've given a quick look to the proposal, and it
seems to combine what is now used, with what oxomoa had proposed. Oxomoa has
been criticized as unnecessarily complicated, and you seem not to have
addresses this issue. What is now proposed is in my opinion worse that what
was before, exactly because it does not address oxomoa's issues. The
proposed schema is more complicated, i.e. instead of one point for a bus
stop, three (!) are proposed: one for the place where the bus stops, and two
platforms, if they exist.

Moreover, the unnecessary in 99% of cases practice of using two relations
for each line is kept, two relations (one in each direction), plus there's a
mother relation, the so-called "route master". A few important issues arise:


* First of all, *Potlatch** does not allow the creation of nested relations*.
Potlatch, when I last looked at statistics, was responsible for 1/3 of all
edits. How do you plan to address this issue?

* Secondly, the creation of such relations is neither easy, nor quick. It
may discourage new mappers as *the learning curve would be much more
difficult*. And it may be perceived as an unnecessary and discouraging. Not
the way to go if we want to increase the quality of the map, which has to be
done by humans.

* Thirdly, Please again *elaborate on the efficiency* of such a solution,
because it seems that the small gain in quality is offset by the huge loss
in time necessary to achieve this. Also, maintaining lines in *three *relations
will be hell: any change of the line will require at least *double* work. Is
there really a good reason for the double work? There have been other
proposals how to deal with lines that have different trace in each
direction, and those were easier than one relation in each direction
(disclosure: one proposal was mine)

As for the examples, all those below seem to be coming from you:
http://www.openstreetmap.org/browse/relation/1342798/history
http://www.openstreetmap.org/browse/relation/1244886/history
http://www.openstreetmap.org/browse/relation/1281532/history

Is there anybody else using it? I'd like to see more examples out of Germany
or Switzerland, bitte.



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

Michał Borsuk
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Michał Borsuk]

On 11 January 2011 07:24, Dominik Mahrer (Teddy)  wrote:

> Hi all
>
> One month ago I already posted an RFC on this proposal. In the meantime I
> got plenty of comments and I have extended/corrected/rewritten nearly the
> whole proposal.
>
> Please visit again
> http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport
>
>
This:

   - The route-[image:
Relation]is
split up into two separate
   *direction*-[image:
Relation]s
   and separate route *variants*, if required.
   - The *route master*-[image:
Relation]contains
all the relations for the route directions and variants

...is a copy of oxomoa, which has been criticized as overbloated. Why was it
kept in the new draft? What are the arguments for two relations in each
direction?



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

Michał Borsuk
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

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

[Dominik Mahrer (Teddy)]

Hi all

One month ago I already posted an RFC on this proposal. In the meantime 
I got plenty of comments and I have extended/corrected/rewritten nearly 
the whole proposal.


Please visit again
http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport

Regards
Teddych

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