Re: [Tagging] Still RFC — Drop stop positions and platforms

[Yves]

One should keep in mind some mappers don't care mapping public_transport in all 
its subtleties, however they can simply want to map a
__
|  | 
platform by the side of a road when they spot one, and
|
|
bus_stop also. 
Yves 

Le 9 avril 2018 23:59:21 GMT+02:00, Michael Reichert  a 
écrit :
>Hi,
>
>Am 31.03.2018 um 17:00 schrieb Johnparis:
>> This implies the following changes to v2:
>> 
>> 1) every platform node should have mandatory {mode}=yes tag(s)
>
>I also think that public_transport=platform without *=yes tags is some
>kind of incomplete.
>
>> 2) stop_positions should be optional on the map and should not be
>included
>> in the route relations
>
>Stop positions should be optional but there are some cases where they
>are useful. If they are mapped, they should be added to the route
>relation. If we don't add them to the route relations, we can skip them
>at all.
>
>> I'm inclined to agree with the wiki that the v1 tags on nodes should
>remain
>> (including the two million highway=bus_stop tags).
>> 
>> I don't really see a big advantage in changing the value of the v2
>tag from
>> public_transport=platform to something like
>public_transport=wait_area (and
>> there are about one million public_transport=platform tags at the
>moment).
>
>+1
>
>If you try to invent new tags just to replace old tags and the old tags
>are used very often, a proposal is doomed to fail.
>
>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)

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Michael Reichert]

Hi,

Am 31.03.2018 um 17:00 schrieb Johnparis:
> This implies the following changes to v2:
> 
> 1) every platform node should have mandatory {mode}=yes tag(s)

I also think that public_transport=platform without *=yes tags is some
kind of incomplete.

> 2) stop_positions should be optional on the map and should not be included
> in the route relations

Stop positions should be optional but there are some cases where they
are useful. If they are mapped, they should be added to the route
relation. If we don't add them to the route relations, we can skip them
at all.

> I'm inclined to agree with the wiki that the v1 tags on nodes should remain
> (including the two million highway=bus_stop tags).
> 
> I don't really see a big advantage in changing the value of the v2 tag from
> public_transport=platform to something like public_transport=wait_area (and
> there are about one million public_transport=platform tags at the moment).

+1

If you try to invent new tags just to replace old tags and the old tags
are used very often, a proposal is doomed to fail.

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] Still RFC — Drop stop positions and platforms

[Kevin Kenny]

On Sun, Apr 8, 2018 at 7:24 AM, ael  wrote:
> No. Railway platform for the raised area to match the floor level of
> trains is entirely standard. Platform normally means a raised structure
> so it applies to the entry floor of a bus, but not to the ground level
> waiting area which is seldom, if ever, raised. Merely being paved and
> perhaps thus slightly elevated would not normally be called a platform.

It's pretty routine to call a railroad waiting area in the US a 'platform'
irrespective of its elevation. At a lot of minor stations here (including
the one in my home town), the platforms are only 20 cm above the
rails and there are several steps up aboard the car when boarding
the train (US standard for the floor of a passenger car is 122 cm
above top of rail, although there are many systems with other heights).

These low platforms are ordinarily furnished with wheelchair lifts or
boarding ramps that can be retracted frrom the edge of the platform,
The reason for the low height is that small-town stations often do
not have a passing track, and heavy freight has a wider loading
gauge than a standard passenger car and cannot clear an elevated
boarding platform.

So here, at least, a 'platform' may be a minimally elevated structure.

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Philip Barnes]

On Sun, 2018-04-08 at 18:17 +0100, Steve Doerr wrote:
> On 08/04/2018 13:45, Paul Allen wrote:
> > A bus stop is a bus stop.  Unless
> > it's at a bus station, in which case it's a stance.
> 
> I've never heard it called a stance, and the Oxford English
> Dictionary 
> shows that this use of the word is Scottish.

I think that was a typo for Stand.

Phil (trigpoint)


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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Philip Barnes]

On Sun, 2018-04-08 at 19:01 +0200, Jo wrote:
> 
> 
> 2018-04-08 17:37 GMT+02:00 Philip Barnes :
> > 
> > 
> > That is referring to the stops (or stands) within the bus station.
> > The
> > overall area is Gorsaf Bws, same as as Railway Station (Gorsaf
> > Reilffordd) and Police Station (Gorsaf Heddlu).
> > 
> > It is very common to see the words Safle Bws painted on the road at
> > Bus
> > Stops.
> > 
> > Phil (trigpoint)
> > 
> 
> This word stand sounds interesting. Could it also refer to the place
> where people stand waiting at a regular bus stop next to a street? Or
> is it only used in bus stations?
> 
A stand refers to where the bus stands (not the passengers) and waits
between runs. It will be at the end of the route and is usually a bus
station, but can be physically a bus stop at the end of the route.

Phil (trigpoint)

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Steve Doerr]

On 08/04/2018 13:45, Paul Allen wrote:

A bus stop is a bus stop.  Unless
it's at a bus station, in which case it's a stance.


I've never heard it called a stance, and the Oxford English Dictionary 
shows that this use of the word is Scottish.


--
Steve

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Jo]

2018-04-08 17:37 GMT+02:00 Philip Barnes :

> On Sun, 2018-04-08 at 15:52 +0100, Paul Allen wrote:
> > On Sun, Apr 8, 2018 at 2:57 PM, Philip Barnes 
> > wrote:
> > > Almost, Safle Bws is a bus stop. A bus station is Gorsaf Bws :)
> > >
> > > Phil (trigpoint)
> >
> > Let me look at my local bus station (well, what passes for one).
> >
> > Stands A, B, C, D and E.  Stand A consists of 4 bus shelters with at
> > least 3 different routes stopping at them,
> > In Welsh they are Safle A, Safle B, etc.
>
> That is referring to the stops (or stands) within the bus station. The
> overall area is Gorsaf Bws, same as as Railway Station (Gorsaf
> Reilffordd) and Police Station (Gorsaf Heddlu).
>
> It is very common to see the words Safle Bws painted on the road at Bus
> Stops.
>
> Phil (trigpoint)
>

This word stand sounds interesting. Could it also refer to the place where
people stand waiting at a regular bus stop next to a street? Or is it only
used in bus stations?

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Philip Barnes]

On Sun, 2018-04-08 at 15:52 +0100, Paul Allen wrote:
> On Sun, Apr 8, 2018 at 2:57 PM, Philip Barnes 
> wrote:
> > Almost, Safle Bws is a bus stop. A bus station is Gorsaf Bws :)
> > 
> > Phil (trigpoint)
> 
> Let me look at my local bus station (well, what passes for one).
> 
> Stands A, B, C, D and E.  Stand A consists of 4 bus shelters with at
> least 3 different routes stopping at them,
> In Welsh they are Safle A, Safle B, etc.

That is referring to the stops (or stands) within the bus station. The
overall area is Gorsaf Bws, same as as Railway Station (Gorsaf
Reilffordd) and Police Station (Gorsaf Heddlu).

It is very common to see the words Safle Bws painted on the road at Bus
Stops.

Phil (trigpoint)


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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Paul Allen]

On Sun, Apr 8, 2018 at 2:57 PM, Philip Barnes  wrote:

>
> Almost, Safle Bws is a bus stop. A bus station is Gorsaf Bws :)
>
> Phil (trigpoint)
>

Let me look at my local bus station (well, what passes for one).

Stands A, B, C, D and E.  Stand A consists of 4 bus shelters with at least
3 different routes stopping at them,
In Welsh they are Safle A, Safle B, etc.

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[ael]

On Sun, Apr 08, 2018 at 01:45:31PM +0100, Paul Allen wrote:
> On Sun, Apr 8, 2018 at 12:49 PM, ael  wrote:
> 
> >
> > In the context of buses, it tends to refer to the part of the vehicle
> > where people may stand to alight or board.
> >
> > In my part of the UK, we never referred to that part of a bus as a
> platform.
> 
> The old AEC Routemaster buses operated in London did refer to that as a
> platform.

Quite so. It was exactly the old Routemasters that I had in mind.

ael


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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Philip Barnes]

On Sun, 2018-04-08 at 13:45 +0100, Paul Allen wrote:
> 
> On Sun, Apr 8, 2018 at 12:49 PM, ael 
> wrote:
> > In the context of buses, it tends to refer to the part of the
> > vehicle
> > where people may stand to alight or board.
> > 
> 
> In my part of the UK, we never referred to that part of a bus as a
> platform.
I vaguely remember these buses in Leicester city, but never heard the
term platform. The last of these was withdrawn in the late 70s.


> 
> The old AEC Routemaster buses operated in London did refer to that as
> a platform.
> But that was because it was not just an entranceway but also an area
> for a few
> passengers to stand when it was crowded.  Also there was no door, so
> people could
> hop on or off while the bus was moving (not legal, but people did
> it).  See
> https://en.wikipedia.org/wiki/File:Heritage_Routemaster.jpg
> 
> In general, though, I wouldn't consider buses to have platforms.  And
> I would
> never refer to a bus stop as a platform unless it were raised higher
> than the
> pavement/causeway/sidewalk leading up to it.  A bus stop is a bus
> stop.  Unless
> it's at a bus station, in which case it's a stance.
+1


>   Unless it's at a bus station in Wales,in which case it's a Safle.

Almost, Safle Bws is a bus stop. A bus station is Gorsaf Bws :)

Phil (trigpoint)


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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Alan Grant]

Same in Ireland, I don't think I ever hear any part of a bus referred to as
a platform, possibly because we didn't have those Routemaster buses with
open boarding areas.

And yes, a bus stop is a bus stop, plain and simple. It is not a platform
because there is normally no raised structure. Rail and bus have different
physical infrastructure so it is not surprising they use different words.
In that sense highway=bus_stop was a lot closer to natural language.

On Sun, 8 Apr 2018, 14:46 Paul Allen,  wrote:

>
> On Sun, Apr 8, 2018 at 12:49 PM, ael  wrote:
>
>>
>> In the context of buses, it tends to refer to the part of the vehicle
>> where people may stand to alight or board.
>>
>> In my part of the UK, we never referred to that part of a bus as a
> platform.
>
> The old AEC Routemaster buses operated in London did refer to that as a
> platform.
> But that was because it was not just an entranceway but also an area for a
> few
> passengers to stand when it was crowded.  Also there was no door, so
> people could
> hop on or off while the bus was moving (not legal, but people did it).  See
> https://en.wikipedia.org/wiki/File:Heritage_Routemaster.jpg
>
> In general, though, I wouldn't consider buses to have platforms.  And I
> would
> never refer to a bus stop as a platform unless it were raised higher than
> the
> pavement/causeway/sidewalk leading up to it.  A bus stop is a bus stop.
> Unless
> it's at a bus station, in which case it's a stance.  Unless it's at a bus
> station in Wales,
> in which case it's a Safle.
>
> --
> Paul
>
> ___
> 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] Still RFC — Drop stop positions and platforms

[Paul Allen]

On Sun, Apr 8, 2018 at 12:49 PM, ael  wrote:

>
> In the context of buses, it tends to refer to the part of the vehicle
> where people may stand to alight or board.
>
> In my part of the UK, we never referred to that part of a bus as a
platform.

The old AEC Routemaster buses operated in London did refer to that as a
platform.
But that was because it was not just an entranceway but also an area for a
few
passengers to stand when it was crowded.  Also there was no door, so people
could
hop on or off while the bus was moving (not legal, but people did it).  See
https://en.wikipedia.org/wiki/File:Heritage_Routemaster.jpg

In general, though, I wouldn't consider buses to have platforms.  And I
would
never refer to a bus stop as a platform unless it were raised higher than
the
pavement/causeway/sidewalk leading up to it.  A bus stop is a bus stop.
Unless
it's at a bus station, in which case it's a stance.  Unless it's at a bus
station in Wales,
in which case it's a Safle.

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[ael]

On Sun, Apr 08, 2018 at 12:09:58AM +0200, "Christian Müller" wrote:
> > Sent: Sat, 7 Apr 2018 22:51:40 +0100 
> > From: ael <law_ence@ntlworld.com>
> > To: tagging@openstreetmap.org
> > Subject: Re: [Tagging] Still RFC — Drop stop positions and platforms
> >
> > > If I'm not mistaken, the dictionary is referring the platform *on* the
> > > bus [^1], not to the bus stop.
> > 
> > As a native English speaker, I am sure that is the case. I have been
> > bemused by the use of "platform" to describe a typical bus stop.
> > Very definitely not BE in normal usage. 
> 
> Do you know if that applies to rail transport in Britain as well?
> 
> Reading the english wikipedia article
> https://en.wikipedia.org/wiki/Railway_platform

I had not looked at the wikipedia entry about before my previous reply.
That entry seems to mainly concern the USA, but there is little
difference. In all cases, platform is as I originally described: a
raised structure. Over time, especially in the railway context, the
strict usage has slipped a little to include associated waiting areas.

ael


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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[ael]

On Sun, Apr 08, 2018 at 12:09:58AM +0200, "Christian Müller" wrote:
> > Sent: Sat, 7 Apr 2018 22:51:40 +0100 
> > From: ael <law_ence@ntlworld.com>
> > To: tagging@openstreetmap.org
> > Subject: Re: [Tagging] Still RFC — Drop stop positions and platforms
> >
> > > If I'm not mistaken, the dictionary is referring the platform *on* the
> > > bus [^1], not to the bus stop.
> > 
> > As a native English speaker, I am sure that is the case. I have been
> > bemused by the use of "platform" to describe a typical bus stop.
> > Very definitely not BE in normal usage. 
> 
> Do you know if that applies to rail transport in Britain as well?

No. Railway platform for the raised area to match the floor level of
trains is entirely standard. Platform normally means a raised structure
so it applies to the entry floor of a bus, but not to the ground level
waiting area which is seldom, if ever, raised. Merely being paved and
perhaps thus slightly elevated would not normally be called a platform.

Hope that is clear?

ael


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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Christian Müller]

> Sent: Sat, 7 Apr 2018 22:51:40 +0100 
> From: ael <law_ence@ntlworld.com>
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] Still RFC — Drop stop positions and platforms
>
> > If I'm not mistaken, the dictionary is referring the platform *on* the
> > bus [^1], not to the bus stop.
> 
> As a native English speaker, I am sure that is the case. I have been
> bemused by the use of "platform" to describe a typical bus stop.
> Very definitely not BE in normal usage. 

Do you know if that applies to rail transport in Britain as well?

Reading the english wikipedia article
https://en.wikipedia.org/wiki/Railway_platform

one may conclude that the term platform is then used interchangably
for waiting area and specific areas on the vehicle  _or_  that there
is a difference in usage of the term across modes of public trans-
portation.


cmuelle8

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[ael]

On Fri, Apr 06, 2018 at 08:11:27PM +0200, Selfish Seahorse wrote:
> On 30 March 2018 at 17:29, Martin Koppenhoefer  wrote:
> >
> > according to a dictionary, in BE platform also means “the floor area at the 
> > entrance to a bus.” (not necessarily the same as the waiting area) while 
> > the same dictionary requires for rail based transportation that the 
> > platform be “raised”
> 
> If I'm not mistaken, the dictionary is referring the platform *on* the
> bus [^1], not to the bus stop.

As a native English speaker, I am sure that is the case. I have been
bemused by the use of "platform" to describe a typical bus stop.
Very definitely not BE in normal usage. I have wondered why other
British English speakers have not commented. Maybe like me, they didn't
feel strongly enough to intervene.

ael


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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Martin Koppenhoefer]

sent from a phone

On 6. Apr 2018, at 11:04, Selfish Seahorse  wrote:

>> in this case you’ll have a platform object and a sidewalk object that happen 
>> to be at the same place.
> 
> But that way you say that there are two separate objects, which isn't
> true: it's just one physical object that functions both as a sidewalk
> and a platform.


if platform is about a function and not a physical object, it is fine. 

According to the wiki, it is indeed about a function: “Use 
public_transport=platform to identify the places where passengers wait for 
public transport of any type, including boarding facilities at airports, bus 
stations, ports, railway stations, as well as for ski lifts and at roadside bus 
stops, taxi ranks. “



> 
> Because two name tags on the same object doesn't work, I think it is
> best to map the sidewalk as a way and public_transport=platform as a
> node for cases where the bus/tram stop is at a sidewalk.


if you are concerned about duplicate objects, this would have the same problem

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Selfish Seahorse]

>> Furthermore,
>> double tagging doesn't work if the sidewalk is called 'X Road' and the
>> bus stop 'Y Square'.
>
>
> in this case you’ll have a platform object and a sidewalk object that happen 
> to be at the same place.

But that way you say that there are two separate objects, which isn't
true: it's just one physical object that functions both as a sidewalk
and a platform.

Because two name tags on the same object doesn't work, I think it is
best to map the sidewalk as a way and public_transport=platform as a
node for cases where the bus/tram stop is at a sidewalk.


On 30 March 2018 at 17:30, Martin Koppenhoefer  wrote:
>
>
> sent from a phone
>
>> On 30. Mar 2018, at 11:06, Selfish Seahorse  
>> wrote:
>>
>> Furthermore,
>> double tagging doesn't work if the sidewalk is called 'X Road' and the
>> bus stop 'Y Square'.
>
>
> in this case you’ll have a platform object and a sidewalk object that happen 
> to be at the same place.
>
> cheers,
> Martin
> ___
> 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] Still RFC — Drop stop positions and platforms

[Christian Müller]

I'd go with function.  If sth. is tagged public_transport=platform
then within the scope of public transport this sth. /functions/ as a
platform.

It does not make sense to view this as a structure or "structure only"
tag, since it is not very specific about the physical realization.
I.e. material, shape, usage, condition vary greatly, while the function
of all realizations is a common denominator of all.

Sticking to this makes it easy to use it in combination with tags that
predominantly seek to describe physical properties (e.g. surface or
similar) and its also easier to understand that this function may be
shared with other functions (e.g. sidewalk).

Imho there is no concrete (read specific) realization associated with
the terms platform or sidewalk.  There is an expectation that sth.
physical exists that may be used to stand, walk or wait on, but in
general there is no surface (concrete, grass, carpet, paving
stones, etc.) or dimension attributes commonly associated when
the terms are used.

Let's lend a picture from another subject: Talking about fruits, ..
once the term is an abstraction for some instances (apples, bananas,
etc.), then someone announcing to give away a fruit won't let the
receiver(s) associate to a specific one (with confidence) until it
is seen, smelt, felt or tasted.

Same with a platform - unless a photo, description or survey reveals
key physical features, there is quite some room for speculation wrt
physical instances.


Greetings
cmuelle8

> Gesendet: Samstag, 31. März 2018 um 09:23 Uhr
> Von: "Selfish Seahorse" <selfishseaho...@gmail.com>
> An: "Tag discussion, strategy and related tools" <tagging@openstreetmap.org>
> Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms
>
> Is public_transport=platform now about the structure or the function?
> 
> If it is about the function, then we need a separate tag for the
> platform structure.
> 
> If it is about the structure, then we should decide to either map the
> sidewalk or public_transport=platform (depending on how we define a
> platform). Otherwise, we say that there are two physical structures,
> which is wrong.

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Selfish Seahorse]

Having two *=platform tags per bus/tram stop doesn't make public transport
tagging more straightforward in my opinion.

Either PTv1 + line variants or PTv2 - stop position + waiting area seems to
achieve this goal better.

On Saturday, March 31, 2018, Johnparis <ok...@johnfreed.com> wrote:

> I independently reached a conclusion similar to Jo's. No need for a
> separate tag; the difference is made clear when you look at whether it's a
> node, way or area. And there are lots of optional tags to indicate
> structural elements like benches, shelters, tactile pavement, etc.
>
> I don't usually go beyond platform nodes, but if others have tagged
> wait-point ways/areas as public_transport=platform (or highway=platform, or
> even highway=pedestrian), I let them be.
>
> The conclusion I'm reaching (for bus routes, anyhow) is that only platform
> nodes should be included in the relations (along with the ways that
> comprise the routes). In particular, platforms that are ways or areas
> should not be included in the relations, nor should stop positions. (All of
> these could be included in stop area relations.)
>
> This implies the following changes to v2:
>
> 1) every platform node should have mandatory {mode}=yes tag(s)
> 2) stop_positions should be optional on the map and should not be included
> in the route relations
>
> I'm inclined to agree with the wiki that the v1 tags on nodes should
> remain (including the two million highway=bus_stop tags).
>
> I don't really see a big advantage in changing the value of the v2 tag
> from public_transport=platform to something like public_transport=wait_area
> (and there are about one million public_transport=platform tags at the
> moment).
>
> John
>
> On Sat, Mar 31, 2018 at 9:46 AM, Jo <winfi...@gmail.com> wrote:
>
>> highway=platform and railway=platform on a WAY or an AREA are perfectly
>> fine tags for such platforms, where they exist. Until about a year ago I
>> was also adding public_transport=platform to these ways, but as it creates
>> confusion with the platform NODES, which as far as I am concerned represent
>> the bus and tram stops, I stopped doing that.
>>
>> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/PT_Assistan
>> t/Mapping_Public_Transport_with_JOSM
>>
>> Jo
>>
>> 2018-03-31 9:23 GMT+02:00 Selfish Seahorse <selfishseaho...@gmail.com>:
>>
>>> Is public_transport=platform now about the structure or the function?
>>>
>>> If it is about the function, then we need a separate tag for the
>>> platform structure.
>>>
>>> If it is about the structure, then we should decide to either map the
>>> sidewalk or public_transport=platform (depending on how we define a
>>> platform). Otherwise, we say that there are two physical structures,
>>> which is wrong.
>>>
>>> On 30 March 2018 at 19:41, "Christian Müller" <cmu...@gmx.de> wrote:
>>> >> Gesendet: Freitag, 30. März 2018 um 11:06 Uhr
>>> >> Von: "Selfish Seahorse" <selfishseaho...@gmail.com>
>>> >> An: "Tag discussion, strategy and related tools" <
>>> tagging@openstreetmap.org>
>>> >> Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms
>>> >>
>>> >> I wouldn't call a sidewalk a platform, especially because the waiting
>>> >> area on the sidewalk often isn't clearly delimited. Furthermore,
>>> >> double tagging doesn't work if the sidewalk is called 'X Road' and the
>>> >> bus stop 'Y Square'.
>>> >>
>>> >
>>> > If a sidewalk _functions_ as a platform, than you can indeed call that
>>> > part of the sidewalk a platform, depending on which role of the area
>>> > you are currently talking about.  This is time-dependent:
>>> >
>>> > If lots of people are standing and waiting on that sidewalk for a
>>> > vehicle to arrive, it will be easier for you to see why this is (also)
>>> > a platform, than e.g. at night time without a PT service serving the
>>> > halt.
>>> >
>>> > A thing as simple as a box may be used as a table or chair.  This is
>>> > the same thing here.  You have a physical structure that is so simple
>>> > that it may function as a platform or a sidewalk, depending on current
>>> > use.
>>> >
>>> >
>>> > Greetings
>>> > cmuelle8
>>> >
>>> > ___
>>> > Tagging mailing list
>>> > Tagging@openstreetmap.org
>>> > https://lists.openstreetmap.org/listinfo/tagging
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>>
>> ___
>> 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] Still RFC — Drop stop positions and platforms

[Johnparis]

One point that hasn't been discussed (and isn't in the subject line) is
that part of Ilya's proposal is to also drop stations.

I would move in the opposite direction and expand the role of stations.
Here's why.

In many (many) cases, GTFS data from bus operators includes a single
StopPoint value for what are in fact multiple stopping points (platforms)
within a station. It would greatly simplify matters if the *station* itself
could be considered the platform. I would suggest this could be
accomplished by including the station (node/way/area) in the route relation
with the role "station" (or, as appropriate, station_entry_only or
station_exit_only).

Not sure what usefulness, if any, this would have for rail routes.



On Sat, Mar 31, 2018 at 9:46 AM, Jo <winfi...@gmail.com> wrote:

> highway=platform and railway=platform on a WAY or an AREA are perfectly
> fine tags for such platforms, where they exist. Until about a year ago I
> was also adding public_transport=platform to these ways, but as it creates
> confusion with the platform NODES, which as far as I am concerned represent
> the bus and tram stops, I stopped doing that.
>
> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/PT_
> Assistant/Mapping_Public_Transport_with_JOSM
>
> Jo
>
> 2018-03-31 9:23 GMT+02:00 Selfish Seahorse <selfishseaho...@gmail.com>:
>
>> Is public_transport=platform now about the structure or the function?
>>
>> If it is about the function, then we need a separate tag for the
>> platform structure.
>>
>> If it is about the structure, then we should decide to either map the
>> sidewalk or public_transport=platform (depending on how we define a
>> platform). Otherwise, we say that there are two physical structures,
>> which is wrong.
>>
>> On 30 March 2018 at 19:41, "Christian Müller" <cmu...@gmx.de> wrote:
>> >> Gesendet: Freitag, 30. März 2018 um 11:06 Uhr
>> >> Von: "Selfish Seahorse" <selfishseaho...@gmail.com>
>> >> An: "Tag discussion, strategy and related tools" <
>> tagging@openstreetmap.org>
>> >> Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms
>> >>
>> >> I wouldn't call a sidewalk a platform, especially because the waiting
>> >> area on the sidewalk often isn't clearly delimited. Furthermore,
>> >> double tagging doesn't work if the sidewalk is called 'X Road' and the
>> >> bus stop 'Y Square'.
>> >>
>> >
>> > If a sidewalk _functions_ as a platform, than you can indeed call that
>> > part of the sidewalk a platform, depending on which role of the area
>> > you are currently talking about.  This is time-dependent:
>> >
>> > If lots of people are standing and waiting on that sidewalk for a
>> > vehicle to arrive, it will be easier for you to see why this is (also)
>> > a platform, than e.g. at night time without a PT service serving the
>> > halt.
>> >
>> > A thing as simple as a box may be used as a table or chair.  This is
>> > the same thing here.  You have a physical structure that is so simple
>> > that it may function as a platform or a sidewalk, depending on current
>> > use.
>> >
>> >
>> > Greetings
>> > cmuelle8
>> >
>> > ___
>> > Tagging mailing list
>> > Tagging@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/tagging
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> ___
> 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] Still RFC — Drop stop positions and platforms

[Johnparis]

I independently reached a conclusion similar to Jo's. No need for a
separate tag; the difference is made clear when you look at whether it's a
node, way or area. And there are lots of optional tags to indicate
structural elements like benches, shelters, tactile pavement, etc.

I don't usually go beyond platform nodes, but if others have tagged
wait-point ways/areas as public_transport=platform (or highway=platform, or
even highway=pedestrian), I let them be.

The conclusion I'm reaching (for bus routes, anyhow) is that only platform
nodes should be included in the relations (along with the ways that
comprise the routes). In particular, platforms that are ways or areas
should not be included in the relations, nor should stop positions. (All of
these could be included in stop area relations.)

This implies the following changes to v2:

1) every platform node should have mandatory {mode}=yes tag(s)
2) stop_positions should be optional on the map and should not be included
in the route relations

I'm inclined to agree with the wiki that the v1 tags on nodes should remain
(including the two million highway=bus_stop tags).

I don't really see a big advantage in changing the value of the v2 tag from
public_transport=platform to something like public_transport=wait_area (and
there are about one million public_transport=platform tags at the moment).

John

On Sat, Mar 31, 2018 at 9:46 AM, Jo <winfi...@gmail.com> wrote:

> highway=platform and railway=platform on a WAY or an AREA are perfectly
> fine tags for such platforms, where they exist. Until about a year ago I
> was also adding public_transport=platform to these ways, but as it creates
> confusion with the platform NODES, which as far as I am concerned represent
> the bus and tram stops, I stopped doing that.
>
> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/PT_
> Assistant/Mapping_Public_Transport_with_JOSM
>
> Jo
>
> 2018-03-31 9:23 GMT+02:00 Selfish Seahorse <selfishseaho...@gmail.com>:
>
>> Is public_transport=platform now about the structure or the function?
>>
>> If it is about the function, then we need a separate tag for the
>> platform structure.
>>
>> If it is about the structure, then we should decide to either map the
>> sidewalk or public_transport=platform (depending on how we define a
>> platform). Otherwise, we say that there are two physical structures,
>> which is wrong.
>>
>> On 30 March 2018 at 19:41, "Christian Müller" <cmu...@gmx.de> wrote:
>> >> Gesendet: Freitag, 30. März 2018 um 11:06 Uhr
>> >> Von: "Selfish Seahorse" <selfishseaho...@gmail.com>
>> >> An: "Tag discussion, strategy and related tools" <
>> tagging@openstreetmap.org>
>> >> Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms
>> >>
>> >> I wouldn't call a sidewalk a platform, especially because the waiting
>> >> area on the sidewalk often isn't clearly delimited. Furthermore,
>> >> double tagging doesn't work if the sidewalk is called 'X Road' and the
>> >> bus stop 'Y Square'.
>> >>
>> >
>> > If a sidewalk _functions_ as a platform, than you can indeed call that
>> > part of the sidewalk a platform, depending on which role of the area
>> > you are currently talking about.  This is time-dependent:
>> >
>> > If lots of people are standing and waiting on that sidewalk for a
>> > vehicle to arrive, it will be easier for you to see why this is (also)
>> > a platform, than e.g. at night time without a PT service serving the
>> > halt.
>> >
>> > A thing as simple as a box may be used as a table or chair.  This is
>> > the same thing here.  You have a physical structure that is so simple
>> > that it may function as a platform or a sidewalk, depending on current
>> > use.
>> >
>> >
>> > Greetings
>> > cmuelle8
>> >
>> > ___
>> > Tagging mailing list
>> > Tagging@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/tagging
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> ___
> 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] Still RFC — Drop stop positions and platforms

[Jo]

highway=platform and railway=platform on a WAY or an AREA are perfectly
fine tags for such platforms, where they exist. Until about a year ago I
was also adding public_transport=platform to these ways, but as it creates
confusion with the platform NODES, which as far as I am concerned represent
the bus and tram stops, I stopped doing that.

https://wiki.openstreetmap.org/wiki/JOSM/Plugins/PT_Assistant/Mapping_Public_Transport_with_JOSM

Jo

2018-03-31 9:23 GMT+02:00 Selfish Seahorse <selfishseaho...@gmail.com>:

> Is public_transport=platform now about the structure or the function?
>
> If it is about the function, then we need a separate tag for the
> platform structure.
>
> If it is about the structure, then we should decide to either map the
> sidewalk or public_transport=platform (depending on how we define a
> platform). Otherwise, we say that there are two physical structures,
> which is wrong.
>
> On 30 March 2018 at 19:41, "Christian Müller" <cmu...@gmx.de> wrote:
> >> Gesendet: Freitag, 30. März 2018 um 11:06 Uhr
> >> Von: "Selfish Seahorse" <selfishseaho...@gmail.com>
> >> An: "Tag discussion, strategy and related tools" <
> tagging@openstreetmap.org>
> >> Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms
> >>
> >> I wouldn't call a sidewalk a platform, especially because the waiting
> >> area on the sidewalk often isn't clearly delimited. Furthermore,
> >> double tagging doesn't work if the sidewalk is called 'X Road' and the
> >> bus stop 'Y Square'.
> >>
> >
> > If a sidewalk _functions_ as a platform, than you can indeed call that
> > part of the sidewalk a platform, depending on which role of the area
> > you are currently talking about.  This is time-dependent:
> >
> > If lots of people are standing and waiting on that sidewalk for a
> > vehicle to arrive, it will be easier for you to see why this is (also)
> > a platform, than e.g. at night time without a PT service serving the
> > halt.
> >
> > A thing as simple as a box may be used as a table or chair.  This is
> > the same thing here.  You have a physical structure that is so simple
> > that it may function as a platform or a sidewalk, depending on current
> > use.
> >
> >
> > Greetings
> > cmuelle8
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> 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] Still RFC — Drop stop positions and platforms

[Selfish Seahorse]

Is public_transport=platform now about the structure or the function?

If it is about the function, then we need a separate tag for the
platform structure.

If it is about the structure, then we should decide to either map the
sidewalk or public_transport=platform (depending on how we define a
platform). Otherwise, we say that there are two physical structures,
which is wrong.

On 30 March 2018 at 19:41, "Christian Müller" <cmu...@gmx.de> wrote:
>> Gesendet: Freitag, 30. März 2018 um 11:06 Uhr
>> Von: "Selfish Seahorse" <selfishseaho...@gmail.com>
>> An: "Tag discussion, strategy and related tools" <tagging@openstreetmap.org>
>> Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms
>>
>> I wouldn't call a sidewalk a platform, especially because the waiting
>> area on the sidewalk often isn't clearly delimited. Furthermore,
>> double tagging doesn't work if the sidewalk is called 'X Road' and the
>> bus stop 'Y Square'.
>>
>
> If a sidewalk _functions_ as a platform, than you can indeed call that
> part of the sidewalk a platform, depending on which role of the area
> you are currently talking about.  This is time-dependent:
>
> If lots of people are standing and waiting on that sidewalk for a
> vehicle to arrive, it will be easier for you to see why this is (also)
> a platform, than e.g. at night time without a PT service serving the
> halt.
>
> A thing as simple as a box may be used as a table or chair.  This is
> the same thing here.  You have a physical structure that is so simple
> that it may function as a platform or a sidewalk, depending on current
> use.
>
>
> Greetings
> cmuelle8
>
> ___
> 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] Still RFC — Drop stop positions and platforms

[Christian Müller]

> Gesendet: Freitag, 30. März 2018 um 11:29 Uhr
> Von: "Selfish Seahorse" <selfishseaho...@gmail.com>
> An: "Tag discussion, strategy and related tools" <tagging@openstreetmap.org>
> Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms
>
> In my opinion, it's never too late to look for alternatives.

+1, if it is an alternative.  Read: A proposal that addresses the same
needs to the same extent.  Dropping some part of an existing proposal
does seem to create gaps, rather than bridge them, imho.

cmuelle8

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Christian Müller]

> Gesendet: Freitag, 30. März 2018 um 11:06 Uhr
> Von: "Selfish Seahorse" <selfishseaho...@gmail.com>
> An: "Tag discussion, strategy and related tools" <tagging@openstreetmap.org>
> Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms
>
> I wouldn't call a sidewalk a platform, especially because the waiting
> area on the sidewalk often isn't clearly delimited. Furthermore,
> double tagging doesn't work if the sidewalk is called 'X Road' and the
> bus stop 'Y Square'.
> 

If a sidewalk _functions_ as a platform, than you can indeed call that
part of the sidewalk a platform, depending on which role of the area
you are currently talking about.  This is time-dependent:

If lots of people are standing and waiting on that sidewalk for a
vehicle to arrive, it will be easier for you to see why this is (also)
a platform, than e.g. at night time without a PT service serving the
halt.

A thing as simple as a box may be used as a table or chair.  This is
the same thing here.  You have a physical structure that is so simple
that it may function as a platform or a sidewalk, depending on current
use.


Greetings
cmuelle8

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Christian Müller]

"wild" platform - the opposite of a built, dedicated platform structure

 

An example for both:

 

wild - a road with a grass strip and a PT post stuck in the ground,

people have to use the grass strip; over time it may have an "upgrade"

using fine gravel to compensate for the dirt revealed by the grass stepped

down

 

dedicated - a platform made of paving_stones or other solid material, may

be equipped with additional street furniture (shelter, tactile paving, bins, etc.)

 

You may find wild platforms (i.e. non-dedicated ones)  in secluded areas

with very low passenger frequency.  Profit-wise such stops are usually

inattractive to a company, so unless they are tax sponsored they often

are a target of consolidation.  An analogy is a wild path, e.g. when people

"shortcut" park meadows - it's a path for usage frequency, not because

it was built for or dedicated to this purpose.

 

 

Tagging wild platforms is addressed by PTv2.  As pointed out previously

platform nodes may be used to indicate these. 

 

 

Greetings

cmuelle8

 



Gesendet: Freitag, 30. März 2018 um 08:56 Uhr
Von: Johnparis <ok...@johnfreed.com>
An: "Tag discussion, strategy and related tools" <tagging@openstreetmap.org>
Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms


I don't think a tag is needed for "wild" platforms. As already noted, public_transport=platform applies to nodes already. And shelter=yes/no or bench=yes/no can be added if that's the infrastructure Christian means. (Not clear to me what exactly a "wild" platform is.)





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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Martin Koppenhoefer]

sent from a phone

> On 30. Mar 2018, at 11:06, Selfish Seahorse  wrote:
> 
> Furthermore,
> double tagging doesn't work if the sidewalk is called 'X Road' and the
> bus stop 'Y Square'.


in this case you’ll have a platform object and a sidewalk object that happen to 
be at the same place.

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Martin Koppenhoefer]

sent from a phone

> On 30. Mar 2018, at 08:56, Johnparis  wrote:
> 
> 
> As has been noted elsewhere, public_transport=platform was probably not an 
> ideal word choice, perhaps wait_area or some such would have been better, but 
> it is what it is.


according to a dictionary, in BE platform also means “the floor area at the 
entrance to a bus.” (not necessarily the same as the waiting area) while the 
same dictionary requires for rail based transportation that the platform be 
“raised”

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[nwastra]

I rarely do public transport tagging but found that using the new tag for a bus 
stop did not render so I had to add the old version of the tag to render. I may 
be in error here due to not being very familiar with the transport schemes. You 
may call that tagging for the renderer but i see very little point in adding 
anything to the osm database if it does not render on the standard map.

N

> On 31 Mar 2018, at 12:55 am, Martin Koppenhoefer  
> wrote:
> 
> 
> 
> sent from a phone
> 
>> On 29. Mar 2018, at 03:56, Daniel Koć  wrote:
>> 
>> Double tagging is a problem too
> 
> 
> can you please explain what you mean with “double tagging” and what the 
> problem is?
> 
> cheers,
> Martin 
> ___
> 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] Still RFC — Drop stop positions and platforms

[Martin Koppenhoefer]

sent from a phone

> On 29. Mar 2018, at 09:37, Topographe Fou  wrote:
> 
> One thing I never understood was why we have to maintain two schemas 
> (probably because consensus was not reached)


it is generally hard in OSM to declare something as better, hence we always 
speak about “alternatives” because every way of mapping might be an advantage 
in some setting / for some question, e.g. when there was only highway=bus_stop 
for bus stops, the discussion was whether to put the stop on the highway or on 
the side of it, and AFAIR both were proclaimed equally valid, each with their 
own pros and cons.

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Martin Koppenhoefer]

sent from a phone

> On 29. Mar 2018, at 03:56, Daniel Koć  wrote:
> 
> Double tagging is a problem too


can you please explain what you mean with “double tagging” and what the problem 
is?

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Jo]

I tag the platform as NODE with:

highway=bus_stop
public_transport=platform
bus=yes
name=
ref=
route_ref=
zone=
...

Because nodes have 1 pair of coordinates, so convenient for direct
comparison with external sources and t's easy to draw text around it with
an offset in MapCSS in JOSM,

If there is a platform, I map it as a way or an area:
highway=platform

Only the platform nodes are added to the route relations.

2018-03-30 13:52 GMT+02:00 Selfish Seahorse <selfishseaho...@gmail.com>:

> If I got you right, you map the platform as a
> public_transport=platform way and add a public_transport=platform node
> in addition?
>
> Why not tag that node public_transport=stop then? This would allow for
> a clear distinction between platform and stop.
>
>
> On 30 March 2018 at 11:52, Jo <winfi...@gmail.com> wrote:
> > When tagging platforms as ways, I wouldn't add details like name to
> them, as
> > the name would already be present on the platform node, which represents
> the
> > stop, both for rendering purposes as for being added to the route
> relations.
> >
> > I would only map a platform as a way, if there is tactile paving, or it's
> > higher than the rest of the sidewalk, or if it's clearly an island
> between
> > main road and cycleway. Before we had the bus_bay=right/left/both, I have
> > been adding platform ways in the shape of the bay. Not sure if that is
> the
> > best practice. As I got used to them, I think they render nicely, but it
> may
> > be exaggerated. They are not mapped for the purpose of adding them to the
> > route relations and there is clearly accommodations for the buses near
> such
> > stops. Most of them look like (narrower) sidewalks though.
> >
> > Jo
> >
> >
> >
> > 2018-03-30 11:06 GMT+02:00 Selfish Seahorse <selfishseaho...@gmail.com>:
> >>
> >> > In this case it is not wrong to tag a fraction of the sidewalk as
> >> > platform, there is dual (multipurpose) use in this case.  There are
> several
> >> > variants, sometimes the paving stones suggest a dedicated area over
> full or
> >> > half of the width, sometimes not.  Since the tags do not conflict
> with the
> >> > highway tags, double tagging with highway=footway
> public_transport=platform
> >> > may be a good way to reflect this ground situation.
> >>
> >> I wouldn't call a sidewalk a platform, especially because the waiting
> >> area on the sidewalk often isn't clearly delimited. Furthermore,
> >> double tagging doesn't work if the sidewalk is called 'X Road' and the
> >> bus stop 'Y Square'.
> >>
> >>
> >> On 29 March 2018 at 23:17, "Christian Müller" <cmu...@gmx.de> wrote:
> >> >> Sent: Thu, 29 Mar 2018 19:55:34 +0200
> >> >> From: "Selfish Seahorse" <selfishseaho...@gmail.com>
> >> >> To: "Tag discussion, strategy and related tools"
> >> >> <tagging@openstreetmap.org>
> >> >> Subject: Re: [Tagging] Still RFC — Drop stop positions and platforms
> >> >>
> >> >> Or, very often, because there's a sidewalk and, therefore, no need
> for
> >> >> a platform.
> >> >
> >> > In this case it is not wrong to tag a fraction of the sidewalk as
> >> > platform,
> >> > there is dual (multipurpose) use in this case.  There are several
> >> > variants,
> >> > sometimes the paving stones suggest a dedicated area over full or half
> >> > of
> >> > the width, sometimes not.  Since the tags do not conflict with the
> >> > highway
> >> > tags, double tagging with highway=footway public_transport=platform
> may
> >> > be
> >> > a good way to reflect this ground situation.
> >> >
> >> > This is also a nice way to see, why and where PT tags perform better
> >> > than
> >> > the legacy tagging - a combination like highway=footway
> highway=platform
> >> > won't do.
> >> >
> >> >> Doesn't b) correspond to how public_transport has been defined? 'If
> >> >> there is no platform in the real world, one can place a node at the
> >> >> pole.'
> >> >
> >> > Yes, it corresponds. I remember seeing kv-pages with the node icon
> >> > crossed out.  Currently this (still?) applies e.g. to
> >> > https://wiki.openstreetmap.org/wiki/DE:Tag:railway%3Dplatform
> >> > It may have affected other platform related pages in the past.
> &g

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Selfish Seahorse]

If I got you right, you map the platform as a
public_transport=platform way and add a public_transport=platform node
in addition?

Why not tag that node public_transport=stop then? This would allow for
a clear distinction between platform and stop.


On 30 March 2018 at 11:52, Jo <winfi...@gmail.com> wrote:
> When tagging platforms as ways, I wouldn't add details like name to them, as
> the name would already be present on the platform node, which represents the
> stop, both for rendering purposes as for being added to the route relations.
>
> I would only map a platform as a way, if there is tactile paving, or it's
> higher than the rest of the sidewalk, or if it's clearly an island between
> main road and cycleway. Before we had the bus_bay=right/left/both, I have
> been adding platform ways in the shape of the bay. Not sure if that is the
> best practice. As I got used to them, I think they render nicely, but it may
> be exaggerated. They are not mapped for the purpose of adding them to the
> route relations and there is clearly accommodations for the buses near such
> stops. Most of them look like (narrower) sidewalks though.
>
> Jo
>
>
>
> 2018-03-30 11:06 GMT+02:00 Selfish Seahorse <selfishseaho...@gmail.com>:
>>
>> > In this case it is not wrong to tag a fraction of the sidewalk as
>> > platform, there is dual (multipurpose) use in this case.  There are several
>> > variants, sometimes the paving stones suggest a dedicated area over full or
>> > half of the width, sometimes not.  Since the tags do not conflict with the
>> > highway tags, double tagging with highway=footway public_transport=platform
>> > may be a good way to reflect this ground situation.
>>
>> I wouldn't call a sidewalk a platform, especially because the waiting
>> area on the sidewalk often isn't clearly delimited. Furthermore,
>> double tagging doesn't work if the sidewalk is called 'X Road' and the
>> bus stop 'Y Square'.
>>
>>
>> On 29 March 2018 at 23:17, "Christian Müller" <cmu...@gmx.de> wrote:
>> >> Sent: Thu, 29 Mar 2018 19:55:34 +0200
>> >> From: "Selfish Seahorse" <selfishseaho...@gmail.com>
>> >> To: "Tag discussion, strategy and related tools"
>> >> <tagging@openstreetmap.org>
>> >> Subject: Re: [Tagging] Still RFC — Drop stop positions and platforms
>> >>
>> >> Or, very often, because there's a sidewalk and, therefore, no need for
>> >> a platform.
>> >
>> > In this case it is not wrong to tag a fraction of the sidewalk as
>> > platform,
>> > there is dual (multipurpose) use in this case.  There are several
>> > variants,
>> > sometimes the paving stones suggest a dedicated area over full or half
>> > of
>> > the width, sometimes not.  Since the tags do not conflict with the
>> > highway
>> > tags, double tagging with highway=footway public_transport=platform may
>> > be
>> > a good way to reflect this ground situation.
>> >
>> > This is also a nice way to see, why and where PT tags perform better
>> > than
>> > the legacy tagging - a combination like highway=footway highway=platform
>> > won't do.
>> >
>> >> Doesn't b) correspond to how public_transport has been defined? 'If
>> >> there is no platform in the real world, one can place a node at the
>> >> pole.'
>> >
>> > Yes, it corresponds. I remember seeing kv-pages with the node icon
>> > crossed out.  Currently this (still?) applies e.g. to
>> > https://wiki.openstreetmap.org/wiki/DE:Tag:railway%3Dplatform
>> > It may have affected other platform related pages in the past.
>> >
>> > So this is yet another example of a problem raised earlier: Legacy
>> > information lingering in the wiki with sparse reference to the suc-
>> > cessor for readers to compare.  As long as a 'deprecated' label is
>> > missing, it seems natural to some extent that there is concurrent
>> > competition between the older and the newer approach to map PT.
>> >
>> >
>> > Greetings
>> > cmuelle8
>> >
>> > ___
>> > Tagging mailing list
>> > Tagging@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/tagging
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> 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] Still RFC — Drop stop positions and platforms

[Jo]

When tagging platforms as ways, I wouldn't add details like name to them,
as the name would already be present on the platform node, which represents
the stop, both for rendering purposes as for being added to the route
relations.

I would only map a platform as a way, if there is tactile paving, or it's
higher than the rest of the sidewalk, or if it's clearly an island between
main road and cycleway. Before we had the bus_bay=right/left/both, I have
been adding platform ways in the shape of the bay. Not sure if that is the
best practice. As I got used to them, I think they render nicely, but it
may be exaggerated. They are not mapped for the purpose of adding them to
the route relations and there is clearly accommodations for the buses near
such stops. Most of them look like (narrower) sidewalks though.

Jo



2018-03-30 11:06 GMT+02:00 Selfish Seahorse <selfishseaho...@gmail.com>:

> > In this case it is not wrong to tag a fraction of the sidewalk as
> platform, there is dual (multipurpose) use in this case.  There are several
> variants, sometimes the paving stones suggest a dedicated area over full or
> half of the width, sometimes not.  Since the tags do not conflict with the
> highway tags, double tagging with highway=footway public_transport=platform
> may be a good way to reflect this ground situation.
>
> I wouldn't call a sidewalk a platform, especially because the waiting
> area on the sidewalk often isn't clearly delimited. Furthermore,
> double tagging doesn't work if the sidewalk is called 'X Road' and the
> bus stop 'Y Square'.
>
>
> On 29 March 2018 at 23:17, "Christian Müller" <cmu...@gmx.de> wrote:
> >> Sent: Thu, 29 Mar 2018 19:55:34 +0200
> >> From: "Selfish Seahorse" <selfishseaho...@gmail.com>
> >> To: "Tag discussion, strategy and related tools" <
> tagging@openstreetmap.org>
> >> Subject: Re: [Tagging] Still RFC — Drop stop positions and platforms
> >>
> >> Or, very often, because there's a sidewalk and, therefore, no need for
> >> a platform.
> >
> > In this case it is not wrong to tag a fraction of the sidewalk as
> platform,
> > there is dual (multipurpose) use in this case.  There are several
> variants,
> > sometimes the paving stones suggest a dedicated area over full or half of
> > the width, sometimes not.  Since the tags do not conflict with the
> highway
> > tags, double tagging with highway=footway public_transport=platform may
> be
> > a good way to reflect this ground situation.
> >
> > This is also a nice way to see, why and where PT tags perform better than
> > the legacy tagging - a combination like highway=footway highway=platform
> > won't do.
> >
> >> Doesn't b) correspond to how public_transport has been defined? 'If
> >> there is no platform in the real world, one can place a node at the
> >> pole.'
> >
> > Yes, it corresponds. I remember seeing kv-pages with the node icon
> > crossed out.  Currently this (still?) applies e.g. to
> > https://wiki.openstreetmap.org/wiki/DE:Tag:railway%3Dplatform
> > It may have affected other platform related pages in the past.
> >
> > So this is yet another example of a problem raised earlier: Legacy
> > information lingering in the wiki with sparse reference to the suc-
> > cessor for readers to compare.  As long as a 'deprecated' label is
> > missing, it seems natural to some extent that there is concurrent
> > competition between the older and the newer approach to map PT.
> >
> >
> > Greetings
> > cmuelle8
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> 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] Still RFC — Drop stop positions and platforms

[Selfish Seahorse]

> And if a tag is needed, stop vs stop_position would surely cause confusion!

If we would map a public_transport=stop node regardless of whether
there's a platform or not and if only public_transport=stop nodes
would be added to route relations then public_transport=stop_position
wouldn't be needed anymore (because for long platform, there is the
information where the vehicle stops) and there would be no confusion.

> As has been noted elsewhere, public_transport=platform was probably not an 
> ideal word choice, perhaps wait_area or some such would have been better, but 
> it is what it is.

It is a scheme that has been around for seven years but hasn't been
adopted widely, which means that something isn't optimal with it.
Seven years is a very long time!

In my opinion, it's never too late to look for alternatives.


On 30 March 2018 at 08:56, Johnparis <ok...@johnfreed.com> wrote:
> I don't think a tag is needed for "wild" platforms. As already noted,
> public_transport=platform applies to nodes already. And shelter=yes/no or
> bench=yes/no can be added if that's the infrastructure Christian means. (Not
> clear to me what exactly a "wild" platform is.)
>
> And if a tag is needed, stop vs stop_position would surely cause confusion!
>
> As has been noted elsewhere, public_transport=platform was probably not an
> ideal word choice, perhaps wait_area or some such would have been better,
> but it is what it is.
>
>
> On Fri, Mar 30, 2018 at 8:45 AM, Selfish Seahorse
> <selfishseaho...@gmail.com> wrote:
>>
>> > If this is a problem, because the tag should ideally discrimnate built
>> > structure features, then either
>> >
>> > a) find a new tag for wild platforms
>>
>> Maybe public_transport=stop?
>>
>>
>> On 29 March 2018 at 16:30, "Christian Müller" <cmu...@gmx.de> wrote:
>> > Mapping public transport in detail was in part started to aid impaired
>> > people and people with diminished mobility.  The stop_position is an
>> > attempt
>> > to tell for large/long platforms at which subarea of the platform you
>> > can
>> > expect a public service vehicle to have an entrance (regardless of its
>> > length, that may change with time of day or when the schedule of the
>> > company
>> > is overhauled).
>> >
>> > The platform itself will not give you any clues which position to route
>> > a
>> > user to so that him/her readjusting position on that platform is minimal
>> > once the vehicle arrived and is ready for boarding.
>> >
>> > If the platform exists, mapping it is more important than the
>> > stop_position,
>> > but the latter gives additional info _especially_ for lengthy or large
>> > platforms.
>> >
>> > -
>> >
>> > There have been complaints about added pseudo-platforms in the data.
>> > This
>> > situation stems from the fact, that platforms are missing on ground (for
>> > lack of money, political decisions or because the halt is seen as a
>> > temporary one).  _Nevertheless_, public transport users _do_ and _have_
>> > to
>> > use parts of the area around the PT-pole as a platform.  In this case
>> > the
>> > tag is not used to map a built structure, but how the space is
>> > effectively
>> > used on ground.  If this is a problem, because the tag should ideally
>> > discrimnate built structure features, then either
>> >
>> > a) find a new tag for wild platforms
>> > b) allow the platform tag on nodes and use a single node only where a
>> > built
>> > platform structure does not exist
>> >
>> > may be an solution.
>> >
>> >
>> > Greetings
>> > cmuelle8
>> >
>> > Gesendet: Donnerstag, 29. März 2018 um 13:36 Uhr
>> > Von: Jo <winfi...@gmail.com>
>> > An: "Tag discussion, strategy and related tools"
>> > <tagging@openstreetmap.org>
>> > Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms
>> > That's what I would like to see happen. Last year I created a wiki page
>> > about it (with screenshots):
>> >
>> >
>> > https://wiki.openstreetmap.org/wiki/JOSM/Plugins/PT_Assistant/Mapping_Public_Transport_with_JOSM#Downloading_data
>> >
>> > Polyglot
>> >
>> > 2018-03-29 13:09 GMT+02:00 Selfish Seahorse <selfishseaho...@gmail.com>:
>> >>
>> >> > Otherwise, public_transport=stop_position could be abandoned, which
>> >> > would make PTv2 tagging a lot easier and more time-efficient.
>> >
>> >
>> > ___
>> > Tagging mailing list
>> > Tagging@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/tagging
>> >
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> 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] Still RFC — Drop stop positions and platforms

[Selfish Seahorse]

> In this case it is not wrong to tag a fraction of the sidewalk as platform, 
> there is dual (multipurpose) use in this case.  There are several variants, 
> sometimes the paving stones suggest a dedicated area over full or half of the 
> width, sometimes not.  Since the tags do not conflict with the highway tags, 
> double tagging with highway=footway public_transport=platform may be a good 
> way to reflect this ground situation.

I wouldn't call a sidewalk a platform, especially because the waiting
area on the sidewalk often isn't clearly delimited. Furthermore,
double tagging doesn't work if the sidewalk is called 'X Road' and the
bus stop 'Y Square'.


On 29 March 2018 at 23:17, "Christian Müller" <cmu...@gmx.de> wrote:
>> Sent: Thu, 29 Mar 2018 19:55:34 +0200
>> From: "Selfish Seahorse" <selfishseaho...@gmail.com>
>> To: "Tag discussion, strategy and related tools" <tagging@openstreetmap.org>
>> Subject: Re: [Tagging] Still RFC — Drop stop positions and platforms
>>
>> Or, very often, because there's a sidewalk and, therefore, no need for
>> a platform.
>
> In this case it is not wrong to tag a fraction of the sidewalk as platform,
> there is dual (multipurpose) use in this case.  There are several variants,
> sometimes the paving stones suggest a dedicated area over full or half of
> the width, sometimes not.  Since the tags do not conflict with the highway
> tags, double tagging with highway=footway public_transport=platform may be
> a good way to reflect this ground situation.
>
> This is also a nice way to see, why and where PT tags perform better than
> the legacy tagging - a combination like highway=footway highway=platform
> won't do.
>
>> Doesn't b) correspond to how public_transport has been defined? 'If
>> there is no platform in the real world, one can place a node at the
>> pole.'
>
> Yes, it corresponds. I remember seeing kv-pages with the node icon
> crossed out.  Currently this (still?) applies e.g. to
> https://wiki.openstreetmap.org/wiki/DE:Tag:railway%3Dplatform
> It may have affected other platform related pages in the past.
>
> So this is yet another example of a problem raised earlier: Legacy
> information lingering in the wiki with sparse reference to the suc-
> cessor for readers to compare.  As long as a 'deprecated' label is
> missing, it seems natural to some extent that there is concurrent
> competition between the older and the newer approach to map PT.
>
>
> Greetings
> cmuelle8
>
> ___
> 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] Still RFC — Drop stop positions and platforms

[Johnparis]

Heh, never noticed that.

iD is now automatically putting bus=yes on the platform node, which seems
clearly correct. The proposal page should be amended, I think.

On Thu, Mar 29, 2018 at 12:33 PM, Selfish Seahorse <
selfishseaho...@gmail.com> wrote:

> > It seems that one major issue was that, given a simple
> public_transport=platform situation, which icon should be used to render
> it? In many cases there isn't a {mode}=yes tag.
>
> This is because according to the PTv2 proposal the transportation
> vehicle tags (bus=yes, tram=yes etc.) have to be put on the stop
> position node, not on the platform node. [^1] This problem could be
> solved if we agree to put them on platform node instead.
>
> [^1]:  Public_Transport#Stop>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Selfish Seahorse]

> If this is a problem, because the tag should ideally discrimnate built 
> structure features, then either
>
> a) find a new tag for wild platforms

Maybe public_transport=stop?


On 29 March 2018 at 16:30, "Christian Müller" <cmu...@gmx.de> wrote:
> Mapping public transport in detail was in part started to aid impaired
> people and people with diminished mobility.  The stop_position is an attempt
> to tell for large/long platforms at which subarea of the platform you can
> expect a public service vehicle to have an entrance (regardless of its
> length, that may change with time of day or when the schedule of the company
> is overhauled).
>
> The platform itself will not give you any clues which position to route a
> user to so that him/her readjusting position on that platform is minimal
> once the vehicle arrived and is ready for boarding.
>
> If the platform exists, mapping it is more important than the stop_position,
> but the latter gives additional info _especially_ for lengthy or large
> platforms.
>
> -
>
> There have been complaints about added pseudo-platforms in the data.  This
> situation stems from the fact, that platforms are missing on ground (for
> lack of money, political decisions or because the halt is seen as a
> temporary one).  _Nevertheless_, public transport users _do_ and _have_ to
> use parts of the area around the PT-pole as a platform.  In this case the
> tag is not used to map a built structure, but how the space is effectively
> used on ground.  If this is a problem, because the tag should ideally
> discrimnate built structure features, then either
>
> a) find a new tag for wild platforms
> b) allow the platform tag on nodes and use a single node only where a built
> platform structure does not exist
>
> may be an solution.
>
>
> Greetings
> cmuelle8
>
> Gesendet: Donnerstag, 29. März 2018 um 13:36 Uhr
> Von: Jo <winfi...@gmail.com>
> An: "Tag discussion, strategy and related tools" <tagging@openstreetmap.org>
> Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms
> That's what I would like to see happen. Last year I created a wiki page
> about it (with screenshots):
>
> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/PT_Assistant/Mapping_Public_Transport_with_JOSM#Downloading_data
>
> Polyglot
>
> 2018-03-29 13:09 GMT+02:00 Selfish Seahorse <selfishseaho...@gmail.com>:
>>
>> > Otherwise, public_transport=stop_position could be abandoned, which
>> > would make PTv2 tagging a lot easier and more time-efficient.
>
>
> ___
> 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] Still RFC — Drop stop positions and platforms

[Johnparis]

Thanks for that last point, Christian. Always good to read the
documentation! The English version (emphasis mine) reads:

These 'traditional' tags are still widely used and are not invalidated by
this scheme and ***should be kept*** in order to ensure compatibility with
legacy software, at the price of redundancy.

If the goal is not to break legacy software, then these legacy tags
"should" also be added going forward, no? So it's not just a case of
co-existing like in forever, but also tagging using v1 and v2 like in
forever. Consider Polyglot's point about tagging bus stops with
highway=bus_stop+public_transport=platform+bus=yes, which in fact is what
ID now does automatically. So we can expect this to be the norm.

Since "highway=bus_stop" is wrong when the platform is a way, it's
necessary to have at least one node tagged (either on the way or possibly
inside it if it's an area) with v1 information. Which is exactly what I
have been doing with bus platforms that have been mapped as ways. And only
including the node in the relation(s).

In general I have not been including the stop positions in the relations,
although I have been including stop positions for the terminal points. Upon
reflection and after reading this discussion, I think it's best just to
include the platforms in the relations, with the terminal points being
marked with the appropriate role (platform_exit_only or
platform_entry_only).

On Thu, Mar 29, 2018 at 11:36 PM, "Christian Müller"  wrote:

> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dplatform
>
> does have a legacy banner, but contrary
>
> https://wiki.openstreetmap.org/wiki/DE:Tag:public_transport%3Dplatform
>
> writes that legacy tags should co-exist (like in forever)
> even if PTv2 tags are present.
>
> If few people read the wiki, then those that do find inconsistent
> tagging guides.  Shaping the wiki to be consistent in what is says
> on all ends is a ressource problem, but this does not invalidate
> the progress made with PTv2 in general.
>
>
> Greetings
> cmuelle8
>
> ___
> 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] Still RFC — Drop stop positions and platforms

[Christian Müller]

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dplatform

does have a legacy banner, but contrary

https://wiki.openstreetmap.org/wiki/DE:Tag:public_transport%3Dplatform

writes that legacy tags should co-exist (like in forever)
even if PTv2 tags are present.

If few people read the wiki, then those that do find inconsistent
tagging guides.  Shaping the wiki to be consistent in what is says
on all ends is a ressource problem, but this does not invalidate
the progress made with PTv2 in general.


Greetings
cmuelle8

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Daniel Koć]

W dniu 29.03.2018 o 09:43, Johnparis pisze:
> I have spent some time reading  
> https://github.com/gravitystorm/openstreetmap-carto/issues/435
> and
> https://github.com/gravitystorm/openstreetmap-carto/issues/331

Great! I will try to do it too, but thanks for the summary anyway.

> It seems that one major issue was that, given a simple
> public_transport=platform situation, which icon should be used to
> render it? In many cases there isn't a {mode}=yes tag.

I don't think that platform should always have an icon. It might be
clear from the context if it's a train, tram or ferry, for example.
Icons for buses however make sense for me, because there is no trail
visible on a default map to spot them.

> A third concern was double-rendering. If both a highway=bus_stop node
> and a public_transport=platform node exist, won't mappers want to
> remove the duplicate? I would hope so! Alternatively, if a stop area
> is mapped with both public_transport=platform
> and public_transport=stop_position, won't that make the map messy?
> That, it seems to me, is a valid consideration. It was proposed to NOT
> render public_transport=stop_position in all cases, which frankly I
> agree with when the node is on a highway (not clear to me when it's on
> a railway, as I don't have experience there).

I don't want to render stop position on default map. It worked great for
a half-automated bus routing updates in Warsaw (we were able to catch up
with the changes and the positions were accurate, without expensive
guessing), so I wouldn't like to get rid of them, but I think this is
not what people are looking for on the map.

I also hope that this will make the schema transition reality. When I
started using Tag History tool I was surprised to find that some
transitions went smooth without proper change in our rendering (like
emergency phones - full transition half a year before visual change,
IIRC), but some more substantial things like landuse->landcover or
platforms need some support from the rendering department to happen in
my opinion.

> The last issue, raised by kocio-pl, who I assume is Daniel Koć of this
> thread, is that someone needs to write the code.

Yes, that's me. We are looking for coders (of all the types of features,
including simple cleaning), because at the moment it's our scarcest
resource - on the other hand the ideas are cheap, because we have a lot
of them...

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Selfish Seahorse]

> There have been complaints about added pseudo-platforms in the data. This 
> situation stems from the fact, that platforms are missing on ground (for lack 
> of money, political decisions or because the halt is seen as a temporary one).

Or, very often, because there's a sidewalk and, therefore, no need for
a platform.

> If this is a problem, because the tag should ideally discrimnate built 
> structure features, then either
>
> a) find a new tag for wild platforms
> b) allow the platform tag on nodes and use a single node only where a built 
> platform structure does not exist

Doesn't b) correspond to how public_transport has been defined? 'If
there is no platform in the real world, one can place a node at the
pole.' [^1]

[^1]: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Platform


On 29 March 2018 at 16:30, "Christian Müller" <cmu...@gmx.de> wrote:
> Mapping public transport in detail was in part started to aid impaired
> people and people with diminished mobility.  The stop_position is an attempt
> to tell for large/long platforms at which subarea of the platform you can
> expect a public service vehicle to have an entrance (regardless of its
> length, that may change with time of day or when the schedule of the company
> is overhauled).
>
> The platform itself will not give you any clues which position to route a
> user to so that him/her readjusting position on that platform is minimal
> once the vehicle arrived and is ready for boarding.
>
> If the platform exists, mapping it is more important than the stop_position,
> but the latter gives additional info _especially_ for lengthy or large
> platforms.
>
> -
>
> There have been complaints about added pseudo-platforms in the data.  This
> situation stems from the fact, that platforms are missing on ground (for
> lack of money, political decisions or because the halt is seen as a
> temporary one).  _Nevertheless_, public transport users _do_ and _have_ to
> use parts of the area around the PT-pole as a platform.  In this case the
> tag is not used to map a built structure, but how the space is effectively
> used on ground.  If this is a problem, because the tag should ideally
> discrimnate built structure features, then either
>
> a) find a new tag for wild platforms
> b) allow the platform tag on nodes and use a single node only where a built
> platform structure does not exist
>
> may be an solution.
>
>
> Greetings
> cmuelle8
>
> Gesendet: Donnerstag, 29. März 2018 um 13:36 Uhr
> Von: Jo <winfi...@gmail.com>
> An: "Tag discussion, strategy and related tools" <tagging@openstreetmap.org>
> Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms
> That's what I would like to see happen. Last year I created a wiki page
> about it (with screenshots):
>
> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/PT_Assistant/Mapping_Public_Transport_with_JOSM#Downloading_data
>
> Polyglot
>
> 2018-03-29 13:09 GMT+02:00 Selfish Seahorse <selfishseaho...@gmail.com>:
>>
>> > Otherwise, public_transport=stop_position could be abandoned, which
>> > would make PTv2 tagging a lot easier and more time-efficient.
>
>
> ___
> 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] Still RFC — Drop stop positions and platforms

[Christian Müller]

> Sent: Wed, 28 Mar 2018 22:20:21 +0200 
> From: "Michael Reichert" <osm...@michreichert.de>
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] Still RFC — Drop stop positions and platforms
>
> - If someone writes such a complicated proposal, he should ask the
> authors of map styles (if he isn't someone himself) for their opinion on
> the new tags. public_transport=stop_position/platform isn't easy to
> render without taking highway=bus_stop into account because (1)
> platforms do not have to be tagged with bus/tram/train/subway=yes and
> because you do not have to map both the platform and the stop. If you
> render only stop positions or only platforms, you will miss features in
> some areas. If you render both, you will have duplicated map icons.

You argue that we do have a platform or a stop_position or both in
any case  and  that a single map object is to be rendered ultimately.

The latter is an abstraction (specific rendering) of an abstraction
(data in the db complying to some model) of the situation on ground.

However, on high zoom scales, it does make sense to render both,
the stop_position and the platform, if both exist.  Lower zoom
scales should merge both in an icon, maybe.

I agree that rendering is difficult to some extent, if the data
is detailed, but it reflects the situation on ground adequately.
With less detail in the data, it is also less useful.  Rendered
maps are an important, but not the only use of OSM data.

bus/tram/train/subway=yes  are  _not_ optional for a specific
platform, these tags are mandatory in accordance to the modes
served by a _specific_ platform.  The reason this tag is set
optional is because not all modes apply to _all_ platforms all
the time.  Maybe documentation of this needs improvement.

However, even if the mode of the platform or stop_position is
not tagged, a generic PT symbol can be an appropiate rendering.


If I understand you correctly, it is hard to relate a stop_position
to a platform if they do not happen to reside in an osm relation at
the same time.  You need to do distance calculations ('around') in
this case, just to decide on low zoom scales  to not draw an icon
twice!?  This _is_ a rendering problem indeed, but it's not specific
to PTv2 (platforms and bus_stop nodes have existed before).


Greetings
cmuelle8

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Christian Müller]

Mapping public transport in detail was in part started to aid impaired people and people with diminished mobility.  The stop_position is an attempt to tell for large/long platforms at which subarea of the platform you can expect a public service vehicle to have an entrance (regardless of its length, that may change with time of day or when the schedule of the company is overhauled).

 

The platform itself will not give you any clues which position to route a user to so that him/her readjusting position on that platform is minimal once the vehicle arrived and is ready for boarding.

 

If the platform exists, mapping it is more important than the stop_position, but the latter gives additional info _especially_ for lengthy or large platforms.

 

-

 

There have been complaints about added pseudo-platforms in the data.  This situation stems from the fact, that platforms are missing on ground (for lack of money, political decisions or because the halt is seen as a temporary one).  _Nevertheless_, public transport users _do_ and _have_ to use parts of the area around the PT-pole as a platform.  In this case the tag is not used to map a built structure, but how the space is effectively used on ground.  If this is a problem, because the tag should ideally discrimnate built structure features, then either

 

a) find a new tag for wild platforms

b) allow the platform tag on nodes and use a single node only where a built platform structure does not exist

 

may be an solution.

 

 

Greetings

cmuelle8

 

Gesendet: Donnerstag, 29. März 2018 um 13:36 Uhr
Von: Jo <winfi...@gmail.com>
An: "Tag discussion, strategy and related tools" <tagging@openstreetmap.org>
Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms


That's what I would like to see happen. Last year I created a wiki page about it (with screenshots):
 

https://wiki.openstreetmap.org/wiki/JOSM/Plugins/PT_Assistant/Mapping_Public_Transport_with_JOSM#Downloading_data

 

Polyglot


 
2018-03-29 13:09 GMT+02:00 Selfish Seahorse <selfishseaho...@gmail.com>:

> Otherwise, public_transport=stop_position could be abandoned, which would make PTv2 tagging a lot easier and more time-efficient.







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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Jo]

That's what I would like to see happen. Last year I created a wiki page
about it (with screenshots):

https://wiki.openstreetmap.org/wiki/JOSM/Plugins/PT_Assistant/Mapping_Public_Transport_with_JOSM#Downloading_data

Polyglot

2018-03-29 13:09 GMT+02:00 Selfish Seahorse :

> > Otherwise, public_transport=stop_position could be abandoned, which
> would make PTv2 tagging a lot easier and more time-efficient.
>
> Or at least exclude them from route relations.
>
>
> On 29 March 2018 at 12:33, Selfish Seahorse 
> wrote:
> >> It seems that one major issue was that, given a simple
> public_transport=platform situation, which icon should be used to render
> it? In many cases there isn't a {mode}=yes tag.
> >
> > This is because according to the PTv2 proposal the transportation
> > vehicle tags (bus=yes, tram=yes etc.) have to be put on the stop
> > position node, not on the platform node. [^1] This problem could be
> > solved if we agree to put them on platform node instead.
> >
> > [^1]:  Public_Transport#Stop>
> >
> >> My contribution to solving that issue is attached -- a generic transit
> icon which I hereby put into the public domain. I think this icon should be
> used (a) when there is no indicator of the transport mode, or (b) when
> there are multiple modes, as in https://www.openstreetmap.org/way/66332939
> >
> > If multiple transportation vehicles serve a platform, it would be
> > useful to have an icon for every vehicle rendered next to one another,
> > as here: https://www.google.ch/maps/@46.948,7.447,17z
> >
> >> It was proposed to NOT render public_transport=stop_position in all
> cases, which frankly I agree with when the node is on a highway (not clear
> to me when it's on a railway, as I don't have experience there).
> >
> > Even for trams/railways, I think, people looking at a map are
> > interested in the waiting area (= platform) and not on the stop
> > position.
> >
> > I'm wondering if there is any use for public_transport=stop_position
> > apart from routing, which, however, should be solvable by calculation
> > (projection of platform on highway/railway way). Otherwise,
> > public_transport=stop_position could be abandoned, which would make
> > PTv2 tagging a lot easier and more time-efficient. As a volunteer
> > project with limited resources, we should try to be as efficient as
> > possible.
> >
> >
> > On 29 March 2018 at 09:43, Johnparis  wrote:
> >> I have spent some time reading
> >> https://github.com/gravitystorm/openstreetmap-carto/issues/435
> >> and
> >> https://github.com/gravitystorm/openstreetmap-carto/issues/331
> >>
> >> It seems that one major issue was that, given a simple
> >> public_transport=platform situation, which icon should be used to
> render it?
> >> In many cases there isn't a {mode}=yes tag. My contribution to solving
> that
> >> issue is attached -- a generic transit icon which I hereby put into the
> >> public domain. I think this icon should be used (a) when there is no
> >> indicator of the transport mode, or (b) when there are multiple modes,
> as in
> >> https://www.openstreetmap.org/way/66332939
> >>
> >> As I understand it, valid relevant mode tags are:
> >> train=yes
> >> light_rail=yes
> >> tram=yes
> >> subway=yes
> >> monorail=yes
> >> bus=yes
> >> trolleybus=yes
> >> ferry=yes
> >> aerialway=yes
> >>
> >> ... and in hindsight, wouldn't it have been nice to have a "platform:"
> >> namespace for these? Very difficult to track these, especially if/when
> a new
> >> mode arrives (self-driving vehicles, anyone?).
> >>
> >> (As a side note, one issue raised in another thread was that "bus=yes"
> does
> >> double duty as an overriding tag in combination with for "access=no" on
> >> highways. This isn't an issue for the vast majority of platforms, as
> they
> >> are nodes not ways, but still... I'd prefer that the access overriding
> tags
> >> have an "access:" namespace anyhow: "access:bus=yes", "access:psv=yes",
> >> etc.)
> >>
> >> Another major issue with rendering public_transport=platform tags was a
> >> limitation in the database schema, which appears to have been lifted
> with
> >> the (relatively recent) addition of hstore. (Though the issue,
> apparently,
> >> was the ability to render based on the mode tags -- which could have
> been
> >> solved with a generic transit icon.)
> >>
> >> A third concern was double-rendering. If both a highway=bus_stop node
> and a
> >> public_transport=platform node exist, won't mappers want to remove the
> >> duplicate? I would hope so! Alternatively, if a stop area is mapped with
> >> both public_transport=platform and public_transport=stop_position,
> won't
> >> that make the map messy? That, it seems to me, is a valid
> consideration. It
> >> was proposed to NOT render public_transport=stop_position in all cases,
> >> which frankly I agree with when the node is on a highway (not 

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Selfish Seahorse]

> Otherwise, public_transport=stop_position could be abandoned, which would 
> make PTv2 tagging a lot easier and more time-efficient.

Or at least exclude them from route relations.


On 29 March 2018 at 12:33, Selfish Seahorse  wrote:
>> It seems that one major issue was that, given a simple 
>> public_transport=platform situation, which icon should be used to render it? 
>> In many cases there isn't a {mode}=yes tag.
>
> This is because according to the PTv2 proposal the transportation
> vehicle tags (bus=yes, tram=yes etc.) have to be put on the stop
> position node, not on the platform node. [^1] This problem could be
> solved if we agree to put them on platform node instead.
>
> [^1]: 
> 
>
>> My contribution to solving that issue is attached -- a generic transit icon 
>> which I hereby put into the public domain. I think this icon should be used 
>> (a) when there is no indicator of the transport mode, or (b) when there are 
>> multiple modes, as in https://www.openstreetmap.org/way/66332939
>
> If multiple transportation vehicles serve a platform, it would be
> useful to have an icon for every vehicle rendered next to one another,
> as here: https://www.google.ch/maps/@46.948,7.447,17z
>
>> It was proposed to NOT render public_transport=stop_position in all cases, 
>> which frankly I agree with when the node is on a highway (not clear to me 
>> when it's on a railway, as I don't have experience there).
>
> Even for trams/railways, I think, people looking at a map are
> interested in the waiting area (= platform) and not on the stop
> position.
>
> I'm wondering if there is any use for public_transport=stop_position
> apart from routing, which, however, should be solvable by calculation
> (projection of platform on highway/railway way). Otherwise,
> public_transport=stop_position could be abandoned, which would make
> PTv2 tagging a lot easier and more time-efficient. As a volunteer
> project with limited resources, we should try to be as efficient as
> possible.
>
>
> On 29 March 2018 at 09:43, Johnparis  wrote:
>> I have spent some time reading
>> https://github.com/gravitystorm/openstreetmap-carto/issues/435
>> and
>> https://github.com/gravitystorm/openstreetmap-carto/issues/331
>>
>> It seems that one major issue was that, given a simple
>> public_transport=platform situation, which icon should be used to render it?
>> In many cases there isn't a {mode}=yes tag. My contribution to solving that
>> issue is attached -- a generic transit icon which I hereby put into the
>> public domain. I think this icon should be used (a) when there is no
>> indicator of the transport mode, or (b) when there are multiple modes, as in
>> https://www.openstreetmap.org/way/66332939
>>
>> As I understand it, valid relevant mode tags are:
>> train=yes
>> light_rail=yes
>> tram=yes
>> subway=yes
>> monorail=yes
>> bus=yes
>> trolleybus=yes
>> ferry=yes
>> aerialway=yes
>>
>> ... and in hindsight, wouldn't it have been nice to have a "platform:"
>> namespace for these? Very difficult to track these, especially if/when a new
>> mode arrives (self-driving vehicles, anyone?).
>>
>> (As a side note, one issue raised in another thread was that "bus=yes" does
>> double duty as an overriding tag in combination with for "access=no" on
>> highways. This isn't an issue for the vast majority of platforms, as they
>> are nodes not ways, but still... I'd prefer that the access overriding tags
>> have an "access:" namespace anyhow: "access:bus=yes", "access:psv=yes",
>> etc.)
>>
>> Another major issue with rendering public_transport=platform tags was a
>> limitation in the database schema, which appears to have been lifted with
>> the (relatively recent) addition of hstore. (Though the issue, apparently,
>> was the ability to render based on the mode tags -- which could have been
>> solved with a generic transit icon.)
>>
>> A third concern was double-rendering. If both a highway=bus_stop node and a
>> public_transport=platform node exist, won't mappers want to remove the
>> duplicate? I would hope so! Alternatively, if a stop area is mapped with
>> both public_transport=platform and public_transport=stop_position, won't
>> that make the map messy? That, it seems to me, is a valid consideration. It
>> was proposed to NOT render public_transport=stop_position in all cases,
>> which frankly I agree with when the node is on a highway (not clear to me
>> when it's on a railway, as I don't have experience there).
>>
>> The last issue, raised by kocio-pl, who I assume is Daniel Koć of this
>> thread, is that someone needs to write the code.
>>
>>
>>
>>
>> On Thu, Mar 29, 2018 at 3:56 AM, Daniel Koć  wrote:
>>>
>>> W dniu 28.03.2018 o 18:42, Jo pisze:
>>> > I've tried to accomplish that many years ago already, it failed. The
>>> > people at the helm of the rendering stack consider the 'old' tags good

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Selfish Seahorse]

> It seems that one major issue was that, given a simple 
> public_transport=platform situation, which icon should be used to render it? 
> In many cases there isn't a {mode}=yes tag.

This is because according to the PTv2 proposal the transportation
vehicle tags (bus=yes, tram=yes etc.) have to be put on the stop
position node, not on the platform node. [^1] This problem could be
solved if we agree to put them on platform node instead.

[^1]: 


> My contribution to solving that issue is attached -- a generic transit icon 
> which I hereby put into the public domain. I think this icon should be used 
> (a) when there is no indicator of the transport mode, or (b) when there are 
> multiple modes, as in https://www.openstreetmap.org/way/66332939

If multiple transportation vehicles serve a platform, it would be
useful to have an icon for every vehicle rendered next to one another,
as here: https://www.google.ch/maps/@46.948,7.447,17z

> It was proposed to NOT render public_transport=stop_position in all cases, 
> which frankly I agree with when the node is on a highway (not clear to me 
> when it's on a railway, as I don't have experience there).

Even for trams/railways, I think, people looking at a map are
interested in the waiting area (= platform) and not on the stop
position.

I'm wondering if there is any use for public_transport=stop_position
apart from routing, which, however, should be solvable by calculation
(projection of platform on highway/railway way). Otherwise,
public_transport=stop_position could be abandoned, which would make
PTv2 tagging a lot easier and more time-efficient. As a volunteer
project with limited resources, we should try to be as efficient as
possible.


On 29 March 2018 at 09:43, Johnparis  wrote:
> I have spent some time reading
> https://github.com/gravitystorm/openstreetmap-carto/issues/435
> and
> https://github.com/gravitystorm/openstreetmap-carto/issues/331
>
> It seems that one major issue was that, given a simple
> public_transport=platform situation, which icon should be used to render it?
> In many cases there isn't a {mode}=yes tag. My contribution to solving that
> issue is attached -- a generic transit icon which I hereby put into the
> public domain. I think this icon should be used (a) when there is no
> indicator of the transport mode, or (b) when there are multiple modes, as in
> https://www.openstreetmap.org/way/66332939
>
> As I understand it, valid relevant mode tags are:
> train=yes
> light_rail=yes
> tram=yes
> subway=yes
> monorail=yes
> bus=yes
> trolleybus=yes
> ferry=yes
> aerialway=yes
>
> ... and in hindsight, wouldn't it have been nice to have a "platform:"
> namespace for these? Very difficult to track these, especially if/when a new
> mode arrives (self-driving vehicles, anyone?).
>
> (As a side note, one issue raised in another thread was that "bus=yes" does
> double duty as an overriding tag in combination with for "access=no" on
> highways. This isn't an issue for the vast majority of platforms, as they
> are nodes not ways, but still... I'd prefer that the access overriding tags
> have an "access:" namespace anyhow: "access:bus=yes", "access:psv=yes",
> etc.)
>
> Another major issue with rendering public_transport=platform tags was a
> limitation in the database schema, which appears to have been lifted with
> the (relatively recent) addition of hstore. (Though the issue, apparently,
> was the ability to render based on the mode tags -- which could have been
> solved with a generic transit icon.)
>
> A third concern was double-rendering. If both a highway=bus_stop node and a
> public_transport=platform node exist, won't mappers want to remove the
> duplicate? I would hope so! Alternatively, if a stop area is mapped with
> both public_transport=platform and public_transport=stop_position, won't
> that make the map messy? That, it seems to me, is a valid consideration. It
> was proposed to NOT render public_transport=stop_position in all cases,
> which frankly I agree with when the node is on a highway (not clear to me
> when it's on a railway, as I don't have experience there).
>
> The last issue, raised by kocio-pl, who I assume is Daniel Koć of this
> thread, is that someone needs to write the code.
>
>
>
>
> On Thu, Mar 29, 2018 at 3:56 AM, Daniel Koć  wrote:
>>
>> W dniu 28.03.2018 o 18:42, Jo pisze:
>> > I've tried to accomplish that many years ago already, it failed. The
>> > people at the helm of the rendering stack consider the 'old' tags good
>> > enough and the new scheme somehow not explicit enough, hence the
>> > double tagging.
>>
>> I'm not sure who do you mean, but I certainly want to make it render on
>> osm-carto. It wasn't possible before we have hstore few months ago
>> (v4.0.0+) and I had to learn coding with this feature enabled, but now
>> it's much closer to being reality - I need just some time probably, 

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Jo]

PT v2 says you CAN map stops using 2 objects. People reading that
understood that you MUST use both a stop_position node and a platform
way/node.

Then it was interpreted as: both of those HAVE TO be added to the route
relations.

To make things look consistent in the route relations, then some mappers
started adding platform ways where no actual platforms exist.

All in all the scheme, when interpreted like that, is too complex.
Information is duplicated across several objects, creating a need to keep
them in sync afterwards, whichj is, of course absurd.

Personally I don't see a need for the stop_position nodes, so for the few
ones that I do add, they don't get details like name, and I don't add them
to the route relations.

Also the route relations, it's not one per direction of travel. It's one
per variation of itinerary, which often comes down to 2 relations per
route_master relation, but it can also be just 1, or up to 50 (
https://www.openstreetmap.org/relation/3944387). For "telescopic"
lines, I only create route relations for the longer variants. The whole
thing is messy enough as it is.

Polyglot

2018-03-29 9:37 GMT+02:00 Topographe Fou :

> Hi,
>
> Your intent is to simplify but I don't understand how replacing one tag by
> three or more with different syntaxes key/value according to the type of
> transportation and their introduction in OSM can make things easier.
>
> I share your view when you say that two schemas is too much to maintain
> but I would rather jump to the conclusion that it is PTv1 which should be
> dropped if we want to drop one as it has limitations. PTv2 is not that
> complexe, it is public transportation which are complexe to map.
>
> One thing I never understood was why we have to maintain two schemas
> (probably because consensus was not reached). I guess this is the main
> reason why some people (especially new mappers) can be lost. And also why
> wiki can sometime say one thing or the opposite. I think it delayed the
> evolution of renderers and tools instead of pushing them to evolve with the
> schemas. I have the feeling that your analysis dropped those factors. Once
> the map on osm.org will render PTv2, I'm sure it will be a huge step and
> that all the work done will pay.
>
> Then I don't see where is the difficulty to map two different features
> instead of mapping a single approximate one. It means more work, right, but
> it adds more values to the project as a whole. And since nobody is forced
> to mapped everything on its own...
>
> To conclude: I disagree with part of the analysis and with the whole
> conclusion.
>
> Yours,
>
> LeTopographeFou
>
>   Message original
> De: i...@zverev.info
> Envoyé: 28 mars 2018 3:54 PM
> À: tagging@openstreetmap.org
> Répondre à: tagging@openstreetmap.org
> Objet: [Tagging] Still RFC — Drop stop positions and platforms
>
> Hi folks,
>
> A while ago I've made a proposal to deprecate some public_transport=* tags:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/
> Drop_stop_positions_and_platforms
>
> The discussion was very slow, and in general mappers seemed to accept the
> change. I'd like to push this to voting in a few days, but first I want to
> know if somebody has anything to say about the proposal. Like, why we
> should not. I'd prefer to discuss that before the voting has started.
>
> Ilya
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> ___
> 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] Still RFC — Drop stop positions and platforms

[Johnparis]

I have spent some time reading
https://github.com/gravitystorm/openstreetmap-carto/issues/435
and
https://github.com/gravitystorm/openstreetmap-carto/issues/331

It seems that one major issue was that, given a simple
public_transport=platform situation, which icon should be used to render
it? In many cases there isn't a {mode}=yes tag. My contribution to solving
that issue is attached -- a generic transit icon which I hereby put into
the public domain. I think this icon should be used (a) when there is no
indicator of the transport mode, or (b) when there are multiple modes, as
in
https://www.openstreetmap.org/way/66332939

As I understand it, valid relevant mode tags are:
train=yes
light_rail=yes
tram=yes
subway=yes
monorail=yes
bus=yes
trolleybus=yes
ferry=yes
aerialway=yes

... and in hindsight, wouldn't it have been nice to have a "platform:"
namespace for these? Very difficult to track these, especially if/when a
new mode arrives (self-driving vehicles, anyone?).

(As a side note, one issue raised in another thread was that "bus=yes" does
double duty as an overriding tag in combination with for "access=no" on
highways. This isn't an issue for the vast majority of platforms, as they
are nodes not ways, but still... I'd prefer that the access overriding tags
have an "access:" namespace anyhow: "access:bus=yes", "access:psv=yes",
etc.)

Another major issue with rendering public_transport=platform tags was a
limitation in the database schema, which appears to have been lifted with
the (relatively recent) addition of hstore. (Though the issue, apparently,
was the ability to render based on the mode tags -- which could have been
solved with a generic transit icon.)

A third concern was double-rendering. If both a highway=bus_stop node and a
public_transport=platform node exist, won't mappers want to remove the
duplicate? I would hope so! Alternatively, if a stop area is mapped with
both public_transport=platform and public_transport=stop_position, won't
that make the map messy? That, it seems to me, is a valid consideration. It
was proposed to NOT render public_transport=stop_position in all cases,
which frankly I agree with when the node is on a highway (not clear to me
when it's on a railway, as I don't have experience there).

The last issue, raised by kocio-pl, who I assume is Daniel Koć of this
thread, is that someone needs to write the code.




On Thu, Mar 29, 2018 at 3:56 AM, Daniel Koć  wrote:

> W dniu 28.03.2018 o 18:42, Jo pisze:
> > I've tried to accomplish that many years ago already, it failed. The
> > people at the helm of the rendering stack consider the 'old' tags good
> > enough and the new scheme somehow not explicit enough, hence the
> > double tagging.
>
> I'm not sure who do you mean, but I certainly want to make it render on
> osm-carto. It wasn't possible before we have hstore few months ago
> (v4.0.0+) and I had to learn coding with this feature enabled, but now
> it's much closer to being reality - I need just some time probably, but
> any help is welcome. Related issue:
>
> https://github.com/gravitystorm/openstreetmap-carto/issues/435
>
> > Dropping the tags you call obsolete from the data, is not an option as
> > far as I'm concerned. Part of the reason for mapping bus stops, is to
> > get them rendered on the map. That's not tagging for the renderer,
> > that's merely being practical and adapting to the situation at hand.
>
> Tagging for rendering is confusing slogan. There's nothing wrong in the
> literal sense, the problem is with faking data just to show something on
> the map. Double tagging is a problem too, but transition is always
> troublesome process.
>
> --
> "My method is uncertain/ It's a mess but it's working" [F. Apple]
>
>
>
> ___
> 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] Still RFC — Drop stop positions and platforms

[Topographe Fou]

Hi,

Your intent is to simplify but I don't understand how replacing one tag by 
three or more with different syntaxes key/value according to the type of 
transportation and their introduction in OSM can make things easier.

I share your view when you say that two schemas is too much to maintain but I 
would rather jump to the conclusion that it is PTv1 which should be dropped if 
we want to drop one as it has limitations. PTv2 is not that complexe, it is 
public transportation which are complexe to map.

One thing I never understood was why we have to maintain two schemas (probably 
because consensus was not reached). I guess this is the main reason why some 
people (especially new mappers) can be lost. And also why wiki can sometime say 
one thing or the opposite. I think it delayed the evolution of renderers and 
tools instead of pushing them to evolve with the schemas. I have the feeling 
that your analysis dropped those factors. Once the map on osm.org will render 
PTv2, I'm sure it will be a huge step and that all the work done will pay. 

Then I don't see where is the difficulty to map two different features instead 
of mapping a single approximate one. It means more work, right, but it adds 
more values to the project as a whole. And since nobody is forced to mapped 
everything on its own...

To conclude: I disagree with part of the analysis and with the whole conclusion.

Yours,

LeTopographeFou

  Message original  
De: i...@zverev.info
Envoyé: 28 mars 2018 3:54 PM
À: tagging@openstreetmap.org
Répondre à: tagging@openstreetmap.org
Objet: [Tagging] Still RFC — Drop stop positions and platforms

Hi folks,

A while ago I've made a proposal to deprecate some public_transport=* tags:

https://wiki.openstreetmap.org/wiki/Proposed_features/Drop_stop_positions_and_platforms

The discussion was very slow, and in general mappers seemed to accept the 
change. I'd like to push this to voting in a few days, but first I want to know 
if somebody has anything to say about the proposal. Like, why we should not. 
I'd prefer to discuss that before the voting has started.

Ilya
___
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] Still RFC — Drop stop positions and platforms

[Johnparis]

>> Add relations and direction of ways (forwards, backwards) and it's a
very time consuming task to upgrade v1 to v2, especially if bus routes
change.

> Do you mean 'forward' and 'backward' roles?

I think what was meant was that in v2 you want to create a forward relation
and a backward relation, then place the two under a route master relation.
Under v1 you already had the forward/backward roles within just one
relation.





On Thu, Mar 29, 2018 at 8:04 AM, Selfish Seahorse  wrote:

> > Add relations and direction of ways (forwards, backwards) and it's a
> very time consuming task to upgrade v1 to v2, especially if bus routes
> change.
>
> Do you mean 'forward' and 'backward' roles? They aren't needed because
> there is one route relation per direction. Thus 'forward' and
> 'backward' roles shouldn't be used in PTv2 route relations. [^1]
>
> [^1]:  Public_Transport#Route_direction.2Fvariant>
>
>
> On 29 March 2018 at 00:30, James  wrote:
> > on top of that documentation is not clear atleast when I was trying to
> learn
> > how to tag bus routes. The only way I understood was a google hangout
> video
> > on youtube(OSM US?) showing how they tagged it.
> >
> > Add relations and direction of ways (forwards, backwards) and it's a very
> > time consuming task to upgrade v1 to v2, especially if bus routes change.
> >
> > ID is not the greatest too for the job either, so not everyone will spin
> up
> > JOSM to edit bus routes
> >
> > On Wed, Mar 28, 2018, 6:21 PM Selfish Seahorse, <
> selfishseaho...@gmail.com>
> > wrote:
> >>
> >> > In my opinion, PTv2 is too complicated, time-consuming and delicate,
> ...
> >>
> >> Sorry, I've meant inefficient, not time-consuming.
> >>
> >>
> >> On 29 March 2018 at 00:13, Selfish Seahorse 
> >> wrote:
> >> >> Many people were involved creating those tags, they are well
> understood
> >> >> and discriminate the features they describe in a thoroughly
> documented and
> >> >> plausible way.
> >> >
> >> > Apparently these tags aren't that well understood: I rarely encounter
> >> > a PTv2 route that doesn't have at least one tagging error or isn't
> >> > otherwise broken. And quite often I find public_transport=platform
> >> > ways even though there isn't a physical platform.
> >> >
> >> > In my opinion, PTv2 is too complicated, time-consuming and delicate,
> >> > and its tags aren't the most clear (e.g. waiting areas are called
> >> > 'platform' even if there is no physical platform).
> >> >
> >> > But maybe the biggest problem, as Michael pointed out, is that
> >> > renderers can't know if a public_transport=platform – the most
> >> > important object for people looking for a public transport stop on a
> >> > map – is served by a bus or a tram, because it isn't tagged with
> >> > bus/tram/...=yes.
> >> >
> >> > I'm wondering why the limitations of PTv1 [^1] haven't been solved by
> >> > keeping PTv1 tags, introducing route variant/master relations and
> >> > mapping tram stops at the waiting area.
> >> >
> >> > [^1]:
> >> >  Public_Transport#Main_problem_with_the_existing_schema>
> >> >
> >> >
> >> > On 28 March 2018 at 16:21, "Christian Müller"  wrote:
> >> >>> Sent: Wed, 28 Mar 2018 16:53:28 +0300
> >> >>> From: "Ilya Zverev" 
> >> >>> To: tagging@openstreetmap.org
> >> >>> Subject: [Tagging] Still RFC — Drop stop positions and platforms
> >> >>>
> >> >>> Hi folks,
> >> >>>
> >> >>> A while ago I've made a proposal to deprecate some
> public_transport=*
> >> >>> tags:
> >> >>>
> >> >>>
> >> >>> https://wiki.openstreetmap.org/wiki/Proposed_features/
> Drop_stop_positions_and_platforms
> >> >>>
> >> >>
> >> >> In your proposal you complain about subjectively felt things like
> >> >> "history won't go away", but at the same time you are trying to
> revert a
> >> >> part of history itself - "the public_transport tags are seven years
> old
> >> >> now".  Many people were involved creating those tags, they are well
> >> >> understood and discriminate the features they describe in a
> thoroughly
> >> >> documented and plausible way.
> >> >>
> >> >> Just because a lot of deprecated tags have not vanished in favor of
> the
> >> >> new ones yet does not mean there is a preference on the deprecated
> tags.  A
> >> >> lot of users and apps have adopted the new public_transport tags.
> It simply
> >> >> does not make any sense to do a rollback on these for the
> observation of a
> >> >> sluggish adoption/transition rate.
> >> >>
> >> >> The proposal has been long thought about and delivers, in itself, a
> >> >> coherent way of tagging public transport infrastructure.  It has
> learned
> >> >> from previous tags, it is thus a refinement of the previous
> tagging.  There
> >> >> will be lots of people -unheared and not- that oppose breaking a
> (slow
> >> >> moving) 

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Selfish Seahorse]

> Add relations and direction of ways (forwards, backwards) and it's a very 
> time consuming task to upgrade v1 to v2, especially if bus routes change.

Do you mean 'forward' and 'backward' roles? They aren't needed because
there is one route relation per direction. Thus 'forward' and
'backward' roles shouldn't be used in PTv2 route relations. [^1]

[^1]: 



On 29 March 2018 at 00:30, James  wrote:
> on top of that documentation is not clear atleast when I was trying to learn
> how to tag bus routes. The only way I understood was a google hangout video
> on youtube(OSM US?) showing how they tagged it.
>
> Add relations and direction of ways (forwards, backwards) and it's a very
> time consuming task to upgrade v1 to v2, especially if bus routes change.
>
> ID is not the greatest too for the job either, so not everyone will spin up
> JOSM to edit bus routes
>
> On Wed, Mar 28, 2018, 6:21 PM Selfish Seahorse, 
> wrote:
>>
>> > In my opinion, PTv2 is too complicated, time-consuming and delicate, ...
>>
>> Sorry, I've meant inefficient, not time-consuming.
>>
>>
>> On 29 March 2018 at 00:13, Selfish Seahorse 
>> wrote:
>> >> Many people were involved creating those tags, they are well understood
>> >> and discriminate the features they describe in a thoroughly documented and
>> >> plausible way.
>> >
>> > Apparently these tags aren't that well understood: I rarely encounter
>> > a PTv2 route that doesn't have at least one tagging error or isn't
>> > otherwise broken. And quite often I find public_transport=platform
>> > ways even though there isn't a physical platform.
>> >
>> > In my opinion, PTv2 is too complicated, time-consuming and delicate,
>> > and its tags aren't the most clear (e.g. waiting areas are called
>> > 'platform' even if there is no physical platform).
>> >
>> > But maybe the biggest problem, as Michael pointed out, is that
>> > renderers can't know if a public_transport=platform – the most
>> > important object for people looking for a public transport stop on a
>> > map – is served by a bus or a tram, because it isn't tagged with
>> > bus/tram/...=yes.
>> >
>> > I'm wondering why the limitations of PTv1 [^1] haven't been solved by
>> > keeping PTv1 tags, introducing route variant/master relations and
>> > mapping tram stops at the waiting area.
>> >
>> > [^1]:
>> > 
>> >
>> >
>> > On 28 March 2018 at 16:21, "Christian Müller"  wrote:
>> >>> Sent: Wed, 28 Mar 2018 16:53:28 +0300
>> >>> From: "Ilya Zverev" 
>> >>> To: tagging@openstreetmap.org
>> >>> Subject: [Tagging] Still RFC — Drop stop positions and platforms
>> >>>
>> >>> Hi folks,
>> >>>
>> >>> A while ago I've made a proposal to deprecate some public_transport=*
>> >>> tags:
>> >>>
>> >>>
>> >>> https://wiki.openstreetmap.org/wiki/Proposed_features/Drop_stop_positions_and_platforms
>> >>>
>> >>
>> >> In your proposal you complain about subjectively felt things like
>> >> "history won't go away", but at the same time you are trying to revert a
>> >> part of history itself - "the public_transport tags are seven years old
>> >> now".  Many people were involved creating those tags, they are well
>> >> understood and discriminate the features they describe in a thoroughly
>> >> documented and plausible way.
>> >>
>> >> Just because a lot of deprecated tags have not vanished in favor of the
>> >> new ones yet does not mean there is a preference on the deprecated tags.  
>> >> A
>> >> lot of users and apps have adopted the new public_transport tags.  It 
>> >> simply
>> >> does not make any sense to do a rollback on these for the observation of a
>> >> sluggish adoption/transition rate.
>> >>
>> >> The proposal has been long thought about and delivers, in itself, a
>> >> coherent way of tagging public transport infrastructure.  It has learned
>> >> from previous tags, it is thus a refinement of the previous tagging.  
>> >> There
>> >> will be lots of people -unheared and not- that oppose breaking a (slow
>> >> moving) transition process at this point in time.  Just be patient and 
>> >> give
>> >> it some more years.
>> >>
>> >> You could help and promote the adoption, instead of dilating it.  A lot
>> >> of rural area data has not been touched for years, waiting for you to do
>> >> research and remapping efforts.
>> >>
>> >>
>> >> Greetings
>> >> cmuelle8
>> >>
>> >> ___
>> >> 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] Still RFC — Drop stop positions and platforms

[Agustin Rissoli]

 something like this?  https://www.youtube.com/watch?v=OcS8-g1EGfk

Agustín-

Date: Wed, 28 Mar 2018 19:53:08 +0200 (CEST)
From: Marián Kyral <mky...@email.cz>
To: <winfi...@gmail.com>, Tag discussion, strategy and related tools
<tagging@openstreetmap.org>
Subject: Re: [Tagging] Still RFC — Drop stop positions and platforms
Message-ID: <4}.yx5v.1gvso5zhwnk.1qk...@seznam.cz>
Content-Type: text/plain; charset="utf-8"


-- Původní e-mail --
Od: Jo <winfi...@gmail.com>
Komu: Tag discussion, strategy and related tools <tagging@openstreetmap.org>
Datum: 28. 3. 2018 18:43:15
Předmět: Re: [Tagging] Still RFC — Drop stop positions and platforms




Yes. I like it as well. But it still could be improved. E.g. I'm thinking
about tool which - If you create four objects: two nodes on highway and two
nodes/ways beside highway and select all of them - will automatically tag
them as stop_position and platform and will create corresponding public_
transport relation. I have to find a time to develop it.


Marián





<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Libre
de virus. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Daniel Koć]

W dniu 28.03.2018 o 18:42, Jo pisze:
> I've tried to accomplish that many years ago already, it failed. The
> people at the helm of the rendering stack consider the 'old' tags good
> enough and the new scheme somehow not explicit enough, hence the
> double tagging.

I'm not sure who do you mean, but I certainly want to make it render on
osm-carto. It wasn't possible before we have hstore few months ago
(v4.0.0+) and I had to learn coding with this feature enabled, but now
it's much closer to being reality - I need just some time probably, but
any help is welcome. Related issue:

https://github.com/gravitystorm/openstreetmap-carto/issues/435

> Dropping the tags you call obsolete from the data, is not an option as
> far as I'm concerned. Part of the reason for mapping bus stops, is to
> get them rendered on the map. That's not tagging for the renderer,
> that's merely being practical and adapting to the situation at hand.

Tagging for rendering is confusing slogan. There's nothing wrong in the
literal sense, the problem is with faking data just to show something on
the map. Double tagging is a problem too, but transition is always
troublesome process.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[James]

on top of that documentation is not clear atleast when I was trying to
learn how to tag bus routes. The only way I understood was a google hangout
video on youtube(OSM US?) showing how they tagged it.

Add relations and direction of ways (forwards, backwards) and it's a very
time consuming task to upgrade v1 to v2, especially if bus routes change.

ID is not the greatest too for the job either, so not everyone will spin up
JOSM to edit bus routes

On Wed, Mar 28, 2018, 6:21 PM Selfish Seahorse, 
wrote:

> > In my opinion, PTv2 is too complicated, time-consuming and delicate, ...
>
> Sorry, I've meant inefficient, not time-consuming.
>
>
> On 29 March 2018 at 00:13, Selfish Seahorse 
> wrote:
> >> Many people were involved creating those tags, they are well understood
> and discriminate the features they describe in a thoroughly documented and
> plausible way.
> >
> > Apparently these tags aren't that well understood: I rarely encounter
> > a PTv2 route that doesn't have at least one tagging error or isn't
> > otherwise broken. And quite often I find public_transport=platform
> > ways even though there isn't a physical platform.
> >
> > In my opinion, PTv2 is too complicated, time-consuming and delicate,
> > and its tags aren't the most clear (e.g. waiting areas are called
> > 'platform' even if there is no physical platform).
> >
> > But maybe the biggest problem, as Michael pointed out, is that
> > renderers can't know if a public_transport=platform – the most
> > important object for people looking for a public transport stop on a
> > map – is served by a bus or a tram, because it isn't tagged with
> > bus/tram/...=yes.
> >
> > I'm wondering why the limitations of PTv1 [^1] haven't been solved by
> > keeping PTv1 tags, introducing route variant/master relations and
> > mapping tram stops at the waiting area.
> >
> > [^1]: <
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Main_problem_with_the_existing_schema
> >
> >
> >
> > On 28 March 2018 at 16:21, "Christian Müller"  wrote:
> >>> Sent: Wed, 28 Mar 2018 16:53:28 +0300
> >>> From: "Ilya Zverev" 
> >>> To: tagging@openstreetmap.org
> >>> Subject: [Tagging] Still RFC — Drop stop positions and platforms
> >>>
> >>> Hi folks,
> >>>
> >>> A while ago I've made a proposal to deprecate some public_transport=*
> tags:
> >>>
> >>>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Drop_stop_positions_and_platforms
> >>>
> >>
> >> In your proposal you complain about subjectively felt things like
> "history won't go away", but at the same time you are trying to revert a
> part of history itself - "the public_transport tags are seven years old
> now".  Many people were involved creating those tags, they are well
> understood and discriminate the features they describe in a thoroughly
> documented and plausible way.
> >>
> >> Just because a lot of deprecated tags have not vanished in favor of the
> new ones yet does not mean there is a preference on the deprecated tags.  A
> lot of users and apps have adopted the new public_transport tags.  It
> simply does not make any sense to do a rollback on these for the
> observation of a sluggish adoption/transition rate.
> >>
> >> The proposal has been long thought about and delivers, in itself, a
> coherent way of tagging public transport infrastructure.  It has learned
> from previous tags, it is thus a refinement of the previous tagging.  There
> will be lots of people -unheared and not- that oppose breaking a (slow
> moving) transition process at this point in time.  Just be patient and give
> it some more years.
> >>
> >> You could help and promote the adoption, instead of dilating it.  A lot
> of rural area data has not been touched for years, waiting for you to do
> research and remapping efforts.
> >>
> >>
> >> Greetings
> >> cmuelle8
> >>
> >> ___
> >> Tagging mailing list
> >> Tagging@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> 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] Still RFC — Drop stop positions and platforms

[Selfish Seahorse]

> In my opinion, PTv2 is too complicated, time-consuming and delicate, ...

Sorry, I've meant inefficient, not time-consuming.


On 29 March 2018 at 00:13, Selfish Seahorse  wrote:
>> Many people were involved creating those tags, they are well understood and 
>> discriminate the features they describe in a thoroughly documented and 
>> plausible way.
>
> Apparently these tags aren't that well understood: I rarely encounter
> a PTv2 route that doesn't have at least one tagging error or isn't
> otherwise broken. And quite often I find public_transport=platform
> ways even though there isn't a physical platform.
>
> In my opinion, PTv2 is too complicated, time-consuming and delicate,
> and its tags aren't the most clear (e.g. waiting areas are called
> 'platform' even if there is no physical platform).
>
> But maybe the biggest problem, as Michael pointed out, is that
> renderers can't know if a public_transport=platform – the most
> important object for people looking for a public transport stop on a
> map – is served by a bus or a tram, because it isn't tagged with
> bus/tram/...=yes.
>
> I'm wondering why the limitations of PTv1 [^1] haven't been solved by
> keeping PTv1 tags, introducing route variant/master relations and
> mapping tram stops at the waiting area.
>
> [^1]: 
> 
>
>
> On 28 March 2018 at 16:21, "Christian Müller"  wrote:
>>> Sent: Wed, 28 Mar 2018 16:53:28 +0300
>>> From: "Ilya Zverev" 
>>> To: tagging@openstreetmap.org
>>> Subject: [Tagging] Still RFC — Drop stop positions and platforms
>>>
>>> Hi folks,
>>>
>>> A while ago I've made a proposal to deprecate some public_transport=* tags:
>>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Drop_stop_positions_and_platforms
>>>
>>
>> In your proposal you complain about subjectively felt things like "history 
>> won't go away", but at the same time you are trying to revert a part of 
>> history itself - "the public_transport tags are seven years old now".  Many 
>> people were involved creating those tags, they are well understood and 
>> discriminate the features they describe in a thoroughly documented and 
>> plausible way.
>>
>> Just because a lot of deprecated tags have not vanished in favor of the new 
>> ones yet does not mean there is a preference on the deprecated tags.  A lot 
>> of users and apps have adopted the new public_transport tags.  It simply 
>> does not make any sense to do a rollback on these for the observation of a 
>> sluggish adoption/transition rate.
>>
>> The proposal has been long thought about and delivers, in itself, a coherent 
>> way of tagging public transport infrastructure.  It has learned from 
>> previous tags, it is thus a refinement of the previous tagging.  There will 
>> be lots of people -unheared and not- that oppose breaking a (slow moving) 
>> transition process at this point in time.  Just be patient and give it some 
>> more years.
>>
>> You could help and promote the adoption, instead of dilating it.  A lot of 
>> rural area data has not been touched for years, waiting for you to do 
>> research and remapping efforts.
>>
>>
>> Greetings
>> cmuelle8
>>
>> ___
>> 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] Still RFC — Drop stop positions and platforms

[Selfish Seahorse]

> Many people were involved creating those tags, they are well understood and 
> discriminate the features they describe in a thoroughly documented and 
> plausible way.

Apparently these tags aren't that well understood: I rarely encounter
a PTv2 route that doesn't have at least one tagging error or isn't
otherwise broken. And quite often I find public_transport=platform
ways even though there isn't a physical platform.

In my opinion, PTv2 is too complicated, time-consuming and delicate,
and its tags aren't the most clear (e.g. waiting areas are called
'platform' even if there is no physical platform).

But maybe the biggest problem, as Michael pointed out, is that
renderers can't know if a public_transport=platform – the most
important object for people looking for a public transport stop on a
map – is served by a bus or a tram, because it isn't tagged with
bus/tram/...=yes.

I'm wondering why the limitations of PTv1 [^1] haven't been solved by
keeping PTv1 tags, introducing route variant/master relations and
mapping tram stops at the waiting area.

[^1]: 



On 28 March 2018 at 16:21, "Christian Müller"  wrote:
>> Sent: Wed, 28 Mar 2018 16:53:28 +0300
>> From: "Ilya Zverev" 
>> To: tagging@openstreetmap.org
>> Subject: [Tagging] Still RFC — Drop stop positions and platforms
>>
>> Hi folks,
>>
>> A while ago I've made a proposal to deprecate some public_transport=* tags:
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Drop_stop_positions_and_platforms
>>
>
> In your proposal you complain about subjectively felt things like "history 
> won't go away", but at the same time you are trying to revert a part of 
> history itself - "the public_transport tags are seven years old now".  Many 
> people were involved creating those tags, they are well understood and 
> discriminate the features they describe in a thoroughly documented and 
> plausible way.
>
> Just because a lot of deprecated tags have not vanished in favor of the new 
> ones yet does not mean there is a preference on the deprecated tags.  A lot 
> of users and apps have adopted the new public_transport tags.  It simply does 
> not make any sense to do a rollback on these for the observation of a 
> sluggish adoption/transition rate.
>
> The proposal has been long thought about and delivers, in itself, a coherent 
> way of tagging public transport infrastructure.  It has learned from previous 
> tags, it is thus a refinement of the previous tagging.  There will be lots of 
> people -unheared and not- that oppose breaking a (slow moving) transition 
> process at this point in time.  Just be patient and give it some more years.
>
> You could help and promote the adoption, instead of dilating it.  A lot of 
> rural area data has not been touched for years, waiting for you to do 
> research and remapping efforts.
>
>
> Greetings
> cmuelle8
>
> ___
> 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] Still RFC — Drop stop positions and platforms

[Warin]

My view, as a person adding things to the data base.

The public transport v2 documentation that I found is not good.
I had difficulty in deciding what to do and
used an iterative approach with the OA tools OSMinspector and JOSM validator to 
come up with something that might work.

I'm yet to do a diary entry on it... basically documenting what I found that 
satisfies these 'rules'.



On 29/03/18 00:53, Ilya Zverev wrote:

Hi folks,

A while ago I've made a proposal to deprecate some public_transport=* tags:

https://wiki.openstreetmap.org/wiki/Proposed_features/Drop_stop_positions_and_platforms

The discussion was very slow, and in general mappers seemed to accept the 
change. I'd like to push this to voting in a few days, but first I want to know 
if somebody has anything to say about the proposal. Like, why we should not. 
I'd prefer to discuss that before the voting has started.

Ilya
___
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] Still RFC — Drop stop positions and platforms

[Michael Reichert]

Hi Christian,

Am 28.03.2018 um 16:21 schrieb "Christian Müller":
> In your proposal you complain about subjectively felt things like "history 
> won't go away", but at the same time you are trying to revert a part of 
> history itself - "the public_transport tags are seven years old now".  Many 
> people were involved creating those tags, they are well understood and 
> discriminate the features they describe in a thoroughly documented and 
> plausible way.
> 
> Just because a lot of deprecated tags have not vanished in favor of the new 
> ones yet does not mean there is a preference on the deprecated tags.  A lot 
> of users and apps have adopted the new public_transport tags.  It simply does 
> not make any sense to do a rollback on these for the observation of a 
> sluggish adoption/transition rate.
> 
> The proposal has been long thought about and delivers, in itself, a coherent 
> way of tagging public transport infrastructure.  It has learned from previous 
> tags, it is thus a refinement of the previous tagging.  There will be lots of 
> people -unheared and not- that oppose breaking a (slow moving) transition 
> process at this point in time.  Just be patient and give it some more years.

I am in favour of PTv2 but have to admit that PTv2 is a great example
how proposals can fail. I joined OSM a few months after PTv2 was adopted
and started using it in 2014. The reasons for its failure are:

- PTv2 has a long and detailed proposal page but after the proposal was
accepted, it was only documented on the proposal page for a long time
while many other pages (some might still do) explained the old schema.

- If someone propose a tagging schema which is not just a new tag or a
few new tags but includes a new type of relation (stop areas, routes
which contain stops etc.), he should provide a application which
demonstrates the usage and/or serves as validator. That did not happen.
Adding support for that type of relation to at least one widely used
data consumer tool like Osm2pgsql will make more users use the data
(currently you have to rely on the slim tables of Osm2pgsql which is a
hack because they are not considered to be stable).

- If someone writes such a complicated proposal, he should ask the
authors of map styles (if he isn't someone himself) for their opinion on
the new tags. public_transport=stop_position/platform isn't easy to
render without taking highway=bus_stop into account because (1)
platforms do not have to be tagged with bus/tram/train/subway=yes and
because you do not have to map both the platform and the stop. If you
render only stop positions or only platforms, you will miss features in
some areas. If you render both, you will have duplicated map icons.
Checking if there are nearby features, does not work as good as manual
selection (I wrote my own SQL queries to group stops and platforms to
form stations in the past – it doesn't work very good).

- The proposal was not understood by significant parts of the community.
Many mappers think that highway=bus_stop and
railway=station/halt/tram_stop are deprecated and use them because some
important applications do not use public_transport=*. (see the quoted
posting above) However, they aren't.

All in all, I would like to thank Ilya for investing time into this
topic even if I do not agree with him on all questions and do not like
some parts of his approach (change tagging in foreign cities using
non-local staff which does not declare its affiliation).

Best regards

Michael


PS This email was written before I read the new proposal by Ilya.


-- 
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] Still RFC — Drop stop positions and platforms

[Jo]

>
> Yes. I like it as well. But it still could be improved. E.g. I'm thinking
> about tool which - If you create four objects: two nodes on highway and two
> nodes/ways beside highway and select all of them - will automatically tag
> them as stop_position and platform and will create corresponding
> public_transport relation. I have to find a time to develop it.
>
If you need that functionality, I can have it added to JOSM's PT_Assistant
plugin. It already has a map mode to add stop_position nodes on ways and
creating a preset that adds/removes specific tags to nodes is also
relatively simple to do.

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Marián Kyral]

-- Původní e-mail --
Od: Jo <winfi...@gmail.com>
Komu: Tag discussion, strategy and related tools <tagging@openstreetmap.org>
Datum: 28. 3. 2018 18:43:15
Předmět: Re: [Tagging] Still RFC — Drop stop positions and platforms
"
I've tried to accomplish that many years ago already, it failed. The people
at the helm of the rendering stack consider the 'old' tags good enough and
the new scheme somehow not explicit enough, hence the double tagging.


"



I don't like this half way situation :-( And if situation does not change 
for some time, it does not mean that it can't change at all.




"




Dropping the tags you call obsolete from the data, is not an option as far
as I'm concerned. Part of the reason for mapping bus stops, is to get them
rendered on the map. That's not tagging for the renderer, that's merely 
being practical and adapting to the situation at hand.



"



I don't like that I'm forced to use these old tags, because it is not render
on map and then some user with Maps.Me will come and put OSM note, that bus
stop is missing or will create a duplicate node with highway=bus_stop.



"




Adding public_transport=platform/stop_position is also being practical, as
they are treated in certain ways by JOSM, with regard to assignment of
roles.



"



Yes. I like it as well. But it still could be improved. E.g. I'm thinking 
about tool which - If you create four objects: two nodes on highway and two
nodes/ways beside highway and select all of them - will automatically tag 
them as stop_position and platform and will create corresponding public_
transport relation. I have to find a time to develop it.



"




I stopped worrying about the wasted disk space or processing power several
years ago.



"



I don't worry about disks or processors, but I worry about my time I waste
by adding this tag or solving OSM notes about "missing" bus stops.




Marián



"




Polyglot











2018-03-28 17:48 GMT+02:00 Marián Kyral <mky...@email.cz
(mailto:mky...@email.cz)>:
"

-- Původní e-mail --
Od: "Christian Müller" <cmu...@gmx.de(mailto:cmu...@gmx.de)>
Komu: tagging@openstreetmap.org(mailto:tagging@openstreetmap.org)
Datum: 28. 3. 2018 16:22:41
Předmět: Re: [Tagging] Still RFC — Drop stop positions and platforms
"> Sent: Wed, 28 Mar 2018 16:53:28 +0300
> From: "Ilya Zverev" <i...@zverev.info(mailto:i...@zverev.info)>
> To: tagging@openstreetmap.org(mailto:tagging@openstreetmap.org)
> Subject: [Tagging] Still RFC — Drop stop positions and platforms
>
> Hi folks,
>
> A while ago I've made a proposal to deprecate some public_transport=* 
tags:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Drop_stop_positions_
and_platforms
(https://wiki.openstreetmap.org/wiki/Proposed_features/Drop_stop_positions_and_platforms)
>

In your proposal you complain about subjectively felt things like "history
won't go away", but at the same time you are trying to revert a part of 
history itself - "the public_transport tags are seven years old now". Many
people were involved creating those tags, they are well understood and
discriminate the features they describe in a thoroughly documented and
plausible way.

Just because a lot of deprecated tags have not vanished in favor of the new
ones yet does not mean there is a preference on the deprecated tags. A lot
of users and apps have adopted the new public_transport tags. It simply does
not make any sense to do a rollback on these for the observation of a
sluggish adoption/transition rate.

"



I fully agree with this.





I'm still waiting for full support of new public_transport schema on maps 
(especially on the "transport" layer on osm.org(http://osm.org)) and
decommission of the old schema. Still no progress on it.. Instead, we still
have to use obsolete tags like highway=bus_stop to see stops on the map. It
is mapping  for render I think and we should stop doing it, convert old
schema objects to new schema (a MapRoulette task?) and use only new schema.





I think the new schema is really good and should be fully implemented. It 
means have support in editors and renderers.





Marián




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

"


___
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] Still RFC — Drop stop positions and platforms

[Jo]

I've tried to accomplish that many years ago already, it failed. The people
at the helm of the rendering stack consider the 'old' tags good enough and
the new scheme somehow not explicit enough, hence the double tagging.

Dropping the tags you call obsolete from the data, is not an option as far
as I'm concerned. Part of the reason for mapping bus stops, is to get them
rendered on the map. That's not tagging for the renderer, that's merely
being practical and adapting to the situation at hand.

Adding public_transport=platform/stop_position is also being practical, as
they are treated in certain ways by JOSM, with regard to assignment of
roles.

I stopped worrying about the wasted disk space or processing power several
years ago.

Polyglot



2018-03-28 17:48 GMT+02:00 Marián Kyral <mky...@email.cz>:

>
> -- Původní e-mail --
> Od: "Christian Müller" <cmu...@gmx.de>
> Komu: tagging@openstreetmap.org
> Datum: 28. 3. 2018 16:22:41
> Předmět: Re: [Tagging] Still RFC — Drop stop positions and platforms
>
> > Sent: Wed, 28 Mar 2018 16:53:28 +0300
> > From: "Ilya Zverev" <i...@zverev.info>
> > To: tagging@openstreetmap.org
> > Subject: [Tagging] Still RFC — Drop stop positions and platforms
> >
> > Hi folks,
> >
> > A while ago I've made a proposal to deprecate some public_transport=*
> tags:
> >
> > https://wiki.openstreetmap.org/wiki/Proposed_features/
> Drop_stop_positions_and_platforms
> >
>
> In your proposal you complain about subjectively felt things like "history
> won't go away", but at the same time you are trying to revert a part of
> history itself - "the public_transport tags are seven years old now". Many
> people were involved creating those tags, they are well understood and
> discriminate the features they describe in a thoroughly documented and
> plausible way.
>
> Just because a lot of deprecated tags have not vanished in favor of the
> new ones yet does not mean there is a preference on the deprecated tags. A
> lot of users and apps have adopted the new public_transport tags. It simply
> does not make any sense to do a rollback on these for the observation of a
> sluggish adoption/transition rate.
>
>
> I fully agree with this.
>
>
> I'm still waiting for full support of new public_transport schema on maps
> (especially on the "transport" layer on osm.org) and decommission of the
> old schema. Still no progress on it.. Instead, we still have to use
> obsolete tags like highway=bus_stop to see stops on the map. It is mapping
> for render I think and we should stop doing it, convert old schema objects
> to new schema (a MapRoulette task?) and use only new schema.
>
>
> I think the new schema is really good and should be fully implemented. It
> means have support in editors and renderers.
>
>
> Marián
>
>
> ___
> 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] Still RFC — Drop stop positions and platforms

[Marián Kyral]

-- Původní e-mail --
Od: "Christian Müller" <cmu...@gmx.de>
Komu: tagging@openstreetmap.org
Datum: 28. 3. 2018 16:22:41
Předmět: Re: [Tagging] Still RFC — Drop stop positions and platforms
"> Sent: Wed, 28 Mar 2018 16:53:28 +0300
> From: "Ilya Zverev" <i...@zverev.info>
> To: tagging@openstreetmap.org
> Subject: [Tagging] Still RFC — Drop stop positions and platforms
>
> Hi folks,
>
> A while ago I've made a proposal to deprecate some public_transport=* 
tags:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Drop_stop_positions_
and_platforms
>

In your proposal you complain about subjectively felt things like "history
won't go away", but at the same time you are trying to revert a part of 
history itself - "the public_transport tags are seven years old now". Many
people were involved creating those tags, they are well understood and
discriminate the features they describe in a thoroughly documented and
plausible way.

Just because a lot of deprecated tags have not vanished in favor of the new
ones yet does not mean there is a preference on the deprecated tags. A lot
of users and apps have adopted the new public_transport tags. It simply does
not make any sense to do a rollback on these for the observation of a
sluggish adoption/transition rate.

"



I fully agree with this.





I'm still waiting for full support of new public_transport schema on maps 
(especially on the "transport" layer on osm.org) and decommission of the old
schema. Still no progress on it.. Instead, we still have to use obsolete 
tags like highway=bus_stop to see stops on the map. It is mapping  for
render I think and we should stop doing it, convert old schema objects to 
new schema (a MapRoulette task?) and use only new schema.





I think the new schema is really good and should be fully implemented. It 
means have support in editors and renderers.





Marián

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Jo]

I'm not very optimistic you'll manage to get that proposal to pass.

We'll probably keep double tagging everything for a long time to come. The
reason why I put public_transport=platform on bus stop nodes, is that JOSM
conveniently adds a platform role when they are added to relations. Also
because it felt like the right thing to do, after the public_transport
scheme was voted on. But as it doesn't seem that they will ever be rendered
on the standard rendering, we have to add
highway=bus_stop/railway=tram_stop anyway. I gave up on trying to change
that many years ago.

The reason why I add stop_position nodes at the start and end of the
itineraries, is because I want to split the way there. For me those nodes
don't serve any other purpose, but I'm mostly mapping bus routes (And the
tram routes according to the same scheme).

What we need to find a solution for is that some mappers want to add each
stop to the route relations multiple times for each and every variation of
the itinerary. Once as a stop_position node and once as the way they drew
for the platform. For "consistency" I sometimes see that platform ways are
added even where no platform is present in reality.

Representing the stops as nodes next to the way solves all that. It might
be easier to propose a new tag for those nodes though, could be
public_transport=passengers / halt / pole, than to try to abolish
platform/stop_position.

In the mean time I'll keep tagging them as;
highway=bus_stop
public_transport=platform
bus=yes
+ details

and
railway=tram_stop
public_transport=platform
tram=yes
+ details

I don't think they add a lot of complexity. It's a bit awkward we have
explain that we have all these shiny "new" tags for a consistent scheme,
but we have to keep using the "old" ones, if we want to get stops rendered
too. I don't mind dropping them, and at the same time I don't mind to keep
using them.

What I do mind is to add more than 1 object to the route relations per
stop. But I'll keep making sure tools like PT_Assistant can cope with that
added complexity.

Polyglot


2018-03-28 16:21 GMT+02:00 "Christian Müller" :

> > Sent: Wed, 28 Mar 2018 16:53:28 +0300
> > From: "Ilya Zverev" 
> > To: tagging@openstreetmap.org
> > Subject: [Tagging] Still RFC — Drop stop positions and platforms
> >
> > Hi folks,
> >
> > A while ago I've made a proposal to deprecate some public_transport=*
> tags:
> >
> > https://wiki.openstreetmap.org/wiki/Proposed_features/
> Drop_stop_positions_and_platforms
> >
>
> In your proposal you complain about subjectively felt things like "history
> won't go away", but at the same time you are trying to revert a part of
> history itself - "the public_transport tags are seven years old now".  Many
> people were involved creating those tags, they are well understood and
> discriminate the features they describe in a thoroughly documented and
> plausible way.
>
> Just because a lot of deprecated tags have not vanished in favor of the
> new ones yet does not mean there is a preference on the deprecated tags.  A
> lot of users and apps have adopted the new public_transport tags.  It
> simply does not make any sense to do a rollback on these for the
> observation of a sluggish adoption/transition rate.
>
> The proposal has been long thought about and delivers, in itself, a
> coherent way of tagging public transport infrastructure.  It has learned
> from previous tags, it is thus a refinement of the previous tagging.  There
> will be lots of people -unheared and not- that oppose breaking a (slow
> moving) transition process at this point in time.  Just be patient and give
> it some more years.
>
> You could help and promote the adoption, instead of dilating it.  A lot of
> rural area data has not been touched for years, waiting for you to do
> research and remapping efforts.
>
>
> Greetings
> cmuelle8
>
> ___
> 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] Still RFC — Drop stop positions and platforms

[Christian Müller]

> Sent: Wed, 28 Mar 2018 16:53:28 +0300
> From: "Ilya Zverev" 
> To: tagging@openstreetmap.org
> Subject: [Tagging] Still RFC — Drop stop positions and platforms
>
> Hi folks,
> 
> A while ago I've made a proposal to deprecate some public_transport=* tags:
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Drop_stop_positions_and_platforms
> 

In your proposal you complain about subjectively felt things like "history 
won't go away", but at the same time you are trying to revert a part of history 
itself - "the public_transport tags are seven years old now".  Many people were 
involved creating those tags, they are well understood and discriminate the 
features they describe in a thoroughly documented and plausible way.

Just because a lot of deprecated tags have not vanished in favor of the new 
ones yet does not mean there is a preference on the deprecated tags.  A lot of 
users and apps have adopted the new public_transport tags.  It simply does not 
make any sense to do a rollback on these for the observation of a sluggish 
adoption/transition rate.

The proposal has been long thought about and delivers, in itself, a coherent 
way of tagging public transport infrastructure.  It has learned from previous 
tags, it is thus a refinement of the previous tagging.  There will be lots of 
people -unheared and not- that oppose breaking a (slow moving) transition 
process at this point in time.  Just be patient and give it some more years.

You could help and promote the adoption, instead of dilating it.  A lot of 
rural area data has not been touched for years, waiting for you to do research 
and remapping efforts.


Greetings
cmuelle8

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