Re: [Tagging] Additions to public_transport scheme

[Martin Koppenhoefer]

sent from a phone

> Il giorno 08 lug 2016, alle ore 00:27, Michael Reichert  ha 
> scritto:
> 
> In Germany there are ref_name=* and uic_name=* in use. (We have the same
> problem)


thank you for pointing to this. Maybe the definition can be improved, I find it 
hard to understand, currently it reads:
"A ref_name is an item in search engine.
ref_name is used in national language. When name finds more than one item in 
search engine you can use ref_name to set a special item. It is used by 
openptmap.org searching tags in sequence (uic_ref , ref:ibnr , ref_name , name) 
and commit the result to a special search engine (in bahn.de)"

Cheers,
Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additions to public_transport scheme

[Martin Koppenhoefer]

sent from a phone

Il giorno 07 lug 2016, alle ore 16:51, Tijmen Stam  ha 
scritto:

>> The tag should be modeled on existing tags that already
>> handle that.
> 
> Except they don't.


official_name?

cheers,
Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additions to public_transport scheme

[Michael Reichert]

Hi,

Am 07.07.2016 um 08:19 schrieb Colin Smale:
> You could use "long_name" to provide a version of the name which
> includes the discriminators 

In Germany there are ref_name=* and uic_name=* in use. (We have the same
problem)

Best regards

Michael




-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additions to public_transport scheme

[Tijmen Stam]

>> On Jul 7, 2016, at 3:04 PM, Tijmen Stam  wrote:
>>
>> No, that's not at all what I mean!
>>
>> It's the place the stop is _in_.
>
> Yea, I know.
>
> But it is the same idea : turn here for Los Angeles.
>
> Get off here for downtown los angeles.

Either we don't understand or we don't agree, but no, it's not the same idea.

> Maybe the exit signs that list the road, exit number *and* what town the
> exit is for is a better example - all of it is additional "for location"
> information. The tag should be modeled on existing tags that already
> handle that.

Except they don't.
For example: Utrecht is a large city (by Dutch standards). One of the main
destinations (traffic-wise) is the "Veemarkt" (Livestock Market).

Most motorists by now know they are in or near Utrecht, so the exit is
only labeled "Livestock Market / City Centre". No mention of the
"placename" Utrecht, road numbers or whatever. Just destinations and the
exit number.
https://www.google.com/maps/@52.1116916,5.1491616,3a,75y,200.51h,81.92t/data=!3m6!1e1!3m4!1sbwD4BSWCD9eYuwTch0tj1w!2e0!7i13312!8i6656

Again, it's the place the stop is _in_ according to the bus company, which
_might_ or _might not_ be the same as the one it is in by administrative
division.
Then there is the problem which administrative level to choose. Is the bus
stop next to my house in "Bijlmer", "Zuidoost", "Amsterdam", "Amsterdam",
"Stadsregio Amsterdam", "Metropoolregio Amsterdam", "Noord-Holland",
"Nederland" or "Europe"?
A road is in all of these at the same time, but the name of the bus stop
isn't equal to all of these at the same time.

So I don't see the similarity in idea here.

Tijmen/IIVQ


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additions to public_transport scheme

[John Willis]

 

> On Jul 7, 2016, at 3:04 PM, Tijmen Stam  wrote:
> 
> No, that's not at all what I mean!
> 
> It's the place the stop is _in_.

Yea, I know. 

But it is the same idea : turn here for Los Angeles. 

Get off here for downtown los angeles. 

Maybe the exit signs that list the road, exit number *and* what town the exit 
is for is a better example - all of it is additional "for location" 
information. The tag should be modeled on existing tags that already handle 
that. 

Javbw. 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additions to public_transport scheme

[Jo]

Did you have a look at that sketch line diagram?

It looks like what you'd find in the bus timetable guide. True, it's not
what you'll find on most of the flags in the field.

Here is another line that passes 3 times by a stop called Oud-Station (that
meanse former railway station):
http://overpass-api.de/api/sketch-line?network=DLVB=318=

It is confusing and people actually do get off at the wrong one. I told
them get of at Bertem Oud-Station, which is the third one and the got off
at the second one 5km too early.


