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

[Jarek Piórkowski]

On Wed, 11 Mar 2020 at 23:09, Joseph Eisenberg
 wrote:
> >  In inclement weather, passengers may well be found waiting in
> the transit shelter 8 metres to west, and the tram will stop for them
> if they are waiting in the shelter. It might also stop if you are
> waiting a little bit beyond the shelter
>
> In this case it sounds like the tram operators are allowed to stop in
> several different places.
>
> I would pick the place where the tram normally stops: either at the
> sign or the location of the shelter, depending on the standard
> practice in the local area. Either way, tram riders will be directed
> to the correct location by routing apps: an 8 meter difference is not
> significant.

But why pick one and not the other? Only for the sake of having one
point rather than two in a database? Especially in this case where
they can be fairly reasonably described as "stop position" (the sign)
and "waiting area" (the shelter).

> >  Berlin mapping of streetside tram stops like 
> > https://www.openstreetmap.org/way/389400777
>
> I have not visited that location in person, and the aerial imagery is
> not high enough resolution to see if there is a separate platform, so
> it is hard for me to say.
>
> The "gold standard" is survey: visiting the stop in location (and
> riding the tram perhaps)
>
> Do you know if the "platform" here is separate from the sidewalk in
> some way? It should either be a different height, or a different
> surface, or at least marked with a painted / thermoplastic line.
> Otherwise the length of this "platform" way would be arbitrary: why
> not include the whole block?

In this particular case, there is not a platform that can be
distinguished - it's a curbside stop. The length of the "platform" way
appears to roughly match the length of the vehicles and thus the area
where the vehicles can be boarded (all-door boarding is in effect).
Berlin doesn't have many curbside stops but where they do exist, this
seems to be the prevailing local tagging.

--Jarek

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

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

[Joseph Eisenberg]

>  In inclement weather, passengers may well be found waiting in
the transit shelter 8 metres to west, and the tram will stop for them
if they are waiting in the shelter. It might also stop if you are
waiting a little bit beyond the shelter

In this case it sounds like the tram operators are allowed to stop in
several different places.

I would pick the place where the tram normally stops: either at the
sign or the location of the shelter, depending on the standard
practice in the local area. Either way, tram riders will be directed
to the correct location by routing apps: an 8 meter difference is not
significant.

>  Berlin mapping of streetside tram stops like 
> https://www.openstreetmap.org/way/389400777

I have not visited that location in person, and the aerial imagery is
not high enough resolution to see if there is a separate platform, so
it is hard for me to say.

The "gold standard" is survey: visiting the stop in location (and
riding the tram perhaps)

Do you know if the "platform" here is separate from the sidewalk in
some way? It should either be a different height, or a different
surface, or at least marked with a painted / thermoplastic line.
Otherwise the length of this "platform" way would be arbitrary: why
not include the whole block?

-- Joseph Eisenberg

On 3/12/20, Jarek Piórkowski  wrote:
> On Wed, 11 Mar 2020 at 22:22, Joseph Eisenberg
>  wrote:
>> > I am thinking of cases like streetside stops for 30 m or 45 m long
>> trams. There might be a shelter, which is the most prominent physical
>> feature of the tram stop. There is no explicit platform. The tram stop
>> sign might be 10 metres away from the shelter, and the farthest
>> possible boarding point at the back doors of the tram another 10 m
>> away. If only a single node could be used, where is it placed and why?
>>
>> How are you currently mapping such tram stops?
>>
>> I would indicate the point where passengers wait for the tram, near
>> the front door, which is usually where the sign is located.
>>
>> But it needs to be verifiable: if another mapper rides the tram, they
>> should be able to understand why the stop is at that location.
>
> To give a real-world example:
> https://www.openstreetmap.org/node/362413 (Esri has the best
> aerial imagery in this area) is placed where the sign for the stop is
> located. In inclement weather, passengers may well be found waiting in
> the transit shelter 8 metres to west, and the tram will stop for them
> if they are waiting in the shelter. It might also stop if you are
> waiting a little bit beyond the shelter. Exact stopping location can
> vary a couple of metres from operator to operator. Where would you
> place the one true node?
>
>> If you map anything as an area, there needs to be a real-world feature
>> that matches that area.
>
> What do you think about the Berlin mapping of streetside tram stops
> like https://www.openstreetmap.org/way/389400777 - as a linear way
> matching the stretch of the sidewalk where passengers might wait?
>
> --Jarek
>
> ___
> 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 - Voting – Refugee site location

[Joseph Eisenberg]

Voting is still open a few more days for place=refugee_site

But I am still concerned about this claim: "For long-term refugee site
that are no longer under operation of the UNHCR or another
organization (other NGO, government, etc.) it is possible to use
instead or also the tag place=town or place=village."

You cannot tag the same Openstreetmap database object with both
place=town and place=refugee_site - you would have to create 2
separate nodes.

-- Joseph Eisenberg

On 3/3/20, Joseph Eisenberg  wrote:
> I do not believe the concerns and questions at the talk page have been
> adequately addressed
>
> (https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Refugee_Site_Location)
>
>  While I appreciate the idea of mapping locations related to refugees,
> I do not think the proposed definition and tags wil work.
>
> The description includes too many possibilities: "A refugee site is a
> place that hosts refugee and/or IDP population and that is under
> operation of the UNHCR or another organization (other NGO, government
> agency, etc.). A refugee site can be a temporary site or a long term
> site."
>
> This could include a single building which which is operated by a
> local church and hosts a single refugee family from another country
> for a month or two. It could also include a huge semi-permanent
> settlement with thousands of people, shops, businesses, permanent
> structures and so on, which is nominally operated by a government
> agency but which actually functions as a town for many years.
>
> The definition needs to be changed so that it is clear what qualifies
> and what does not.
>
> Also, another new tag "refugee_site:for" is proposed with values
> "refugee" or "IDP." The second value is bad because it's a rare
> acronym for "internally displaced persons", and neither value is
> defined. Apparently "refugree" might only be used for people who have
> crossed a national border?
>
> There is also mention of additional tags "operational_status" and
> "official_status=unofficial" which are undefined. The second,
> official_status, had a proposal but that one was quite different
> (https://wiki.openstreetmap.org/wiki/Proposed_features/Official_status)
>
> And operational_status=* has no wiki page, and this proposal does not
> define it.
>
> For these reasons, the current version of the proposal should not be
> approved.
>
> I suggest improving the definition of the tags and making it very
> clear which new tags are being approved by the proposal.
>
> - Joseph Eisenberg
>
> On 3/2/20, Manon Viou  wrote:
>> Dear all,
>>
>> The proposed feature for refugee site location was posted for comment on
>> January 30 th. During February we have received several valuable
>> comments.
>> Thank you for your feedbacks!
>>
>> Your participation allowed us to improve our proposal in order to map
>> refugee site location.
>>
>> We would like now to start the Request for Voting,
>>
>> Please find below the proposal which is being put to vote :
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Refugee_Site_Location#Tagging
>>
>> This ends on 2020-02-17
>>
>> Regards,
>>
>> Manon,
>>
>> [image: CartONG- Humanitarian mapping and information management]
>>
>> Manon Viou
>>
>> Coordinatrice projet Missing Maps
>>
>> [image: Email:] m_v...@cartong.org | [image: Skype:] manon.viou
>> [image: Phone:] +33 (0)4 79 26 28 82 | [image: Mobile:] +33 (0)7 83889839
>>
>> [image: Address:] Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E
>

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

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

[Jarek Piórkowski]

On Wed, 11 Mar 2020 at 22:22, Joseph Eisenberg
 wrote:
> > I am thinking of cases like streetside stops for 30 m or 45 m long
> trams. There might be a shelter, which is the most prominent physical
> feature of the tram stop. There is no explicit platform. The tram stop
> sign might be 10 metres away from the shelter, and the farthest
> possible boarding point at the back doors of the tram another 10 m
> away. If only a single node could be used, where is it placed and why?
>
> How are you currently mapping such tram stops?
>
> I would indicate the point where passengers wait for the tram, near
> the front door, which is usually where the sign is located.
>
> But it needs to be verifiable: if another mapper rides the tram, they
> should be able to understand why the stop is at that location.

To give a real-world example:
https://www.openstreetmap.org/node/362413 (Esri has the best
aerial imagery in this area) is placed where the sign for the stop is
located. In inclement weather, passengers may well be found waiting in
the transit shelter 8 metres to west, and the tram will stop for them
if they are waiting in the shelter. It might also stop if you are
waiting a little bit beyond the shelter. Exact stopping location can
vary a couple of metres from operator to operator. Where would you
place the one true node?

> If you map anything as an area, there needs to be a real-world feature
> that matches that area.

What do you think about the Berlin mapping of streetside tram stops
like https://www.openstreetmap.org/way/389400777 - as a linear way
matching the stretch of the sidewalk where passengers might wait?

--Jarek

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

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

[Joseph Eisenberg]

> I am thinking of cases like streetside stops for 30 m or 45 m long
trams. There might be a shelter, which is the most prominent physical
feature of the tram stop. There is no explicit platform. The tram stop
sign might be 10 metres away from the shelter, and the farthest
possible boarding point at the back doors of the tram another 10 m
away. If only a single node could be used, where is it placed and why?

How are you currently mapping such tram stops?

I would indicate the point where passengers wait for the tram, near
the front door, which is usually where the sign is located.

But it needs to be verifiable: if another mapper rides the tram, they
should be able to understand why the stop is at that location.

If you map anything as an area, there needs to be a real-world feature
that matches that area.

(So if your trams or trains stop in the exact same place each time,
with sub-meter precision, and all vehicles have the same length and
same door configuration, it's probably fine to invent a new tag to map
the location of each door, especially when the platform has a
permanent marking which shows where the door will open, as is common
with modern subways.

But it would not be good to map this on lines where different vehicles
can vary in length or door configuration, or if the operators do not
stop the vehicle in a certain place each time)

- Joseph Eisenberg

On 3/12/20, Jarek Piórkowski  wrote:
> On Wed, 11 Mar 2020 at 08:12, Jo  wrote:
>> That stop_position nodes became optional is probably because of my
>> influence. In the beginning they were definitely part of how PTv2. I
>> disliked this very much because all of a sudden we were using 2 objects to
>> define a single stop, duplicating details, which seemed like a very bad
>> idea. And it was.
>>
>> About the stops, I would have all the details on a single node,
>> highway=bus_stop, railway=tram_stop next to the road where the passengers
>> wait. If there is a physical platform, I would add a way highway=platform,
>> railway=platform. This way would only have tags describing the attributes
>> of the platform like wheelchair and tactile_paving.
>
> Would this be mandatory?
>
> I am thinking of cases like streetside stops for 30 m or 45 m long
> trams. There might be a shelter, which is the most prominent physical
> feature of the tram stop. There is no explicit platform. The tram stop
> sign might be 10 metres away from the shelter, and the farthest
> possible boarding point at the back doors of the tram another 10 m
> away. If only a single node could be used, where is it placed and why?
>
> --Jarek
>
> ___
> 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] Add man_made=goods_conveyor to Map Features or vote on the proposal first?

[Joseph Eisenberg]

> Is it reasonable to support `oneway=no`? I know of one that serves a lime 
> kiln that hauls coal one way and cement the other.

Is the same conveyor reversed from time to time, or are there two
parts, one for the coal and one for the cement?

If it's really the same object which is being used in both directions,
I think oneway=no (or some similar tag) would be a good idea.

The original proposal page suggested that the ways should be mapped in
the direction that the conveyor operates, but I have not checked to
see if mappers have been following that advice or not.

> No objection to rendering this!

I don't have any rendering ideas for this feature in the Openstreetmap
Carto map style, but if someone wants to work on it, see issue 1999:
https://github.com/gravitystorm/openstreetmap-carto/issues/1999

- Joseph Eisenberg


