Re: [Talk-transit] Revisiting the use of ref in bus stops

[Paul Johnson]

If any.  Seems there's so many unanswered questions about mapping transit
in OSM that nothing solidly uses it yet.

On Fri, Aug 17, 2018 at 2:44 PM, Kevin Dalley  wrote:

> And then we need to look at all of the mapping programs, which need to
> interpret the new info.
>
> I'll do ref for now. It's fairly common in the AC Transit space.
>
> And most stops are single agency, with other agencies stopping nearby.
>
> On 08/17/2018 11:52 AM, Stephen Sprunk wrote:
> > ref:NS, where NS is some sort of namespace code, seems like the right
> > solution.  I see two problems:
> >
> > 1. Consumers only looking at ref will see nothing.  Perhaps it should
> > contain a semicolon-list of all the values in the suffixed tags?  Now
> > we're duplicating data, which introduces the risk of the tags getting
> > out of sync, but that's easy to automate.
> >
> > 2. It creates a new meta-namespace for namespace codes, which could have
> > its own collisions.  This is probably only a problem in practice if
> > collisions are nearby, though, so it may not be worth worrying about.
> >
> > S
> >
> >
> > On 2018-08-17 07:18, Wiklund Johan wrote:
> >
> >> It doesnt really matter if the country is organized if a bus comes
> >> from abroad and uses the stop (such as FlixBus). Organized world would
> >> fix it.
> >>
> >>
> >>
> >> *From:*Jo [mailto:winfi...@gmail.com]
> >> *Sent:* fredag 17. august 2018 10.05
> >> *To:* Public transport/transit/shared taxi related topics
> >> 
> >> *Subject:* Re: [Talk-transit] Revisiting the use of ref in bus stops
> >>
> >>
> >>
> >> We have 3 operators here in Belgium. I started by adding stops for 1
> >> first, so I used ref.
> >>
> >>
> >>
> >> Then I started working on the other operator and some stops are indeed
> >> shared. The other operator has 5 subdivisions and annoyingly they all
> >> assign their own identifiers, those stops also overlap.
> >>
> >>
> >>
> >> For a while I added 2 nodes, sometimes 3, but that really doesn't work
> >> well.
> >>
> >>
> >>
> >> So I merged them and now it's like this:
> >>
> >>
> >>
> >> ref:De_Lijn for stops of De Lijn
> >>
> >> ref:TECB for stops of TEC Brabant-Wallon
> >>
> >> ref:TECC for stops of TEC Charleroi
> >>
> >> ref:TECH for stops of TEC Hainaut
> >>
> >> ref:TECN for stops of TEC Namur
> >>
> >> ref:TECL for stops of TEC Liège
> >>
> >> reft:TECX for stops of TEC Luxembourg
> >>
> >>
> >>
> >> It's a bit messy, so I hope they'll change that at some point in the
> >> future.
> >>
> >>
> >>
> >> and the stops in Brussels could simply use ref, but I don't think we
> >> know their identifiers.
> >>
> >>
> >>
> >> In The Netherlands they are now using
> >>
> >>
> >>
> >> ref:IFOPT=NL:Q:78400680
> >>
> >>
> >>
> >> That would be better, but you need an organised country like The
> >> Netherlands to assign them.
> >>
> >>
> >>
> >> So, I'd say yes use ref:OPRTR, but not OPRTR:ref. You want them to
> >> sort together in the list of tags.
> >>
> >>
> >>
> >> I also use route_ref:OPRTR
> >>
> >>
> >>
> >> Polyglot
> >>
> >>
> >>
> >> Op vr 17 aug. 2018 om 05:33 schreef Paul Johnson  >> >:
> >>
> >> On Thu, Aug 16, 2018 at 5:55 PM, Kevin Dalley  >> > wrote:
> >>
> >> I am using GO-Sync, gtfs-osm-sync, to synchronize data for AC
> >> Transit.
> >>
> >> For AC Transit, the gtfs_id, or stop_code, can be used to
> >> identify the
> >> stop. That's the number on the sign, and can be as a phone code.
> >>
> >> For example,
> >>
> >> stop code is 56669
> >>
> >> stop_name is: "MacArthur Blvd:Randolph Av"
> >>
> >> stop name does not appear on the sign, though variations of
> >> this name
> >> appear on the schedule, usually with a "&" rather than ":".
> >>
> >> stop_code does appear on sign.
> >>
> >> I agree with previous users that, at least for AC Transit,
> >> stop_code
> >> should translated to "ref", which a defined meaning for
> bus_stop.
> >> GO-Sync does not do this, though it would be easy to patch my
> >> version,
> >> at least for AC Transit.
> >>
> >> and use stop_name as name, which is what GO-Sync does.
> >>
> >> Are there recent thoughts on this issue?
> >>
> >>
> >>
> >>  I'm thinking ref on the stop needs to be entirely revisited,
> >> given stops may be used by more than one network and therefore
> >> have more than one ref.
> >>
> >>
> >>
> >> Maybe something like, say, trimet:ref=* for TriMet's stops, and
> >> tillamook-wave:ref=* for Tillamook County's The Wave, which share
> >> the same stop bays at Sunset Transit Center and several locations
> >> in downtown Portland, for example.
> >>
> >> ___
> >> Talk-transit mailing list
> >> Talk-transit@openstreetmap.org  openstreetmap.org>
> >> 

Re: [Talk-transit] Revisiting the use of ref in bus stops

[Kevin Dalley]

And then we need to look at all of the mapping programs, which need to
interpret the new info.

I'll do ref for now. It's fairly common in the AC Transit space.

And most stops are single agency, with other agencies stopping nearby.

On 08/17/2018 11:52 AM, Stephen Sprunk wrote:
> ref:NS, where NS is some sort of namespace code, seems like the right
> solution.  I see two problems:
> 
> 1. Consumers only looking at ref will see nothing.  Perhaps it should
> contain a semicolon-list of all the values in the suffixed tags?  Now
> we're duplicating data, which introduces the risk of the tags getting
> out of sync, but that's easy to automate.
> 
> 2. It creates a new meta-namespace for namespace codes, which could have
> its own collisions.  This is probably only a problem in practice if
> collisions are nearby, though, so it may not be worth worrying about.
> 
> S
> 
> 
> On 2018-08-17 07:18, Wiklund Johan wrote:
> 
>> It doesnt really matter if the country is organized if a bus comes
>> from abroad and uses the stop (such as FlixBus). Organized world would
>> fix it.
>>
>>  
>>
>> *From:*Jo [mailto:winfi...@gmail.com]
>> *Sent:* fredag 17. august 2018 10.05
>> *To:* Public transport/transit/shared taxi related topics
>> 
>> *Subject:* Re: [Talk-transit] Revisiting the use of ref in bus stops
>>
>>  
>>
>> We have 3 operators here in Belgium. I started by adding stops for 1
>> first, so I used ref.
>>
>>  
>>
>> Then I started working on the other operator and some stops are indeed
>> shared. The other operator has 5 subdivisions and annoyingly they all
>> assign their own identifiers, those stops also overlap.
>>
>>  
>>
>> For a while I added 2 nodes, sometimes 3, but that really doesn't work
>> well.
>>
>>  
>>
>> So I merged them and now it's like this:
>>
>>  
>>
>> ref:De_Lijn for stops of De Lijn
>>
>> ref:TECB for stops of TEC Brabant-Wallon
>>
>> ref:TECC for stops of TEC Charleroi
>>
>> ref:TECH for stops of TEC Hainaut
>>
>> ref:TECN for stops of TEC Namur
>>
>> ref:TECL for stops of TEC Liège
>>
>> reft:TECX for stops of TEC Luxembourg
>>
>>  
>>
>> It's a bit messy, so I hope they'll change that at some point in the
>> future.
>>
>>  
>>
>> and the stops in Brussels could simply use ref, but I don't think we
>> know their identifiers.
>>
>>  
>>
>> In The Netherlands they are now using
>>
>>  
>>
>> ref:IFOPT=NL:Q:78400680
>>
>>  
>>
>> That would be better, but you need an organised country like The
>> Netherlands to assign them.
>>
>>  
>>
>> So, I'd say yes use ref:OPRTR, but not OPRTR:ref. You want them to
>> sort together in the list of tags.
>>
>>  
>>
>> I also use route_ref:OPRTR
>>
>>  
>>
>> Polyglot
>>
>>  
>>
>> Op vr 17 aug. 2018 om 05:33 schreef Paul Johnson > >:
>>
>> On Thu, Aug 16, 2018 at 5:55 PM, Kevin Dalley > > wrote:
>>
>> I am using GO-Sync, gtfs-osm-sync, to synchronize data for AC 
>> Transit.
>>
>> For AC Transit, the gtfs_id, or stop_code, can be used to
>> identify the
>> stop. That's the number on the sign, and can be as a phone code.
>>
>> For example,
>>
>> stop code is 56669
>>
>> stop_name is: "MacArthur Blvd:Randolph Av"
>>
>> stop name does not appear on the sign, though variations of
>> this name
>> appear on the schedule, usually with a "&" rather than ":".
>>
>> stop_code does appear on sign.
>>
>> I agree with previous users that, at least for AC Transit,
>> stop_code
>> should translated to "ref", which a defined meaning for bus_stop.
>> GO-Sync does not do this, though it would be easy to patch my
>> version,
>> at least for AC Transit.
>>
>> and use stop_name as name, which is what GO-Sync does.
>>
>> Are there recent thoughts on this issue?
>>
>>  
>>
>>  I'm thinking ref on the stop needs to be entirely revisited,
>> given stops may be used by more than one network and therefore
>> have more than one ref.
>>
>>  
>>
>> Maybe something like, say, trimet:ref=* for TriMet's stops, and
>> tillamook-wave:ref=* for Tillamook County's The Wave, which share
>> the same stop bays at Sunset Transit Center and several locations
>> in downtown Portland, for example.
>>
>> ___
>> Talk-transit mailing list
>> Talk-transit@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-transit
>>
>>
>> ___
>> Talk-transit mailing list
>> Talk-transit@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-transit
> 
> 
> -- 
> Stephen Sprunk  "Those people who think they know everything
> CCIE #3723 are a great annoyance to those of us who do."
> K5SSS --Isaac 

Re: [Talk-transit] Revisiting the use of ref in bus stops

[Stephen Sprunk]

ref:NS, where NS is some sort of namespace code, seems like the right
solution.  I see two problems: 

1. Consumers only looking at ref will see nothing.  Perhaps it should
contain a semicolon-list of all the values in the suffixed tags?  Now
we're duplicating data, which introduces the risk of the tags getting
out of sync, but that's easy to automate. 

2. It creates a new meta-namespace for namespace codes, which could have
its own collisions.  This is probably only a problem in practice if
collisions are nearby, though, so it may not be worth worrying about. 

S 

On 2018-08-17 07:18, Wiklund Johan wrote:

> It doesnt really matter if the country is organized if a bus comes from 
> abroad and uses the stop (such as FlixBus). Organized world would fix it. 
> 
> FROM: Jo [mailto:winfi...@gmail.com] 
> SENT: fredag 17. august 2018 10.05
> TO: Public transport/transit/shared taxi related topics 
> 
> SUBJECT: Re: [Talk-transit] Revisiting the use of ref in bus stops 
> 
> We have 3 operators here in Belgium. I started by adding stops for 1 first, 
> so I used ref.
> 
> Then I started working on the other operator and some stops are indeed 
> shared. The other operator has 5 subdivisions and annoyingly they all assign 
> their own identifiers, those stops also overlap. 
> 
> For a while I added 2 nodes, sometimes 3, but that really doesn't work well. 
> 
> So I merged them and now it's like this: 
> 
> ref:De_Lijn for stops of De Lijn 
> 
> ref:TECB for stops of TEC Brabant-Wallon 
> 
> ref:TECC for stops of TEC Charleroi 
> 
> ref:TECH for stops of TEC Hainaut 
> 
> ref:TECN for stops of TEC Namur 
> 
> ref:TECL for stops of TEC Liège 
> 
> reft:TECX for stops of TEC Luxembourg 
> 
> It's a bit messy, so I hope they'll change that at some point in the future. 
> 
> and the stops in Brussels could simply use ref, but I don't think we know 
> their identifiers. 
> 
> In The Netherlands they are now using 
> 
> ref:IFOPT=NL:Q:78400680 
> 
> That would be better, but you need an organised country like The Netherlands 
> to assign them. 
> 
> So, I'd say yes use ref:OPRTR, but not OPRTR:ref. You want them to sort 
> together in the list of tags. 
> 
> I also use route_ref:OPRTR 
> 
> Polyglot 
> 
> Op vr 17 aug. 2018 om 05:33 schreef Paul Johnson : 
> 
> On Thu, Aug 16, 2018 at 5:55 PM, Kevin Dalley  wrote: 
> 
> I am using GO-Sync, gtfs-osm-sync, to synchronize data for AC  Transit.
> 
> For AC Transit, the gtfs_id, or stop_code, can be used to identify the
> stop. That's the number on the sign, and can be as a phone code.
> 
> For example,
> 
> stop code is 56669
> 
> stop_name is: "MacArthur Blvd:Randolph Av"
> 
> stop name does not appear on the sign, though variations of this name
> appear on the schedule, usually with a "&" rather than ":".
> 
> stop_code does appear on sign.
> 
> I agree with previous users that, at least for AC Transit, stop_code
> should translated to "ref", which a defined meaning for bus_stop.
> GO-Sync does not do this, though it would be easy to patch my version,
> at least for AC Transit.
> 
> and use stop_name as name, which is what GO-Sync does.
> 
> Are there recent thoughts on this issue? 
> 
> I'm thinking ref on the stop needs to be entirely revisited, given stops may 
> be used by more than one network and therefore have more than one ref. 
> 
> Maybe something like, say, trimet:ref=* for TriMet's stops, and 
> tillamook-wave:ref=* for Tillamook County's The Wave, which share the same 
> stop bays at Sunset Transit Center and several locations in downtown 
> Portland, for example. 
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit

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

-- 
Stephen Sprunk  "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Revisiting the use of ref in bus stops

[Wiklund Johan]

It doesnt really matter if the country is organized if a bus comes from abroad 
and uses the stop (such as FlixBus). Organized world would fix it.

From: Jo [mailto:winfi...@gmail.com]
Sent: fredag 17. august 2018 10.05
To: Public transport/transit/shared taxi related topics 

Subject: Re: [Talk-transit] Revisiting the use of ref in bus stops

We have 3 operators here in Belgium. I started by adding stops for 1 first, so 
I used ref.

Then I started working on the other operator and some stops are indeed shared. 
The other operator has 5 subdivisions and annoyingly they all assign their own 
identifiers, those stops also overlap.

For a while I added 2 nodes, sometimes 3, but that really doesn't work well.

So I merged them and now it's like this:

ref:De_Lijn for stops of De Lijn
ref:TECB for stops of TEC Brabant-Wallon
ref:TECC for stops of TEC Charleroi
ref:TECH for stops of TEC Hainaut
ref:TECN for stops of TEC Namur
ref:TECL for stops of TEC Liège
reft:TECX for stops of TEC Luxembourg

It's a bit messy, so I hope they'll change that at some point in the future.

and the stops in Brussels could simply use ref, but I don't think we know their 
identifiers.

In The Netherlands they are now using

ref:IFOPT=NL:Q:78400680

That would be better, but you need an organised country like The Netherlands to 
assign them.

So, I'd say yes use ref:OPRTR, but not OPRTR:ref. You want them to sort 
together in the list of tags.

I also use route_ref:OPRTR

Polyglot

Op vr 17 aug. 2018 om 05:33 schreef Paul Johnson 
mailto:ba...@ursamundi.org>>:
On Thu, Aug 16, 2018 at 5:55 PM, Kevin Dalley 
mailto:ke...@kelphead.org>> wrote:
I am using GO-Sync, gtfs-osm-sync, to synchronize data for AC  Transit.

For AC Transit, the gtfs_id, or stop_code, can be used to identify the
stop. That's the number on the sign, and can be as a phone code.

For example,

stop code is 56669

stop_name is: "MacArthur Blvd:Randolph Av"

stop name does not appear on the sign, though variations of this name
appear on the schedule, usually with a "&" rather than ":".

stop_code does appear on sign.

I agree with previous users that, at least for AC Transit, stop_code
should translated to "ref", which a defined meaning for bus_stop.
GO-Sync does not do this, though it would be easy to patch my version,
at least for AC Transit.

and use stop_name as name, which is what GO-Sync does.

Are there recent thoughts on this issue?

 I'm thinking ref on the stop needs to be entirely revisited, given stops may 
be used by more than one network and therefore have more than one ref.

Maybe something like, say, trimet:ref=* for TriMet's stops, and 
tillamook-wave:ref=* for Tillamook County's The Wave, which share the same stop 
bays at Sunset Transit Center and several locations in downtown Portland, for 
example.
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit