Re: [Tagging] shop=discount

On Tue, 26 Jun 2018 at 11:01, Martin Koppenhoefer wrote: > > Sorry for writing again, but I believe this discussion shows that the term > shop=discount is not self-explaining at all. It evokes different thoughts in > different people / national contexts. In Germany, the term "discounter" is >

Re: [Tagging] shop=discount

On Tue, 26 Jun 2018 at 00:50, Paul Allen wrote: > > Discount stores are, as I understand it (I don't have any remotely near me) > more of a cut-down wholesaler but open > to the public. Presentation and packaging is that of a wholesaler, and > savings come from buying in bulk. Depending on >

Re: [Tagging] shop=discount

Hi No, a discount shop isn't the same as a a variety shop. To cite Wikipedia [^1]: > A discount store or discount shop is a retail shop which sells products at > prices that are lower than the typical market price. > > [...] > > Discount stores/shops are not variety stores, which sell goods at

Re: [Tagging] The endless debate about "landcover" as a top-level tag

On 7 June 2018 at 19:26, Mateusz Konieczny wrote: > 7. Jun 2018 19:25 by selfishseaho...@gmail.com: > >> Sorry, I didn't mean to deprecate landuse=forest. What I meant is: >> what prevents us from fixing bad choices? > > > It depends. Can you be more precise what you specifically mean by this?

Re: [Tagging] The endless debate about "landcover" as a top-level tag

On 7 June 2018 at 18:41, Mateusz Konieczny wrote: > I responded to "what's wrong with getting rid of these bad choices?" > > I see nothing wrong with using landcover=trees. > > But in context of this discussion I understood "bad choices" as > landuse=forest. Sorry, I didn't mean to deprecate

Re: [Tagging] The endless debate about "landcover" as a top-level tag

On 7 June 2018 at 10:46, Christoph Hormann wrote: > There are tons of established tags in OSM where the key makes no sense > at all. Don't get me started on 'waterway' for example. But that is > how OSM works. Get over it, accept that people have made bad choices > of keys when choosing tags

Re: [Tagging] Seasonal, intermittent, and ephemeral water tags

On 28 May 2018 at 17:51, Mateusz Konieczny wrote: > You may dislike this tagging scheme but seasonal=yes + intermittent=yes > > is not unclear. > > > It means that > > - presence is not pernament > > - presence is seasonal You are right. Stupid me ...

Re: [Tagging] Seasonal, intermittent, and ephemeral water tags

On 26 May 2018 at 15:27, Tod Fitch wrote: > ... So something like > > waterway=* (or natural=spring | water ) > presence=perennial | seasonal | intermittent | ephemeral > > If the presence is seasonal, then the existing seasonal=* could be used to > describe what times of

Re: [Tagging] Sample tagging for highways with no lane markings

On 23 May 2018 at 08:07, José G Moya Y. wrote: > @Martin:I don't want to be a troll, but I feel there is some inconsistence > between answers in this thread and answers in cycle:lanes last week. Exactly. I too prefer to not dilute the current definition of the lanes key

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

On 19 May 2018 at 21:20, Martin Koppenhoefer wrote: > route=walking_bus? > that’s duck tagging, simple and concise, and is easy to understand for who > knows the concept. +1 ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

I don't mean that they shouldn't be mapped but that I'd rather not use the public transport scheme for it. On 6 May 2018 at 10:53, Erkin Alp Güney <erkinalp9...@gmail.com> wrote: > What about foot tram routes? Should they be mapped? > > > 06-05-2018 11:51 tarihinde Selfish Sea

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

Hi, Like Martin, I think the public transport scheme should not be used here, because a walking bus is neither a form of transport nor is it really public. On 6 May 2018 at 09:45, Lorenzo Stucchi wrote: > Hi, > I’m sorry for the error that I made using the old

Re: [Tagging] Outdoor deckchairs

In my opinion, (sun)loungers are something different form benches, as they are designed to lie on, not to sit on. Besides, tagging them amenity=bench + bench:type=lounger would mean we need another bench:type for real benches. Instead, I suggest amenity=lounger.

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

a sidewalk. On 30 March 2018 at 17:30, Martin Koppenhoefer <dieterdre...@gmail.com> wrote: > > > sent from a phone > >> On 30. Mar 2018, at 11:06, Selfish Seahorse <selfishseaho...@gmail.com> >> wrote: >> >> Furthermore, >> double t

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

ransport=platform to these ways, but as it creates >> confusion with the platform NODES, which as far as I am concerned represent >> the bus and tram stops, I stopped doing that. >> >> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/PT_Assistan >> t/Mapping_Public_Transpo

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

a platform). Otherwise, we say that there are two physical structures, which is wrong. On 30 March 2018 at 19:41, "Christian Müller" <cmu...@gmx.de> wrote: >> Gesendet: Freitag, 30. März 2018 um 11:06 Uhr >> Von: "Selfish Seahorse" <selfishseaho...@gmail.com>

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

is ground situation. >> >> I wouldn't call a sidewalk a platform, especially because the waiting >> area on the sidewalk often isn't clearly delimited. Furthermore, >> double tagging doesn't work if the sidewalk is called 'X Road' and the >> bus stop 'Y Square'. >> &

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

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

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

le tagging doesn't work if the sidewalk is called 'X Road' and the bus stop 'Y Square'. On 29 March 2018 at 23:17, "Christian Müller" <cmu...@gmx.de> wrote: >> Sent: Thu, 29 Mar 2018 19:55:34 +0200 >> From: "Selfish Seahorse" <selfishseaho...@gmail.com>

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

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

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

gmail.com> > 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): &

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 <selfishseaho...@gmail.com> wrote: >> It seems th

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

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

ecially if bus routes change. > > ID is not the greatest too for the job either, so not everyone will spin up > JOSM to edit bus routes > > On Wed, Mar 28, 2018, 6:21 PM Selfish Seahorse, <selfishseaho...@gmail.com> > wrote: >> >> > In my opinion, PTv2 is too compli

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

> In my opinion, PTv2 is too complicated, time-consuming and delicate, ... Sorry, I've meant inefficient, not time-consuming. On 29 March 2018 at 00:13, Selfish Seahorse <selfishseaho...@gmail.com> wrote: >> Many people were involved creating those tags, they are

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

> Many people were involved creating those tags, they are well understood and > discriminate the features they describe in a thoroughly documented and > plausible way. Apparently these tags aren't that well understood: I rarely encounter a PTv2 route that doesn't have at least one tagging error

Re: [Tagging] railway=platform nodes at tram stops

y to define that there is no platform. > maybe a better value should be "embarkation point" but it's "too late" > to change a so common value. Why not just 'stop'? It's never too late to correct a mistake ... On 20 February 2018 at 22:11, marc marc <marc_marc_...@hot

Re: [Tagging] railway=platform nodes at tram stops

]: <https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform> [^2]: <https://wiki.openstreetmap.org/wiki/Tag:railway%3Dplatform> On 20 February 2018 at 21:30, Kevin Kenny <kevin.b.kenny+...@gmail.com> wrote: > On Tue, Feb 20, 2018 at 3:17 PM, Selfish Seahorse >

[Tagging] railway=platform nodes at tram stops

Hello iD's new 'Tram Stop / Platform' preset adds a `railway=platform` tag even on nodes. I thought this were a bug [^1], but the wiki [^2] says: > platforms: `public_transport=platform` + `railway=platform` If the platform > is just a pole with a sign and the tram stops on the road without a

Re: [Tagging] Default values for residential roads and living streets

ult value. On 12 February 2018 at 22:16, marc marc <marc_marc_...@hotmail.com> wrote: > Hello, > > Le 12. 02. 18 à 22:02, Selfish Seahorse a écrit : >> There were quite a few additions of cycleway:both=no and lanes=1 tags >> to residential roads and living streets rece

Re: [Tagging] Default values for residential roads and living streets

> Nearly all the residential roads in my part of the world should default to > lanes=2. OK, I didn't know that (this is why I asked). Thanks for your reply! On 12 February 2018 at 22:09, Tod Fitch <t...@fitchdesign.com> wrote: > >> On Feb 12, 2018, at 1:02 PM, Selfish S

[Tagging] Default values for residential roads and living streets

Hi There were quite a few additions of cycleway:both=no and lanes=1 tags to residential roads and living streets recently, which makes me wonder if it might make sense to define cycleway:both=no and lanes=1 as default values for highway=residential and highway=living_street on the wiki. What do

Re: [Tagging] How to tag sports halls?

018 09:20, Selfish Seahorse wrote: >>> >>> IMHO we should suggest both, building=sports_hall for any sports hall >>> building and leisure=sports_hall if it is also used as a sports hall. >> >> This seems to be a good idea to me. >> > We can sugge

Re: [Tagging] How to tag sports halls?

> IMHO we should suggest both, building=sports_hall for any sports hall > building and leisure=sports_hall if it is also used as a sports hall. This seems to be a good idea to me. > I agree with restricting the usage of leisure=sports_centre to sports centres. +1 This is what I wrote back in

Re: [Tagging] Water source types

now if he can easily drink or fill a bottle or connect a hose etc.. >> >> Quality of water would be : drinking_water=yes/no; mineral_water=yes/no >> >> >> De : Selfish Seahorse <selfishseaho...@gmail.com> >> Envoyé : mercredi

Re: [Tagging] Water source types

On 10 January 2018 at 01:49, Daniel Koć wrote: > I would say that amenity=drinking_water is a general source of the high > quality water and it would be good to make it more specific if possible - > adding tap, well and pump tags would be nice. Because drinking water is a

Re: [Tagging] route/forward/backward members in all types of routes

On 9 January 2018 at 19:57, Fernando Trebien wrote: > I was about to fix a mistake I caused in the map due to these > contradictions in the wiki, then I found a problematic case [1]. > > According to PTv2, this route needs to be broken into two, one per > direction,

Re: [Tagging] Kerbs

the > incline, and how much does it matter? Does a kerb=* node imply that a > footway should be split, and the two ways it connects to should (ideally) > have separate incline=* tags? I prefer that last option, personally. Plus, > it would benefit from adding a separate curb ramp tag for a

Re: [Tagging] Kerbs

ll get a lot of very different complaints, both > about not having enough possible routes ('I don't care about curb ramps, > just tell me where big displacements and driveways are') and also too many > ('I can't handle 8 cm displacements, and this rolled curb kept me from > making my tri

Re: [Tagging] Kerbs

On 29 December 2017 at 01:41, Warin <61sundow...@gmail.com> wrote: > kerb:shape=* would be better as it suggests what is to be tagged. Thus, `kerb=*` values could be replaced with: * `mountable`: mountable for wheelchairs and vehicles * `semi-mountable`: not mountable for wheelchairs but

Re: [Tagging] Kerbs

On 29 December 2017 at 00:32, Nick Bolten wrote: > That's a really great example of how it may make sense to separate out the > idea of a 'curb ramp' from the curb interface. I might have to steal it! Maybe `kerb=ramp`, leaving `kerb=lowered` for kerbs of low height? @Warin:

Re: [Tagging] Kerbs

On 28 December 2017 at 23:50, Nick Bolten wrote: > With that said, I agree that there are opportunities for improving `kerb` > tags. Here are some ideas to toss around: > > - `kerb=square` would seem to be as descriptive as `kerb=raised`, but more > clear. > > - `barrier=kerb`

Re: [Tagging] Kerbs

I agree that `kerb:height` is more useful than `kerb`. However, `kerb` seems to be a good starting point when mapping many kerbs and you can't measure them all yet, as it gives a rough information whether most wheelchair users can cross the street there or not. The question is: does it make sense

Re: [Tagging] Kerbs

On 28 December 2017 at 20:29, Martin Koppenhoefer wrote: > I think it makes a difference to many wheelchair users or cyclists or > automobilists or most other vehicles and pedestrians whether the kerb is 12 > or 30 centimeters (assuming that meters was a typo, right?).

[Tagging] Fountains

Hello It seems that there is some disagreement whether `amenity=fountain` is the appropriate tag for some type of fountains where the water isn't jet into the air but runs out of a pipe (example[^1], tagged `amenity=fountain` like all such fountains in Bern). Originally, such fountains were

Re: [Tagging] sidewalk unsuitable for wheelchair

On 11 December 2017 at 17:11, Tobias Knerr wrote: > What's needed is a direct relationship between one road segment and the > one or two sidewalk segments that belong to it. Grouping a large number > of segments that happen to share the same name does not help, no matter >

Re: [Tagging] sidewalk unsuitable for wheelchair

On 10 December 2017 at 21:19, Tobias Knerr wrote: > Unfortunately, this breaks the semantic relationship between sidewalks > and the rest of the road ("this section of sidewalk belongs to that road > section"). Many applications do need that relationship, and it's pretty >

Re: [Tagging] Deprecating of leisure=common and leisure=village_green

Hello On 7 December 2017 at 17:34, Marc Zoutendijk wrote: > My view (and not mine only, read the discussion) is that a wiki should > describe how a tag _is_used_ and not how it should be used. Ideally, how tags *are* used and *should* be used should be the same. For our

Re: [Tagging] a tag for "really-really-freestores"

Martin Koppenhoefer wrote: > the obvious proposal would be > amenity=freeshop or give-away_shop or sth similar, if you want to avoid the > shop key. Good idea! That seems to make more sense than shop=*. > Maybe I'm wrong (English not my first language), but I thought a

Re: [Tagging] a tag for "really-really-freestores"

Hi On 4 December 2017 at 16:52, thomas schwaerzler wrote: > sounds logic. but i would like to have something that distiinguish those > "shops" clearly from a usual shop. Maybe shop=give-away? ___ Tagging mailing list

Re: [Tagging] Road barrier

On 28 November 2017 at 19:32, José G Moya Y. wrote: > This response makes me wonder if there is a way to mark the "thermoking not > allowed to park" sign I've read in some gas station truck parkings. I couldn't find a temperature control tag or any similar tag in taginfo

Re: [Tagging] Road barrier

On 28 November 2017 at 12:58, Simon Poole wrote: > In general the access categories and rules for "traffic at rest" are > different, than for moving traffic. > > As to sign C, 3a (Vienna convention), the OSM access wiki page is a bit > unclear in that it doesn't clearly state that

Re: [Tagging] Road barrier

On 28 November 2017 at 11:26, Georg Feddern wrote: > Yes, unfortunately the european common-in-use traffic sign "VEHICLES > PROHIBITED EXCEPT MOTORBIKE/SIDECAR" or "Prohibited for any double-tracked > motor vehicles" has no equivalent in the OSM access scheme. > I think it

Re: [Tagging] Road barrier

Sorry for asking again, but does anyone know if motorcar=no implies that there is no access for all multi-track motor vehicles or only for motorcars? Thanks ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Road barrier

On 25 November 2017 at 00:24, marc marc wrote: > This sign doesn't block mofa. I tag this as : motorcar=no motorcycle=no > > Depending of your country, rules may be different ( some use > motor_vehicle=no mofa=yes ) Does motorcar=no imply 'no' for all multi-track motor

[Tagging] Road barrier

Hi How is this kind of road barrier that prevents access for motor vehicles but allows pedestrians and cyclists to pass on both sides best tagged? Is barrier = yes (+ bicycle = yes + foot = yes + motor_vehicle = no) enough information

Re: [Tagging] Swimming pool facilities

BTW, please have a look at how dictionaries define 'sports centre': * a building where the public can go to play many different kinds of sports, swim, etc. (Oxford Advanced Learner's Dictionary) * a building where you can play different sports (Cambridge Advanced Learner’s Dictionary & Thesaurus)

Re: [Tagging] Swimming pool facilities

On 26 September 2017 at 16:52, Kevin Kenny wrote: > There's ample reason for mapping private swimming pools, so I > take issue with "makes no sense at all". How else are you going to > indicate to fire fighters that there is a swimming pool on the premises > (both as

Re: [Tagging] Swimming pool facilities

Even if all private swimming pool facilities were tagged with access=private, leisure=swimming_pool isn't suitable as POI, because (1) pools of thermal baths and water parks are also tagged as swimming_pool, (2) indoor swimming pools seem not to be tagged, and (3) there is usually more than one

Re: [Tagging] Swimming pool facilities

Hi Yes, that's a pity. My main interest in introducing a new tag was to make it possible to find nearby public swimming pool facilities with an OSM based app like Maps.me or skobbler.com. At present, with leisure=swimming_pool used for the water area only and many private pools tagged with it

[Tagging] Swimming pool facilities

Hi everyone The current situation of how public outdoor and indoor swimming pool facilities are tagged is not ideal. There is no dedicated tag, so they are all tagged differently: e.g. as water parks, sports centres, swimming pools, recreation grounds or parks. However, these tags all define

[Tagging] Swimming pool facilities

Hi everyone The current situation of how public outdoor and indoor swimming pool facilities are tagged is not ideal. There is no dedicated tag, so they are all tagged differently: e.g. as water parks, sports centres, swimming pools, recreation grounds or parks. However, these tags all define