date:20190814


On 15/08/19 14:16, Mateusz Konieczny wrote:




15 Aug 2019, 03:43 by joseph.eisenb...@gmail.com:

For context: yesterday Mateusz Konieczny edited the description of
natural=beach on the Landuse page and commented that "beach is not
always unvegetated and concrete along shore is not a beach", and then
I used his new description on the natural=beach page.

My edit was triggered by 
https://wiki.openstreetmap.org/w/index.php?title=Landuse=prev=1889234

edit that claimed that beach is well defined by
"Unvegetated strip of land at the edge of water."


And that was paraphrased form the original OSM description of a beach.


Main problem with such definition is that strip of concrete/asphalt 
along shore

is not a beach.

I thought about dunes when I claimed that "beach is not
always unvegetated" but now I see that dunes are not considered as 
part of the beach.


I copied definition from Wikipedia as it seemed far better as it 
managed to

exclude stuff like
https://commons.wikimedia.org/wiki/File:Sea_defences_(21467789266).jpg 



https://commons.wikimedia.org/wiki/File:Mole_in_Funchal,_Ponta_do_Garajau,_statue_of_Cristo_Rei_and_Desertas_Islands._Madeira,_Portugal.jpg

https://commons.wikimedia.org/wiki/File:Concrete_defences_by_the_Saxon_Shore_way_-_geograph.org.uk_-_1240179.jpg

Maybe copying previous definition from natural=beach would be preferable.


Don't know .. hence my question here .. any 'beach' 'experts'?


Re: > "To me it does not have plants growing on it - so unvegetated."

I agree that beaches generally don't have surface plants like grass -
this can be found in wind-formed sand dunes next to some beaches,
which I would map as natural=sand or natural=dune + surface=grass if
relevant.

However, there are many beaches shaded by coconut palms and other
spreading or leaning trees here in the rainy tropics - the canopy
would extend out over the high tide water line, so the leaves cover a
significant part of the beach (5 or even 10 meters), and most mappers
put the boundary of natural=wood at the end of the canopy. So I don't
know if mentioning "un-vegetated" in the description is necessary.

So it seems that maybe I managed to improve it, but purely by accident.

Overall I am fine also with older definition from natural=beach, page 
but I strongly
oppose defining beaches as "Unvegetated strip of land at the edge of 
water."


Good point about concrete may not be a 'beach' .. but then what is a 
'beach'?



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

Re: [Tagging] Definition of a Beach




15 Aug 2019, 03:43 by joseph.eisenb...@gmail.com:

> For context: yesterday Mateusz Konieczny edited the description of
> natural=beach on the Landuse page and commented that "beach is not
> always unvegetated and concrete along shore is not a beach", and then
> I used his new description on the natural=beach page.
>
My edit was triggered by 
https://wiki.openstreetmap.org/w/index.php?title=Landuse=prev=1889234
 

edit that claimed that beach is well defined by
"Unvegetated strip of land at the edge of water."

Main problem with such definition is that strip of concrete/asphalt along shore
is not a beach.

I thought about dunes when I claimed that "beach is not
always unvegetated" but now I see that dunes are not considered as part of the 
beach.
I copied definition from Wikipedia as it seemed far better as it managed to
exclude stuff like 
https://commons.wikimedia.org/wiki/File:Sea_defences_(21467789266).jpg 


https://commons.wikimedia.org/wiki/File:Mole_in_Funchal,_Ponta_do_Garajau,_statue_of_Cristo_Rei_and_Desertas_Islands._Madeira,_Portugal.jpg
 


https://commons.wikimedia.org/wiki/File:Concrete_defences_by_the_Saxon_Shore_way_-_geograph.org.uk_-_1240179.jpg
 


Maybe copying previous definition from natural=beach would be preferable.


> Re: > "To me it does not have plants growing on it - so unvegetated."
>
> I agree that beaches generally don't have surface plants like grass -
> this can be found in wind-formed sand dunes next to some beaches,
> which I would map as natural=sand or natural=dune + surface=grass if
> relevant.
>
> However, there are many beaches shaded by coconut palms and other
> spreading or leaning trees here in the rainy tropics - the canopy
> would extend out over the high tide water line, so the leaves cover a
> significant part of the beach (5 or even 10 meters), and most mappers
> put the boundary of natural=wood at the end of the canopy. So I don't
> know if mentioning "un-vegetated" in the description is necessary.
>
So it seems that maybe I managed to improve it, but purely by accident.

Overall I am fine also with older definition from natural=beach, page but I 
strongly 
oppose defining beaches as "Unvegetated strip of land at the edge of water."
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Document personal tags in Proposed_features/ space, User: space, or Tag:/Key: space?


On 15/08/19 13:33, Joseph Eisenberg wrote:

"accepted and historic method of documenting new tags."
"No matter how little used this is the accepted method"

Is there evidence or documentation that the accepted and historic
method of documenting new, unused or little-used tags is to create a
Tag:key=value page, without discussion first?

I'm new here, but it looks like back in 2007 to 2008 tags were
discussed and then voted upon and added to Map Features quite
frequently; there were many newly approved tags, before "Any tags you
like" was written - perhaps the later page was a reaction against the
developing proposal process?


OSM existed before the 'proposal process' came along.

The accepted method before the proposal process was to document new tags by 
directly entering them in the wiki.

When the 'proposal process' started there was no change to the practice of 
document new tags by directly entering them in the wiki.

