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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [Tagging] Tagging of bullrings

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

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

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

[Tagging] Tagging of bullrings

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

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

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

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

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

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

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

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

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

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

> - 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 >

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

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ___

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

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"

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

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

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

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

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

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

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

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=