Re: [Tagging] Request for Discussion - Drying_room or Drying_area

[Warin]

On 11-Mar-17 05:13 PM, Yves wrote:
Of course in an hotel there is not much confusion possible with 
agricultural purposes , however why not clothes_drying if 'area' is 
used in the tag?


Some dry tents, at least I do. I can see some drying backpacks, sleeping 
bags.. mine are usually dry.




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

Re: [Tagging] Request for Discussion - Drying_room or Drying_area

[Yves]

Of course in an hotel there is not much confusion possible with agricultural 
purposes , however why not clothes_drying if 'area' is used in the tag? 
Yves ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Request for Discussion - Drying_room or Drying_area

[Warin]

On 11-Mar-17 01:25 PM, Thilo Haug wrote:


O.k., I see, in case of drying_room it doesn't work.

Perhaps:
drying:room=yes/no/heated
drying:compartment=yes/no/heated
drying:dryer=convection/inertised/microwave
(leaves the possibility to add more "drying" stuff if needed ?).



Don't think that level of detail is necessary.
If you needed to know the size then the length/height/width keys could 
be used

drying_area:length=1 etc




__

Regarding the sports :

How about the other "services", those should be "sport-specific" ?
http://wiki.openstreetmap.org/wiki/Tag:shop%3Dbicycle#Additional_keys



The bicycle service keys .. I don't think were ever approved .. just the 
shop=bicycle.



motorcycle:tools=yes
bicycle:tools=yes
skiing:tools=yes

motorcycle:tours=guided/info
bicycle::tours=guided/info
skiing:tours=guided/info

There's one thing I'm not quite sure about, that's
motorcycle:parking=yes
(I know that there's amenity=motorcycle_parking, but this doesn't work 
on accommodations,

as there's often amenity=restaurant/bar etc. included)
So I see it similar to beer_garden (which is separately mapped) and 
outdoor_seating=yes (combined with the accommodation).



Getting a bit off the topic? Would need more thought time.


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

Re: [Tagging] Request for Discussion - Drying_room or Drying_area

[Thilo Haug]

O.k., I see, in case of drying_room it doesn't work.

Perhaps:
drying:room=yes/no/heated
drying:compartment=yes/no/heated
drying:dryer=convection/inertised/microwave
(leaves the possibility to add more "drying" stuff if needed ?).

__

Regarding the sports :

How about the other "services", those should be "sport-specific" ?
http://wiki.openstreetmap.org/wiki/Tag:shop%3Dbicycle#Additional_keys

motorcycle:tools=yes
bicycle:tools=yes
skiing:tools=yes

motorcycle:tours=guided/info
bicycle::tours=guided/info
skiing:tours=guided/info

There's one thing I'm not quite sure about, that's
motorcycle:parking=yes
(I know that there's amenity=motorcycle_parking, but this doesn't work
on accommodations,
as there's often amenity=restaurant/bar etc. included)
So I see it similar to beer_garden (which is separately mapped) and
outdoor_seating=yes (combined with the accommodation).

Possibly
motorcycle:storage=garage/court
bicycle::storage=garage/court
skiing:storage=room/court

?
__


Am 11.03.2017 um 02:49 schrieb Warin:
> We do not tag
>
> motorcycle:tourism=hotel
> bicycle:tourism=hotel
> skiing:tourism=hotel
> hiking:tourism=hotel
>
> where they are all used by the same activities even the general
> public, we simply tag the singular feature tourism=hotel.
>
> nor do we tag
>
> motorcycle:internet_access=yes
> bicycle:internet_access=yes
> skiing:internet_access=yes
> hiking:internet_access=yes
>
> where they are all used by the same activities even the general
> public, we simply tag the singular property internet_access=yes.
>
> Same for drying rooms ... all used by anyone who has access, so only
> tagged once.
>
>
> On 11-Mar-17 12:33 PM, Thilo Haug wrote:
>>
>> That's what I meant with
>> "same for bicycle/skiing/hiking etc.".
>>
>> skiing:drying=heated
>>
>> This naming system is used by
>> addr:*=*
>> http://wiki.openstreetmap.org/wiki/Key:addr#Commonly_used_subkeys
>> contact:*=*
>> http://wiki.openstreetmap.org/wiki/Key:contact
>>
>
> Each of these are different properties ... not the same property used
> for different activities.
>>
>> And bicycle has an (undocumented) similar system :
>> http://wiki.openstreetmap.org/wiki/Tag:shop%3Dbicycle#Additional_keys
>> (I think the service: part could be left out, as I can't see the
>> advantage)
>>
>>
>> Am 11.03.2017 um 02:19 schrieb Warin:
>>> Err this will be a separate key
>>> I think of it more as a property key .. like internet_access 
>>> ? 
>>> Consider that these are not only attractive to motorcyclists but also to 
>>> hikers, bicyclist, canoeists, canyoners, skiers ...  
>>> anyone with wet gear. There is noting specific to any drying room/area that 
>>> I have seen that limits it to motorcyclists only. 
>>> so 
>>> tourism=hotel
>>> drying_area=yes
>>> phone=23421 543453
>>> website=idon'tknow.ups 
>>> I suppose the values could be 
>>> drying_area=yes/no/heated/? 
>>>
>>>
>>> 
>>> My thinking on the room vs area .. some are too small to be called a 
>>> 'room', 
>>> others can be used for other things like parking vehicles too. 
>>>
>>>
>>> On 11-Mar-17 11:51 AM, Thilo Haug wrote:
 Hi,

 you're right, it doesn't have to be a separate room,
 but how about :

 motorcycle:drying=room/area/compartment ?

 (same for bicycle/skiing/hiking etc.)

 Cheers,
 Thilo

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

-- 

Thilo Haug
Bismarckstr.37
72764 Reutlingen

Mobil: +49 177 3185856

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

Re: [Tagging] Request for Discussion - Drying_room or Drying_area

[Thilo Haug]

That's what I meant with
"same for bicycle/skiing/hiking etc.".

skiing:drying=heated

This naming system is used by
addr:*=*
http://wiki.openstreetmap.org/wiki/Key:addr#Commonly_used_subkeys
contact:*=*
http://wiki.openstreetmap.org/wiki/Key:contact

And bicycle has an (undocumented) similar system :
http://wiki.openstreetmap.org/wiki/Tag:shop%3Dbicycle#Additional_keys
(I think the service: part could be left out, as I can't see the advantage)


Am 11.03.2017 um 02:19 schrieb Warin:
> Err this will be a separate key
> I think of it more as a property key .. like internet_access 
> ? 
> Consider that these are not only attractive to motorcyclists but also to 
> hikers, bicyclist, canoeists, canyoners, skiers ...  
> anyone with wet gear. There is noting specific to any drying room/area that I 
> have seen that limits it to motorcyclists only. 
> so 
> tourism=hotel
> drying_area=yes
> phone=23421 543453
> website=idon'tknow.ups 
> I suppose the values could be 
> drying_area=yes/no/heated/? 
>
>
> 
> My thinking on the room vs area .. some are too small to be called a 'room', 
> others can be used for other things like parking vehicles too. 
>
>
> On 11-Mar-17 11:51 AM, Thilo Haug wrote:
>> Hi,
>>
>> you're right, it doesn't have to be a separate room,
>> but how about :
>>
>> motorcycle:drying=room/area/compartment ?
>>
>> (same for bicycle/skiing/hiking etc.)
>>
>> Cheers,
>> Thilo
>>
>>
>> Am 11.03.2017 um 01:37 schrieb Warin:
>>> Hi,
>>>
>>> Following on from the 'friendly:*=*' discussion there appears to be a
>>> desire to tag the property of a drying_room for some physical features.
>>>
>>>
>>> But I think some of these 'rooms' .. don't meet a strict definition of
>>> a 'room'?
>>>
>>>
>>> So would it be preferable to use 'drying_area' as a key value for this
>>> proposal?
>>>
>>>
>>> Thoughts?
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

-- 

Thilo Haug
Bismarckstr.37
72764 Reutlingen

Mobil: +49 177 3185856

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

Re: [Tagging] Request for Discussion - Drying_room or Drying_area

[Warin]

Err this will be a separate key
I think of it more as a property key .. likeinternet_access 
?
Consider that these are not only attractive to motorcyclists but also to 
hikers, bicyclist, canoeists, canyoners, skiers ...
anyone with wet gear. There is noting specific to any drying room/area that I 
have seen that limits it to motorcyclists only.

so

tourism=hotel

drying_area=yes

phone=23421 543453

website=idon'tknow.ups

I suppose the values could be

drying_area=yes/no/heated/?



My thinking on the room vs area .. some are too small to be called a 'room',
others can be used for other things like parking vehicles too.


On 11-Mar-17 11:51 AM, Thilo Haug wrote:

Hi,

you're right, it doesn't have to be a separate room,
but how about :

motorcycle:drying=room/area/compartment ?

(same for bicycle/skiing/hiking etc.)

Cheers,
Thilo


Am 11.03.2017 um 01:37 schrieb Warin:

Hi,

Following on from the 'friendly:*=*' discussion there appears to be a
desire to tag the property of a drying_room for some physical features.


But I think some of these 'rooms' .. don't meet a strict definition of
a 'room'?


So would it be preferable to use 'drying_area' as a key value for this
proposal?


Thoughts?






___
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] Request for Discussion - Drying_room or Drying_area

[Thilo Haug]

Hi,

you're right, it doesn't have to be a separate room,
but how about :

motorcycle:drying=room/area/compartment ?

(same for bicycle/skiing/hiking etc.)

Cheers,
Thilo


Am 11.03.2017 um 01:37 schrieb Warin:
> Hi,
>
> Following on from the 'friendly:*=*' discussion there appears to be a
> desire to tag the property of a drying_room for some physical features.
>
>
> But I think some of these 'rooms' .. don't meet a strict definition of
> a 'room'?
>
>
> So would it be preferable to use 'drying_area' as a key value for this
> proposal?
>
>
> Thoughts?
>
>
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

-- 

Thilo Haug
Bismarckstr.37
72764 Reutlingen

Mobil: +49 177 3185856


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

[Tagging] Request for Discussion - Drying_room or Drying_area

[Warin]

Hi,

Following on from the 'friendly:*=*' discussion there appears to be a 
desire to tag the property of a drying_room for some physical features.



But I think some of these 'rooms' .. don't meet a strict definition of a 
'room'?



So would it be preferable to use 'drying_area' as a key value for this 
proposal?



Thoughts?






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

Re: [Tagging] charging station power output

[Warin]

On 11-Mar-17 05:23 AM, lucas-...@use.startmail.com wrote:


Calculating the max. power is really easy. You just need to know the max. 
amperage (I), the max. voltage (U) and the number of phases (#np) the current 
is delivered in (do you say that?).
p = square_root(#np) * I * U


Measuring AC has a few methods; peak, apparent, ...
but most people are interested in the root mean squared (RMS) values - these 
are equivalent to the DC effects.
Where the AC values contain no information on what measurement method is used 
it is usual to assume that rms has been used.


So a normal Schuko socket would give us roughly square_root(1) * 16A * 230V = 
3,7kW at best.


For RMS calculation; 16 V (rms) * 230 V (rms) = 3.68 kW (rms). [no square root 
required]

I'll ignore the rest until this


What about adopting this scheme like charging_station:output=* to specify the 
max. power output of the whole station, distributed over all available sockets. 
And socket:[socket_type]:output=* to specify the max. power output of one 
specific socket.

An example:
https://upload.wikimedia.org/wikipedia/commons/f/f6/Charging_station_socks.jpg
https://upload.wikimedia.org/wikipedia/commons/4/4a/Charging_station_specs.jpg

charging_station:output=98kW
socket:type2:output=43kW
socket:type2_combo:output=50kW
socket:chademo:output=50kW

As far as I know, these values are always provided on the station itself. On 
the front to inform the user of it’s max. power per socket and on the back 
there’s a specification of the input of the whole station / max. output of all 
sockets.


Socket power:

Most sockets have a stated maximum for any installation no matter where they 
are installed (house, factory, charging station).

I think this will be the same for your charging stations? In other words - this 
does not change in a given distribution area (country).

From this you can determine the minimum recharge time - assuming the maximum 
socket power is available, an optimistic value.

Charging Station Power:

Where a charging station limits the total output power due to the number of 
sockets in use ...

You cannot determine from OSM how many are in use at the moment, nor
how many might be in use in an hours time nor their respective loads (and these 
may well change over time)

 ... so you cannot determine the charge time ... because of the variable number 
of sockets and their power requirements that are in use now and into the future.

So the information maybe of little very real value?

It might be used to determine the maximum charge time ...
 assuming you get the minimum power possible from the charge station, this 
would be a very pessimistic value.


I agree with using *:output=* for tagging .. but see little real world 
application?


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

Re: [Tagging] Undiscussed changes for wki pages about access mode "designated".

[Dalibor Jelínek]

Hello,
I fully aggree that this change is undesirable.

If you want to use an access type key lets say bicycle=* then you go to this 
page for documentation
https://wiki.openstreetmap.org/wiki/Key:bicycle
and you are refered to the Key:access page for values.
And there you see that it is discouraged.
The same is true for all other access keys. They all refer to that page with 
values definitiion.

Dalibor (chrabros)

> -Original Message-
> From: Mariusz [mailto:marius...@gmail.com]
> Sent: Friday, March 10, 2017 8:56 PM
> To: Tag discussion, strategy and related tools 
> Subject: Re: [Tagging] Undiscussed changes for wki pages about access mode
> "designated".
> 
> W dniu 2017-03-10 o 20:25, Frederik Ramm pisze:
> >
> > As far as I can see the change you are referring to is
> >
> >
> https://wiki.openstreetmap.org/w/index.php?title=Key%3Aaccess=re
> v
> > ision=1440112=1439975
> >
> > before that, "access=designated" wasn't even on the "Key:access" page,
> > and Verdy_p added it there:
> >
> > ''(disapproved)'' A preferred or designated route for the class of
> > traffic specified by the tag key, such as {{tag|foot|designated}}.
> > Using this value with the plain access key, {{tag|access|designated}},
> > has no meaning, and should '''not''' be used. ''(see [[#Transport mode
> > restrictions]])''
> 
> This is obviously incorrect change, as this page is about all access keys, not
> single "access" tag.
> The notation he used suggests that the value "designated" is deprecated.
> The wording is inconvenient, the strike-through font for designated is
> misleading.
> 
> > On https://wiki.openstreetmap.org/wiki/Tag:access%3Ddesignated,
> > Verdy_p added a banner saying "NOTE! The exact key/value combination
> > access=designated should never appear on an object. The value
> > *=designated must be used with a specific mode of transport. Examples:
> > bicycle=designated or foot=designated." - he made this change without
> > any change comment.
> >
> > The user rafmar (you?) seems to have assumed that Verdy_p wanted to
> > discourage the use of all "designated" values, but to be fair to
> > Verdy_p, the banner explicitly says you SHOULD use the "designated"
> > value, just not with the "access" key.
> 
> I'm pretty sure he wanted discouraged only "access=designated", not
> foot=designated or bicycle=designated, but he failed.
> Unfortunately, this wiki article is for all *=designated tags, as the
> foot/bicycle/horse tag pages redirect to that page. Some changes are
> necessary, but not that kind.
> 
> > BUT in this particular case, rafmar's complaint seems to be unfounded
> > and based on a misunderstanding.
> 
> Imagine, you are beginner and want to find if it is ok to use foot=designated
> tag. What wiki page says so now?
> 
> Mariusz/rafmar
> 
> 
> ___
> 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] Undiscussed changes for wki pages about access mode "designated".

[Dalibor Jelínek]

Of course it was there, he just moved it to the lower part of the table.

Dalibor (chrabros)

> -Original Message-
> From: Mariusz [mailto:marius...@gmail.com]
> Sent: Friday, March 10, 2017 9:09 PM
> To: Tag discussion, strategy and related tools 
> Subject: Re: [Tagging] Undiscussed changes for wki pages about access mode
> "designated".
> 
> W dniu 2017-03-10 o 20:25, Frederik Ramm pisze:
> > As far as I can see the change you are referring to is
> >
> https://wiki.openstreetmap.org/w/index.php?title=Key%3Aaccess=re
> vision=1440112=1439975
> >
> > before that, "access=designated" wasn't even on the "Key:access" page,
> 
> Certainly it was.
> 
> Mariusz
> 
> 
> ___
> 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] Improve toilet tagging

[Dave Swarthout]

I'm all for simplicity... this discussion is all too sophisticated for me!
+1

Hi Kevin,

Some of these discussions involve the most trivial (IMO) tagging issues.
This one has some merit I suppose but it's obvious to me that some people
have run out of bigger projects and are starting to focus on details

By the way, this is the type of toilet I used for many years in Alaska. But
the first ones I ever saw were in the High Peak region back in the 60s.
That's when hikers still left their garbage in an unsavory pile behind the
lean-tos. The environmental movement was just starting in the U.S. and
we've come a long way since that time. Here in Thailand people still toss
paper and water bottles all over the place. They're about 40-50 years
behind Europe and the U.S. in those sorts of things.

Best,

Dave

On Sat, Mar 11, 2017 at 5:20 AM, Kevin Kenny 
wrote:

> On Fri, Mar 10, 2017 at 4:51 PM, Frederik Ramm 
> wrote:
>
>> I'm wary of tagging too many business details. I fear a toilets
>> namespace would lead to people adding all sorts of observations about
>> toilets that they used in some shop or other and that might at best be
>> access=customers if not access=private. I think this would be going too
>> far, it's almost as if we were to start taggin how wide the isles in a
>> shop were or how many checkout desks or if they stock canned
>> strawberries. I suggest to encourage the recording of details only for
>> toilets that are explicitly public, and not those in restaurants or
>> department stores.
>>
>
> I'm all for simplicity... this discussion is all too sophisticated for me!
> The last amenity=toilets that I tagged looked like this.
> (http://www.openstreetmap.org/node/3649882546)
>
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Improve toilet tagging

[Warin]

On 11-Mar-17 08:51 AM, Frederik Ramm wrote:


Hi,

On 03/10/2017 09:43 PM, Micah Cochran wrote:

#2. Single-stall versus Multi-stall tagging

There's also those male toilets with a discrete number of urinals and
those where you have basically one wall-wide urinal used by as many
people as manage to cram in ;)


There are also discrete urinals with modesty walls to either side.

There are also toilets with urinal/s only (these were termed pissoir).




#3. A way to tag the toilets male/female/unisex within an establishment.

Until SotM Brussels I always assumed that an un-gendered amenity=toilets
would automatically mean there'll be separate facilites for men an
women, and only when accompanied with gender tags would it be limited to
a specific sex. In Brussels there was a talk by a woman from India who -
if I remember correctly - said that she'd usually not consider to even
visit a toilet that was not explicitly marked as having capacity for
women because the "default" over there seems to be it's for men. Which
brings a whole new urgency to gender tagging.


Unisex toilets exist in Japan, open to both sexes.
Some have male urinals alongside the wash basins, there, if you want privacy, 
you would have to use a stall (enclosed single toilet).




#1. toilets: namespace
There could be a default toilets: namespace for when tagged within a
place/establishment.This would allow for tagging a richer level of
toilet information.

I'm wary of tagging too many business details. I fear a toilets
namespace would lead to people adding all sorts of observations about
toilets that they used in some shop or other and that might at best be
access=customers if not access=private. I think this would be going too
far, it's almost as if we were to start taggin how wide the isles in a
shop were or how many checkout desks or if they stock canned
strawberries. I suggest to encourage the recording of details only for
toilets that are explicitly public, and not those in restaurants or
department stores.


Some establishments have no toilet for customers use, that, I view, as very 
poor for any eating establishment.
I would prefer to know that so that I can select another establishment that has 
toilet facilities.



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

Re: [Tagging] Improve toilet tagging

[Kevin Kenny]

On Fri, Mar 10, 2017 at 4:51 PM, Frederik Ramm  wrote:

> I'm wary of tagging too many business details. I fear a toilets
> namespace would lead to people adding all sorts of observations about
> toilets that they used in some shop or other and that might at best be
> access=customers if not access=private. I think this would be going too
> far, it's almost as if we were to start taggin how wide the isles in a
> shop were or how many checkout desks or if they stock canned
> strawberries. I suggest to encourage the recording of details only for
> toilets that are explicitly public, and not those in restaurants or
> department stores.
>

I'm all for simplicity... this discussion is all too sophisticated for me!
The last amenity=toilets that I tagged looked like this.
(http://www.openstreetmap.org/node/3649882546)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Orientation of an adit?

[Tod Fitch]

This is exactly what I was looking for! And I see the wiki for man_made=adit 
was updated today to include mention of the direction tag.

Thanks!


> On Mar 10, 2017, at 6:11 AM, Zecke  wrote:
> 
> Please note that www.historic.place displays the orientation of adits. As it 
> can be seen here:
> http://gk.historic.place/historische_objekte/translate/en/index-en.html?zoom=17=49.27361=6.9515=n2218896180=KmHaSaHe
> 
> We evaluate the direction tag, Please note that the direction is seen from 
> the underground gallery outwards.
> 
> See also:
> http://wiki.openstreetmap.org/wiki/Key:direction
> 
> Regards,
> Carsten
> 
> Am 10.03.2017 um 14:48 schrieb Tod Fitch:
>> There are a number of abandoned adits and mine shafts in an area I’ve done 
>> some mapping in. When looking at old USGS topographic maps of the area, I’ve 
>> noticed that they used to align their symbol for an adit to show its 
>> orientation.
> 



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

Re: [Tagging] Improve toilet tagging

[Frederik Ramm]

Hi,

On 03/10/2017 09:43 PM, Micah Cochran wrote:
> #2. Single-stall versus Multi-stall tagging

There's also those male toilets with a discrete number of urinals and
those where you have basically one wall-wide urinal used by as many
people as manage to cram in ;)

> #3. A way to tag the toilets male/female/unisex within an establishment.

Until SotM Brussels I always assumed that an un-gendered amenity=toilets
would automatically mean there'll be separate facilites for men an
women, and only when accompanied with gender tags would it be limited to
a specific sex. In Brussels there was a talk by a woman from India who -
if I remember correctly - said that she'd usually not consider to even
visit a toilet that was not explicitly marked as having capacity for
women because the "default" over there seems to be it's for men. Which
brings a whole new urgency to gender tagging.

> #1. toilets: namespace
> There could be a default toilets: namespace for when tagged within a
> place/establishment.This would allow for tagging a richer level of
> toilet information.

I'm wary of tagging too many business details. I fear a toilets
namespace would lead to people adding all sorts of observations about
toilets that they used in some shop or other and that might at best be
access=customers if not access=private. I think this would be going too
far, it's almost as if we were to start taggin how wide the isles in a
shop were or how many checkout desks or if they stock canned
strawberries. I suggest to encourage the recording of details only for
toilets that are explicitly public, and not those in restaurants or
department stores.

Bye
Frederik

-- 
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] Orientation of an adit?

[Kevin Kenny]

On Fri, Mar 10, 2017 at 2:52 PM, Mark Wagner  wrote:

> Thing is, the information *isn't* available by other means.  Adits
> don't always go straight in -- of the two I'm aware of, both are at
> rather sharp angles to the (very local) slope of the hill.
>
OK, you've convinced me, and in any case, I was playing
the devil's advocate and anticipating the objections of others.

I still like this approach for cave entrances, small dams (represented
as points), waterfalls on small streams (represented as points), and
other similar features where there is a point feature with a flow
of goods, water, traffic, 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Orientation of an adit?

[Kevin Kenny]

On Fri, Mar 10, 2017 at 2:04 PM, Mike Thompson  wrote:

> On Fri, Mar 10, 2017 at 7:34 AM, Kevin Kenny 
> wrote:
>
>>
>> I can just now hear, nevertheless, a chorus asserting that the
>> information is available by other means and therefore does not belong in
>> OSM. An adit or a cave entrance (that isn't a sinkhole) pretty much has to
>> go into a hillside, and a waterfall or a dam flows downhill, so with
>> information about local topography, the direction can be determined.
>>
> In many parts of the world there may not be elevation data with an open
> license of suitable resolution to make this determination for an adit.
>

Outside the band of 54° S to 60° N, you're certainly right about that.
Within that band, the August 2015 NASA data set is in the public domain and
has coverage at 30 m resolution horizontally. That's probably Not Quite
Good Enough - I get spoilt by the 10 m coverage available for North America.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Improve toilet tagging

[Micah Cochran]

I am looking to improve tagging of toilets.  Specifically, I'm interested
in tagging gender neutral toilets (unisex or "family toilets") and
single-stall toilets.

I'm using establishment  to mean any place that would be tagged that would
have a public toilet within the place and that you would not create a
separate node/area amenity=toilet.  So, public toilets in an
amenity=restaurant or a shop=department_store, etc.

I'm interesting in gather a little more information for toilets within an
establishment.

===  Here are some deficiencies that I see with current toilet tagging
scheme  ===

#1. toilets: namespace for establishments
#2. Single-stall versus Multi-stall tagging
#3. A way to tag the toilets male/female/unisex within an establishment.
#4. Wiki page amenity=toilets could use some example tagging.


=  Proposed ways to address those deficiencies  =

#1. toilets: namespace
There could be a default toilets: namespace for when tagged within a
place/establishment.This would allow for tagging a richer level of
toilet information.

If it makes sense to tag or not, would be left up to the mapper.

There might be a few places that this would have to be smoothed over to
make this work.  (Example: indoor=yes doesn't necessarily make sense.)

Note: The amenity=toilets page does mention the toilets: namespace, but my
understanding is this namespace only applies to very few of the tags.


#2. Single-stall versus Multi-stall tagging

Is the toilet room itself intended to be used by a single person
(single-stall) at a time or by multiple people (multi-stall)?

Is "stall" the term used in British English for that arrangement of
toilets?  Is there better term?  (Alternatively: Single-occupant /
Multi-occupant could be workable.)

Assume that male/female/unisex are all the same.  This could also be an
instance that you are tagging a single restroom area.
toilets:stall=single/multi

This specifies male/female/unisex for that arrangement
toilets:stall:male=single/multi

For example, Target department stores might be tagged this way for male and
female multi-stall toilets and a single-stall unisex toilets:
toilets:stall=multi
toilets:stall:unisex=single

If you have both single-stall and multi-stall restrooms for male/female
(note semi-colon separated for toilet:stall tag) :
toilets:male=yes
toilets:female=yes
toilets:stall=single;multi


toilets:stall tag should work for amenity=toilets and toilets within an
establishment.


#3.  A way to tag the toilets male/female/unisex within an establishment.

This a specific instance of #1 :toilets namespace.  (Just in case, #1 has
issues.)

This is to tag the male/female/unisex of provided restrooms.

male/female tag is used for access to an establishment.  So a men's social
club might use the tag male=yes.  There seem to be some facilities that
have days only for males and other days only for females.

toilets:male=yes/no
toilets:female=yes/no
toilets:unisex=yes/no

If toilets:male=yes it should imply toilets:female=no and
toilets:unisex=no. This is the same behavior as the male=* access tag.


#4. Wiki page amenity=toilets could use some example tagging.
The existing pictures could be used as examples with tags.  Other examples
could be added.

Note: I've seen some other issues regarding toilet tags, but I don't have
the motivation to tackle those.

Any feedback will be helpful and I will use it to inform writing a proposal.

Thank you for your help,
Micah
-- 

*Micah Cochran*

GIS Coordinator  -  City of Athens  -  Engineering Services & Community
Development Dept.  -  Dept. of Public Works Building  -  1600 ELM ST W,
Athens, AL  - geo:34.820608,-86.991474 -  p.
256-233-2224 <(256)%20233-2224>  -  f. 256-233-8791 <(256)%20233-8791> -
www.athensalabama.us
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Undiscussed changes for wki pages about access mode "designated".

[Andy Townsend]

On 10/03/2017 19:36, Yves wrote:
Not saying it's not useful, but at least self-moderation should be 
considered.


I'll try and be tactful here - let's just say that that approach has 
been suggested :)


Best Regards,

Andy


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

Re: [Tagging] Undiscussed changes for wki pages about access mode "designated".

[Mariusz]

W dniu 2017-03-10 o 20:25, Frederik Ramm pisze:

As far as I can see the change you are referring to is
https://wiki.openstreetmap.org/w/index.php?title=Key%3Aaccess=revision=1440112=1439975

before that, "access=designated" wasn't even on the "Key:access" page,


Certainly it was.

Mariusz


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

Re: [Tagging] Undiscussed changes for wki pages about access mode "designated".

[Mariusz]

W dniu 2017-03-10 o 20:25, Frederik Ramm pisze:


As far as I can see the change you are referring to is

https://wiki.openstreetmap.org/w/index.php?title=Key%3Aaccess=revision=1440112=1439975

before that, "access=designated" wasn't even on the "Key:access" page,
and Verdy_p added it there:

''(disapproved)'' A preferred or designated route for the class of
traffic specified by the tag key, such as {{tag|foot|designated}}. Using
this value with the plain access key, {{tag|access|designated}}, has no
meaning, and should '''not''' be used. ''(see [[#Transport mode
restrictions]])''


This is obviously incorrect change, as this page is about all access 
keys, not single "access" tag.

The notation he used suggests that the value "designated" is deprecated.
The wording is inconvenient, the strike-through font for designated is 
misleading.



On https://wiki.openstreetmap.org/wiki/Tag:access%3Ddesignated, Verdy_p
added a banner saying "NOTE! The exact key/value combination
access=designated should never appear on an object. The value
*=designated must be used with a specific mode of transport. Examples:
bicycle=designated or foot=designated." - he made this change without
any change comment.

The user rafmar (you?) seems to have assumed that Verdy_p wanted to
discourage the use of all "designated" values, but to be fair to
Verdy_p, the banner explicitly says you SHOULD use the "designated"
value, just not with the "access" key.


I'm pretty sure he wanted discouraged only "access=designated", not 
foot=designated or bicycle=designated, but he failed.
Unfortunately, this wiki article is for all *=designated tags, as the 
foot/bicycle/horse tag pages redirect to that page. Some changes are 
necessary, but not that kind.



BUT in this particular case, rafmar's complaint seems to be unfounded
and based on a misunderstanding.


Imagine, you are beginner and want to find if it is ok to use 
foot=designated tag. What wiki page says so now?


Mariusz/rafmar


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

Re: [Tagging] Orientation of an adit?

[Mark Wagner]

On Fri, 10 Mar 2017 09:34:51 -0500
Kevin Kenny  wrote:

> I can just now hear, nevertheless, a chorus asserting that the
> information is available by other means and therefore does not belong
> in OSM. An adit or a cave entrance (that isn't a sinkhole) pretty
> much has to go into a hillside, and a waterfall or a dam flows
> downhill, so with information about local topography, the direction
> can be determined.

Thing is, the information *isn't* available by other means.  Adits
don't always go straight in -- of the two I'm aware of, both are at
rather sharp angles to the (very local) slope of the hill.

-- 
Mark

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

Re: [Tagging] Undiscussed changes for wki pages about access mode "designated".

[Yves]

Woosh, 200 edits a day! 
Not saying it's not useful, but at least self-moderation should be considered. 
After all it's a community there. 
Yves 

Le 10 mars 2017 20:25:17 GMT+01:00, Frederik Ramm  a écrit 
:
>Hi,
>
>On 03/10/2017 08:05 PM, Mariusz wrote:
>> 
>> Please note that due to recent changes by user Verdy_p the
>"designated"
>> value for various access key has been apparently marked as
>deprecated.
>> Pages affected:
>> https://wiki.openstreetmap.org/wiki/Key:access
>> https://wiki.openstreetmap.org/wiki/Tag:access%3Ddesignated
>
>The user Verdy_p changes about 200 wiki pages every day, and none of
>his
>changes are usually discussed before he applies them. I have no idea if
>the overall quality is good or bad but there's hardly a day without
>someone complaining.
>
>As far as I can see the change you are referring to is
>
>https://wiki.openstreetmap.org/w/index.php?title=Key%3Aaccess=revision=1440112=1439975
>
>before that, "access=designated" wasn't even on the "Key:access" page,
>and Verdy_p added it there:
>
>''(disapproved)'' A preferred or designated route for the class of
>traffic specified by the tag key, such as {{tag|foot|designated}}.
>Using
>this value with the plain access key, {{tag|access|designated}}, has no
>meaning, and should '''not''' be used. ''(see [[#Transport mode
>restrictions]])''
>
>On https://wiki.openstreetmap.org/wiki/Tag:access%3Ddesignated, Verdy_p
>added a banner saying "NOTE! The exact key/value combination
>access=designated should never appear on an object. The value
>*=designated must be used with a specific mode of transport. Examples:
>bicycle=designated or foot=designated." - he made this change without
>any change comment.
>
>The user rafmar (you?) seems to have assumed that Verdy_p wanted to
>discourage the use of all "designated" values, but to be fair to
>Verdy_p, the banner explicitly says you SHOULD use the "designated"
>value, just not with the "access" key.
>
>In my eyes it was not ok for Verdy_p to make sweeping changes like that
>under the radar but as I said, he makes SO MANY of them that nobody
>even
>has the time to discuss them all.
>
>BUT in this particular case, rafmar's complaint seems to be unfounded
>and based on a misunderstanding.
>
>Bye
>Frederik
>
>-- 
>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] Orientation of an adit?

[Mike Thompson]

On Fri, Mar 10, 2017 at 12:20 PM, Zecke  wrote:

> Am 10.03.2017 20:04, schrieb Mike Thompson:
>
>
>
> On Fri, Mar 10, 2017 at 7:34 AM, Kevin Kenny 
> wrote:
>
>>
>> I can just now hear, nevertheless, a chorus asserting that the
>> information is available by other means and therefore does not belong in
>> OSM. An adit or a cave entrance (that isn't a sinkhole) pretty much has to
>> go into a hillside, and a waterfall or a dam flows downhill, so with
>> information about local topography, the direction can be determined.
>>
> In many parts of the world there may not be elevation data with an open
> license of suitable resolution to make this determination for an adit.
>
> It's not true that an adit always enters the hill in slope direction. I
> know of many adits entering at an angle. So this approach does not really
> help. We decided to use a different symbol for adits without direction
> information than for directed adits.
>
All the more reason to explicitly tag the direction of the opening.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Undiscussed changes for wki pages about access mode "designated".

[Frederik Ramm]

Hi,

On 03/10/2017 08:05 PM, Mariusz wrote:
> 
> Please note that due to recent changes by user Verdy_p the "designated"
> value for various access key has been apparently marked as deprecated.
> Pages affected:
> https://wiki.openstreetmap.org/wiki/Key:access
> https://wiki.openstreetmap.org/wiki/Tag:access%3Ddesignated

The user Verdy_p changes about 200 wiki pages every day, and none of his
changes are usually discussed before he applies them. I have no idea if
the overall quality is good or bad but there's hardly a day without
someone complaining.

As far as I can see the change you are referring to is

https://wiki.openstreetmap.org/w/index.php?title=Key%3Aaccess=revision=1440112=1439975

before that, "access=designated" wasn't even on the "Key:access" page,
and Verdy_p added it there:

''(disapproved)'' A preferred or designated route for the class of
traffic specified by the tag key, such as {{tag|foot|designated}}. Using
this value with the plain access key, {{tag|access|designated}}, has no
meaning, and should '''not''' be used. ''(see [[#Transport mode
restrictions]])''

On https://wiki.openstreetmap.org/wiki/Tag:access%3Ddesignated, Verdy_p
added a banner saying "NOTE! The exact key/value combination
access=designated should never appear on an object. The value
*=designated must be used with a specific mode of transport. Examples:
bicycle=designated or foot=designated." - he made this change without
any change comment.

The user rafmar (you?) seems to have assumed that Verdy_p wanted to
discourage the use of all "designated" values, but to be fair to
Verdy_p, the banner explicitly says you SHOULD use the "designated"
value, just not with the "access" key.

In my eyes it was not ok for Verdy_p to make sweeping changes like that
under the radar but as I said, he makes SO MANY of them that nobody even
has the time to discuss them all.

BUT in this particular case, rafmar's complaint seems to be unfounded
and based on a misunderstanding.

Bye
Frederik

-- 
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] Orientation of an adit?

[Zecke]

Am 10.03.2017 20:04, schrieb Mike Thompson:



On Fri, Mar 10, 2017 at 7:34 AM, Kevin Kenny 
> wrote:



I can just now hear, nevertheless, a chorus asserting that the
information is available by other means and therefore does not
belong in OSM. An adit or a cave entrance (that isn't a sinkhole)
pretty much has to go into a hillside, and a waterfall or a dam
flows downhill, so with information about local topography, the
direction can be determined.

In many parts of the world there may not be elevation data with an 
open license of suitable resolution to make this determination for an 
adit.
It's not true that an adit always enters the hill in slope direction. I 
know of many adits entering at an angle. So this approach does not 
really help. We decided to use a different symbol for adits without 
direction information than for directed adits.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Undiscussed changes for wki pages about access mode "designated".

[Mariusz]

Please note that due to recent changes by user Verdy_p the "designated" 
value for various access key has been apparently marked as deprecated.

Pages affected:
https://wiki.openstreetmap.org/wiki/Key:access
https://wiki.openstreetmap.org/wiki/Tag:access%3Ddesignated

Mariusz



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

Re: [Tagging] Orientation of an adit?

[Mike Thompson]

On Fri, Mar 10, 2017 at 7:34 AM, Kevin Kenny 
wrote:

>
> I can just now hear, nevertheless, a chorus asserting that the information
> is available by other means and therefore does not belong in OSM. An adit
> or a cave entrance (that isn't a sinkhole) pretty much has to go into a
> hillside, and a waterfall or a dam flows downhill, so with information
> about local topography, the direction can be determined.
>
In many parts of the world there may not be elevation data with an open
license of suitable resolution to make this determination for an adit.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] charging station power output

[lucas-osm]

Hey guys,
 
two of the criteria on charging stations that matter the most to the drivers 
are the max. power output of the whole station and the max. power output of the 
socket compatible with my car. The power output of a specific socket gives some 
orientation on how fast you can charge in the best case. Regardless of other 
cars charging simultaneously or the battery’s charging level.
It’s useful to know the max power available for the whole station, because this 
power will be shared among all sockets. So for example if one station only got 
one socket, these values would be equal. But if you have one with three 
sockets, your current charging power does not only depend on the sockets max, 
but also on the total power available.
That’s why these readings should be directly or indirectly available through 
calculation.
Calculating the max. power is really easy. You just need to know the max. 
amperage (I), the max. voltage (U) and the number of phases (#np) the current 
is delivered in (do you say that?).
p = square_root(#np) * I * U
So a normal Schuko socket would give us roughly square_root(1) * 16A * 230V = 
3,7kW at best. A Schuko always operates on one phase. So you could say that’s 
great, we can determine the phases just by looking at the socket type. But 
sadly there are sockets which can operate at one or three phases. For example 
the Type2. Just by looking at this one you are not able the tell how many 
phases are in use. That’s a problem.
Theoretically say there would be a tag specifying the phase count, at least for 
those with unclear count (assumed we could find this on the station somewhere), 
there would be another issue: The Type2 socket can not only operate on direct 
current (DC) or alternating current (AC), but also on both simultaneously. I 
guess DC and AC will not operate on the same amperage / voltage.
This is getting really messy. As a driver you do not have to worry about the 
max. voltage or max. amperage one station is able to provide at a socket to 
determine if you are able to use and charge at a specific station. Because 
Type2, Type2 Combo etc. all ask your car via pulse-width modulation about it’s 
limits. If you’ve got the right socket or an adapter, only the maximum charging 
speed (depends on power output) matters.
I hope the above was not too confusing. If something in this explanation is 
somehow unclear to you please tell me.

That’s why I’d propose to add a tag describing the power output of the whole 
station and every single socket.
Obviously the power=* tag is no potential candidate, because it’s already in 
use “to identify facilities and features that relate to the generation and 
distribution of electrical power including power lines, power generation ...”.
So what else could we use? Generators already use generator:output=* to 
classify their output in Watts.
What about adopting this scheme like charging_station:output=* to specify the 
max. power output of the whole station, distributed over all available sockets. 
And socket:[socket_type]:output=* to specify the max. power output of one 
specific socket.

An example:
https://upload.wikimedia.org/wikipedia/commons/f/f6/Charging_station_socks.jpg
https://upload.wikimedia.org/wikipedia/commons/4/4a/Charging_station_specs.jpg

charging_station:output=98kW
socket:type2:output=43kW
socket:type2_combo:output=50kW
socket:chademo:output=50kW

As far as I know, these values are always provided on the station itself. On 
the front to inform the user of it’s max. power per socket and on the back 
there’s a specification of the input of the whole station / max. output of all 
sockets. I do not know about other countries, but I think here in Germany this 
sort of specification is mandatory. So through local research you are always 
able to get these values.
IMHO the currently advised tagging scheme of amperage and voltage (for charging 
stations) is meaningless without proper additional information.

What do you think about this?

Thanks a lot!

Lucas

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

Re: [Tagging] Feature Proposal - RFC - amenity=courier

[John F. Eldredge]

The services offered by post offices vary from country. Post offices in the 
US handle letters and packages, but don't offer any of the other services 
you mention. The main distinction in the USA is that "post office" 
conventionally refers only to offices of the United States Postal Service, 
which is quasi-governmental. A private company that rents out postboxes 
would be referred to as a "mail center". The private companies that offer 
package delivery are typically more expensive than the USPS, but are faster 
and more reliable about delivering on schedule.




On March 10, 2017 7:02:12 AM Philip Barnes  wrote:


On Friday, 10 March 2017, Paul Johnson wrote:

On Fri, Mar 10, 2017 at 4:04 AM, muzirian  wrote:

> The fact that people are relying these services more than post offices to
> send/recieve things (which is the most important purpose) made me think
> that they have the significance to be called as amenity, but it is
> debatable. What i wish is to make a standard for them , no matter if its
> tagged as amenity or office.


That's my rationale for the amenity=post_office operator=* combination.
They're functionally similar to functionally identical these days.

Not really, you only go to a post office to send large items that is very 
occadional if you are not running a business.


A post office on the other hand is a bank, you go there to withdraw cash, 
get foreign currency, tax your car, collect your pension, pick up 
government forms, renew your passport.


Phil (trigpoint)
--
Sent from my Jolla
___
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] Orientation of an adit?

[Dalibor Jelínek]

Hello,
+1 for direction tag.

Dalibor

> -Original Message-
> From: Zecke [mailto:zecke@historic.place]
> Sent: Friday, March 10, 2017 3:12 PM
> To: Tag discussion, strategy and related tools 
> Subject: Re: [Tagging] Orientation of an adit?
> 
> Please note that www.historic.place displays the orientation of adits.
> As it can be seen here:
> http://gk.historic.place/historische_objekte/translate/en/index-
> en.html?zoom=17=49.27361=6.9515=n2218896180=Km
> HaSaHe
> 
> We evaluate the direction tag, Please note that the direction is seen from the
> underground gallery outwards.
> 
> See also:
> http://wiki.openstreetmap.org/wiki/Key:direction
> 
> Regards,
> Carsten
> 
> Am 10.03.2017 um 14:48 schrieb Tod Fitch:
> > There are a number of abandoned adits and mine shafts in an area I’ve
> done some mapping in. When looking at old USGS topographic maps of the
> area, I’ve noticed that they used to align their symbol for an adit to show 
> its
> orientation.
> 
> 
> ___
> 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] Orientation of an adit?

[Kevin Kenny]

 On 03/10/2017 08:48 AM, Tod Fitch wrote:

There are a number of abandoned adits and mine shafts in an area I’ve
done some mapping in. When looking at old USGS topographic maps of the
area, I’ve noticed that they used to align their symbol for an adit to
show its orientation.

My inclination, at present, is to use either:

bearing=*
or
adit:bearing=*

Where the value would be in degrees clockwise from north, though I
doubt that more accuracy is needed than just compass points.

Comments? Suggestions?

I rather like this idea (which, I'm afraid, means that the consensus here
will not.

It would be useful not only for adits, but also for cave entrances.
Moreover, I'd like to see such a thing on small dams, small waterfalls, and
other directional point features. I know that the hydrographic ones can be
deduced from direction of the flow of the watercourse, but that, too, is
difficult to extract from the OSM data model - difficult enough that I know
of no rendering of OSM that is able to use the conventional symbol of blue
hashmarks across a stream to represent a waterfall or black ones to
represent a dam. It would similarly help for point objects used to
represent barriers such as gates.

I can just now hear, nevertheless, a chorus asserting that the information
is available by other means and therefore does not belong in OSM. An adit
or a cave entrance (that isn't a sinkhole) pretty much has to go into a
hillside, and a waterfall or a dam flows downhill, so with information
about local topography, the direction can be determined. The conventional
symbol for a gate would be drawn across the roadway (and presumably the
roadway direction is available), and so on. The fact that this hasn't been
done yet, I'd argue, indicates that it is difficult enough that a little
bit of auxiliary data might help!

And now I've got something added to my "to do eventually if nobody gets to
it first" list - a piece of programming to take features of this sort, find
corresponding points on interpolated data in an elevation data set, and use
gradient information to come up with a direction for rendering the symbol
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Orientation of an adit?

[Zecke]

Please note that www.historic.place displays the orientation of adits. 
As it can be seen here:

http://gk.historic.place/historische_objekte/translate/en/index-en.html?zoom=17=49.27361=6.9515=n2218896180=KmHaSaHe

We evaluate the direction tag, Please note that the direction is seen 
from the underground gallery outwards.


See also:
http://wiki.openstreetmap.org/wiki/Key:direction

Regards,
Carsten

Am 10.03.2017 um 14:48 schrieb Tod Fitch:

There are a number of abandoned adits and mine shafts in an area I’ve done some 
mapping in. When looking at old USGS topographic maps of the area, I’ve noticed 
that they used to align their symbol for an adit to show its orientation.



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

Re: [Tagging] Orientation of an adit?

[Colin Smale]

On 2017-03-10 14:48, Tod Fitch wrote:

> There are a number of abandoned adits and mine shafts in an area I've done 
> some mapping in. When looking at old USGS topographic maps of the area, I've 
> noticed that they used to align their symbol for an adit to show its 
> orientation.
> 
> I'd like to duplicate that rendering on the topographic maps I make, but 
> adits [1 [1]] are single points in the OSM data model without a bearing or 
> orientation tag so there is no information to drive the rendering.
> 
> There does not seem to be much in the wiki [2 [2]], [3 [3]] or taginfo [4 
> [4]] for applying a bearing or orientation to a point.
> 
> My inclination, at present, is to use either:
> 
> bearing=*
> or
> adit:bearing=*

Speaking of inclination, would that not be a relevant characteristic for
adits? They are not all level, as I understand it. 

//colin 

Links:
--
[1] https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dadit
[2] https://wiki.openstreetmap.org/wiki/NaPTAN/Tag_mappings
[3]
https://wiki.openstreetmap.org/wiki/Seamarks/Sectored_and_Directional_Lights
[4] https://taginfo.openstreetmap.org/search?q=bearing___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Orientation of an adit?

[Tod Fitch]

There are a number of abandoned adits and mine shafts in an area I’ve done some 
mapping in. When looking at old USGS topographic maps of the area, I’ve noticed 
that they used to align their symbol for an adit to show its orientation.

I’d like to duplicate that rendering on the topographic maps I make, but adits 
[1] are single points in the OSM data model without a bearing or orientation 
tag so there is no information to drive the rendering.

There does not seem to be much in the wiki [2], [3] or taginfo [4] for applying 
a bearing or orientation to a point.

My inclination, at present, is to use either:

bearing=*
or
adit:bearing=*

Where the value would be in degrees clockwise from north, though I doubt that 
more accuracy is needed than just compass points.

Comments? Suggestions?

[1] https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dadit
[2] https://wiki.openstreetmap.org/wiki/NaPTAN/Tag_mappings
[3] https://wiki.openstreetmap.org/wiki/Seamarks/Sectored_and_Directional_Lights
[4] https://taginfo.openstreetmap.org/search?q=bearing



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

Re: [Tagging] Feature Proposal - RFC - amenity=courier

[muzirian]

As phillip said, post office tag is unsuitable, they offer more services,
and they are not just for post.They have similarity in one service they
offer but that dont make both same thing. For example bar and pub are two
distinct objects.

On Fri, Mar 10, 2017 at 6:37 PM, Paul Johnson  wrote:

> On Fri, Mar 10, 2017 at 7:01 AM, Philip Barnes 
> wrote:
>
>> On Friday, 10 March 2017, Paul Johnson wrote:
>> > On Fri, Mar 10, 2017 at 4:04 AM, muzirian  wrote:
>> >
>> > > The fact that people are relying these services more than post
>> offices to
>> > > send/recieve things (which is the most important purpose) made me
>> think
>> > > that they have the significance to be called as amenity, but it is
>> > > debatable. What i wish is to make a standard for them , no matter if
>> its
>> > > tagged as amenity or office.
>> >
>> >
>> > That's my rationale for the amenity=post_office operator=* combination.
>> > They're functionally similar to functionally identical these days.
>> >
>> Not really, you only go to a post office to send large items that is very
>> occadional if you are not running a business.
>>
>> A post office on the other hand is a bank, you go there to withdraw cash,
>> get foreign currency, tax your car, collect your pension, pick up
>> government forms, renew your passport.
>>
>
>  See, that's where I would tag an additional bank, bureau du change, tag
> agent, and investment agent, since in north america, (all three major
> countries), posts offices only handle the post and, *if you're lucky*,
> have forms for this years taxes and passport renewals.
>
> ___
> 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] Feature Proposal - RFC - amenity=courier

[Paul Johnson]

On Fri, Mar 10, 2017 at 7:01 AM, Philip Barnes  wrote:

> On Friday, 10 March 2017, Paul Johnson wrote:
> > On Fri, Mar 10, 2017 at 4:04 AM, muzirian  wrote:
> >
> > > The fact that people are relying these services more than post offices
> to
> > > send/recieve things (which is the most important purpose) made me think
> > > that they have the significance to be called as amenity, but it is
> > > debatable. What i wish is to make a standard for them , no matter if
> its
> > > tagged as amenity or office.
> >
> >
> > That's my rationale for the amenity=post_office operator=* combination.
> > They're functionally similar to functionally identical these days.
> >
> Not really, you only go to a post office to send large items that is very
> occadional if you are not running a business.
>
> A post office on the other hand is a bank, you go there to withdraw cash,
> get foreign currency, tax your car, collect your pension, pick up
> government forms, renew your passport.
>

 See, that's where I would tag an additional bank, bureau du change, tag
agent, and investment agent, since in north america, (all three major
countries), posts offices only handle the post and, *if you're lucky*, have
forms for this years taxes and passport renewals.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - amenity=courier

[Philip Barnes]

On Friday, 10 March 2017, Paul Johnson wrote:
> On Fri, Mar 10, 2017 at 4:04 AM, muzirian  wrote:
> 
> > The fact that people are relying these services more than post offices to
> > send/recieve things (which is the most important purpose) made me think
> > that they have the significance to be called as amenity, but it is
> > debatable. What i wish is to make a standard for them , no matter if its
> > tagged as amenity or office.
> 
> 
> That's my rationale for the amenity=post_office operator=* combination.
> They're functionally similar to functionally identical these days.
>
Not really, you only go to a post office to send large items that is very 
occadional if you are not running a business.

A post office on the other hand is a bank, you go there to withdraw cash, get 
foreign currency, tax your car, collect your pension, pick up government forms, 
renew your passport.

Phil (trigpoint)
-- 
Sent from my Jolla
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - amenity=courier

[Paul Johnson]

On Fri, Mar 10, 2017 at 4:04 AM, muzirian  wrote:

> The fact that people are relying these services more than post offices to
> send/recieve things (which is the most important purpose) made me think
> that they have the significance to be called as amenity, but it is
> debatable. What i wish is to make a standard for them , no matter if its
> tagged as amenity or office.


That's my rationale for the amenity=post_office operator=* combination.
They're functionally similar to functionally identical these days.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - amenity=courier

[muzirian]

The fact that people are relying these services more than post offices to
send/recieve things (which is the most important purpose) made me think
that they have the significance to be called as amenity, but it is
debatable. What i wish is to make a standard for them , no matter if its
tagged as amenity or office.

On Friday, March 10, 2017, Warin <61sundow...@gmail.com> wrote:

> In this case I would tag it "office=courier" with the description "An
> office where goods are sent/received".
> The tag 'operator' can be used to specify the firm.
>
> I would not use amenity.
>
> On 10-Mar-17 01:26 AM, muzirian wrote:
>
> By courier I meant a place where you can sent and receive parcels and
> mail, like post office.
>
> On Thursday, March 9, 2017, Warin <61sundow...@gmail.com
> > wrote:
>
>> On 08-Mar-17 08:42 PM, muzirian wrote:
>>
>>> A company that transports commercial packages and documents.
>>>
>>> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcourier
>>>
>>>
>> What physical feature are you mapping?
>>
>> The description says "A company.." Companies are legal entities ... not
>> physical features.
>>
>>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - amenity=courier

[muzirian]

I know there are places which privatized post offices and we can use post
offices tag for them.But these facilities which I am talking about arent
post offices and they co exist at places where post offices only state
owned.

On Friday, March 10, 2017, John F. Eldredge  wrote:

> We already have an "amenity=post_office" tag.  I note that the wiki page
> for that tag includes an operator subtag, for if the post office is
> operated by a private company rather than a government agency. The United
> States Postal Service is quasi-governmental; the US Constitution calls for
> its establishment, and there are laws that apply specifically to it, but it
> is self-funded by selling its services, not funded by the Federal
> government.
>
> On 03/09/2017 04:49 PM, Warin wrote:
>
> In this case I would tag it "office=courier" with the description "An
> office where goods are sent/received".
> The tag 'operator' can be used to specify the firm.
>
> I would not use amenity.
>
> On 10-Mar-17 01:26 AM, muzirian wrote:
>
> By courier I meant a place where you can sent and receive parcels and
> mail, like post office.
>
> On Thursday, March 9, 2017, Warin <61sundow...@gmail.com
> > wrote:
>
>> On 08-Mar-17 08:42 PM, muzirian wrote:
>>
>>> A company that transports commercial packages and documents.
>>>
>>> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcourier
>>>
>>>
>> What physical feature are you mapping?
>>
>> The description says "A company.." Companies are legal entities ... not
>> physical features.
>>
>>
>
>
> ___
> Tagging mailing listtagg...@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging