Re: [Tagging] free_standing_emergency_department, amenity or clinic ?

[Nita Rae Sanders]

On 5/1/19, Graeme Fitzpatrick  wrote:
>> On 5/1/2019 7:47 AM, Nita Rae Sanders wrote:
>> > Have we reached the conclusion that a new tagging value is needed ?
>>
>
> Getting there!
>
>
>> > If so, what is the schema for the new value ?
>>
>
> Still being discussed
>
>
>> > Can we move on to a vote ?
>>
>
> Not yet!
>
> On Thu, 2 May 2019 at 01:41, Jmapb  wrote:
>
>> Personally I'm okay with continuing to use
>> healthcare=centre+healthcare:speciality=emergency.
>>
>> I'm warm to the idea of a healthcare=department tag, but I don't know if
>> it fully expresses the importance of a standalone emergency department.
>>
>
> I did suggest healthcare=emergency the other day.
>
> Was thinking about swapping it around to emergency=medical or something
> similar, but then just saw emergency=emergency_ward_entrance
> https://wiki.openstreetmap.org/wiki/Tag:emergency%3Demergency_ward_entrance
> ,
> which has been used 600 times.
>
> How about changing that to either just =emergency_ward or
> =emergency_department?
>
> Unfortunately, it apparently only currently renders as a normal entrance,
> without the medical colour scheme. As I also mentioned that could be
> rendered as A-E using the hospital white on red colours.
>
> To muddle things further, there's a possibility that healthcare=* POIs
>> will stop rendering in the default style,
>
>
> That will be somewhat annoying :-(
>
>  Thanks
>
> Graeme
>
 My view is that we should focus on getting the schema, keys and
attributes correct, and worry less about the rendering. If the
rendering is not doing the desired thing, then we open a ticket about
that issue, and let the rendering folks deal with it. Right now, I am
more concerned with getting some form of consensus about what the
correct tag=value should be, such that anyone down the road can
quickly understand the meaning of same.

The facilities in question are both a remote appendage to a large
hospital, and a stand alone destination in their own right. The
article I linked up thread makes it clear that a few of these
facilities exist without the major hospital connection, but they are a
very small minority. In Florida, I do not believe they exist at all
(due to state licensing requirements).

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

Re: [Tagging] free_standing_emergency_department, amenity or clinic ?

[Graeme Fitzpatrick]

> On 5/1/2019 7:47 AM, Nita Rae Sanders wrote:
> > Have we reached the conclusion that a new tagging value is needed ?
>

Getting there!


> > If so, what is the schema for the new value ?
>

Still being discussed


> > Can we move on to a vote ?
>

Not yet!

On Thu, 2 May 2019 at 01:41, Jmapb  wrote:

> Personally I'm okay with continuing to use
> healthcare=centre+healthcare:speciality=emergency.
>
> I'm warm to the idea of a healthcare=department tag, but I don't know if
> it fully expresses the importance of a standalone emergency department.
>

I did suggest healthcare=emergency the other day.

Was thinking about swapping it around to emergency=medical or something
similar, but then just saw emergency=emergency_ward_entrance
https://wiki.openstreetmap.org/wiki/Tag:emergency%3Demergency_ward_entrance ,
which has been used 600 times.

How about changing that to either just =emergency_ward or
=emergency_department?

Unfortunately, it apparently only currently renders as a normal entrance,
without the medical colour scheme. As I also mentioned that could be
rendered as A-E using the hospital white on red colours.

To muddle things further, there's a possibility that healthcare=* POIs
> will stop rendering in the default style,


That will be somewhat annoying :-(

 Thanks

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

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Graeme Fitzpatrick]

Pretty good Joseph, but I'd suggest going a bit further by changing this
bit:
On Wed, 1 May 2019 at 18:18, Joseph Eisenberg 
wrote:

> "Verifiability is an important concept to OpenStreetMap

to "a vital (or even the vital?) concept ..." to stress how important it is.

Thanks

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

Re: [Tagging] Handicap Parking Access Aisles

[Clifford Snow]

On Wed, May 1, 2019 at 11:47 AM Mateusz Konieczny 
wrote:

>
> 1 May 2019, 20:11 by cliff...@snowandsnow.us:
>
>
> On Tue, Apr 30, 2019 at 9:13 PM Warin <61sundow...@gmail.com> wrote:
>
>
> highway=footway wheelchair=yes ... would be in keeping with present
> tagging of wheelchairs in OSM. ???
>
>
> wheelchair=yes doesn't capture the specific nature of the access_aisle.
> Most any footway could be wheelchair=yes, only only areas designed for
> unloading vans in a handicap parking space would have the tag
> highway=footway+footway=access_aisle.
>
> This would allow van navigation right to a parking lot with an access
> aisle.
>
> highway=footway wheelchair=designated may be worth considering
>
> Note that footway=access_aisle is not making clear that it is for
> wheelchairs -
> there are access aisles footway used for say unloading deliveries
>

Since the off loading area is called an access aisle, both in the US and UK
[2], it seem to me that it would be an appropriate term to use.  Would
using highway=footway + footway=access_aisle +  wheelchair=yes be a more
acceptable tagging scheme? My concern is that just adding wheelchair=yes to
a footway doesn't get at the requirement for the width of the access_aisle.


[1]
https://www.access-board.gov/guidelines-and-standards/buildings-and-sites/about-the-ada-standards/guide-to-the-ada-standards/chapter-5-parking
[2]
https://researchbriefings.files.parliament.uk/documents/SN01360/SN01360.pdf

Best,
Clifford

-- 
@osm_washington
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Handicap Parking Access Aisles

[Mateusz Konieczny]

1 May 2019, 20:11 by cliff...@snowandsnow.us:

>
> On Tue, Apr 30, 2019 at 9:13 PM Warin <> 61sundow...@gmail.com 
> > > wrote:
>
>>
>> highway=footway wheelchair=yes ... would be in keeping with present
>>  tagging of wheelchairs in OSM. ???
>>
>
> wheelchair=yes doesn't capture the specific nature of the access_aisle. Most 
> any footway could be wheelchair=yes, only only areas designed for unloading 
> vans in a handicap parking space would have the tag 
> highway=footway+footway=access_aisle. 
>
> This would allow van navigation right to a parking lot with an access aisle. 
>
highway=footway wheelchair=designated may be worth considering

Note that footway=access_aisle is not making clear that it is for wheelchairs -
there are access aisles footway used for say unloading deliveries

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

Re: [Tagging] Handicap Parking Access Aisles

[Clifford Snow]

On Tue, Apr 30, 2019 at 9:13 PM Warin <61sundow...@gmail.com> wrote:

>
> highway=footway wheelchair=yes ... would be in keeping with present
> tagging of wheelchairs in OSM. ???
>

wheelchair=yes doesn't capture the specific nature of the access_aisle.
Most any footway could be wheelchair=yes, only only areas designed for
unloading vans in a handicap parking space would have the tag
highway=footway+footway=access_aisle.

This would allow van navigation right to a parking lot with an access
aisle.

I admit I was kind of lazy when I sent this email. Sending a complete
proposal would have been better, and I'm willing to create one, but this
seemed like a no-brainer to me.

Best,
Clifford
-- 
@osm_washington
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] free_standing_emergency_department, amenity or clinic ?

[Jmapb]

On 5/1/2019 7:47 AM, Nita Rae Sanders wrote:

Have we reached the conclusion that a new tagging value is needed ?
If so, what is the schema for the new value ?

Can we move on to a vote ?

TIA


Personally I'm okay with continuing to use
healthcare=centre+healthcare:speciality=emergency. But... I'm not
*thrilled* with it because it doesn't really fit the wiki's description
for centre ("group of medical practices") and because there's general
ambiguity about how healthcare=centre fits hierarchically. I've seen it
used for large clinics, for hospitally things that don't quite quality
as hospitals (like these standalone ERs), for hospital departments with
"Center" in their name, for entire hospitals with "Center" in their
name, and finally for large medical complexes that contain multiple
healthcare=hospital features.

I'm warm to the idea of a healthcare=department tag, but I don't know if
it fully expresses the importance of a standalone emergency department.

To muddle things further, there's a possibility that healthcare=* POIs
will stop rendering in the default style, at least for a few months
while some bugs are worked out.  See
https://github.com/gravitystorm/openstreetmap-carto/pull/3731

J


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

Re: [Tagging] Wiki page for natural=mountain_range

[Kevin Kenny]

On Wed, May 1, 2019 at 8:52 AM Paul Allen  wrote:
> There is a reason it's called a saddle.  It's because it's shaped like one.  
> It is a low point between
> two high points but it is also a high point between the lower area 
> encompassing the high points.
>
> Mathematics uses a similar definition, and the diagram on the WIkipedia page 
> may be helpful
> in visualising what is meant: https://en.wikipedia.org/wiki/Saddle_point
>
> For the technical definition of landform saddles, see
> https://en.wikipedia.org/wiki/Saddle_(landform)

Not all gaps are saddles in that not all of them are higher on both
sides (consider a plateau ringed by mountains, with a valley exiting
one side. There's a clear gap between the mountains, but a continuous
descent in the valley floor).
https://kbk.is-a-geek.net/catskills/test4.html?la=42.1230&lo=-74.0679&z=14
- Platte Clove (the canyon, not the settlement) is definitely a gap in
the Catskill Escarpment, but the saddle point is some distance to the
west, near Prediger Road.
https://kbk.is-a-geek.net/catskills/test4.html?la=42.1766&lo=-74.0478&z=14
is somewhat more extreme - Kaaterskill Clove is clearly a gap in the
range, but the saddle is west of Haines Falls. The reason these gaps
aren't saddles is that the valley on one side of the escarpment is 600
metres higher than on the other, with the peaks another 600 metres
above that, so that there's a clear mountain range being split but no
climb into the gap from the high side.  The higher gaps in the
Escarpment don't have this issue because they're above that valley
floor - Windham Pass
https://kbk.is-a-geek.net/catskills/test4.html?la=42.3348&lo=-74.1627&z=15
or Dutcher Notch
https://kbk.is-a-geek.net/catskills/test4.html?la=42.2487&lo=-74.0754&z=15
have well-defined saddles.

Because of the plethora of nearly-interchangeable terms used in my
part of the world (pass, gap, water gap [a gap with a stream or river
running through it], wind gap [a gap without a stream or river],
saddle, notch, clove), mountaineers around me pretty consistently use
'col' for the saddle point (and, by extension, the relatively flat
area surrounding it) between two peaks. "There's a nice campsite in
Jimmy Dolan Notch, the col between Indian Head and Twin Mountain"  "To
descend to the Neversink River, follow the ridge west from Rocky
Mountain until you get to the col, and then explore to the north for a
drainage that starts near it."

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

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Martin Koppenhoefer]

sent from a phone

> On 1. May 2019, at 10:17, Joseph Eisenberg  wrote:
> 
> - A tag/value combination and geometry is verifiable if and only if
> independent users observing the same feature would make the same
> observation every time.


every time means under the same circumstances, there are features that are not 
always present but only on a schedule (opening hours is typically used). Or the 
coastline changes periodically with the tides. Or intermittent waterways.



> 
> - Objective criteria, clearly documented on the wiki, help to make
> tagging verifiable by individual mappers.
> 
> Examples 
> 
> Objective Criteria: e.g. Building Height 


e.g. the building height isn’t sufficiently defined to get to the same results 
every time you measure it, because it is not defined where to measure it (which 
ground elevation is the relevant one)

Cheers, Martin 

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

Re: [Tagging] Wiki page for natural=mountain_range

[Paul Allen]

On Wed, 1 May 2019 at 05:29, Warin <61sundow...@gmail.com> wrote:

>
> SADDLE = low point between two high points (mountains), it does not
> descend near the level of the adjacent valleys.
>

There is a reason it's called a saddle.  It's because it's shaped like
one.  It is a low point between
two high points but it is also a high point between the lower area
encompassing the high points.

Mathematics uses a similar definition, and the diagram on the WIkipedia
page may be helpful
in visualising what is meant: https://en.wikipedia.org/wiki/Saddle_point

For the technical definition of landform saddles, see
https://en.wikipedia.org/wiki/Saddle_(landform)

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

Re: [Tagging] Status of oneway=cw oneway=ccw

[osm]

s8evq skrev den 30.04.2019 20:18:

Helo everyone. I would like to pick up this month old discussion again
and try to come to a conclussion.

The situation so far:

Problem: There are signposted hiking and biking routes, where the
route itself goes only one way, because it's not way-marked in the
opposite direction. How do we add that information in OSM?

Current solution: oneway=yes. Not preferred by many on this list, as
oneway should indicate a legal restriction.

New solution: Some of you suggested alternative new tags, but we
didn't come to a conclusion on this yet. What I have gathered from the
various answers:

- bidirectional=no
- signed_oneway=yes
- signed_direction=yes
- designated_direction=forward|both|backward
- signed=forward|backward|both|none

Personally, I like signed_direction=yes. It's simple and avoids using
the word oneway.
Also, using the value forward|backward might not be necessary, as it's
possible to deduce this from the order of ways in the relation.


This is a false assumption. You should never rely on ways in route 
relations to even be ordered at all. OSM route relations are often 
edited by less experienced or non-technical contributors with no idea 
about ordering at all and there are also lots of cases where you can't 
even order a route in a meaningfull way.


Any other views? Anybody against replacing oneway=yes with
signed_direction=yes in the wiki pages of route=foot and route=hiking?


I happen to know the guy who came up with the oneway=cw/ccw tagging 
(https://wiki.openstreetmap.org/w/index.php?title=Tag:route%3Dhiking&oldid=1453921) 
and remember briefly discussing it with him (he mapped a ton of 
walking/hiking routes in the areas around the danish/german border).


I don't really have much of a problem with oneway=* on route relations 
(since the meaning is fairly obvious to me), but I'm not against 
replacing it (note that the inventors primary language isn't english) , 
but have to state that the cw/ccw values (I suggested 
clockwise/anticlockwise) are necessary, since there's really no other 
way to indicate which direction a circular route is better followed.


Do also note that clockwise/anticlockwise values can be usefull for 
human consumers, even though they may not be for data consumers.



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

Re: [Tagging] free_standing_emergency_department, amenity or clinic ?

[Nita Rae Sanders]

On 4/30/19, Jmapb  wrote:
> On 4/30/2019 12:13 PM, Nita Rae Sanders wrote:
>
>> On 4/30/19, Jmapb  wrote:
>>> I've mapped one of these: https://www.openstreetmap.org/node/6372786026
>>> ...
>>>
>>> It's got a very different feel from an "Urgent Care" center, which I'd
>>> tag as healthcare=clinic. It feels like a hospital department that
>>> happens to be offsite.
>> That's exactly what it is. They exist for all the following reasons:
>>
>> o Cheaper than building a whole new hospital (just to get the ER)
>> o Allow for better utilization of the inpatient care capacity at the
>> central facility
>> o Redundancy of the ER department
>> o Outreach to areas otherwise poorly served
>> o Reduction of time for ambulance pickup to ER arrival (and to patient
>> stabilization)
>> o Functionally equivalent to an onsite ER department, with the
>> exception of Trauma handling
>>
>> There are now more off-site ER departments in Florida, than on-site ER
>> departments.
>
> I've contemplated a healthcare=department tag, for mapping complex
> hospital campuses. This could also be useful for offsite departments
> like these ERs.
>
> J
This article, from 2016, makes it clear that a FSED is not a retail
medical clinic or an urgent care facility
https://catalyst.nejm.org/how-the-freestanding-emergency-department-boom-can-help-patients/

So now I have several questions …

Have we reached the conclusion that a new tagging value is needed ?

If so, what is the schema for the new value ?

Can we move on to a vote ?

TIA

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

[Tagging] Feature Proposal - Voting - camp_site=camp_pitch

[Joseph Eisenberg]

I believe the discussion about the tag camp_site=camp_pitch is now
complete here. Also see the talk page:
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/camp_site_pitch

You can now vote to approve or reject this tag. See:
https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch

Description of camp_site=camp_pitch:
"An tent or caravan pitch location within a camp site"

This proposal provides a way to tag individual pitches within a
campground or caravan site. A "camp pitch" in this context is the free
space used to place a tent or or caravan within a tourism=camp_site or
tourism=caravan_site area. Usually only one caravan is permitted in an
individual pitch, but more than 1 tent may be allowed on a single
pitch in some cases."

Please read the proposal and vote:
https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch#Voting

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

Re: [Tagging] unused tags and properties

[Philip Barnes]

On Wednesday, 1 May 2019, Warin wrote:
> Fridge, stove and sink would be handy for some camp sites ... I came 
> across one camp site with a fridge .. standing all by itself in the open 
> (with a power point connection). Most of these woiuld be 'inside' a camp 
> kitchen .. (some camp kitchens have no walls just a roof.
 
 
The other common object you find on campsites is a microwave.

Phil (trigpoint)

-- 
Sent from my Sailfish device
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Joseph Eisenberg]

Based on everyone's comments, I've tried editing the page again. Now
there are two main sections: a short section that defines "What is
Verifiability?, then all of the Examples. The main change is that I
added 2 bullet points to the "What is?" section, pulled from the 2
older examples about buildings and waterways, and I removed one of my
new examples (ridges):

"Verifiability is an important concept to OpenStreetMap. OSM data
should, as far as is reasonably possible, be verifiable. This is a
good practice guideline covering all mapping activity and a policy
governing choices we make about which tags are used and gain
acceptance."

[Contents]

What is Verifiability?

At the core, "verifiability" is that everything you do can be
demonstrated to be true or false by other mappers - the latter
hopefully implying that there has been a change on the ground that
needs mapping.

- We apply this not only to the mapping data itself, but also to the
way in which we record it - the geometries, tags and values we use to
describe objects on the map.

- A tag/value combination and geometry is verifiable if and only if
independent users observing the same feature would make the same
observation every time.

- Objective criteria, clearly documented on the wiki, help to make
tagging verifiable by individual mappers.

Examples 

Objective Criteria: e.g. Building Height 

It is desirable to have objective criteria for a user's tagging to be
verifiable. This principle applies to any observable characteristic,
be it numerical or descriptive.

For example, buildings come in various sizes. ... 

Improving verifiability by documenting values: e.g. Waterways 

Clearly documenting tags on the wiki always helps with verifiability.

... 

.

The one thing that could make the page shorter would be to cut out the
"Problematic Tags" section at the end, which discusses Highways
classification and then calls out "smoothness", "sac_scale", and
"trail_visibility" as problematic. I'm not sure if these examples are
still so relevant now as they were in 2008.

But I don't see how all of the examples could be removed or moved to a
different page. The original page from 2008 was 50% example, because
defining verifiability is hard without practical examples.

On 5/1/19, Warin <61sundow...@gmail.com> wrote:
> One problem is the 'audience' is so varied.
>
> We have the beginner.. who wants basic stuff fast. No time to read details,
> get on and map!
>
> The 'expert' with an edge case or problem and wants minute detail.
>
> How to deal with them in the one document?
>
> Have sections..
>
> At the front there needs to be the basics.. for the beginners... avoid TL:DR
>
> Then as a completely separate section .. details.. verbose. Possibly these
> should be separate pages, or use the discussion page?
>
>
>
> On 28/04/19 22:43, Joseph Eisenberg wrote:
>> I could remove some of my examples and some of the other that have
>> been added since 2015, but I wonder if the page will still be
>> understood by most people without examples?
>>
>> Perhaps we could move all the examples to a later section, so that the
>> first part is relatively short and to the point?
>>
>> On 4/28/19, Andy Townsend  wrote:
>>> On 28/04/2019 10:43, Joseph Eisenberg wrote:
 Please suggest any improvements to the wording or corrections:
 https://wiki.openstreetmap.org/wiki/Verifiability#Geometry

>>> Thanks for trying to improve the documentation, but unfortunately,
>>> trying to add more detail (including specifics about particular tags)
>>> makes the page more complicated and more difficult to understand for new
>>> mappers (who are usually the people I'd point at that page with a DWG
>>> hat on).
>>>
>>> For example, compare the current version of the page with this one from
>>> 2015:
>>>
>>> https://wiki.openstreetmap.org/w/index.php?title=Verifiability&oldid=1141651
>>>
>>> The 2015 version contains a definition, an example and short "what to
>>> do" and "what not to do" sections.
>>>
>>> The current one simply doesn't do that.  Obviously there are 20 edits
>>> since that example that I picked out pretty much at random from 2015, of
>>> which yours is only the last, and the authors of each of those have seen
>>> an edge case that wasn't quite covered by the documentation, which led
>>> to them adding their new section. The problem is that while all of those
>>> extra little bits on their own have value, taken together they do make
>>> the page less useful as a summary of a key concept in OpenStreetMap.
>>>
>>> Maybe what would be better would be to try and reduce the
>>> "Verifiability" page to its original summary status but to break out
>>> some of the detail into linked sub-pages?  The whole "geometry" section
>>> would be a good candidate for that (the page already contains an
>>> example, two paragraphs above).  Also "story-telling" content such as
>>> "Someone might do this" is probably better elsewhere too.
>>>
>>> Best Regards,

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Philip Barnes]

On Tuesday, 30 April 2019, Graeme Fitzpatrick wrote:
> On Wed, 1 May 2019 at 00:46, Martin Koppenhoefer 
> wrote:
> 
> >
> > > On 30. Apr 2019, at 15:03, Colin Smale  wrote:
> > >
> > > Beware also the quest for the universal solution. Postal addressing,
> > administrative segmentation and people's affinities are separate
> > dimensions. Any attempt to force them into a single model is doomed to
> > failure, so why try?
> >
> >
> > exactly, we do have entities for all of these: addr tags for postal
> > addressing, administrative boundaries for administrative structures and
> > place for sociocultural places, and I’ve always been a defendant of this
> > distinction, but it cannot be denied that a lot of mappers add place tags
> > for settlements to administrative entities, thereby extending the
> > settlement on the whole administrative territory.
> >
> 
> Another personal example of "towns" being very spread out.
> 
> When I was a kid, my Auntie & Uncle ran a sheep station ("ranch") in
> Western Queensland. They were ~40 km out of town (Blackall), but their
> postal address was Avondale, Blackall & their phone number was Blackall
> 104K (does anybody overseas even know about manual party lines? - & for
> that matter, does anybody else in Australia remember them? :-))
> 
I'm in the UK and remember party lines,.sometimes when you picked up the phone 
we would hear our neighbours talking on the phone and would have to wait. 
People calling us would get an engaged tone if the neighbours were using the 
phone.

Phil (trigpoint)

-- 
Sent from my Sailfish device
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki page for natural=mountain_range

[Joseph Eisenberg]

"a pass was simply a saddle that was a convenient route for travel."

Yes, usually.

But not all passes are saddles. A saddle is a specific topographical
feature: the lowest point on the ridge line between two higher areas.
It's also called a "col" (from French), especially in the Alps. Like a
peak, a saddle is a single point.

A pass is any "navigable route through a mountain range or over a
ridge", so it's always a point on a path or road:
https://wiki.openstreetmap.org/wiki/Tag:mountain_pass=yes

Often the location of the pass on the highway is a few meters away
from the exact point of the saddle, for example, if the road has to
curve while crossing the ridgeline. Other times there are named passes
which cross a ridge at a fairly high point, far away from a saddle.

"Be aware that highways don't always go exactly through the saddle
point, so that the highest point on the highway and the saddle point
can have different positions."

So a mountain pass is any place where a road or path passes over a
ridge, whether at a saddle or not

On 5/1/19, Tod Fitch  wrote:
>
>> On Apr 30, 2019, at 9:28 PM, Warin <61sundow...@gmail.com> wrote:
>>
>> Depends?
>>
>> Warning - my interpretation!
>>
>> SADDLE = low point between two high points (mountains), it does not
>> descend near the level of the adjacent valleys.
>>
>> PASS =A gap in a range of mountains or hills permitting easier passage
>> from one side to the other, it descends near the level of the adjacent
>> valleys.
>>
>> This gives me a difference between 'pass' and 'saddle',otherwise they
>> appear to be the same?
>>
>>
>> If it were a 'pass' then that would make the range into two separate
>> ways.
>> If it is a saddle then it does not break the range, but forms part of it.
>>
>> Some mountain ranges do not have crest along their entire length .. yet
>> they are a mountain range along the entire length.
>>
>
> Hmmm. Then many of the passes, including Donner Pass and Tioga Pass, in
> California’s Sierra Nevada are actually saddles?
>
> I’ve assumed that a pass was simply a saddle that was a convenient route for
> travel.
>
> Looking at
> https://www.vividmaps.com/2018/11/gap-vs-pass-vs-notch-vs-saddle.html
> 
> maybe the difference between pass, saddle, gap and passage - at least in the
> US - is mostly a difference in regional dialect. In which case I guess OSM
> can do its usual and try to formalize the use and definition of one that
> most closely matches UK usage.
>
>
>

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