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

[Richard Mann]

On Wed, Dec 29, 2010 at 6:43 AM, Dominik Mahrer (Teddy)  wrote:
> On 12/29/2010 12:30 AM, Richard Mann wrote:
>>
>> If someone maps a single node on the way and calls it
>> highway=bus_stop, then that should be OK (but not recommended).
>
> unified_stoparea recommends that. You would allow but not recommend it,
> correct?

Correct. We will have to live with these, but it's better that the use
of bus_stop should homogenise to the dominant use.

>
>> If someone then wants to put highway=bus_stop nodes on either side,
>> that should be seen as the more correct tagging. The original node
>> should be stripped of it's highway=bus_stop tag, or changed to
>> something meaningless like highway=bus_stop_group_centroid or
>> highway=bus_stop_position (if it genuinely is a stopping position,
>> rather than a group centroid).
>
> What about changing it to platform, if it is really the platform/pole?
>

We will have to live with people doing this, but it's better that the
use of bus_stop should homogenise to the dominant use.

Richard

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

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

[Dominik Mahrer (Teddy)]

On 12/29/2010 12:30 AM, Richard Mann wrote:

If someone maps a single node on the way and calls it
highway=bus_stop, then that should be OK (but not recommended).


unified_stoparea recommends that. You would allow but not recommend it, 
correct?



If someone then wants to put highway=bus_stop nodes on either side,
that should be seen as the more correct tagging. The original node
should be stripped of it's highway=bus_stop tag, or changed to
something meaningless like highway=bus_stop_group_centroid or
highway=bus_stop_position (if it genuinely is a stopping position,
rather than a group centroid).


What about changing it to platform, if it is really the platform/pole?

Regards
Teddy

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

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

[Richard Mann]

On Mon, Dec 27, 2010 at 9:09 PM, Dominik Mahrer (Teddy)  wrote:
> Other mappers want to map a stop_position. At the moment they abuse 
> highway=bus_stop as stop_position.
>
> What do you suggest these mappers to use for as stop_position?

If someone maps a single node on the way and calls it
highway=bus_stop, then that should be OK (but not recommended).

If someone then wants to put highway=bus_stop nodes on either side,
that should be seen as the more correct tagging. The original node
should be stripped of it's highway=bus_stop tag, or changed to
something meaningless like highway=bus_stop_group_centroid or
highway=bus_stop_position (if it genuinely is a stopping position,
rather than a group centroid).

Richard

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

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

[Dominik Mahrer (Teddy)]

Hi Richard

On 12/22/2010 12:16 AM, Richard Mann wrote:

But what would you suggest to use as the stop_position for bus stops, if you
would have to decide?


I would expect data users to infer it from the position of the bus
stop. Logically, you could mark a node for the stop_position between
the bus-stop and the way (or even on the way if the stop_position
blocks all traffic on the way). But this is pretty pointless - data
users will probably ignore them anyway, and infer it from the bus stop
location.


Data users can do with the data what they think it is best. Also Mappers 
can map what they think it is best. If this is congruent is another 
question.


I guess you will never map a stop_position. Other mappers want to map a 
stop_position. At the moment they abuse highway=bus_stop as 
stop_position. There is no (approved/rendered) alternative.


I think you agree that this is not an optimal solution.

What do you suggest these mappers to use for as stop_position?

Regards
Teddych

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

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

[Richard Mann]

On Fri, Dec 17, 2010 at 8:32 AM, Dominik Mahrer (Teddy)  wrote:
> How would you
> handle existing routes, only containing the stop_positions
> (railway=tram_stop)? Removing stop positions and adding the platform/pole?

Leave them as they are. Or add platforms or highway=tram_stop nodes
and put them in the relation instead of the railway=tram-stop nodes.

> So you would deprecate railway=tram_stop as the stop position?

railway=tram_stop remains useful for rendering (it functions not as a
"stop-position" but as the centroid of the stop area)

> My proposal therefore would add both (stop
> position and platform) [to the relation].

On this we do not have agreement. I would add platforms (or
railway=tram_stop as a proxy for a platform). But not stop-positions.

> But what would you suggest to use as the stop_position for bus stops, if you
> would have to decide?

I would expect data users to infer it from the position of the bus
stop. Logically, you could mark a node for the stop_position between
the bus-stop and the way (or even on the way if the stop_position
blocks all traffic on the way). But this is pretty pointless - data
users will probably ignore them anyway, and infer it from the bus stop
location.

Richard

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

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

[Dominik Mahrer (Teddy)]

On 12/13/2010 11:35 PM, Richard Mann wrote:

Because sometimes trams just stop in the road, not at anything that
might be described as a platform. The only thing you can see is a pole
(looking remarkably like a bus stop, in fact). You could call them
railway=platform nodes, but it doesn't sound right. You could call
them bus stops, but then they'd render as bus stops. Calling them
highway=tram_stop allows the nodes to be used by bus relations, while
still using a conventional railway=tram_stop for rendering purposes.


So I think there is the consensus that there exist tree things that can 
be mapped: stop position (railway=tram_stop), platform 
(railway=platform) and the pole (new tag highway=tram_stop).


You suggest to only add the platform (or if not existing the pole) to 
the route. If there is only the platform mapped this is obvious. How 
would you handle existing routes, only containing the stop_positions 
(railway=tram_stop)? Removing stop positions and adding the platform/pole?



Because the platform/pole is a direct indicator of where the
passengers should go to catch the service. The stop position is an
indirect indicator of where the passengers should go - ok for simple
pairs of tram platforms, but less use for anything else. I struggle to
see the value of knowing the stop position except for rendering (it's
just the point on the path of the service which happens to be closest
to the platform/pole).


So you would deprecate railway=tram_stop as the stop position?


I read implicitly that you agree to use the platform instead of the

>> pole for relations, correct?
>

Yes. The things that might constitute a stop (platform, bus_stop,
tram_stop, halt, station etc) are all quite distinct from the things
that constitute the path of the service. If it stops at a platform,
and you have that object available to put in the list of stops in the
relation, then I'd use it.


We are in consensus.


I do not want to obligate someone to tag a stop position. Adding a stop
position would close an incompleteness compared to trams/trains too. And
there are mappers they think it is useful/necessary. Those mappers tag it
actually with public_transport=stop_position+bus=yes and/or highway=bus_stop
on the way. What do you suggest those mappers? Removing the tags?


Tag what you like, as they say, but the route relation should include
a clear list of stops. If some people want to use on-the-way nodes as
a proxy for the platform (and they do), then having both platforms and
stop_positions in the relation strikes me as likely to cause
confusion. Better to only put one node (or platform way/area) in the
relation per stop.


Only adding on-the-way nodes into the relation is often used, correct. 
But I agree that this is incomplete. My proposal therefore would add 
both (stop position and platform).


I think I will have to extend my proposal that it is not mandatory to 
map all the proposed points.


But what would you suggest to use as the stop_position for bus stops, if 
you would have to decide?


Regards
Teddych

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

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

[Richard Mann]

On Mon, Dec 13, 2010 at 7:56 PM, Dominik Mahrer (Teddy)  wrote:
> You want to use railway=platform for relations for trains. Why creating a
> new tag highway=tram_stop instead of railway=platform?

Because sometimes trams just stop in the road, not at anything that
might be described as a platform. The only thing you can see is a pole
(looking remarkably like a bus stop, in fact). You could call them
railway=platform nodes, but it doesn't sound right. You could call
them bus stops, but then they'd render as bus stops. Calling them
highway=tram_stop allows the nodes to be used by bus relations, while
still using a conventional railway=tram_stop for rendering purposes.

> Why replacing the stop position for trams/trains with the platform/pole in
> routes?

Because the platform/pole is a direct indicator of where the
passengers should go to catch the service. The stop position is an
indirect indicator of where the passengers should go - ok for simple
pairs of tram platforms, but less use for anything else. I struggle to
see the value of knowing the stop position except for rendering (it's
just the point on the path of the service which happens to be closest
to the platform/pole).

>
> I read implicitly that you agree to use the platform instead of the pole for
> relations, correct?
>

Yes. The things that might constitute a stop (platform, bus_stop,
tram_stop, halt, station etc) are all quite distinct from the things
that constitute the path of the service. If it stops at a platform,
and you have that object available to put in the list of stops in the
relation, then I'd use it.

> I do not want to obligate someone to tag a stop position. Adding a stop
> position would close an incompleteness compared to trams/trains too. And
> there are mappers they think it is useful/necessary. Those mappers tag it
> actually with public_transport=stop_position+bus=yes and/or highway=bus_stop
> on the way. What do you suggest those mappers? Removing the tags?

Tag what you like, as they say, but the route relation should include
a clear list of stops. If some people want to use on-the-way nodes as
a proxy for the platform (and they do), then having both platforms and
stop_positions in the relation strikes me as likely to cause
confusion. Better to only put one node (or platform way/area) in the
relation per stop.

Richard

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

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

[Dominik Mahrer (Teddy)]

On 12/13/2010 07:06 PM, Richard Mann wrote:

Quite a large proportion (?90%) of the public_transport=platform nodes
are also tagged highway=bus_stop (and bus=yes).


Depending of the view this is one of the following:

1. It is the result of combining Oxomoa/public transport with unified 
stoparea.


or:

2. It is Oxomoa with renderer compatible tags until Oxomoa gets rendered 
correctly on its own.


Teddych

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

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

[Dominik Mahrer (Teddy)]

On 12/13/2010 06:26 PM, Albin Michlmayr wrote:


Till now I solved this by defining one stop in the loop as terminus.
This lines then take different routes for each direction. Therefore I
found the solution with single-direction route relations quite
suitable. I don't know if this is the best solution for openstreetmap
but I defenately think that there ist missing something in the
established scheme.


I agree, I do it equal.


The forward or backward role of a way in the relation is in my opinion
useless, because it is not clear if it refers to the direction of the
way or the route. Currently it is used in both senses.


I agree to this too.


I think what we're edging towards is that expressing a tram stop as a
single node isn't really enough. I think the open question is how tram
stop pole nodes should be tagged, whether that affects
highway=bus_stop, and how you deal with joint bus and tram stops.


When I first discovered the oxomoa-scheme I thougt that it's quite a
good idea to use the new tag "public_transport" because what's the
difference between bus and tram stops - there are enough stops used
by both means of transport. After following this discussion here I'm
not so shure any more because world wide there are already mapped about
66 bus stops as highway=bus_stop and it's senseless to retag all
this stops. On the contrary there are also already mapped about 57000
objects as public_transport=* (23000 nodes as stop_position and 22000
nodes and ways as platform) which of course is much less but also too
many to retag all these.


Because highway=bus_stop (pole) and railway=tram_stop/halt (stop 
position) have different meanings the current schema is stamped with an 
inconsistency. Resolving this inconsistency would require a redefinition 
of at least one of these tags. As you have written: This does not make 
sense.



I don't know which tags are best to be used at the moment but I'm really
interested in a broadly accepted guideline for a more unified taging in
the future.


The longer I think about it, I think it would make sense to use new and 
clearly defined tags. But the well known tags highway=bus_stop and 
railway=tram_stop should not lose the meaning/value. In the new schema 
it should be defined how they are interpreted. For example: node on the 
way => stop position; node beside the way => pole/platform. So we do not 
loose information and the already invested work does not lose the value. 
Actually in my proposal this is missing.


Regards
Teddych

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

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

[Dominik Mahrer (Teddy)]

On 12/13/2010 03:56 PM, Richard Mann wrote:

Adding highway=tram_stop as the representation of the tram pole eliminates
the inconsistency between railway=tram_stop and highway=bus_stop. What do
you suggest for trains?


railway=platform ways/areas replace the station nodes in the ordered
list of stops


You want to use railway=platform for relations for trains. Why creating 
a new tag highway=tram_stop instead of railway=platform?


Why replacing the stop position for trams/trains with the platform/pole 
in routes?



Here in Switzerland we have up to 470m long trains (German ICE), so we have
up to 470m long platforms with often two or more poles (or displays as a
replacement) per platform. Does it make sense to map all poles/displays and
to add them to the relation? Doesn't it make more sense to replace the
pole(s)/display(s) with the platform for relation data to simplify things?


If the platform breaks into distinct sections (such as the A-E on DB
main stations or U-Z on SNCF) then there could be distinct
nodes/ways/areas for each section. You might have the whole length of
the platform as an area, with subsections (or groups of subsections)
done as ways, so you can choose which to make a member of the
relation. Which mainline service uses which platform can be a bit
variable, so you may just end up using the station node anyway.


In some (rare?) cases splitting the platform into several ways/areas 
would make sense. I know a hand full of practical examples.


I read implicitly that you agree to use the platform instead of the pole 
for relations, correct?



What do you suggest as the stop position for buses (as counterpart of
railway=tram_stop and railway=halt)? Or would you leave this completely
away?


I wouldn't tag it. It isn't tagged at the vast majority of bus stops,
so data users are going to have to find a way of coping with it not
being marked, and will probably ignore any that are marked. I also
wouldn't include the stop position in a relation unless it's the only
node available.


For those thousands of highway=bus_stop tagged beside the way 
(interpreted as pole) this is the best way to handle. Those tagged on 
the way should be interpreted as stop position.


I do not want to obligate someone to tag a stop position. Adding a stop 
position would close an incompleteness compared to trams/trains too. And 
there are mappers they think it is useful/necessary. Those mappers tag 
it actually with public_transport=stop_position+bus=yes and/or 
highway=bus_stop on the way. What do you suggest those mappers? Removing 
the tags?


Regards
Teddych

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

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

[Richard Mann]

On Mon, Dec 13, 2010 at 5:26 PM, Albin Michlmayr  wrote:
> ... there are also already mapped about 57000
> objects as public_transport=* (23000 nodes as stop_position and 22000
> nodes and ways as platform) which of course is much less but also too
> many to retag all these.

Quite a large proportion (?90%) of the public_transport=platform nodes
are also tagged highway=bus_stop (and bus=yes).

Richard

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

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

[Albin Michlmayr]

Am Mon, 13 Dec 2010 12:12:15 +
schrieb Richard Mann :

> I think I may have figured out what it is that the established tags
> can't do.

Yes, I guess you found a quite good summary for the roots of this
discussion.

> If you've got a railway=tram with a series of nice neat (and
> well-established) railway=tram_stop nodes then you can only make that
> railway=tram_stop node a member of a route relation once. The oxomoa
> conclusion was to have single-direction route relations.
> 
> But this doesn't work well when you have lines that loop at the ends
> (fairly common with bus services), because the two relations overlap
> (you have to make certain nodes members in both relations, and that
> starts crossing a complexity/maintainability threshold).

Till now I solved this by defining one stop in the loop as terminus.
This lines then take different routes for each direction. Therefore I
found the solution with single-direction route relations quite
suitable. I don't know if this is the best solution for openstreetmap
but I defenately think that there ist missing something in the
established scheme.

The forward or backward role of a way in the relation is in my opinion
useless, because it is not clear if it refers to the direction of the
way or the route. Currently it is used in both senses.

> I think what we're edging towards is that expressing a tram stop as a
> single node isn't really enough. I think the open question is how tram
> stop pole nodes should be tagged, whether that affects
> highway=bus_stop, and how you deal with joint bus and tram stops.

When I first discovered the oxomoa-scheme I thougt that it's quite a
good idea to use the new tag "public_transport" because what's the
difference between bus and tram stops - there are enough stops used
by both means of transport. After following this discussion here I'm
not so shure any more because world wide there are already mapped about
66 bus stops as highway=bus_stop and it's senseless to retag all
this stops. On the contrary there are also already mapped about 57000
objects as public_transport=* (23000 nodes as stop_position and 22000
nodes and ways as platform) which of course is much less but also too
many to retag all these.

I don't know which tags are best to be used at the moment but I'm really
interested in a broadly accepted guideline for a more unified taging in
the future.

Regards, Albin

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

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

[Richard Mann]

On Mon, Dec 13, 2010 at 1:50 PM, Dominik Mahrer (Teddy)  wrote:
> Adding highway=tram_stop as the representation of the tram pole eliminates
> the inconsistency between railway=tram_stop and highway=bus_stop. What do
> you suggest for trains?

railway=platform ways/areas replace the station nodes in the ordered
list of stops

> Here in Switzerland we have up to 470m long trains (German ICE), so we have
> up to 470m long platforms with often two or more poles (or displays as a
> replacement) per platform. Does it make sense to map all poles/displays and
> to add them to the relation? Doesn't it make more sense to replace the
> pole(s)/display(s) with the platform for relation data to simplify things?

If the platform breaks into distinct sections (such as the A-E on DB
main stations or U-Z on SNCF) then there could be distinct
nodes/ways/areas for each section. You might have the whole length of
the platform as an area, with subsections (or groups of subsections)
done as ways, so you can choose which to make a member of the
relation. Which mainline service uses which platform can be a bit
variable, so you may just end up using the station node anyway.

> What do you suggest as the stop position for buses (as counterpart of
> railway=tram_stop and railway=halt)? Or would you leave this completely
> away?

I wouldn't tag it. It isn't tagged at the vast majority of bus stops,
so data users are going to have to find a way of coping with it not
being marked, and will probably ignore any that are marked. I also
wouldn't include the stop position in a relation unless it's the only
node available.

Richard

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

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

[Dominik Mahrer (Teddy)]

On 12/13/2010 01:12 PM, Richard Mann wrote:

But this doesn't work well when you have lines that loop at the ends
(fairly common with bus services), because the two relations overlap
(you have to make certain nodes members in both relations, and that
starts crossing a complexity/maintainability threshold).


I see the problem with looping lines and I know several practical 
examples. Even hafas sometimes can not handle this correctly and if then 
this is usually solved that one stop is defined as the terminal stop. 
The stops before belong to the route to the terminal stop, the others to 
the route back. So in theory you have to change the bus at the terminal 
stop, in practice this is not the case.



I think what we're edging towards is that expressing a tram stop as a
single node isn't really enough. I think the open question is how tram
stop pole nodes should be tagged, whether that affects
highway=bus_stop, and how you deal with joint bus and tram stops.


I support that one node for a 40m long tram stop isn't really enough.


My suggestion:
1) highway=bus_stop - nodes to mark bus stop poles and to be members
of bus relations (can also be used for tram relations)
2) highway=tram_stop - nodes to mark tram stop poles and to be members
of tram relations (can also be used for bus relations). Renderers may
prefer not to render these (there will generally be a
railway=tram_stop node to use instead). There are only 13 of these in
the world according to taginfo, so adoption of this tag for this
purpose is unlikely to annoy anyone too much.
3) railway=tram_stop - nodes to mark the centre of the tram stop area,
in the absence of a stop area relation. Mostly for rendering/labelling
purposes. Can be used as a member of uni-directional relations, if
setting up highway=tram_stop nodes is viewed as too complicated.


This is constructive. Thanks for that.
May I ask you some questions about that?

railway=tram_stop and railway=halt are mainly used for the stop position 
of a tram/train. highway=bus_stop is the representation of the pole 
(current schema).


Adding highway=tram_stop as the representation of the tram pole 
eliminates the inconsistency between railway=tram_stop and 
highway=bus_stop. What do you suggest for trains?


Here in Switzerland we have up to 470m long trains (German ICE), so we 
have up to 470m long platforms with often two or more poles (or displays 
as a replacement) per platform. Does it make sense to map all 
poles/displays and to add them to the relation? Doesn't it make more 
sense to replace the pole(s)/display(s) with the platform for relation 
data to simplify things?


What do you suggest as the stop position for buses (as counterpart of 
railway=tram_stop and railway=halt)? Or would you leave this completely 
away?


Regards
Teddych

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

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

[Richard Mann]

I think I may have figured out what it is that the established tags can't do.

If you've got a railway=tram with a series of nice neat (and
well-established) railway=tram_stop nodes then you can only make that
railway=tram_stop node a member of a route relation once. The oxomoa
conclusion was to have single-direction route relations.

But this doesn't work well when you have lines that loop at the ends
(fairly common with bus services), because the two relations overlap
(you have to make certain nodes members in both relations, and that
starts crossing a complexity/maintainability threshold).

I think what we're edging towards is that expressing a tram stop as a
single node isn't really enough. I think the open question is how tram
stop pole nodes should be tagged, whether that affects
highway=bus_stop, and how you deal with joint bus and tram stops.

My suggestion:
1) highway=bus_stop - nodes to mark bus stop poles and to be members
of bus relations (can also be used for tram relations)
2) highway=tram_stop - nodes to mark tram stop poles and to be members
of tram relations (can also be used for bus relations). Renderers may
prefer not to render these (there will generally be a
railway=tram_stop node to use instead). There are only 13 of these in
the world according to taginfo, so adoption of this tag for this
purpose is unlikely to annoy anyone too much.
3) railway=tram_stop - nodes to mark the centre of the tram stop area,
in the absence of a stop area relation. Mostly for rendering/labelling
purposes. Can be used as a member of uni-directional relations, if
setting up highway=tram_stop nodes is viewed as too complicated.