On 3/12/20, Kevin Kenny  wrote:
> On Wed, Mar 11, 2020 at 6:48 PM Joseph Eisenberg
>  wrote:
>>
>> The tag man_made=goods_conveyor was proposed years ago for industrial
>> conveyor belts and systems which move goods like mining ore. It is now
>> documented as "in use" and used over 4000 times:
>>
>> https://wiki.openstreetmap.org/wiki/Tag%3Aman_made%3Dgoods_conveyor
>>
>> "A stationary conveyor system for transporting materials between
>> locations."
>>
>> "How to map: Draw a way way in the direction of the transport and tag
>> it man_made=goods_conveyor. You can add the tag resource=* to indicate
>> the material being transported."
>
> Just a quick question. Is it reasonable to support `oneway=no`? I know
> of one that serves a lime kiln that hauls coal one way and cement the
> other. The discussion on the WIki states, "I think that virtually all
> conveyors are unidirectional, and this calls for an unidirectional map
> symbol," but that's not universal.
>
> No objection to rendering this!
>
> ___
> 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] Add man_made=goods_conveyor to Map Features or vote on the proposal first?

[Marc M.]

Le 11.03.20 à 23:47, Joseph Eisenberg a écrit :
> The tag man_made=goods_conveyor was proposed years ago for industrial
> conveyor belts and systems which move goods like mining ore. It is now
> documented as "in use" and used over 4000 times:
> 
> https://wiki.openstreetmap.org/wiki/Tag%3Aman_made%3Dgoods_conveyor
> 
> "A stationary conveyor system for transporting materials between locations."

you may do both :
- run a RFC/vote because it's the best way to get the maximum amount of
feedback and get the "approved" status
- add to the maps feature right now, if the RFC/vote show a major issue,
it's never too late to revert that.

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

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

[Jarek Piórkowski]

On Wed, 11 Mar 2020 at 08:12, Jo  wrote:
> That stop_position nodes became optional is probably because of my influence. 
> In the beginning they were definitely part of how PTv2. I disliked this very 
> much because all of a sudden we were using 2 objects to define a single stop, 
> duplicating details, which seemed like a very bad idea. And it was.
>
> About the stops, I would have all the details on a single node, 
> highway=bus_stop, railway=tram_stop next to the road where the passengers 
> wait. If there is a physical platform, I would add a way highway=platform, 
> railway=platform. This way would only have tags describing the attributes of 
> the platform like wheelchair and tactile_paving.

Would this be mandatory?

I am thinking of cases like streetside stops for 30 m or 45 m long
trams. There might be a shelter, which is the most prominent physical
feature of the tram stop. There is no explicit platform. The tram stop
sign might be 10 metres away from the shelter, and the farthest
possible boarding point at the back doors of the tram another 10 m
away. If only a single node could be used, where is it placed and why?

--Jarek

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

Re: [Tagging] Add man_made=goods_conveyor to Map Features or vote on the proposal first?

[Kevin Kenny]

On Wed, Mar 11, 2020 at 6:48 PM Joseph Eisenberg
 wrote:
>
> The tag man_made=goods_conveyor was proposed years ago for industrial
> conveyor belts and systems which move goods like mining ore. It is now
> documented as "in use" and used over 4000 times:
>
> https://wiki.openstreetmap.org/wiki/Tag%3Aman_made%3Dgoods_conveyor
>
> "A stationary conveyor system for transporting materials between locations."
>
> "How to map: Draw a way way in the direction of the transport and tag
> it man_made=goods_conveyor. You can add the tag resource=* to indicate
> the material being transported."

Just a quick question. Is it reasonable to support `oneway=no`? I know
of one that serves a lime kiln that hauls coal one way and cement the
other. The discussion on the WIki states, "I think that virtually all
conveyors are unidirectional, and this calls for an unidirectional map
symbol," but that's not universal.

No objection to rendering this!

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

Re: [Tagging] highway=bus_stop is PTv2 compatible

[Andrew Davidson]

On 11/03/2020 10:16 pm, Marc M. wrote:


then some proposals for improvement have no choice but to first propose
a new one without depreciating the old one


A classic example of this is the lanes general extension proposal, which 
deliberately did not modify the definition of lanes=* to cut down on 
people objecting to it being modified. As a result we now get to have 
sporadic debates about why doesn't lanes=* and :lanes=* line up?


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

Re: [Tagging] Add man_made=goods_conveyor to Map Features or vote on the proposal first?

[Martin Koppenhoefer]

sent from a phone

> On 11. Mar 2020, at 23:48, Joseph Eisenberg  
> wrote:
> 
> 
> Is there enough usage to just add it to those pages, or should the
> proposal be voted on first?


I am in favor of adding it right away.

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

[Tagging] Add man_made=goods_conveyor to Map Features or vote on the proposal first?

[Joseph Eisenberg]

The tag man_made=goods_conveyor was proposed years ago for industrial
conveyor belts and systems which move goods like mining ore. It is now
documented as "in use" and used over 4000 times:

https://wiki.openstreetmap.org/wiki/Tag%3Aman_made%3Dgoods_conveyor

"A stationary conveyor system for transporting materials between locations."

"How to map: Draw a way way in the direction of the transport and tag
it man_made=goods_conveyor. You can add the tag resource=* to indicate
the material being transported."

Usage is global:
https://taginfo.openstreetmap.org/tags/?key=man_made=goods_conveyor#map

But it's not on the Key:man_made page or Map Features.

Is there enough usage to just add it to those pages, or should the
proposal be voted on first?

Old proposal page from 2015:
https://wiki.openstreetmap.org/wiki/Proposed_features/Goods_conveyor

- Joseph Eisenberg

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

Re: [Tagging] Feature Proposal - RFC - survey_point:benchmark

[Warin]

On 12/3/20 1:16 am, Greg Troxel wrote:

"ITineris OSM"  writes:


I need help in tagging a special kind of survey points: geodesic towers.

Are they called "geodetic" towers?


These are tubular concrete structures, with usual steel triangulation tripods 
on their top.

Wow, those are pretty big!


They have the precise benchmark on the ground level, the tower is erected so that 
its visible from far, being higher than the trees around.
They form the base of the national reference grid.

I'm not sure if you mean "benchmark" as vertical control, or if you mean
the horizontal control mark and then the tower is basically over it, to
translate it up along the plumb line.


So the control point is man_made=survey_point.  Then there is a tower
which is physcially notable regardless, and the tourist bit.  OSM's
representation does not really admit multiple primary tags on objects,
except that sometimes they dno't conflict.

I'd put in man_made=survey_point as a node for the thing on the ground,
some survey_point:geodetic_tower=yes subtag on that (to inform those who
care about the survey aspect of that), maybe some kind of height tag,
and then draw a way around the tower and tag that as man_mde=tower
and/or tourism.

I don't think we should try to drag towerness and being an attraction
into the survey_point namespace; it seems easy enough to dneote multiple
properties separately.
[>


+ 1 for using a node to signify the survey point, I would wait on a sub tag to 
see what happens with the present discussions.

For the tower I'm map that as an area with whatever tags you think appropriate, 
I'd not put any man_made=survey_point on it though.




  


They could be tagging as man_made=survey_point because their main purpose is being a 
geodesic reference point.

However, they could be a man_made=tower, for being a tower emerging from the surface - and 
to distinguish it from brackets, benchmarks or pavement rivets.

Furthermore, additional functions can be connected to the latter only:

Some of them are tourist attractions, like this 
https://hu.wikipedia.org/wiki/Cs%C3%B3v%C3%A1nyos#/media/F%C3%A1jl:Csovanyos2014_12.jpg. It is a tower:type=observation.

If its rigged with GSM and microwave antennae, its tower:type=communication.


  


(And of course you may add the triangulation_point=yes tagging.)

  


So how would you tag them?

  


Greets,
kos


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

w

___
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 Wed, 11 Mar 2020 at 16:56, Guillaume Rischard 
wrote:

>
> You talk a lot about ‘thinking like a router’.
>

Actually, thinking like EVERY router used by every renderer that chooses to
show bus/rail routes.  And then adding vias to ensure they ALL give the
right
result (tagging for the routers as opposed to tagging for the renderer) and
then
hoping future changes (new roads, changes to sped limits, changes to router
algorithms/weightings, etc) don't cause any of those routers to change their
minds.  Because I want the displayed route to EXACTLY match the canonical
route, not be an approximation (I am prepared, if forced to, to relax that
constraint on long-distance routes but it's not negotiable on urban routes).

Of course you’d have the route shown in your editor. Try this demo
> 
>  to
> get a rough idea. It even has a ‘create relation in josm’ button at the
> bottom left.
>

Maybe it's the lack of instructions, but I couldn't make it do anything
useful.
Trying to get it to load the route into JOSM caused a "bad request" error
because of the size of the data.  There are other buttons that do things
that
seem to have nothing whatsoever to do with the route and I have no idea
what they are displaying.  So all it gives me, that I can make sense of, is
a
set of map pins showing stops and vias.  Colour me unimpressed.

The proposer suggested that editors would, in future, incorporate a router
but that
doesn't guarantee it will use the same algorithms/weightings as the routers
used
by renderers.  So with a future editor I no longer have to think like a
router
because the editor will do that for me.  Except the routers used by
renderers may come up with a different route.  So even if the editor
shows me a route that matches the canonical route, the renderers may
not.

You also accuse John of not having mapped bus routes.
>

He certainly appears to have no experience of mapping urban bus routes
in my part of the world, given that he didn't think bus routes would pass
along
highway=residential.  Bus routes passing through housing estates are very
common in my part of the world.  He also appeared to have given little
or no thought to hail and ride sections of routes, also very common in my
part of the world.

Whatever experience you two have of mapping bus routes elsewhere, you
seem to have little grasp of mapping the sort of bus routes I encounter.
That
wouldn't be too much of a problem for me if PTV3 were an alternative to PTV2
(until I wanted to ride on a route mapped with PTV3 and started to worry
when the bus I was on diverged from the route on the map) but you now want
PTV3 to replace PTV2.

PTV3 may make life easier for you when mapping the type of routes you map.
It would make life harder for me.  I have an idea that might lead to a
solution
that would keep both of us happy (well, not make either of us very unhappy)
but I'm probably wrong about that since I can understand the problems of
mapping long-distance routes with PTV2 but you see no problem using PTV3 for
everything.

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

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

[Guillaume Rischard]

Paul,

You talk a lot about ‘thinking like a router’. Of course you’d have the route 
shown in your editor. Try this demo 

 to get a rough idea. It even has a ‘create relation in josm’ button at the 
bottom left.

You also accuse John of not having mapped bus routes. While the conversation 
should be about the tagging scheme itself, it’s worth noting that he’s mapped 
most of Delhi, and I’ve mapped most of Luxembourg, supported mappers and turned 
the data into maps for bus companies. We have intimate familiarity with 
production and consumption of PTv2, and are not tagging astronauts who comment 
from very far away.

Guillaume

> On 10 Mar 2020, at 15:24, Paul Allen  wrote:
> 
> On Tue, 10 Mar 2020 at 07:55, John Doe  > wrote:
> 
> > 
> > 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.
> > 
> 
> 
> Could you please try to replicate that and report it to the iD developers? 
> Sounds like a pretty serious bug, if it is that.
> 
> To replicate it I'd have to remove the spur, then sort the route (very, very 
> slow
> and tedious) then add the spur back.  And then get nowhere because I appear
> to be on the iD developer ignore list (I know others are on such a list 
> because
> iD developers proudly stated it).  It was only a year or two ago that iD
> developers stated that it was impossible to keep the order of ways in a
> relation when retrieving it from the server, at a time when JOSM had no
> problem doing so.  Now iD protects route relations if you try to break the
> relation and doesn't scramble them as much as it used to.  Maybe in
> another couple of years...
>  
> While many others have, in the process of this proposal, questioned the need 
> to map exact routes at all (given the presence of platforms), I have always 
> wanted to map canonical routes as closely as I can.
> 
> The fact that this scheme relies upon the decisions made by an arbitrary 
> router
> using algorithms that could change and weighting factors that could change, it
> seems impossible to guarantee even a close approximation to canonical routes,
> even with plentiful vias.
> 
> > A new housing estate with two connections to the existing road system could 
> > cause the bus to be re-routed.
> 
> Sounds a little odd - would a router really route a bus on a 
> highway=residential or highway=service?
> 
> As somebody else mentioned, bus routes in towns deliberately pass through
> residential areas along highway=residential.  I think a problem here is that 
> you're
> more familiar with long-distance routes than urban routes.  What makes sense
> for long-distance routes doesn't make much sense for urban routes.
> 
> But, be that as it may, your response helped me see two things -
> 1. It will be helpful to have a route visualizer in editors that can preempt 
> ambiguities.
> 
> Yeah, but the editor will need its own router (not a trivial addition) which 
> will
> almost certainly differ in the algorithm and weightings from the router used 
> by the
> renderer.  It's likely that what the editor shows will not be what the 
> renderer
> shows.
> 
> 2. Hail and ride routes longer than last-mile services really do suffer under 
> this schema.
> 
> Urban routes suffer under this scheme, whether hail and ride or not.  It's 
> just that
> not having the canonical route when there are hail and ride sections is a
> serious problem.  Being on an urban bus that isn't following the route the map
> says it does is not as serious, but still a problem.
> 
> > 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.
> 
> I reiterate that I initially wanted it to be just that - an additional way to 
> map.
> 
> I'll support the scheme if it is an alternative way to map.  I probably won't 
> use it
> as the 

Re: [Tagging] Feature Proposal - RFC - survey_point:benchmark

[Greg Troxel]

"ITineris OSM"  writes:

> I need help in tagging a special kind of survey points: geodesic towers.

Are they called "geodetic" towers?

> These are tubular concrete structures, with usual steel triangulation tripods 
> on their top.

Wow, those are pretty big!

> They have the precise benchmark on the ground level, the tower is erected so 
> that its visible from far, being higher than the trees around.
> They form the base of the national reference grid.

I'm not sure if you mean "benchmark" as vertical control, or if you mean
the horizontal control mark and then the tower is basically over it, to
translate it up along the plumb line.


So the control point is man_made=survey_point.  Then there is a tower
which is physcially notable regardless, and the tourist bit.  OSM's
representation does not really admit multiple primary tags on objects,
except that sometimes they dno't conflict.

I'd put in man_made=survey_point as a node for the thing on the ground,
some survey_point:geodetic_tower=yes subtag on that (to inform those who
care about the survey aspect of that), maybe some kind of height tag,
and then draw a way around the tower and tag that as man_mde=tower
and/or tourism.

I don't think we should try to drag towerness and being an attraction
into the survey_point namespace; it seems easy enough to dneote multiple
properties separately.
[>


>  
>
> They could be tagging as  style="font-family:Courier 
> New,Courier,monospace;">man_made=survey_point because their 
> main purpose is being a geodesic reference point.
>
> However, they could be a  style="font-family:Courier 
> New,Courier,monospace;">man_made=tower, for being a tower 
> emerging from the surface - and to distinguish it from brackets, benchmarks 
> or pavement rivets.
>
> Furthermore, additional functions can be connected to the latter only:
>
> Some of them are tourist attractions, like this 
> https://hu.wikipedia.org/wiki/Cs%C3%B3v%C3%A1nyos#/media/F%C3%A1jl:Csovanyos2014_12.jpg.
>  It is a tower:type=observation.
>
> If its rigged with GSM and microwave antennae, its  style="color:#ff;">tower:type=communication.
>
>
>  
>
> (And of course you may add the  style="font-family: Courier New , Courier , 
> monospace;">triangulation_point=yes tagging.)
>
>  
>
> So how would you tag them?
>
>  
>
> Greets,
> kos
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
w

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

Re: [Tagging] Feature Proposal - RFC - survey_point:benchmark

[Paul Allen]

On Wed, 11 Mar 2020 at 13:31, Kevin Kenny  wrote:
[A whole load of stuff about surveying]

Thanks for your comprehensive contribution to this topic.  Not that I
expected
anything less than a comprehensive contribution when I saw your name.

I was particularly impressed that you knew what a pheon is.  The symbol is
also called (especially by the MoD) the government property mark (see
Defence
Standard 05-34, Marking of Service Matériel)..

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

Re: [Tagging] Feature Proposal - RFC - survey_point:benchmark

[Kevin Kenny]

On Sun, Mar 8, 2020 at 8:42 AM Anne-Karoline Distel  wrote:
> I've been surveying benchmarks for the past four months and I would like
> to propose an alternative to benchmark=yes for survey points:
> https://wiki.openstreetmap.org/wiki/Proposed_features/survey_point:benchmark
> The reason being that I would like to also propose
> survey_point:hexagonal_bolt and survey_point:ground_bolt with it.
>
> Definition: Ordnance survey point usually chiselled in stone with its
> typical horizontal bar and arrow below on vertical surfaces, dot with
> arrow below on horizontal surfaces. Now often replaced by hexagonal
> bolts in walls or bolts in the ground.
>
> Thank you for your time,

A 'control station' is any fixed mark used by surveyors to establish a
frame of reference. They're often placed specifically for the purpose
(often called 'monuments' in that case), but visible and stable marks
such as church steeples and fire towers have been used as stations.

In common speech, it's typical to call all the monuments 'benchmarks',
but to be technically correct, a 'benchmark' is limited to a 'vertical
control', a fixed point at a known elevation. The horizontal position
of a benchmark may or may not be established to survey accuracy.

'Ordnance survey' is UK-specific, as is marking benchmarks with the
Broad Arrow (a heraldic pheon, historically used to label Crown
property). The US, for instance, has no Ordnance Survey. We have the
US Coast and Geodetic Survey, the US Geologic Survey, many state
surveys (New York's is under the Department of Environmental
Conservation in the Adirondacks, the Department of Transportation
elsewhere), and many oddball ones
(https://forums.geocaching.com/GC/index.php?/topic/73161-1934-us-supreme-court-border-survey-mark/
- even the Supreme Court has ordered surveys). In the US, many
benchmarks have been placed by private surveys as well, because large
private operators also need coordinate frames. The best known are
perhaps http://www.wintertime.com/OH/GC/Disney/disneymarks.html

There's a fairly comprehensive discussion about the types of markers
used by the US government at
https://www.ngs.noaa.gov/web/about_ngs/history/Survey_Mark_Art.pdf

Right now the `survey_point=*` key is a mess. In fact, I'd write it
off as a total loss. It conflates several ideas:

Purpose:  Vertical control, horizontal control (or both). There are
also 'reference marks' - additional monuments placed to establish the
location of a primary mark lest the primary be lost or destroyed;
'azimuth marks' - used to establish a sighting direction from the
primary mark immune to geomagnetic variation, and stations that were
used in surveys to map the geomagnetic field, the gravitational
potential, the tidal variation, and so on. In addition, some control
stations had 'witness marks' that were placed only to alert people to
the presence of the station.
https://flickr.com/photos/ke9tv/29681317420 is one form these could
take. The trig point that it warns of is
https://flickr.com/photos/ke9tv/29348215163.

Form: I understand that the commonest form of a UK survey mark is a
stone tablet (or lettering and symbols of the same form chiseled in
native stone. While the US has used stone tablets, disc-shaped bronze
tablets are the commonest form here. Other forms frequently observed
are rods, pipes, bolts, drill holes, and clay cones.  In diggable
soil, a second mark was often installed underground, and was actually
the primary reference. The surface mark would be plumbed above it and
offset by a known vertical distance. Some of these
formerly-underground markers have since been exposed by damage. In
addition to form, material might be interesting: is a tablet of stone,
bronze, concrete, fired clay, ...?  Many tablets and rods were affixed
to drill holes by pouring hot lead, Babbitt metal, sulphur or bitumen
in the hole, and sometimes the hole and fill material are all that
remain (and the centre of the hole is still a usable horizontal
control).  You also seem to consider shape important - disc-shaped,
rectangular, or hexagonal tablets may have particular meaning to you?

Accuracy: Many surveys placed markers to different orders of accuracy.
Standards varied by agency and time.

Operator: Who placed the mark? Who now controls it?

(There are no doubt other attributes.)

Since all four of these can vary independently, it seems unwise to
group them all under 'type'

A more-complete description might be: 'BLACK (OD1740) horizontal
trigonometric control station, marked by a copper nail and washer
stamped "N.Y. / V.C.", position established to first-order accuracy
and thought to be of better than normal stability, placed by the
Adirondack Survey (Verplanck Colvin, state surveyor), now controlled
jointly by the National Oceanographic and Atmospheric Administration
and the New York State Department of Environmental Conservation.' or
'ALANDER (MZ2083) geomagnetic station, marked by a disc-shaped bronze
tablet, placed by US Coast and 

Re: [Tagging] Criticism of PTv2

[Dave F via Tagging]

On 10/03/2020 20:52, Phake Nick wrote:


In the sense of bus, sidewalk could be a platform because they are raised
from the driving road surface. You can google "bus platform" and see many
example of the word being used in real world.


But that's not how it was implemented in the PT documentation.

In fact for nodes it specifically mentions "locations where there is no 
physical infrastructure"


DaveF



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

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

[Joseph Eisenberg]

> if we have to keep  highway=bus_stop anyway, then one could also say that 
> it's not needed to add public_transport=platform to such nodes anymore.

Yes, that's right. It doesn't make sense to add 2 tags or 3 tags when 1 will do.

On 3/11/20, Jo  wrote:
>>
>>
>> But if the originally, more common
>> tag highway=bus_stop is already used, there is no need to add bus=yes.
>>
>>
> OK, but if we have to keep  highway=bus_stop anyway, then one could also
> say that it's not needed to add public_transport=platform to such nodes
> anymore.
>
> And if we do that, then those nodes don't really need roles in the route
> relations either,
>
> The problem with PTv2 is that it was an attempt to streamline how buses
> were mapped based on how railway was mapped, where it would have made more
> sense to go in the other direction and map railway the way buses are
> mapped.
>
> Jo
>

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

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

[Jo]

>
>
> But if the originally, more common
> tag highway=bus_stop is already used, there is no need to add bus=yes.
>
>
OK, but if we have to keep  highway=bus_stop anyway, then one could also
say that it's not needed to add public_transport=platform to such nodes
anymore.

And if we do that, then those nodes don't really need roles in the route
relations either,

The problem with PTv2 is that it was an attempt to streamline how buses
were mapped based on how railway was mapped, where it would have made more
sense to go in the other direction and map railway the way buses are mapped.

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

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

[Jo]

That stop_position nodes became optional is probably because of my
influence. In the beginning they were definitely part of how PTv2. I
disliked this very much because all of a sudden we were using 2 objects to
define a single stop, duplicating details, which seemed like a very bad
idea. And it was.

About the stops, I would have all the details on a single node,
highway=bus_stop, railway=tram_stop next to the road where the passengers
wait. If there is a physical platform, I would add a way highway=platform,
railway=platform. This way would only have tags describing the attributes
of the platform like wheelchair and tactile_paving.

Only the  highway=bus_stop, railway=tram, which has the details like name,
ref, etc would be a member in the route relations.

I think it's good that we are discussing how to map PT in a reasonable way.
My take on all this, is that I would prefer to 'simplify' it by adding
another layer of subrelations in between.

This would definitely make it easier to reroute several bus itineraries in
one go. Or fix several by making a single intervention.

It would not be clear anymore which buses use which ways directly, but that
would be the effect of the current proposal as well.

Anyway, the reason why I am not making an official proposal for years now,
even though I'm telling myself I should is that

1. it would be very hard to get it to pass
2. even if it passes, it may not be adopted in some places

Polyglot

PS: I saw PT_Assistant mentioned a few times. I'm glad it's being used. If
it doesn't work like you expect, let me know, maybe we can improve it.
Also, not all validator warnings are of the same importance. If your bus
travels against a oneway restriction, or the route is interrupted, it would
be good to fix that. If it complains about first or last way not matching
with first or last stop, it may be that the stops aren't ordered correctly.
If it complains about the first or last way isn't split near the stop,
that's not crucially important, I'd say.



On Wed, Mar 11, 2020 at 12:46 PM Peter Elderson  wrote:

> I get the impression that consensus and general adoption will not be
> reached during my lifetime.
>
> Good luck with it, I'm out!
>
> Vr gr Peter Elderson
>
>
> Op wo 11 mrt. 2020 om 12:13 schreef alan_gr :
>
>> John Doe wrote
>> > I don't understand why the critics of PTv2 seem to think stop positions
>> > are such a big deal - they are optional!
>>
>> My memory of starting to map bus stops a few years ago is that it wasn't
>> clear from the documentation that stop positions are optional. I certainly
>> formed the impressions that they were required, and came to regret
>> spending
>> so much time mapping both stop positions and platforms. At that time I
>> think
>> the main reference for how to map using PTv2 was the proposal page itself,
>> now archived at https://wiki.openstreetmap.org/w/index.php?oldid=625726.
>> That doesn't indicate that stop_position is optional (see "the Schema in
>> short", where stop_area is explicitly described as optional, but
>> stop_position is not).
>>
>> It seems other wiki pages have since been edited to make this optionality
>> clearer. I notice that they also refer to adding bus=yes etc to platforms
>> representing bus stops, which was not part of the PTv2 proposal, but I
>> guess
>> tries to deal with one of the issues that led people to prefer
>> highway=bus_stop.
>>
>> Bringing this closer to the original topic ... if the proposal for PTv3 is
>> "PTv2 with some exceptions", is there a single coherent reference for what
>> is meant by "PTv2"?
>>
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>>
>> ___
>> 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] Feature Proposal - RFC - Public Transport v3

[Joseph Eisenberg]

> I notice that they also refer to adding bus=yes etc to platforms
representing bus stops, which was not part of the PTv2 proposal, but I guess
tries to deal with one of the issues that led people to prefer
highway=bus_stop.

Yes, that is a rather silly thing that has been added, since it was
noticed after the proposal that if you removed highway=bus_stop and
only had public_transport=platform, then you would have no way to know
it was a bus stop rather than a train platform.

So now some mappers advocate adding a second tag bus=yes, originally
only proposed for stop positions. But if the originally, more common
tag highway=bus_stop is already used, there is no need to add bus=yes.

- Joseph Eisenberg

On 3/11/20, Peter Elderson  wrote:
> I get the impression that consensus and general adoption will not be
> reached during my lifetime.
>
> Good luck with it, I'm out!
>
> Vr gr Peter Elderson
>
>
> Op wo 11 mrt. 2020 om 12:13 schreef alan_gr :
>
>> John Doe wrote
>> > I don't understand why the critics of PTv2 seem to think stop positions
>> > are such a big deal - they are optional!
>>
>> My memory of starting to map bus stops a few years ago is that it wasn't
>> clear from the documentation that stop positions are optional. I
>> certainly
>> formed the impressions that they were required, and came to regret
>> spending
>> so much time mapping both stop positions and platforms. At that time I
>> think
>> the main reference for how to map using PTv2 was the proposal page
>> itself,
>> now archived at https://wiki.openstreetmap.org/w/index.php?oldid=625726.
>> That doesn't indicate that stop_position is optional (see "the Schema in
>> short", where stop_area is explicitly described as optional, but
>> stop_position is not).
>>
>> It seems other wiki pages have since been edited to make this optionality
>> clearer. I notice that they also refer to adding bus=yes etc to platforms
>> representing bus stops, which was not part of the PTv2 proposal, but I
>> guess
>> tries to deal with one of the issues that led people to prefer
>> highway=bus_stop.
>>
>> Bringing this closer to the original topic ... if the proposal for PTv3
>> is
>> "PTv2 with some exceptions", is there a single coherent reference for
>> what
>> is meant by "PTv2"?
>>
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>>
>> ___
>> 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

[Peter Elderson]

I get the impression that consensus and general adoption will not be
reached during my lifetime.

Good luck with it, I'm out!

Vr gr Peter Elderson


Op wo 11 mrt. 2020 om 12:13 schreef alan_gr :

> John Doe wrote
> > I don't understand why the critics of PTv2 seem to think stop positions
> > are such a big deal - they are optional!
>
> My memory of starting to map bus stops a few years ago is that it wasn't
> clear from the documentation that stop positions are optional. I certainly
> formed the impressions that they were required, and came to regret spending
> so much time mapping both stop positions and platforms. At that time I
> think
> the main reference for how to map using PTv2 was the proposal page itself,
> now archived at https://wiki.openstreetmap.org/w/index.php?oldid=625726.
> That doesn't indicate that stop_position is optional (see "the Schema in
> short", where stop_area is explicitly described as optional, but
> stop_position is not).
>
> It seems other wiki pages have since been edited to make this optionality
> clearer. I notice that they also refer to adding bus=yes etc to platforms
> representing bus stops, which was not part of the PTv2 proposal, but I
> guess
> tries to deal with one of the issues that led people to prefer
> highway=bus_stop.
>
> Bringing this closer to the original topic ... if the proposal for PTv3 is
> "PTv2 with some exceptions", is there a single coherent reference for what
> is meant by "PTv2"?
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>
> ___
> 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] highway=bus_stop is PTv2 compatible (was: Re: Feature Proposal - RFC - Public Transport v3)

[Marc M.]

Le 11.03.20 à 10:53, Mateusz Konieczny via Tagging a écrit :
> I am not entirely sure why it was done this way

because the too many opposing "if a tag has more than X occurrences,
it must be kept for eternity".
then some proposals for improvement have no choice but to first propose
a new one without depreciating the old one and then hope one day to
reopen the debate if the new tag surpasses the old one, which doesn't
happen if only the old one is render, it's the cat that bites its own tail.

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

Re: [Tagging] Proposal drinking_water:refill:fee

[European Water Project]

Hi Martin,

I agree with you on one point.

The default for "amenity =drinking_water"  and "drinking_water=yes" should
definitely be free water. I also believe the same should hold  be for
"drinking_water:refill = yes".

I am not a big fan of meta data and poorly maintained data. Unless there is
a use for the price data for someone, eventually it will get stale-
especially with the economic difficulty so many cafes and restaurants are
facing.

Quality and accuracy of data was one of the main reasons our project has
swiftly migrated from Wikidata to OSM.

Best regards,

Stuart


On Wed, Mar 11, 2020, 10:22 Martin Koppenhoefer 
wrote:

>
>
> Am Mi., 11. März 2020 um 04:25 Uhr schrieb European Water Project <
> europeanwaterproj...@gmail.com>:
>
>> Hi Martin,
>>
>> drinking_water:refill:fee=no/yes/0..9
>>
>> >>  I don't think the third tag value "0,9" is easily mappible as one
>> needs to have access to the menu to get the price data. a mapper should
>> be able to map without speaking the local language.
>>
>> Also, the price data might quickly become inaccurate.
>>
>> Free vs. Fee should be inherent to the network...
>>
>
>
> The amount if fee may indeed by volatile, but it is often mapped, for
> example for parkings, and I do not see how an old information about the
> amount would be worse than a binary yes/no information (if you know the
> price was 50ct 3 years ago you might deduce it is still somewhere near
> that, or if you see it was 1 ¥€$ 10 years ago, it is like seeing it was
> "yes" 10 years ago. It's generally interesting not only to get the stored
> information, but also meta information (e.g. how old is the information).
>
> Cheers
> Martin
>
> PS: for me the most important part is that amenity=drinking_water means
> without fee by default and it's definitions do not have to be reconsidered
> in the light of the new drinking_water:refill-scheme and tags.
>
> ___
> 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

[alan_gr]

John Doe wrote
> I don't understand why the critics of PTv2 seem to think stop positions
> are such a big deal - they are optional!

My memory of starting to map bus stops a few years ago is that it wasn't
clear from the documentation that stop positions are optional. I certainly
formed the impressions that they were required, and came to regret spending
so much time mapping both stop positions and platforms. At that time I think
the main reference for how to map using PTv2 was the proposal page itself,
now archived at https://wiki.openstreetmap.org/w/index.php?oldid=625726.
That doesn't indicate that stop_position is optional (see "the Schema in
short", where stop_area is explicitly described as optional, but
stop_position is not).

It seems other wiki pages have since been edited to make this optionality
clearer. I notice that they also refer to adding bus=yes etc to platforms
representing bus stops, which was not part of the PTv2 proposal, but I guess
tries to deal with one of the issues that led people to prefer
highway=bus_stop.

Bringing this closer to the original topic ... if the proposal for PTv3 is
"PTv2 with some exceptions", is there a single coherent reference for what
is meant by "PTv2"? 




--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] Feature Proposal - RFC - survey_point:benchmark

[ITineris OSM]

Hi,

 

I need help in tagging a special kind of survey points: geodesic towers.

A new tag may help some.

 

These are tubular concrete structures, with usual steel triangulation tripods on their top.


They have the precise benchmark on the ground level, the tower is erected so that it's visible from far, being higher than the trees around.
They form the base of the national reference grid.
 

http://ballon.hu/wp-content/uploads/2017/12/2017-12-23-12.39.37.jpg

http://karpat-medence.hu/keptar/galleries/Magyarorszag/Fejer/Perkata/Geotorony/perkata-geotorony_02.jpg

 

They could be tagging as man_made=survey_point because their main purpose is being a geodesic reference point.

However, they could be a man_made=tower, for being a tower emerging from the surface - and to distinguish it from brackets, benchmarks or pavement rivets.

Furthermore, additional functions can be connected to the latter only:

Some of them are tourist attractions, like this viewpoint. It is a tower:type=observation.

If it's rigged with GSM and microwave antennae, it's tower:type=communication.


 

(And of course you may add the triangulation_point=yes tagging.)

 

So how would you tag them?

 

Greets,
Ákos


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

[Tagging] highway=bus_stop is PTv2 compatible (was: Re: Feature Proposal - RFC - Public Transport v3)

[Mateusz Konieczny via Tagging]

Mar 8, 2020, 02:41 by music.kash...@gmail.com:

> 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 that highway=bus_stop usage and support, while completely ignoring new
tags introduced by PTv2 is fully compatible with PTv2.

Yes, supporting just highway=bus_stop, railway=tram_stop, amenity=bus_station
and completely ignoring public_transport=platform, public_transport=station and
so on is one of possible ways for implementing approved PTv2 proposal.

Yes, PTv2 is not a well written proposal.

No, I am not entirely sure why it was done this way (I have some theories 
but...)


> 2. People with a preference for the old tags see that as an excuse to keep 
> using them
>
Simple tags are fully PTv2 compatible.

> 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
>
Supporting simple tags (and only simple tags) are fully compatible with 
approved PTv2 proposal.
Simple tags are also more popular and simpler to use.

> 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.
>
Note that it is extremely rare in OSM to actually transition tags. 
waterway=wadi still have more than 5000 uses.
Even highway=unsurfaced still have some uses.

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

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

[Mateusz Konieczny via Tagging]

Mar 9, 2020, 12:28 by music.kash...@gmail.com:

> I don't understand why the critics of PTv2 seem to think stop positions are 
> such a big deal - they are optional!
>
I dislike them, because many people are using them.
Also in places where using them adds no information whatsoever.

I also very deeply dislike reason for its introduction
"Missing tag for stop position causes extra preprocessing for routing 
software."[1]

Why it was considered as a good idea to burden mappers with
something that good be done with extra preprocessing in routing software?

[1] 
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport=625726#Main_Problem_with_the_existing_Schema
 




Overall, except extremely rare cases stop positions only make map harder to edit
and people keep wasting time to add them. This is one of many ways how PTv2
leads to pointless waste of time, without benefits that would justify this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal drinking_water:refill:fee

[Martin Koppenhoefer]

Am Mi., 11. März 2020 um 04:25 Uhr schrieb European Water Project <
europeanwaterproj...@gmail.com>:

> Hi Martin,
>
> drinking_water:refill:fee=no/yes/0..9
>
> >>  I don't think the third tag value "0,9" is easily mappible as one
> needs to have access to the menu to get the price data. a mapper should
> be able to map without speaking the local language.
>
> Also, the price data might quickly become inaccurate.
>
> Free vs. Fee should be inherent to the network...
>


The amount if fee may indeed by volatile, but it is often mapped, for
example for parkings, and I do not see how an old information about the
amount would be worse than a binary yes/no information (if you know the
price was 50ct 3 years ago you might deduce it is still somewhere near
that, or if you see it was 1 ¥€$ 10 years ago, it is like seeing it was
"yes" 10 years ago. It's generally interesting not only to get the stored
information, but also meta information (e.g. how old is the information).

Cheers
Martin

PS: for me the most important part is that amenity=drinking_water means
without fee by default and it's definitions do not have to be reconsidered
in the light of the new drinking_water:refill-scheme and tags.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging