Re: [Tagging] Carpet hangers

[Tom Pfeifer]

Which is strange, since the beater is the instrument you keep at home:
https://en.wikipedia.org/wiki/Carpet_beater

On 31.03.2018 18:45, Mateusz Konieczny wrote:

It seems that amenity=beater is the most popular tagging (at least it was when 
I was checking it).

On Sat, 31 Mar 2018, 18:12 Tomasz Wójcik, mailto:tom...@wp.pl>> 
wrote:

You may don't know about this, but in central and eastern--Europe
countries there are outdoor carpet hangers for cleaning them before
holidays.

https://en.wikipedia.org/wiki/Carpet_hanger


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

Re: [Tagging] Carpet hangers

[Mateusz Konieczny]

It may be an attempt to translate word "trzepak".

On Sun, 1 Apr 2018, 11:05 Tom Pfeifer,  wrote:

> Which is strange, since the beater is the instrument you keep at home:
> https://en.wikipedia.org/wiki/Carpet_beater
>
> On 31.03.2018 18:45, Mateusz Konieczny wrote:
> > It seems that amenity=beater is the most popular tagging (at least it
> was when I was checking it).
> >
> > On Sat, 31 Mar 2018, 18:12 Tomasz Wójcik,  tom...@wp.pl>> wrote:
> >
> > You may don't know about this, but in central and eastern--Europe
> > countries there are outdoor carpet hangers for cleaning them before
> > holidays.
> >
> > https://en.wikipedia.org/wiki/Carpet_hanger
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Attendant on amenity=fuel

[Paul Johnson]

On Sat, Mar 31, 2018 at 5:48 PM,  wrote:

> There is also an automated key mentioned on the wiki.
>
>
>
> This applies mostly to self_service I would guess, and I assumed
> automated=yes indicates that you can pay at the pump.
>
>
>
> I didn’t mention the following because taginfo showed that it’s not used
> and there pretty surely is no software support for them yet, but I agree
> with marc that it would make sense to extend the allowed values from
> yes/no.
>
>
>
> I think two additional values would make sense: only (=yes, and only this)
> and optional (=yes, but alternatives exist). They are basically both more
> specific versions of “yes”.
>
>
>
> If we are not going to define completely new keys, I would suggest keeping
> both self_service and full_service, but with the extended values you can
> get away with only defining one of the two.
>
>
>
> e.g.
>
>
>
> self_service=optional (implies full_service=optional)
>
> full_service=only (implies self_service=no)
>

It should be noted that minimum service is where they just pump the gas
(and they might wash your windows if it's slow and they're bored).  Full
service, they also check your fluids and top off what's low a discounted
rate or no extra charge.  Additionally, minimum service is cheaper than
self service, full service tends to be the same price or more expensive
than self service.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Selfish Seahorse]

Having two *=platform tags per bus/tram stop doesn't make public transport
tagging more straightforward in my opinion.

Either PTv1 + line variants or PTv2 - stop position + waiting area seems to
achieve this goal better.

On Saturday, March 31, 2018, Johnparis  wrote:

> I independently reached a conclusion similar to Jo's. No need for a
> separate tag; the difference is made clear when you look at whether it's a
> node, way or area. And there are lots of optional tags to indicate
> structural elements like benches, shelters, tactile pavement, etc.
>
> I don't usually go beyond platform nodes, but if others have tagged
> wait-point ways/areas as public_transport=platform (or highway=platform, or
> even highway=pedestrian), I let them be.
>
> The conclusion I'm reaching (for bus routes, anyhow) is that only platform
> nodes should be included in the relations (along with the ways that
> comprise the routes). In particular, platforms that are ways or areas
> should not be included in the relations, nor should stop positions. (All of
> these could be included in stop area relations.)
>
> This implies the following changes to v2:
>
> 1) every platform node should have mandatory {mode}=yes tag(s)
> 2) stop_positions should be optional on the map and should not be included
> in the route relations
>
> I'm inclined to agree with the wiki that the v1 tags on nodes should
> remain (including the two million highway=bus_stop tags).
>
> I don't really see a big advantage in changing the value of the v2 tag
> from public_transport=platform to something like public_transport=wait_area
> (and there are about one million public_transport=platform tags at the
> moment).
>
> John
>
> On Sat, Mar 31, 2018 at 9:46 AM, Jo  wrote:
>
>> highway=platform and railway=platform on a WAY or an AREA are perfectly
>> fine tags for such platforms, where they exist. Until about a year ago I
>> was also adding public_transport=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_Transport_with_JOSM
>>
>> Jo
>>
>> 2018-03-31 9:23 GMT+02:00 Selfish Seahorse :
>>
>>> Is public_transport=platform now about the structure or the function?
>>>
>>> If it is about the function, then we need a separate tag for the
>>> platform structure.
>>>
>>> If it is about the structure, then we should decide to either map the
>>> sidewalk or public_transport=platform (depending on how we define a
>>> platform). Otherwise, we say that there are two physical structures,
>>> which is wrong.
>>>
>>> On 30 March 2018 at 19:41, "Christian Müller"  wrote:
>>> >> Gesendet: Freitag, 30. März 2018 um 11:06 Uhr
>>> >> Von: "Selfish Seahorse" 
>>> >> An: "Tag discussion, strategy and related tools" <
>>> tagging@openstreetmap.org>
>>> >> Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms
>>> >>
>>> >> 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'.
>>> >>
>>> >
>>> > If a sidewalk _functions_ as a platform, than you can indeed call that
>>> > part of the sidewalk a platform, depending on which role of the area
>>> > you are currently talking about.  This is time-dependent:
>>> >
>>> > If lots of people are standing and waiting on that sidewalk for a
>>> > vehicle to arrive, it will be easier for you to see why this is (also)
>>> > a platform, than e.g. at night time without a PT service serving the
>>> > halt.
>>> >
>>> > A thing as simple as a box may be used as a table or chair.  This is
>>> > the same thing here.  You have a physical structure that is so simple
>>> > that it may function as a platform or a sidewalk, depending on current
>>> > use.
>>> >
>>> >
>>> > Greetings
>>> > cmuelle8
>>> >
>>> > ___
>>> > Tagging mailing list
>>> > Tagging@openstreetmap.org
>>> > https://lists.openstreetmap.org/listinfo/tagging
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>>
>> ___
>> 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] Clarificarions for highway=speed_camera

[Nelson A. de Oliveira]

Sometimes some doubts about highway=speed_camera arise here in Brazil.

The most recent discussion is about:

1) In iD "speed camera" was translated as "speed sensor" in Portuguese
and some people are mapping where the ground sensor (which detects the
vehicle) is located at the road, instead understading and mapping it
as the camera device itself.

For me it's just necessary to fix the translation, but to solve this
doubt, "speed camera" means *only* the camera device?
ie, this device at the right side
https://wiki.openstreetmap.org/w/images/7/7c/Speed_camera.jpg

People usually understand it as an object that summarizes a group of
ground sensors + radar + camera.

2) For simplicity¹ people are mapping speed cameras as a node at the
highway. I won't discuss this here, but a related problem with this
is: they are starting to use the "direction" key to specify which side
the speed camera applies to, when used in a two-way street.
ie, direction=forward if the enforcement applies only to the same
direction as the highway way, direction=backward if it applies to the
opposite direction and direction=both, if the enforcement applies to
vehicles in both directions.

¹ simplicity = not knowing/wanting to use an enforcement relation

Their arguments in favor of using direction like this:
- it's simple to map (since people will not have to use an enforcement relation)
- it should work exactly like highway=stop's direction (where it
represents the way direction that the stop applies to)

But what I see:
- it is ambiguous: it means where the camera is pointing to or it
means the direction that it applies too?
- it changes the semantics of "direction"; ie, if we map a speed
camera with direction=forward meaning "the enforcement applies only to
the same direction of the way", then how we are going to represent the
direction the camera is pointing?
- we already have enforcement relations to represent the direction
that the enforcement applies (the direction key will then duplicate
the same kind of information from the relation).


On Jan 31 we had the number of highway=speed_camera +
direction=forward|backward|both as:

Global: 85
Brazil: 28 (32.94% of total)

On Mar 29 we had:

Global: 103
Brasil: 41 (39.8% of total)

And today (April 1):

Global:
highway=speed_camera + direction=forward|backward|both: 116
highway=speed_camera + other value for direction: 635
highway=speed_camera without direction: 31196

Brazil:
highway=speed_camera + direction=forward|backward|both: 55 (47.41% of total)
highway=speed_camera + other value for direction: 261 (41.10%)
highway=speed_camera without direction: 2998 (9.61%)


So it seems that this kind of "direction" usage is quickly growing here.


I have also included some common doubts at
https://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dspeed_camera#Clarifications_about_common_doubts_and_how_people_view_speed_camera


Comments, please?

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

[Tagging] Coastal beach definition for mapping.

[Warin]

The present OSM wiki defintion for beach

is "Coastal beaches should be mapped down to the mean high water spring line (natural =coastline 
)"


(from https://wiki.openstreetmap.org/wiki/Tag:natural=beach)

I think this is incorrect .. they should be mapped past the high water mark to 
the low water mark.

I see a beach as the place where the sea meets the land .. and that includes 
the bit between hi and low water .. even the extremes of hi and low.

References

https://en.wikipedia.org/wiki/Beach

https://en.oxforddictionaries.com/definition/beach "A pebbly or sandy shore, especially by the sea between high- and 
low-water marks."


Comments? Any that support the high water mark limit I'd be interested 
in seeing.


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

Re: [Tagging] Clarificarions for highway=speed_camera

[Marc Gemis]

As I see it

* highway=speed_camera is only the "device", the camera, not the sensors
* the direction is mapped via the enforcement-relation {1], the from
and to nodes here could be the sensors


[1] https://wiki.openstreetmap.org/wiki/Relation:enforcement


regards

m.

On Mon, Apr 2, 2018 at 3:18 AM, Nelson A. de Oliveira  wrote:
> Sometimes some doubts about highway=speed_camera arise here in Brazil.
>
> The most recent discussion is about:
>
> 1) In iD "speed camera" was translated as "speed sensor" in Portuguese
> and some people are mapping where the ground sensor (which detects the
> vehicle) is located at the road, instead understading and mapping it
> as the camera device itself.
>
> For me it's just necessary to fix the translation, but to solve this
> doubt, "speed camera" means *only* the camera device?
> ie, this device at the right side
> https://wiki.openstreetmap.org/w/images/7/7c/Speed_camera.jpg
>
> People usually understand it as an object that summarizes a group of
> ground sensors + radar + camera.
>
> 2) For simplicity¹ people are mapping speed cameras as a node at the
> highway. I won't discuss this here, but a related problem with this
> is: they are starting to use the "direction" key to specify which side
> the speed camera applies to, when used in a two-way street.
> ie, direction=forward if the enforcement applies only to the same
> direction as the highway way, direction=backward if it applies to the
> opposite direction and direction=both, if the enforcement applies to
> vehicles in both directions.
>
> ¹ simplicity = not knowing/wanting to use an enforcement relation
>
> Their arguments in favor of using direction like this:
> - it's simple to map (since people will not have to use an enforcement 
> relation)
> - it should work exactly like highway=stop's direction (where it
> represents the way direction that the stop applies to)
>
> But what I see:
> - it is ambiguous: it means where the camera is pointing to or it
> means the direction that it applies too?
> - it changes the semantics of "direction"; ie, if we map a speed
> camera with direction=forward meaning "the enforcement applies only to
> the same direction of the way", then how we are going to represent the
> direction the camera is pointing?
> - we already have enforcement relations to represent the direction
> that the enforcement applies (the direction key will then duplicate
> the same kind of information from the relation).
>
>
> On Jan 31 we had the number of highway=speed_camera +
> direction=forward|backward|both as:
>
> Global: 85
> Brazil: 28 (32.94% of total)
>
> On Mar 29 we had:
>
> Global: 103
> Brasil: 41 (39.8% of total)
>
> And today (April 1):
>
> Global:
> highway=speed_camera + direction=forward|backward|both: 116
> highway=speed_camera + other value for direction: 635
> highway=speed_camera without direction: 31196
>
> Brazil:
> highway=speed_camera + direction=forward|backward|both: 55 (47.41% of total)
> highway=speed_camera + other value for direction: 261 (41.10%)
> highway=speed_camera without direction: 2998 (9.61%)
>
>
> So it seems that this kind of "direction" usage is quickly growing here.
>
>
> I have also included some common doubts at
> https://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dspeed_camera#Clarifications_about_common_doubts_and_how_people_view_speed_camera
>
>
> Comments, please?
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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