Richard

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

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

[Dominik Mahrer (Teddy)]

On 12/13/2010 11:52 AM, Jo wrote:

I like the proposal, the only thing I don't like about it is the massive
duplication of information in the route relations, which will make it
harder to maintain them in the long run. But I see why we would do it
that way. Maybe I'll come up with a proposal for 'proto-relations' made
up of other 'routepart'-relations some time. Those could get converted
to the massively duplicated relations automatically then.


When I understand correct you mean the same as Marl brought up on the 
talk page under "Shared Route Segments":

http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Public_Transport#Shared_Route_Segments

Regards
Teddych

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

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

[Jo]

I'm one of the people who would like to add data about Public Tranportation.
Since nobody likes to have to enter the same data several times, I can
understand the need for a 'definitive' way to map PT in such a way that all
downstream users (map rendereres, routers, etc) have the information they
need to work with. Apparently the system that you want to call established
does not completely cater for that, so people come up with improvements.

I like the proposal, the only thing I don't like about it is the massive
duplication of information in the route relations, which will make it harder
to maintain them in the long run. But I see why we would do it that way.
Maybe I'll come up with a proposal for 'proto-relations' made up of other
'routepart'-relations some time. Those could get converted to the massively
duplicated relations automatically then.

Cheers,

Jo

2010/12/13 Richard Mann 

> On Mon, Dec 13, 2010 at 8:54 AM, Dominik Mahrer (Teddy) 
> wrote:
> > You both are right, "old" is the wrong word for what I wanted to say. I
> do
> > not want to replace or deprecate highway=bus_stop. Because English is not
> my
> > first language, I catched up to consult my dictionary and I think
> > "traditional" or "conventional" would be the better word, expressing what
> I
> > wanted to say.
>
> "established" would be a better term
>
> ___
> 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 - RFC - Public Transport

[Richard Mann]

On Mon, Dec 13, 2010 at 8:54 AM, Dominik Mahrer (Teddy)  wrote:
> You both are right, "old" is the wrong word for what I wanted to say. I do
> not want to replace or deprecate highway=bus_stop. Because English is not my
> first language, I catched up to consult my dictionary and I think
> "traditional" or "conventional" would be the better word, expressing what I
> wanted to say.

"established" would be a better term

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

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

[Dominik Mahrer (Teddy)]

On 12/13/2010 02:17 AM, David Peek wrote:

Can I just add, this seems to sum up most of my feelings towards this
discussion - if it can be called that.


Yes you can, and thanks you do.


On 12 December 2010 13:35, Jerry Clough - OSM mailto:sk53_...@yahoo.co.uk>> wrote:

Odd, this, as I can immediately think of the opposite use case:
several marked bus stops, but the buses stop at random positions
over about 100m of road depending on how many other buses are
present. Individual buses serving the same routes will stop in
completely different places (sometimes two or more buses serving the
same route will be present at the stop).

Not sure about this, but it's not the main thrust of the message in my
opinion.


The main message I want to say is: There are mappers hoping for/needing 
a more exact schema to be able to reflect some cases they can not be 
mapped adequate at the moment.



Please stop referring to the current widespread practice of
highway=bus_stop mapped at the pole as 'old': in doing so you are
instantly raising the hackles of those who have spent time on the
ground mapping, rather than writing proposals on the wiki.

Agreed. "Old" implies it has been replaced or is depreciated. That is
unhelpful given to my knowledge this is the case neither in theory or
(more importantly) in practice.


You both are right, "old" is the wrong word for what I wanted to say. I 
do not want to replace or deprecate highway=bus_stop. Because English is 
not my first language, I catched up to consult my dictionary and I think 
"traditional" or "conventional" would be the better word, expressing 
what I wanted to say.



For all I know the various discussions and proposals may have some
value, but I find the initial tone off-putting, lacking respect and
overly confrontational. It is not a good route (;-)) to building
consensus. By far and away the best approach is to map a specific
area, and show how it really adds value to the map and to a range of
data consumers (not just a pet public transport router). If it
really is better than what exists you'll get people using it:
telling people they're stupid, which is the basic tone of many
messages to this list and discussions on the wiki is less likely to
be successful.


Thanks for the constructive idea to map an area with that. I will do 
this for a bus line.



As I implied further up, I don't think discussions is really an
appropriate word. Most of the messages seem to be of the "I am right,
you are wrong" variety. Hardly a good way to build consensus.


You are right, this is not the way to a consensus.

I get a lot of constructive criticism about the proposal, especially on 
the talk page. This gives me a lot of input to revise the proposal. This 
also shows me that many mappers are interested in something new/corrected.


In contrast to that I get only one message on this list: We have a 
schema, we do not want to correct the inconsistency of it and we do not 
want to have anything additional.


I do not say my proposal is the best. But I think it is time to 
extend/correct the currently used schema. Constructive criticism is 
highly welcome.


Regards,
Teddych

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

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

[David Peek]

Can I just add, this seems to sum up most of my feelings towards this
discussion - if it can be called that.

On 12 December 2010 13:35, Jerry Clough - OSM  wrote:

> Odd, this, as I can immediately think of the opposite use case: several
> marked bus stops, but the buses stop at random positions over about 100m of
> road depending on how many other buses are present. Individual buses serving
> the same routes will stop in completely different places (sometimes two or
> more buses serving the same route will be present at the stop).
>
Not sure about this, but it's not the main thrust of the message in my
opinion.

>
> Please stop referring to the current widespread practice of
> highway=bus_stop mapped at the pole as 'old': in doing so you are instantly
> raising the hackles of those who have spent time on the ground mapping,
> rather than writing proposals on the wiki.
>
Agreed. "Old" implies it has been replaced or is depreciated. That is
unhelpful given to my knowledge this is the case neither in theory or (more
importantly) in practice.

>
> For all I know the various discussions and proposals may have some value,
> but I find the initial tone off-putting, lacking respect and overly
> confrontational. It is not a good route (;-)) to building consensus. By far
> and away the best approach is to map a specific area, and show how it really
> adds value to the map and to a range of data consumers (not just a pet
> public transport router). If it really is better than what exists you'll get
> people using it: telling people they're stupid, which is the basic tone of
> many messages to this list and discussions on the wiki is less likely to be
> successful.
>
As I implied further up, I don't think discussions is really an appropriate
word. Most of the messages seem to be of the "I am right, you are wrong"
variety. Hardly a good way to build consensus.

David.


>
> --
> *From:* Dominik Mahrer (Teddy) 
> *To:* Public transport/transit/shared taxi related topics <
> talk-transit@openstreetmap.org>
> *Sent:* Fri, 10 December, 2010 15:31:50
> *Subject:* Re: [Talk-transit] Proposed Feature - RFC - Public Transport
>
>
>
> Think of a terminal bus station somewhere in the center of a city. Four bus
> lines end here. One platform of 50m. The four lines stop always at the same
> position (line 1 is first,..., line 4 is last). Only one pole for all buses.
> Where do you place your tags? Or how do you tell where to wait for bus
> number 4? At the pole that is 40m away from the stop position?
>
> It is up to you to use a new schema, or not if you dislike.
>
> I usually do not map already mapped routes/stations again, so I do not have
> to drop an original node. But when I map a new station I map stop position
> AND platform.
>
>
> On 10.12.2010 14:51, Richard Mann wrote:
> > Dominik/Teddy
> >
> > Please could you explain what situation do highway=bus_stop /
> > highway=platform / railway=platform not cover already, that requires
> > public_transport=platform to be added to the list? If you're not
> > intending to deprecate, then you're just adding complexity.
>
> highway=platform is for buses/nonrail
> railway=platform is for train/tam/rail
> What should be used if there are buses and trams at the same station?
>
> I do not plan to replace existing tags with
> highway/railway=public_transport, but I will tag unmapped platforms with
> public_transport=platform. If so this can be done with a bot.
>
> highway=bus_stop is used different. Sometimes as stop position, more often
> as platform/pole. See
> http://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dbus_stop#Results_2010-10-27
> The meaning of how highway=bus_stop should be used differ. It can not be
> replaced easily with a new public_transport tag.
>
>
> > Also I think you need to make a clearer case for
> > public_transport=stopping_position. You claim it's needed for routing
> > - but routers currently seem to manage without.
> >
> > The existing tags can cover the simpler situations (starting with a
> > single node, then two or three nodes, then the two nodes become
> > platform ways/areas), and still used for the more-complicated
> > situations (>2 platforms / bus_stops), just grouped into a relation
> > (and at which point you might well drop the original single node).
> >
> > Richard
> >
> > ___
> > 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 - RFC - Public Transport

[Jerry Clough - OSM]

Odd, this, as I can immediately think of the opposite use case: several marked 
bus stops, but the buses stop at random positions over about 100m of road 
depending on how many other buses are present. Individual buses serving the 
same 
routes will stop in completely different places (sometimes two or more buses 
serving the same route will be present at the stop).

Please stop referring to the current widespread practice of highway=bus_stop 
mapped at the pole as 'old': in doing so you are instantly raising the hackles 
of those who have spent time on the ground mapping, rather than writing 
proposals on the wiki. 


For all I know the various discussions and proposals may have some value, but I 
find the initial tone off-putting, lacking respect and overly confrontational. 
It is not a good route (;-)) to building consensus. By far and away the best 
approach is to map a specific area, and show how it really adds value to the 
map 
and to a range of data consumers (not just a pet public transport router). If 
it 
really is better than what exists you'll get people using it: telling people 
they're stupid, which is the basic tone of many messages to this list and 
discussions on the wiki is less likely to be successful.





From: Dominik Mahrer (Teddy) 
To: Public transport/transit/shared taxi related topics 

Sent: Fri, 10 December, 2010 15:31:50
Subject: Re: [Talk-transit] Proposed Feature - RFC - Public Transport



Think of a terminal bus station somewhere in the center of a city. Four bus 
lines end here. One platform of 50m. The four lines stop always at the same 
position (line 1 is first,..., line 4 is last). Only one pole for all buses. 
Where do you place your tags? Or how do you tell where to wait for bus number 
4? 
At the pole that is 40m away from the stop position?

It is up to you to use a new schema, or not if you dislike.

I usually do not map already mapped routes/stations again, so I do not have to 
drop an original node. But when I map a new station I map stop position AND 
platform.


On 10.12.2010 14:51, Richard Mann wrote:
> Dominik/Teddy
> 
> Please could you explain what situation do highway=bus_stop /
> highway=platform / railway=platform not cover already, that requires
> public_transport=platform to be added to the list? If you're not
> intending to deprecate, then you're just adding complexity.