There has been no suggestion that this method is depreciated, abandoned etc.




"The ideal of forcing a proposal ... does not fly with me due to the probability of 
being cast as 'abandoned'."

Using the proposal namespace should not force the original page author
to do anything else in the Proposal process. Most proposed tags are
never discussed on this list, and never move past "draft" status.


The status can be changed by anyone, not only the page author, I think quite a 
few proposal status changes to 'abandoned' are by others.
The author has probably lost all faith in the tagging group and moved on.



But at some point the tag is clearly abandoned, and it's useful to
mark it as such: the first user stops adding new features, and no more
are added for several years. That's part of the benefit of keeping new
tags in Proposal spaces: it makes it clear that they are not yet "in
use" or "de facto" tags, and may well no longer be actively used by
current mappers. (I don't think such abandoned tag proposal pages
should be deleted, as long as the tag is still in the database, but
the status change is helpful.)

The alternative of putting a new tag page in user namespace could also
be helpful for tags used by one person, if the user doesn't want to
discuss things or have the page changed by others. Wiki editors will
not feel the need to change the page by adding mentions of other tags,
problems with the tag, alternatives, etc, if it's in a personal User
space.


So it is a 'private' tag .. harder to find, not to be advertised...


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

Re: [Tagging] [OSM-talk] Document personal tags in Proposed_features/ space, User: space, or Tag:/Key: space?


15 sie 2019, 04:18 od joseph.eisenb...@gmail.com:

> Thoughts?
> (You can also respond at
> https://wiki.openstreetmap.org/wiki/Talk:Any_tags_you_like 
> > )
>
I would consider it as a great idea to
document actually used tags.

Documenting tag with 1 use is a waste of time, but not problematic.

It is harmful when it is not a new 
page but adding it to list of tags used
with some feature like amenity=parking.

So I would encourage documenting 
actually used tags and strongly discourage
mentioning rarely used tags on other
pages.

Creating page for unused tags is fine.

Note that there are cases of page describing 
barely used tags duplicating far more 
popular one and without evidence that
it is preferable. It is useful to describe
such duplicate as unwanted and discouraged.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Document personal tags in Proposed_features/ space, User: space, or Tag:/Key: space?

> "accepted and historic method of documenting new tags."
> "No matter how little used this is the accepted method"

Is there evidence or documentation that the accepted and historic
method of documenting new, unused or little-used tags is to create a
Tag:key=value page, without discussion first?

I'm new here, but it looks like back in 2007 to 2008 tags were
discussed and then voted upon and added to Map Features quite
frequently; there were many newly approved tags, before "Any tags you
like" was written - perhaps the later page was a reaction against the
developing proposal process?

> "The ideal of forcing a proposal ... does not fly with me due to the 
> probability of being cast as 'abandoned'."

Using the proposal namespace should not force the original page author
to do anything else in the Proposal process. Most proposed tags are
never discussed on this list, and never move past "draft" status.

But at some point the tag is clearly abandoned, and it's useful to
mark it as such: the first user stops adding new features, and no more
are added for several years. That's part of the benefit of keeping new
tags in Proposal spaces: it makes it clear that they are not yet "in
use" or "de facto" tags, and may well no longer be actively used by
current mappers. (I don't think such abandoned tag proposal pages
should be deleted, as long as the tag is still in the database, but
the status change is helpful.)

The alternative of putting a new tag page in user namespace could also
be helpful for tags used by one person, if the user doesn't want to
discuss things or have the page changed by others. Wiki editors will
not feel the need to change the page by adding mentions of other tags,
problems with the tag, alternatives, etc, if it's in a personal User
space.

On 8/15/19, Warin <61sundow...@gmail.com> wrote:
> On 15/08/19 12:18, Joseph Eisenberg wrote:
>> [Posted to Talk + Tagging]:
>>
>> Currently the section "Non proposed features" in the OSM wiki page
>> "Proposal_process" mentions that new tags should not be added to
>> "Map_Features" without discussion. Some users also believe that new
>> tags should not be documented under the feature wiki space with
>> "Key:New_feature" or "Tag:key=value" pages, but should instead be
>> documented in a User:username/ namespace or the Proposed_features/
>> namespace.
>>
>> In contrast, the current text of the wiki page "Any tags you like
>> suggests creating a new tag for bird nests (as an example) with
>> Key:endangered_nest=Siberian_flying_squirrel - besides suggesting
>> using non-standard capitalization in the value, this suggests creating
>> a new Key: / Tag: page directly,
>
> This has been the method for a very long time.
>
>>   rather than using User:username/ or
>> Proposed_features/.
>
> This is a new method that some think is better.
>
>>
>> Is this a good idea?  Occasionally new wiki pages are created in these
>> standard spaces for tags with only a few uses or no uses in the
>> database.
>>
>> I would encourage mappers not to create new feature pages for tags
>> which are not yet in use, or have only been used a handful of times by
>> one mapper. Instead, it would be good to clarify that the
>> Proposed_features/ namespace can be used even if the user has no
>> interest in continuing the proposal process. I though that new feature
>> pages should be created to document "in use" tags that have been used
>> by more than a handful of different mappers in more than a handful of
>> places.
>>
>> Thoughts?
>
> Past practice has been to simple document what you have tagged as a new wiki
> page. Simple, easy and accessible by all. No matter how little used this is
> the accepted method and has neen in use for a long time.
>
> Placing it as a proposal and then not proceeding with it sees it being down
> graded to 'abandoned'. These may be harder to find.
>
> Placing it in User:username/
> humm .. will that show up if I search for the key/value?
>
> -
>
> I am against depreciation the accepted and historic method of documenting
> new tags.
> I would need convincing that the other methods are 'better'.
> The ideal of forcing a proposal ... does not fly with me due to the
> probability of being cast as 'abandoned'.
>
>
>
>
>
> ___
> 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] How to distinguish public and private offices?

office=diplomatic was recently approved for consulates (and
embassies), which almost always provide public services.

Office=government is one that is most in need of more distinctions.

I suppose access=private isn’t wrong, but it seems incomplete: many
government offices do not legally exclude the public, but also do not
offer public services. For example, the offices of members of the
American legislature are clearly not public, but anyone in the public
can get an appointment to visit the legislator from their district.
Local government offices often allow walk-in visitors, but may not
offer any services.

Perhaps more types of government offices which provide public services
should have a specific amenity or shop tag, like the existing tags
amenity=town_hall,  amenity=courthouse, amenity=embassy,
amenity=register_office?

Or do we just need more sub-tags like government=ministry,
government=register_office and government=tax? There are many other
values that are not yet document, and many are not very clear.

I'd note that the proposal Proposed_features/Government_offices was
approved in 2015 (though with some objection), and switched from
amenity=register_office to government=register_office +
office=government, for a public-facing service office.

- Joseph

On 8/15/19, Warin <61sundow...@gmail.com> wrote:
> On 15/08/19 07:35, Martin Koppenhoefer wrote:
>>
>> sent from a phone
>>
>>> On 14. Aug 2019, at 23:30, Mateusz Konieczny 
>>> wrote:
>>>
>>> Unfortunately many office=* tags represent something that is accessible
>>
>> yes it is unfortunate
>
> Not it is not.
>
> An office is a place predominantly providing services, frequently selling
> them.
>
> A shop is a place that predominantly sells physical objects like fruit and
> vegetables.
>
>
> The majority of values of offices look to me to provide public services.
>
> To signify restriction on access use the access key, just as it is done for
> highways etc.
>
>
>
>
> ___
> 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] Document personal tags in Proposed_features/ space, User: space, or Tag:/Key: space?


On 15/08/19 12:18, Joseph Eisenberg wrote:

[Posted to Talk + Tagging]:

Currently the section "Non proposed features" in the OSM wiki page
"Proposal_process" mentions that new tags should not be added to
"Map_Features" without discussion. Some users also believe that new
tags should not be documented under the feature wiki space with
"Key:New_feature" or "Tag:key=value" pages, but should instead be
documented in a User:username/ namespace or the Proposed_features/
namespace.

In contrast, the current text of the wiki page "Any tags you like
suggests creating a new tag for bird nests (as an example) with
Key:endangered_nest=Siberian_flying_squirrel - besides suggesting
using non-standard capitalization in the value, this suggests creating
a new Key: / Tag: page directly,


This has been the method for a very long time.


  rather than using User:username/ or
Proposed_features/.


This is a new method that some think is better.



Is this a good idea?  Occasionally new wiki pages are created in these
standard spaces for tags with only a few uses or no uses in the
database.

I would encourage mappers not to create new feature pages for tags
which are not yet in use, or have only been used a handful of times by
one mapper. Instead, it would be good to clarify that the
Proposed_features/ namespace can be used even if the user has no
interest in continuing the proposal process. I though that new feature
pages should be created to document "in use" tags that have been used
by more than a handful of different mappers in more than a handful of
places.

Thoughts?


Past practice has been to simple document what you have tagged as a new wiki 
page. Simple, easy and accessible by all. No matter how little used this is the 
accepted method and has neen in use for a long time.

Placing it as a proposal and then not proceeding with it sees it being down 
graded to 'abandoned'. These may be harder to find.

Placing it in User:username/
humm .. will that show up if I search for the key/value?

-

I am against depreciation the accepted and historic method of documenting new 
tags.
I would need convincing that the other methods are 'better'.
The ideal of forcing a proposal ... does not fly with me due to the probability 
of being cast as 'abandoned'.





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

[Tagging] New property Key:walk-in for amenities like clinics, barbers, hair salons that offer walk-in appointments/service?

Another user has proposed the Key walk-in=* to specify if an amenity,
like a healthcare facility, sees people on a walk-in basis or not. In
particular it's for medical clinics or doctor's practices.

Suggested values are:

yes - walk-in service is available (appointments might also be available)

no - does not normally serve walk-in patients/customers (appointments required).

only - for clinics (or hair salons, barbers, etc) which only provide
"walk-in" service, and do not offer advance appointments

This looks pretty good to me, unless there is a different term used in
British English?

See https://wiki.openstreetmap.org/wiki/Proposed_features/Key:walk-in

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

[Tagging] New property Key:walk-in for amenities like clinics, barbers, hair salons that offer walk-in appointments/service?

Another user has proposed the Key walk-in=* to specify if an amenity,
like a healthcare facility, sees people on a walk-in basis or not. In
particular it's for medical clinics or doctor's practices.

Suggested values are:

yes - walk-in service is available (appointments might also be available)

no - does not normally serve walk-in patients/customers (appointments required).

only - for clinics (or hair salons, barbers, etc) which only provide
"walk-in" service, and do not offer advance appointments

This looks pretty good to me, unless there is a different term used in
British English?

See https://wiki.openstreetmap.org/wiki/Proposed_features/Key:walk-in

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

[Tagging] Document personal tags in Proposed_features/ space, User: space, or Tag:/Key: space?

[Posted to Talk + Tagging]:

Currently the section "Non proposed features" in the OSM wiki page
"Proposal_process" mentions that new tags should not be added to
"Map_Features" without discussion. Some users also believe that new
tags should not be documented under the feature wiki space with
"Key:New_feature" or "Tag:key=value" pages, but should instead be
documented in a User:username/ namespace or the Proposed_features/
namespace.

In contrast, the current text of the wiki page "Any tags you like
suggests creating a new tag for bird nests (as an example) with
Key:endangered_nest=Siberian_flying_squirrel - besides suggesting
using non-standard capitalization in the value, this suggests creating
a new Key: / Tag: page directly, rather than using User:username/ or
Proposed_features/.

Is this a good idea?  Occasionally new wiki pages are created in these
standard spaces for tags with only a few uses or no uses in the
database.

I would encourage mappers not to create new feature pages for tags
which are not yet in use, or have only been used a handful of times by
one mapper. Instead, it would be good to clarify that the
Proposed_features/ namespace can be used even if the user has no
interest in continuing the proposal process. I though that new feature
pages should be created to document "in use" tags that have been used
by more than a handful of different mappers in more than a handful of
places.

Thoughts?
(You can also respond at
https://wiki.openstreetmap.org/wiki/Talk:Any_tags_you_like)

- Joseph Eisenberg

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

Re: [Tagging] Definition of a Beach

For context: yesterday Mateusz Konieczny edited the description of
natural=beach on the Landuse page and commented that "beach is not
always unvegetated and concrete along shore is not a beach", and then
I used his new description on the natural=beach page.

Re: > "Is mud not a beach?"

Generally beaches are formed from sand or larger mineral particles, up
to cobble-sized stones, deposited by moving water. Smaller mineral
particles are carried away by the water.

Mud is formed from mainly wet silt and clay - these are small and very
small mineral particles (clay is so fine that it feels smooth, silt
still feels a little gritty to the touch), which only settle out in
slow moving water.

At the coastline, mud is found at tidal flats ("mud flats"), not on
beaches. These are tagged natural=wetland + wetland=tidalflat

Re: > What about rock?

In British English (and OSM), "Rock" generally means bedrock. The
images of Marino Rocks Beach show an area of round cobblestones up
higher on the sloped beach, and then areas of exposed bedrock lower
down. Solid rock can be mapped as natural=bare_rock (this rock is
probably outside of the coastline, but that's ok if it's above the low
tide line), and the beach area (loose stones) with natural=beach +
surface=stones or =shingle.

Sometimes you also find rough, jagged stones next to a beach where
they have fallen from a cliff: this can be mapped as natural=scree.

Along rivers, areas of rounded stones and pebbles are usually mapped
as natural=shingle rather than natural=beach.

Re: > "To me it does not have plants growing on it - so unvegetated."

I agree that beaches generally don't have surface plants like grass -
this can be found in wind-formed sand dunes next to some beaches,
which I would map as natural=sand or natural=dune + surface=grass if
relevant.

However, there are many beaches shaded by coconut palms and other
spreading or leaning trees here in the rainy tropics - the canopy
would extend out over the high tide water line, so the leaves cover a
significant part of the beach (5 or even 10 meters), and most mappers
put the boundary of natural=wood at the end of the canopy. So I don't
know if mentioning "un-vegetated" in the description is necessary.

-Joseph

On 8/15/19, Warin <61sundow...@gmail.com> wrote:
> What is a beach?
>
> Oxford Dictionary: A pebbly or sandy shore, especially by the sea
> between high- and low-water marks.
>
> OSM description now: landform along a body of water which consists of
> sand, shingle or other loose material
>
> OSM description yesterday: Unvegetated strip of sand, shingle or other loose
> material at the
> coast or the shore of a lake
>
> OSM text: Thenatural =beach
>  tag is used to mark a loose geological landform along the coast or
> along another body of water consisting of sand, gravel, shingle, pebbles,
> cobblestones or sometimes shell fragments etc.
>
> --
>
> To me it does not have plants growing on it - so unvegitated.
>
> Is mud not a beach?
> Merseyside?https://www.adelaidenow.com.au/news/national/rnli-rescue-dog-walker-stuck-in-mud-on-merseyside-beach/video/f52508898923c2dc9907202049229bbe
>
>
> https://www.niwa.co.nz/coasts-and-oceans/nz-coast/learn-about-coastal-environments/beach-types/13-beach-types/reflective-tidal-mud-flats
>
> What about rock?
>
> https://www.weekendnotes.com/marino-rocks-beach/
>
>

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

Re: [Tagging] Merging tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes


On 15/08/19 09:37, Paul Allen wrote:
On Thu, 15 Aug 2019 at 00:13, Warin <61sundow...@gmail.com 
> wrote:


One hiking trail I know of the locals usually go bare foot, not
only because of poverty but also terrain.
So the foot ware would be a guide, not a rule.
Are all foot routes paved?  I would think so.


Around my town there are several footpaths that are paved.  But 
they're not walking routes,
just short cuts between locations.  Pretty much indistinguishable from 
a sidewalk apart from

not being at the side of a road.

Around the outskirts of my town there are also several footpaths 
which, at least in part, go
across fields.  Again, not walking routes, just short cuts.  They 
could probably be incorporated

into walking routes but, as far as I know, nobody has done so.


Are these 'signed' routes? If not then they fail that test for a 'route'.


Then there are footpaths which are part of walking routes.  Usually 
unpaved, cutting across fields
or through woods.  And then there are hiking routes where the surface 
is uneven, or stony, or

boggy, or you have to ford through a stream.

Hiking route may have sections that are 'paved', mainly to prevent
damage to the environment.


True.  Some of the walking and hiking routes I know of have a section, 
or sections, along a road.
But you choose footwear for the worst conditions you'll encounter on 
the route, not the best.


Going by the footwear was only a rule of thumb, but it seems like a 
useful one.  There are going
to be exceptions, but if you need hiking boots, and even fit people 
need a walking stick to keep
their balance, it's better to call it a hiking route than a walking 
route.  Similarly, if you could do it
wearing slippers without any discomfort or getting wet feet, it's 
probably a walking route.  It
seems like useful guidance to mappers rather than not defining any 
distinction at all.  But

maybe somebody can come up with something better.


Yes.. 'something better' is always useful. I do like the footwear as a 
guide, but not as a rule.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Merging tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes

Re: > "One hiking trail I know of the locals usually go bare foot, not
only because of poverty but also terrain. So the foot ware would be a
guide, not a rule.

Agreed. That's also true of most paths and footways in rural eastern
Indonesia, many of which are steeper, rockier or muddier and more
exposed to fall risk than some of the "via ferrata" paths in Europe.
(They often even have wooden ladders to aid climbing up steep cliff
sections).

It probably would have been nice if we had one type of tag for all
pedestrian routes including foot/walking/hiking/pilgrimage, but since
both "hiking" and "walking" are widely used, I agree with documenting
them in a similar way and mentioning the other option on both wiki
pages.

On 8/15/19, Warin <61sundow...@gmail.com> wrote:
> It would be usefull to document the method of  including alternate, side
> trips and access tracks to these routes.
>
> At the moment I and others are using the role 'alternate' for track
> alternative paths.
>
> For 'side trips' (short paths to features of interest) possibly the role
> 'side_trip'?
>
> For 'access tracks' (paths from common and signed places that leas to teh
> main track) possibly the role 'access_track'?
>
>
> On 13/08/19 18:50, s8evq wrote:
>> Hello everyone,
>>
>> On the discussion page of the wiki entry Hiking
>> (https://wiki.openstreetmap.org/wiki/Talk:Hiking#Synchronize_wiki_page_Hiking.2C_Walking_Routes.2C_route.3Dhiking_and_route.3Dfoot_on_tagging_scheme.)
>> I have started a topic, but with little response so far. That's why I come
>> here, before proceeding.
>>
>>
>> Currently, there are four tagging scheme tables describing how walking (or
>> hiking) routes should be tagged.
>> https://wiki.openstreetmap.org/wiki/Hiking
>> https://wiki.openstreetmap.org/wiki/Walking_Routes
>> https://wiki.openstreetmap.org/wiki/Tag:route%3Dhiking
>> https://wiki.openstreetmap.org/wiki/Tag:route%3Dfoot
>>
>> Would it not be easier and more clear if we just keep one, and add a link
>> to it in the others?
>>
>> Last month, I already started harmonizing these four tagging scheme
>> tables. I changed the order, added some missing tags, adjusted the
>> explanation etc... In my view, I only had to do minor edits. For those
>> interested, here are my edits:
>>
>> https://wiki.openstreetmap.org/w/index.php?title=Hiking=revision=1878387=1873054
>> https://wiki.openstreetmap.org/w/index.php?title=Walking_Routes=revision=1881156=1879580
>> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dhiking=revision=1878383=1853636
>> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dfoot=revision=1878384=1853797
>>
>> So these four tagging scheme tables are now almost 100% the same.
>>
>>
>> My idea was to keep the tagging scheme table on one of the wiki pages, and
>> put a link to it on the three other pages. I would like to have broader
>> support before going further.
>>
>>
>> Of course, we can discuss about the content of the tagging scheme. But
>> that's irrelevant to my question about the organization of the wiki page.
>>
>>
>>
>>
>> ___
>> 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] Definition of a Beach


What is a beach?

Oxford Dictionary: A pebbly or sandy shore, especially by the sea 
between high- and low-water marks.


OSM description now: landform along a body of water which consists of 
sand, shingle or other loose material


OSM description yesterday: Unvegetated strip of sand, shingle or other loose 
material at the
coast or the shore of a lake

OSM text: Thenatural =beach  
tag is used to mark a loose geological landform along the coast or
along another body of water consisting of sand, gravel, shingle, pebbles, 
cobblestones or sometimes shell fragments etc.

--

To me it does not have plants growing on it - so unvegitated.

Is mud not a beach? 
Merseyside?https://www.adelaidenow.com.au/news/national/rnli-rescue-dog-walker-stuck-in-mud-on-merseyside-beach/video/f52508898923c2dc9907202049229bbe

 
https://www.niwa.co.nz/coasts-and-oceans/nz-coast/learn-about-coastal-environments/beach-types/13-beach-types/reflective-tidal-mud-flats

What about rock?

https://www.weekendnotes.com/marino-rocks-beach/

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

Re: [Tagging] Merging tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes

2019-08-14 Thread Paul Allen

On Thu, 15 Aug 2019 at 00:13, Warin <61sundow...@gmail.com> wrote:

One hiking trail I know of the locals usually go bare foot, not only
> because of poverty but also terrain.
> So the foot ware would be a guide, not a rule.
> Are all foot routes paved?  I would think so.
>

Around my town there are several footpaths that are paved.  But they're not
walking routes,
just short cuts between locations.  Pretty much indistinguishable from a
sidewalk apart from
not being at the side of a road.

Around the outskirts of my town there are also several footpaths which, at
least in part, go
across fields.  Again, not walking routes, just short cuts.  They could
probably be incorporated
into walking routes but, as far as I know, nobody has done so.

Then there are footpaths which are part of walking routes.  Usually
unpaved, cutting across fields
or through woods.  And then there are hiking routes where the surface is
uneven, or stony, or
boggy, or you have to ford through a stream.

Hiking route may have sections that are 'paved', mainly to prevent damage
> to the environment.
>

True.  Some of the walking and hiking routes I know of have a section, or
sections, along a road.
But you choose footwear for the worst conditions you'll encounter on the
route, not the best.

Going by the footwear was only a rule of thumb, but it seems like a useful
one.  There are going
to be exceptions, but if you need hiking boots, and even fit people need a
walking stick to keep
their balance, it's better to call it a hiking route than a walking route.
Similarly, if you could do it
wearing slippers without any discomfort or getting wet feet, it's probably
a walking route.  It
seems like useful guidance to mappers rather than not defining any
distinction at all.  But
maybe somebody can come up with something better.

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

Re: [Tagging] Merging tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes

It would be usefull to document the method of including alternate, side trips
and access tracks to these routes.

At the moment I and others are using the role 'alternate' for track alternative
paths.

For 'side trips' (short paths to features of interest) possibly the role
'side_trip'?

For 'access tracks' (paths from common and signed places that leas to teh main
track) possibly the role 'access_track'?

On 13/08/19 18:50, s8evq wrote:

Hello everyone,

On the discussion page of the wiki entry Hiking
(https://wiki.openstreetmap.org/wiki/Talk:Hiking#Synchronize_wiki_page_Hiking.2C_Walking_Routes.2C_route.3Dhiking_and_route.3Dfoot_on_tagging_scheme.)
I have started a topic, but with little response so far. That's why I come
here, before proceeding.

Currently, there are four tagging scheme tables describing how walking (or
hiking) routes should be tagged.
https://wiki.openstreetmap.org/wiki/Hiking
https://wiki.openstreetmap.org/wiki/Walking_Routes
https://wiki.openstreetmap.org/wiki/Tag:route%3Dhiking
https://wiki.openstreetmap.org/wiki/Tag:route%3Dfoot

Would it not be easier and more clear if we just keep one, and add a link to it
in the others?

Last month, I already started harmonizing these four tagging scheme tables. I
changed the order, added some missing tags, adjusted the explanation etc... In
my view, I only had to do minor edits. For those interested, here are my edits:

https://wiki.openstreetmap.org/w/index.php?title=Hiking=revision=1878387=1873054
https://wiki.openstreetmap.org/w/index.php?title=Walking_Routes=revision=1881156=1879580
https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dhiking=revision=1878383=1853636
https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dfoot=revision=1878384=1853797

So these four tagging scheme tables are now almost 100% the same.

My idea was to keep the tagging scheme table on one of the wiki pages, and put
a link to it on the three other pages. I would like to have broader support
before going further.

Of course, we can discuss about the content of the tagging scheme. But that's
irrelevant to my question about the organization of the wiki page.

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

Re: [Tagging] Merging tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes


On 14/08/19 22:21, Paul Allen wrote:
On Wed, 14 Aug 2019 at 10:56, s8evq > wrote:



1) Remove the wording "(optional)" in front of the explanation of
some keys. What's the function of adding (optional) in front of
tags that are in the Useful section of the table? Isn't every tag
that is not in Required optional by default?


It helps newbies.  Newbies have to start somewhere, and adding a 
walking/hiking route
might be the first thing somebody tries and doesn't read any other 
documentation first.
At least consider a sentence under the heading "Useful" explaining 
that those tags
are optional.  Not strictly needed, but I'm remembering my early days 
with OSM and
trying to make sense of it without getting lost in a twisty maze of 
wiki pages, all

different.

Yes, to the sentence at the top.
To me there are 3 things in the pecking order; required to make it work, 
recommended to add really usefull detail and usefull for adding stuff 
that matters little.





To do
1) Explanation route=hiking / route=foot is merely a copy paste at
the moment. Should be cleaned out and clarified


One distinction I saw (I have no idea where) is that it influences the 
type of footwear needed.
Walking shoes (at a pinch, even ordinary shoes) are adequate for a 
walking trail but a
hiking trail needs walking boots because you will encounter sharp 
rocks and/or heavy
undergrowth and/or muddy terrain and/or have to wade through shallow 
streams.


One hiking trail I know of the locals usually go bare foot, not only 
because of poverty but also terrain.

So the foot ware would be a guide, not a rule.
Are all foot routes paved?  I would think so.
Hiking route may have sections that are 'paved', mainly to prevent 
damage to the environment.




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

Re: [Tagging] How to distinguish public and private offices?


On 15/08/19 07:35, Martin Koppenhoefer wrote:


sent from a phone


On 14. Aug 2019, at 23:30, Mateusz Konieczny  wrote:

Unfortunately many office=* tags represent something that is accessible


yes it is unfortunate


Not it is not.

An office is a place predominantly providing services, frequently selling them.

A shop is a place that predominantly sells physical objects like fruit and 
vegetables.


The majority of values of offices look to me to provide public services.

To signify restriction on access use the access key, just as it is done for 
highways etc.




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

Re: [Tagging] Connectivity relations - approved

Good job!

Thank you, Leif.



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] Bicycle kitchens, community centres that offer bicycle repairs etc

Sorry,

Obviusly, «amenity=community_centre» (my mistake).



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] Bicycle kitchens, community centres that offer bicycle repairs etc

Hi, Morten.

Where I live (Málaga, Spain), there is (or was) a bicycle workshop with
similar characteristics. Its creator defined it as a socio-cultural bicycle
workshop. You could take your bike there for repair. I had tools and
everything you might need. In addition, more experienced people could help
you repair your bike. 

There was no need to pay anything, it was a community center. It was not a
shop, it was not a workshop, it was not a business. It was a community
workshop or socio-cultural bicycle workshop, if you prefer. In any case a
community centre.

I find it acceptable to use repair shop or bicycle shops sub-tags to specify
the services offered if there is nothing better, indicating that the
services are free ("fee=no") and that the centre is not a shop or workshop,
but a community centre ("community=centre").

Greetings from Spain.

Regards,
Daniel



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] How to distinguish public and private offices?

Hi,

Why not "access=private"?

Examples from the wiki [1]:

 "amenity=parking" + "access=private" for private parking, such as company
employees.
 "leisure=swimming_pool" + "access=private" for a swimming pool in a private
backyard.  
 "leisure=playground" + "access=private" for a playground in a school or
kindergarten.

Examples from the wiki could also include, as another example, a private
office [1]:

 "office=yes" + "access=private" for private office generally not accessible
by general public.

I think it's a simple and correct solution.

Greetings from Spain.

Regards,
Daniel

[1] https://wiki.openstreetmap.org/wiki/Tag:access%3Dprivate



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] How to distinguish public and private offices?



sent from a phone

> On 14. Aug 2019, at 23:30, Mateusz Konieczny  wrote:
> 
> Unfortunately many office=* tags represent something that is accessible


yes it is unfortunate 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to distinguish public and private offices?




14 Aug 2019, 23:11 by dieterdre...@gmail.com:

>
>
>> There are some that can be assumed to be accessible like office=travel_agent.
>>
>
>
> depends what this is describing: a place where you go to book a tour / hotel 
> / flight or a business 2 business place (back office) where contracts / 
> agreements are made, tours are composed, offers calculated, catalogues 
> created, etc.?
>
> IMHO upholding clear semantics for shop and amenity (public generally 
> admitted) and office (public generally not admitted) would help make/keep 
> tagging easier.
>
Unfortunately many office=* tags represent something that is accessible - for 
example
office=insurance is used far more often than shop=insurance (what is causing 
throuble
as there are

- actual offices of companies without public access
- places where one may sign up for insurance services
- offices open for public, not selling insurance services (for example, 
center for processing vehicle insurance claims)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to distinguish public and private offices?

sent from a phone

> On 14. Aug 2019, at 22:27, Mateusz Konieczny  wrote:
> 
> There are some offices that can be assumed to be without access by general 
> public
> like office=company.

I would generally think of office=* as not accessible for the general public, 
at least this was the initial idea if I recall correctly. The office=company 
tag seems to be an outlier among the office tags.

For example 
amenity=bank is a place where (small) customers go to do banking 

office=bank is a place where the “other” bankers are working (no public 
admittance)

Those places where the public is generally admitted will usually/often also 
have private areas where the public can’t access (similar to the kitchen or 
office of a restaurant)

> 
> There are some that can be assumed to be accessible like office=travel_agent.

depends what this is describing: a place where you go to book a tour / hotel / 
flight or a business 2 business place (back office) where contracts / 
agreements are made, tours are composed, offers calculated, catalogues created, 
etc.?

IMHO upholding clear semantics for shop and amenity (public generally admitted) 
and office (public generally not admitted) would help make/keep tagging easier.

There is also craft, which is more about formal qualification though and can be 
used in addition to other main tags.

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

[Tagging] How to distinguish public and private offices?

There are some offices that can be assumed to be without access by general 
public
like office=company.

There are some that can be assumed to be accessible like office=travel_agent.

But there are some like office=political_party, office=religion,
office=government that are generally accessible and used by general public but 
some
are for internal use and not used by general public.

For example office=government may be place where people order or file documents.
But it may be also place without public entry and handling some internal things.

Is there a standard way to tag this? I thought about access=private/no, but 
maybe there
is other way to handle this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Gorges, Canyons, Ravines: natural=valley or new tag?

2019-08-14 Thread Kevin Kenny

On Wed, Aug 14, 2019 at 4:34 AM Michael Patrick  wrote:

> 4. These folks have their own 'Encyclopedia of Geomorphology', which gives 
> detailed explanations of what sorts of observable features define a term, and 
> where terms overlap. ( See page 486 'Ravines and Gullies at 
> http://bit.ly/2YJca7I ). Various agencies in various countries dealing with 
> geomorphology nomenclature also publish there own glossaries ( see Part 
> 629–Glossary of Landform and Geologic Terms at 
> https://directives.sc.egov.usda.gov/OpenNonWebContent.aspx?content=41992.wba 
> ), derived from an American Geologic Institute (AGI) publication.

And please, please, don't make me follow it to the letter! I live in
an area where there's a lot of highly complex glaciokarst terrain, and
the correct classification of many landforms, even where not
controversial, is rather récherché for the ordinary mapper.

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

Re: [Tagging] Gorges, Canyons, Ravines: natural=valley or new tag?

sent from a phone

> On 14. Aug 2019, at 10:31, Michael Patrick  wrote:
> 
> 5. For international features, the National Geospatial Agency GeoNames Search 
> page ( http://geonames.nga.mil/namesgaz/ ) enables you to look up the 
> classifications, and what they are called in the local language(s).Open up 
> the Feature Designations section, and scan through the 'Hypsographic' 
> listing, and you'll see CNYN/Canyon, searching on Mexico, it gives 1732 
> cañada. You also get direct links to mapping services so you can look at the 
> features.

why would you want to do this, if the common name has nothing to do with the 
formal definition of a feature type (your point 2)? This operation would only 
give you the expected results if there was a Mexican Spanish word of with an 
identical definition as the definition of an English word (which is often not 
the case, generally, with different languages).

Even without knowing the details I agree it is quite unlikely gorge, canyon and 
other similar words all have an identical meaning.

Cheers Martin 

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

Re: [Tagging] Gorges, Canyons, Ravines: natural=valley or new tag?

sent from a phone

> On 14. Aug 2019, at 07:20, Graeme Fitzpatrick  wrote:
> 
> natural=valley + valley=canyon etc

this would also be my preference, presupposed we can come up with definitions 
for these valley subtypes that make sense.

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

Re: [Tagging] Merging tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes

2019-08-14 Thread Paul Allen

On Wed, 14 Aug 2019 at 10:56, s8evq  wrote:

>
> 1) Remove the wording "(optional)" in front of the explanation of some
> keys. What's the function of adding (optional) in front of tags that are in
> the Useful section of the table? Isn't every tag that is not in Required
> optional by default?
>

It helps newbies.  Newbies have to start somewhere, and adding a
walking/hiking route
might be the first thing somebody tries and doesn't read any other
documentation first.
At least consider a sentence under the heading "Useful" explaining that
those tags
are optional.  Not strictly needed, but I'm remembering my early days with
OSM and
trying to make sense of it without getting lost in a twisty maze of wiki
pages, all
different.

To do
> 1) Explanation route=hiking / route=foot is merely a copy paste at the
> moment. Should be cleaned out and clarified
>

One distinction I saw (I have no idea where) is that it influences the type
of footwear needed.
Walking shoes (at a pinch, even ordinary shoes) are adequate for a walking
trail but a
hiking trail needs walking boots because you will encounter sharp rocks
and/or heavy
undergrowth and/or muddy terrain and/or have to wade through shallow
streams.

Yes, that definition seems to be putting the cart before the horse, but
follow it backwards.
If the map says it's a walking route you can get away with walking shoes or
even
ordinary shoes; if the map says it's a hiking route then you need hiking
boots.  And that
is the reason for the map making a distinction in the first place, so you
know what type
of equipment you need.

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

Re: [Tagging] Merging tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes

2019-08-14 Thread Hufkratzer


I would also prefer the transclusion (template) instead of just links.

It may be possible to split it up in and a part with more general tags 
(e.g. name, ref, operator, distance, ...) that are also used with other 
kinds of routes (e.g. for 
route=running;bicycle;mtb;horse;piste;inline_skates), so that this can 
be used there too, and in a part with hiking/walking specific tags (e.g. 
network, educational).


On 13.08.2019 12:31, Paul Allen:
On Tue, 13 Aug 2019 at 09:52, s8evq > wrote:


Would it not be easier and more clear if we just keep one, and add
a link to it in the others?


A principle used in programming is "DRY."  Don't repeat yourself.  
Maintaining the same
code in two or more places will cause problems down the line when one 
version gets

changed and the other does not.

Documentation is a little different, because you often wish the same 
information to appear
in several places.  This is the case where the documentation is 
extensive but people
assume that everything they need to know about a topic will appear in 
one place.   OTOH,
the desirability of not repeating yourself increases a lot when you 
have many translations

of the material.

One way of handling this is a link.  Another way of doing it offered 
by the wiki is transclusion.

See https://en.wikipedia.org/wiki/Wikipedia:Transclusion and
https://en.wikipedia.org/wiki/Wikipedia:Transclusion/How_Transclusion_Works
(the first of those two links transcludes the second of those links, 
just so you can see how

it looks).

There are arguments against each way.  If you link to a full page then 
the poor user
encountering the link has to wade through that full page to find the 
table.  If you transclude
then those wishing to edit the page, or even the transcluded material, 
may find it
difficult to figure out how to do it.  You could, of course, put the 
table in its own page and
link to that, which avoids the editing problem and the information 
overload problem, but
still means more clicks and page loads are required than reading a 
page with a

transclusion.

Up to you which one you go with.  Note that at some point in the 
future, somebody may
decide that whichever way you chose to do it was wrong and edit it to 
do it differently. :)


--
Paul



___
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] Merging tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes