Re: [Tagging] Attendant on amenity=fuel

sent from a phone > On 30. Mar 2018, at 12:37, > wrote: > > The expectation for the default values of self_serivce and full_service will > probably vary greatly from location to location, so it’s probably best to >

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

> Gesendet: Freitag, 30. März 2018 um 11:29 Uhr > Von: "Selfish Seahorse" > An: "Tag discussion, strategy and related tools" > Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms > > In my opinion, it's never too late to look

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

> Gesendet: Freitag, 30. März 2018 um 11:06 Uhr > Von: "Selfish Seahorse" > An: "Tag discussion, strategy and related tools" > Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms > > I wouldn't call a sidewalk a platform,

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

"wild" platform - the opposite of a built, dedicated platform structure   An example for both:   wild - a road with a grass strip and a PT post stuck in the ground, people have to use the grass strip; over time it may have an "upgrade" using fine gravel to compensate for the dirt revealed

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

sent from a phone > On 30. Mar 2018, at 11:06, Selfish Seahorse wrote: > > Furthermore, > double tagging doesn't work if the sidewalk is called 'X Road' and the > bus stop 'Y Square'. in this case you’ll have a platform object and a sidewalk object that happen to

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

sent from a phone > On 30. Mar 2018, at 08:56, Johnparis wrote: > > > As has been noted elsewhere, public_transport=platform was probably not an > ideal word choice, perhaps wait_area or some such would have been better, but > it is what it is. according to a

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

I rarely do public transport tagging but found that using the new tag for a bus stop did not render so I had to add the old version of the tag to render. I may be in error here due to not being very familiar with the transport schemes. You may call that tagging for the renderer but i see very

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

sent from a phone > On 29. Mar 2018, at 09:37, Topographe Fou wrote: > > One thing I never understood was why we have to maintain two schemas > (probably because consensus was not reached) it is generally hard in OSM to declare something as better, hence we

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

sent from a phone > On 29. Mar 2018, at 03:56, Daniel Koć wrote: > > Double tagging is a problem too can you please explain what you mean with “double tagging” and what the problem is? cheers, Martin ___ Tagging mailing list

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

I tag the platform as NODE with: highway=bus_stop public_transport=platform bus=yes name= ref= route_ref= zone= ... Because nodes have 1 pair of coordinates, so convenient for direct comparison with external sources and t's easy to draw text around it with an offset in MapCSS in JOSM, If there

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

If I got you right, you map the platform as a public_transport=platform way and add a public_transport=platform node in addition? Why not tag that node public_transport=stop then? This would allow for a clear distinction between platform and stop. On 30 March 2018 at 11:52, Jo

Re: [Tagging] Attendant on amenity=fuel

Based on the information provided here: https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel#Service and what was stated in previous posts on the mailing list, I would guess that the correct tags would be: Only serviced by attendant: self_service=no full_service=yes Self

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

When tagging platforms as ways, I wouldn't add details like name to them, as the name would already be present on the platform node, which represents the stop, both for rendering purposes as for being added to the route relations. I would only map a platform as a way, if there is tactile paving,

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

> And if a tag is needed, stop vs stop_position would surely cause confusion! If we would map a public_transport=stop node regardless of whether there's a platform or not and if only public_transport=stop nodes would be added to route relations then public_transport=stop_position wouldn't be

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

> In this case it is not wrong to tag a fraction of the sidewalk as platform, > there is dual (multipurpose) use in this case. There are several variants, > sometimes the paving stones suggest a dedicated area over full or half of the > width, sometimes not. Since the tags do not conflict

Re: [Tagging] Attendant on amenity=fuel

I understand you can tag "self_service:no" in case of attended fuel stations? As Javier says, disabled people use to need attended fuel stations. In Spain (are you from here, Javier?) some administrative areas (atonomous communities) are moving to enforce attended fuel stations. In other

Re: [Tagging] Attendant on amenity=fuel

On 30 March 2018 08:50:07 BST, "Javier Sánchez Portero" wrote: >El vie., 30 mar. 2018 8:a >I think this is important for disabled drivers to have to go down the >car >to fill or not. > Not really, at self service filling stations the cashier will fill the car for

Re: [Tagging] Attendant on amenity=fuel

El vie., 30 mar. 2018 8:54, escribió: > While it has never been used before, the logical key to me would be > self_service:conditional following the usual rules for conditional keys. > I agree. It will require only a minor change in the conditional restrictions

Re: [Tagging] Attendant on amenity=fuel

While it has never been used before, the logical key to me would be self_service:conditional following the usual rules for conditional keys. At least you can choose during the day if you fuel by your self or not. So I would treat it as not self service during the day. I consider this

Re: [Tagging] Attendant on amenity=fuel

El vie., 30 mar. 2018 8:13, Stephan Knauss escribió: > Hello Dave, > > As this is a thing country specific, people typically expect the norm. So > no need to tag this explicitly. > > Question is how to tag it. > > self_service sounds like the right key to tag exceptions

Re: [Tagging] Attendant on amenity=fuel

Hello Dave, As this is a thing country specific, people typically expect the norm. So no need to tag this explicitly. Question is how to tag it. self_service sounds like the right key to tag exceptions from the norm. It can also be used with the same meaning for example for car wash. These

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

Heh, never noticed that. iD is now automatically putting bus=yes on the platform node, which seems clearly correct. The proposal page should be amended, I think. On Thu, Mar 29, 2018 at 12:33 PM, Selfish Seahorse < selfishseaho...@gmail.com> wrote: > > It seems that one major issue was that,

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

> If this is a problem, because the tag should ideally discrimnate built > structure features, then either > > a) find a new tag for wild platforms Maybe public_transport=stop? On 29 March 2018 at 16:30, "Christian Müller" wrote: > Mapping public transport in detail was in part

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

Thanks for that last point, Christian. Always good to read the documentation! The English version (emphasis mine) reads: These 'traditional' tags are still widely used and are not invalidated by this scheme and ***should be kept*** in order to ensure compatibility with legacy software, at the