highway=platform is for buses/nonrail
railway=platform is for train/tam/rail
What should be used if there are buses and trams at the same station?

I do not plan to replace existing tags with highway/railway=public_transport, 
but I will tag unmapped platforms with public_transport=platform. If so this 
can 
be done with a bot.

highway=bus_stop is used different. Sometimes as stop position, more often as 
platform/pole. See 
http://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dbus_stop#Results_2010-10-27

The meaning of how highway=bus_stop should be used differ. It can not be 
replaced easily with a new public_transport tag.


> Also I think you need to make a clearer case for
> public_transport=stopping_position. You claim it's needed for routing
> - but routers currently seem to manage without.
> 
> The existing tags can cover the simpler situations (starting with a
> single node, then two or three nodes, then the two nodes become
> platform ways/areas), and still used for the more-complicated
> situations (>2 platforms / bus_stops), just grouped into a relation
> (and at which point you might well drop the original single node).
> 
> Richard
> 
> ___
> 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



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

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

[Dominik Mahrer (Teddy)]

On 12/11/2010 03:32 PM, Michał Borsuk wrote:


And by the way: What physical thing is represented by railway=tram_stop?

I don't deal with trams.


So you have a very limited view of Public Transport.


Whenever I criticize Oxomoa I hear the same silly argument: "but in my
Siedlung there's a bus that does such a complicated thing...". So what?
Who cares?


The mapper cares. In his eyes it is not silly. It is the willing of 
mapping it as correct as possible. If you do not want to care about 
complicated things, this does not mean others do not want too.



I am not sure if I know what "the old system" is. Maybe we actually
criticize the same thing. I'd do it this way: highway:bus_stop for each
bus stop, and then the bus stops are added to each line (relation) that
stops there. Nothing more is needed from the point of view of even rich
future applications in OSM. There is the info where the bus stop is,
there's the line, if we ever want to link OSM with timetables (as I am
planning), then we have everything we need.


I do it the same way. The differences are the details.


Would you be so kind and withdraw from the accusation that the reason
behind the resistance is the unwillingness to convert the existing system?


You do not deal with trams, you have written. So you have a limited view 
and can not see the inconsistency in the schema. And you can not see the 
need for changing the schema.


Regards
Teddych

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

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

[Sam Vekemans]

cool,
I'm just blogging this for later, the Oxoma Schema sounds interesting
to investigate further.
cheers,
sam

On 12/8/10, Michael von Glasow  wrote:
> On 12/08/2010 08:44 PM, Dominik Mahrer (Teddy) wrote:
>> Hello
>>
>> Yes, the Public Transport proposal is basically based on Oxomoa, but
>> in some details different.
>>
>> unified stoparea would "redefine" highway=bus_stop from beside the way
>> to on the way. I'm quite sure this would reject the proposal in a vote.
>>
>> unified stoparea and public transport can and do exist beside each
>> other. But you are right, it does not make sense to approve both
>> proposals.
>>
>> I do not care about which of the two proposals will be approved. But I
>> think it is time to get a more exact schema approved then the
>> fuzzy/non-existing schema (A railway station of 400m length and 20
>> platforms or a bus stop for 3 buses per direction of 50m length is
>> reduced to one node) we have now.
>>
>> Regards
>> Teddych
>>
>>
>> On 12/08/2010 06:02 PM, Oleksandr Vlasov wrote:
>>> Dominik Mahrer (Teddy  teddy.ch>  writes:
>>>
 I want to invite everyone to comment the (in central europe) already
 widely used new Public Transport Schema:

 http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport
>>>
> Good work - a few months ago I started mapping the public transportation
> network in Milan and started out by looking around how other cities were
> doing it. My aim was to use a tagging scheme which is easy to
> understand/learn, minimizes data entry effort (it makes a difference
> whether mapping a single line takes half an hour or two hours) and is
> supported by the common renderers.
>
> The results of the research I did back then is at:
>
> http://wiki.openstreetmap.org/wiki/Milano/Trasporti_pubblici
>
> (unfortunately it is in Italian only, but maybe non-Italian speakers can
> still get some information on tagging out of it).
>
> The differentiation between stop_position and platform elegantly solves
> the dilemma on the position of the node (on the way or next to it). For
> routing applications it is definitely more convenient if the node is
> part of the way. However, two stops located on either side of the road
> would thus collapse into one point and it would no longer be possible to
> tag explicitly one or the other. (For example: here in Milan each stop,
> i.e. pole, has a unique number, which I tag as ref. If there is a double
> tram stop, there is a single node but two numbers. Using only this
> single node, there is no easy way to tell which number belongs to which
> side of the road. Or another example: what if there is a shelter on one
> side of the road, but not on the other?)
>
> In the new proposal I am missing some details on how to build relations:
>
> 1. Should the outward and return trip be represented as two separate
> relations, as a single relation or is that up to the mapper?
>
> I would favor separate relations: The ways used may be different (a road
> with two physically separated lanes, or a labyrinth of one-way streets
> in a European city), and with one relation per direction it is easy to
> sort the ways and detect holes in the route.
>
> 2. Which members should the relation contain, and in which order?
>
> My approach to this: all way segments, tagged as role=forward or
> role=backward. The way segments should be sorted; where a bus passes the
> same way twice, it should be added twice - this allows for easy
> verification if the route is complete. Additionally the relation should
> contain all stops, which must also be sorted (some rendering
> applications, e.g. sketch-route, need the correct order of all stops).
> Stops should not be mangled with the ways - either insert ways first,
> then stops, or vice versa. Again, this is for better overview and makes
> the process less error-prone.
>
> 3. Which data primitive should be added for stops?
>
> My suggestion: the one which best identifies the actual position at
> which the vehicle stops (and passengers board). This can be either the
> platform, the stop position or the stop area relation. Given that the
> stop position is always a node while the platform may be a node or an
> area, the stop position is probably the less problematic one to use
> (some renderers already support the combination of role=stop,
> public_transport=stop_position). I would recommend against adding the
> stop group relation as stop, since this does not provide sufficient
> information as to where passengers can really board the vehicle (stop
> groups can be huge).
>
> 4. How are line variants mapped?
>
> One relation for each variant? Or one relation for the common part and
> one for each alternative? Sincerely, this is where I'm myself at a loss.
> Imagine a bus line with the following stops: A - B - C - D - E1 - F1 - G
> - H - I - K.
>
> Now as for the variants. It's a made-up example, but there are lines in
> Milan which are hardly better:
> - Stops E1 and F1 are in a street which 

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

[Michał Borsuk]

On 11 December 2010 15:08, Dominik Mahrer (Teddy)  wrote:

> On 12/11/2010 09:26 AM, Michał Borsuk wrote:
>
>>Many city and/or network public transport wiki pages in central
>>europe recommend to use highway=bus_stop _on_ the way
>>
>>
>> And they are wrong. Because according to OSM's principles, the object
>> should be placed where it physically exists.
>>
>
> Depending of what highway=bus_stop should represent.
> If it represents the pole/platform they are wrong.
> If it represents the yellow zigzag line on the street they are right.
>

How often is there just a pole? Quite often. Does the existence of other
types of bus stops justify the addition of a new tag? Yes, if it's not too
complicated, and does not break compatibility. The idea with a platform does
not match either.

I do use platforms, but at larger termini and transfer points, where there
are indeed more than two platforms, and it's important to have them
labelled. On a street with one bus stop in each direction it is not possible
to confuse anything.


>
> And by the way: What physical thing is represented by railway=tram_stop?


I don't deal with trams.

>
>
> I would like to approve a tagging schema that is clearly defined.
>>
>> ..but which is not against the principles of OSM.
>>
>
> What is against the principles of OSM in public transport proposal?


Points on the way do not represent bus stops' location.


>
>
>  Imagine that you're not German.
>>
>
> I do not have to imagine this, I am not German.
>
>
> Your beginners version:
>
> highway=bus_stop beside the way
> highway=platform beside the way
>

One of those, of course. Not both.

>
> Oxomoas beginner version:
> public_transport=stop_position on the way
> public_transport=platform beside the way
>

Too complicated, too much work:
1) it is not compatible with what's being used
2) platform is not a node, but a line, requires more work

What does it really give? How is it better?


>
> Where is the difference in effort?
>

Explained above.


> Whatever proposal/schema you take (old/unified/oxomoa/stop place): Nothing
> of the tags is a *must*. Everything is optional.


The point is to have a sensible system that can be shown to beginners. A
Wiki page with a clear system, that is easy to grasp, and not the usual
bullshit about multiple-level B-Tree complicated relations.


> You can invest as much effort in tagging you want. But the upper limit of
> (unified/oxomoa/stop place) is much higher then in the old, very limited
> schema.
>

My problem is the lower level, not the upper level. This is the problem with
oxomoa: that  by doing complicated things well, it messes up easy things.
Oxomoa is centered around the quality of itself, while a good system would
be centered around ease of use for the most frequently used tags, and then
it would bother with crazy lines that loop somewhere in the forest.

Whenever I criticize Oxomoa I hear the same silly argument: "but in my
Siedlung there's a bus that does such a complicated thing...". So what? Who
cares? This is OSM, not a competitor to hafas. We show lines where they are,
and not how they go. (If you wonder why, I can elaborate on the difficulty
of storing data in hafas, I know it from the inside. It would be practically
impossible as of today to transfer this data completely to OSM. And
useless).


>

>
>  There are as many bus stops near the road as there are out there in the
>> field, because the resolution of the map is so detailed, that placing
>> one dot on the road is not enough. Moreover, as far as I remember, North
>> American system (contrary to Hafas), gives each physical stop place a
>> different index number.
>>
>
> How do you want to map this with the old schema? You do not have a stop
> place/stop position tag.


I am not sure if I know what "the old system" is. Maybe we actually
criticize the same thing. I'd do it this way: highway:bus_stop for each bus
stop, and then the bus stops are added to each line (relation) that stops
there. Nothing more is needed from the point of view of even rich future
applications in OSM. There is the info where the bus stop is, there's the
line, if we ever want to link OSM with timetables (as I am planning), then
we have everything we need.


>
>
> The platform definitely is beside the way
>>
>> Where? Behind the corner?  On the left? On the right? No, this is not
>> detailed enough.
>>
>
> As you said: There where it physically exists.


Yes, my misunderstanding.

>
>
> My understanding for those they have put hundreds of tags on/beside
>>the way. They do not want to move them (in which direction ever).
>>
>> Do you have any other personal accusations towards other mappers?
>>
>
> This is not an accusation, this is the only plausible reason I heard until
> now for not changing the old schema.


Would you be so kind and withdraw from the accusation that the reason behind
the resistance is the unwillingness to convert the existing system?



-- 
Best regards, mit freundlic

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

[Dominik Mahrer (Teddy)]

On 12/11/2010 09:26 AM, Michał Borsuk wrote:

Many city and/or network public transport wiki pages in central
europe recommend to use highway=bus_stop _on_ the way


And they are wrong. Because according to OSM's principles, the object
should be placed where it physically exists.


Depending of what highway=bus_stop should represent.
If it represents the pole/platform they are wrong.
If it represents the yellow zigzag line on the street they are right.

And by the way: What physical thing is represented by railway=tram_stop?


I would like to approve a tagging schema that is clearly defined.

..but which is not against the principles of OSM.


What is against the principles of OSM in public transport proposal?


Imagine that you're not German.


I do not have to imagine this, I am not German.

> Do you see how unnecessarily complicated

Oxomoa's plan is? It covers very, very small details (read: they rarely
occur), at the some time forcing much more work on simple (most often
occurring) situations.


Your beginners version:
highway=bus_stop beside the way
highway=platform beside the way

Oxomoas beginner version:
public_transport=stop_position on the way
public_transport=platform beside the way

Where is the difference in effort?

If this is still too much effort, you can leave away one of them. I 
guess you do. Sometimes I do either.


Whatever proposal/schema you take (old/unified/oxomoa/stop place): 
Nothing of the tags is a *must*. Everything is optional. You can invest 
as much effort in tagging you want. But the upper limit of 
(unified/oxomoa/stop place) is much higher then in the old, very limited 
schema.



Au contraire, my fellow mapper, and it this discussion was *closed*.


Two years ago or so. I opened it again in 2010, because the underlaying 
basics changed since then.



There are as many bus stops near the road as there are out there in the
field, because the resolution of the map is so detailed, that placing
one dot on the road is not enough. Moreover, as far as I remember, North
American system (contrary to Hafas), gives each physical stop place a
different index number.


How do you want to map this with the old schema? You do not have a stop 
place/stop position tag.



The platform definitely is beside the way

Where? Behind the corner?  On the left? On the right? No, this is not
detailed enough.


As you said: There where it physically exists.


My understanding for those they have put hundreds of tags on/beside
the way. They do not want to move them (in which direction ever).

Do you have any other personal accusations towards other mappers?


This is not an accusation, this is the only plausible reason I heard 
until now for not changing the old schema.


Teddych

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

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

[Michał Borsuk]

On 10 December 2010 22:12, Dominik Mahrer (Teddy)  wrote:

> On 12/10/2010 08:55 PM, Richard Mann wrote:
>
>  I would agree that on-highway highway=bus_stop should be phased out
>> (is anyone saying they should be retained?). I think they're a
>> hangover from the time before we realised that tagging the pole was a
>> better approach. In the mean time, I don't think it causes any major
>> problem (it just isn't as clear as tagging the pole).
>>
>
> Many city and/or network public transport wiki pages in central europe
> recommend to use highway=bus_stop _on_ the way


And they are wrong. Because according to OSM's principles, the object should
be placed where it physically exists.



> Even on the wiki page highway=bus_stop is not clearly defined as _beside_
> the way.
>

Then we have to do it.

>
> highway=bus_stop is a fuzzy tag.


I see it very clearly.


I would like to approve a tagging schema that is clearly defined.


..but which is not against the principles of OSM.


> Doing this with new tags is portably the easiest way.


Not sure about that. Backwards compatibility is very important. Approving a
bunch of tags from people who created such a system as oxomoa is not my
priority.

I am also waiting impatiently for a clear system, but I am not in a hurry to
approve crap just because we're tired of the old system. The new one could
be a bigger mess than the old one. If you like oxomoa, then you're missing
the understanding how unnecessarily complicated it is, and difficult  for
beginners.

OSM is not a castle on a high mountain, we have to take care of beginners'
learning curve.


> Redefining highway=bus_stop on or beside the way seams to be nearly
> impossible. Again: Have a look at the German talk page.
>

Why? Please, take a moment and look at German solutions from a side. Imagine
that you're not German. Do you see how unnecessarily complicated Oxomoa's
plan is? It covers very, very small details (read: they rarely occur), at
the some time forcing much more work on simple (most often occurring)
situations.

Sorry, but this is not efficient.


> Why is highway=bus_stop recommended to use _on_ the way? Because it does
> not make sense to have two tags _beside_ the way (highway=bus_stop and
> highway=platform).


Au contraire, my fellow mapper, and it this discussion was *closed*. There
are as many bus stops near the road as there are out there in the field,
because the resolution of the map is so detailed, that placing one dot on
the road is not enough. Moreover, as far as I remember, North American
system (contrary to Hafas), gives each physical stop place a different index
number.


> The platform definitely is beside the way
>

Where? Behind the corner?  On the left? On the right? No, this is not
detailed enough.

>
> My understanding for those they have put hundreds of tags on/beside the
> way. They do not want to move them (in which direction ever).
>

Do you have any other personal accusations towards other mappers?




-- 
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 - RFC - Public Transport

[Michał Borsuk]

On 11 December 2010 00:39, Richard Mann
wrote:

> On Fri, Dec 10, 2010 at 9:12 PM, Dominik Mahrer (Teddy) 
> wrote:
> > Especially see the German talk page. I would like to approve a tagging
> > schema that is clearly defined. Doing this with new tags is portably the
> > easiest way. Redefining highway=bus_stop on or beside the way seams to be
> > nearly impossible. Again: Have a look at the German talk page.
>
> The English-language discussion appears to have long reached a
> consensus (except for you).
>
> My German is not sufficient to follow the discussion, but clearly
> there are more people arguing each way, and shouting about it.
>
> If some people wish to use highway=bus_stop on the road, with
> highway=platform alongside, that can perfectly well be deciphered by
> software, and clearly documented as an alternative approach, and tag
> stats displayed to show which is dominant where. It does not need a
> public_transport key to confuse matters further.
>

Most of all, 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 - RFC - Public Transport

[Dominik Mahrer (Teddy)]

On 12/11/2010 12:39 AM, Richard Mann wrote:


The English-language discussion appears to have long reached a
consensus (except for you).


The decision to place highway=bus_stop beside the road has been made 
before highway=platform existed. Without highway=platform I also would 
vote for beside the way.


Then highway=platform has bin introduced. Beside the way. Since two and 
a have year we have two tags for a bus stop beside the way. At the same 
position. This definitely does not make sense. Or does it for you?


The decision to place highway=bus_stop was based on the fact that one 
should be able to see on maps in which direction a bus runs. The need 
for highway=bus_stop beside the way has been replaced with the approved 
feature highway=platform.


Could you give me an argument why highway=bus_stop should be beside the way?

To place highway=bus_stop beside the way is inconsistent and incomplete.


If some people wish to use highway=bus_stop on the road, with
highway=platform alongside, that can perfectly well be deciphered by
software, and clearly documented as an alternative approach,


This is the point where we are in the wiki now. And this is very close 
to unified stoparea.



It does not need a
public_transport key to confuse matters further.


If we define highway=bus_stop *on* the way, we do not need another tag, 
you are right.


Regards
Teddych

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

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

[Richard Mann]

On Fri, Dec 10, 2010 at 9:12 PM, Dominik Mahrer (Teddy)  wrote:
> Especially see the German talk page. I would like to approve a tagging
> schema that is clearly defined. Doing this with new tags is portably the
> easiest way. Redefining highway=bus_stop on or beside the way seams to be
> nearly impossible. Again: Have a look at the German talk page.

The English-language discussion appears to have long reached a
consensus (except for you).

My German is not sufficient to follow the discussion, but clearly
there are more people arguing each way, and shouting about it.

If some people wish to use highway=bus_stop on the road, with
highway=platform alongside, that can perfectly well be deciphered by
software, and clearly documented as an alternative approach, and tag
stats displayed to show which is dominant where. It does not need a
public_transport key to confuse matters further.

Richard

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

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

[Dominik Mahrer (Teddy)]

On 12/10/2010 08:55 PM, Richard Mann wrote:


I would agree that on-highway highway=bus_stop should be phased out
(is anyone saying they should be retained?). I think they're a
hangover from the time before we realised that tagging the pole was a
better approach. In the mean time, I don't think it causes any major
problem (it just isn't as clear as tagging the pole).


Many city and/or network public transport wiki pages in central europe 
recommend to use highway=bus_stop _on_ the way (in coexistence with 
Oxomoa and unified stoparea and public transport proposal). So 
highway=bus_stop on the way does not get phased out.


Even on the wiki page highway=bus_stop is not clearly defined as 
_beside_ the way.


highway=bus_stop is a fuzzy tag. I do not like this war around this tag. 
Especially see the German talk page. I would like to approve a tagging 
schema that is clearly defined. Doing this with new tags is portably the 
easiest way. Redefining highway=bus_stop on or beside the way seams to 
be nearly impossible. Again: Have a look at the German talk page.


Why is highway=bus_stop recommended to use _on_ the way? Because it does 
not make sense to have two tags _beside_ the way (highway=bus_stop and 
highway=platform). The platform definitely is beside the way (It is an 
approved feature and I never heard other voices). highway=bus_stop _on_ 
the way would be in consistence with railway=tram_stop. And it would be 
a stop position. And it would fit unified stoparea.


My understanding for those they have put hundreds of tags on/beside the 
way. They do not want to move them (in which direction ever).


Regards
Teddych

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

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

[Richard Mann]

On Fri, Dec 10, 2010 at 7:17 PM, Michał Borsuk  wrote:
> If so, then may I ask if we really need this role? Could you provide an
> example, as I may not completely understand the details?

I was thinking about a relation like this:

http://www.openstreetmap.org/browse/relation/143147

(This is unordered and doesn't have stops in it yet, unless someone
else has done it).

The bits on the loops at each end are legitimate for travelling in
both forward and backward directions, and it wouldn't obviously be any
clearer if the relation got separated into two directions.

I'm not sure it needs roles on the nodes at all - an ordered list of
nodes would probably give a data user all they need, and they could
perfectly well treat the list as circular rather than linear to cover
loop situations.

Richard

Richard

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

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

[Richard Mann]

On Fri, Dec 10, 2010 at 3:31 PM, Dominik Mahrer (Teddy)  wrote:
> Think of a terminal bus station somewhere in the center of a city. Four bus
> lines end here. One platform of 50m. The four lines stop always at the same
> position (line 1 is first,..., line 4 is last). Only one pole for all buses.
> Where do you place your tags? Or how do you tell where to wait for bus
> number 4? At the pole that is 40m away from the stop position?
>

That'd be four bus stops in the NaPTAN system, the three "invisible"
ones being what they call customary stops (these are far more common
in rural areas). I wouldn't recommend the passengers go to the
stopping position (not unless I wanted them to be run over).

> highway=platform is for buses/nonrail
> railway=platform is for train/tam/rail
> What should be used if there are buses and trams at the same station?

Whichever feels right. I'd probably use highway=platform if you can
walk across the tracks at the platform, railway=platform if you can't.
Does it matter?

> highway=bus_stop is used different. Sometimes as stop position, more often
> as platform/pole. See
> http://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dbus_stop#Results_2010-10-27
> The meaning of how highway=bus_stop should be used differ. It can not be
> replaced easily with a new public_transport tag.

I would agree that on-highway highway=bus_stop should be phased out
(is anyone saying they should be retained?). I think they're a
hangover from the time before we realised that tagging the pole was a
better approach. In the mean time, I don't think it causes any major
problem (it just isn't as clear as tagging the pole).

Richard

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

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

[Michał Borsuk]

On 10 December 2010 12:31, Richard Mann
wrote:

>
> I was thinking that role=loop on the loop stops might be one way to do
> it, with role=terminus for single-point route ends (and as a notional
> terminus on a loop)?
>

I think we're talking about two slightly different things. In my area there
are a lot of lines which *end* with a loop (instead of a terminal where the
direction switches). I think you're referring to a completely circular line,
like the yellow line in London, or what is often in Eastern Europe called
"line 0".

If so, then may I ask if we really need this role? Could you provide an
example, as I may not completely understand the details?


-- 
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 - RFC - Public Transport

[Dominik Mahrer (Teddy)]

Think of a terminal bus station somewhere in the center of a city. Four 
bus lines end here. One platform of 50m. The four lines stop always at 
the same position (line 1 is first,..., line 4 is last). Only one pole 
for all buses. Where do you place your tags? Or how do you tell where to 
wait for bus number 4? At the pole that is 40m away from the stop position?


It is up to you to use a new schema, or not if you dislike.

I usually do not map already mapped routes/stations again, so I do not 
have to drop an original node. But when I map a new station I map stop 
position AND platform.



On 10.12.2010 14:51, Richard Mann wrote:

Dominik/Teddy

Please could you explain what situation do highway=bus_stop /
highway=platform / railway=platform not cover already, that requires
public_transport=platform to be added to the list? If you're not
intending to deprecate, then you're just adding complexity.


highway=platform is for buses/nonrail
railway=platform is for train/tam/rail
What should be used if there are buses and trams at the same station?

I do not plan to replace existing tags with 
highway/railway=public_transport, but I will tag unmapped platforms with 
public_transport=platform. If so this can be done with a bot.


highway=bus_stop is used different. Sometimes as stop position, more 
often as platform/pole. See 
http://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dbus_stop#Results_2010-10-27
The meaning of how highway=bus_stop should be used differ. It can not be 
replaced easily with a new public_transport tag.




Also I think you need to make a clearer case for
public_transport=stopping_position. You claim it's needed for routing
- but routers currently seem to manage without.

The existing tags can cover the simpler situations (starting with a
single node, then two or three nodes, then the two nodes become
platform ways/areas), and still used for the more-complicated
situations (>2 platforms / bus_stops), just grouped into a relation
(and at which point you might well drop the original single node).

Richard

___
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 - RFC - Public Transport

[Richard Mann]

Dominik/Teddy

Please could you explain what situation do highway=bus_stop /
highway=platform / railway=platform not cover already, that requires
public_transport=platform to be added to the list? If you're not
intending to deprecate, then you're just adding complexity.

Also I think you need to make a clearer case for
public_transport=stopping_position. You claim it's needed for routing
- but routers currently seem to manage without.

The existing tags can cover the simpler situations (starting with a
single node, then two or three nodes, then the two nodes become
platform ways/areas), and still used for the more-complicated
situations (>2 platforms / bus_stops), just grouped into a relation
(and at which point you might well drop the original single node).

Richard

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

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

[Dominik Mahrer (Teddy)]

Hi Richard


There appears to be a degree of consensus on using one type=route
relation per direction (though it's not entirely clear whether this is
really necessary), not worrying overmuch about telescopic routes or
occasional diversions, and (groaning but) creating separate relations
for routes that branch. Some of the work to implement this is waiting
on Potlatch2 (which will have rather better relation support). I think
the biggest uncertainty is how you handle loops at the end of a route
- do you have overlapping single-direction relations, pick an
abritrary position to change direction, or stick with having both
directions in the same relation and let the data user worry about it.


This sounds more to try to find a consensus then all you have written 
before.


It's up to the mapper how much time he/she wants to spend in mapping 
bus/tram routes. The more time he/she has the more exact the result will be.


One simple relation per direction is not more work then only one 
relation for both directions with complicated roles.


If you do not want (or your software can't) create a master relation, 
just leave it away.


Reflecting very complicated variants should be possible for interested 
power mappers. This is what Oxomoa already wanted to cover nearly two 
years ago and several mappers are already using.


Regards
Teddych

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

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

[Dominik Mahrer (Teddy)]

Hi Richard


The only inconsistency is that "tram_stop" generally refers to a
stopping place and "bus_stop" generally refers to a quay. This is not
enough reason to propose changing half a million established tags.
Sometimes trams stop at bus_stops and sometimes buses stop at
platforms, but that's not a reason to change the tags to something
more generic.


It does not make sense to change more then half a million tags.
I did not write this, I do not mean that.
And the proposal does not conflict with highway=bus_stop or another tag 
you and many others are using the way you explained.


The proposal is NOT for redefining or replacing highway=bus_stop!!! 
(Other proposals do.)


Your way of tagging is the "old" way. Historically crown and widely 
used/accepted. It is NOT deprecated or obsolete.


But keep in mind that there are more and more mappers they want a more 
exact schema then you are using. We should give them ONE approved 
possibility how they can do it. Otherwise everyone does it different 
(like today). So we should find a consensus how this more exact schema 
should lock like.


To say we do not need anything else we have (this is how I read your 
text) is not a consensus.


Teddych

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

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

[Richard Mann]

On Fri, Dec 10, 2010 at 11:11 AM, Michał Borsuk  wrote:
> On 12/10/2010 11:20 AM, Richard Mann wrote:
>>
>> I think
>> the biggest uncertainty is how you handle loops at the end of a route
>> - do you have overlapping single-direction relations, pick an
>> abritrary position to change direction, or stick with having both
>> directions in the same relation and let the data user worry about it.
>>
>>
>
> I do it this way: end points from the timetable (Kursbuch), so the "forward"
> role goes to the last stop indicated in the timetable, and the "backward"
> role goes forth.

I was thinking that role=loop on the loop stops might be one way to do
it, with role=terminus for single-point route ends (and as a notional
terminus on a loop)? This might also avoid the need for
role=forward/backward on all the other stops.

Richard

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

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

[Michał Borsuk]

On 12/10/2010 11:20 AM, Richard Mann wrote:

I think
the biggest uncertainty is how you handle loops at the end of a route
- do you have overlapping single-direction relations, pick an
abritrary position to change direction, or stick with having both
directions in the same relation and let the data user worry about it.

   
I do it this way: end points from the timetable (Kursbuch), so the 
"forward" role goes to the last stop indicated in the timetable, and the 
"backward" role goes forth.

Richard
   


--
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 - RFC - Public Transport

[Richard Mann]

On Fri, Dec 10, 2010 at 5:29 AM, Dominik Mahrer (Teddy)  wrote:
> On 12/10/2010 01:45 AM, Richard Mann wrote:
>>
>> highway=bus_stop on a node next to a road
>> railway=tram_stop on a node on railway=tram
>> railway=platform on a node or way or area next to the tram tracks
>
> This is how you are using it.
> It is inconsistent.
> It is incomplete.
> It is historic.

I don't think you are going to get consensus with that sort of
aggressive language (or indeed with any complex proposal that isn't
graciously compatible with existing large-scale uses).

The only inconsistency is that "tram_stop" generally refers to a
stopping place and "bus_stop" generally refers to a quay. This is not
enough reason to propose changing half a million established tags.
Sometimes trams stop at bus_stops and sometimes buses stop at
platforms, but that's not a reason to change the tags to something
more generic.

Relations for stop-groups are generally supported, but data-users need
to be able to bundle adjacent stops with the same name for themselves,
not rely on the presence of a relation.

There appears to be a degree of consensus on using one type=route
relation per direction (though it's not entirely clear whether this is
really necessary), not worrying overmuch about telescopic routes or
occasional diversions, and (groaning but) creating separate relations
for routes that branch. Some of the work to implement this is waiting
on Potlatch2 (which will have rather better relation support). I think
the biggest uncertainty is how you handle loops at the end of a route
- do you have overlapping single-direction relations, pick an
abritrary position to change direction, or stick with having both
directions in the same relation and let the data user worry about it.

Richard

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

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

[Michał Borsuk]

On 9 December 2010 23:40, Michael von Glasow  wrote:

>  On 12/09/2010 01:31 PM, Michał Borsuk wrote:
>
>
>
>
> There is the issue of "multiple relations per line" in oxomoa, which in my
> opinion is a total misfit. There are "roles" in relations, and different
> variants of a route can be put there.
>
> My previous post to this list contains an example of what you may encounter
> in real life. The case of a telescope line may be representable in a single
> relation, but I really do not know how to express in a single relation that
> some courses skip part of the route (the market example) and follow another
> (including some different stops)
>

IMHO You don't. OSM shows where the line passes regularly, and not how it
goes in detail. The point of bus lines on OSM is not to replace timetables
and programs like Hafas, but to show people where they can take a bus, which
passes regularly (whatever that means). For this purpose I personally do not
map for example schoolbus lines (even though legally they are open to all
passengers).

For me personally it is important to see if there is a bus line in the area,
and how's the bus stop called. Then I connect to hafas by my telephone and
find the timetable. It works in practice.


> If you have a decent way of expressing that in a single relation, please do
> share it here - I'd happily adopt that if only someone suggests a
> satisfactory solution to the issue.
>

In case of a telescope line there is no problem - simply ignore the fact
that some runs (Kurse? in German) end earlier. In case of a line which
alternates between two different paths, my idea is to add "a" and "b" to the
roles (or "forward_a" and "forward_b", but again, this is not so crucial,
because for the user the info is clear: there's a bus line. The user doesn't
care that the same bus line goes another path, s/he sees this line. If the
bus passes some place less often than every 2 hours, then I don't put the
line on OSM at all, because what's the use?


> Two, or more, relations per line is not only "illegal" (clearly against the
> principle, as it was stated by its creators), but also hell to administer,
> and JOSM-limited.
>
> Are you referring to the master relation which contains the relations for
> the route variants? In fact I don't use them in Milan
>

Yes.


> (in Munich it seems common practice and I follow that), and as of today
> renderers seem to be fine even without it. Take the following example:
>
> http://78.46.81.38/api/sketch-line?network=SITAM&ref=69&style=padua
>
> This line is made up of four relations (two variants with one relation for
> each direction),
>

That's not much different from what I deal with, and as of today I ignored
different variants out of the lack of a sensible solution (oxomoa not being
one), and the world has not collapsed. The lines I mapped appear on
öpnvkarte.de , the only problem being
http://78.46.81.38/service
doesn't work. But again, I am almost alone in the area, and I have
more important issues to address, such as adding bus stops to relations.


> and OSM Server Side Script manages to put them together based on their ref
> and network tags.
>

And this is the way to go: leave the mess to be cleaned by scripts, not
humans. The author of önpvkarte managed to get all the data and make sense
of it. It should be middleware, not humans, which would deal with details
such as telescope or spoon lines (with a loop instead of a terminus).


>
> Editor support, as Dominik writes, I would not overestimate. JOSM may be
> complex, but maintaining public transportation routes is complex on itself
>

This is not a reason to limit it to one editor.


>  Potlatch and Merkaartor account for 2/3 edits together.
>
> Now this does surprise me - I would have expected a higher "market share"
> for JOSM.
>

Really? Let's see:
* ugly interface
* more difficult that the others
* written in Java, which requires >100MB installation

None of the above bother me, but I can see why some people won't try it.
Remember, mappers are not always geeks. We are.


> If you have the figures at hand, it would be interesting to find out how
> many of the people who edit public transportation data use JOSM vs. other
> editors.
>

I can tell you what I do in JOSM: adding lines to a mother relation. All
other things are done in  Potlatch. I don't even know how to import gpx to
JOSM.


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

What is important for me is that Potlatch does well with mapping bus lines.
It doesn't even need any extensions for it.


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

Michał Borsuk
___
Talk-transit

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

[Dominik Mahrer (Teddy)]

On 12/09/2010 11:40 PM, Michael von Glasow wrote:


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


Nice tool. But usability can be improved (GUI is missing).

Regards
Teddych

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

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

[Dominik Mahrer (Teddy)]

On 12/10/2010 12:08 AM, Michael von Glasow wrote:


3. Which data primitive should be added for stops?


Stop positions AND platform. Stop position is important for the route
itself, the platform is important for pedestrian routing.

Fine for me, though it does mean some more effort to enter data. Except
that we might consider adding the platform right after the stop it
belongs to - that would make it easier to verify that both are there.


You are right. I have to think about.


As far as I know, this is accurately defined: it is relative to the
tagged way direction, which may or may correspond to the route
direction. But I, too, realize that this part confuses people. If we
agree that ways must always be sorted, each way sharing an end node with
the ones before and after (which I strongly recommend), then we can
extract this information from the route itself without tagging it
explicitly.


It is defined, yes. But not everyone reads the part, and even if he/she 
read it and does it correctly: Another mapper could reverse the way for 
some reason and the relation is broken.



Practical:

I map the variant with the most stops (in your example twice A B1 E1
K. In JOSM you can easily copy a relation and change what is
different. So to handle your 8 variants should not take 8 times
mapping one variant.

That works when you have the entire route from beginning to end. But
some of us (I do) often follow just a part of the way and enter that,
hoping to complete it at a later occasion (or someone else doing it).
And once you have two partially-complete relations, updating them both
together mostly means editing each relation manually.


This is correct, but this is not a problem of partially or not. This is 
brought up by a route for each variant.

But I hope your routes in Milan are not updated every two weeks...

Regards
Teddych

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

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

[Dominik Mahrer (Teddy)]

On 12/10/2010 01:45 AM, Richard Mann wrote:

highway=bus_stop on a node next to a road
railway=tram_stop on a node on railway=tram
railway=platform on a node or way or area next to the tram tracks


This is how you are using it.
It is inconsistent.
It is incomplete.
It is historic.

Beside your opinion there exist other, better schema that are _in use_:
- Oxomoa (draft)
- Public Transport (proposal)
- unified stoparea (proposal)
- stop place (proposal)
- several variations of the four listed schema.

If we go on waiting to approve one of them, the number of ideas and 
proposals will grow and the variations of them will increase too. This 
is not what OSM is designed for. OSM is useless if everyone makes it 
different.


Regards
Teddych


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

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

[Richard Mann]

highway=bus_stop on a node next to a road
railway=tram_stop on a node on railway=tram
railway=platform on a node or way or area next to the tram tracks

all work fine, so don't change them

If you've got a bus stop in the middle of the road (if Alv can spot
them, so can a router), it's probably quite tolerable that you call it
highway=bus_stop, and leave it to a router to identify it as being on
a road, and to prefer a highway=platform as the pedestrian
destination, if there is one. If someone uses highway=tram_stop
(because everything that stops there is a tram), you can just process
it the same way as a bus stop.

You don't need all the bus=yes, tram=yes stuff. You can pick that up
from the relations that use a stop.

You don't need the stop_position to be shown on the road for each and
every bus stop - it's not going to happen generally, though (as ever)
feel free to do it if you want to.

In general, we don't need a new public_transport key - just define the
usage of the existing tags so that more complex situations can just be
extensions of simple situations.

Richard

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

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

[Michael von Glasow]

On 12/09/2010 06:35 AM, Dominik Mahrer (Teddy) wrote:

Hi Michael


In the new proposal I am missing some details on how to build relations:

1. Should the outward and return trip be represented as two separate
relations, as a single relation or is that up to the mapper?


Each direction should be in a separate relation. This is written in 
the proposal. Both directions/variants should be member of a master 
relation.
you're right, I overlooked that. I already use separate relations for 
each direction so I agree on that unless we find a convenient way of 
reducing the number of relation needed. I don't use master relations - 
in most cases, the relations of a single line are sufficiently 
identified by their ref and network. There may be exceptions, though: 
the network name is not guaranteed to be unique, and in that case it may 
be difficult to separate two lines with the same network names which in 
fact belong to different networks. Plus, here in Milan line variants are 
often (not always) indicated by adding a slash. For instance, line 42/ 
may mostly follow line 42 but serve some extra stops not served by 42 
(and, in some cases, skipping the last stops of 42).



2. Which members should the relation contain, and in which order?


You are not the first with this question, so I added some explanations 
to the proposal:


First the stop_positions ordered (with role stop), then platforms 
ordered (with role platform) and then the ways ordered (without role).



3. Which data primitive should be added for stops?


Stop positions AND platform. Stop position is important for the route 
itself, the platform is important for pedestrian routing.
Fine for me, though it does mean some more effort to enter data. Except 
that we might consider adding the platform right after the stop it 
belongs to - that would make it easier to verify that both are there.



4. How are line variants mapped?


Problem 1:

A - B1/B2 - C - D - E1/E2 - F

In morning and evening hours the bus stops at B2 instead of B1.
During school holiday the bus stops at E2 instead of E1.
This gives us four possibilities really used.

When you add alt-roles to a stop you can't say when is what route 
used. So this does not work, we need really four relations.
Yes, this is a more complex variant of my market example (yours is the 
equivalent of two markets, say, one on Monday and Wednesday and the 
other on Wednesday and Friday). As I mentioned in my post, I have no 
feasible solution for mapping this in a single relation.

Problem 2:

What do you want to say with role forward/backward? Forward/backward 
compared to what? To the route direction or to the tagged way 
direction? Actually both is used in the OSM database and no one knows 
how to interpret it. Role forward and backward is in my eyes a nice 
try to solve a problem. But it confused more then it solved. We should 
leave this away.
As far as I know, this is accurately defined: it is relative to the 
tagged way direction, which may or may correspond to the route 
direction. But I, too, realize that this part confuses people. If we 
agree that ways must always be sorted, each way sharing an end node with 
the ones before and after (which I strongly recommend), then we can 
extract this information from the route itself without tagging it 
explicitly.

Practical:

I map the variant with the most stops (in your example twice A B1 E1 
K. In JOSM you can easily copy a relation and change what is 
different. So to handle your 8 variants should not take 8 times 
mapping one variant.
That works when you have the entire route from beginning to end. But 
some of us (I do) often follow just a part of the way and enter that, 
hoping to complete it at a later occasion (or someone else doing it). 
And once you have two partially-complete relations, updating them both 
together mostly means editing each relation manually.
I personally leave away the very special cases (ex. first course 
starts at B instead of A). This is only relevant when timetable 
information is added to.
For some applications, namely public transport maps and route sketches, 
this information might still be useful. For instance, those parts of the 
route which are omitted by some courses could be represented as a dashed 
line, the rest being drawn as a solid line.


Michael

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

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

[Michael von Glasow]

On 12/09/2010 01:31 PM, Michał Borsuk wrote:



On 8 December 2010 20:44, Dominik Mahrer (Teddy) > wrote:


Hello

Yes, the Public Transport proposal is basically based on Oxomoa,
but in some details different.


I do not care about which of the two proposals will be approved.
But I think it is time to get a more exact schema approved then
the fuzzy/non-existing schema (A railway station of 400m length
and 20 platforms or a bus stop for 3 buses per direction of 50m
length is reduced to one node) we have now.


There is the issue of "multiple relations per line" in oxomoa, which 
in my opinion is a total misfit. There are "roles" in relations, and 
different variants of a route can be put there. 
My previous post to this list contains an example of what you may 
encounter in real life. The case of a telescope line may be 
representable in a single relation, but I really do not know how to 
express in a single relation that some courses skip part of the route 
(the market example) and follow another (including some different stops) 
instead. If you have a decent way of expressing that in a single 
relation, please do share it here - I'd happily adopt that if only 
someone suggests a satisfactory solution to the issue.
Two, or more, relations per line is not only "illegal" (clearly 
against the principle, as it was stated by its creators), but also 
hell to administer, and JOSM-limited.
Are you referring to the master relation which contains the relations 
for the route variants? In fact I don't use them in Milan (in Munich it 
seems common practice and I follow that), and as of today renderers seem 
to be fine even without it. Take the following example:


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

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


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


Editor support, as Dominik writes, I would not overestimate. JOSM may be 
complex, but maintaining public transportation routes is complex on 
itself - someone doing that is quite likely to use JOSM anyway. I don't 
really see a reason against using JOSM - Potlatch in my opinion is for 
the occasional mapper or for very quick edits; Merkaartor may have some 
performance benefits (being a native application) but JOSM still has 
satisfactory performance.

Potlatch and Merkaartor account for 2/3 edits together.
Now this does surprise me - I would have expected a higher "market 
share" for JOSM. If you have the figures at hand, it would be 
interesting to find out how many of the people who edit public 
transportation data use JOSM vs. other editors.


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


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

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

[Oleksandr Vlasov]

Dominik Mahrer (Teddy  teddy.ch> writes:

> Yes, the Public Transport proposal is basically based on Oxomoa, but in 
> some details different.
> 
> unified stoparea would "redefine" highway=bus_stop from beside the way 
> to on the way. I'm quite sure this would reject the proposal in a vote.
> 
> unified stoparea and public transport can and do exist beside each 
> other. But you are right, it does not make sense to approve both proposals.
> 
> I do not care about which of the two proposals will be approved. But I 
> think it is time to get a more exact schema approved then the 
> fuzzy/non-existing schema (A railway station of 400m length and 20 
> platforms or a bus stop for 3 buses per direction of 50m length is 
> reduced to one node) we have now.

Hello,

me neither, I'm just waiting that issue (practice vs unified stoparea vs public
transport) to be solved in some manner. Basically, nobody wants to spend time
tagging something what will be retagged shortly.

Anyway, that looks reasonable, so I'm probably going to use that proposal as a
guideline. 

Regards,


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

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

[Dominik Mahrer (Teddy)]

On 09.12.2010 13:31, Michał Borsuk wrote:
There is the issue of "multiple relations per line" in oxomoa, which 
in my opinion is a total misfit. There are "roles" in relations, and 
different variants of a route can be put there. Two, or more, 
relations per line is not only "illegal" (clearly against the 
principle, as it was stated by its creators), but also hell to 
administer, and JOSM-limited. Potlatch and Merkaartor account for 2/3 
edits together.


This simply cannot be passed to the final draft unchanged (as is).


A missing feature in a specific software implementation usually is not a 
criteria of using or not using a feature in an API.


Teddych

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

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

[Michał Borsuk]

On 8 December 2010 20:44, Dominik Mahrer (Teddy)  wrote:

> Hello
>
> Yes, the Public Transport proposal is basically based on Oxomoa, but in
> some details different.
>

I do not care about which of the two proposals will be approved. But I think
> it is time to get a more exact schema approved then the fuzzy/non-existing
> schema (A railway station of 400m length and 20 platforms or a bus stop for
> 3 buses per direction of 50m length is reduced to one node) we have now.
>

There is the issue of "multiple relations per line" in oxomoa, which in my
opinion is a total misfit. There are "roles" in relations, and different
variants of a route can be put there. Two, or more, relations per line is
not only "illegal" (clearly against the principle, as it was stated by its
creators), but also hell to administer, and JOSM-limited. Potlatch and
Merkaartor account for 2/3 edits together.

This simply cannot be passed to the final draft unchanged (as is).


-- 
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 - RFC - Public Transport

[Richard Mann]

Why do routers need a node on the street? Next you'll be wanting me to
put a node on the street outside every house so you can route to a
house. This is a problem that should be solved by the router, not in
the data.

Richard

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

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

[Dominik Mahrer (Teddy)]

Hi Michael


In the new proposal I am missing some details on how to build relations:

1. Should the outward and return trip be represented as two separate
relations, as a single relation or is that up to the mapper?


Each direction should be in a separate relation. This is written in the 
proposal. Both directions/variants should be member of a master relation.



2. Which members should the relation contain, and in which order?


You are not the first with this question, so I added some explanations 
to the proposal:


First the stop_positions ordered (with role stop), then platforms 
ordered (with role platform) and then the ways ordered (without role).



3. Which data primitive should be added for stops?


Stop positions AND platform. Stop position is important for the route 
itself, the platform is important for pedestrian routing.



4. How are line variants mapped?


Problem 1:

A - B1/B2 - C - D - E1/E2 - F

In morning and evening hours the bus stops at B2 instead of B1.
During school holiday the bus stops at E2 instead of E1.
This gives us four possibilities really used.

When you add alt-roles to a stop you can't say when is what route used. 
So this does not work, we need really four relations.


Problem 2:

What do you want to say with role forward/backward? Forward/backward 
compared to what? To the route direction or to the tagged way direction? 
Actually both is used in the OSM database and no one knows how to 
interpret it. Role forward and backward is in my eyes a nice try to 
solve a problem. But it confused more then it solved. We should leave 
this away.


Practical:

I map the variant with the most stops (in your example twice A B1 E1 K. 
In JOSM you can easily copy a relation and change what is different. So 
to handle your 8 variants should not take 8 times mapping one variant.


I personally leave away the very special cases (ex. first course starts 
at B instead of A). This is only relevant when timetable information is 
added to.


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

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

[Michael von Glasow]

On 12/08/2010 08:44 PM, Dominik Mahrer (Teddy) wrote:

Hello

Yes, the Public Transport proposal is basically based on Oxomoa, but 
in some details different.


unified stoparea would "redefine" highway=bus_stop from beside the way 
to on the way. I'm quite sure this would reject the proposal in a vote.


unified stoparea and public transport can and do exist beside each 
other. But you are right, it does not make sense to approve both 
proposals.


I do not care about which of the two proposals will be approved. But I 
think it is time to get a more exact schema approved then the 
fuzzy/non-existing schema (A railway station of 400m length and 20 
platforms or a bus stop for 3 buses per direction of 50m length is 
reduced to one node) we have now.


Regards
Teddych


On 12/08/2010 06:02 PM, Oleksandr Vlasov wrote:

Dominik Mahrer (Teddy  teddy.ch>  writes:


I want to invite everyone to comment the (in central europe) already
widely used new Public Transport Schema:

http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport


Good work - a few months ago I started mapping the public transportation 
network in Milan and started out by looking around how other cities were 
doing it. My aim was to use a tagging scheme which is easy to 
understand/learn, minimizes data entry effort (it makes a difference 
whether mapping a single line takes half an hour or two hours) and is 
supported by the common renderers.


The results of the research I did back then is at:

http://wiki.openstreetmap.org/wiki/Milano/Trasporti_pubblici

(unfortunately it is in Italian only, but maybe non-Italian speakers can 
still get some information on tagging out of it).


The differentiation between stop_position and platform elegantly solves 
the dilemma on the position of the node (on the way or next to it). For 
routing applications it is definitely more convenient if the node is 
part of the way. However, two stops located on either side of the road 
would thus collapse into one point and it would no longer be possible to 
tag explicitly one or the other. (For example: here in Milan each stop, 
i.e. pole, has a unique number, which I tag as ref. If there is a double 
tram stop, there is a single node but two numbers. Using only this 
single node, there is no easy way to tell which number belongs to which 
side of the road. Or another example: what if there is a shelter on one 
side of the road, but not on the other?)


In the new proposal I am missing some details on how to build relations:

1. Should the outward and return trip be represented as two separate 
relations, as a single relation or is that up to the mapper?


I would favor separate relations: The ways used may be different (a road 
with two physically separated lanes, or a labyrinth of one-way streets 
in a European city), and with one relation per direction it is easy to 
sort the ways and detect holes in the route.


2. Which members should the relation contain, and in which order?

My approach to this: all way segments, tagged as role=forward or 
role=backward. The way segments should be sorted; where a bus passes the 
same way twice, it should be added twice - this allows for easy 
verification if the route is complete. Additionally the relation should 
contain all stops, which must also be sorted (some rendering 
applications, e.g. sketch-route, need the correct order of all stops). 
Stops should not be mangled with the ways - either insert ways first, 
then stops, or vice versa. Again, this is for better overview and makes 
the process less error-prone.


3. Which data primitive should be added for stops?

My suggestion: the one which best identifies the actual position at 
which the vehicle stops (and passengers board). This can be either the 
platform, the stop position or the stop area relation. Given that the 
stop position is always a node while the platform may be a node or an 
area, the stop position is probably the less problematic one to use 
(some renderers already support the combination of role=stop, 
public_transport=stop_position). I would recommend against adding the 
stop group relation as stop, since this does not provide sufficient 
information as to where passengers can really board the vehicle (stop 
groups can be huge).


4. How are line variants mapped?

One relation for each variant? Or one relation for the common part and 
one for each alternative? Sincerely, this is where I'm myself at a loss. 
Imagine a bus line with the following stops: A - B - C - D - E1 - F1 - G 
- H - I - K.


Now as for the variants. It's a made-up example, but there are lines in 
Milan which are hardly better:
- Stops E1 and F1 are in a street which is regularly closed for the 
weekly market (suppose Wednesday from 6:00 to 16:00). During that time, 
the bus takes a detour, on which two other stops (E2 and F2) are located.
- The first courses in the morning (6:00 to 7:00) begin at B rather than 
at A. (For instance because B is near the depot.)
- Every

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

[Dominik Mahrer (Teddy)]

Hello

Yes, the Public Transport proposal is basically based on Oxomoa, but in 
some details different.


unified stoparea would "redefine" highway=bus_stop from beside the way 
to on the way. I'm quite sure this would reject the proposal in a vote.


unified stoparea and public transport can and do exist beside each 
other. But you are right, it does not make sense to approve both proposals.


I do not care about which of the two proposals will be approved. But I 
think it is time to get a more exact schema approved then the 
fuzzy/non-existing schema (A railway station of 400m length and 20 
platforms or a bus stop for 3 buses per direction of 50m length is 
reduced to one node) we have now.


Regards
Teddych


On 12/08/2010 06:02 PM, Oleksandr Vlasov wrote:

Dominik Mahrer (Teddy  teddy.ch>  writes:


I want to invite everyone to comment the (in central europe) already
widely used new Public Transport Schema:

http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport


Hello,

it's based on Oxomoa scheme, isn't it?
What's the status of the "unified stoparea" proposal then? those two contradict
each other and unified stoparea is in RFC stage for a year now. Are there any
data regarding actual usage of those two (I understand that unified stoparea
uses quite common tags and thus it's hard to compare just a number of
appropriate tags' occurrences)

Regards,


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

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

[Oleksandr Vlasov]

Dominik Mahrer (Teddy  teddy.ch> writes:

> I want to invite everyone to comment the (in central europe) already 
> widely used new Public Transport Schema:
> 
> http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport

Hello,

it's based on Oxomoa scheme, isn't it?
What's the status of the "unified stoparea" proposal then? those two contradict
each other and unified stoparea is in RFC stage for a year now. Are there any
data regarding actual usage of those two (I understand that unified stoparea
uses quite common tags and thus it's hard to compare just a number of
appropriate tags' occurrences) 

Regards,





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