date:20180329

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

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

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


On Fri, Mar 30, 2018 at 8:45 AM, Selfish Seahorse  wrote:

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

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

Heh, never noticed that.

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

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

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

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

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

Maybe public_transport=stop?


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

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

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

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

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

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

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

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

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

> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dplatform
>
> does have a legacy banner, but contrary
>
> https://wiki.openstreetmap.org/wiki/DE:Tag:public_transport%3Dplatform
>
> writes that legacy tags should co-exist (like in forever)
> even if PTv2 tags are present.
>
> If few people read the wiki, then those that do find inconsistent
> tagging guides.  Shaping the wiki to be consistent in what is says
> on all ends is a ressource problem, but this does not invalidate
> the progress made with PTv2 in general.
>
>
> Greetings
> cmuelle8
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Attendant on amenity=fuel

2018-03-29 Thread Dave Swarthout

In the U.S. almost all service stations are unattended these days. The
pumps are automated and accept only credit cards. Persons needing to pay
cash have to go to a separate office or shop to pay. Oregon used to be the
only state I visit regularly in which customers were not allowed to fuel
their vehicles. Attendants did everything; filled the tank, cleaned the
windshield, checked the oil. IIRC, that law just recently changed.

Dave

On Fri, Mar 30, 2018 at 7:44 AM, Stephan Knauss 
wrote:

> It is the norm that you have an attendant coming and filling up the tank
> for you.
>
> Some places will always clean the windscreen while waiting for the refill,
> but don't this is something to tag special as you can always ask the
> attendant to clean them.
>
> In some countries it differs, so I suggest to tag things not following the
> norm of the country.
>
> Stephan
>
>
> On March 29, 2018 5:58:51 PM GMT+07:00, "Javier Sánchez Portero" <
> javiers...@gmail.com> wrote:
>>
>> Sorry, english is not my first languange and I'm not sure of have been
>> used the correct word in the subject. I'm looking for a key to denote if
>> you have to refuel by your self or not. I meant if the station operates on
>> self service mode.
>>
>> Didn't found nothing in the wiki or taginfo.
>>
>> I'm confused also about the use of Key:tenant. The description in the
>> wiki is to short for a non native English speaker. Could any one give me
>> further details?
>>
>> Thank you, Javier.
>>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Attendant on amenity=fuel

2018-03-29 Thread Stephan Knauss

It is the norm that you have an attendant coming and filling up the tank for 
you.

Some places will always clean the windscreen while waiting for the refill, but 
don't this is something to tag special as you can always ask the attendant to 
clean them.

In some countries it differs, so I suggest to tag things not following the norm 
of the country.

Stephan

On March 29, 2018 5:58:51 PM GMT+07:00, "Javier Sánchez Portero" 
 wrote:
>Sorry, english is not my first languange and I'm not sure of have been
>used
>the correct word in the subject. I'm looking for a key to denote if you
>have to refuel by your self or not. I meant if the station operates on
>self
>service mode.
>
>Didn't found nothing in the wiki or taginfo.
>
>I'm confused also about the use of Key:tenant. The description in the
>wiki
>is to short for a non native English speaker. Could any one give me
>further
>details?
>
>Thank you, Javier.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Attendant on amenity=fuel

2018-03-29 Thread Graeme Fitzpatrick

On 30 March 2018 at 05:34, Javier Sánchez Portero 
wrote:

> In my area  there are still some serviced stations and I consider this an
> added value.
>

Definitely!

Question re another variation thanks.

We have a service station nearby that has an attendant during the day, but,
he only looks after the pumps at that end, the pumps a this end are
self-serve.

How would you handle that?

Thanks

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

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

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

does have a legacy banner, but contrary

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

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

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


Greetings
cmuelle8

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

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

> Sent: Thu, 29 Mar 2018 19:55:34 +0200 
> From: "Selfish Seahorse" 
> To: "Tag discussion, strategy and related tools" 
> Subject: Re: [Tagging] Still RFC — Drop stop positions and platforms
>
> Or, very often, because there's a sidewalk and, therefore, no need for
> a platform.

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

This is also a nice way to see, why and where PT tags perform better than
the legacy tagging - a combination like highway=footway highway=platform
won't do.

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

Yes, it corresponds. I remember seeing kv-pages with the node icon
crossed out.  Currently this (still?) applies e.g. to
https://wiki.openstreetmap.org/wiki/DE:Tag:railway%3Dplatform
It may have affected other platform related pages in the past.

So this is yet another example of a problem raised earlier: Legacy
information lingering in the wiki with sparse reference to the suc-
cessor for readers to compare.  As long as a 'deprecated' label is
missing, it seems natural to some extent that there is concurrent
competition between the older and the newer approach to map PT.


Greetings
cmuelle8

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

Re: [Tagging] Attendant on amenity=fuel

In my area  there are still some serviced stations and I consider this an
added value.

El 29 mar. 2018 18:39, "Philip Barnes"  escribió:

Although very few mappers will tag self service as it is usually the norm
in most places.

Phil (trigpoint)

On 29 March 2018 15:22:17 BST, "Javier Sánchez Portero" <
javiers...@gmail.com> wrote:
>
> Opsss! There was a mention to it in the Tag:amenity=fuel wiki. I didn't
> see it. Thank you.
>
> 2018-03-29 13:14 GMT+01:00 Michal Fabík :
>
>> On Thu, Mar 29, 2018 at 12:58 PM, Javier Sánchez Portero
>>  wrote:
>> > Sorry, english is not my first languange and I'm not sure of have been
>> used
>> > the correct word in the subject. I'm looking for a key to denote if you
>> have
>> > to refuel by your self or not. I meant if the station operates on self
>> > service mode.
>> >
>> > Didn't found nothing in the wiki or taginfo.
>> >
>> > I'm confused also about the use of Key:tenant. The description in the
>> wiki
>> > is to short for a non native English speaker. Could any one give me
>> further
>> > details?
>> >
>> > Thank you, Javier.
>>
>> Hi,
>> I can't really tell what the tenant tag is intended for either. In any
>> case, there's the tag self_service:
>> https://wiki.openstreetmap.org/wiki/Key:self_service. (And yes,
>> attendant is the right word.)
>>
>> --
>> Michal Fabík
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

2018-03-29 Thread Daniel Koć

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

Re: [Tagging] Attendant on amenity=fuel

2018-03-29 15:22 GMT+01:00 Javier Sánchez Portero :

> 2018-03-29 13:14 GMT+01:00 Michal Fabík :
>
>> On Thu, Mar 29, 2018 at 12:58 PM, Javier Sánchez Portero
>>  wrote:
>> > Sorry, english is not my first languange and I'm not sure of have been
>> used
>> > the correct word in the subject. I'm looking for a key to denote if you
>> have
>> > to refuel by your self or not. I meant if the station operates on self
>> > service mode.
>> >
>> > Didn't found nothing in the wiki or taginfo.
>> >
>> > I'm confused also about the use of Key:tenant. The description in the
>> wiki
>> > is to short for a non native English speaker. Could any one give me
>> further
>> > details?
>> >
>> > Thank you, Javier.
>>
>> Hi,
>> I can't really tell what the tenant tag is intended for either. In any
>> case, there's the tag self_service:
>> https://wiki.openstreetmap.org/wiki/Key:self_service. (And yes,
>> attendant is the right word.)
>>
>> --
>> Michal Fabík
>>
>
> Opsss! There was a mention to it in the Tag:amenity=fuel wiki. I didn't
> see it. Thank you.
>
>
BTW. How would you tag if the station usually have attendants but operates
in self service mode in nightly hours. I think in the conditional postfix,
like this:

self_service:conditional = yes @ (22:00-06:00)

With no uses in taginfo. An alternative is opening_hours:self_service=*
with only two uses.

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

Re: [Tagging] Attendant on amenity=fuel

2018-03-29 Thread Philip Barnes

Although very few mappers will tag self service as it is usually the norm in 
most places.

Phil (trigpoint) 

On 29 March 2018 15:22:17 BST, "Javier Sánchez Portero"  
wrote:
>Opsss! There was a mention to it in the Tag:amenity=fuel wiki. I didn't
>see
>it. Thank you.
>
>2018-03-29 13:14 GMT+01:00 Michal Fabík :
>
>> On Thu, Mar 29, 2018 at 12:58 PM, Javier Sánchez Portero
>>  wrote:
>> > Sorry, english is not my first languange and I'm not sure of have
>been
>> used
>> > the correct word in the subject. I'm looking for a key to denote if
>you
>> have
>> > to refuel by your self or not. I meant if the station operates on
>self
>> > service mode.
>> >
>> > Didn't found nothing in the wiki or taginfo.
>> >
>> > I'm confused also about the use of Key:tenant. The description in
>the
>> wiki
>> > is to short for a non native English speaker. Could any one give me
>> further
>> > details?
>> >
>> > Thank you, Javier.
>>
>> Hi,
>> I can't really tell what the tenant tag is intended for either. In
>any
>> case, there's the tag self_service:
>> https://wiki.openstreetmap.org/wiki/Key:self_service. (And yes,
>> attendant is the right word.)
>>
>> --
>> Michal Fabík
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Historic building usage




On 29/03/2018 15:38, Tom Pfeifer wrote:

On 29.03.2018 15:38, Dave F wrote:
The building=train_station tag remains, since it describes the 
building type, independent of the current usage.


No. The building tag is for current usage. OSM maps the present with 
its primary tags. If contributors want to indicate it had previous 
use, as I do in this case, it should be tagged with clearly defined 
sub tags.


We understand that you have strong personal opinions, and remember the 
debate about exit nodes in roundabouts.

For which I still believe I'm correct.



However the consensus with many other mappers in OSM is, as descried 
in the wiki:


"the [building=*] value may be used to classify the _type_ of 
building. Note that it may be not the same as the building's current 
use (tagged using building:use=*). For example, a hospital building 
that is abandoned or repurposed to be a marketplace is still a 
building=hospital, and to mark active hospitals amenity=hospital is 
used. "


Which was added less than one month ago. Was there a recent discussion?



It also perfectly reflects common language. Imagine the following BrE 
example:
"Do you see the church building over there? It is now used as a 
climbing hall!"


I disagree. "Say what you see" is more common. if you point to a 
warehouse that's converted to apartments & ask "What's that there?" 
you're either get "Those are apartments"  or "That's the old warehouse". 
A building's historical purpose should be put in a specific tag.




The building:use tag is inaccurately used. (I believe it shouldn't be 
used at all).


Again this is your personal opinion. building:use is well defined in 
the wiki, and used 63 times.


IMO this is poor tagging. If a building is now used as a place for 
people to live then it clearly isn't a warehouse any more.


No, but it has the building type of a warehouse. Ans some people like 
it, and say:

"Hey, I have an new loft in the old warehouse."


Yes! Note your use of 'old'. 'Building' tag does not indicate a previous 
purpose.


If a shop tagged a building=retail, shop=* is change to a residential 
house would you keep the building=retail tag?



DaveF
.

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

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

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

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

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

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

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

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

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


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


Greetings
cmuelle8

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

Re: [Tagging] Historic building usage




On 29/03/2018 10:04, Martin Koppenhoefer wrote:



sent from a phone

On 29. Mar 2018, at 10:05, Johnparis > wrote:



Interesting. Musée d'Orsay in Paris offers another possibility:
building=disused:train_station



usually the disused prefix is used on the key, but it wouldn’t make 
sense in this case as the building is used. If disused:train_station 
is a building typology, this tag is fine.



https://www.openstreetmap.org/way/175464203 

(the second one has disused:railway=station but still a generic yes 
for building)


There's no reference to the building original use. Please note there's a 
difference between railway=station & building=train_station.

The graphic on this page clarifies:
https://wiki.openstreetmap.org/wiki/Railway_stations





Cheers,
Martin


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


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

Re: [Tagging] Historic building usage

2018-03-29 Thread marc marc

Le 29. 03. 18 à 15:38, Dave F a écrit :
> On 28/03/2018 23:02, Tom Pfeifer wrote:
>> On 28.03.2018 23:20, Dave F wrote:
>>> I've a building to tag which used to be a train_station 
>>> but currently has a different use.
>>
>> The building=train_station tag remains, since it describes the 
>> building type, independent of the current usage.
> 
> No. The building tag is for current usage. 

that is not the common meaning. see the 2 first lines of
https://wiki.openstreetmap.org/wiki/Key:building
The common meaning is like Tom said.
building for what the building look like
building:use and/or another key for the current use
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Historic building usage

2018-03-29 Thread Tom Pfeifer

On 29.03.2018 15:38, Dave F wrote:
The building=train_station tag remains, since it describes the building type, independent of the
current usage.

No. The building tag is for current usage. OSM maps the present with its primary tags. If
contributors want to indicate it had previous use, as I do in this case, it should be tagged with
clearly defined sub tags.

We understand that you have strong personal opinions, and remember the debate about exit nodes in
roundabouts.

However the consensus with many other mappers in OSM is, as descried in the
wiki:

"the [building=*] value may be used to classify the _type_ of building. Note that it may be not the
same as the building's current use (tagged using building:use=*). For example, a hospital building
that is abandoned or repurposed to be a marketplace is still a building=hospital, and to mark active
hospitals amenity=hospital is used. "

It also perfectly reflects common language. Imagine the following BrE example:
"Do you see the church building over there? It is now used as a climbing hall!"

The building:use tag is inaccurately used. (I believe it shouldn't be used at
all).

Again this is your personal opinion. building:use is well defined in the wiki,
and used 63 times.

IMO this is poor tagging. If a building is now used as a place for people to live then it clearly
isn't a warehouse any more.

No, but it has the building type of a warehouse. Ans some people like it, and
say:
"Hey, I have an new loft in the old warehouse."

A separate tag is required.

We have two separate tags, building=* and building:use=, they are well defined and serve their
intention. If your intention is different, I understand that, but that will not change our minds.

On 29.03.2018 16:26, Dave F wrote:
> On 29/03/2018 09:05, Johnparis wrote:
>> Interesting. Musée d'Orsay in Paris offers another possibility:
building=disused:train_station
>
> But that doesn't account for what it currently is.

Correct, that's what people use building:use for.

tom

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

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


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

 

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

 

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

 

-

 

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

 

a) find a new tag for wild platforms

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

 

may be an solution.

 

 

Greetings

cmuelle8

 

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


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

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

 

Polyglot


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

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







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

Re: [Tagging] Historic building usage


On 29/03/2018 09:05, Johnparis wrote:

Interesting. Musée d'Orsay in Paris offers another possibility:
building=disused:train_station


But that doesn't account for what it currently is.

DaveF

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

Re: [Tagging] Attendant on amenity=fuel

Opsss! There was a mention to it in the Tag:amenity=fuel wiki. I didn't see
it. Thank you.

2018-03-29 13:14 GMT+01:00 Michal Fabík :

> On Thu, Mar 29, 2018 at 12:58 PM, Javier Sánchez Portero
>  wrote:
> > Sorry, english is not my first languange and I'm not sure of have been
> used
> > the correct word in the subject. I'm looking for a key to denote if you
> have
> > to refuel by your self or not. I meant if the station operates on self
> > service mode.
> >
> > Didn't found nothing in the wiki or taginfo.
> >
> > I'm confused also about the use of Key:tenant. The description in the
> wiki
> > is to short for a non native English speaker. Could any one give me
> further
> > details?
> >
> > Thank you, Javier.
>
> Hi,
> I can't really tell what the tenant tag is intended for either. In any
> case, there's the tag self_service:
> https://wiki.openstreetmap.org/wiki/Key:self_service. (And yes,
> attendant is the right word.)
>
> --
> Michal Fabík
>
> ___
> 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] Historic building usage




On 28/03/2018 23:02, Tom Pfeifer wrote:

On 28.03.2018 23:20, Dave F wrote:

Hi

I've a building to tag which used to be a train_station but currently 
has a different use.


The building=train_station tag remains, since it describes the 
building type, independent of the current usage.


No. The building tag is for current usage. OSM maps the present with its 
primary tags. If contributors want to indicate it had previous use, as I 
do in this case, it should be tagged with clearly defined sub tags.




If it is protected, heritage=* would be used, which allows to give 
details about the protection status.


Heritage gives no indication of the original use of the building. In the 
UK a numerical system is used.




This page recommends historic=building, but I don't see how that's 
beneficial. It can't be tagged to describe it's historic use. 
Building=* should be used to describe what it is now.


No, building=* remains as the original type. You can add 
building:use=* for the current use.


The building:use tag is inaccurately used. (I believe it shouldn't be 
used at all).


From the wiki:

                For example, if a warehouse building serves as a 
residence, then you could tag it:

                    building=warehouse
                    building:use=residential


IMO this is poor tagging. If a building is now used as a place for 
people to live then it clearly isn't a warehouse any more.






Wouldn't historic:building=* be better?


not necessary as the above covers the case.


A separate tag is required.

DaveF


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

Re: [Tagging] Attendant on amenity=fuel

2018-03-29 Thread Michal Fabík

On Thu, Mar 29, 2018 at 12:58 PM, Javier Sánchez Portero
 wrote:
> Sorry, english is not my first languange and I'm not sure of have been used
> the correct word in the subject. I'm looking for a key to denote if you have
> to refuel by your self or not. I meant if the station operates on self
> service mode.
>
> Didn't found nothing in the wiki or taginfo.
>
> I'm confused also about the use of Key:tenant. The description in the wiki
> is to short for a non native English speaker. Could any one give me further
> details?
>
> Thank you, Javier.

Hi,
I can't really tell what the tenant tag is intended for either. In any
case, there's the tag self_service:
https://wiki.openstreetmap.org/wiki/Key:self_service. (And yes,
attendant is the right word.)

-- 
Michal Fabík

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

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

2018-03-29 Thread Jo

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

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

Polyglot

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

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

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

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

Or at least exclude them from route relations.


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

[Tagging] Attendant on amenity=fuel

Sorry, english is not my first languange and I'm not sure of have been used
the correct word in the subject. I'm looking for a key to denote if you
have to refuel by your self or not. I meant if the station operates on self
service mode.

Didn't found nothing in the wiki or taginfo.

I'm confused also about the use of Key:tenant. The description in the wiki
is to short for a non native English speaker. Could any one give me further
details?

Thank you, Javier.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

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

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

[^1]: 


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

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

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

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

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


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

Re: [Tagging] Historic building usage

2018-03-29 Thread Martin Koppenhoefer



sent from a phone

> On 29. Mar 2018, at 10:05, Johnparis  wrote:
> 
> Interesting. Musée d'Orsay in Paris offers another possibility:
> building=disused:train_station


usually the disused prefix is used on the key, but it wouldn’t make sense in 
this case as the building is used. If disused:train_station is a building 
typology, this tag is fine.

See for example these:
https://www.openstreetmap.org/way/237687069#map=16/52.5298/13.3700
https://www.openstreetmap.org/way/175464203
(the second one has disused:railway=station but still a generic yes for 
building)


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

Re: [Tagging] Historic building usage

Interesting. Musée d'Orsay in Paris offers another possibility:
building=disused:train_station

https://www.openstreetmap.org/relation/2853923

... as well as tourism=museum (reflecting the current use)

On Thu, Mar 29, 2018 at 12:02 AM, Tom Pfeifer 
wrote:

> On 28.03.2018 23:20, Dave F wrote:
>
>> Hi
>>
>> I've a building to tag which used to be a train_station but currently has
>> a different use.
>>
>
> The building=train_station tag remains, since it describes the building
> type, independent of the current usage.
>
> https://wiki.openstreetmap.org/wiki/Key:historic
>>
>
> If you consider it of historic value you can add the tag, however it is a
> bit vague.
> If it is protected, heritage=* would be used, which allows to give details
> about the protection status.
>
> This page recommends historic=building, but I don't see how that's
>> beneficial. It can't be tagged to describe it's historic use. Building=*
>> should be used to describe what it is now.
>>
>
> No, building=* remains as the original type. You can add building:use=*
> for the current use.
>
> Wouldn't historic:building=* be better?
>>
>
> not necessary as the above covers the case.
>
> Refs:
>
> https://wiki.openstreetmap.org/wiki/Key:building:use
> https://wiki.openstreetmap.org/wiki/Key:heritage
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

2018-03-29 Thread Jo

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

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

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

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

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

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

Polyglot

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2018-03-29 Thread Topographe Fou

Hi,

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

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

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

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

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

Yours,

LeTopographeFou

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

Hi folks,

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

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

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

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

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