Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[John Doe]

Hey, thanks for sharing your views 🙂

07-Mar-2020 03:01:41 Phake Nick :

> [...] for such renderer to work, access restriction for public transit 
> vehicle need to be complete, which is rather difficult not just because of 
> the work it take or the current incompleteness of the amount of keys in OSM 
> that can be used to represent multiple localized types of transportation, but 
> also because of things like mechanical restrictions of bus models that would 
> not be available in any public document and cannot be verified outside of the 
> public transit company.

I feel that this information can largely be approximated from road 
classifications. PT Assistant already complains if a bus route is using a road 
lower than a certain classification. As and when turn restriction data is 
added, routers can adapt the route automatically.

> [...] how can editors know when it is necessary to add a waypoint to show a 
> route correctly?

I think it will always need mapper testing, as it already does. But PTv3 does 
remove a lot of moving parts, and makes creation and maintenance of routes 
easier.

> If a new road is being built next to existing road which doesn't affect 
> existing public transit routes, how to preemptively make sure routing engines 
> won't automatically redirected a route to the new road?

In this case, since the platforms being served haven't changed, I think you'll 
find that
1. The likelihood of the route changing is very low. Even hail and ride routes 
shouldn't be likely to change much, since the via points used to define them 
would probably keep the routers on track.
2. Even if it does change, the platforms are the same and the router is still 
preferring the fastest path between them - users are unlikely to be greatly 
affected. At worst, accuracy of ETAs could be affected.

What I have in mind is the case of Delhi's NH9, in which a road was changed 
from two to four carriageways. In such a situation, with the constraint of the 
existing stops, routers would have to ignore the new inner carriageways and 
stick to the outer carriageways, which is exactly what happened on the ground 😄 
If you have some other examples in mind, it would help us all to discuss their 
specifics.

> Third, way points are more transient than ways. It's more easy for a node to 
> be deleted or replaced when editing geometry than ways. How to maintain 
> integrity of a route geometry when others edit road geometry?

To verify this, I tried deleting a stop position which was part of a route 
relation. Both JOSM and Vespucci warn you about the relation, and ask for 
confirmation. iD does not, but fortunately someone's already made an issue 
about it and they're considering it - 
https://github.com/openstreetmap/iD/issues/5846

I've added FAQ entries for all these, thanks for the feedback! I hope I'm able 
to address your concerns about our proposal.


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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Alan Mackie]

On Sun, 8 Mar 2020, 13:48 Dave F via Tagging, 
wrote:

> This proposal by Stereo is nothing really new.  Just a alternative to
> routing which has been around since relations were introduced.
> Definitely not 'PTv3'. The 'via' option appears almost as difficult to
> maintain as including ways.
>
>
> On 08/03/2020 01:41, John Doe wrote:
>
>
> >
> > That would be tempting, because it would mean a lot less work for us in
> the short term. However, I'm afraid of ending up like PTv2 -
> > 1. It 'does not deprecate the old tags', use of the new tags is
> 'recommended but not mandatory'...whatever that means.
> It means PTv2 tags aren't required as there are existing tags performing
> the same job.
> > 2. People with a preference for the old tags see that as an excuse to
> keep using them
>
> No. They are preferred because they simple to comprehend, accurate &
> abundant.
> > 3. Consumers see that as an excuse to not support the new schema, even
> after 8 years of people requesting it -
> https://github.com/gravitystorm/openstreetmap-carto/issues/311
> PTv2 
> isn't supported because it's not abundant (people get bored of
> adding them after a couple weeks)
>
> > 4. People who want to use the new tags have to use _both_ sets of tags
> 🤦♀️
> No they don't. They can use just the original tags. PTv2 tags are pure
> duplication.
> > 5. Both sets of tags have to be documented, making the documentation
> more verbose than it might be.
> > They should coexist...for a transitional phase. But it has to be just
> that - a _transition_, not a permanent inconsistent mess.
>
> The original tags are here to stay because they work. PTv2 is a
> *separate*, *independent* scarcer schema running in parallel that adds
> nothing over existing tags.
>
> It is only PTv2 which is the mess. Even those who conceived it are
> confused by it.
>
> DaveF
>

 Whenever I have considered adding things in a ptv2 compatible way I have
ended up confused and reverted to a simple highway=bus_stop. Ptv2  seems to
want imaginary unverifiable stop points and for you to add signs on poles
as "platforms" for reasons I could never fathom. Then of course even the
simplest route actually has to be two or more routes for some reason. All
of these seemed to have documentation spread across several different wiki
pages with no clear relationship to each other.

The new proposal seems to be an attempt to get back to the clarity of the
original system while throwing the baby away with the bathwater. In theory
a router could reconstruct a route from points, if it's simple enough, but
if we are going to do that then we may as well drop the route relation
completely and just put the list of services on the stop nodes where most
jurisdictions have them signposted. After all, we have just massively
increased the amount of data crunching by any consumer anyway, they may as
well start that process by doing a search for local refs and build their
own stop lists.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Martin Koppenhoefer]

sent from a phone

> On 9. Mar 2020, at 09:04, John Doe  wrote:
> 
> What I have in mind is the case of Delhi's NH9, in which a road was changed 
> from two to four carriageways. In such a situation, with the constraint of 
> the existing stops, routers would have to ignore the new inner carriageways 
> and stick to the outer carriageways, which is exactly what happened on the 
> ground 😄 If you have some other examples in mind, it would help us all to 
> discuss their specifics.



Here’s a local example I spotted recently, where a major oneway street has 
changed direction (but which still has to be fixed, unfortunately I do not know 
the details and could not fix it so far, the direction of the road is still 
wrong, and specifics of updated bus routes are unknown to me) : 
https://www.openstreetmap.org/way/22889394

This is something that happens from time to time, another example where major 
oneways have changed direction some years ago is here: 
https://www.openstreetmap.org/way/290266289#map=17/41.89215/12.49178

Another example coming to mind: the introduction of roundabouts on some 
arterial roads required modifications to bus routes.
https://www.openstreetmap.org/way/371587513
https://www.openstreetmap.org/way/378391843

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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[John Doe]

This is quite off-topic, but I can't bear to read more completely unfounded 
criticism of PTv2.

I hereby declare that I find the old tags to be a complete abomination (Is it 
on the way? Is it beside the way? Is it a stop, a platform, a halt, a station? 
Why is a platform or a bus stop a railway or a highway?), and PTv2 tags to be 
very consistent and comprehensible in comparison. Indeed, this thread has 
motivated me to stop using legacy tags entirely - to hell with Carto and other 
legacy consumers.

If tram stops (as described on the wiki) are accessible from both sides and it 
makes sense to put them on the way, then PTv2 is very much justified in 
creating an umbrella tag for stops which are placed on the way. I don't 
understand why the critics of PTv2 seem to think stop positions are such a big 
deal - they are optional!

Platforms are where passengers wait.
Stations are places with many platforms.
Stop positions are where vehicles stop - an optional alternative to using 
platforms, included for backward-compatibility.
And the feature is not confounded with the vehicle that serves it, nor the 
infrastructure provided. A platform is a platform regardless of shelter, bench, 
or tactile paving.

It remains an elusive mystery as to how I, a mere mortal, managed to map >70 
services using this arcane, Baroque schema. /s

https://wiki.openstreetmap.org/wiki/Delhi/Buses#Routes_surveyed_by_traveling

https://wiki.openstreetmap.org/wiki/Noida/Buses#Routes_surveyed_by_traveling

https://wiki.openstreetmap.org/wiki/Delhi/Share_autos

09-Mar-2020 13:46:42 Alan Mackie :

> 
> 
> On Sun, 8 Mar 2020, 13:48 Dave F via Tagging, < tagging@openstreetmap.org 
> [mailto:tagging@openstreetmap.org] > wrote:
> 
> > This proposal by Stereo is nothing really new. Just a alternative to
> > routing which has been around since relations were introduced.
> > Definitely not 'PTv3'. The 'via' option appears almost as difficult to
> > maintain as including ways.
> > 
> > 
> > On 08/03/2020 01:41, John Doe wrote:
> > 
> > 
> > >
> > > That would be tempting, because it would mean a lot less work for us in 
> > > the short term. However, I'm afraid of ending up like PTv2 -
> > > 1. It 'does not deprecate the old tags', use of the new tags is 
> > > 'recommended but not mandatory'...whatever that means.
> > It means PTv2 tags aren't required as there are existing tags performing
> > the same job.
> > > 2. People with a preference for the old tags see that as an excuse to 
> > > keep using them
> > 
> > No. They are preferred because they simple to comprehend, accurate &
> > abundant.
> > > 3. Consumers see that as an excuse to not support the new schema, even 
> > > after 8 years of people requesting it - 
> > > https://github.com/gravitystorm/openstreetmap-carto/issues/311
> > PTv2 [https://github.com/gravitystorm/openstreetmap-carto/issues/311PTv2] 
> > isn't supported because it's not abundant (people get bored of
> > adding them after a couple weeks)
> > 
> > > 4. People who want to use the new tags have to use _both_ sets of tags 🤦♀️
> > No they don't. They can use just the original tags. PTv2 tags are pure
> > duplication.
> > > 5. Both sets of tags have to be documented, making the documentation more 
> > > verbose than it might be.
> > > They should coexist...for a transitional phase. But it has to be just 
> > > that - a _transition_, not a permanent inconsistent mess.
> > 
> > The original tags are here to stay because they work. PTv2 is a
> > *separate*, *independent* scarcer schema running in parallel that adds
> > nothing over existing tags.
> > 
> > It is only PTv2 which is the mess. Even those who conceived it are
> > confused by it.
> > 
> > DaveF
> > 
> 
> Whenever I have considered adding things in a ptv2 compatible way I have 
> ended up confused and reverted to a simple highway=bus_stop. Ptv2 seems to 
> want imaginary unverifiable stop points and for you to add signs on poles as 
> "platforms" for reasons I could never fathom. Then of course even the 
> simplest route actually has to be two or more routes for some reason. All of 
> these seemed to have documentation spread across several different wiki pages 
> with no clear relationship to each other.  
> The new proposal seems to be an attempt to get back to the clarity of the 
> original system while throwing the baby away with the bathwater. In theory a 
> router could reconstruct a route from points, if it's simple enough, but if 
> we are going to do that then we may as well drop the route relation 
> completely and just put the list of services on the stop nodes where most 
> jurisdictions have them signposted. After all, we have just massively 
> increased the amount of data crunching by any consumer anyway, they may as 
> well start that process by doing a search for local refs and build their own 
> stop lists.  
> 


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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Paul Allen]

On Mon, 9 Mar 2020 at 00:18, Joseph Eisenberg 
wrote:

> > editors would have to take similar precautions with nodes.  Not
> impossible, but it would take time to appear.  Your scheme will be more
> fragile than the existing one, at least for a while.
>
> Well yes, any change will take some work by the maintainers of editor
> applications, so we should not make changes lightly.
>

Given that iD still seems to scramble sorted routes in some circumstances,
one
should not assume that editors will correctly handle any changes we make.  I
might be being unfair to iD here, I didn't check the route was still sorted
before
I added a spur, so maybe somebody else doing something that didn't directly
affect the route using another editor scrambled it.

>
> But this should not prevent us from making a change which would make
> things easier for mappers and might better represent reality.
>

Given recent comments on the proposal's talk page, I doubt it will better
represent reality because it's the router that determines the fine details.
Maybe it will go for shortest path, or fastest path, or something else.
Maybe at some future date it will switch from shortest path to fastest
path.  Yes, there are vias, but read on.

For a long-distance inter-city route where the bus only stops at official
stops,
this might be good enough for many people.  The router may or may not
guess the exact route between two stops, but it's close enough for some
people.  Not for me, because I worry when a bus I'm on isn't following
the route I thought it would.  Maybe I'm on the wrong bus.  Maybe the
route has changed and it's not going to stop where I want to get off.  I
want to see exact routes, not close approximations.

The county I live in is the second-most sparsely populated county in
Wales and has an area of 1,795 square km (693 sq mi).  Just about
every route is hail and ride.  Even the routes in the towns (and the
one city) are hail and ride except in small sections where the road
configuration would make it unsafe to stop.  In these cases,
knowing the exact route is vital: otherwise you'll be waiting
for a bus where the router thinks it goes instead of where it
actually goes.  Yes, there are vias, but read on.

>
> Greater ease of mapping is a strong reason to consider changes to
> editor applications.
>

Is it actually easier?  For the "long-distance, few official stops, only
stops
at official stops" routes, maybe.  For any route in my county I'll have
to insert vias to make sure hail and ride buses (almost all of them) are
mapped as going where they actually go.  It means I have to spend time
thinking like a router, anticipating alternate routes between any adjacent
junctions and insert a via where a router might possibly come up with
the non-factual answer.  Sorting additional vias into place is going to
be almost as tedious as re-sorting existing relations of ways that
get scrambled.

However carefully I place the vias (and check the calculated route to see if
it's right, some change to the roads which doesn't affect the route the bus
actually takes may cause the mapped route to be wrong until one or more
new vias are inserted.  A new housing estate with two connections to
the existing road system could cause the bus to be re-routed.  Fine if
the person adding the estate takes care to check nearby bus routes.
A change to the speed limit on a way may cause the router to decide
on a different route.  Etc.

Adding ways to create a relation is mechanical and tedious but requires
little thought.  Guessing where one might have to insert vias that will cope
not only with whatever router is used to generate the carto but all future
algorithms that router might use requires a lot of thoughtful consideration
of
potential alternative routes.  Or I can avoid thought by placing a via at
every node along the route, which is more tedious than just adding ways.

In some cases this proposal might be easier, in others (the ones I deal
with) a
lot harder.  Which is fine if they're alternative ways of mapping bus
routes.  But
the proposers seem to want to make this the one and only way of doing
things.

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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Peter Elderson]

I suggest again: Make the route a separate route relation and include it as
an optional member of the PTv3 routing relation as proposed. Everybody
happy (routing lobby AND route lobby), all bases covered including backward
compatibility. Data users, renderers and tools can make up their mind what
best serves their purpose.

Best, Peter Elderson


Op ma 9 mrt. 2020 om 12:50 schreef Paul Allen :

> On Mon, 9 Mar 2020 at 00:18, Joseph Eisenberg 
> wrote:
>
>> > editors would have to take similar precautions with nodes.  Not
>> impossible, but it would take time to appear.  Your scheme will be more
>> fragile than the existing one, at least for a while.
>>
>> Well yes, any change will take some work by the maintainers of editor
>> applications, so we should not make changes lightly.
>>
>
> Given that iD still seems to scramble sorted routes in some circumstances,
> one
> should not assume that editors will correctly handle any changes we make.
> I
> might be being unfair to iD here, I didn't check the route was still
> sorted before
> I added a spur, so maybe somebody else doing something that didn't directly
> affect the route using another editor scrambled it.
>
>>
>> But this should not prevent us from making a change which would make
>> things easier for mappers and might better represent reality.
>>
>
> Given recent comments on the proposal's talk page, I doubt it will better
> represent reality because it's the router that determines the fine details.
> Maybe it will go for shortest path, or fastest path, or something else.
> Maybe at some future date it will switch from shortest path to fastest
> path.  Yes, there are vias, but read on.
>
> For a long-distance inter-city route where the bus only stops at official
> stops,
> this might be good enough for many people.  The router may or may not
> guess the exact route between two stops, but it's close enough for some
> people.  Not for me, because I worry when a bus I'm on isn't following
> the route I thought it would.  Maybe I'm on the wrong bus.  Maybe the
> route has changed and it's not going to stop where I want to get off.  I
> want to see exact routes, not close approximations.
>
> The county I live in is the second-most sparsely populated county in
> Wales and has an area of 1,795 square km (693 sq mi).  Just about
> every route is hail and ride.  Even the routes in the towns (and the
> one city) are hail and ride except in small sections where the road
> configuration would make it unsafe to stop.  In these cases,
> knowing the exact route is vital: otherwise you'll be waiting
> for a bus where the router thinks it goes instead of where it
> actually goes.  Yes, there are vias, but read on.
>
>>
>> Greater ease of mapping is a strong reason to consider changes to
>> editor applications.
>>
>
> Is it actually easier?  For the "long-distance, few official stops, only
> stops
> at official stops" routes, maybe.  For any route in my county I'll have
> to insert vias to make sure hail and ride buses (almost all of them) are
> mapped as going where they actually go.  It means I have to spend time
> thinking like a router, anticipating alternate routes between any adjacent
> junctions and insert a via where a router might possibly come up with
> the non-factual answer.  Sorting additional vias into place is going to
> be almost as tedious as re-sorting existing relations of ways that
> get scrambled.
>
> However carefully I place the vias (and check the calculated route to see
> if
> it's right, some change to the roads which doesn't affect the route the bus
> actually takes may cause the mapped route to be wrong until one or more
> new vias are inserted.  A new housing estate with two connections to
> the existing road system could cause the bus to be re-routed.  Fine if
> the person adding the estate takes care to check nearby bus routes.
> A change to the speed limit on a way may cause the router to decide
> on a different route.  Etc.
>
> Adding ways to create a relation is mechanical and tedious but requires
> little thought.  Guessing where one might have to insert vias that will
> cope
> not only with whatever router is used to generate the carto but all future
> algorithms that router might use requires a lot of thoughtful
> consideration of
> potential alternative routes.  Or I can avoid thought by placing a via at
> every node along the route, which is more tedious than just adding ways.
>
> In some cases this proposal might be easier, in others (the ones I deal
> with) a
> lot harder.  Which is fine if they're alternative ways of mapping bus
> routes.  But
> the proposers seem to want to make this the one and only way of doing
> things.
>
> --
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/ta

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Jarek Piórkowski]

On Mon, 9 Mar 2020 at 07:29, John Doe  wrote:
> This is quite off-topic, but I can't bear to read more completely unfounded 
> criticism of PTv2.

highway=bus_stop ("PTv1") is fine for people who survey bus stops and
who want to approximately map a route of a simple bus.

PTv2 is fine for people who want to handle routes that have variants
and branches and who want computer validators to be able to spot
potential errors in these branches.

Some people on both sides don't want to see advantages of the other
scheme, and resort to flatly declaring them bad.

--Jarek (credentials: about 20 non-basic tram, bus, and train routes,
but in an area where stop locations are mostly already surveyed/known)

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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Phake Nick]

At 2020-03-09 Mon 16:04, John Doe   wrote:

>
> Hey, thanks for sharing your views 🙂
>
> 07-Mar-2020 03:01:41 Phake Nick :
>
> > [...] for such renderer to work, access restriction for public transit
> vehicle need to be complete, which is rather difficult not just because of
> the work it take or the current incompleteness of the amount of keys in OSM
> that can be used to represent multiple localized types of transportation,
> but also because of things like mechanical restrictions of bus models that
> would not be available in any public document and cannot be verified
> outside of the public transit company.
>
> I feel that this information can largely be approximated from road
> classifications. PT Assistant already complains if a bus route is using a
> road lower than a certain classification. As and when turn restriction data
> is added, routers can adapt the route automatically.
>

It is not the question of grade but it is related to turn diameter and
obstacles and emission regulation and such on different roads, and they
differ according to specific bus models used by each routes.


>
> > [...] how can editors know when it is necessary to add a waypoint to
> show a route correctly?
>
> I think it will always need mapper testing, as it already does. But PTv3
> does remove a lot of moving parts, and makes creation and maintenance of
> routes easier.
>

In PTv2 one can simply select all the ways and then add them into relation,
unlike this proposal where I woild need to try and see where I needs to add
waypoint, and identify if there are any way that can be rendered
differently on different renderer despite it might coincidentally appear as
expected on editor's software.

>
> > If a new road is being built next to existing road which doesn't affect
> existing public transit routes, how to preemptively make sure routing
> engines won't automatically redirected a route to the new road?
>
> In this case, since the platforms being served haven't changed, I think
> you'll find that
> 1. The likelihood of the route changing is very low. Even hail and ride
> routes shouldn't be likely to change much, since the via points used to
> define them would probably keep the routers on track.
> 2. Even if it does change, the platforms are the same and the router is
> still preferring the fastest path between them - users are unlikely to be
> greatly affected. At worst, accuracy of ETAs could be affected.
>

1. Yes, the chance of route changes are very low, and that's why I ask how
to fixate a route against such changes which would affect how routing
engines route a route.
2. As I have mentioned previously, my greatest use of PT mapping is the
geometry of the routes. So even if stops are the same that'd still affect
my intended use of those routes.


> What I have in mind is the case of Delhi's NH9, in which a road was
> changed from two to four carriageways. In such a situation, with the
> constraint of the existing stops, routers would have to ignore the new
> inner carriageways and stick to the outer carriageways, which is exactly
> what happened on the ground 😄 If you have some other examples in mind, it
> would help us all to discuss their specifics.
>

For example, routes like route E11 in Hong Kong which continues to
use Cheung Tsing Tunnel instead of Nam Wan Tunnel after the latter finish
construction.



> > Third, way points are more transient than ways. It's more easy for a
> node to be deleted or replaced when editing geometry than ways. How to
> maintain integrity of a route geometry when others edit road geometry?
>
> To verify this, I tried deleting a stop position which was part of a route
> relation. Both JOSM and Vespucci warn you about the relation, and ask for
> confirmation. iD does not, but fortunately someone's already made an issue
> about it and they're considering it -
> https://github.com/openstreetmap/iD/issues/5846
>
> I've added FAQ entries for all these, thanks for the feedback! I hope I'm
> able to address your concerns about our proposal.
>
>
> ___
> 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] Feature Proposal - RFC - Public Transport v3

[Paul Allen]

On Mon, 9 Mar 2020 at 13:45, Phake Nick  wrote:

>
> In PTv2 one can simply select all the ways and then add them into
> relation, unlike this proposal where I woild need to try and see where I
> needs to add waypoint, and identify if there are any way that can be
> rendered differently on different renderer despite it might coincidentally
> appear as expected on editor's software.
>

+1

And then you have to worry that whatever router the renderer uses changes
its
algorithm and/or weightings in such a way that the bus route that is now
rendered
no longer matches reality.  Oh, and worry about future speed limit changes
if the router is going for fastest rather than shortest.  Oh, and new roads
that
offer a shorter and/or faster path between waypoints.  Oh, and different
renderers
using different routers.

The only way you stand a chance of future-proofing against changes like
those is
to include EVERY node along the route as a waypoint.  Which would be more
effort than including all the ways, since a way might consist of many nodes.
And even then a new road might change the rendered route.

This proposal might be OK for long-distance inter-city type routes that stop
only at official stops and there are very few official stops.  Some people
might be happy with just a route from A to B even if it's not quite correct
because it shows the essential inter-connectedness.  I wouldn't be happy,
because the moment I saw the bus taking a different path from the one
shown on the map is the moment I'd be worrying I was on the wrong bus.

As an alternative for those mapping routes where it's easer to use and gives
adequate results, fine.  There are, however, people who want this to
completely replace existing ways of mapping bus routes, and that
possibility means I'll vote against it unless the proposal explicitly states
that it's an alternative, not a replacement.

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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Dave F via Tagging]

On 09/03/2020 13:21, Jarek Piórkowski wrote:


PTv2 is fine for people who want to handle routes that have variants
and branches and who want computer validators to be able to spot
potential errors in these branches.


I'm intrigued: What Ptv2 tags enable those?


DaveF

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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Alan Mackie]

Ptv2 uses a different relation for every possible direction, variant and
whim and rolls them up into a routemaster relation. So you can
theoretically check whether each bit is continuous.

On Mon, 9 Mar 2020, 17:09 Dave F via Tagging, 
wrote:

> On 09/03/2020 13:21, Jarek Piórkowski wrote:
> >
> > PTv2 is fine for people who want to handle routes that have variants
> > and branches and who want computer validators to be able to spot
> > potential errors in these branches.
>
> I'm intrigued: What Ptv2 tags enable those?
>
>
> DaveF
>
> ___
> 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] Feature Proposal - RFC - Public Transport v3

[Janko Mihelić]

As an avid public transportation mapper, I welcome the PTv3. It has all the
features I need, and it will reduce maintenance by a lot.

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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Victor/tuxayo]

Hello,

On 20-03-06 11:07, John Doe wrote:

Stereo and I have been working on a schema that makes it easier to create and 
maintain public transport route relations. We would like to invite feedback, 
questions, and suggestions, so it can mature and hopefully gain widespread use.

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


Pinging Virgile1994.
@Virgile1994 do you have an English translation of your proposal?
https://wiki.openstreetmap.org/wiki/User:Virgile1994/Proposition
Which has been used since few years in a number of networks:
https://wiki.openstreetmap.org/wiki/User:Virgile1994/Mes_R%C3%A9alisations

And do you have feedback about the v3 proposal? This is the best 
opportunity to contribute to what most people will be applying in the 
next years.


Here are the previous messages:
http://gis.19327.n8.nabble.com/Feature-Proposal-RFC-Public-Transport-v3-td5959870.html#none

Here you can subscribe to the list to answer:
https://lists.openstreetmap.org/listinfo/tagging

Cheers,

--
Victor/tuxayo

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

Re: [Tagging] Criticism of PTv2 (was: Feature Proposal - RFC - Public Transport v3)

[Alan Mackie]

On Mon, 9 Mar 2020 at 11:30, John Doe  wrote:

>
> This is quite off-topic, but I can't bear to read more completely
> unfounded criticism of PTv2.
>
> I hereby declare that I find the old tags to be a complete abomination (Is
> it on the way? Is it beside the way? Is it a stop, a platform, a halt, a
> station? Why is a platform or a bus stop a railway or a highway?), and PTv2
> tags to be very consistent and comprehensible in comparison. Indeed, this
> thread has motivated me to stop using legacy tags entirely - to hell with
> Carto and other legacy consumers.
>

So it's better to label them all as platforms? I can't see any raised area
in a typical bus stop:
https://www.mapillary.com/app/?lat=53.470542&lng=-2.23758900071&z=17&pKey=sHRXz6nnNKdV1u_AFXAjJw&mapStyle=OpenStreetMap&focus=photo

Why would we tag it as if it looks like this?
https://www.mapillary.com/app/?lat=53.48198622803868&lng=-2.2391616517737676&z=17&mapStyle=OpenStreetMap&pKey=-yZ4kkeVica0Kcmnd-TotA&focus=photo

The section for buses on the main public transport page says: "If there is
no real platform ... the location of the bus stop sign ...  gets ...
public_transport=platform. " I.E. If there is no platform, make one up. How
is that more logical than highway=bus_stop for "there is a bus stop here"?

As for 'why is  a bus stop a highway' do you also suggest we scrap the
tagging for traffic lights, road signs, crosswalks etc. etc?

If tram stops (as described on the wiki) are accessible from both sides and
> it makes sense to put them on the way, then PTv2 is very much justified in
> creating an umbrella tag for stops which are placed on the way. I don't
> understand why the critics of PTv2 seem to think stop positions are such a
> big deal - they are optional!
>

They are largely imaginary for most types of transport. Most public
transport experiences centre around where the people stand not when the
driver slams on the brakes.


> Platforms are where passengers wait.
> Stations are places with many platforms.
> Stop positions are where vehicles stop - an optional alternative to using
> platforms, included for backward-compatibility.
> And the feature is not confounded with the vehicle that serves it, nor the
> infrastructure provided. A platform is a platform regardless of shelter,
> bench, or tactile paving.
>

A platform is a platform, a perfectly flat bit of sidewalk isn't.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Jarek Piórkowski]

On Mon, 9 Mar 2020 at 13:07, Dave F via Tagging
 wrote:
> On 09/03/2020 13:21, Jarek Piórkowski wrote:
> > PTv2 is fine for people who want to handle routes that have variants
> > and branches and who want computer validators to be able to spot
> > potential errors in these branches.
>
> I'm intrigued: What Ptv2 tags enable those?

Separate relations per each route variant - verifying that the highway
ways are continuous in the relation.

Or are you suggesting to adopt the PTv2 one-relation-per-trip-variant
scheme without using public_transport=* tags? Feel free, as far as I
can tell JOSM PT plugin doesn't even complain about that. Just don't
be surprised if iD "upgrades" your tags after.

--Jarek

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

[Tagging] camp_pitch : an area inside a site : also in a park ?

[Marc M.]

Hello,

When fixing depreciated tag camp_site=camp_pitch,
I've found several of these in huge parks in the United States.
the current and approved definition of tourism=camp_pitch says that
sites are tourism=camp_site or tourism=caravan_site
however these parks often have identical characteristics to these
tourism=*_site : they sometimes have a common reception desk for
different camp_pitch, toilets, a drinking water point, ...

what do you think is the best schema :
- Change the definition of tourism=camp_pitch to include these large
parks as a valid _site.
- add tourism=camp_site on the whole park ? with the default of having 2
main tags on the same object
- other ideas ?

one among others https://overpass-turbo.eu/s/Rsg

Regards,
Marc

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

Re: [Tagging] camp_pitch : an area inside a site : also in a park ?

[Joseph Eisenberg]

> These "parks" often have identical characteristics to these
tourism=*_site : they sometimes have a common reception desk for
different camp_pitch, toilets, a drinking water point, ...

Many places in the USA are tagged leisure=park when they really ought
to be boundary=protected area, or divided up into smaller areas which
represent the actual feature.

If the "park" is large, often only part of it is the campsite. In that
case, create a new area which just includes the actual
tourism=camp_site feature, if you can confirm the boundaries, and this
should include the individual pitches as well.

If there are more than one cluster of pitches which are widely
separated and have a separate entrance or reception, there may be
several separate tourism=camp_site areas.

Your link did not work for me. Were you trying to show the relation
with ID 6565934, perhaps?
https://www.openstreetmap.org/relation/6565934 - "High Cliff State
Park".

A "state park" is similar to a "national park" though smaller and
managed by a State instead of the Federal (national) government, so it
usually should be a boundary=protected_area instead of a leisure=park.
In this case the State Park seems mainly for recreation, so it's
possible that part of the area should be tagged leisure=park, but the
part that is a historic site shouldn't be, nor the part that is a
tourism=camp_site, etc... (I don't know the area well enough to re-map
it myself)

https://en.wikipedia.org/wiki/en:High%20Cliff%20State%20Park?uselang=en-US
- "The effigy mounds at the top of the escarpment have led to a small
part of the park ... added to the National Register of Historic
Places, listed as High Cliff Mounds" - that's not a leisure=park, but
perhaps a historic=archeological_site (actually, it looks like these
are already mapped).

On 3/10/20, Marc M.  wrote:
> Hello,
>
> When fixing depreciated tag camp_site=camp_pitch,
> I've found several of these in huge parks in the United States.
> the current and approved definition of tourism=camp_pitch says that
> sites are tourism=camp_site or tourism=caravan_site
> however these parks often have identical characteristics to these
> tourism=*_site : they sometimes have a common reception desk for
> different camp_pitch, toilets, a drinking water point, ...
>
> what do you think is the best schema :
> - Change the definition of tourism=camp_pitch to include these large
> parks as a valid _site.
> - add tourism=camp_site on the whole park ? with the default of having 2
> main tags on the same object
> - other ideas ?
>
> one among others https://overpass-turbo.eu/s/Rsg
>
> Regards,
> Marc
>
> ___
> 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] camp_pitch : an area inside a site : also in a park ?

[Kevin Kenny]

New York's largest parks are enormous - the Adirondack Park is about
the same land area as Massachusetts or Belgium, and the Catskill Park
is about of a size with Yosemite National Park. Between the magnitude
and the function, I've had no compunction about tagging both of them
`boundary=national_park`, particularly since (as is also done in the
UK) there is human habitation within them, still regulated by the park
authorities. I discuss the reasoning behind this decision at
considerably more length in the diary entry at
https://www.openstreetmap.org/user/ke9tv/diary/390233.

Both of these large reserves have multiple state campgrounds within
them, and these are `tourism=camp_site`, leaving the possibility of
tagging the individual pitches if desired (I've not tried). They also
contain ski areas and day use areas (the latter are
`recreation_ground`), Wilderness Areas and Wild Forests
(`boundary=protected_area protect_class=1b`) and various other
facilities.  A worked example is that the Fish Creek Pond Campground
(https://www.openstreetmap.org/relation/6378239) is surrounded by but
cut out from the Saranac Lakes Wild Forest
(https://www.openstreetmap.org/relation/6362702), which is a diffuse
area of state land (with waterways and private inholdings cut out)
that is in turn within the Adirondack Park
(https://www.openstreetmap.org/relation/1695394). It has designated
and numbered pitches within it which have been too numerous for me to
map: https://www.dec.ny.gov/docs/permits_ej_operations_pdf/fishcreekmap2019.pdf.

New York's State Parks (the two big ones aren't State Parks, they're a
different beast entirely) are also tagged as protected areas. They are
also a mix of conservation and recreation, In most of the larger ones,
the former use predominates, so I also tag them as
`leisure=nature_reserve` and exercise judgment (which may be
inconsistent) about `protect_class`.  In those cases, I overlay the
other land uses - recreation_ground, camp_site, winter_sports, etc.,
and the data consumers don't appear to be all that unhappy with the
result. For the largest of the State Parks (Allegany, Bear
Mountain-Harriman-Sterling Forest, Minnewaska, Letchworth, Fahnestock,
Hudson Highlands, Taconic, maybe Moreau Lake), I'd not be too
uncomfortable with `boundary=national_park`, which would also deal
with the fact that these parks contain multiple campgrounds wihtout
bending the tagging rules by putting landuse within landuse.

Some of the State Parks are actually historic sites, swimming beaches,
marinas, stand-alone recreation grounds, golf courses or even parks in
the European/OSM sense (landscaped areas principally for passive
leisure and visual enjoyment). These are tagged according to their
purpose.

Many of New York's State Parks were initially entered by mappers other
than me, I haven't always messed with their tagging, so there's still
some inappropriate 'leisure=park' floating around.

New York also has State Forests (`boundary=protected_area
protect_class=6` since they are managed in part for timber harvest). I
don't think any have managed campgrounds within their borders, but
some do restrict backcountry camping to designated pitches, which
could be mapped.

Tagging of State Parks has been hotly debated, to say the least.  My
lengthy discussion, trying to find common ground, can be found at
https://www.openstreetmap.org/user/ke9tv/diary/390260.  The underlying
problem with tagging appears to be that the word 'park' doesn't mean
the same thing in the US that it does in the UK, and the language of
OpenStreetMap tagging is UK English. Unfortunately, the UK really
doesn't have anything that's parallel in structure and function to a
'state park' in the US, so there is no appropriate term for us to use!
 It tends to be that the purists see the multiple functions that a
typical State Park serves, and say, "you can't map the whole thing,
only map the individual facilities." Understandably, the US mappers
rebel against that dictum: the "whole thing" is what is signed, and
what appears on paper maps sold in the US, and what's commonly spoken
of: "We're going to Bear Mountain State Park for the afternoon, want
to come along?" ("State Park" is often omitted in speaking; to locals,
'Bear Mountain' more likely means the State Park than the eponymous
mountain within it. It's quite ordinary to go to "Moreau Lake" and
never come withiin sight of the lake, much less swim or put a boat in
the water, or to "Bear Mountain" without climbing it.)


On Mon, Mar 9, 2020 at 7:25 PM Marc M.  wrote:
>
> Hello,
>
> When fixing depreciated tag camp_site=camp_pitch,
> I've found several of these in huge parks in the United States.
> the current and approved definition of tourism=camp_pitch says that
> sites are tourism=camp_site or tourism=caravan_site
> however these parks often have identical characteristics to these
> tourism=*_site : they sometimes have a common reception desk for
> different camp_pitch, toilets, a drinking water poi

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[John Doe]

> 
> I suggest again: Make the route a separate route relation and include it as 
> an optional member of the PTv3 routing relation as proposed. Everybody happy 
> (routing lobby AND route lobby), all bases covered including backward 
> compatibility.
> 
> 


Thank you for that suggestion, apologies for not being able to talk about it 
before.

I like that it tries to let mappers who like ways to use them, without stepping 
on the toes of (i.e. without creating maintenance problems for) those who don't.

> Data users, renderers and tools can make up their mind what best serves their 
> purpose.

But that's where I feel confused.

If e.g. OsmAnd decides to only use the route relation, mappers would be 
discouraged from using the routing relation. There would be no maintenance 
benefits.

There's also the fact that it creates two sets of data to describe the same 
thing (the route)...it means having to keep them in sync. That would _increase_ 
maintenance work, instead of decreasing it. 🙁



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