[Talk-transit] different interpretations of v2 PT scheme

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Talk-transit] different interpretations of v2 PT scheme

Jo-2
When I look at how PT is mapped according to what they consider to be v2 of the public transport scheme, I notice a few problems.

The first is that details about the stops is sometimes mapped on the stop_position node, sometimes on the platform, which can be a way or a node.

As far as I'm concerned a platform (way), a shelter, a bench, a waste basket are all attributes of a stop. At some point the wiki said to map the pole as platform, so I went ahead and did that. Each and every pole is now mapped on a node next to the way:

highway=bus_stop (for rendering, tried to lose it, won't ever render)
public_transport=platform
bus=yes
name
ref
operator
network

Now I find that public_transport=stop_position is getting highway=bus_stop. Where I'm mapping PT, not all stop_positions are present (yet). Adding 65000 bus stops on nodes next to the way, was enough work without trying to make it twice as hard to accomplish.

In retrospect public_transport=platform was a misnomer. Maybe we should have used public_transport=pole.

Anyway, the attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time.

My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so.

At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes.

The stop_area relations combine both directions, That's useless. I don't know who abolished stop_area_group, But what good are these stop_area relations if they don't help to relate an individual platform with a stop_position?

Polyglot

_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

Eric Gillet
2015-07-01 7:38 GMT+02:00 Jo <[hidden email]>:
In retrospect public_transport=platform was a misnomer. Maybe we should have used public_transport=pole.
A platform can be a pole, or a shelter, or a dock, or a boarding "platform" for a train... It is meant to abstract differences between different means of transport.

Anyway, the attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time.
The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ?
 
My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so.
It seems to be more a problem with toxic mappers more than the PT scheme
 
At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes.
In theory, "redundant" details on the same stop should be put in the stop_area relation in order to reduce redundancy.

The stop_area relations combine both directions, That's useless. I don't know who abolished stop_area_group, But what good are these stop_area relations if they don't help to relate an individual platform with a stop_position?
See above.

Éric 


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

Jo-2
2015-07-01 10:00 GMT+02:00 Éric Gillet <[hidden email]>:
2015-07-01 7:38 GMT+02:00 Jo <[hidden email]>:
In retrospect public_transport=platform was a misnomer. Maybe we should have used public_transport=pole.
A platform can be a pole, or a shelter, or a dock, or a boarding "platform" for a train... It is meant to abstract differences between different means of transport.

That's why I tought I was doing all right putting the details of the stop on those public_transport=platform mapped as nodes. When there is an actual platform, I map it separately as a way or an area, which goes into the stop_area relation.

Anyway, the attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time.
The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ?

I don't mind having both. I do mind putting extra tags like name, ref, operator, network, route_ref, zone on the stop_position nodes. It's enough to have that information once.
 
My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so.
It seems to be more a problem with toxic mappers more than the PT scheme

They moved the details to the stop_position, which I don't consider for processing.
 
At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes.
In theory, "redundant" details on the same stop should be put in the stop_area relation in order to reduce redundancy.

That only works if there is one stop_area relation per direction of travel. At the moment the wiki states to use a stop_area relation for all PT related stuff that is near to each other. I need to relate the platform nodes to the nearby way, sometimes by means of a stop_position node, sometimes with help of a stop_area relation.

The stop_area relations combine both directions, That's useless. I don't know who abolished stop_area_group, But what good are these stop_area relations if they don't help to relate an individual platform with a stop_position?
See above.

Éric 


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit



_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

Eric Gillet
2015-07-01 10:53 GMT+02:00 Jo <[hidden email]>:
That only works if there is one stop_area relation per direction of travel. At the moment the wiki states to use a stop_area relation for all PT related stuff that is near to each other. I need to relate the platform nodes to the nearby way, sometimes by means of a stop_position node, sometimes with help of a stop_area relation.

I don't see what attributes of a stop/platform could be dependant on the direction, do you have examples ?
Anyway, if there really is different informations on each stop, it is okay to put them in the nodes/way and only put data applicable to all stops in the stop_area in the stop_area relation.

This is the usual way of using relations : aggregate common data between multiple features in a relation containing said features, and if there is differences between these features put the tags directly on the nodes/ways.

_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

Richard Mann-2
In reply to this post by Jo-2
Your processing needs to be able to cope with these situations, using the latlon of the features, if the relationships aren't explicit. Get the computer to do the work, not the mappers.

Richard

On Wed, Jul 1, 2015 at 9:53 AM, Jo <[hidden email]> wrote:
2015-07-01 10:00 GMT+02:00 Éric Gillet <[hidden email]>:
2015-07-01 7:38 GMT+02:00 Jo <[hidden email]>:
In retrospect public_transport=platform was a misnomer. Maybe we should have used public_transport=pole.
A platform can be a pole, or a shelter, or a dock, or a boarding "platform" for a train... It is meant to abstract differences between different means of transport.

That's why I tought I was doing all right putting the details of the stop on those public_transport=platform mapped as nodes. When there is an actual platform, I map it separately as a way or an area, which goes into the stop_area relation.

Anyway, the attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time.
The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ?

I don't mind having both. I do mind putting extra tags like name, ref, operator, network, route_ref, zone on the stop_position nodes. It's enough to have that information once.
 
My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so.
It seems to be more a problem with toxic mappers more than the PT scheme

They moved the details to the stop_position, which I don't consider for processing.
 
At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes.
In theory, "redundant" details on the same stop should be put in the stop_area relation in order to reduce redundancy.

That only works if there is one stop_area relation per direction of travel. At the moment the wiki states to use a stop_area relation for all PT related stuff that is near to each other. I need to relate the platform nodes to the nearby way, sometimes by means of a stop_position node, sometimes with help of a stop_area relation.

The stop_area relations combine both directions, That's useless. I don't know who abolished stop_area_group, But what good are these stop_area relations if they don't help to relate an individual platform with a stop_position?
See above.

Éric 


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit



_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit



_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

Jo-2
I am the mapper. I use the processing to assist me, like a tool. I also try to map them all in the same way for consistency. The problem is that apparently there was still room for interpretation in the 'version 2' of the public transport scheme.

What I see happening in Germany is that information is duplicated needlessly. Moving it to the stop_area relation would be a logical step, but information doesn't cascade through like that in OSM. In Belgium every stop has its own ref, and of course if you calculate a route_ref from the schedules this will not always yield the same result for both sides of a street.

Jo



2015-07-01 11:43 GMT+02:00 Richard Mann <[hidden email]>:
Your processing needs to be able to cope with these situations, using the latlon of the features, if the relationships aren't explicit. Get the computer to do the work, not the mappers.

Richard

On Wed, Jul 1, 2015 at 9:53 AM, Jo <[hidden email]> wrote:
2015-07-01 10:00 GMT+02:00 Éric Gillet <[hidden email]>:
2015-07-01 7:38 GMT+02:00 Jo <[hidden email]>:
In retrospect public_transport=platform was a misnomer. Maybe we should have used public_transport=pole.
A platform can be a pole, or a shelter, or a dock, or a boarding "platform" for a train... It is meant to abstract differences between different means of transport.

That's why I tought I was doing all right putting the details of the stop on those public_transport=platform mapped as nodes. When there is an actual platform, I map it separately as a way or an area, which goes into the stop_area relation.

Anyway, the attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time.
The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ?

I don't mind having both. I do mind putting extra tags like name, ref, operator, network, route_ref, zone on the stop_position nodes. It's enough to have that information once.
 
My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so.
It seems to be more a problem with toxic mappers more than the PT scheme

They moved the details to the stop_position, which I don't consider for processing.
 
At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes.
In theory, "redundant" details on the same stop should be put in the stop_area relation in order to reduce redundancy.

That only works if there is one stop_area relation per direction of travel. At the moment the wiki states to use a stop_area relation for all PT related stuff that is near to each other. I need to relate the platform nodes to the nearby way, sometimes by means of a stop_position node, sometimes with help of a stop_area relation.

The stop_area relations combine both directions, That's useless. I don't know who abolished stop_area_group, But what good are these stop_area relations if they don't help to relate an individual platform with a stop_position?
See above.

Éric 


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit



_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit




_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

Jo-2
What I'm doing comes down to mapping the poles. stop_positions could be shared for stops that are exactly across one another.

I guess there is no choice but to rewrite the script(s) in order to cope with all variations of possible ways to map. Or else simply give up on it and move on. Not sure which I will choose.

It would be nicer if we were able to come up with a totally consistent version 3 of mapping PT, but what I see, is we're moving in different directions. What is logical to me, apparently isn't for the rest of the world. What I do know is that I'm not going to be spending the next 2 years to make sure all the stop_positions (50000 for a small country) are present. They're simply not important enough for that. I add them here and there and consistently for the terminal stops.

What I want to focus on at the moment is to get all the itineraries in , the routes and their variations. To me that seems like a better use of my time.

Polyglot

2015-07-01 11:59 GMT+02:00 Jo <[hidden email]>:
I am the mapper. I use the processing to assist me, like a tool. I also try to map them all in the same way for consistency. The problem is that apparently there was still room for interpretation in the 'version 2' of the public transport scheme.

What I see happening in Germany is that information is duplicated needlessly. Moving it to the stop_area relation would be a logical step, but information doesn't cascade through like that in OSM. In Belgium every stop has its own ref, and of course if you calculate a route_ref from the schedules this will not always yield the same result for both sides of a street.

Jo



2015-07-01 11:43 GMT+02:00 Richard Mann <[hidden email]>:
Your processing needs to be able to cope with these situations, using the latlon of the features, if the relationships aren't explicit. Get the computer to do the work, not the mappers.

Richard

On Wed, Jul 1, 2015 at 9:53 AM, Jo <[hidden email]> wrote:
2015-07-01 10:00 GMT+02:00 Éric Gillet <[hidden email]>:
2015-07-01 7:38 GMT+02:00 Jo <[hidden email]>:
In retrospect public_transport=platform was a misnomer. Maybe we should have used public_transport=pole.
A platform can be a pole, or a shelter, or a dock, or a boarding "platform" for a train... It is meant to abstract differences between different means of transport.

That's why I tought I was doing all right putting the details of the stop on those public_transport=platform mapped as nodes. When there is an actual platform, I map it separately as a way or an area, which goes into the stop_area relation.

Anyway, the attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time.
The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ?

I don't mind having both. I do mind putting extra tags like name, ref, operator, network, route_ref, zone on the stop_position nodes. It's enough to have that information once.
 
My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so.
It seems to be more a problem with toxic mappers more than the PT scheme

They moved the details to the stop_position, which I don't consider for processing.
 
At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes.
In theory, "redundant" details on the same stop should be put in the stop_area relation in order to reduce redundancy.

That only works if there is one stop_area relation per direction of travel. At the moment the wiki states to use a stop_area relation for all PT related stuff that is near to each other. I need to relate the platform nodes to the nearby way, sometimes by means of a stop_position node, sometimes with help of a stop_area relation.

The stop_area relations combine both directions, That's useless. I don't know who abolished stop_area_group, But what good are these stop_area relations if they don't help to relate an individual platform with a stop_position?
See above.

Éric 


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit



_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit





_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

Janko Mihelić
To me it's logical to put all those ref, network and operator tags in the stop_area relation, not on the nodes or ways. The relation is the only element that describes the bus stop completely. If you only put the ref and operator on the platform, the stop position is missing.

But if mappers in a city agree that they don't need stop_area relations, they can put ref and operator tags on platforms, or stop_areas. I think this can be reasonably flexible, but only between networks, or countries.

Also, putting waste_baskets, benches, flowers, toilets, cafes and other things in the stop area relation is unnecessary. Who decides if a cafe is near enough to be in a stop_area? What do they have to do with public transport? Only the stop_position and platform are needed. But I'm not going to remove those from a stop_area relation, they don't hurt.

sri, 1. srp 2015. u 13:55 Jo <[hidden email]> napisao je:
What I'm doing comes down to mapping the poles. stop_positions could be shared for stops that are exactly across one another.

I guess there is no choice but to rewrite the script(s) in order to cope with all variations of possible ways to map. Or else simply give up on it and move on. Not sure which I will choose.

It would be nicer if we were able to come up with a totally consistent version 3 of mapping PT, but what I see, is we're moving in different directions. What is logical to me, apparently isn't for the rest of the world. What I do know is that I'm not going to be spending the next 2 years to make sure all the stop_positions (50000 for a small country) are present. They're simply not important enough for that. I add them here and there and consistently for the terminal stops.

What I want to focus on at the moment is to get all the itineraries in , the routes and their variations. To me that seems like a better use of my time.

Polyglot

2015-07-01 11:59 GMT+02:00 Jo <[hidden email]>:
I am the mapper. I use the processing to assist me, like a tool. I also try to map them all in the same way for consistency. The problem is that apparently there was still room for interpretation in the 'version 2' of the public transport scheme.

What I see happening in Germany is that information is duplicated needlessly. Moving it to the stop_area relation would be a logical step, but information doesn't cascade through like that in OSM. In Belgium every stop has its own ref, and of course if you calculate a route_ref from the schedules this will not always yield the same result for both sides of a street.

Jo



2015-07-01 11:43 GMT+02:00 Richard Mann <[hidden email]>:
Your processing needs to be able to cope with these situations, using the latlon of the features, if the relationships aren't explicit. Get the computer to do the work, not the mappers.

Richard

On Wed, Jul 1, 2015 at 9:53 AM, Jo <[hidden email]> wrote:
2015-07-01 10:00 GMT+02:00 Éric Gillet <[hidden email]>:
2015-07-01 7:38 GMT+02:00 Jo <[hidden email]>:
In retrospect public_transport=platform was a misnomer. Maybe we should have used public_transport=pole.
A platform can be a pole, or a shelter, or a dock, or a boarding "platform" for a train... It is meant to abstract differences between different means of transport.

That's why I tought I was doing all right putting the details of the stop on those public_transport=platform mapped as nodes. When there is an actual platform, I map it separately as a way or an area, which goes into the stop_area relation.

Anyway, the attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time.
The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ?

I don't mind having both. I do mind putting extra tags like name, ref, operator, network, route_ref, zone on the stop_position nodes. It's enough to have that information once.
 
My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so.
It seems to be more a problem with toxic mappers more than the PT scheme

They moved the details to the stop_position, which I don't consider for processing.
 
At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes.
In theory, "redundant" details on the same stop should be put in the stop_area relation in order to reduce redundancy.

That only works if there is one stop_area relation per direction of travel. At the moment the wiki states to use a stop_area relation for all PT related stuff that is near to each other. I need to relate the platform nodes to the nearby way, sometimes by means of a stop_position node, sometimes with help of a stop_area relation.

The stop_area relations combine both directions, That's useless. I don't know who abolished stop_area_group, But what good are these stop_area relations if they don't help to relate an individual platform with a stop_position?
See above.

Éric 


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit



_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit




_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit

_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

Jo-2
I tend to add the waste_basket that clearly 'belongs' to the bus stop, the bench, the shelter, the ticker/departures screen in as well. Most of the time they have a style you don't see elsewhere. Never occurred to me to add toilets or flowers or pubs though.

But do we agree a stop_area relation is needed for each side of a street? and a stop_area_group to show that they belong together?

Jo



2015-07-02 0:31 GMT+02:00 Janko Mihelić <[hidden email]>:
To me it's logical to put all those ref, network and operator tags in the stop_area relation, not on the nodes or ways. The relation is the only element that describes the bus stop completely. If you only put the ref and operator on the platform, the stop position is missing.

But if mappers in a city agree that they don't need stop_area relations, they can put ref and operator tags on platforms, or stop_areas. I think this can be reasonably flexible, but only between networks, or countries.

Also, putting waste_baskets, benches, flowers, toilets, cafes and other things in the stop area relation is unnecessary. Who decides if a cafe is near enough to be in a stop_area? What do they have to do with public transport? Only the stop_position and platform are needed. But I'm not going to remove those from a stop_area relation, they don't hurt.

sri, 1. srp 2015. u 13:55 Jo <[hidden email]> napisao je:
What I'm doing comes down to mapping the poles. stop_positions could be shared for stops that are exactly across one another.

I guess there is no choice but to rewrite the script(s) in order to cope with all variations of possible ways to map. Or else simply give up on it and move on. Not sure which I will choose.

It would be nicer if we were able to come up with a totally consistent version 3 of mapping PT, but what I see, is we're moving in different directions. What is logical to me, apparently isn't for the rest of the world. What I do know is that I'm not going to be spending the next 2 years to make sure all the stop_positions (50000 for a small country) are present. They're simply not important enough for that. I add them here and there and consistently for the terminal stops.

What I want to focus on at the moment is to get all the itineraries in , the routes and their variations. To me that seems like a better use of my time.

Polyglot

2015-07-01 11:59 GMT+02:00 Jo <[hidden email]>:
I am the mapper. I use the processing to assist me, like a tool. I also try to map them all in the same way for consistency. The problem is that apparently there was still room for interpretation in the 'version 2' of the public transport scheme.

What I see happening in Germany is that information is duplicated needlessly. Moving it to the stop_area relation would be a logical step, but information doesn't cascade through like that in OSM. In Belgium every stop has its own ref, and of course if you calculate a route_ref from the schedules this will not always yield the same result for both sides of a street.

Jo



2015-07-01 11:43 GMT+02:00 Richard Mann <[hidden email]>:
Your processing needs to be able to cope with these situations, using the latlon of the features, if the relationships aren't explicit. Get the computer to do the work, not the mappers.

Richard

On Wed, Jul 1, 2015 at 9:53 AM, Jo <[hidden email]> wrote:
2015-07-01 10:00 GMT+02:00 Éric Gillet <[hidden email]>:
2015-07-01 7:38 GMT+02:00 Jo <[hidden email]>:
In retrospect public_transport=platform was a misnomer. Maybe we should have used public_transport=pole.
A platform can be a pole, or a shelter, or a dock, or a boarding "platform" for a train... It is meant to abstract differences between different means of transport.

That's why I tought I was doing all right putting the details of the stop on those public_transport=platform mapped as nodes. When there is an actual platform, I map it separately as a way or an area, which goes into the stop_area relation.

Anyway, the attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time.
The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ?

I don't mind having both. I do mind putting extra tags like name, ref, operator, network, route_ref, zone on the stop_position nodes. It's enough to have that information once.
 
My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so.
It seems to be more a problem with toxic mappers more than the PT scheme

They moved the details to the stop_position, which I don't consider for processing.
 
At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes.
In theory, "redundant" details on the same stop should be put in the stop_area relation in order to reduce redundancy.

That only works if there is one stop_area relation per direction of travel. At the moment the wiki states to use a stop_area relation for all PT related stuff that is near to each other. I need to relate the platform nodes to the nearby way, sometimes by means of a stop_position node, sometimes with help of a stop_area relation.

The stop_area relations combine both directions, That's useless. I don't know who abolished stop_area_group, But what good are these stop_area relations if they don't help to relate an individual platform with a stop_position?
See above.

Éric 


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit



_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit




_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

nounours77
I think Jo is right to rise this problem. It is unclear which stop/platform belongs to which direction of the route. Often you can decude it from proximity, or from the side.
But I've seen quite some examples, where only the stop_positions are mapped, and if they are quite distant, you have no way to find out to which direction of the route it belongs.
On the other side, the stop_area relation should group stops from different lines, to be able to show the correct communting between lines.
So, if two buslines cross perpendicularly, normally there are four stops, each belonging to one line in one direction.
On one hand, all four should be in the same stop_area (for communting), but then there might be some disambiguity on which belongs to which. (my personal solution is: map stops and platforms, so 4 each, and put BOTH, stop and platform into the route relation, but this seems not to supported by the JOSM verificator).

nounours77


Am 02.07.2015 um 00:53 schrieb Jo <[hidden email]>:

I tend to add the waste_basket that clearly 'belongs' to the bus stop, the bench, the shelter, the ticker/departures screen in as well. Most of the time they have a style you don't see elsewhere. Never occurred to me to add toilets or flowers or pubs though.

But do we agree a stop_area relation is needed for each side of a street? and a stop_area_group to show that they belong together?

Jo



2015-07-02 0:31 GMT+02:00 Janko Mihelić <[hidden email]>:
To me it's logical to put all those ref, network and operator tags in the stop_area relation, not on the nodes or ways. The relation is the only element that describes the bus stop completely. If you only put the ref and operator on the platform, the stop position is missing.

But if mappers in a city agree that they don't need stop_area relations, they can put ref and operator tags on platforms, or stop_areas. I think this can be reasonably flexible, but only between networks, or countries.

Also, putting waste_baskets, benches, flowers, toilets, cafes and other things in the stop area relation is unnecessary. Who decides if a cafe is near enough to be in a stop_area? What do they have to do with public transport? Only the stop_position and platform are needed. But I'm not going to remove those from a stop_area relation, they don't hurt.

sri, 1. srp 2015. u 13:55 Jo <[hidden email]> napisao je:
What I'm doing comes down to mapping the poles. stop_positions could be shared for stops that are exactly across one another.

I guess there is no choice but to rewrite the script(s) in order to cope with all variations of possible ways to map. Or else simply give up on it and move on. Not sure which I will choose.

It would be nicer if we were able to come up with a totally consistent version 3 of mapping PT, but what I see, is we're moving in different directions. What is logical to me, apparently isn't for the rest of the world. What I do know is that I'm not going to be spending the next 2 years to make sure all the stop_positions (50000 for a small country) are present. They're simply not important enough for that. I add them here and there and consistently for the terminal stops.

What I want to focus on at the moment is to get all the itineraries in , the routes and their variations. To me that seems like a better use of my time.

Polyglot

2015-07-01 11:59 GMT+02:00 Jo <[hidden email]>:
I am the mapper. I use the processing to assist me, like a tool. I also try to map them all in the same way for consistency. The problem is that apparently there was still room for interpretation in the 'version 2' of the public transport scheme.

What I see happening in Germany is that information is duplicated needlessly. Moving it to the stop_area relation would be a logical step, but information doesn't cascade through like that in OSM. In Belgium every stop has its own ref, and of course if you calculate a route_ref from the schedules this will not always yield the same result for both sides of a street.

Jo



2015-07-01 11:43 GMT+02:00 Richard Mann <[hidden email]>:
Your processing needs to be able to cope with these situations, using the latlon of the features, if the relationships aren't explicit. Get the computer to do the work, not the mappers.

Richard

On Wed, Jul 1, 2015 at 9:53 AM, Jo <[hidden email]> wrote:
2015-07-01 10:00 GMT+02:00 Éric Gillet <[hidden email]>:
2015-07-01 7:38 GMT+02:00 Jo <[hidden email]>:
In retrospect public_transport=platform was a misnomer. Maybe we should have used public_transport=pole.
A platform can be a pole, or a shelter, or a dock, or a boarding "platform" for a train... It is meant to abstract differences between different means of transport.

That's why I tought I was doing all right putting the details of the stop on those public_transport=platform mapped as nodes. When there is an actual platform, I map it separately as a way or an area, which goes into the stop_area relation.

Anyway, the attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time.
The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ?

I don't mind having both. I do mind putting extra tags like name, ref, operator, network, route_ref, zone on the stop_position nodes. It's enough to have that information once.
 
My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so.
It seems to be more a problem with toxic mappers more than the PT scheme

They moved the details to the stop_position, which I don't consider for processing.
 
At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes.
In theory, "redundant" details on the same stop should be put in the stop_area relation in order to reduce redundancy.

That only works if there is one stop_area relation per direction of travel. At the moment the wiki states to use a stop_area relation for all PT related stuff that is near to each other. I need to relate the platform nodes to the nearby way, sometimes by means of a stop_position node, sometimes with help of a stop_area relation.

The stop_area relations combine both directions, That's useless. I don't know who abolished stop_area_group, But what good are these stop_area relations if they don't help to relate an individual platform with a stop_position?
See above.

Éric 


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit



_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit




_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit

_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

Janko Mihelić
In reply to this post by Jo-2
If you are adding stop_areas, then there certainly have to be two of them, one on each side. One of them is put in the route that goes one way, the other one is put in the other way. I'm also pretty sure that the stop_area_group is not needed. If they are near each other, then it's a group. But to someone "near each other" means within 400m, to someone in a wheelchair it means ramps, to a blind person it means traffic lights with sound. What else can a group achieve that spatial placement can't? Maybe if a group has a ref.

After all this, I'm not sure that stop_area is absolutely necessary. Stop_position and platform are nearby, so there is really not that much chance an algorithm is going to connect the wrong ones. If it was me, I would just add all the refs to the platform, like you did, and ignore all the refs on the stop_position. Job done, no relations needed.

čet, 2. srp 2015. u 00:54 Jo <[hidden email]> napisao je:
I tend to add the waste_basket that clearly 'belongs' to the bus stop, the bench, the shelter, the ticker/departures screen in as well. Most of the time they have a style you don't see elsewhere. Never occurred to me to add toilets or flowers or pubs though.

But do we agree a stop_area relation is needed for each side of a street? and a stop_area_group to show that they belong together?

Jo



2015-07-02 0:31 GMT+02:00 Janko Mihelić <[hidden email]>:
To me it's logical to put all those ref, network and operator tags in the stop_area relation, not on the nodes or ways. The relation is the only element that describes the bus stop completely. If you only put the ref and operator on the platform, the stop position is missing.

But if mappers in a city agree that they don't need stop_area relations, they can put ref and operator tags on platforms, or stop_areas. I think this can be reasonably flexible, but only between networks, or countries.

Also, putting waste_baskets, benches, flowers, toilets, cafes and other things in the stop area relation is unnecessary. Who decides if a cafe is near enough to be in a stop_area? What do they have to do with public transport? Only the stop_position and platform are needed. But I'm not going to remove those from a stop_area relation, they don't hurt.

sri, 1. srp 2015. u 13:55 Jo <[hidden email]> napisao je:
What I'm doing comes down to mapping the poles. stop_positions could be shared for stops that are exactly across one another.

I guess there is no choice but to rewrite the script(s) in order to cope with all variations of possible ways to map. Or else simply give up on it and move on. Not sure which I will choose.

It would be nicer if we were able to come up with a totally consistent version 3 of mapping PT, but what I see, is we're moving in different directions. What is logical to me, apparently isn't for the rest of the world. What I do know is that I'm not going to be spending the next 2 years to make sure all the stop_positions (50000 for a small country) are present. They're simply not important enough for that. I add them here and there and consistently for the terminal stops.

What I want to focus on at the moment is to get all the itineraries in , the routes and their variations. To me that seems like a better use of my time.

Polyglot

2015-07-01 11:59 GMT+02:00 Jo <[hidden email]>:
I am the mapper. I use the processing to assist me, like a tool. I also try to map them all in the same way for consistency. The problem is that apparently there was still room for interpretation in the 'version 2' of the public transport scheme.

What I see happening in Germany is that information is duplicated needlessly. Moving it to the stop_area relation would be a logical step, but information doesn't cascade through like that in OSM. In Belgium every stop has its own ref, and of course if you calculate a route_ref from the schedules this will not always yield the same result for both sides of a street.

Jo



2015-07-01 11:43 GMT+02:00 Richard Mann <[hidden email]>:
Your processing needs to be able to cope with these situations, using the latlon of the features, if the relationships aren't explicit. Get the computer to do the work, not the mappers.

Richard

On Wed, Jul 1, 2015 at 9:53 AM, Jo <[hidden email]> wrote:
2015-07-01 10:00 GMT+02:00 Éric Gillet <[hidden email]>:
2015-07-01 7:38 GMT+02:00 Jo <[hidden email]>:
In retrospect public_transport=platform was a misnomer. Maybe we should have used public_transport=pole.
A platform can be a pole, or a shelter, or a dock, or a boarding "platform" for a train... It is meant to abstract differences between different means of transport.

That's why I tought I was doing all right putting the details of the stop on those public_transport=platform mapped as nodes. When there is an actual platform, I map it separately as a way or an area, which goes into the stop_area relation.

Anyway, the attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time.
The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ?

I don't mind having both. I do mind putting extra tags like name, ref, operator, network, route_ref, zone on the stop_position nodes. It's enough to have that information once.
 
My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so.
It seems to be more a problem with toxic mappers more than the PT scheme

They moved the details to the stop_position, which I don't consider for processing.
 
At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes.
In theory, "redundant" details on the same stop should be put in the stop_area relation in order to reduce redundancy.

That only works if there is one stop_area relation per direction of travel. At the moment the wiki states to use a stop_area relation for all PT related stuff that is near to each other. I need to relate the platform nodes to the nearby way, sometimes by means of a stop_position node, sometimes with help of a stop_area relation.

The stop_area relations combine both directions, That's useless. I don't know who abolished stop_area_group, But what good are these stop_area relations if they don't help to relate an individual platform with a stop_position?
See above.

Éric 


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit



_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit




_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

Eric Gillet
In reply to this post by nounours77
2015-07-02 14:21 GMT+02:00 Nounours77 <[hidden email]>:
I think Jo is right to rise this problem. It is unclear which stop/platform belongs to which direction of the route. Often you can decude it from proximity, or from the side.
But I've seen quite some examples, where only the stop_positions are mapped, and if they are quite distant, you have no way to find out to which direction of the route it belongs.

I think "variant" of a route is more appropriate than "side". Platforms and stop_positions are present in a PTv2 route relation, so it's easy to find which ones belong to which side/variant of a route.

 
On the other side, the stop_area relation should group stops from different lines, to be able to show the correct communting between lines.
That's precisely the goal of the stop_area relation.



_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

Shaun McDonald
In reply to this post by Janko Mihelić
In the UK, the NaPTAN standard uses a stop area to group stops together, such that you have one stop in each direction within the same stop area, or a whole bus station within a stop area.

Shaun

On 2 Jul 2015, at 14:52, Janko Mihelić <[hidden email]> wrote:

If you are adding stop_areas, then there certainly have to be two of them, one on each side. One of them is put in the route that goes one way, the other one is put in the other way. I'm also pretty sure that the stop_area_group is not needed. If they are near each other, then it's a group. But to someone "near each other" means within 400m, to someone in a wheelchair it means ramps, to a blind person it means traffic lights with sound. What else can a group achieve that spatial placement can't? Maybe if a group has a ref.

After all this, I'm not sure that stop_area is absolutely necessary. Stop_position and platform are nearby, so there is really not that much chance an algorithm is going to connect the wrong ones. If it was me, I would just add all the refs to the platform, like you did, and ignore all the refs on the stop_position. Job done, no relations needed.

čet, 2. srp 2015. u 00:54 Jo <[hidden email]> napisao je:
I tend to add the waste_basket that clearly 'belongs' to the bus stop, the bench, the shelter, the ticker/departures screen in as well. Most of the time they have a style you don't see elsewhere. Never occurred to me to add toilets or flowers or pubs though.

But do we agree a stop_area relation is needed for each side of a street? and a stop_area_group to show that they belong together?

Jo



2015-07-02 0:31 GMT+02:00 Janko Mihelić <[hidden email]>:
To me it's logical to put all those ref, network and operator tags in the stop_area relation, not on the nodes or ways. The relation is the only element that describes the bus stop completely. If you only put the ref and operator on the platform, the stop position is missing.

But if mappers in a city agree that they don't need stop_area relations, they can put ref and operator tags on platforms, or stop_areas. I think this can be reasonably flexible, but only between networks, or countries.

Also, putting waste_baskets, benches, flowers, toilets, cafes and other things in the stop area relation is unnecessary. Who decides if a cafe is near enough to be in a stop_area? What do they have to do with public transport? Only the stop_position and platform are needed. But I'm not going to remove those from a stop_area relation, they don't hurt.

sri, 1. srp 2015. u 13:55 Jo <[hidden email]> napisao je:
What I'm doing comes down to mapping the poles. stop_positions could be shared for stops that are exactly across one another.

I guess there is no choice but to rewrite the script(s) in order to cope with all variations of possible ways to map. Or else simply give up on it and move on. Not sure which I will choose.

It would be nicer if we were able to come up with a totally consistent version 3 of mapping PT, but what I see, is we're moving in different directions. What is logical to me, apparently isn't for the rest of the world. What I do know is that I'm not going to be spending the next 2 years to make sure all the stop_positions (50000 for a small country) are present. They're simply not important enough for that. I add them here and there and consistently for the terminal stops.

What I want to focus on at the moment is to get all the itineraries in , the routes and their variations. To me that seems like a better use of my time.

Polyglot

2015-07-01 11:59 GMT+02:00 Jo <[hidden email]>:
I am the mapper. I use the processing to assist me, like a tool. I also try to map them all in the same way for consistency. The problem is that apparently there was still room for interpretation in the 'version 2' of the public transport scheme.

What I see happening in Germany is that information is duplicated needlessly. Moving it to the stop_area relation would be a logical step, but information doesn't cascade through like that in OSM. In Belgium every stop has its own ref, and of course if you calculate a route_ref from the schedules this will not always yield the same result for both sides of a street.

Jo



2015-07-01 11:43 GMT+02:00 Richard Mann <[hidden email]>:
Your processing needs to be able to cope with these situations, using the latlon of the features, if the relationships aren't explicit. Get the computer to do the work, not the mappers.

Richard

On Wed, Jul 1, 2015 at 9:53 AM, Jo <[hidden email]> wrote:
2015-07-01 10:00 GMT+02:00 Éric Gillet <[hidden email]>:
2015-07-01 7:38 GMT+02:00 Jo <[hidden email]>:
In retrospect public_transport=platform was a misnomer. Maybe we should have used public_transport=pole.
A platform can be a pole, or a shelter, or a dock, or a boarding "platform" for a train... It is meant to abstract differences between different means of transport.

That's why I tought I was doing all right putting the details of the stop on those public_transport=platform mapped as nodes. When there is an actual platform, I map it separately as a way or an area, which goes into the stop_area relation.

Anyway, the attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time.
The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ?

I don't mind having both. I do mind putting extra tags like name, ref, operator, network, route_ref, zone on the stop_position nodes. It's enough to have that information once.
 
My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so.
It seems to be more a problem with toxic mappers more than the PT scheme

They moved the details to the stop_position, which I don't consider for processing.
 
At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes.
In theory, "redundant" details on the same stop should be put in the stop_area relation in order to reduce redundancy.

That only works if there is one stop_area relation per direction of travel. At the moment the wiki states to use a stop_area relation for all PT related stuff that is near to each other. I need to relate the platform nodes to the nearby way, sometimes by means of a stop_position node, sometimes with help of a stop_area relation.

The stop_area relations combine both directions, That's useless. I don't know who abolished stop_area_group, But what good are these stop_area relations if they don't help to relate an individual platform with a stop_position?
See above.

Éric 


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit



_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit




_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit

_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

Eric Gillet
In reply to this post by Janko Mihelić
2015-07-02 15:52 GMT+02:00 Janko Mihelić <[hidden email]>:
If you are adding stop_areas, then there certainly have to be two of them, one on each side. One of them is put in the route that goes one way, the other one is put in the other way. I'm also pretty sure that the stop_area_group is not needed. If they are near each other, then it's a group. But to someone "near each other" means within 400m, to someone in a wheelchair it means ramps, to a blind person it means traffic lights with sound. What else can a group achieve that spatial placement can't? Maybe if a group has a ref.
Aggregate data to reduce duplication, and provide strong and explicit links betweens features.
 
After all this, I'm not sure that stop_area is absolutely necessary. Stop_position and platform are nearby, so there is really not that much chance an algorithm is going to connect the wrong ones. If it was me, I would just add all the refs to the platform, like you did, and ignore all the refs on the stop_position. Job done, no relations needed.
In a mutlimodal hub (rail,buses, etc.) that could easily be the case. Anyway explicit is most often better than implicit. 

_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

Jo-2
In reply to this post by Janko Mihelić
Scenario:

I have data from 'upstream'.
This data relates to public_transport=platform nodes next to the way

What I need now, is to figure out which nearby way 'belongs' to this 'platform'.

If there is a stop_area relation, this is easy (as long as there is a stop_area relation which contains a platform and a stop_position pair).

(Note that there are also stops where several buses can stop one after another, so it's not impossible to have more than 1 stop_position for a single platform)

The opposite is also possible, but less likely to be needed.

It is true that there are many cases where the relation between platform and stop_area can be made unambiguously based on proximity. Note that I'm doing this in JOSM not in a geographically enabled database.

There are also times that a stop_position is not needed to get from a platform to the "candidate" way that needs to be added to the route relation.

Anyway, I wouldn't try to abolish stop_area relations, but rather make sure that SA relations can be grouped together into stop_area_group relations. This makes sense for bus stations where the separate stop_area relations will have names with numbers or letters after them.

Jo

2015-07-02 15:52 GMT+02:00 Janko Mihelić <[hidden email]>:
If you are adding stop_areas, then there certainly have to be two of them, one on each side. One of them is put in the route that goes one way, the other one is put in the other way. I'm also pretty sure that the stop_area_group is not needed. If they are near each other, then it's a group. But to someone "near each other" means within 400m, to someone in a wheelchair it means ramps, to a blind person it means traffic lights with sound. What else can a group achieve that spatial placement can't? Maybe if a group has a ref.

After all this, I'm not sure that stop_area is absolutely necessary. Stop_position and platform are nearby, so there is really not that much chance an algorithm is going to connect the wrong ones. If it was me, I would just add all the refs to the platform, like you did, and ignore all the refs on the stop_position. Job done, no relations needed.

čet, 2. srp 2015. u 00:54 Jo <[hidden email]> napisao je:
I tend to add the waste_basket that clearly 'belongs' to the bus stop, the bench, the shelter, the ticker/departures screen in as well. Most of the time they have a style you don't see elsewhere. Never occurred to me to add toilets or flowers or pubs though.

But do we agree a stop_area relation is needed for each side of a street? and a stop_area_group to show that they belong together?

Jo



2015-07-02 0:31 GMT+02:00 Janko Mihelić <[hidden email]>:
To me it's logical to put all those ref, network and operator tags in the stop_area relation, not on the nodes or ways. The relation is the only element that describes the bus stop completely. If you only put the ref and operator on the platform, the stop position is missing.

But if mappers in a city agree that they don't need stop_area relations, they can put ref and operator tags on platforms, or stop_areas. I think this can be reasonably flexible, but only between networks, or countries.

Also, putting waste_baskets, benches, flowers, toilets, cafes and other things in the stop area relation is unnecessary. Who decides if a cafe is near enough to be in a stop_area? What do they have to do with public transport? Only the stop_position and platform are needed. But I'm not going to remove those from a stop_area relation, they don't hurt.

sri, 1. srp 2015. u 13:55 Jo <[hidden email]> napisao je:
What I'm doing comes down to mapping the poles. stop_positions could be shared for stops that are exactly across one another.

I guess there is no choice but to rewrite the script(s) in order to cope with all variations of possible ways to map. Or else simply give up on it and move on. Not sure which I will choose.

It would be nicer if we were able to come up with a totally consistent version 3 of mapping PT, but what I see, is we're moving in different directions. What is logical to me, apparently isn't for the rest of the world. What I do know is that I'm not going to be spending the next 2 years to make sure all the stop_positions (50000 for a small country) are present. They're simply not important enough for that. I add them here and there and consistently for the terminal stops.

What I want to focus on at the moment is to get all the itineraries in , the routes and their variations. To me that seems like a better use of my time.

Polyglot

2015-07-01 11:59 GMT+02:00 Jo <[hidden email]>:
I am the mapper. I use the processing to assist me, like a tool. I also try to map them all in the same way for consistency. The problem is that apparently there was still room for interpretation in the 'version 2' of the public transport scheme.

What I see happening in Germany is that information is duplicated needlessly. Moving it to the stop_area relation would be a logical step, but information doesn't cascade through like that in OSM. In Belgium every stop has its own ref, and of course if you calculate a route_ref from the schedules this will not always yield the same result for both sides of a street.

Jo



2015-07-01 11:43 GMT+02:00 Richard Mann <[hidden email]>:
Your processing needs to be able to cope with these situations, using the latlon of the features, if the relationships aren't explicit. Get the computer to do the work, not the mappers.

Richard

On Wed, Jul 1, 2015 at 9:53 AM, Jo <[hidden email]> wrote:
2015-07-01 10:00 GMT+02:00 Éric Gillet <[hidden email]>:
2015-07-01 7:38 GMT+02:00 Jo <[hidden email]>:
In retrospect public_transport=platform was a misnomer. Maybe we should have used public_transport=pole.
A platform can be a pole, or a shelter, or a dock, or a boarding "platform" for a train... It is meant to abstract differences between different means of transport.

That's why I tought I was doing all right putting the details of the stop on those public_transport=platform mapped as nodes. When there is an actual platform, I map it separately as a way or an area, which goes into the stop_area relation.

Anyway, the attempt to clear up the distinction between mapping stops next to the road and as a node on the road has failed utterly, now all seems to be done twice, which is a total waste of time.
The stop_position is where the bus, train, etc. stop on their way, while the platform is where passengers will be waiting to board. Both features are distinct and serve different purposes in real life, so why not store both in OSM ?

I don't mind having both. I do mind putting extra tags like name, ref, operator, network, route_ref, zone on the stop_position nodes. It's enough to have that information once.
 
My problem is that when I'm adding stops as nodes in Germany and put the details on there, those nodes get cleared/removed. I can reinstate them, but it won't stick, so it's futile to do so.
It seems to be more a problem with toxic mappers more than the PT scheme

They moved the details to the stop_position, which I don't consider for processing.
 
At some point I thought that starting to include the platform ways to the background database would help, but that's not the case if the details are mapped on the stop_position nodes.
In theory, "redundant" details on the same stop should be put in the stop_area relation in order to reduce redundancy.

That only works if there is one stop_area relation per direction of travel. At the moment the wiki states to use a stop_area relation for all PT related stuff that is near to each other. I need to relate the platform nodes to the nearby way, sometimes by means of a stop_position node, sometimes with help of a stop_area relation.

The stop_area relations combine both directions, That's useless. I don't know who abolished stop_area_group, But what good are these stop_area relations if they don't help to relate an individual platform with a stop_position?
See above.

Éric 


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit



_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit




_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit



_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

Roger Slevin
In reply to this post by Eric Gillet

Eric

 

I think you are falling into the trap of trying to cover too many things in one relationship.  A stoparea to me as a public transport person is (defined functionally) a cluster of stoppoints at which it is possible to interchange between services – and as such it is also a collection of stops for which a single stop name can be shared (in the UK we then have a separate “indicator” to allow you to make the naming of each stoppoint unique within the stoparea.   If ramps or other accessibility features are relevant then they should be coded as a separate parameter (attached to the route which can be walked between such stops) – likewise if a light-controlled crossing with audible signals exists, then that too is a separately coded feature.

 

I am not sufficiently familiar with this in the context of mapping to know how best to advise these points are handled in a mapping context.  To me it is better that the mapping focuses on the topographic features (including paths and equipment) and then service information can be overlaid from a public transport information system.

 

Best wishes

 

Roger

 

 

From: Éric Gillet [mailto:[hidden email]]
Sent: 02 July 2015 15:12
To: Public transport/transit/shared taxi related topics
Subject: Re: [Talk-transit] different interpretations of v2 PT scheme

 

2015-07-02 15:52 GMT+02:00 Janko Mihelić <[hidden email]>:

If you are adding stop_areas, then there certainly have to be two of them, one on each side. One of them is put in the route that goes one way, the other one is put in the other way. I'm also pretty sure that the stop_area_group is not needed. If they are near each other, then it's a group. But to someone "near each other" means within 400m, to someone in a wheelchair it means ramps, to a blind person it means traffic lights with sound. What else can a group achieve that spatial placement can't? Maybe if a group has a ref.

Aggregate data to reduce duplication, and provide strong and explicit links betweens features.

 

After all this, I'm not sure that stop_area is absolutely necessary. Stop_position and platform are nearby, so there is really not that much chance an algorithm is going to connect the wrong ones. If it was me, I would just add all the refs to the platform, like you did, and ignore all the refs on the stop_position. Job done, no relations needed.

In a mutlimodal hub (rail,buses, etc.) that could easily be the case. Anyway explicit is most often better than implicit. 


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

Eric Gillet
2015-07-02 16:31 GMT+02:00 Roger Slevin <[hidden email]>:

Eric

 

I think you are falling into the trap of trying to cover too many things in one relationship.


It seems like your email client did not display the quote properly. The only thing I said in the first paragraph is :
"Aggregate data to reduce duplication, and provide strong and explicit links betweens features."

The part about ramps was written by Janko Mihelić <[hidden email]>


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

Roger Slevin

Eric

 

My apologies – I misinterpreted the layout of that message.  My comment was indeed referring to the post by Janko Mihelić.

 

Best wishes

 

Roger

 

 

From: Éric Gillet [mailto:[hidden email]]
Sent: 02 July 2015 18:35
To: Public transport/transit/shared taxi related topics
Subject: Re: [Talk-transit] different interpretations of v2 PT scheme

 

2015-07-02 16:31 GMT+02:00 Roger Slevin <[hidden email]>:

Eric

 

I think you are falling into the trap of trying to cover too many things in one relationship.

 

It seems like your email client did not display the quote properly. The only thing I said in the first paragraph is :

"Aggregate data to reduce duplication, and provide strong and explicit links betweens features."

 

The part about ramps was written by Janko Mihelić <[hidden email]>

 


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

Janko Mihelić
In reply to this post by Roger Slevin

čet, 2. srp 2015. 16:32 Roger Slevin <[hidden email]> je napisao:

I think you are falling into the trap of trying to cover too many things in one relationship.  A stoparea to me as a public transport person is (defined functionally) a cluster of stoppoints at which it is possible to interchange between services – and as such it is also a collection of stops for which a single stop name can be shared (in the UK we then have a separate “indicator” to allow you to make the naming of each stoppoint unique within the stoparea.


IMHO there is no sense in using a stop_area_group relation (You probably meant stop_area_group instead of stop_area) to show where you can interchange between services. That is already obvious if they are near each other, isn't it? Any two stops that are within ~100m from each other can be seen as an stop_area_group. You don't have to make a relation to tell you that.
I see no reason to group objects in stop_area_groups, unless maybe if there is a name or ref that only makes sense to give to a collection of stops, and they all have different names. But if you are talking about a station, we have the tag public_transport=station.

Janko Mihelić

_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

Re: [Talk-transit] different interpretations of v2 PT scheme

Roger Slevin

Janko

 

Janko

 

Remember I am not a mapping specialist but I am a specialist in public transport information systems - and perhaps it is our different perspectives that triggers different views, and the terminology that we use. I am also guilty of using UK terminology which (for historic reasons) slightly differs from that used in the relevant European Standards that covers this area.

 

If you simply use crow-fly proximity to determine whether an interchange is possible then you can quickly find situations where there are physical barriers river, buildings, ...) that prevent connections being made.  If you determine proximity by routed walks then this requires a very detailed level of mapping to be available = and even then you might have two stops on opposite sides of a dual carriageway where the central reservation prevents pedestrians getting from one side of the road to the other.  Furthermore, issues of road safety or personal security may mean that you would never want to offer a journey plan which uses a particular combination of stops as an interchange point. These are perhaps the key reasons why in public transport information systems the best practice is to define the members of an interchange location using what is termed a "stoparea" - which is a collection of stoppoints which generally will use the same public-facing name, and between which it is possible to interchange. When planning a public transport journey it is generally the case that the interchange time between stops in a stoparea are a fixed value - in the UK this is typically set to 5 mins - which allows for a short walk between two stoppoints within the stoparea plus a small time buffer in the event that the arriving service is slightly late.

 

A station is a special type of stoparea in public transport information systems.

 

Where interchanges involve a link between stoppoints which are physically separated by more than a modest distance (in the system I am involved in this generally would mean stops that are more than 150m apart) then, and only then, is a specific walk route defined for the interchange leg - in which case a specific walk time becomes part of the calculation for the journey plan.

 

In the UK all of this forms part of the NaPTAN specification for stops - and this in turn is reflected in the European IFOPT standard, which is in the family of public transport information standards under the Transmodel reference data model.  The key terminology difference is that in the European Standards a "Stop" is what I refer to as a "Stoparea" (because in everyday English a "stop" means an individual "stoppont".

 

I hope this explains my perspective on what I have referred to as “stopareas”.

 

Best wishes

 

Roger

 

 

From: Janko Mihelić [mailto:[hidden email]]
Sent: 03 July 2015 22:59
To: [hidden email]; Public transport/transit/shared taxi related topics
Subject: Re: [Talk-transit] different interpretations of v2 PT scheme

 

čet, 2. srp 2015. 16:32 Roger Slevin <[hidden email]> je napisao:

I think you are falling into the trap of trying to cover too many things in one relationship.  A stoparea to me as a public transport person is (defined functionally) a cluster of stoppoints at which it is possible to interchange between services – and as such it is also a collection of stops for which a single stop name can be shared (in the UK we then have a separate “indicator” to allow you to make the naming of each stoppoint unique within the stoparea.

 

IMHO there is no sense in using a stop_area_group relation (You probably meant stop_area_group instead of stop_area) to show where you can interchange between services. That is already obvious if they are near each other, isn't it? Any two stops that are within ~100m from each other can be seen as an stop_area_group. You don't have to make a relation to tell you that.
I see no reason to group objects in stop_area_groups, unless maybe if there is a name or ref that only makes sense to give to a collection of stops, and they all have different names. But if you are talking about a station, we have the tag public_transport=station.

Janko Mihelić


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
12