It's not overly hard to change the naming of those stops in Belgium over
the coming months/years. I prefer more verbose naming where this is more
practical. To me it also helps when working with those routes in the
relation editor, but if I'm alone with that opinion, so be it.

Polyglot


2016-07-07 10:10 GMT+02:00 Marc Gemis :

> On Thu, Jul 7, 2016 at 9:37 AM, Jo  wrote:
> >
> > And I know it's possible to deduce those village names from the
> geometries,
> > but we don't all have geodatabase functionality available all of the
> time,
> > to make that calculation over and over, and over again.
>
> We do not repeat the name of the town in front of each street name, do
> we ? Maybe there is someone without a geodatabase that needs to know
> that...
>
> OSM is a geodatabase, and when you do not use it like that you will
> not have all the functionality a geodatabase offers. Should we repeat
> all info all the time for this group of data consumers ?
> I hope not.
>
> regardrs
>
> m
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additions to public_transport scheme

[Marc Gemis]

On Thu, Jul 7, 2016 at 9:37 AM, Jo  wrote:
>
> And I know it's possible to deduce those village names from the geometries,
> but we don't all have geodatabase functionality available all of the time,
> to make that calculation over and over, and over again.

We do not repeat the name of the town in front of each street name, do
we ? Maybe there is someone without a geodatabase that needs to know
that...

OSM is a geodatabase, and when you do not use it like that you will
not have all the functionality a geodatabase offers. Should we repeat
all info all the time for this group of data consumers ?
I hope not.

regardrs

m

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additions to public_transport scheme

[Martin Koppenhoefer]

sent from a phone

> Il giorno 07 lug 2016, alle ore 09:14, Tijmen Stam  ha 
> scritto:
> 
> Another example near me is where the two stops are in different 
> municipalities, despite that both stops are called placename Diemen by the 
> transport company.


would this be resolvable with place polygons? Or is it just the transport 
company  that finds it makes sense to use this structure?

cheers,
Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additions to public_transport scheme

[Martin Koppenhoefer]

sent from a phone

> Il giorno 07 lug 2016, alle ore 08:27, Marc Gemis  ha 
> scritto:
> 
> put
> some others thought it would be nice to have the same name as in the
> timetable books.


while I'm not sure you can legally do this, a natural tag to put this would be 
official_name (or even timetable_name or alt_name if it isn't official)

cheers,
Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additions to public_transport scheme

[Jo]

The reason why I propose to add the placename as part of the name, is that
it gives a feedback about the correct order of the stops:

http://overpass-api.de/api/sketch-line?network=DLVB=5=

On the second line of that diagram, you can see:

Haasrode Kerk
Haasrode Kerkstraat
Blanden Kerk

So two times a church very near to one another. Without the placename this
would be:

..
Kerk
Kerkstraat
Kerk
..

So which church is served first now?

And I know it's possible to deduce those village names from the geometries,
but we don't all have geodatabase functionality available all of the time,
to make that calculation over and over, and over again.

We could put it in a separate tag, but what would that tag be then? not
addr: as that will give warnings in the validator, if I'm not mistaken. Not
contact: either. is_in? I thought we were trying to eradicate that one.

Polyglot

2016-07-07 9:14 GMT+02:00 Tijmen Stam :

> On 07-07-16 08:15, Frederik Ramm wrote:
>
>> Hi,
>>
>> On 07/07/2016 08:04 AM, Tijmen Stam wrote:
>>
>>> It's the place the stop is _in_.
>>>
>>
>> We usually resolve such issues by looking at the surrounding
>> administrative area polygons. You will see that, for example, we have
>> long since stopped tagging a village with
>> "is_in=CountyA,StateB,CountryC" because the geocoder can easily
>> determine this information from the admin boundaries. The same can be
>> done for public transport stops.
>>
>> Or are you saying that the public transport company might use a
>> different name for the administrative entity than can be deduced from
>> the admin boundary?
>>
>
> Yes!
> As an example:
> The bus stop called "Veenendaal, Station de Klomp" (placename: Veenendaal,
> Stopname "Station de Klomp")
> is situated in the Hamlet of De Klomp, which is in an entirely different
> province than the city=municipality of Veenendaal.
>
> See <
> http://www.openstreetmap.org/relation/271169#map=18/52.04610/5.57297=T>
> for the stop, zoom out to see the municipality of Veenendaal in orange and <
> http://connexxion.nl/dienstregeling/halte?id=50810252=E080=2=07072016>
> is the bus company's stop.
>
> (Note that the bus stop's name is not the same as the train station's name
> because there are more train stations in and around Veenendaal
> The train station called "Veenendaal-De Klomp" is called Veenendaal
> because it serves that city, despite the station being in hamlet "De Klomp")
>
> Another example near me is where the two stops are in different
> municipalities, despite that both stops are called placename Diemen by the
> transport company.
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additions to public_transport scheme

[Tijmen Stam]

On 07-07-16 08:15, Frederik Ramm wrote:

Hi,

On 07/07/2016 08:04 AM, Tijmen Stam wrote:

It's the place the stop is _in_.


We usually resolve such issues by looking at the surrounding
administrative area polygons. You will see that, for example, we have
long since stopped tagging a village with
"is_in=CountyA,StateB,CountryC" because the geocoder can easily
determine this information from the admin boundaries. The same can be
done for public transport stops.

Or are you saying that the public transport company might use a
different name for the administrative entity than can be deduced from
the admin boundary?


Yes!
As an example:
The bus stop called "Veenendaal, Station de Klomp" (placename: 
Veenendaal, Stopname "Station de Klomp")
is situated in the Hamlet of De Klomp, which is in an entirely different 
province than the city=municipality of Veenendaal.


See 
 
for the stop, zoom out to see the municipality of Veenendaal in orange 
and 
 
is the bus company's stop.


(Note that the bus stop's name is not the same as the train station's 
name because there are more train stations in and around Veenendaal
The train station called "Veenendaal-De Klomp" is called Veenendaal 
because it serves that city, despite the station being in hamlet "De Klomp")


Another example near me is where the two stops are in different 
municipalities, despite that both stops are called placename Diemen by 
the transport company.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additions to public_transport scheme

[Colin Smale]

On 2016-07-07 08:15, Frederik Ramm wrote:

> Hi,
> 
> On 07/07/2016 08:04 AM, Tijmen Stam wrote: 
> 
>> It's the place the stop is _in_.
> 
> We usually resolve such issues by looking at the surrounding
> administrative area polygons. You will see that, for example, we have
> long since stopped tagging a village with
> "is_in=CountyA,StateB,CountryC" because the geocoder can easily
> determine this information from the admin boundaries. The same can be
> done for public transport stops.

Depends on the country... the UK does not have well-defined boundaries
for settlements unless they happen to coincide with a parish council
boundary. In very many ways the UK is far less organised and structured
than most European countries. The results from Nominatim for an
arbitrary location in the UK are usually just about recognisable, but in
many cases differ widely from what a "local resident" would
instinctively expect. 

> Or are you saying that the public transport company might use a
> different name for the administrative entity than can be deduced from
> the admin boundary?

This can easily be the case, as the transport company might use the
colloquial name for a location. Admin boundaries can be funny sometimes,
dividing a settlement into parts which the man in the street doesn't
recognise. 

//colin___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additions to public_transport scheme

[Marc Gemis]

On Wed, Jul 6, 2016 at 11:39 PM, Tijmen Stam  wrote:
> For example:
> - in most of rural Belgium, " " is used (as in
> http://www.openstreetmap.org/relation/59518#map=17/51.23869/4.57898=T)

There was some kind of vote on the Belgian mailing list a few years
ago to chose between just "" or " ".
The latter had more voters. Hence, all stops should have the combined
name.
 I never liked it (for the reasons mentioned by Frederik & Colin), put
some others thought it would be nice to have the same name as in the
timetable books.
The placename is never mentioned on the bus stop.

As for your formula, it might be better to discuss that on the public
transport mailing list.

regards

m

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additions to public_transport scheme

[Colin Smale]

We don't do it for street names... There is a High Street in every town
and we seem to survive...

You could use geolocation or your own geometry to find the place
enclosing (or nearest to) the stop 

You could use the is_in tag to provide this information (not sure about
the status of this tag) 

You could use "long_name" to provide a version of the name which
includes the discriminators 

//colin 

On 2016-07-07 08:04, Tijmen Stam wrote:

> On 07-07-16 01:28, John Willis wrote: 
> 
> On Jul 7, 2016, at 6:39 AM, Tijmen Stam  wrote:
> 
> 1. a "placename" (or "place") tag for stop_position, platform and stop_area. 
> I notice that most public transport companies have a somewhat separate idea 
> of a place name and a stop name. 
> This sounds like the destination names on road signs, especially on 
> motorways.  (interstate 5 north - Los Angeles), the "control city" in US 
> highway lingo.

No, that's not at all what I mean!

It's the place the stop is _in_.

For example, a rural line going from Acity to Ecity via Btown, Cville
and Dhamlet might have the stops on the website as

Acity, City Hall
Acity, Industrial Park
Acity, Junction
Btown, Church
Cville, Church
Cville, Post Office
Cville, Industrial Park
Dhamlet, Junction
Ecity, Post Office
Ecity, City Hall

So if you are _in_ Btown, you'd only see "Church" on the bus stop
. But on the site you'd see a stop at "Industrial Park" at
both 8:04 and at 8:31, and without what I propose as "placename" you
wouldn't be able to discern between the two.

The place a certain stop goes _to_ (as you thought my proposal means)
can be deciphered by interpreting the various public_transport=route
relations that have the stop_position/platform as their member.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additions to public_transport scheme

[Frederik Ramm]

Hi,

On 07/07/2016 08:04 AM, Tijmen Stam wrote:
> It's the place the stop is _in_.

We usually resolve such issues by looking at the surrounding
administrative area polygons. You will see that, for example, we have
long since stopped tagging a village with
"is_in=CountyA,StateB,CountryC" because the geocoder can easily
determine this information from the admin boundaries. The same can be
done for public transport stops.

Or are you saying that the public transport company might use a
different name for the administrative entity than can be deduced from
the admin boundary?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additions to public_transport scheme

[John Willis]

> On Jul 7, 2016, at 6:39 AM, Tijmen Stam  wrote:
> 
> 1. a "placename" (or "place") tag for stop_position, platform and stop_area. 
> I notice that most public transport companies have a somewhat separate idea 
> of a place name and a stop name.

This sounds like the destination names on road signs, especially on motorways.  
(interstate 5 north - Los Angeles), the "control city" in US highway lingo. 

Perhaps the existing tags (or similar) for adding destinations to the motorway 
exits would be appropriate in this situation as well, so there is no 
reinventing the wheel for a similar tagging situation.  

I forget what that tagging is, but I have seen it before. 

Javbw. 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Additions to public_transport scheme

[Tijmen Stam]

Hello,

I suggest two additions to the public transport scheme:

1. a "placename" (or "place") tag for stop_position, platform and 
stop_area. I notice that most public transport companies have a somewhat 
separate idea of a place name and a stop name. For example: "New York, 
Grand Central Terminal", where on timetables both are used but on the 
stop itself only the stopname ("Grand Central Terminal").

There is no consistent way of tagging this.

For example:
- in most of rural Belgium, " " is used (as in 
http://www.openstreetmap.org/relation/59518#map=17/51.23869/4.57898=T)
- in most of the Netherlands, but also urban Belgium, "" is 
used 
(http://www.openstreetmap.org/relation/59518#map=16/52.2148/5.2800=T)
- in other places you see combinations like ", ", 
"stopname>, " or " - ", as here in 
Bordeaux for some stops 
(http://www.openstreetmap.org/relation/59518#map=17/44.84029/-0.57879=T)


I suggest setting the placename in another tag "placename" which is 
valid on stops, platforms and stop_areas (and by extension on the "old" 
tags like highway=bus_stop and their rail variants)


2. A tag "formula" on route and route_master relations, which is valid 
for special (marketing) formulas within a network or spanning multiple 
networks.
For example, in the Netherlands there is the "brand" of R·NET for fast 
interurban bus and subway lines. The brand is owned by an independent 
entity and local governements decides whether certain lines are elegible 
or required to have the brand, whereas bus operators operate these 
lines. For example, within one concession, Connexxion runs green 
(Connexxion's brand) colour city and rural buses and red R·NET buses).


I suggest allowing a formula to distinguish lines which have a special 
formula.


---
What is the procedure for addendums to existing tag structures? Should 
there be a formal voting process?


With regards,

Tijmen

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging