Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Warin]

On 31/07/19 16:45, Joseph Eisenberg wrote:

Based on current practice, it seems that most people are ok with
adding new values to certain keys that already have a long list of
documented values in map features, as long as the tag is frequently
used and well-documented?

The relevant keys appear to be:

craft=
building=
office=
shop=
sport=

Are there any others that don't need a proposal to add a new value to
Map Features?


There is no requirement for a proposal for values or keys of any kind.
A proposal is at best a 'recommendation', not a 'requirement'.

"Any tag you like" is one of the OSM mantras.
https://wiki.openstreetmap.org/wiki/Any_tags_you_like

It is 'desirable' to consult others before creating new values or keys as this 
can lead to a better tag. But there is no requirement.





I'd like to mention this at the end of the Proposal Process page, as
the final lines of "Non-proposed features" like this:

"Generally, new [keys] should always be discussed before being added
to [Map features], and new tags in major keys like "highway=" should
be formally proposed. A proposal is also recommended for any new tag
which replaces an existing tag.

"However, if a tag is commonly used and clearly documented in the
wiki, and does not replace an existing tag, new values for certain
keys with can be added without a proposal to these keys: craft=,
building=, office=, shop= and sport=. Please discuss the new tag in a
public forum before adding to Map Features."

Does everyone agree with this wording?


Err No. It is misleading to say "new values for certain keys with can be added 
without a proposal" as new values can be add to any key without a proposal.
Indeed new keys can be added without a proposal.


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

[Tagging] Deprecate access=public (synonym for access=yes)

[Joseph Eisenberg]

I'd like to deprecate access=public. This tag never documented as a
value for access, but was imported massively one time a few years
back, then mostly deleted, but then a few years ago it was added to a
couple of presets in JOSM and iD, for toilets and parking lots. Now
it's been removed from those again, and usage has not increased over
the past year.

The tag access=yes means the same thing, and has increased this year
from 600k to 700k uses; it's over 20 times more common.

Any objections?

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

Re: [Tagging] Charging stations: socket::output -- which format for the value?

[Warin]

On 31/07/19 01:39, Joseph Eisenberg wrote:

The tag socket::output has been used 5000 times, so I think it's
best to describe existing usage on the wiki. The current usage is to
tag the units, which are almost always kW:

socket:type2:output has been used 3663 times, and the majority (>70%)
are tagged with 22kW, 22 kW, 43kW and 11 kW - they all have kW after
the number, but the presence of a space is variable.
https://taginfo.openstreetmap.org/keys/socket%3Atype2%3Aoutput#values

socket:chademo:output has been used 1 275 times, and 91% are tagged
50kW or 50 kW - there are 12 with 5 and 11 with 50 and no units
(0.1% each).

socket:schuko:output has been used 1 306 times and 80% are tagged
3.6kW, with another 11% tagged 3.7␣kW - all but one common value
included kW as a unit (3700 is used 11 times; 0.1%).

socket:typee:output has been used 128 times, and 84% area tagged "3
kW", none have no units.

socket:type1:output is used 83 times, all values end with "kW"

socket:tesla_supercharger:output is used 72 times, all values end with
"kW" except 2 (one is 12, the other 120).

So 99% have the format "kW" or " kW" with a space.

I think the wiki should state that the output is specified in kW and
the unit is specified, to match current usage.


Err the wiki could state the default is kW.
There is no present default unit for power - see 
https://wiki.openstreetmap.org/wiki/Map_Features/Units#Default_units
Adding a default would be good, and kW is probably the most universal in this 
case, but for power generation MW is more universal.


And the wiki could also state that a space is required between the numeric 
values and the units, if any.
This is the case for all other units so the convention should be held.



Joseph

On 7/30/19, dktue  wrote:

OSM typically places unit after the value.
For examples see
https://wiki.openstreetmap.org/wiki/Map_Features/Units#Explicit_specifications

In Some cases the unit is omitted and a default is assumed. Would this
default be "kW" in this case?





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

Re: [Tagging] Deprecate access=public (synonym for access=yes)

[Frederik Ramm]

Hi,

On 31.07.19 09:22, Joseph Eisenberg wrote:
> I'd like to deprecate access=public. 

Can you explain what concrete actions you mean by that? What exactly
would you do if everyone said "yeah, go ahaead"?

Bye
Frderik

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

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

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Martin Koppenhoefer]

sent from a phone

> On 31. Jul 2019, at 09:20, Warin <61sundow...@gmail.com> wrote:
> 
> There is no requirement for a proposal for values or keys of any kind.
> A proposal is at best a 'recommendation', not a 'requirement'.


+1

Cheers Martin 

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

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Markus]

Hi Joseph

On Tue, 30 Jul 2019 at 15:59, Joseph Eisenberg
 wrote:
>
> I still haven't seen any benefit in adding public_transport=platform
> to highway=bus_stop or highway=platform or railway=platform features,
> and it doesn't look like the =stop_position tag is needed for routers
> either, so all 3 of the main public_transport tags (except perhaps the
> stop_area relation?) are rarely helpful.

I agree, and it seems that most people that took part in this long
discussion [1] i initiated in April about improving public transport
mapping agreed too.

[1]: 
https://lists.openstreetmap.org/pipermail/talk-transit/2019-April/002052.html

While highway=bus_stop works in most simpler cases, it doesn't work
very well for bus stations. For example, consider this simplified map
of the postbus station in Bern. [2]

[2]: https://wiki.openstreetmap.org/wiki/File:Postautostation_Bern.svg

It consists of seven platforms, numbered 1–7, and a mere pole on the
sidewalk with the number 8. As highway=bus_stop and highway=platform
both use the the highway=* key and thus can't be combined, for every
platform i would need to map a highway=platform and a highway=bus_stop
object. But which one should get the ref=*? Both? And which one should
be added to the route relation? Usually highway=bus_stop is added to
the route relation, but for trains, it is the platform.

A possible solution of this problem were to invent a new tag for
stops, which doesn't use the highway=* or railway=* key and thus can
be combined with highway/railway=platform (e.g. public_transport=stop;
or, alternatively, a new tag for platforms). However, i haven't got
any feedback on that idea, so i don't know whether the community would
accept such a change in tagging.

Regards

Markus

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

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Joseph Eisenberg]

I apologize for the unclear wording. I'm not asking if a proposal is
needed for creating a new key or value. Anyone can make up a new tag,
and this happens hundreds of times a day.

I'm asking:

when should a new value should be added to the wiki page "Map Features".

The idea is that for a key like "shop=" or "office=", the key itself
is enough to define the feature for most purposes. Most map makers or
apps will just show one icon for all or most types of shop, and for
most types of office, so it's probably fine if users add more of these
to Map Features under "Shop" and "Office" - it won't cause any
problems.

Probably it still should be mentioned in a public forum at least once,
but a proposal would be a bit of a waste of time for a specialty tag
"shop=fountain_pens" (a shop specializing in selling fountain pens).

In contrast, I wouldn't have added "waterway=tidal_channel" to the 3
existing natural waterway types on Map Features without an approved
proposal, since that would be a major change to the whole tagging
system for waterways which requires community discussion.

On 7/31/19, Martin Koppenhoefer  wrote:
>
>
> sent from a phone
>
>> On 31. Jul 2019, at 09:20, Warin <61sundow...@gmail.com> wrote:
>>
>> There is no requirement for a proposal for values or keys of any kind.
>> A proposal is at best a 'recommendation', not a 'requirement'.
>
>
> +1
>
> 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] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[marc marc]

Le 31.07.19 à 10:50, Joseph Eisenberg a écrit :
> when should a new value should be added to the wiki page "Map Features".

imho when the key is :
- documented
- well used/supported
- not controversial
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Paul Allen]

On Wed, 31 Jul 2019 at 07:47, Joseph Eisenberg 
wrote:

> Based on current practice, it seems that most people are ok with
> adding new values to certain keys that already have a long list of
> documented values in map features, as long as the tag is frequently
> used and well-documented?
>

It depends, as others have already pointed out on this thread.  The wiki
pages for some
keys, such as shop=* have a special value "user defined" which is "All
commonly used
values according to Taginfo."  For those, it is implicit that values can be
added without
discussion, if they meet certain criteria.  As ever, it ends up as "use
your common
sense."

I'd also point out that at least one editor populates some of its
drop-downs from Wiki
pages (more recently it uses the Wikidata in some cases).  This may be a
factor in
your considerations.

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

Re: [Tagging] Deprecate access=public (synonym for access=yes)

[Joseph Eisenberg]

1) Add to list of deprecated features
(https://wiki.openstreetmap.org/wiki/Deprecated_features)
2) Add deprecated features template to wiki page Tag:access=public, which says:

"This feature has been labeled as deprecated. The recommended
replacement is: access=yes.
The reason is documented in Deprecated features. You are still free to
continue to use or interpret this tag as you see fit since
OpenStreetMap does not have “banned features”. Under no circumstances
should you (semi-)automatically change “deprecated” tags to something
else in the database..." (this is a standard template)

On 7/31/19, Frederik Ramm  wrote:
> Hi,
>
> On 31.07.19 09:22, Joseph Eisenberg wrote:
>> I'd like to deprecate access=public.
>
> Can you explain what concrete actions you mean by that? What exactly
> would you do if everyone said "yeah, go ahaead"?
>
> Bye
> Frderik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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] Charging stations: socket::output -- which format for the value?

[Paul Allen]

On Wed, 31 Jul 2019 at 08:35, Warin <61sundow...@gmail.com> wrote:

>
> Err the wiki could state the default is kW.
> There is no present default unit for power - see
> https://wiki.openstreetmap.org/wiki/Map_Features/Units#Default_units
> Adding a default would be good, and kW is probably the most universal in
> this case, but for power generation MW is more universal.
>

There have been sporadic discussions here about mapping the availability of
USB charger
outlets.  A default of kW doesn't suit everything.  But, assuming we agree
that SI multipliers
can be used, then sure, kW is a reasonable default.  I would also propose
that any value
that defaults to any SI unit should allow SI multipliers.

And the wiki could also state that a space is required between the numeric
> values and the units, if any.
> This is the case for all other units so the convention should be held.
>

It is certainly desirable that a space be there (in non-monospaced fonts, a
good typographer
would insert a thin space rather than a full space, this does conform to SI
requirements for
spacing).  However, people are fallible and may omit the space for many
reasons (didn't
read the documentation, typo, etc.).  It would be nice if editors (at a
minimum, it could be
applied to other steps in the chain too) applied Postel's robustness
principle: "Be conservative
in what you send, be liberal in what you accept."  I.e., an editor would
allow a user to enter
"7kW" but would upload it as "7 kW."  Some editors already strip
superfluous spaces from
values (of any kind) so this would not be a drastic break from what they
currently do.

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

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[yo paseopor]

please: NO MORE TAGS
Either... can we mix all the tags of all the versions of Public transport
into a UNIQUE scheme for ALL kinds of transports, tagging it at the same
way with the same name: from electric autonomous buses to new Uber's
helicopters?
A scheme has to be scalable. Can we define that? Can we design that?
-Basic parts
-Basic tags
-Basic values

And then... some kind of automated conversion of tags done by local
communities, with specific instructions at the wiki. Also tag as deprecated
all the old mixed stuff.

What do you think?
Salut i mapes (health and maps)
yopaseopor


On Wed, Jul 31, 2019 at 10:37 AM Markus  wrote:

> Hi Joseph
>
> On Tue, 30 Jul 2019 at 15:59, Joseph Eisenberg
>  wrote:
> >
> > I still haven't seen any benefit in adding public_transport=platform
> > to highway=bus_stop or highway=platform or railway=platform features,
> > and it doesn't look like the =stop_position tag is needed for routers
> > either, so all 3 of the main public_transport tags (except perhaps the
> > stop_area relation?) are rarely helpful.
>
> I agree, and it seems that most people that took part in this long
> discussion [1] i initiated in April about improving public transport
> mapping agreed too.
>
> [1]:
> https://lists.openstreetmap.org/pipermail/talk-transit/2019-April/002052.html
>
> While highway=bus_stop works in most simpler cases, it doesn't work
> very well for bus stations. For example, consider this simplified map
> of the postbus station in Bern. [2]
>
> [2]: https://wiki.openstreetmap.org/wiki/File:Postautostation_Bern.svg
>
> It consists of seven platforms, numbered 1–7, and a mere pole on the
> sidewalk with the number 8. As highway=bus_stop and highway=platform
> both use the the highway=* key and thus can't be combined, for every
> platform i would need to map a highway=platform and a highway=bus_stop
> object. But which one should get the ref=*? Both? And which one should
> be added to the route relation? Usually highway=bus_stop is added to
> the route relation, but for trains, it is the platform.
>
> A possible solution of this problem were to invent a new tag for
> stops, which doesn't use the highway=* or railway=* key and thus can
> be combined with highway/railway=platform (e.g. public_transport=stop;
> or, alternatively, a new tag for platforms). However, i haven't got
> any feedback on that idea, so i don't know whether the community would
> accept such a change in tagging.
>
> Regards
>
> Markus
>
> ___
> 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] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Joseph Eisenberg]

Agreed, there are enough tags for public transport already. I don't
think anything new is needed.

If there is a platform where buses stop, then there's a bus stop, and
a platform. The platform is a physical feature, and I believe it would
still be a highway=platform even if the bus service were discontinued.

The bus stop represents that public buses actually stop at the
location to pick up or drop off passengers.

The ref= should go on whatever of the two features that it actual
refers to: if it's on the bus stop sign or pole, it probably
represents the bus stop, but it might actually refer to the physical
platform and each different bus route that stops there might have a
different ref=* for that bus stop.

Perhaps sometimes you'll have to add the ref=* to both the stop and
the platform, but that's ok. The public_transport=stop_position +
=platform + stop_area idea often leads to putting the same ref on 3
different objects.

In all other situations (rail platforms, regular bus stops without an
elevated platform, tram stops etc), the Refined_Public_Transport
proposal is clearly simpler than using public_transport=* tags, so it
looks like a good option.

Joseph

On 7/31/19, yo paseopor  wrote:
> please: NO MORE TAGS
> Either... can we mix all the tags of all the versions of Public transport
> into a UNIQUE scheme for ALL kinds of transports, tagging it at the same
> way with the same name: from electric autonomous buses to new Uber's
> helicopters?
> A scheme has to be scalable. Can we define that? Can we design that?
> -Basic parts
> -Basic tags
> -Basic values
>
> And then... some kind of automated conversion of tags done by local
> communities, with specific instructions at the wiki. Also tag as deprecated
> all the old mixed stuff.
>
> What do you think?
> Salut i mapes (health and maps)
> yopaseopor
>
>
> On Wed, Jul 31, 2019 at 10:37 AM Markus  wrote:
>
>> Hi Joseph
>>
>> On Tue, 30 Jul 2019 at 15:59, Joseph Eisenberg
>>  wrote:
>> >
>> > I still haven't seen any benefit in adding public_transport=platform
>> > to highway=bus_stop or highway=platform or railway=platform features,
>> > and it doesn't look like the =stop_position tag is needed for routers
>> > either, so all 3 of the main public_transport tags (except perhaps the
>> > stop_area relation?) are rarely helpful.
>>
>> I agree, and it seems that most people that took part in this long
>> discussion [1] i initiated in April about improving public transport
>> mapping agreed too.
>>
>> [1]:
>> https://lists.openstreetmap.org/pipermail/talk-transit/2019-April/002052.html
>>
>> While highway=bus_stop works in most simpler cases, it doesn't work
>> very well for bus stations. For example, consider this simplified map
>> of the postbus station in Bern. [2]
>>
>> [2]: https://wiki.openstreetmap.org/wiki/File:Postautostation_Bern.svg
>>
>> It consists of seven platforms, numbered 1–7, and a mere pole on the
>> sidewalk with the number 8. As highway=bus_stop and highway=platform
>> both use the the highway=* key and thus can't be combined, for every
>> platform i would need to map a highway=platform and a highway=bus_stop
>> object. But which one should get the ref=*? Both? And which one should
>> be added to the route relation? Usually highway=bus_stop is added to
>> the route relation, but for trains, it is the platform.
>>
>> A possible solution of this problem were to invent a new tag for
>> stops, which doesn't use the highway=* or railway=* key and thus can
>> be combined with highway/railway=platform (e.g. public_transport=stop;
>> or, alternatively, a new tag for platforms). However, i haven't got
>> any feedback on that idea, so i don't know whether the community would
>> accept such a change in tagging.
>>
>> Regards
>>
>> Markus
>>
>> ___
>> 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] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Paul Allen]

On Wed, 31 Jul 2019 at 12:52, Joseph Eisenberg 
wrote:

> Agreed, there are enough tags for public transport already. I don't
> think anything new is needed.
>

There's something I haven't found a way of mapping.  That's a bus stop
where there's a bay
inlet into the pavement (aka sidewalk, aka causeway).  If it served a
different purpose and
had different road markings, it could be a lay-by (aka rest area) or a
parking bay.  But it's a
bus stop where the bus does not obstruct the flow of traffic.  There are
four of those in
my town, that I can think of (there may be others I've missed).

Yes, I could use area:highway or add area=yes to a closed way, but those
don't seem to render
on a popular, well-known carto intended for mappers to check their work for
anything but
pedestrian ways.

Is there a way of doing it that I've missed?  If not, could we have one?

Example: https://www.openstreetmap.org/edit#map=20/52.08760/-4.65318

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

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Martin Koppenhoefer]

sent from a phone

> On 31. Jul 2019, at 10:50, Joseph Eisenberg  
> wrote:
> 
> when should a new value should be added to the wiki page "Map Features".


only after it has become generally established :)

while none of these conditions are maybe absolute hard requirements, IMHO most 
of them should be fulfilled:

- is used in significant numbers by many different people 
- has presets in different applications 
- is used by at least one “important” data user (e.g. OpenStreetMap carto, 
routing service, osmand, etc.)
- is used on several continents and not just in a limited geographic area 
(otherwise it shouldn’t appear on the global map features list)
- has a definition and it is (largely ) undisputed 

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

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Jo]

bus_bay = right | left | both (  https://www.openstreetmap.org/way/485293336
  )

For me the object that represents the bus stop, is always a simple node. I
don't see a problem for doing that in bus stations as well.

If there are actual platforms, whether in a bus station or somewhere along
a way, it can be tagged:

highway=platform (https://www.openstreetmap.org/way/304753571)

or

or railway=platform (https://www.openstreetmap.org/way/255344359)

for trams.

on a way.

These ways don't get the ref, name, route_ref, zone, local_ref, operator,
network, and so on, those go on the node that represents the bus stop. Only
that node needs to be added to the route relations. It doesn't get any
simpler than that.

https://www.openstreetmap.org/node/576656712  (example of a bus stop served
by 3 different operators near Brussels, I only put
public_transport=platform, bus=yes because for a few years that seemed like
the right thing to do. Today I wouldn't mind removing those 2 tags once
again.)

Those platform ways could get:

tactile_paving=yes
wheelchair=yes
height=

So there is no real conflict between highway=bus_stop or railway=tram_stop
on a node

and

highway=platform or railway=platform on a way or an area.

Polyglot

On Wed, Jul 31, 2019 at 2:13 PM Paul Allen  wrote:

> On Wed, 31 Jul 2019 at 12:52, Joseph Eisenberg 
> wrote:
>
>> Agreed, there are enough tags for public transport already. I don't
>> think anything new is needed.
>>
>
> There's something I haven't found a way of mapping.  That's a bus stop
> where there's a bay
> inlet into the pavement (aka sidewalk, aka causeway).  If it served a
> different purpose and
> had different road markings, it could be a lay-by (aka rest area) or a
> parking bay.  But it's a
> bus stop where the bus does not obstruct the flow of traffic.  There are
> four of those in
> my town, that I can think of (there may be others I've missed).
>
> Yes, I could use area:highway or add area=yes to a closed way, but those
> don't seem to render
> on a popular, well-known carto intended for mappers to check their work
> for anything but
> pedestrian ways.
>
> Is there a way of doing it that I've missed?  If not, could we have one?
>
> Example: https://www.openstreetmap.org/edit#map=20/52.08760/-4.65318
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Joseph Eisenberg]

> - is used in significant numbers by many different people
> - has presets in different applications
> - is used by at least one “important” data user (e.g. OpenStreetMap carto,
> routing service, osmand, etc.)
> - is used on several continents and not just in a limited geographic area
> (otherwise it shouldn’t appear on the global map features list)
> - has a definition and it is (largely ) undisputed

I used to think that these were requirements for all features. but
many values of shop=, building=, office= and even some types of
barriers= have been added without discussion when they are still
rarely used.

My thought was that we could clarify that certain types of new
features can be added to the Map Features pages without meeting all
those characteristics (shops, offices) but that other types shouldn't
be added without discussion.

If you want to be strict about those standards above, there are
several dozen tags that would need to be removed from Map Features.
I'm actually ok with that option, but it seems unnecessary for values
of keys where the key itself is enough for rendering and general
classification.

Joseph

On 7/31/19, Martin Koppenhoefer  wrote:
>
>
> sent from a phone
>
>> On 31. Jul 2019, at 10:50, Joseph Eisenberg 
>> wrote:
>>
>> when should a new value should be added to the wiki page "Map Features".
>
>
> only after it has become generally established :)
>
> while none of these conditions are maybe absolute hard requirements, IMHO
> most of them should be fulfilled:
>
> - is used in significant numbers by many different people
> - has presets in different applications
> - is used by at least one “important” data user (e.g. OpenStreetMap carto,
> routing service, osmand, etc.)
> - is used on several continents and not just in a limited geographic area
> (otherwise it shouldn’t appear on the global map features list)
> - has a definition and it is (largely ) undisputed
>
> Cheers Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

On 7/31/19, Martin Koppenhoefer  wrote:
>
>
> sent from a phone
>
>> On 31. Jul 2019, at 10:50, Joseph Eisenberg 
>> wrote:
>>
>> when should a new value should be added to the wiki page "Map Features".
>
>
> only after it has become generally established :)
>
> while none of these conditions are maybe absolute hard requirements, IMHO
> most of them should be fulfilled:
>
> - is used in significant numbers by many different people
> - has presets in different applications
> - is used by at least one “important” data user (e.g. OpenStreetMap carto,
> routing service, osmand, etc.)
> - is used on several continents and not just in a limited geographic area
> (otherwise it shouldn’t appear on the global map features list)
> - has a definition and it is (largely ) undisputed
>
> 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] Was public_transport=platform intended to > always be combined with highway=bus_stop?

[Peter Neale via Tagging]

FWIW, I agree; No more tags, please, when we can manage with those that we have.
Busses stop at bus-stops and the route information shows which bus-stops they 
serve and the times when they are due there, so these should be tagged with ID, 
Ref Number, etc. as appropriate.  
A platform is a raised structure, constructed to bring the passengers up to, or 
near, the same level as the floor in the transport vehicle (bus, tram, train).  
So, if there is a platform at the bus-stop, that can be mapped, just as tactile 
pavement might be, but needs no more tags.
Trains stop at stations and the route information and timetable show which 
stations they serve and when they are due to arrive/depart, so the whole area 
should be mapped and tagged as a station.  Within the station there will 
normally be several platforms, which may be named "Platform 1", "Platform 2"... 
...or "Platform A", "Platform B" etc.  These could / should be mapped and given 
an name tag.  Whilst trains for particular destinations may NORMALLY use a 
certain platform, that can vary, depending on breakdowns, delays, scheduling 
issues, etc. so the Platforms should not be tagged with further information 
about the trains / route(s) using them.
The only potential issues I can see with my own argument above are:  How will 
the stations be connected to the railway lines? / Do they need to be? / How 
does the train route relation connect lines and stations? 
I do hope that helps, rather than just making things more confusing. 
Peter    
>Date: Wed, 31 Jul 2019 20:51:13 +0900
>From: Joseph Eisenberg 
>To: "Tag discussion, strategy and related tools"
    
>Subject: Re: [Tagging] Was public_transport=platform intended to
>    always be combined with highway=bus_stop?
>Message-ID:
>    
Content-Type: text/plain; charset="UTF-8"

>Agreed, there are enough tags for public transport already. I don't
>think anything new is needed.

>If there is a platform where buses stop, then there's a bus stop, and
>a platform. The platform is a physical feature, and I believe it would
>still be a highway=platform even if the bus service were discontinued.

>The bus stop represents that public buses actually stop at the
>location to pick up or drop off passengers.

>The ref= should go on whatever of the two features that it actual
>refers to: if it's on the bus stop sign or pole, it probably
>represents the bus stop, but it might actually refer to the physical
>platform and each different bus route that stops there might have a
>different ref=* for that bus stop.

>Perhaps sometimes you'll have to add the ref=* to both the stop and
>the platform, but that's ok. The public_transport=stop_position +
>=platform + stop_area idea often leads to putting the same ref on 3
>different objects.

>In all other situations (rail platforms, regular bus stops without an
>elevated platform, tram stops etc), the Refined_Public_Transport>proposal is 
>clearly simpler than using public_transport=* tags, so it
>looks like a good option.

>Joseph

>>On 7/31/19, yo paseopor  wrote:
>> please: NO MORE TAGS
>> Either... can we mix all the tags of all the versions of Public transport
>> into a UNIQUE scheme for ALL kinds of transports, tagging it at the same
>> way with the same name: from electric autonomous buses to new Uber's
>> helicopters?
>> A scheme has to be scalable. Can we define that? Can we design that?
>> -Basic parts>> -Basic tags
>> -Basic values
>>
>> And then... some kind of automated conversion of tags done by local
>> communities, with specific instructions at the wiki. Also tag as deprecated
>> all the old mixed stuff.
>>
>> What do you think?
>> Salut i mapes (health and maps)>> yopaseopor
>>
>>
>> On Wed, Jul 31, 2019 at 10:37 AM Markus  wrote:
>>
>>> Hi Joseph
>>>
>>> On Tue, 30 Jul 2019 at 15:59, Joseph Eisenberg
>>>  wrote:
>> >>
>> >> I still haven't seen any benefit in adding public_transport=platform
>> >> to highway=bus_stop or highway=platform or railway=platform features,
>> >> and it doesn't look like the =stop_position tag is needed for routers
>> >> either, so all 3 of the main public_transport tags (except perhaps the
>> >> stop_area relation?) are rarely helpful.
>>>
>>> I agree, and it seems that most people that took part in this long
>>> discussion [1] i initiated in April about improving public transport
>>> mapping agreed too.
>>>
>>> [1]:
>>> 
>>>https://lists.openstreetmap.org/pipermail/talk-transit/2019-April/002052.html
>>>
>>> While highway=bus_stop works in most simpler cases, it doesn't work
>>> very well for bus stations. For example, consider this simplified map
>>> of the postbus station in Bern. [2]
>>>
>>> [2]: https://wiki.openstreetmap.org/wiki/File:Postautostation_Bern.svg
>>>
>>> It consists of seven platforms, numbered 1–7, and a mere pole on the>>> 
>>> sidewalk with the number 8. As highway=bus_stop and highway=platform
>>> both use the the highway=* key and thus can't be combined, for every
>>> platform i would need to map a highway=pl

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Markus]

On Wed, 31 Jul 2019 at 13:52, Joseph Eisenberg
 wrote:
>
> Agreed, there are enough tags for public transport already. I don't
> think anything new is needed.

My idea was actually to replace the misnamed public_transport=platform
with public_transport=stop and to abandon highway=bus_stop and
railway=tram_stop as well as public_transport=stop_position. All in
all that's not more tags, but three less.

Besides, as there were only one element per stop (even if the stop is
a platform), public_transport=stop_area would only be necessary at
stations.

> If there is a platform where buses stop, then there's a bus stop, and
> a platform. The platform is a physical feature, and I believe it would
> still be a highway=platform even if the bus service were discontinued.

I agree, it remains a highway=platform even if it's not operated
anymore. But when it's operated, the platform actually represents a
bus stop.

> [...]
>
> The ref= should go on whatever of the two features that it actual
> refers to: if it's on the bus stop sign or pole, it probably
> represents the bus stop, but it might actually refer to the physical
> platform and each different bus route that stops there might have a
> different ref=* for that bus stop.

The number in my example refers to the place where people wait for the
buses, for numbers 1–7 this is the platform and for number 8 it is the
place on the sidewalk. So, where should i put ref=1 ... ref=7
according to you? On highway=platform, on highway=bus_stop or on both?
And which one of them should i add to the route relation? It were a
lot easier if there were just one object.

> Perhaps sometimes you'll have to add the ref=* to both the stop and
> the platform, but that's ok. The public_transport=stop_position +
> =platform + stop_area idea often leads to putting the same ref on 3
> different objects.
>
> In all other situations (rail platforms, regular bus stops without an
> elevated platform, tram stops etc), the Refined_Public_Transport
> proposal is clearly simpler than using public_transport=* tags, so it
> looks like a good option.

I find that proposal to be inconsistent and unnecessarily complex.
Inconsistent because sometimes highway=bus_stop has to be mapped
beside the road and at other times on the road, and because sometimes
there is one highway=bus_stop for one stop and at other times there is
one highway=bus_stop for two stops. And unnecessarily complex because
it not only requires a stop_area, but also a stop_area_group. In
contrast, my suggestion would only require stop_area's at stations.

Regards

Markus

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

Re: [Tagging] Was public_transport=platform intended to > always be combined with highway=bus_stop?

[Markus]

On Wed, 31 Jul 2019 at 15:08, Peter Neale via Tagging
 wrote:
>
> Within the station there will normally be several platforms, which may be 
> named "Platform 1", "Platform 2"... ...or "Platform A", "Platform B" etc.  
> These could / should be mapped and given an name tag.

Common practice is to use ref=*, not name=*, because it's the number
or letter of the platform, not its name. (This also has the advantage
that e.g. routers can translate it into other languages.)

> Whilst trains for particular destinations may NORMALLY use a certain 
> platform, that can vary, depending on breakdowns, delays, scheduling issues, 
> etc. so the Platforms should not be tagged with further information about the 
> trains / route(s) using them.

I disagree. If the train normally uses the same platform, except in
some rare moments, i think it helps to know from which platform it
departs. Note that bus stops sometimes can also be displaced or even
omitted because of roadworks, breakdowns, delays etc.

Regards

Markus

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

Re: [Tagging] Was public_transport=platform intended to > always be combined with highway=bus_stop?

[Peter Neale via Tagging]

Hi Markus,
Thank you for your comments.
I stand corrected on the Name v. Ref issue.  You are right; it would be better 
to map a platform and tag it with Ref= .
As regards your other comment; I stand by my view that it is useful to know 
which services stop at a given station, but that any user wishing to travel 
would expect to check which platform to stand on, as that could be changed at 
short notice.  So adding that detail to the map would not (IMHO) be useful.   
Regards,
Peter
On Wednesday, 31 July 2019, 17:49:06 BST, Markus 
 wrote:  
 
 On Wed, 31 Jul 2019 at 15:08, Peter Neale via Tagging
 wrote:
>
> Within the station there will normally be several platforms, which may be 
> named "Platform 1", "Platform 2"... ...or "Platform A", "Platform B" etc.  
> These could / should be mapped and given an name tag.

Common practice is to use ref=*, not name=*, because it's the number
or letter of the platform, not its name. (This also has the advantage
that e.g. routers can translate it into other languages.)

> Whilst trains for particular destinations may NORMALLY use a certain 
> platform, that can vary, depending on breakdowns, delays, scheduling issues, 
> etc. so the Platforms should not be tagged with further information about the 
> trains / route(s) using them.

I disagree. If the train normally uses the same platform, except in
some rare moments, i think it helps to know from which platform it
departs. Note that bus stops sometimes can also be displaced or even
omitted because of roadworks, breakdowns, delays etc.

Regards

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

[Tagging] Tagging of bullrings

[dcapillae]

Hi,

I would like to ask you about the best tagging for a bullring:

leisure=stadium
stadium=bullring

or

leisure=stadium
stadium=bull_ring

or

leisure=stadium
sport=bullfighting (in use)

I haven't considered "leisure=bullring". Some mappers use this tag to 
map bullrings, but I think it's better "leisure=stadium". Obviously a 
bullring is a type of stadium.


I'm not interested in the controversy about bullfights, I just want to 
know what tags I should use to map a bullring as best as possible.


Thank you for your comments.

Greetings from Spain.

Regards,
Daniel


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

Re: [Tagging] Was public_transport=platform intended to > always be combined with highway=bus_stop?

[Jo]

For platform numbers or letters I've seen local_ref being used succesfully.
For train platforms it is also possible they are divided into zones, where
one part of the train may have one destination, and the other another
destination. Such trains are split either in that station or a subsequent
one.

On Wed, Jul 31, 2019 at 7:07 PM Peter Neale via Tagging <
tagging@openstreetmap.org> wrote:

> Hi Markus,
>
> Thank you for your comments.
>
> I stand corrected on the Name v. Ref issue.  You are right; it would be
> better to map a platform and tag it with Ref= .
>
> As regards your other comment; I stand by my view that it is useful to
> know which services stop at a given station, but that any user wishing to
> travel would expect to check which platform to stand on, as that could be
> changed at short notice.  So adding that detail to the map would not (IMHO)
> be useful.
>
> Regards,
>
> Peter
>
> On Wednesday, 31 July 2019, 17:49:06 BST, Markus <
> selfishseaho...@gmail.com> wrote:
>
>
> On Wed, 31 Jul 2019 at 15:08, Peter Neale via Tagging
>  wrote:
> >
> > Within the station there will normally be several platforms, which may
> be named "Platform 1", "Platform 2"... ...or "Platform A", "Platform B"
> etc.  These could / should be mapped and given an name tag.
>
> Common practice is to use ref=*, not name=*, because it's the number
> or letter of the platform, not its name. (This also has the advantage
> that e.g. routers can translate it into other languages.)
>
> > Whilst trains for particular destinations may NORMALLY use a certain
> platform, that can vary, depending on breakdowns, delays, scheduling
> issues, etc. so the Platforms should not be tagged with further information
> about the trains / route(s) using them.
>
> I disagree. If the train normally uses the same platform, except in
> some rare moments, i think it helps to know from which platform it
> departs. Note that bus stops sometimes can also be displaced or even
> omitted because of roadworks, breakdowns, delays etc.
>
>
> Regards
>
> Markus
> ___
> 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] Tagging of bullrings

[Jmapb]

On 7/31/2019 1:19 PM, dcapillae wrote:


leisure=stadium
sport=bullfighting (in use)


Hi Daniel -- definitely this one: leisure=stadium + sport=bullfighting. 
You might also want to use the building=stadium tag, if the stadium
occupies the entire building in question (assuming it's in a building --
I'm guessing they all are but I'm not too familiar with bullfighting
stadia.)

Jason


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

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Martin Koppenhoefer]

sent from a phone

> On 31. Jul 2019, at 14:46, Joseph Eisenberg  
> wrote:
> 
> My thought was that we could clarify that certain types of new
> features can be added to the Map Features pages without meeting all
> those characteristics (shops, offices) but that other types shouldn't
> be added without discussion.


I’m unsure about the map features page, although I occasionally pass by I have 
not really been using it for many years. My idea about it is that it is an 
introductory or summary page to explain the tagging system in principle, 
essentially aiming at newbies, so it shouldn’t be too long (which it clearly is 
at the moment). For finding tags I would recommend taginfo and the wiki search. 


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

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Graeme Fitzpatrick]

On Wed, 31 Jul 2019 at 22:37, Martin Koppenhoefer 
wrote:

>
> only after it has become generally established :)
>
> while none of these conditions are maybe absolute hard requirements, IMHO
> most of them should be fulfilled:
>
> - is used in significant numbers by many different people
>

But what are "generally established" & "significant numbers"?

500 / 1000 / 5000 ?

On Wed, 31 Jul 2019 at 22:47, Joseph Eisenberg 
wrote:

> My thought was that we could clarify that certain types of new
> features can be added to the Map Features pages without meeting all
> those characteristics (shops, offices) but that other types shouldn't
> be added without discussion.
>

Not a bad idea.

It would also be handy to have something very prominent up the top of the
page to tell people to search via the Wiki box up top right, & also via
TagInfo (with link), to see if an appropriate tag already exists.

Thanks

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

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Warin]

Ferries also seam to be forgotten...

public_transport=platform??? Covers ferry, bus, train, trams ... ??

(One ring to rule them all etc)

With regard to ref. I have bus stops that have 'Stand A' etc near train 
stations. these also carry a reference number that is used by the 
transport company - they are handy if you knowthem as you can type that 
in as your destination or start for there website on finding a trip 
scheduled/fee. Discussion on the Australian list resulted in this 
https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#Bus_Stop_names_and_references




On 31/07/19 22:43, Jo wrote:
bus_bay = right | left | both ( 
https://www.openstreetmap.org/way/485293336  )


For me the object that represents the bus stop, is always a simple 
node. I don't see a problem for doing that in bus stations as well.


If there are actual platforms, whether in a bus station or somewhere 
along a way, it can be tagged:


highway=platform (https://www.openstreetmap.org/way/304753571)

or

or railway=platform (https://www.openstreetmap.org/way/255344359)

for trams.

on a way.

These ways don't get the ref, name, route_ref, zone, local_ref, 
operator, network, and so on, those go on the node that represents the 
bus stop. Only that node needs to be added to the route relations. It 
doesn't get any simpler than that.


Good. I can see no benefit to adding additional information to the 
route. Things like shelters, toilets etc all become evident when the map 
is viewed. The routeing information does not need it.


https://www.openstreetmap.org/node/576656712 (example of a bus stop 
served by 3 different operators near Brussels, I only put 
public_transport=platform, bus=yes because for a few years that seemed 
like the right thing to do. Today I wouldn't mind removing those 2 
tags once again.)


Those platform ways could get:

tactile_paving=yes
wheelchair=yes
height=

So there is no real conflict between highway=bus_stop or 
railway=tram_stop on a node


and

highway=platform or railway=platform on a way or an area.

Polyglot

On Wed, Jul 31, 2019 at 2:13 PM Paul Allen > wrote:


On Wed, 31 Jul 2019 at 12:52, Joseph Eisenberg
mailto:joseph.eisenb...@gmail.com>>
wrote:

Agreed, there are enough tags for public transport already. I
don't
think anything new is needed.


There's something I haven't found a way of mapping. That's a bus
stop where there's a bay
inlet into the pavement (aka sidewalk, aka causeway).  If it
served a different purpose and
had different road markings, it could be a lay-by (aka rest area)
or a parking bay.  But it's a
bus stop where the bus does not obstruct the flow of traffic. 
There are four of those in
my town, that I can think of (there may be others I've missed).

Yes, I could use area:highway or add area=yes to a closed way, but
those don't seem to render
on a popular, well-known carto intended for mappers to check their
work for anything but
pedestrian ways.

Is there a way of doing it that I've missed?  If not, could we
have one?

Example: https://www.openstreetmap.org/edit#map=20/52.08760/-4.65318

-- 
Paul


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



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



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

Re: [Tagging] Charging stations: socket::output -- which format for the value?

[Warin]

On 31/07/19 20:28, Paul Allen wrote:
On Wed, 31 Jul 2019 at 08:35, Warin <61sundow...@gmail.com 
> wrote:



Err the wiki could state the default is kW.
There is no present default unit for power - see
https://wiki.openstreetmap.org/wiki/Map_Features/Units#Default_units
Adding a default would be good, and kW is probably the most
universal in this case, but for power generation MW is more universal.


There have been sporadic discussions here about mapping the 
availability of USB charger

outlets.  A default of kW doesn't suit everything.


USB outlets are typically specified by the current capability. So I 
would not tag power on them but current.

Say, current=0.5 A or current=2.1 A .. where A stands for Ampere.


But, assuming we agree that SI multipliers
can be used, then sure, kW is a reasonable default.  I would also 
propose that any value

that defaults to any SI unit should allow SI multipliers.

And the wiki could also state that a space is required between the
numeric values and the units, if any.
This is the case for all other units so the convention should be held.


It is certainly desirable that a space be there (in non-monospaced 
fonts, a good typographer
would insert a thin space rather than a full space, this does conform 
to SI requirements for
spacing).  However, people are fallible and may omit the space for 
many reasons (didn't
read the documentation, typo, etc.).  It would be nice if editors (at 
a minimum, it could be
applied to other steps in the chain too) applied Postel's robustness 
principle: "Be conservative
in what you send, be liberal in what you accept."  I.e., an editor 
would allow a user to enter
"7kW" but would upload it as "7 kW."  Some editors already strip 
superfluous spaces from
values (of any kind) so this would not be a drastic break from what 
they currently do.

+1


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

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Joseph Eisenberg]

If you read the talk page of the proposal,it’s clear that the stop_area
relations are optional. I actually think that needs to be further clarified
in the main text.

I’m not certain if any database users actually manage stop_area relations
for public transit?

The ref can go on just the highway=bus_stop as a few other people and the
proposal suggest.

The highway=platform way is like a highway=footway of building=roof which
you might also add to the same vicinity to represent real features: it’s a
real, physical feature; an elevated area for passengers to board or alight.

The bus stop node represents the bus service and is always present whether
or not there is a physical platform, so it’s what you add to the route
relation in the proposal. It looks like this is already fairly common
practice.

Joseph

On Thu, Aug 1, 2019 at 1:32 AM Markus  wrote:

> On Wed, 31 Jul 2019 at 13:52, Joseph Eisenberg
>  wrote:
> >
> > Agreed, there are enough tags for public transport already. I don't
> > think anything new is needed.
>
> My idea was actually to replace the misnamed public_transport=platform
> with public_transport=stop and to abandon highway=bus_stop and
> railway=tram_stop as well as public_transport=stop_position. All in
> all that's not more tags, but three less.
>
> Besides, as there were only one element per stop (even if the stop is
> a platform), public_transport=stop_area would only be necessary at
> stations.
>
> > If there is a platform where buses stop, then there's a bus stop, and
> > a platform. The platform is a physical feature, and I believe it would
> > still be a highway=platform even if the bus service were discontinued.
>
> I agree, it remains a highway=platform even if it's not operated
> anymore. But when it's operated, the platform actually represents a
> bus stop.
>
> > [...]
> >
> > The ref= should go on whatever of the two features that it actual
> > refers to: if it's on the bus stop sign or pole, it probably
> > represents the bus stop, but it might actually refer to the physical
> > platform and each different bus route that stops there might have a
> > different ref=* for that bus stop.
>
> The number in my example refers to the place where people wait for the
> buses, for numbers 1–7 this is the platform and for number 8 it is the
> place on the sidewalk. So, where should i put ref=1 ... ref=7
> according to you? On highway=platform, on highway=bus_stop or on both?
> And which one of them should i add to the route relation? It were a
> lot easier if there were just one object.
>
> > Perhaps sometimes you'll have to add the ref=* to both the stop and
> > the platform, but that's ok. The public_transport=stop_position +
> > =platform + stop_area idea often leads to putting the same ref on 3
> > different objects.
> >
> > In all other situations (rail platforms, regular bus stops without an
> > elevated platform, tram stops etc), the Refined_Public_Transport
> > proposal is clearly simpler than using public_transport=* tags, so it
> > looks like a good option.
>
> I find that proposal to be inconsistent and unnecessarily complex.
> Inconsistent because sometimes highway=bus_stop has to be mapped
> beside the road and at other times on the road, and because sometimes
> there is one highway=bus_stop for one stop and at other times there is
> one highway=bus_stop for two stops. And unnecessarily complex because
> it not only requires a stop_area, but also a stop_area_group. In
> contrast, my suggestion would only require stop_area's at stations.
>
> Regards
>
> Markus
>
> ___
> 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] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Joseph Eisenberg]

Ferries use just amenity=ferry_terminal and route=ferry. You can also map
the man_made=pier as the equivalent of a “platform”.

Similarly, aerialways like gondolas have their own station tag,
aerialway=station.

The public_transport tags have never been popular for ferries or
“aerialways”.

On Thu, Aug 1, 2019 at 9:39 AM Warin <61sundow...@gmail.com> wrote:

> Ferries also seam to be forgotten...
>
> public_transport=platform??? Covers ferry, bus, train, trams ... ??
>
> (One ring to rule them all etc)
>
> With regard to ref. I have bus stops that have 'Stand A' etc near train
> stations. these also carry a reference number that is used by the transport
> company - they are handy if you knowthem as you can type that in as your
> destination or start for there website on finding a trip scheduled/fee.
> Discussion on the Australian list resulted in this
> https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#Bus_Stop_names_and_references
>
>
>
> On 31/07/19 22:43, Jo wrote:
>
> bus_bay = right | left | both (
> https://www.openstreetmap.org/way/485293336  )
>
> For me the object that represents the bus stop, is always a simple node. I
> don't see a problem for doing that in bus stations as well.
>
> If there are actual platforms, whether in a bus station or somewhere along
> a way, it can be tagged:
>
> highway=platform (https://www.openstreetmap.org/way/304753571)
>
> or
>
> or railway=platform (https://www.openstreetmap.org/way/255344359)
>
> for trams.
>
> on a way.
>
> These ways don't get the ref, name, route_ref, zone, local_ref, operator,
> network, and so on, those go on the node that represents the bus stop. Only
> that node needs to be added to the route relations. It doesn't get any
> simpler than that.
>
>
> Good. I can see no benefit to adding additional information to the route.
> Things like shelters, toilets etc all become evident when the map is
> viewed. The routeing information does not need it.
>
>
> https://www.openstreetmap.org/node/576656712  (example of a bus stop
> served by 3 different operators near Brussels, I only put
> public_transport=platform, bus=yes because for a few years that seemed like
> the right thing to do. Today I wouldn't mind removing those 2 tags once
> again.)
>
> Those platform ways could get:
>
> tactile_paving=yes
> wheelchair=yes
> height=
>
> So there is no real conflict between highway=bus_stop or railway=tram_stop
> on a node
>
> and
>
> highway=platform or railway=platform on a way or an area.
>
> Polyglot
>
> On Wed, Jul 31, 2019 at 2:13 PM Paul Allen  wrote:
>
>> On Wed, 31 Jul 2019 at 12:52, Joseph Eisenberg <
>> joseph.eisenb...@gmail.com> wrote:
>>
>>> Agreed, there are enough tags for public transport already. I don't
>>> think anything new is needed.
>>>
>>
>> There's something I haven't found a way of mapping.  That's a bus stop
>> where there's a bay
>> inlet into the pavement (aka sidewalk, aka causeway).  If it served a
>> different purpose and
>> had different road markings, it could be a lay-by (aka rest area) or a
>> parking bay.  But it's a
>> bus stop where the bus does not obstruct the flow of traffic.  There are
>> four of those in
>> my town, that I can think of (there may be others I've missed).
>>
>> Yes, I could use area:highway or add area=yes to a closed way, but those
>> don't seem to render
>> on a popular, well-known carto intended for mappers to check their work
>> for anything but
>> pedestrian ways.
>>
>> Is there a way of doing it that I've missed?  If not, could we have one?
>>
>> Example: https://www.openstreetmap.org/edit#map=20/52.08760/-4.65318
>>
>> --
>> Paul
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://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] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Daniel Koć]

W dniu 01.08.2019 o 02:56, Joseph Eisenberg pisze:
> I’m not certain if any database users actually manage stop_area
> relations for public transit?

I'm not sure if you ask if stop_area tag is useful at all or you ask
only about such relation.

In Warsaw there are like 300 lines, if I remember correctly, and every
day some of them are changing, so the script is used to prepare routing
(to be tuned manually before commiting to a database). I'm not sure if
this is still used currently, but I can't imagine any better way to
manage this.


-- 
"Pojechałam truizmem, ale mogę, bo jestem trochę pierdołą" [P. Potocka]



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

[Tagging] Proposed removal of rendering support for natural=marsh in Openstreetmap-carto style

[Joseph Eisenberg]

I've proposed removing the rendering of natural=marsh in
Openstreetmap-carto, the rendering stylesheet used for the "standard"
map layer on openstreetmap.org

https://github.com/gravitystorm/openstreetmap-carto/pull/3829

The common tagging for a marsh is natural=wetland + wetland=marsh as
with other types of wetland.

According to the wiki, natural=marsh has not been recommended at least
since January 2009:
https://wiki.openstreetmap.org/w/index.php?title=Tag:natural%3Dmarsh&oldid=217946;
and since 2016 the page has specified that this tag is deprecated:
https://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dmarsh

Since 2009, wetland=marsh has shown steadily increasing usage. It is
now used 130,000 times, compared to less than 10k remaining uses of
natural=marsh.

Please comment at github if there are any objections to this change or
other comments:
https://github.com/gravitystorm/openstreetmap-carto/pull/3829

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