Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit

[Kevin Kenny]

On Sat, Jan 27, 2024 at 7:06 PM Greg Troxel  wrote:

> As someone not happy about the deprecation of mailinglists, a few brief
> comments here:
>
>   First, I think this proposal is fine, as documenting widespread
>   practice.  Regardless of my further comments, I think it's solidly
>   progress to adopt it.
>
>   While yonur comments about survey feet are valid, modern elevations
>   (NAVD88) are as far as I can tell actually in meters, and when
>   expressed in feet, in international feet.  Elevations are small enough
>   that 2 ppm is less than the errors in the values.
>
>   I would expect the proposal to give an example.  It seems that one
>   would have a tag
> ele=6288 ft
>   for Mount Washington (showing my East Coast bias).
>
>   It would be good to explicitly state that in keeping with convention,
>   ft means international feet, perhaps with a parenthetical comment that
>   if someone meant US Survey Feet they would have written ftUS.   Maybe
>   this is already documented.
>

As far as I know, Survey Feet are used only for horizontal measurements,
mostly in state plane coordinates. And I don't think that there are yet any
elevations, anywhere, for which precision to 2 parts per million matters.


>   Further, WGS84's first height definition is ellipsoidal height, and
>   that simply is not elevation.  Obviously elevation should be in "WGS84
>   Orthometric Height", which is what GPS receivers provide as elevation.
>   But elevations are not published in WGS Orthometric Height; they are
>   published in a national or regional datum which is pretty close, as
>   all datums at least roughly target a similar origin.
>

In newer datums than WGS84, even horizontal position is reported relative
to an epoch, with corrections for phenomena like continental drift. I've
hiked to one of the stations used for such geodesy - a copper bolt placed
in 1870 in truly ancient and stable rock (Hawkeye Gneiss, ~1.15 Ga) with
accuracy that would have been considered first-order even a century after
its placement.

The difference between survey feet and international feet for horizontal
coordinates is significant, because in UTM coordinates, the 2
part-per-million error adds up to 20 metres in the polar regions (or 10 or
so in the mid-latitudes).  It's somewhat less significant over the smaller
range of state plane coordinates, which is why most states don't plan to do
anything about it until 2025 at the earliest. In a few 'bad' planes like
Nevada North and Michigan East, the origins are far enough outside the
state that the errors can be about 15 m.

Many "authoritative, official" data sets that I've worked with appear to
suffer from mixed horizontal datums, with NAD27 coordinates mistakenly
transferred over into WGS84 uncorrected. When working with county tax maps,
for instance, I always try to spot-check things like street intersections
or monumented corners, to make sure what datum I'm working with, because
it's often not what the map claims to be. Sometimes the error is backward -
the county has never made the conversion of its systems off of NAD27, but
WGS84 data have crept in!

But for vertical coordinates, I'm willing to wager that no mapper has the
technology to measure absolute elevation to less than a mm. In fact, I
doubt that it's even meaningful to discuss that sort of precision in
elevation. The geoid isn't defined to that accuracy.  So I can easily live
with the ambiguity in which 'ft' are used.  (Moreover, I can't think of any
OSM tag at the moment in which a measure in feet would need a few parts in
10**-6 precision.)

I'd certainly approve of a proposal optionally to tag elevations with the
vertical datum used - but since the differences are typically on the order
of 1-2 metres, I surely don't insist on such a tag!  I understand that most
GPS units use GRS80+EGM1984, but I'm sure that NAVD88 has crept in, even
among objects that I've mapped.  And I betcha there's a ton of uncorrected
NGVD1929 in TIGER. For a metre or two, who cares (yet?).

 But I'll roundly condemn anyone who confuses height-above-ellipsoid with
elevation!  (I'm looking at you, Android Location Services!)

Changes in vertical datum together with LIDAR data have wrought confusion
among some of the hiking clubs around here, who maintain lists like the
Adirondack 46'ers (the 46 summits in the Adirondacks thought at the time of
the list's compilation to exceed 4000 feet elevation) or the Catskill
3500's (the 34 summits thought at the time of compilation to exceed 3500
feet, plus Leavitt Peak - which had escaped the notice of the people who
compiled the list, and minus Doiubletop and Mt Graham - which are now
off-limits to hikers). The uniform decision of the clubs was to ignore the
problem and simply say that the lists are by now traditional - it's _these_
summits, and no others. Most Adirondack 46'rs also climb Mt MacNaughton,
which was not on the list, but was revealed in a 1953 survey to exceed 4000
feet.  But then the change 

Re: [Tagging] Proposal: Use description instead of name for route relations

[Kevin Kenny]

On Sat, Oct 7, 2023 at 4:50 PM Andrew Hain 
wrote:

> I have started a new proposal: that the name tag should be restricted to
> the same meaning for route relations that it has on other elements and that
> the description tag should be used otherwise.
>

The proposal is unclear and appears to deprecate route and way names of a
form that are common around here for what I consider to be good reasons.
(In any case, 'description' appears to be an inappropriate tag for whatever
it is you are proposing.) More details on the talk page.
-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Route names being applied to tracks/paths

[Kevin Kenny]

On Fri, Dec 30, 2022 at 10:20 PM stevea  wrote:

> I have mapped perhaps tens of thousands of miles of bike routes in OSM.
> Yes, really.  I don't do this sort of "apply the name of the route to the
> element track/path."  We shouldn't.
>
> Zeke's example is excellent and is a good reason for "route element
> naming" to be "case by case" rather than there be a "one-size-fits-all"
> approach, which simply cannot work for all cases.  There are other examples
> (let's stick with bicycle routes) where it won't be a residential street,
> but a path which is specifically unnamed, but IS part of a route relation
> (which DOES have a name), as well as (almost?) every combination that can
> be thought of.  If the path is unnamed, LEAVE it unnamed, even if it is
> part of one or more route relations.  Indeed if it is part of one route
> relation, you might think you should name it, though, you shouldn't.  If it
> is part of MORE than one route relation, you might think there is ambiguity
> and shouldn't name it, but Zeke presents us with an example where "the
> dominant" (I paraphrase what I think he means) route name DOES (happen to)
> influence the naming of the element way, but that is very much a "local
> rules apply" situation.  In fact, I am of the strong opinion that ONLY
> "local rules apply" and OSM must strive to "name" things (like this, in
> relations) on a case-by-case basis.  Because one-size-fits-all doesn't work
> in our real, messy world.
>

There are certainly cases where the route and the path are named alike.  I
understand hiking trails better than I do bicycle routes, but for example
the Northville-Placid Trail https://www.openstreetmap.org/relation/4286650
has many member ways that are signed with its name. (It has a
characteristic marker, seen in
https://cdn.securem2.com//commonimages/pages/2022/4/ntptrailsign.jpg).  Its
off-road segments are named with the route name because that's how they're
signed.

For the relatively short stretches like
https://www.openstreetmap.org/way/20092775 where the trail follows a road,
the segments are of course tagged with the name of the road rather than the
name of the trail. (The markers continue, on utility poles, signposts,
guard rails or nearby trees, but the road signage is much more prominent,
and the road name is associated with street addresses.)

 https://www.openstreetmap.org/way/426361535 is named Devil's Path. It
happens to be that Long Path follows it (and is a much more important
trail) but Devi'ls Path was there first (and retains its red blaze rather
than Long Path aqua because it's the senior trail).
https://www.openstreetmap.org/way/1005078526, by contrast, was
purpose-built as part of Long Path, and is signed with that name and marked
with the Long Path's blaze. The locals call it by that name, and that's the
name it has in OSM.

I do the same thing with road routes when the road has no other name AND
has street addresses on it.  If houses on a route have addresses like "5749
Route 28" and blade signs at the intersections say "Route 28", then "Route
28" is the name of the road.  That;s pretty common in some counties around
here. In fact, I consider the use of the route number in the street
addresses to be quite strong evidence that the name of the route is the
name on the ground. It's especially important to carry the name through
concurrences. The buildings along https://www.openstreetmap.org/way/44965854
had addresses like '41158 State Highway 28' - NY 30 runs concurrently but
does NOT lend its name to the road.
https://www.openstreetmap.org/way/236739253 gives the name 'State Highway
30' to its street addresses, and NY 206 does not. Leaving these segments
nameless would give navigation software no guidance on what to call them.

If there's no name other than the route number, there are no street
addresses, and there's no signage other than the route markers, the way is
nameless.  That's most motorways and some rural highways.


Steve is right that the world is messy.  Around me, a simple rule that "a
way that is named the same as its route is actually nameless" is a bad
rule, and "a way is always named the same as its route" is just plain
wrong.  There's little harm done by the occasional redundant name. I
suspect a general rule like what Warin proposes might work well in a tidier
country than the US. Unlike some places, our places and names have grown
organically and chaotically. We don't have everything all neatly catalogued
back to the year 1086.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] building=entrance

[Kevin Kenny]

On Mon, Dec 12, 2022 at 3:51 PM Jmapb  wrote:

> On 12/12/2022 2:28 PM, Martin Koppenhoefer wrote:
> > Following a JOSM discussion I wanted to ask here, if someone else is
> > using building=entrance to tag entrance buildings.
> >
> > It is a term that seems well introduced and understandable, so there
> > is not much hindering people from using it, just that there was the
> > bad practice to use the same tag on nodes for what is now done with
> > the "entrance" key.
> > sorry, missed the link https://josm.openstreetmap.de/ticket/22570
> >
> > any comments on the tag? Someone else using it for buildings?
>
> Two thoughts offhand:
>
> 1) I feel pretty strongly that any value of building=* should refer to a
> type of building. To me, building=entrance would sound like an attempt
> at tagging something similar to building=gatehouse.
>
> 2) building=* on a node is just fine; we don't always have sufficient
> aerial imagery or other data to discern an acceptable footprint. (That's
> on a freestanding node of course; building=* on a node that's part of
> another building's perimeter would be a problem.)
>

I seldom if ever use `building=entrance` for anything.  Routing and
rendering appear to work just fine with `entrance=*`, as on the four
entrances to https://www.openstreetmap.org/way/1117519651

If this usage is incorrect, then we probably need to raise issues with the
various editors, since JOSM at least has never warned me of underspecified
tagging on these.


-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - highway=scramble

[Kevin Kenny]

On Thu, Sep 15, 2022 at 6:12 PM Martin Koppenhoefer 
wrote:

> here is an example for a mountain situation where you should probably have
> the right shoes, and someone in sneakers of flip flops, or pushing (well,
> carrying at this point) a baby stroller would have a hard time, but it
> wouldn’t qualify for scramble or via ferrata:
>

yeah, looks like a YDS class 2, or `sac_scale=hiking`.  Maybe
`mountain_hiking` if that talus is unstable, because then you start to need
some technique. I know some runners who would do that barefoot, but I think
they're nuts.

Do we need `sac_scale=no` for `paved path in a city park`?

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - highway=scramble

[Kevin Kenny]

On Thu, Sep 15, 2022 at 2:53 PM Janko Mihelić  wrote:

> čet, 15. ruj 2022. 19:57 Peter Elderson  je napisao:
>
>> I know, but the scale does not indicate specific things you encounter,
>> just that somewhere along the way you will be challenged.
>>
>
> That isn't true. If you tag a relation with sac_scale, then it is as you
> say. But if you tag a way with sac_scale, then this says "this sac_scale is
> exactly here, along this whole way".
>

Or at least "you can't hike this section if you're not up to handling this
sac_scale."  I don't usually bother breaking up a way by scale if there are
no intersections or PoI's along it.  There may be flat spots in among the
scrambles, and I generally don't bother trying to distinguish them.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - highway=scramble

[Kevin Kenny]

On Thu, Sep 15, 2022 at 12:10 PM Sarah Hoffmann via Tagging <
tagging@openstreetmap.org> wrote:

> To get this mess sorted out we should probably start with the discussion
> 'what is a hishway=path'. The current definition in the wiki is
> not helpful in any way. It basically says that anything can be a path,
> i.e. a way with only highway=path carries no information at all.
>

There's a saying in some hiking communities in the US:  "They call this
thing a trail."

The trouble with all the classifications is that they are subject to over-
and under-grading, and I'm afraid I don't have a good way to work around
that.

I think of one trail that I've been on multiple times that I've had
arguments about the grading of.  Some sample garden spots on that trail are
here. They're probably not the most difficult since they were places where
my daughter or I felt secure enough in our footing to pull out a camera.

https://flickr.com/photos/ke9tv/51335515628 - note the tall-ish man (me)
standing at upper right. You can see that the rock slab is totally covered
in tool marks!
https://flickr.com/photos/ke9tv/51334609512 - another treacherous slab -
covered with black ice in mid-October
https://flickr.com/photos/ke9tv/51336071749 - not horribly difficult, but a
slip could very well be fatal (and hikers have indeed died falling on that
trail)
https://flickr.com/photos/ke9tv/52336974320 - because the stuff just keeps
right on coming at you
https://flickr.com/photos/ke9tv/52360038196 - every bit as vertical as it
looks. You can see the red trail marker on the tree.

That trail has a very poor safety record - it's been called the most
dangerous hiking trail in the US - partly because of its reputation for
difficulty and danger. It draws people from New York City, with relatively
little hiking experience, who are looking to prove something. It's a point
of pride among some hikers to have done the whole 40 km (with about 2800 m
of elevation gained and lost again) in under 24 hours. I've never tried.
I'm an old man and know my limits.

For what it's worth, I'd carry technical ice gear on that trail pretty much
at any time between mid-October and mid-May.  It's a totally different game
in winter, and up in the hills winter comes early and stays late.
https://3.bp.blogspot.com/-oOi7vvpUt0Q/VJnktGwmMDI/BoY/xYpcKlxPPqI/s1600/DSC_3880.JPG
is a typical scene - that was the ledge where we were switching from
snowshoes and ski poles to crampons and ice axes. (Oops, wait, that's a
different trail. Same mountain range, though.)

Again, for what it's worth, my daughter and I encountered one party
speaking Hoch-Alemannisch among themselves. (Or Schyzertütsch? I find that
general set of accents pretty incomprehensible, my German isn't very
good.)  The one with the best English said to me, "These mountains aren't
very high, but they're _demanding!_"  (I figure that if someone from the
actual Alps is saying that, they're probably demanding.)

One guidebook says of one section: "The rock is sound, holds are plentiful,
and route-finding is easy. Nevertheless, exposures are dramatic, and less
confident parties may wish to use a rope."

What SAC scale?  I've had arguments about that before.  I've had people
solemnly assure me that the trail is mere 'hiking' - and others tell me
that it has definitely crossed over beyond 'demanding mountain hiking' into
'alpine hiking'.  I'd put it into class 4 on the Yosemite scale (which,
being an American, is what I know best).  But a great many climbers believe
that class four is a myth:
https://www.summitpost.org/class-four-is-a-myth-problems-in-yds/891794. The
hardest moves are probably in the 5.3 or 5.4 range (again on the Yosemite
scale), but they're not exposed. My guess is that The Powers That Be are
willing to blaze it as a hiking trail because the hard moves aren't exposed
and the exposed moves aren't hard.

It's a hard problem.  Experienced climbers think nothing of this stuff, and
put it all in the "not interesting" bucket.  But they're the only ones with
enough experience to grade the trail accurately. What you need is grading
from an experienced _guide_, well versed in assessing trail difficulty with
respect to the ability and experience of clients.  But you don't get a lot
of those people mapping.

Instead, you have trails graded by folks like
https://youtu.be/k8XmjebwoQw?t=110 "You all right?" and
https://youtu.be/k8XmjebwoQw?t=134 "Holy sh*t!" who run on rock that I
climb - or by duffers (by comparison with those guys, at least!) like me.
Whose definition of 'scramble' should prevail?

Disclaimer. I'm terrible at climbing. I decided a long time ago that I was
going to stay terrible at climbing because the folks who get good at
climbing seem to have an unfortunate habit of winding up dead. I have a
good time Out There limiting myself to 'technical hiking' as opposed to
'real climbing.'

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

[Kevin Kenny]

On Thu, Dec 24, 2020 at 10:10 AM Paul Allen  wrote:

> Yes, we already have fee and access which can cope with these things.
> What we didn't have was an understanding in the US that such tags
> were even applicable or that anyone might wish to map fishing
> features on rivers, especially pools that don't "bulge" enough to
> be obvious from aerial imagery but which are obvious from
> detailed measurement (using, say, a rod, line and float) on
> the ground.  The legislation affects the degree to which
> such details become public knowledge.
>

Yeah... but...

Don't think we don't understand that we can apply the tags; we just don't
often need them.

 The New York State-owned lands have pretty uniform rules for hunting and
fishing; for these, I follow 'don't tag the local legislation'.

The New York City ones vary all over the place, and the import of those
tags them specifically. For instance, in the case of
https://www.openstreetmap.org/way/481482895 there is,

`foot=hunting;fishing' - public foot access allowed only for the stated
purposes.
'hunting=permit fishing=permit trapping=no' - a permit is required for
hunting or fishing; the setting of traps is prohibited.
`NYSDEC:wildlife_management_unit=3H` - the specific state Wildlife
Management Unit that hunters must consult.
`website=*` - link to lots more information, including, of course, how a
permit may be obtained.

https://www.openstreetmap.org/relation/6304851 has similar tagging, but
declares that you don't need a permit to fish there. (Or to enter on foot
for other reasons, but I find it hard to imagine why you'd want to go
plooshing about in that marsh if it weren't to fish.)

We do have facilities devoted to fishing access, such as
https://www.openstreetmap.org/relation/6396542 -- which doesn't render
because there's no good "tag for the renderer" approach. (That one's not
got access constraints shown because it's free to all comers; of course,
anglers over 16 need a state fishing license.)

Essentially all of our Wildlife Management Areas are devoted to the
preservation of habitat for game fish and for wild game for hunters. (
https://www.openstreetmap.org/relation/6367671 is an example. There are a
great many of these.)  Once again, these are free to all comers. These are
supported financially by the revenue from the sale of hunting and fishing
licenses and by a tax on arms and ammunition.

There are some of our State Forests, for example
https://www.openstreetmap.org/relation/7229593, that I can't imagine why
you'd trouble to visit if it weren't to fish. (Note the adjacent presence
of https://www.openstreetmap.org/way/429194108.)

I can easily see how 'access=private', 'access=fee' and so on would apply
to fishing spots. I just haven't had occasion to map any.

You're right that I haven't mapped a lot of specific fishing spots, but
that's partly because they're so numerous.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

[Kevin Kenny]

On Wed, Dec 23, 2020 at 1:08 PM Paul Allen  wrote:

> On Wed, 23 Dec 2020 at 17:28, Kevin Kenny  wrote:
>
>> On Wed, Dec 23, 2020 at 7:17 AM Paul Allen  wrote:
>>
>> British anglers must be different from American ones. Most fishermen that
>> I know don't want their favorite fishing holes to be mapped! They'll tell
>> you where they are if you're really nice and ply them with a pint or three,
>> but will then swear you to secrecy!
>>
>
> The good places for certain types of fish require permits.  Angling
> associations make their money by selling permits to waters they control.
>
> Teifi Trout Association maps: https://teifitrout.co.uk/tta-waters/
> and permits https://teifitrout.co.uk/tta-shop/fishing-permits/
>

Ah.  Around here, the best freshwater fishing is mostly on public land.
Since the anglers can't sell permits, they keep the choice places to
themselves. (A handful also work as wilderness guides. :) )

Around here the fishermen have names for some of the pools too, such as
Bear Hole https://www.flickr.com/photos/ke9tv/14799397098, Devil's Kitchen
https://www.flickr.com/photos/ke9tv/7082920415, Rat Hole
https://youtu.be/2rCKgEum2FQ?t=39 and Fawn's Leap
https://youtu.be/2rCKgEum2FQ?t=77  (Oh, yeah, did I mention that the cliff
divers have names for them, too?)
-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fuzzy areas again: should we have them or not?

[Kevin Kenny]

On Mon, Dec 21, 2020 at 3:38 PM Anders Torger  wrote:

> I think it's more about that most OSMers are interested in urban areas,
> street routing and stuff like that, and outdoor maps haven't really been
> much of a thing other than for simple illustrative purposes.
>
Most OSM'ers are sophisticated computer users. Most humans are interested
most in mapping the features that they interact with. Most sophisticated
computer users live in cities.

Those of us who map in the wild areas of New York State (which are
surprisingly large; the Adirondack Park is slightly smaller than Belgium;
larger than New Jersey, Massachusetts or Slovenia), deal with the problem
of "too much ground to cover, too few people to map it."  The Adirondack
Park, for all that its land area is comparable to the states and countries
that I mentioned, has a population of only about 130,000.  Only about a
quarter of the residents have broadband service; many do not even have
land-line telephone. Cell service is spotty in the villages and nonexstent
in the back country, even on I-87 (the one freeway that crosses the park).
There are no computer geeks, because there are no computer geek jobs.  On
one mapping trip through the park, I had to plan a 100-km segment without
resupply. (The segment included one stop at a developed campground, but
nowhere to buy groceries or charge batteries!) The Catskill Park is not
quite as remote, but nearly so; it certainly has wilderness areas big
enough to get lost in.

Given the overwhelming size of the area, and the scarcity of mappers, I
don't expect the area to be mapped well in OSM. Nevertheless, for certain
features such as hiking trails, campsites, and similar amenities, OSM is
the best data source that I have.

In producing my own maps, such as what you might see in
https://kbk.is-a-geek.net/catskills/test4.html?la=44.1408=-74.1034=15,
I've had to depend on external data sources to a great extent.  Even the
external data sources are not "boots on the ground" surveys; for instance,
I know that the landcover has largely been derived from computer-based
analysis of multi-band, multi-season satellite imagery. (The multi-season
aspect allows for estimating the leaf cycle.)

This is far from an ideal rendering for outdoor maps, but it's at least an
attempt at a proof of concept.

Because I'm combining so many data sources, the map takes on rather a
'cubistic' aspect, with, for instance, many shorelines drawn for the water
bodies.  I actually find this to be an advantage in practice. If I see
shorelines that vary widely, I know that I can expect that the water level
will be correspondingly variable, according to season and level of beaver
activity.  If I see that different databases have multiple routings of a
trail giving a 'braided' appearance, I have reason to expect that the trail
in that area will be indistinct and difficult to follow.

Indeed, my chief concern in rendering (beyond things like the open problems
of better lettering of area features, suppression of river names inside
lakes, representation of features such as mountain ranges, valleys, ridges,
passes, ...) is how better to manage conflation of features when I have
up-to-date information in OSM and out-of-date information in the external
databases.  Duck Hole, for isntance, is rendering peculiarly because OSM
has it as a wetland with a rather different boundary. The Cold River dam
failed in 2011 and there are no plans to rebuild. but NLCD (National
Landcover Database) and the APA (Adirondack Park Agency)  hydrography
database have never been updated to provide that information. Nevertheless,
hydrographic features are pretty stable and those datasets are considerably
more complete (albeit less reliable) than OSM.

It's a common mistake for the urban micromappers to think that if the
country folk cared about their mapping, they'd micromap to the same level.
It's just not feasible to do so. The lack of mapping does not indicate a
lack of interest.

In any case, I hope that this side project indicates that you're not alone
in your interest in mapping outdoor recreation. Note that this particular
project is very much US-specific, owing to the fact that I'm building it
from US-specific data sources, and its iconography is also distinctly
USAian, but I think the principles could apply anywhere.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

[Kevin Kenny]

On Mon, Dec 21, 2020 at 2:15 PM ipswichmapper--- via Tagging <
tagging@openstreetmap.org> wrote:

> What do you mean by this? You would have to tag with addr:range=no, as
> that is not a default value.
>
> However, don't see this as a downside. Currently, software such as OSMand
> interprets hypenated addresses as a range anyway, so requirement to  tag
> addr:range=no would be a benefit.
>

Ouch.  So every building in Queens, NY (one of the five boroughs of New
York City, with about 2.3 million inhabitants) would need to have an
'addr:range=no' tag added in order not to break routing and navigation
there?


-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fuzzy areas again: should we have them or not?

[Kevin Kenny]

On Mon, Dec 21, 2020 at 1:56 PM Anders Torger  wrote:

> Do you think there is a valid use for fuzzy areas in outdoor/rural areas,
> or would you rather see them not being used there either?
>

I've mentioned before that I, at least, have fuzzy administrative
boundaries to deal with.

https://caltopo.com/map.html#ll=43.9281,-74.49657=14=t shows an example
of a political boundary where even the USGS topo has the callout,
'INDEFINITE BOUNDARY' - and an error of closure indicated at the north
corner of Arietta township!

(It's not just an error in aligning the map sheets.  Note that the contour
lines and water bodies align perfectly.  The old surveys simply don't line
up. Nobody cares enough to put up the substantial expense that it would
take to resolve the question.)

In the hamlet of Oxbow, the residents do care what township they inhabit
(and pay taxes to), so the town line is surveyed and monumented in the
little strip at https://caltopo.com/map.html#ll=43.43904,-74.48374=15=t
.  Most of the rest is pretty, uhm, approximate.

Historical fact: Gore Mountain
https://caltopo.com/map.html#ll=43.67821,-74.03996=14=t was so named
because it fell in the 'gore' created by the fact that the old land grant
lines failed to close, and hence didn't belong to any township.  In that
case, nobody cared for decades, until Barton discovered garnets on its
north slope.  A protracted legal battle ensued over which town had the
right to tax the mines, which was eventually resolved by resurveying the
old lines and creating the new town of Johnsburg in the gap. That's just
how we address these questions here in the US; ignore them until someone's
willing to pay to find out the answer.

The answer to 'what county contains the cluster of houses on Kings Flow (
https://caltopo.com/map.html#ll=43.68781,-74.22956=15=t)?' is obvious:
Hamilton County.  The answer to "which county contains the summit of
Chimney Mountain?" is "who wants to know?"

Topology matters. You can't answer an 'inside/outside' query without a
closed region. Whatever solution we arrive at, it ought to allow an
implementor to resolve a question like, "in what county is the village of
Indian Lake?" (Hamilton, despite its indefiite boundary!) or  "Is Port
Sudan a port on the Red Sea?" If it cannot represent the fuzzy world to the
point where that sort of question can be answered, it is an incomplete
solution. Nobody familiar with the places would have the slightest trouble
answering those questions.

I'm really reluctant to say that the solution must be to foist the problem
off on an external database.  All geodata are approximate. To say that
anything with imprecision doesn't belong in OSM is to open the door to
endless haggling over how good the survey must be before data meet OSM's
standards. Is that the path we want to take?
-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

[Kevin Kenny]

On Mon, Dec 21, 2020 at 1:41 PM Paul Allen  wrote:

> On Mon, 21 Dec 2020 at 18:13, Brian M. Sperlongano 
> wrote:
>
>>
>> "Occasionally a river or stream will form a stream pool or plunge pool,
>> which are bodies of water that naturally occur along the course of the
>> waterway. These waterbodies may either be tagged as a lake or (usually)
>> pond if they are named or significant in size, or else they can be simply
>> conflated with the river."
>>
>
> I think you need to expand a little on how to "conflate" a pool with a
> river.  The
> disadvantage of doing so is that the pool then cannot have a name assigned.
>
> Also, there are tidal pools (which may be outside the scope of the
> proposal).
>
> Is this distinction satisfactory?  How are folks tagging these features?
>>
>
> I've been tagging them as ponds, for lack of anything better.  Well,
> until a few days ago I didn't realize the distinction between ponds
> and pools so I was tagging them as ponds because I didn't know
> they weren't ponds but pools.  If I'd had to map bigger ones
> I'd have tagged them as lakes.
>
>
I've been tagging them as `natural=water`.  :)
Or maybe `waterway=riverbank.`.


In the karst terrain around here, you sometimes have to do more geologic
investigation than I have time for to determine what's actually retaining
the water in a waterbody, and there are plenty for which the distinctions
are unclear anyway. https://www.openstreetmap.org/way/226924460 appears in
origin to be a glacial tarn.  It has an outflow stream, but the majority of
the water exits through percolation (there's no identified sinkhole) into
the caves beneath, and tracers injected into the water have appeared in
several of the stream outlets below the cliffs
https://www.openstreetmap.org/way/595609787.   In a dry summer, the outflow
stream may stop flowing entirely, but the lake never dries up.  So is that
a tarn, or a doline, or (considering that humans have actually dammed the
outflow stream in an effort to preserve the boating value of the lake) a
reservoir?  Frankly, I don't care very much. I have no ambition to produce
a detailed map of the local surface geology, which is horrendously
complicated. It's a permanent body of fresh water, navigable by pleasure
boats. If someone else wants to try to fill in the geologic details, be my
guest!

I might tag as `waterway=riverbank` (the commonest usage around here) if
there's no good reason not to keep the plunge pool separate from the river,
as at the base of https://www.openstreetmap.org/node/5844315874.



-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Kevin Kenny]

On Wed, Dec 16, 2020 at 1:24 PM Tomas Straupis 
wrote:

>   This might be correct. I guess it depends on direction you look at
> it: what is exception from the reservoir rule - hard shoreline or non
> hard. I was thinking of the ways to map fuzzy shore in OSM and had the
> same idea to tag fuzzy shoreline as a line - this would be the same
> way as in your example but would need to de-emphasize rather than
> emphasize the shoreline. And I'm sure I've seen a legend with blackish
> border for reservoir, but do not remember if that was USGS or NATO map
> (reservoirs have some distinct properties worth depicting on some
> specific maps)... And I remember talking about lake/reservoir black
> border symbolisation with one of the leading cartography experts in
> Lithuania.
>

In my part of the world, the most significant reservoirs are the large ones
of the New York City water system (some of which are a couple of hundred km
from the city itself), and the Great Sacandaga Lake. They have hardened
shorelines only near the dams or where the reinforcement is needed to
protect a feature such as a highway. Otherwise, if you couldn't see the
dams (and the signage!) they'd be hard to distinguish from natural lakes.

Where I have good hydrology data, I render normal seasonal limits (by
drawing two shorelines), the presence or absence of emergent vegetation,
and the flood stage (a dashed blue line).  That makes for a pretty complex
(and somewhat 'cubistic') rendering, as at
https://kbk.is-a-geek.net/catskills/test4.html?la=43.5897=-74.6176=15,
but at least gives me some idea how likely I am to get my feet wet. (Or
drown, in the wrong season!)

I have no plans to get any of the data behind this rendering into OSM. I've
managed imports before. I might again. I'm not going to attempt one on this
scale, particularly when I'm not certain about the data quality.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Kevin Kenny]

On Wed, Dec 16, 2020 at 12:58 PM Tomas Straupis 
wrote:

>   Why? Cayaking info is pretty rare - opposite of lake/reservoir data.
> Therefore it's fine to map what you need only:
>   https://upes.openmap.lt/#17/56.296411/22.330154


Looks good, I think... but what is the tagging?

An example (with part of the hydrography and nearly all of the landcover
from non-OSM sources) follows. I'm rendering polygons of the river with a
white overlay when they are stretches of rapids.  The rapids can be short
and relatively discrete as at
https://kbk.is-a-geek.net/catskills/test4.html?la=43.3152=-73.8440=15
In the mountains, though, there may be long stretches of nearly continuous
whitewater:
https://kbk.is-a-geek.net/catskills/test4.html?la=43.3604=-74.3637=14
The last time I looked, there was no non-deprecated way to map the
information that I had.

I now see that @jeisenbe has restored the `waterway=rapids` tag to the
Wiki.

At the time I last had the discussion, the version of the page on the Wiki
looked like
https://wiki.openstreetmap.org/w/index.php?title=Tag:waterway%3Drapids=1322133
- deprecating the tag.  On the other hand, the discussion on
https://wiki.openstreetmap.org/wiki/Whitewater_sports is highly technical.
I know that I am not skilled enough at whitewater paddling (I did a little
in my youth, but my youth is quite a long time ago) to make a safe
assessment of grade, and the `Whtiewater sports' page makes no mention of
'grade=unknown'. I asked here on the mailing list, and the only answers
that I got were along the lines of "then don't map it."  So for several
years I haven't attempted to map rapids. The ones I know of and want to
render, I maintain separately from OSM, because the previous discussion had
caused me to label this feature mentally as, "OSM doesn't want this mapped."


-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Kevin Kenny]

On Wed, Dec 16, 2020 at 12:27 PM Tomas Straupis 
wrote:

>   In other maps reservoirs (US?) could have black border.


The usual symbology on USGS and DMS maps is that the black border denotes
an 'artificial shoreline', where the shore is either stabilized with riprap
or concrete, or built up with a groyne, quay or similar structure.

Sometimes I care enough to map those. (No apologies for not caring. There's
so very much around me that is unmapped that anything I do is leaving
something else undone.)  The stabilized shorelines even look decent on the
default rendering.

https://www.openstreetmap.org/#map=16/42.4601/-74.4525
https://www.openstreetmap.org/#map=16/42.4769/-74.4393

Many smaller reservoirs have artificially hardened shorelines completely
surrounding them, which could be why you thought that the symbology
distinguishes 'lake' from 'reservoir.'

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Kevin Kenny]

On Wed, Dec 16, 2020 at 11:52 AM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> Re: "natural=water' wins.  I can see that there's water there"
>
> You still have to distinguish marine water (outside of the
> natural=coastline) from inland waters, and distinguishing rivers from lakes
> is very important for proper rendering of many maps.
>

I do know that the coastline is a special case, and I know about the
'water=*' key. I fill a value in when I know the answer. I leave it out
when I don't.


> Also, many areas of natural=water actually don't have any water for much
> of the year, if they are also intermittent=yes - such as seasonal lakes in
> semi-arid areas.
>

I use that tag too.

I personally am not as concerned about water=reservoir for artificial
> lakes, but I am concerned that water=river is often forgotten when mapping
> areas of river water, where previously waterway=riverbank was clearly
> distinguished from lakes.
>
> Many map styles distinguish rivers and streams from lakes, since it is
> often helpful to use a darker color for narrow linear features.
>

That's fine. I can see that it's moving water and tag it appropriately.

If I have to figure out if a pond is karstic, glacial, man-made or
beaver-made before I can map it, it's likely to go unmapped. I can't always
see that from aerials and I can't always access the outlet to figure out
what's retaining the water.

We seem to be dividing into two camps here, as we do on many tagging
issues. One camp is, "we must have the highest possible quality. Everything
must be mapped perfectly or not mapped at all." The other is, "it's all
right to have some missing details, they can be filled in later. It's
better to fill in the picture with broad brush strokes and then go back to
add the details."The perfectionists appear to support tagging schemata
that make it difficult to map without complete research. Both sides appear
to agree that doing the research is desirable. It comes down to an
apparently irreconcilable argument over whether it's worse to have an
incompletely characterized waterbody or a blank spot on the map.

With respect to water, another concern  of mine is that our tagging schema
does not offer any way to tag that there are rapids in a river without
knowing how to grade the difficulty of a canoe or kayak run. That's a case
where the voted-on tagging requires perfect mapping before the data can be
entered at all - and when I mentioned that once before, I was put down with
"if you don't understand it, don't map it." I understand it well enough to
know that as a greenwater canoeist, I'll want to portage around it. I can
see the whitewater. I cannot grade it safely. Here, however, the community
consensus appears to have settled on the perfectionist approach, so I don't
map rapids.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

[Kevin Kenny]

My take on it:

Wearing my data consumer's hat:

For most purposes, I care about "this ground is covered with water".
'natural=water' is the main thing to look for, but I also have to look for
'landuse=reservoir' and several other things that I can't be bothered to
look up at the moment. I have to look for all those things, so I don't
really care all that much which one is in use.

The chief problem with both of these tags is that even for the rough-level
mapping, I have to examine 'water=*' or 'reservior_type=*' to find that the
contained substance is, in fact, water and not sewage or mine tailings.

In any case, both uses are widespread.  I'm going to need to interpret both
for the foreseeable future.  I can cope with synonyms.  I'm not going to
lobby strongly for one or the other.

Wearing my mapper's hat:

'natural=water' wins.  I can see that there's water there. The big
counterargument that I've heard, other than that 'landuse=reservoir' has
been the predominant tagging, is that a reservoir isn't "natural" water.
But in our complex, human- (and beaver-) sculpted environment, what is
natural?  Many of the reservoirs that I've encountered have natural lakes
and ponds underneath, and simply have had their water raised. It seems to
me that by the thinking of those who think that 'natural' means "totally
untouched by humans", that I'd actually be required to do the research
about where the old shoreline lay before humans raised the water, and
divide the reservoir into an inner 'natural=water' and an outer
'landuse=reservoir' - which is an example of the tagging position that I
abhor.  I shouldn't have to do historical research in order to map
something that I can directly observe with my own eyes. In fact, with some
of the ponds I've mapped, I've not troubled (or been able to) access the
outlet to find out what controls the water level. I don't know whether they
are tarns, dolines, beaver ponds, or man-made ponds created for logging
until I can find out where the water goes when it leaves.  (I hike in
glaciated karst; the landforms are complex.) But I can see at a  glance,
"there's water here," whether glaciers, limestone, beavers or humans put it
there. That should be enough to map it.

If someone else feels strongly enough about it to change something that
I've mapped as 'natural=water' to 'landuse=reservoir', well, I know that I
have to accept that as a synonym. so it's not going to harm me as a data
consumer.  I'm not going to change it back.  But I'm not going to accept
that the original tagging was "incorrect" or "deprecated".  I mapped what I
saw. You can go there and see it too.

To continue the classification of waterbodies, this argument to me is a
tempest in a teapot.
-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC Update - Hazard Proposal - rock/land fall/slide

[Kevin Kenny]

On Thu, Dec 3, 2020 at 8:50 PM Brian M. Sperlongano 
wrote:

> I poked into the existing usages of hazard=landslide, and they seem to
> mostly be on hiking trails or at best track roads, rather than regular
> roads.  I don't think anyone would quibble with tagging a landslide hazard
> on this [1] for example.
>
> [1] https://commons.wikimedia.org/wiki/File:Landslide_area.JPG
>

I think that https://www.flickr.com/photos/ke9tv/50114553127 might have
similar signage on the trail that runs on the canyon rim - warning people
who might want to head out to the edge for a photo.  There's no signage at
river level, but I'd still give the slope a wide berth when hiking in
winter or heavy rain. (In better weather, all that scree makes for an easy
ford, and in fact I'd just crossed dry-shod when I turned back to snap
the picture.) In any case, I don't think there would be much controversy
that the hazard exists, signed or not - and probably ought to be indicated.
The place is close to the city of Schenectady, and many people come out
unprepared for the conditions. Technical rescues are common, and every few
years someone suffers a fatal fall or drowns.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC Update - Hazard Proposal - rock/land fall/slide

[Kevin Kenny]

On Thu, Dec 3, 2020 at 12:54 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> I am not exactly happy about "rock slide" as it seems weird to use it where
> danger is primarily about individual rocks dropping, not about full scale
> rock slide.
>
> Personally I would prefer "failing rocks" for warning used by a standard
> road
> sign.
>
> (difference is minor, but if we have luxury of selecting any value...)
>
> Disclaimer: I am from a relatively flat country, maybe this sign warns
> about
> full scale rock slides elsewhere?
>

You are a flatlander, aren't you?

Around here, before the international iconography was adopted, the signs
always said, 'fallEN rocks'.  There's precious little a driver can do about
fallING rocks, but incidents of being under them are vanishingly rare.
Instead, the real hazard is fallEN rock blocking the roadway. (Even now,
the MUTCD W8-14 sign prefers the sign with the English words
http://www.trafficsign.us/150/warn/w8-14.png, although some states,
particularly near the Canadian border, favor the pictorial one
https://www.usa-traffic-signs.com/v/vspfiles/photos/cust_W8-14-2.gif that
suggests, incorrectly, that fallING rocks are the chief hazard.)

Around here, also, the stone is sedimentary, often consisting of layers of
soft shale or dolomitic limestone interspersed with much harder sandstone.
The shale erodes away from underneath in a valley or highway gut, until the
sandstone on top of it can no longer support the weight of the overhang and
collapses,  It has little enough structural integrity that you don't
generally get single rocks falling, you get a pile of talus and debris.
Sometimes it's a five minute job with a skid-steer to push the stuff away.
Sometimes it's a couple of weeks with many vehicles to clear away a huge
mass of material and rebuild the shattered pavement underneath.

On Thu, Dec 3, 2020 at 1:09 PM Paul Allen  wrote:

> That's not to say we don't have landslides in the UK, but it appears
> we don't construct roads in places where they are anticipated to
> happen.
>

The idea of "we don't build where the rocks might fall in the road" doesn't
work all that well when every mountain pass poses the same risk.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] coastline v. water

[Kevin Kenny]

On Tue, Nov 24, 2020 at 9:23 AM Christoph Hormann  wrote:

> The problem we have here is that of a widening gap between the goals and
> aspirations of the mapper community - which naturally grow as OSM grows in
> ambitions - and the abilities and engagement in the non-mapping part of the
> community to develop and satisfy similar ambitions in cartographic quality
> without outsourcing the hard part of that work to the mappers.  Too many
> people have followed the illusion for too long that the large corporate OSM
> data users will provide the necessary support in that field while it turns
> out (non-surprisingly in my eyes) that they have neither an interest in
> above average cartographic quality nor in substantially sharing methods and
> competency in the little work they do in that domain.
>

(Brief summary: 1. Many area features are indefinite only at margins that
do not have a significant deleterious effect on statistics when analyzed or
on the understanding of the map when rendered. 2. Topology still matters -
for analyzing or rendering them. 3. Algorithm development needs data to
chew on. Blocking the data while waiting for the algorithms is a 'deadly
embrace.' 4. Mappers are continuing to enter the data for approximate
regions because they understand 1.-3. above. 5. Which argument are you
willing to give up in order not to argue against all progress in this
domain?)

In my earlier message, I was speaking not as a mapper looking to enter
data, nor as a map user looking for a pretty rendering - although I wear
both those hats from time to time - but as a newly-retired applied
mathematician (A.B., mathematics, Dartmouth College, MS in electrical
engineering, Arizona State University, PhD, computer science, University of
Illinois, about forty years of experience with GE, Northrop, Honeywell, and
others), with a reasonable background in computational geometry, thinking
of what challenges I ought to tackle next.

Given that one of my principal avocations is hiking, my chief rendering
interest is not with an endlessly-panning map, as useful as that is; it is
with paper maps where labeling must conform with the neatline.  For those
maps, simply placing a point for 'label painting' near the center of an
indefinite feature is not sufficient. Instead, a first step has to be
calculating the intersection of the area feature with the region of
interest, leading to one of the results: (a) the area is totally within the
region; (b) the area is totally outside the region and may be discarded;
(c) the area intersects the region partially and one or more regions of
intersection must have labels placed individually. The 'one or more' arises
from the fact that a non-convex area feature or a non-convex region of
interest (a rectangle, for instance, with a corner cut out for placement of
a legend) may yield more than one polygon of intersection.

You have on several occasions advanced the argument that the central label
should be enough for this and made a contention that I don't understand
about projecting from the central label of a bay onto the shoreline to
reconstruct the area. With that contention came the implication that the
topological information about an indefinite area would not be needed, if
only the renderers and data analysts worked hard enough. Unless you can
provide me with literature citations to what you have in mind, I'm afraid
that I'll have to dismiss your claim as hand-waving. As far as I can tell,
there is no known way to achieve the result that mappers want - or at least
I want - without the detailed geometry of the partially indefinite area. If
you can provide such citations, I'm eager to follow up with you!

I should digress into the phrase, 'partially indefinite,' that I've already
been using.  For the contentious areas such as the Red Sea, the indefinite
portion about which the controversy arises is typically small, and
typically of a nature where a rough approximation is acceptable to all
users. There is no controversy arising from the shoreline of the Red Sea
except for a trivial amount of border.  Very few claim that the Red Sea
exists only as a social construct. Scientists discuss its hydrology and
ecology in contradistinction to that of the region of the Indian Ocean to
which it connects.  Mariners speak of Port Sudan, Jeddah, Sharm al-Sheikh,
or Eilat as Red Sea ports (Eilat may be further specialised as being a port
on the Gulf of Aqaba, a smaller area that is similarly well-defined; the
relation is one of hierarchy rather than exclusion. (Moving somewhat to the
northwest, I've seen papers on hydrology that have tabulated observations
in rows labeled 'Ionian Sea', 'Ægean Sea', 'Tyrrhenian Sea', 'Adriatic
Sea', and so on. There is _some_ shared understanding that those words have
meanings.)

'Partially indefinite' extends to other features such as peninsulæ (a
mirror image of bays - the indefinite boundary is one of land rather than
water); straits (indefinite water margins at both 

Re: [Tagging] coastline v. water

[Kevin Kenny]

On Mon, Nov 23, 2020 at 2:57 PM Frederik Ramm  wrote:

> Now, you might smirk and say "let's fix the tools then", but until the
> tools are fixed - which might take years -, you've made life a hell of a
> lot harder for anyone editing or quality monitoring in the whole area.
>
> And all for what - a nice blue label in the bay?
>

TL;DR: I understand the technical problems. Don't let the technical
problems block the discussion for people who might be able to develop
technical solutions.



Back when this discussion started, it started because you deleted a
relation for the Gulf of Bothnia, entirely without warning, without
discussion, and without mentioning it in public even afterward until it was
noticed and you were called on it in public. Generally speaking, it was
accepted, ex post facto, as an emergency measure needed to rescue the
servers from a performance trap, and most of us were willing to accept a
temporary moratorium on creating large area relations because of the
technical complications.

That issue became complicated because others chimed in and started to argue
that, rather than being a measure to rescue the servers from trouble, it
was actually a reflection of a universally accepted policy that every
millimetre of an area feature's boundary must be unambiguously defined and
visible on the ground, and the discussion rapidly deteriorated because that
definition, taken to its logical extreme, would exclude virtually all
rivers, lakes and streams from being distinct bodies of water, would
entirely exclude features such as bays, isthmi, peninsulae, and so on from
ever being mapped regardless of size or obvious closure, and in general
would dismiss topology as being entirely unimportant. The arguments went as
far as to have one user advance the claim that a number of counties and
townships north of me should not be mapped, despite having well-defined
borders in the inhabited regions, because portions of their boundaries have
never been successfully surveyed.

But somehow, those voices never gained entirely the upper hand.  If so,
features like `bay`, `peninsula`, `strait`, `isthmus`, `ridge`, `valley`
and so on would all bear prominent warnings on the Wiki that it is
inappropriate to map them. Somehow, the people who loudly proclaim that
objectivity and observability require that every feature be bright-line
observable in the field cannot bring themselves to do that, or know that
the community would reject it.

For myself, I've deferred to you on the matter - including refraining from
mapping even small features like Jamaica Bay (
https://www.openstreetmap.org/#map=12/40.6125/-73.8082) - despite the fact
that the specific feature is reasonably sized, local, quite different from
the Atlantic Ocean (calm water, much lower salinity, much greater tidal
range, and a very different ecosystem) and that I would very much like at
some point to produce a detailed paper map of my boyhood home town (
https://www.openstreetmap.org/relation/174930) including, of course,
labeling the waterways that lie only partially within its neatline. I'm
willing to accept for now that OSM cannot cope with that requirement and
I'll have to develop another system alongside OSM and manage multiple map
layers to produce such a thing.

That sort of desire - wishing to include some information about long routes
or about area features that are large, diffuse, imprecisely defined, or
otherwise difficult - appears to be fairly commonplace, given the number of
words that have been expended on the subject here and elsewhere. Those of
us to whom the topology of area features is important - for instance,
because we produce paper maps and wish to produce normal rendering,
including labeling, of area features that extend outside the neatline -
rapidly grew frustrated, and eventually the discussion died from
exhaustion, as discussions on this list usually do. Meanwhile, there's no
indication to mappers (for example, warnings in the popular editors) that
creating enormous area features is inappropriate because of inability of
the tools to deal with them.

Moreover, those who actually have the technical expertise to experiment
with solutions to the problem feel stymied at every turn by the gatekeepers
- who may also have the technical expertise, but have a different opinion
of the problem's importance. I've talked off-list with several skilled
programmers and data analysts who definitely believe that even if a
solution were to be developed, it would be rejected. There is certainly
zero interest from the gatekeepers in maintaining a discussion of the
requirements for such a thing - it turns into 'I haven't seen a good enough
solution yet, and I'll know it when I see it,' without an answer to, 'in
what way is a given proposal unsatisfactory and how might it improve?'
There's a natural temptation to transform, 'this problem is too hard for me
to solve in the time I have available' into 'this problem is too hard in
relation to its importance', 

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Kevin Kenny]

On Sun, Nov 22, 2020 at 8:04 PM Brian M. Sperlongano 
wrote:

> Therefore, a holistic solution is needed for large objects.  Setting an
> api limit is good because it gives consumers a guarantee about the
> worst-case object they might have to handle.  However, it must also be
> combined with a replacement mechanism for representing large objects.  The
> 2,000 node limit for a way is fine because longer ways can be combined via
> relations.  If the relation member limit were capped, you create a class of
> objects that cannot be represented in the data set.
>

We've already substantially solved that problem for routes. Super-relations
seem to work well, and only rarely do we even need a three-level hierarchy.
As Steve points out, we could go deeper, but there's no need.

>
> What I think is missing is a way to store huge multipolygons in such a way
> that they can be worked with in a piecemeal way.  The answer that
> immediately comes to mind is a scheme where large objects are represented
> as relations of relations, where portions of a huge multipolygon are
> chopped up into fragments and stored in subordinate multipolygon
> relations.  This hierarchy could perhaps nest several levels if needed.
> Now a 40,000 member relation could be composed of 200 relations of 200
> members each, with each subordinate relation member being a valid
> multipolygon with disjoint or adjacent portions of the overall geometry.
>
> Then, an editor could say "here is a large relation, I've drawn bounding
> boxes for the 200 sub-relations, if you select one, I'll load its data and
> you can edit just that sub-relation".
>

> This could *almost* work under the current relation scheme (provided new
> relation types are invented to cover these types of data structures, and
> consumers roger up to supporting such hierarchical relations).  The thing
> that makes this fail for interactive data consumers (such as an editor or a
> display) is that *there's no way to know where relation members are,
> spatially, within the relation*.  The api does not have a way to say
> "what is the bounding box of this object?"  A consumer would need to
> traverse down through the hierarchy to compute the inner bounding boxes,
> which defeats the purpose of subdividing it in the first place.
>

You're right that it's a problem, but you misdiagnose the details. Rather
than identifying bounding boxes, which is easy, the problem comes down to
identifying topology - is a given point in space on the inside or outside
of the multipolygon? The minimal information needed when that question is
asked is one of two things. You need to know either the 'winding number' -
essentially, if you draw a mathematical ray from the point to infinity in a
given direction, how many times do you cross the boundary of the region?
(Odd = inside, even = outside).  The second is to add a requirement to the
data model that the boundaries of regions must follow a particular winding
direction; most GIS systems use the "right hand rule" of specifying that as
you proceed along a boundary way, the interior of a relation should be on
your right.

The second rule is by far the easiest to implement. Unfortunately, it's
also inconsistent with OSM's base data model. The problem is that we do not
necessarily require multipolygons to be sorted in any particular order
(depending on client software to order them if necessary), nor do we
require the boundary ways to proceed in any particular direction with
respect to the multipolygon.  In fact, we cannot require the boundary ways
to proceed in a particular direction, since shared ways between adjacent
multipolygons are a fairly common practice. The practice is somewhat
controversial; nevertheless, it seems like a good idea when the adjoining
regions by their nature are both known to touch and known to be mutually
exclusive. The lines that separate landuse from landuse, landcover from
landcover, administrative region from administrative region, land from
water, or cadastral parcel from cadastral parcel (where cadastre is
accepted, as it is with objects like public recreational land).

Except for monsters such as the World Ocean (the coastline is a perpetual
headache), seas, and objects with extremely complex topology, the problem
is somewhat manageable. A single 'ring' (the cycle of contiguous ways,
inner or outer, that form one region of a multipolygon) or a single
'complex polygon' (an outer way and any inner ways subordinate to it) are
generally quite manageable in terms of data volume.  I can edit shorelines
of the Great Lakes, for instance, with some confidence, by loading into
JOSM all the data near the single stretch of shoreline that I'm working on,
plus the entire outer perimeter of the lake (using the 'download incomplete
members' function); having the shoreline outside the immediate region of
interest doesn't stress the memory even of a somewhat obsolete laptop
computer. Not all editors are as competent with managing large relations 

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

[Kevin Kenny]

On Mon, Nov 16, 2020 at 9:20 PM Dave F via Tagging <
tagging@openstreetmap.org> wrote:

> Be careful. This is where many contributors get confused. The name of the
> *path* is often not the name of the *route*. A route relation can, & often
> does, go along paths with different names. Multiple routes can go along a
> path.
>

To give a more concrete example, there's a rail-trail in my neighborhood
called the Mohawk-Hudson Bike-Hike Trail.
It has a relation, for several reasons that I'll discuss below.  Most of
its member ways are also named 'Mohawk-Hudson Bike-Hike Trail'. There are a
few ways, however, that have the names of highways because freeways and
active rail lines interrupt the rail grade, and the trail follows some
lightly-trafficked streets for a short distance before rejoining the
grade.  Those ways have name='Dunsbach Ferry Road', name='Island View
Road', name='Scrafford Lane', name='Iroquois Street', etc, but remain
members of the route named 'Mohawk-Hudson Bike-Hike Trail'. (Actually,
there are two route relations: one for cycling and one for walking.)

Large portions of the rail-trail are, in turn, used by two long-distance
routes: the Erie Canalway Trail and the Empire State Trail.  There are
separate relations for these two, and most of the members of the
Mohawk-Hudson Bike-Hike Trail are also members of these other relations.
(That does not affect the names of the member ways. The Mohawk-Hudson
signage is consistent, while the signage for the other two trails is still
something of a work in progress, although there's a lot more of it than
there used to be. The naming of the member ways follows the commonest
signage.)

There are a great many member ways because of changes of the
characteristics of the way (bridge=yes, embankment=yes, bicycle=dismount,
surface changing from asphalt to wood on a bridge, and so on.)

>
The Mohawk-Hudson relation exists (a) because not all the member ways have
its name (since it borrows roads for short segments) and (b) because
Waymarked Trails and other data consumers do better with a route relation
grouping all the ways, rather than trying to assemble a route from ways
with nothing in common other than being named alike.

>
> I assume this is not prefered because a number of applications use the
> names in the Ways themselves and not the Route Relation, most notably
> osm-carto.
>
>
> It renders the names of the paths, not the routes.
>
>
> However, some benefits of doing this might be:
>
>- Takes up less space in the DB
>- More tags that apply to the whole coute could be added to the
>Relation like surface 
>=* and source =* (like
>the official map of the route).
>
>
> Surface has no place in a route relation as it refers diectly to the path,
> not the multiple relations passing along it. Similar for the source tag.
>
> DaveF
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecate water=pond?

[Kevin Kenny]

On Thu, Nov 12, 2020 at 6:22 PM Adam Franco  wrote:

>
>- origination:natural=beavers
>
> Thanks for remembering this one. Around here, beavers are a significant
sculpting force on the landscape.

(And `man_made=dam` is the best tagging that we have for their water
control structures, which are also often adjusted seasonally)

Very long story short, I think we might be able to worry a little less
> about what the body of still water *is* and more about its other
> properties that might be of interest. In programming languages this is
> referred to as "duck typing ".
>

If ducks could type, I could easily imagine that a pond might be mapped and
the tags entered by a duck typing. I think that the duck in question might
be Atwood's Duck.
https://en.wikipedia.org/wiki/Law_of_triviality#Related_principles_and_formulations

And ... having seen this argument several times before, I basically avoid
`water=*` when mapping. I can hardly think of any waterbody, intermediate
on the large..small and natural..artificial scales between the Great Lakes
and a farmer's stock pond, where the `water=*` value would be
uncontroversial. `natural=water` renders, and I'll try to avoid taking a
census of the angels dancing on that particular pinhead.

This whole discussion reminds me of one time that someone who wasn't from
around here (nor a native speaker) was insisting that anything that was
called a 'creek' in English *must* be a tiny watercourse.  Not around here!
The creek in question was, if memory serves, either the Schoharie Creek,
shown in this picture:
http://minerva.union.edu/garverj/mohawk/images/schoharie_falls.jpg or else
the West Canada Creek
https://en.wikipedia.org/wiki/West_Canada_Creek#/media/File:Aug_2011_Ft_Noble_Mtn.JPG
I'm comfortable with `waterway=river` on any waterway where I map the
riverbank.

On Thu, Nov 12, 2020 at 2:52 PM Paul Allen  wrote:
>
>> On Thu, 12 Nov 2020 at 19:30, Joseph Eisenberg <
>> joseph.eisenb...@gmail.com> wrote:
>>
>>> Re: is water=* tag needed?
>>>
>>
>>
>>> But since water=pond is not clearly defined as natura/semi-natural vs
>>> man-made, we have a large number of features where the water=* tag is not
>>> providing this information. Since the previous tagging system clearly
>>> distinguished natural from man-made water bodies, this would be a loss for
>>> database quality.
>>>
>>
>> We often do not know if it is natural or artificial.  Maybe it's a natural
>> depression in the ground that fills with water.  Maybe it was created
>> by man as a water feature.  Maybe it's an old quarry that has flooded.
>> Even if it was originally a result of something like quarrying it may have
>> happened so long ago that there are no records.
>>
>> What we can determine (at least in principle) is if it meets criteria
>> for a lake (large size or large waves or has aphotic zones) or a
>> pond.  In principle, a suitably-qualified mapper could investigate
>> those things on site.  We can accept using guesswork based on
>> size pending fuller investigation. A lake/pond distinction is
>> useful irrespective of whether it is entirely natural or entirely
>> artificial.
>>
>> Determining if it's entirely natural, or deliberately man-made, or
>> an unintended consequence of past human activity is harder.
>> Possible for retention basins that are still in use.  Mostly
>> possible for reservoirs, although some reservoirs are
>> based around natural lakes.  But historical records are
>> incomplete (and some mappers insist we should never
>> ever make use of historical data to inform our mapping).
>>
>> Maybe we need an artificial=yes/no.
>>
>> --
>> 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
>


-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] What does bicycle=no on a node means?

[Kevin Kenny]

On Thu, Oct 15, 2020 at 3:46 AM Martin Koppenhoefer 
wrote:

> On 13. Oct 2020, at 23:42, Volker Schmidt  wrote:
>
> I changed the crossing to the way we do it in many parts of Europe, i.e. a
> crossing node *and* a crossing way.
>
>
>
> I thought the standard was highway=crossing on the nodes where they cross
> the road and highway=footway with footway=crossing on the way segment
> between the kerbs (if sidewalks are mapped) or between the crossing nodes
> (if several carriageways are present).
>

For the specific way that Volker was discussing,  the situation was a
stand-alone shared-use foot/cycleway crossing a tertiary highway. Single
carriageway, but with a way segment added to the cycleway to carry the
signed  `bicycle=dismount` restriction. No kerbs anywhere.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] What does bicycle=no on a node means?

[Kevin Kenny]

On Tue, Oct 13, 2020, 17:41 Volker Schmidt  wrote:

>
>
> On Tue, 13 Oct 2020 at 22:16, Emvee via Tagging 
> wrote:
>

I changed the crossing to the way we do it in many parts of Europe, i.e. a
> crossing node *and* a crossing way. This was described as an option on
> the highway=crossing wiki page until it was changed on 07:52, 3 October
> 2020by user Emvee  by
> addng the diagram and its description.
> If you don't like it, please change it back - I used it in place of a
> longish explanation.
> (I also moved the two stops away from the end nodes of the ways as the tag
> direction=forward|backward is better not placed on a node that connects two
> ways )
>

Both of those are better, thanks!

The routers that I use for testing seem to be aware of crossings without
crossing nodes, so I too often forget to tag them.

Having the STOP signs tagged as I did works, since 'direction=forward'
means 'when approaching this node on the forward direction of any
connecting way', but your method is more robust against inadvertently
reversing one way and not the other.

>
> This recent wiki change by Emvee
>  is in my view not
> helpful, or even misleading, as it does discourage a wide-spread tagging
> practice (if we like this or not is a different question, but it's
> established tagging, and the wiki is supposed to describe the establsihed
> methods of tagging)
>

I'm posting from a smartphone, so I'm not in a good position to review the
change log. I'll let you and Emvee sort it out.

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

Re: [Tagging] What does bicycle=no on a node means?

[Kevin Kenny]

On Tue, Oct 13, 2020 at 8:07 AM OSM  wrote:

>
> How to solve the issue with a single crossing node at highway=
> without a crossing highway= because of "sideway
> tagging by tags on highway" mapping?
>

I don't try to solve it. I put in a short way for the crossing.

https://www.openstreetmap.org/way/781981138 is the first example that came
to mind for me. https://www.flickr.com/photos/ke9tv/49667335508 is a street
view of the crossing in question.

Don't excoriate me for the `highway=path`. That's what the mappers around
here do for a shared-foot-and-cycleway. I tried once, after a scolding
here, retagging it as `highway=cycleway foot=designated shared=yes`. Other
locals reverted.


-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] Large fire perimeter tagging?

[Kevin Kenny]

On Wed, Sep 30, 2020 at 6:22 AM stevea  wrote:
> I’m not positive that this is true for the entire perimeter, but 
> bulldozer-cleared areas, hand-dug trenches many meters wide (to prevent a 
> fire “jumping” from one side of the perimeter to the other) and usage of 
> cutlines (for power cables / towers) and roadways to establish part of a 
> perimeter are all strategies I believe firefighters use to “build” such a 
> fire perimeter.  This is much more clearly delineated in the real world than 
> might be a bit of red tape on a tree.

Definitely, and more permanent as well.  My brother's place has a line
that was bulldozed down to bare rock in a firefighting operation in
1950. There's still a strip of bare rock there, because it takes
decades for enough duff and debris to accumulate to rebuild the soil.
(Moreover, the slope is steep, so the spring snowmelt tends to flush
away what has accumulated.) We still use the fire line to walk to the
back of the property. Nature is gradually rebuilding, but the
landcover there is still mostly ferns, mosses and lycopodia, although
there are a lot more perennial forbs and we're starting to see alders
reappear.

> I think “burden” for a lightly-tagged polygon is hyperbole (exaggeration), 
> but I do see the point that a sophisticated user who is curating data in, 
> around or associated with such a polygon might find an overlay strategy to be 
> ideal.  But doing so leaves out all other OSM users (many, besides the single 
> user noted above) and all other “useful” reasons for the data being shared in 
> the database (which might become many, but are now discussed as “at least 
> two:  to better re-map and to warn users “there was a fire here, use care”). 
> Perhaps we have identified an edge between where “data are better curated 
> outside of OSM” and “data that seriously benefit by being shared and hence 
> Inside of OSM.”  Who decides?  How?

I tend to have little patience with claims that features that are
visible in the field ought not to be mapped because they will "burden
the map".  Generally speaking, that means simply that those features
are not of interest to the claimant. I welcome correct mapping of any
observable feature, even ones that I'm highly unlikely to map or care
about. I don't think any of us has the right to dictate that another
mapper ought not to be interested in a given feature.

On Wed, Sep 30, 2020 at 8:29 AM Paul Allen  wrote:
> On Wed, 30 Sep 2020 at 09:58, stevea  wrote:
>> I saw someone say “six to seven years” (as what might pass for “recovery” to 
>> a large degree) to have “taken root” and after living most of my life here, 
>> that sounds about right.
>
> It was I who said that.  I don't have your personal experience, but in a
> "seven degrees of Kevin Bacon" kind of way I have come to know a
> group of people on Facebook who avidly hike in the affected areas.  When
> discussing the fires and their possible aftermath they compare them to past
> fires and mention six to seven years for past recoveries.

If you consider replacing a stand of mature hemlocks with an alder
thicket to be 'recovery'.  (Substitute the successional stages of your
local ecosystem. Mostly where I hike, it's the mixed-deciduous forest
of eastern North America, transistioning to Canadian taiga at the
higher elevations, with alpine tundra on a few high peaks.)

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] .Re: tagging drinking water of unclear official (signed)

[Kevin Kenny]

It's not US English, it's just a misspelling yielding a wrong word. The
correct word is 'potable' on this side of the pond as well.

On Mon, Sep 7, 2020 at 8:14 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 7. Sep 2020, at 13:52, Peter Neale  wrote:
> >
> > I'm not arguing against "drinking water", just against "portable water"
> (water that can be carried)
>
>
> sorry for posting in reply to you, it was meant more generally as
> responding to the warming up of a discussion about the words used in the
> main tags.
>
> Cheers Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

[Kevin Kenny]

On Mon, Aug 24, 2020 at 10:34 AM Matthew Woehlke 
wrote:

> Does it really only use the changeset bounding box? That's good as a
> first-pass culling test, but I would be somewhat annoyed if my ROI is
> "Chicago, IL" and I get notified because someone changed Kansas City, MO
> and Detroit, MI in the same changeset without changing anything near
> Chicago.
>

I get annoyed in general when people do that. Grouping unrelated edits into
the same changeset is very poor practice. (I do big changesets myself, but
the data in any individual changeset are clustered, either in a dense
geographic area or along a linear feature.)


-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Waterway equivalent of noexit=yes?

[Kevin Kenny]

On Fri, Aug 14, 2020 at 7:08 AM Paul Allen  wrote:

> On Thu, 13 Aug 2020 at 06:42, Mark Wagner  wrote:
>
>>
>> For a larger and far more dramatic example of this sort of situation,
>> look at the area to the west of Death Valley Playa.  It looks like
>> someone stacked hundreds of river deltas on top of one another, but
>> forgot to add the water.
>>
>
> As I understand it (possibly not all that well) a sinkhole as the wiki
> defines it
> is a large hole in the ground which water enters and vanishes without
> pooling.
> What Ordnance Survey calls "sinks" appears to be more akin to a hole in a
> golf
> course that water enters and vanishes.  What Ordnance Survey calls
> "spreads"
> is a sand or soil or gravel surface that water vanishes into without
> pooling and without there being any noticeable hole.
>

The WIki picture of a sinkhole happens to be large, but in karst terrain
they come in all sizes. https://www.openstreetmap.org/node/5599524737 is a
sinkhole of quite a small stream. I couldn't find a good way to tag the
rise a short distance to the west.
https://www.openstreetmap.org/way/226924460 is a much larger sinkhole. In a
wet season there's significant outflow to the east, but in a dry season all
of the outflow from the lake runs through the caves, exiting through cracks
in the limestone below the cliffs to the east. Many of the small streams
thus formed haven't been mapped because there are significant technical
challenges to mapping them. GPS coverage at the cliff bases is so poor that
one would probably have to resort to alidade and plane table, and the
evergreen cover is dense enough that you can't see much that's useful on
satellite imagery.

I'm not sure if any of those fit what you have and maybe what you have is
> more of a network of intermittent streams.
>

What Mark is showing is usually called an alluvial fan.
https://en.wikipedia.org/wiki/Alluvial_fan
Some fans have well-defined (perennial or intermittent) distributary
streams flowing through them. Often, though, most of the stream channels
are ephemeral in nature. Sometimes an individual channel was cut in a
matter of hours by a debris flow coming from upriver.

In arid climates, it's entirely possible for the entire flow of the stream,
except during flash flooding events, to vanish by percolation and
evaporation, so that there is no river downstream. There's no well-defined
sinkhole, and no well-defined specific point at which it transitions from
perennial to intermittent, intermittent to ephemeral, ephemeral to a dry
wadi that has seen water only in geologic time, eventually disappearing
entirely into a salt flat.

It's relatively rare to find a fan that's still actively depositing
sediment. One example is that Mòlèqiē Hé (莫勒切河) in Xinjiang forms an
enormous and nearly unique one near 37.4°  north, 84.3° east.
-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Kevin Kenny]

On Tue, Aug 4, 2020 at 3:16 PM Frederik Ramm  wrote:

> Hi,
>
> On 8/4/20 18:28, Kevin Kenny wrote:
> > In actual practice, in the estuaries of rivers, the 'coastline' is very
> > seldom tagged that far upstream.
>
> From my Chesapeake Bay example, in OSM, Havre de Grace (290km inland) is
> a "coastal"city
>
>
> https://www.openstreetmap.org/?mlat=39.5443=-76.0961#map=10/39.5443/-76.0961
>
> though Baltimore (260km inland) is not, due to Patapsco River having its
> own polygon:
>
>
> https://www.openstreetmap.org/?mlat=39.2461=-76.6523#map=10/39.2461/-76.6523
>
> Of course my "xxx km inland" depends on where you define the bay to
> begin, I used the US13 crossing at Norfolk.
>
> Not saying that is the measuring stick, and perhaps as a result of this
> discussion it needs to be tagged differently, or maybe the physical
> geography is different there.
>
>
Chesapeake Bay is commonly understood (not among biologists or
oceanographers, but in everyday speech) to be a marine environment. Even
its name suggests that.  Moreover, the Susquehanna is where the fall line
comes closest to the coast;  and so has the least problem of all the
Eastern US rivers. Nobody sane would place the 'coastline' above the
Conowingo dam, only a few km from Havre de Grace.Were it not for the dam
and lock, Conowingo would be the limit of navigability of the Susquehanna,
and the Potomac would not be navigable beyond Washington without the C
Canal infrastructure.

In any case, the number of words we've all exchanged on this topic itself
indicates that what we're trying to do is to fix indefinite boundaries.
Whether a particular land-water border is 'coastline' or not, for most
purposes, is a distinction without a difference. You have land on one side,
and water (of whatever salinity and tidal variation) on the other.  The
water likely belongs to one or more water bodies that have names; the
boundaries among named water bodies are almost always both indefinite and
culturally determined. Rivers are (usually) fresh and (usually) flow in one
direction. The ocean is salt and is (usually) tidal. We use 'estuary' to
describe the whole indefinite continuum between. For the Hudson, a
hydrologist would correctly say that the whole thing from the dam in Troy
to the ocean is estuarine. There are no bright lines separating the pieces.

Since there are no bright lines, there is a weaker technical argument in
favor of making the 'coastline' as small as possible - minimizing the
extent over which trivial mapping mistakes cause continent-wide rendering
gaffes.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Kevin Kenny]

On Tue, Aug 4, 2020 at 3:18 PM Joseph Eisenberg 
wrote:

>
> These rules would exclude the lower Rio De La Plata and the lower part of
> the mouth of the Saint Lawrence river, as well as other wide estuaries
> where winds and tides have more influence on surface water flow than does
> the discharge of the river. It would not prevent mapping the Hudson mouth
> at the southern tip of Manhattan, because the flow is strong all the way to
> New York Harbor, if I understand correctly.
>

The Hudson definitely reverses flow. One of its names among the First
Peoples translates to 'the river flows both ways.'  The division in the
flow lies less in the fraction of the tidal cycle than the speed of the
current. It flows 'upstream' for half the time, 'downstream' for half, but
the downstream current is considerably swifter.


-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Kevin Kenny]

On Tue, Aug 4, 2020 at 2:54 PM Joseph Eisenberg 
wrote:

> It's perfectly possible to make a physical definition of an estuary which
> allows the line of the natural=coastline to be placed across the lower
> Hudson, rather than at Troy or Albany, if we look at salinity and currents
> rather than just tides: and we must, because some parts of the coast in the
> tropics have nearly 0 tidal variation (including the region around the Rio
> de la Plata).
>
> But the current position of the natural=coastline ways between Argentina
> and Uruguay is like if all of Lower New York Bay were outside of the
> natural=coastline, and a line was instead drawn from Long Beach NY to Long
> Branch NJ.
>
> This is quite serious when it comes to the Saint Lawrence river (Fleuve
> Saint-Laurent), which can extend as far west into the Golf of Saint
> Lawrence as you want, if we take the current placement of the
> natural=coastline along the eastern edge of the Rio de la Plata as a guide.
> I would suggest that the natural=coastline should cross no farther
> downstream than Quebec City, where the river widens into the huge lower
> estuary.
>
> Similarly, should Puget Sound and San Francisco Bay be mapped as
> natural=water + water=river? These are also estuaries.
>

Deferring to local cultural understanding is actually a good start for the
other examples.

For the Hudson, if you wanted to draw the line from Rockaway Point to Sandy
Hook (the two lighthouses commonly understood to mark the entrance of New
York Harbor), from the Battery to Liberty Pier (mile 0 of the Hudson as it
appears on the nautical charts) or from Spuyten Duyvil to Englewood Cliffs
(just upstream from the first distributary, the Harlem River), I'd have no
heartburn.

 The lowest point on the river that would be at all defensible by any
argument other than culture (and 'eyeball' geometry - on the map it *looks*
like a river) would probably be between Peekskill and Stony Point. That's
where you'd start to see mean annual salinity start to fall off sharply.
(The seasonal variation is substantial.) That's already getting culturally
and "eyeball geometry" start of dodgy.  Beyond that, I'd have to consult
historical records for the historical maximum retreat of the salt front,
but we're already quite some way upriver.

Similarly, there's a local understanding of "Fleuve Saint-Laurent" vs
"Golfe du Saint-Laurent" - and here I see that the locals have compromised
by creating objects for 'Estuaire fluvial', 'Estuaire moyen' and 'Estuaire
maritime'. Even there, the 'Estuaire fluvial' does not extend nearly to the
tidal limit.

The locals certainly make a distinction between the waters of the
Sacramento and American rivers and those of San Pablo and San Franscisco
Bays, or those of Puget Sound and the many rivers that empty into it. They
also make a distinction between the bays, or the sound, and the ocean.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Kevin Kenny]

On Tue, Aug 4, 2020 at 12:59 PM Christoph Hormann  wrote:

> I am not saying that OSM should only record physical geography.  I am
> saying that natural=coastline is a physical geography tag and should be
> defined based on physical geography criteria.  If there is no consensus
> about this we can end the discussion because if we cannot even agree on
> basic conceptual separation on that level (i.e. that we separate the
> mapping of the physical extent of surface water cover on this planet
> from culturally defined elements of the geography) we can close up shop
> right away.
>

Your straw man looks to be quite flammable.

A water polygon remains a water polygon whether its boundary is
`natural=coastilne`, `waterway=river`, `natural=water` or whatever. Nobody
is arguing over the physical extent of surface water coverage.

The precise line at which a river becomes a lake or the ocean is and will
always be indefinite. We are arguing about how broadly or narrowly to draw
it. Your argument is that the first dam or waterfall is the only
'objective' way to place it. That may be true: it's the first bright line.
Nevertheless, in practice, it gives a much broader definition of the World
Ocean than seems reasonable - placing the line hundreds of km from the
commonly understood river mouth in many cases.

I'm arguing that both cultural considerations (generally speaking, people
do not call tidal inland riverbanks 'the coastline') and practical
considerations (a much longer coastline further complicates the already
horrible situation for coastline rendering) both militate in favor of
putting the coastline as far downstream in the estuarine environment as is
practicable. Nothing in my argument changes the physical extent of the
mapped water surface by one centimetre. It's simply saying that for any
indefinite boundary, there is no single right answer. Deference to the
local cultural definitions, provided that they don't warp the indefinite
boundary beyond any reasonable physical interpretation, is most likely
warranted.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Kevin Kenny]

On Tue, Aug 4, 2020 at 11:24 AM Joseph Eisenberg 
wrote:

> This means that the line tagged with natural=coastline is on the inland
> side of all marine water, including mangroves, salt marshes, and tidal
> channels, as far as possible. It makes sense that in estuaries, the route
> of the ways tagged natural=coastline should also extend up to the limit of
> marine influence. In some cases this has been taken to mean the limit of
> the tides, in others it is the limit of mixing of salt and fresh water.
>

I agree that's what the Wiki says. The Wiki says a lot of things.

In actual practice, in the estuaries of rivers, the 'coastline' is very
seldom tagged that far upstream.

I return to the example of the Hudson River. The tidal influence extends
upstream to Lock and Dam Number One - 248 km from the river mouth. The salt
front varies strongly with the season. There can be fresh water in New York
Harbor during the spring snowmelt, or salt water at Poughkeepsie (122 km
upriver) in a dry summer. (It's also defined somewhat arbitrarily as a
conductivity of 510 microsiemens/metre at the surface - but surface
salinity is, in most seasons, higher than the salinity at depth because the
cold, fresh river water underlies the relatively warm, brackish surface
water.) Needless to say, the biome is very different between Albany (always
fresh water) and Yonkers (always salt, except for snowmelt events).
Oceangoing vessels of up to 9 m draft can ply the river as far as Albany.
(In less xenophobic times, vessels of friendly nations could clear customs
at Albany.)

For pretty much all the rivers in eastern North America, the tidal
influence extends to the first dam or waterfall. This usually coincides
with what would be the head of navigation if it were not for modern
improvements such as locks. Riverports from Augusta, Maine to Macon,
Georgia would become 'coastal' cities. That's surely no more the local
understanding on the Kennebec or the Ocmulgee than it is on the Elbe!

For the Amazon, the situation is even more extreme - the river is tidal for
a thousand kilometres from what would be conventionally recognized as the
'coast'.

It appears that for most of the world, this rule, if actually implemented -
and it is important to stress that it is NOT the way things are mapped at
present - would extend the 'coastline' for tens or hundreds of km upstream
on most of the first-order rivers of the world.

Given the fact that even with today's definition, we frequently go for
months without a consistent coastline to give to the renderer, do we want
to add tens of thousands more kilometres of 'natural=coastline'? We'd never
see a coastline update again! (For this reason, I'm inclined to push the
'coastline' as far toward the sea as sensibly possible, to have as little
'coastline' as possible to get broken, rather than going for months without
updates or worse, seeing rendering accidents flood whole continents.)

Moreover, I'm somewhat puzzled at Christoph's insistence that
'natural=coastline' have a strict physical definition, and dismiss local
understanding as merely political and cultural. In almost all other aspects
of OSM, the understanding of the locals is what governs. That understanding
is, ipso facto, cultural - but we dismiss it at our peril. Ignoring local
understanding is a path to irrelevance. (In another OSM domain, I've seen
this sort of nonsense before; I've actually seen someone seriously suggest
that a peak should not have its name in OSM unless someone can find a sign
with the name on it, because asking locals and consulting reference works
is not 'verifiability in the field.')

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addr:street for routes

[Kevin Kenny]

On Tue, Aug 4, 2020 at 4:57 AM Sarah Hoffmann  wrote:

> Follow-up question on that: are all route relation names/refs mapped as
> route=highway in the US usable as an address part or is that restricted to
> certain routes and/or regions (for example, rural only)?
>
>
It's case-by-case.  Near me, New York State Route 146 (which was used as an
example elsewhere) wanders.

There's a stretch of a few blocks
(https://www.openstreetmap.org/way/5640056 and
neighbouring ways) near a shopping mall where it's 'Clifton Park
Boulevard', but nobody knows that name because there are big overhead
direction signs that carry only the route number.  On either side, it's
called just 'State Route 146' and has no other name. The post office
prefers '806 [State] Route 146' as a building address, but '806 Clifton
Park Boulevard' is deliverable.

Farther south/west (146 does not have consistent cardinal directions!) 146
is co-aligned with city streets.  Balltown Road (
https://www.openstreetmap.org/way/338036383 etc.) is signed 146, but nobody
calls it anything other than Balltown Road.  Addressing mail to '1617 Route
146' would likely face delays and misdeliveries because it woiuld be
ambiguous: 1617 Balltown Road
https://www.openstreetmap.org/way/689572012 fronts
on Route 146, but so does 1617 [Upper] Union Street
https://www.openstreetmap.org/node/804483895 , and I haven't done the
address points but there's likely a 1617 on Brandywine Avenue
https://www.openstreetmap.org/way/5646367, Hamburg Street
https://www.openstreetmap.org/way/53306647 , or Carman Road
https://www.openstreetmap.org/way/135620106

Beyond Western Avenue, there's a brief stretch
https://www.openstreetmap.org/way/159115284 where 146 has no other name.
For a few blocks, it follows Main Street, Maple Avenue, and Township Road
through the village of Altamont. It retains the 'Township Road' name west
to the county line, but the situation is fuzzier. Mail will be addressed to
'1234 Township Road' but a local directing you to a house will tell you to
follow 'Route 146' because there isn't much signage with the formal name
(There is some, so 'unsigned_name' isn't appropriate.) From the county line
to the terminus at Route 443, 146 goes back to having no other name.

In these cases, I don't expect a geocoder to associate a building
automatically with a nearby street, and place the full set of address
fields on every building, entrance or other address point. My preference
would be to put 'New York State Route 146' as the 'name' of the route where
it has no other name, or as 'alt_name' if it has another name but the
locals favor the highway name over the formal name. I think that pairing
'ref=NY 146' with 'State Route 146' is too much to ask of a geocoder, while
asking it to match a partial string ('New York 146', 'State Route 146',
'Route 146' or even just '146') is pretty much all in a day's work for
full-text search engines.

Nevertheless, the last time that I raised this issue, there was an
overwhelming consensus that 'Route 146', in the stretches where that is the
only name, is an unnamed way. For that reason, and quite against my better
judgment, I've been sporadically deleting `name="New York State Highway
146"` when it appears and replacing it with `noname=yes`.  I've been doing
this only when I happen to be working on a segment of the way, and only
when I happen to think of it, rather than systematically. This
lackadaisical approach is probably in part because I still don't agree with
the consensus, merely defer to it.


Some side notes to remember:

It's worthy of note that the US has multiple route networks overlaid, with
reuse of numbers. Where this happens, generally speaking, the signs have
distinctive colors and shapes, but it is necessary to keep the authority as
well as the route number. There are crossings (e.g.
https://www.openstreetmap.org/#map=15/43.0047/-76.7002) where that's
significant - note the two routes numbered 90. It's uncommon - for
instance, counties often simply skip over the numbers of state routes that
traverse the county when assigning county route numbers - but it happens.

It also is worth noting that the jurisdiction cannot always be deduced from
boundaries.  https://www.openstreetmap.org/way/666565376 is signed 'NY
120A' even though it is in Connecticut.
https://www.openstreetmap.org/way/46691563 is signed 'Vermont 279' in New
York, although the small reference markers on the shoulder (these are
unreadable at speed, and where mapped in New York are unsigned_ref) show
'915G'.

Finally, 'State Highway', as far as I know, is not an official designation
of any road in New York: the state DOT uses 'State Route' consistently for
its numbered routes. Pedantically, there's also 'State Reference Route' for
various numbered routes that are not prominently signed but are
state-maintained. Most of these are either named (e.g., 'Taconic State
Parkway') or connector routes that often bear signs like 'TO NY 5'
-- 
73 de ke9tv/2, Kevin

Re: [Tagging] Rio de la Plata edit war

[Kevin Kenny]

On Sat, Aug 1, 2020 at 6:42 PM Paul Norman via Tagging <
tagging@openstreetmap.org> wrote:

> Starting locally, the Fraser River has a strong tidal influence 25km
> upstream of the coastline/riverbank edge. Fishers report a tidal
> influence 90km upstream. Wikipedia says the Columbia has tidal influence
> up to the first dam, which is 120km upstream of the coastline/riverbank
> edge. There are tidal forecasts published for 75km upstream of the edge.
>
> Looking in Europe, the Thames is tidal for 80km upstream of the
> coastline/riverbank edge.
>

Near to me, the Hudson River is an even more extreme example of what you're
talking about. It is tidal for 134 nautical miles (248 km) north of Mile
Zero (which is the tip of the Battery, where it enters New York Harbor).
The salt front ranges from some distance out in New York Harbor during the
spring snowmelt to about Poughkeepsie (124 km upriver) in a dry summer.
Because of resonance effects, the tidal range is actually greatest right at
the Federal Dam in Troy, the northernmost extent of the estuarine region.
If you say that Troy is on the coast, people will look at you as if you
have two heads. If you start to explain that well, the river is tidal, and
dredged to a depth of 9m to accommodate oceangoing vessels, and (yada,
yada, yada), they'll say, 'yeah, I suppose if you want to be THAT way about
it,' and file you mentally under 'insufferable pedant.'

Much farther afield,  the Amazon is tidal at least as far as Óbidos,
Brasil, nearly a thousand km from the river's mouth.

As a practical matter, given the woes of coastline maintenance, pushing the
coastline for tens or hundreds of km up most of the world's rivers would be
a disaster.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Kevin Kenny]

On Sat, Aug 1, 2020 at 5:29 PM Paul Johnson  wrote:

> On Sat, Aug 1, 2020 at 3:09 PM Clay Smalley  wrote:
>
>> Chiming in as another settler. I really wish we had more Natives active
>> on OSM contributing their cultural knowledge. What could we be doing
>> different in the future to welcome and engage them in our community?
>>
>
> Outreach to tribal GIS offices where they exist couldn't hurt.  The
> standard map rendering native areas, particularly when most don't (or in
> Oklahoma's case, most are *egregiously* incomplete, often only including
> the Osage Nation) definitely is a nice start and I'm glad we're to that.
> At least in the north american context, having a separate tag for
> indigenous lands seems a little strange compared to filing it under the
> administrative boundary, admin_level system, but I can live with it.
>

It depends on the jurisdiction.  The non-Federal Schaghticoke reservation
in Connecticut is simply part of Kent Township; there's a tribal government
of sorts but it's not recognized by the BIA, and so there isn't really an
admin_level that would fit.

On the other hand, all of the Indian Reservations in New York are not part
of either Towns or Cities, and so would slot in nicely at admin_level=7.
The sole inconsistency that designation would introduce is that the city of
Salamanca is entirely within the Allegany reservation. (Salamanca, and
several smaller communities, have significant non-Haudenosaunee populations
and stand on reservation land that is leased from the Seneca Nation.)
-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Kevin Kenny]

On Sat, Aug 1, 2020 at 2:25 PM Clifford Snow 
wrote:

> After some digging, it appears that Saint Regis Mohawk Indian Territory is
> in OSM. Just across the border, on a Saint Lawrence River island, is the
> Akwesasne 59 First Nations tribe is also in OSM. According to Wikipedia [1]
> the Mohawk consider their territory to be a single nation, with no border
> separating its parts.
>
> It seems to me that we should map the tribal areas as one. Possibly as a
> super relation, though I'm not sure if super relations are used for
> boundaries. What I find interesting is that the Canadian Border Crossing is
> located on the North side of the Saint Lawrence River while the US crossing
> station is located on the South side of the river. It seems to imply that
> the Akwesasne Nation is not in either country.
>
> [1] https://en.wikipedia.org/wiki/St._Regis_Mohawk_Reservation
>

It's complicated. (When are sovereignty disputes _not_ complicated?)

Both the US and Canada consider the river to be the US-Canada boundary, and
that the reservations are their separate dependencies. The Canadians
recognize the Six Nations as domestic dependent nations, and they enjoy
limited sovereignty on their own lands. The US recognizes certain
Haudenosaunee lands as dependent nations, but Akwesáhsne is not one of
them, owing to the fact that they have not adopted a written constitution
and a representative democracy. (In completely open elections, they
consistently prefer their semi-hereditary chiefship, and elect the
traditional chiefs to the political offices. In current practice, the
traditional chiefs are disqualified from standing for election.)

The Jay Treaty of 1795 recognizes that the Akwesáhsro:non have freedom to
travel their land on both banks of the river.  The current rule is
particularly burdensome: an Akwesáhsro:non wishing to return to Cornwall
Island from Saint Regis must first cross a second bridge into Canada to
clear customs and pay duty if necessary, and then return to Cornwall
Island. There have been recurring discussions of placing the Canadian port
of entry on the US side of the river to avoid this situation.

There was an earlier query in the thread about government web sites: The
respective tribal governments maintain Web presence at
http://www.akwesasne.ca/
and https://www.srmt-nsn.gov/

I've refrained from trying to map the situation, not being qualified. (I'm
an Old White Guy with a trace of Six Nations ancestry,)
-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addr:street for routes

[Kevin Kenny]

On Fri, Jul 31, 2020 at 4:28 PM Paul Johnson  wrote:

> On Fri, Jul 31, 2020 at 3:16 PM Kevin Kenny 
> wrote:
>
>> The reductio-ad-absurdum would be to argue that 42nd Street in Manhattan
>> should be `noname=yes ref=???` and participate in a route relation with
>> `network=US:NY:New York:Street ref=42`. I'm sure that would please strict
>> taxonomists, but most people would think it silly to argue that the name of
>> the road at the downtown end of Times Square isn't 'Forty-Second Street'.
>> If 42nd Street can be a name, why can't County Route 23C?
>>
>
> If you're trying to argue that "Sixth Street" is not a name, I'm not
> buying.  Especially when you call out that it's absurd to suggest it is.
> Or that you don't understand the difference between a name and a ref.  Or
> that you don't understand why data consumers may find conflating the two to
> be confusing or annoyingly redundant.  Surely you give our intelligence
> more credit than that, don't you?
>

Quite the contrary. I'm not arguing that 'Sixth Street' is not a name.  I'm
arguing that 'County Route 23' may be a name, particularly when the given
road has no other and the name is marked on blade signs, direction signs,
or other cases where a name rather than a ref would be expected.

I'm not suggesting that it's good practice to omit the ref. It is not.

I'm not suggesting that it's good practice to include a ref as an alt-name
on a street that is signed with an actual name. It is not.

I'm suggesting that sometimes the ref _is_ the name. Out in the
countryside, there's really very little difference between a road signed,
'297th Avenue' https://www.openstreetmap.org/way/263171081 and one signed
'North [County Road] 400 East' https://www.openstreetmap.org/way/13723307 -
they're both numeric references for county roads. County Route 39
https://www.openstreetmap.org/way/20082802 is really no different, except
as to the form of the name. County Route 39 is what the locals call it.
It's what the post office delivers to. It's what the blade signs say.
(Unlike the nearby Mountain Avenue and Heart's Content Road, where the
blade signs and addresses have the name.)

The only real harm that I can see from the duplication is that there's a
trivial additional amount of storage, and that voice synthesis might repeat
itself, since a navigation system often reads off the name and the ref.
It's otherwise not much of a conflation problem, since search operations
that look for a name will find it, and ones that look for a ref will find
it.  Free-text search already often has to deduplicate results, for
unavoidable reasons. (New York County, within New York City, within New
York State, or New York Avenue, within Kings County, New York City, New
York State.)
-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addr:street for routes

[Kevin Kenny]

On 31. Jul 2020, at 18:25, Jmapb  wrote:
>
> But most of the ways in the route have no valid name. Segments were
> imported from TIGER with name=State Highway 214 but that's been removed
> in favor of ref=NY 214.

On Fri, Jul 31, 2020 at 12:01 PM Martin Koppenhoefer 
wrote:

>  around here we keep both, no need to remove the name if it makes sense.
State Highway 214 looks like a reasonable name, especially outside of
builtup areas.

On Fri, Jul 31, 2020 at 3:15 PM Joseph Eisenberg 
wrote:

> I agree.
>
> Proof of this is that a section of road which was formerly US Highway 99,
> but where the highway ref is now on a new bypass, will often by signed as
> “Old Highway 99”, so it’s reasonable to say that the name=* was “Highway
> 99” before.
>

OK, where were you guys the last time I brought this up?

On Fri, Jul 31, 2020 at 3:31 PM Paul Johnson  wrote:

> Name is only the name.  Names are not refs.  For the above example, ref=NY
> 214, noname=yes would be the right way.
>

The last time I mentioned that using 'State Route 214' as a name appeared
to be common practice around here if (and only if) the road had no other
name. I got quite a chorus of replies, all of which agreed with you.
Richard Fairhurst offered a bunch of UK examples with ref=A1234 noname=yes.

I've certainly been deleting the ref from 'name_1' where it appears (TIGER
put it there throughout) if the road does have another name.  I've not been
jumping to replace all the other ref-as-name with `noname=yes` (I might do
it if I'm editing a way for another reason and happen to notice) because I
have better things to do, and because it's the name that the locals use. It
even appears on blade signs at some intersections, spelt out.

The reductio-ad-absurdum would be to argue that 42nd Street in Manhattan
should be `noname=yes ref=???` and participate in a route relation with
`network=US:NY:New York:Street ref=42`. I'm sure that would please strict
taxonomists, but most people would think it silly to argue that the name of
the road at the downtown end of Times Square isn't 'Forty-Second Street'.
If 42nd Street can be a name, why can't County Route 23C?

There are even parallels for 'the road has a name other than the ref, but
the ref remains the common name' in Manhattan. Sixth Avenue is also named
Avenue of the Americas. Nowadays, it carries signs for both, but I can
remember a time when the locals and the subway said 'Sixth Avenue' and the
street signs said 'Avenue of the Americas', confusing the tourists.  These
are 'name' and 'alt_name', not 'name' and 'ref'; Sixth Avenue was there
first. (Also see Seventh Avenue/Fashion Avenue - only in the Garment
District; Fourth Avenue/Park Avenue South - the segment south of Union
Square)
-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Should admin_level=1 tag be applied to EU?

[Kevin Kenny]

On Thu, Jul 30, 2020 at 5:07 PM Alan Mackie  wrote:

> Many if not most of the entities mentioned in this discussion as being
> candidates for "admin level above country" do have geographic reach
> encompassing multiple countries, but are also limited in scope, often
> severely. To tag such a limited body as fully encompassing a higher admin
> level seems fundamentally flawed as a concept. If their powers were
> expanded to have unlimited scope within that geographic area you would
> effectively have a single larger country. Having an entity grow in scope
> from "admin levels that includes (largely) independent countries" down to
> admin level of a country seems counter to the general structure.
>

The defining test probably has to be the power to engage in foreign
relations with entities at the same admin_level without deferring to the
next higher level.

The test as you have stated it fails in federal systems. In the US, at
least, the plenary power to govern belongs to the States (Or to the People,
but constitutionally this is enforced only by a requirement that each State
have a republican form of government.)  The national government has only
those powers that are delegated to it from the states under the
Constitution. When it tries to exercise plenary jurisdiction (as, alas,
we're seeing nowadays!), it tends to unfold as a constitutional crisis.
The States are above the Federal government, not beneath it.

The reason that this principle is not obvious from abroad is that the
States have delegated to the Federal government the sole power to engage in
foreign relations; a State may not engage in diplomacy abroad because the
States have relinquished that power.  Which is why, when you arrive at JFK,
you clear US customs and not New York's.

By the way, a 'containment' test fails as well in the US.  While there are
no municipal governments that cross state lines (there are some
special-purpose entities that do by the consent of both states and the
Congress, such as the Port Authority of New York and New Jersey), it's not
uncommon for a city to lie in more than one county, or a village in more
than one township.  Having a clean hierarchy of admin_levels just isn't
important to USAians.

And I have Absolutely No Idea what to do with extraterritorial dependencies
or domestic dependent nations.

Feel free to stop reading here. I'm going off topic.

The nearest problem case to me is Ahkwesáhsne, a territory of
the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy that straddles
the US-Canadian border, and whose government is recognized by neither
state. The political situation there has deteriorated into shootings as
recently as 1990, and sabre-rattling among US, Canadian and Akwesáhsro:non
persons as recently as 2009. The disputes usually stem from one or the
other large nation deciding to deny the Kanien'kehá free pratique to travel
and trade within their own nation, requiring customs and imposts every time
the US-Canadian border is crossed.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addr:street for routes

[Kevin Kenny]

.On Fri, Jul 31, 2020 at 12:25 PM Jmapb  wrote:

> Hi all, what's the best way to tag the addr:street of an address along a
> highway route?
>
> Example, I'm mapping houses and POIs along NY 212:
> https://www.openstreetmap.org/relation/411064
>
> Some segments of the route are tagged name=Main Street and the addresses
> there use Main Street for their street name -- easy.
>
> But most of the ways in the route have no valid name. Segments were
> imported from TIGER with name=State Highway 214 but that's been removed
> in favor of ref=NY 214. Written addresses found in government data and
> POI signs/websites/business cards are various: Highway 214, Route 214,
> State Highway 214, State Route 214, NY Route 214, New York 214, NY-214,
> etc. Most buildings are signed with a housenumber only.
>
> Is it best to simply tag addr:street=NY 214, matching the ref tag of the
> segment and the name tag of the route? This isn't consistent with the
> wiki, which specifically says addr:street should match the *name* of a
> nearby *way*.
>

The `addr:street` should match what goes on the address label that a
delivery driver will be reading.

Ordinarily, that's the signed name of the street, if the street has a
name.  Rural New York has many streets that will have a `ref=* noname=yes`
- because their highway number is their only name.  In this case, I use the
postal address spelt out, so a building or address point will
have `addr:housenumber=1234 addr:street="'State Route 214"` or
`addr=housenumber=1234 addr:street="County Route 23C"`

That practice gives some validation engines heartburn - they warn that
`addr:street` shows a name that does not belong to a nearby way. That issue
is the reason that I formerly advocated having the way carry the tag
`name="State Route 214`" if the street has no other name and postal
addresses use the reference.  I was convinced by many others here that the
consensus is that the latter is poor practice, and that simply having the
`addr:street` show a name that attaches to no way is correct.

I think that duplicating the ref `CR 23C` or `NY 214` literally in the
`addr:name` is a less-than-optimal practice; I strongly prefer having the
name spelt out, and possibly including the authority:  `New York State
Route 214` or `Greene County Route 23C`.  Note that the word 'Route' is
appropriate for both of these; New York doesn't have roads formally named
'State Highway' or 'County Road' - both are 'Routes' in the official
documentation.

One reason for spelling out everything is that these fields often wind up
in voice-synthesis software, and it's much easier to deal with spelt-out
words than obscure abbreviations. To this day, when I go to Schoharie,
OSMand will direct me onto 'Enn Wye Thirty Amperes toward Shah-ha-ree'
because Android's voice synthesis lacks a pronunciation for 'Schoharie' and
the context for 'NY 30A'. (I've also heard highway numbers read out as 'Enn
Wye Nine Newtons', 'You Ess Nine Watts', 'See Are Twenty-Three Coulombs',
and so on - apparently a letter following a string of digits is
consistently interpreted as being the abbreviation of an SI unit.)

Side note: We really ought to settle on name:pronunciation or some similar
key, because otherwise there is No Flippin' Way that navigation software
will ever realize that Schoharie is /skoʊˈheɪɹˌiː/, Valatie is /vəˈleɪ.ʃə/,
or Cairo is /ˈkeɪɹ.oʊ/. You're an Upstater, so you know what I'm talking
about! (For those who aren't, the voice of Salli on
http://ipa-reader.xyz/?text=v%C9%99%CB%88le%C9%AA.%CA%83%C9%99 is pretty
close to the local pronunciation, although her intonation isn't quite right
on 'Schoharie'.)

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Two side-of-road parking questions

[Kevin Kenny]

For what it's worth, ordinarily I will map a stretch of road with parallel
or diagonal parking by drawing a parking area that shares nodes with the
road centre-line. The routers find it when asked to find parking, it
doesn't render badly, and I think it expresses the intention.  If there is
parallel or diagonal parking on both sides of the road, it looks like a
road going through a parking field, but if it's `highway=residential` (or
`unclassified` or `tertiary` or whatever) the routers don't appear to care.

On Fri, Jul 24, 2020 at 10:54 AM Paul Allen  wrote:

> On Fri, 24 Jul 2020 at 15:26, Matthew Woehlke 
> wrote:
>
>> On 24/07/2020 10.18, Paul Allen wrote:
>> >
>> > Sounds like the same thing,  Near enough.  Especially if some streets
>> > have signs saying "no parking at any time."
>>
>> Right; I didn't mean "we don't have on-street parking", I meant we don't
>> mark it like that.
>>
>
> Tomato/tomahto. :)
>
>>
>> Relatedly: I would call that "on-street parking". To me, a "parking
>> lane" is actually more like the NYC video I linked, i.e. a space that is
>> dedicated to *parking* and not intended to be used by through traffic.
>>
>
> That's my take on it, too.
>
> This is probably a large part of the confusion, as it seems that what
>> OSM calls a "parking lane" is what I would call "on-street parking", and
>> what I call a "parking lane", OSM considers a parking lot.
>>
>
> A lot of the documentation was written by people who don't have British
> English as a first language.  You have to look at the pictures, too.
>
>>
>> >> BTW, this is what NYC apparently considers a "parking lane":
>> >> https://www.youtube.com/watch?v=RJv4oleZAhQ
>> >
>> > That's a "floating parking lane," according to the video.
>>
>> Yeah, I don't know what "floating" means there.
>>
>
> You don't?  It even explained it in the video.  Or the description.
> Somewhere.
> The parking spaces are detached from the sidewalk because there's a
> bicycle lane between the two.
>
>>
>> > Looks to me like a parking lot adjoining a road at one side and
>> > adjoining a cycle lane at the other.  I say this because of what is
>> > visible at the left of that "floating parking lane" - an obstacle.
>> > Even with no vehicles parked there, through traffic would be
>> > obstructed.  Difficult to be sure, from the video, though.  I'm glad
>> > I don't have anything like that around here, otherwise I'd have to
>> > figure out how to map it.
>>
>> It's pretty typical of what I'm dealing with in Quantico, though. We
>> seem to have come to an agreement to map this as a "lot".
>>
>
> It's how I'd handle the one in the video.  But that's just me, bringing my
> own cultural assumptions and idiosyncrasies with me.  And I'm
> very idiosyncratic.
>
>>
>> > Was there through traffic in the parking lane itself in the above video?
>>
>> I can state with some confidence that there isn't *intended* to be.
>>
>
> I don't recall seeing any.  I don't want to use up more of my
> download limit checking, so I'm relying on my increasingly-
> defective memory.
>
> Again, I think we've agreed to treat that as a "lot". (Which I believe
>> is what I was trying to say, admittedly very badly, with the above.)
>>
>
> I think it's a floating parking lot not a floating parking lane. :)
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

[Kevin Kenny]

On Thu, Jul 23, 2020 at 12:59 PM Paul Allen  wrote:

> Different cultural expectations.  You're looking for information about a
> trail and don't care what form it takes.
>

I suppose that you therefore consider that the principal tag for these
objects, `tourism=information` is somewhat misleading, since it suggests
that the informative function rather than the shape is the important
attribute?

And I guess I had better go back and get a better picture of
https://www.flickr.com/photos/ke9tv/9438767603 because in the photo I can't
really tell whether that's a poorly-set post made from a fallen tree trunk,
or a sign nailed to a tree that fell over and had its top cropped because
it was likely obstructing the trail. (Which would be fine; I haven't
climbed Indian Head in a few years, and it's got a nice view. It'll have to
wait, though, until the local authorities give me a less ambiguous 'green
light' that it's OK to travel there.)

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

[Kevin Kenny]

On Thu, Jul 23, 2020 at 10:23 AM Paul Allen  wrote:

>
> Good question.  But it more closely resembles a guidepost than a blaze.
> Whereas the things being shoe-horned into guidepost in this thread more
> closely resemble blazes.  Elaborate blazes with text.  Not that I'm
> arguing we should abuse either tag by using for other things that
> go against expectations.
>
>
Sometimes 'expectations' turn out, on examination, to be 'cultural
assumptions'. I tend to prefer, where possible, to interpret tags _sensu
lato,_ because otherwise there's a tagging quandary any time something
doesn't fit the definition _sensu stricto_.

In the strict sense that you are advocating. I suspect that my area has
absolutely nothing that you would call a 'guidepost',.

https://www.flickr.com/photos/ke9tv/14276154341 is probably the closest,
since the signs are outboard from the support, but even there, they aren't
finger- or blade-shaped; they are rectangular signs hanging from a
cantilevered arm.

Cantilevered arms are unusual. Commoner practice around here is just to
nail the signs to the support as with
https://www.flickr.com/photos/ke9tv/15541120652 and
https://www.flickr.com/photos/ke9tv/7881561738

Using a post is also uncommon. It's much more usual for the signs to be
placed on whatever is available. Most commonly, that's a tree:
https://www.flickr.com/photos/ke9tv/14276103771
https://www.flickr.com/photos/ke9tv/14092717700 but it can be a utility
pole https://www.flickr.com/photos/ke9tv/6936695538 a building
https://www.flickr.com/photos/ke9tv/14190539728 or some other convenient
surface. (I've seen them on cliff faces, boulders, cairns and bridge
railings, but I don't have photos to hand.)

The common thread in all cases is that there's an enumeration of
destinations, with directions identifying the ways that go to them, and
(usually) the distances to the destinations. I distinguish a guidepost from
a trail blaze in that a trail blaze ordinarily identifies only the trail
you're on - or even just that you're on a trail - and sometimes (more
often, just by implication) the direction to follow.

Depending on the land manager's practice, around me a blaze could be a
simple splash of paint https://www.flickr.com/photos/ke9tv/14018094576, a
generic marker in tin or plastic
https://www.flickr.com/photos/ke9tv/14018066876, a slightly less generic
marker showing a trail purpose such as a spur leading to a campsite
https://www.flickr.com/photos/ke9tv/10282365273, a sign with a route number
(here also augmented with a generic blaze for a snowmobile trail)
https://www.flickr.com/photos/ke9tv/14318057029, or the logo of a
particular trail. For example, in
https://www.flickr.com/photos/ke9tv/7881583380 the stylized AT is the
symbol for the Appalachian Trail, which goes through the crawlway as
indicated by the arrow. The white rectangle (about 5 x 15 cm, long axis
vertical) is the AT's usual blaze. On the sign already shown at
https://www.flickr.com/photos/ke9tv/14092717700, there's a Long Path marker
at upper left, with that particular trail's logo on it. (Its customary
blaze is a 5 x 10 cm rectangle in aquamarine, already seen at
https://www.flickr.com/photos/ke9tv/14018094576.

Usually the only directional indication with a trail blaze will be an
arrow, and it's commoner to indicate the direction by conventional
placement of the markers. In https://www.flickr.com/photos/ke9tv/4988268609,
there are two markers on the tree at right, with the top one offset to the
right, indicating a right turn.

I don't ordinarily map trail blazes unless they're otherwise interesting
for some reason. I make route relations for them.

Sometimes, where a trail crosses open country (farmland or marshy ground)
where there are no stones to build a cairn or natural surfaces to paint a
blaze, a trail will be marked using posts with the blazes marked on them.
Confusingly, the word 'guidepost' is also used in common speech for these,
but I wouldn't use the 'guidepost' tag for them!

I don't think I've ever seen a UK-style finger post on a trail or road
around here.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Finger- or guide-post text

[Kevin Kenny]

On Thu, Jul 16, 2020 at 3:33 PM Sarah Hoffmann  wrote:

> On Thu, Jul 16, 2020 at 07:24:25PM +0100, Andy Mabbett wrote:
> > I am mapping a fingerpost, aka guidepost:
> >
> >https://wiki.openstreetmap.org/wiki/Tag:information%3Dguidepost
> >
> > I would like to add the inscription, for each of the three fingers,
> > with their compass points. I note:
> >
> >https://wiki.openstreetmap.org/wiki/Key:destination
> >
> > is similar but "destination:forward" and "destination:backward" are
> > meaningless in this context; and many finger posts have more than four
> > fingers, or fingers not at 90-degree angles to each other, or to
> > North. I propose something like:
>
> Please have a look at
> https://wiki.openstreetmap.org/wiki/Relation:destination_sign
>
> That's what it looks like in the wild:
> https://hiking.waymarkedtrails.org/#guidepost?id=3673098550
>
> The schema is a bit verbose but it has the advantage that you can clearly
> mark which
> way the finger points to instead of giving compass degree approximations.
>
>
Thanks for the pointer; I'd missed that one!

Do I understand the intent correctly that the direction should be the way
that the finger is pointing, and not the cardinal direction of the route? I
ask because in the US, we often describe a direction as "trail north" or
whatever in that a hiker going 'northbound' on the route will be walking in
that direction - which may be any direction at all on the compass.

Following my accustomed habit of jumping right in with the awkward cases, I
might try to compose the relations for
https://www.flickr.com/photos/ke9tv/7881561738/in/album-72157631291668040/ Note
that the top two signs are 'north' and the bottom two are 'south' in terms
of trail directions.  The post is mapped
https://www.openstreetmap.org/node/4987311715 "Trail north" on the
Appalachian Trail at that point is approximately southeast. (What the
compass says, I'm not sure. At that point, you're standing on top of an
abandoned iron mine and your compass could be pointing in any direction.)

Simply having "to" as a distant node could yield a horribly misleading.
Oh, wait, 'to' is the next node along the way, not the ultimate
destination.  Is there a way to give a node ref for what the 'destination'
corresponds to?  On the sign in question, it might be nice to be able to
indicate where Wawayanda Shelter is, since it's about 40 km distant. On my
screen, you have to go out to z12 to see both it and the guidepost pointing
to it, but the icons for them don't appear until z16 and you need to go to
z17 to see the name.



-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Kevin Kenny]

On Fri, Jul 10, 2020 at 1:34 PM Matthew Woehlke
 wrote:
> > The car park in town, is that barren?
> If it's well maintained, hopefully it is. If it's crumbling, it might
> not be! My previous residence had a paved driveway that, strictly
> speaking, was not barren.

In a wet climate like the one I inhabit, truly barren surfaces are
rare.  Just a few days ago, I spotted these beauties growing in a
crack in the pavement _on a bridge_.  No real soil anywhere about!
They were rooted in whatever wind-blown material had accumulated
between the asphalt of the cycleway and the parapet of the bridge:
https://www.flickr.com/photos/ke9tv/50076407291 There are even a few
stray blades of grass taking root in the concrete.



-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Kevin Kenny]

On Fri, Jul 10, 2020 at 8:19 AM Warin <61sundow...@gmail.com> wrote:

> On 10/7/20 9:30 pm, Peter Elderson wrote:
>
> Looks like humus is a component of soil. So I think soil covers it, being
> a top layer consisting of mixed organic and mineral matter.
>
> To me it is hard to imagine an area as permanently natural=bare_soil.
> Wouldn't there always be some kind of vegetation within a year?
>
>
> Not always.
>
> Sorry to say but some soils have been so polluted combined with the
> resulting soil erosion vegetation has taken some decades to come back.
>
> See https://en.wikipedia.org/wiki/Queenstown,_Tasmania#Ecology
>

I'd imagine that pollution and erosion would result in a surface of
mineral, rather than organic soil; hence the land cover would be clay,
sand, scree, or bare_rock, depending on the particle size. Even the article
you cite mentions areas eroded to bare rock.  These values are all
available for tagging a mineral surface.



-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] nhd tags - documentation page review

[Kevin Kenny]

On Sun, Jun 14, 2020 at 4:21 PM Mateusz Konieczny via Tagging
 wrote:
> I created
> https://wiki.openstreetmap.org/wiki/Key:nhd:fcode
> https://wiki.openstreetmap.org/wiki/Key:nhd:ftype
> https://wiki.openstreetmap.org/wiki/Key:nhd:reach_code
> https://wiki.openstreetmap.org/wiki/Key:nhd:com_id
> about tags added in imports.

I agree with you  about fcode and ftype. My only caveat is that I'd
have to find my old notes; I seem to recall a couple of cases where
there were distinct fcode/ftype for some water feature or other, that
OSM tagging failed to distinguish. (The solution to that is to extend
the tagging and *make* these keys superfluous!)

Reach_code is useful.  It is a _stable_ identifier - the schema
specifies that reach code will not ordinarily change (unlike many
numeric primary keys in databases!). It not only identifies a
particular waterway, but also gives its primary drainage path; the
reachcode of a third-order stream will have that of the second-order
stream as a prefix, and the reachcode of the second-order stream will
be that of the first-order river.

(There are exceptions where, owing to the fixed length of the fields,
an enormous river needs to be divided into two or more parts, but the
principle is there, at least.)

Com_id is somewhat peculiar and I've hardly seen it as a foreign key
in databases other than NHD. I don't much care about it.

So, of the four, reach_code is the only one that I'll raise a stink
about. With that said, extraneous data in OSM are Mostly Harmless.
Deleting unneccessary (as opposed to incorrect) data is never
something that I'd demand.  (It would be good to request that any
further import from NHD - which would have to be done with careful
conflation - refrain from including the FCode and FType.)

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Should we map things that do not exist?

[Kevin Kenny]

On Sun, Jun 14, 2020 at 12:47 PM Niels Elgaard Larsen  wrote:
> Yes. And I would not delete, e.g., power lines that are visible
> on aerials.
> Also because I would not be sure that were really removed and not just
> unused.

I'd add a lifecycle prefix to make sure that someone else looking at
the aerials doesn't put them back.

What do you mean by 'just unused?'

If I'm in the field, looking at the alleged powerline, and finding
nothing, why would I not simply make them go away (with a lifecycle
prefix to protect against someone else tracing from obsolete aerials)?
 I see no poles, no wires, no markers warning people not to dig. If
there's still a cutline visible, I might tag `man_made=cutline`.
Otherwise, the power company might own the right-of-way, but we
ordinarily don't map that sort of cadastre.

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Do we map pedestrian crossings twice?

[Kevin Kenny]

On Wed, Jun 10, 2020 at 1:54 AM Andrew Davidson  wrote:
>
> On Wed, Jun 10, 2020 at 12:04 PM Jack Armstrong  
> wrote:
>>
>> I’ve been told by a user, anecdotally, there’s a Slack group that decided 
>> this is correct. To my knowledge Slack groups do not supersede the OSM wiki. 
>> I assume mapping a crossing twice is incorrect?
>
>
> I don't know if it is "correct" or not, but the footway=crossing tagging is 
> part of the Sidewalk as separate way proposal 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_as_separate_way#Crossings.
-- 
73 de ke9tv/2, Kevin

The technology that current routers use would have a fair amount of
trouble simply deducing from the crossing cycleway that a motorist
would need to avoid a crossing. Still, on a detailed map, it may well
be desirable to map the dimensions of the crossing and add tags for
pavement markings, kerbs (I hope not, but you never know in some
places!), tactile pavement, and so on.  As someone in the Slack
discussion pointed out, you do have two "things" - the linear
cycleway, which changes characteristics when it's on the highway
surface, and the point that represents the interaction between highway
and cycleway - the crossing as seen by a motorist (or a motor router).

As far as I know, all routers need the node if they're going to, for
instance, present a warning to an approaching motorist or cyclist that
the crossing is impending. But some attributes of the crossing (most
notably, its full geometry!) can belong only to a way.

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

Re: [Tagging] Help explain the difference between path and track

[Kevin Kenny]

On Tue, Jun 9, 2020 at 6:13 PM Tod Fitch  wrote:

> The two major factions seem to be set in their ways: “It is only a track if 
> it is used for agriculture or forestry” on one side. “It has the same 
> physical characteristics as a track, so it is a track even if it is currently 
> used for hiking, bicycling, riding horses, or by ATVs” on the other side.
>
> That also spills into is it a track or a service (driveway)? Depends on if it 
> goes to a barn or a house! But I can’t tell without trespassing, how can I 
> map it?
>
> First step, I think, is to be less pedantic about function on things that 
> look exactly like a track. Mappers in all the areas I’ve looked at will tag a 
> way that is unpaved and about the width of a four wheeled vehicle as a track 
> regardless of current use. Maybe it is being used as a driveway. Maybe it is 
> being used as a bicycling/hiking/equestrian trail. Maybe it accesses a field. 
> Maybe it hasn’t been used for a while and just hasn’t decayed or been 
> overgrown into nothing. Who knows? But it looks like a track. Saying that the 
> way “isn’t for forestry or agricultural use” so it can’t be a track is 
> worthless: Real world mappers have voted otherwise with their tagging.

In terms of function, 'track' and 'service' (with or without
'driveway') are practically interchangeable - at least in terms of
what they provide to the road network. They're both distinguished by
the fact that they don't 'go anywhere'. They typically serve only a
single establishment - public roads that serve multiple establishments
are typically at least 'unclassified'.  They typically are something
that a router should treat by default as 'access=destination'. They're
the 'leaves' of the network. The distinction makes essentially no
difference to routing, unless you are of the faction that believes
that 'track' is something that needs more than a regular car. Even
then, if your destination lies on a track, you probably are equipped
for it.  It makes a difference to rendering, well, mostly because
someone thought it ought to.

For me, If I see the ruts that indicate that double-tracked vehicles
use a way, it's at least a track.  That causes me to map some hiking
trails as tracks (because they're also snowmobile trails, or because
there's someone with an inholding who has keys to the gate, or the
park service drives on them, or whatever.  I've departed from that in
cases where the ruts are obviously not current, for instance in the
case of a logging road that's been abandoned long enough that trees
are growing in it, even though ruts and workings are clearly visible
(https://www.flickr.com/photos/ke9tv/14919563634 - note that not all
the workings have held up as well:
https://www.flickr.com/photos/ke9tv/14920137133)

I don't use 'path'  very much except that JOSM wants to use it for
'combined foot- and cycleway'.  Using JOSM, I'll typically tag a way
as a 'path' so that I get the dialog where I can quickly fill in
surface, smoothness, maybe width and incline.  Then I retag using one
of the 'footway', 'cycleway' or 'bridleway' presets depending on the
largest creature that uses it - so I've recently tagged a few
track-ish things around here as 'highway=bridleway surface=compacted
smoothness=good bicycle=designated foot=designated width=3'  There's
some evidence that motor vehicles use it occasionally, but only for
official purposes.

The locals near me seem to use 'service' or 'unclassified' if you can
drive on it in a regular car (at least in summer) and 'track' if you
are likely to need a four-wheeler or at least a high ground clearance.

This is fundamentally an American perspective. I'm sure that there's
some sort of legal difference in the UK between a service way and a
track that's extremely important.

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Meaning of "administrative" in boundary=administrative, in your country?

[Kevin Kenny]

On Mon, Jun 1, 2020 at 5:49 AM Colin Smale  wrote:
> IIRC Indian Reservations can, and do, cross state boundaries, in which case 
> they don't fit in this hierarchy. Or am I wrong here?

Some do. The only one of New York's that crosses the state line is
Akwesasne, which is not recognized as a unified entity by any
government but its own. (The Federal government calls the portion in
New York the 'Saint Regis Indian Reservation'.) The hierarchical point
is that every point in the state is in exactly one City, Town or
Indian Reservation and no City or Town claims an Indian Reservation as
part of its domain.  No Town crosses a county line, and the instances
where a City or Indian Reservation does can be counted on the fingers
of one hand.


-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Meaning of "administrative" in boundary=administrative, in your country?

[Kevin Kenny]

On Sun, May 31, 2020 at 5:34 PM Martin Machyna  wrote:
>
> Just to add to this. I agree that there needs to be a cut off. I would 
> suggest that as long as the area has clearly defined boundaries (in 
> accessible official documents) and it was defined or is actively used by 
> country's administrative officials or agencies then that would constitute for 
> accepting it.
>
> Since these areas often don't fall into exact hierarchy they would not have 
> `admin_level=*` tag, but would instead be distinguished by additional tags 
> e.g. `boundary=administrative + administrative=police`.
> The advantage of this would be that all the areas used for administration 
> would be in one place instead of arbitrary split into many individual tags. 
> And would also preserve consistency, as some countries are already using 
> statistical and cadastral regions under administrative tagging.

US counties (or the equivalent: Louisiana has parishes, and I don't
recall what Alaska's are called) are strictly hierarchical - they
don't cross state lines - and all fifty states have them. The federal
government asks for 'county' on a wide variety of forms, including
passport and security clearance applications. The block that a notary
public uses to witness signatures begins "State of , County of
, SS: (City/Town/Village/Other) of :"

>> "_Administrative boundaries are intended for the general public's everyday 
>> use, not for specialists._"
>
> I don't think that OSM is only for general public and not for specialists. In 
> fact, it is already used by specialist cartography companies and startups. 
> And OSM could even be used by state administrations in the future as well. 
> (Or whoever wants to work with government data visualization)

I don't map special-purpose administrative districts, of which New
York has a whole menagerie. I don't object if others do, but don't try
to fit them into the boundary=administrative hierarchy.  They don't
go. In New York, the admin_levels are as tabulated on the Wiki: 2=US
4=NY 5=New York City (don't ask!) 6=county 7=city, town, Indian
Reservation 8=village, hamlet (outside cities), ward, district,
precinct, community board (in cities). There are only a few ways in
which this scheme breaks hierarchy (New York City, one other city that
has annexed across a county line, a chartered city that has in
practice reverted to being a village, and about 15% of villages are in
two or more towns.). If things like school, library, police, fire,
water, sewer, or sanitation districts were to be included, the
hierarchy would be broken all over the place. And that only scratches
the surface of special-purpose administrative districts. As I said, go
ahead and map them, but don't try to make admin_level fit.


-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Highway mistagging ... again

[Kevin Kenny]

On Sat, May 30, 2020 at 4:44 AM Alan Mackie  wrote:
> I think part of the problem with the highway=track description is that even 
> when you are there on the ground it isn't always clear what it's being used 
> for. They are often two ruts in the ground disappearing of into the distance 
> with little else to go on. If you then look at aerial imagery you may see 
> that is goes to a single house and re-tag as driveway or that it serves 
> multiple buildings and guess at whether the buildings lean towards 
> highway=residential, highway=service or highway=unclassified. It's easy to 
> say "primarily agricultural or forestry" but this is often rather difficult 
> to verify.

And likely, no user cares very much. When it's just two ruts going off
into the distance, if it's part of the road network (you use it to
access multiple establishments or as a connection between other roads)
it's probably an `unclassified` highway.  If it's used just to get to
a house or two, it's a driveway. If it's used for mining, quarrying,
or similar industrial uses, or to access facilities like boat
launches, it's a service way. If it's used for farming or forestry,
it's a track. Except for 'unclassified', which is a hint to a router
that this is the way to multiple places, the only people who actually
care what sort of establishment the track serves are the residents,
workers, customers and guests of the respective establishments. They
already know why the road is there! Sure, if you know the reason the
road was built and want to map it, go ahead, but recognize that it
doesn't really tell people all that much.

> There is then a separate problem in that OSM-carto, the default 'check that 
> it worked' renderer, doesn't render road surfaces or tracktypes for anything 
> other than tracks. This discourages the 'proper' tagging for those who want 
> to tell at a glance how likely they are to get their car stuck or how likely 
> it is that they will be able to do a three point turn if there are 
> obstructions.
>
> Tangentially, I have always found the tracktypes a little difficult to apply 
> if you don't have the type of soil depicted in the examples. Some ground 
> tends to get "lumpier" rather than softer if you keep using it without 
> improvement.

Hmm. I don't think I've ever tagged a tracktype. When I'm trying to be
careful about the details, I tag surface and smooothness, add width if
it looks to be a problem for turning around, and hope for the best. I
also have occasionally used an unpopular and unwikified value like
`surface=shale`.  That can be very rough and lumpy indeed when it's
laid, but over time the shale weathers to smaller flakes of stone
mixed with fine clay, and in dry weather a shale road can offer a fine
compacted surface that doesn't even need to be rolled that often.

As far as I can tell, `tracktype` is mostly intended for surface
firmness: how likely are you to sink if you drive it in wet weather?
If I'm not doing a field survey in mud season, it's hard to tell.
Everythiing from grade3 to grade5 will have vegetation growing on it.
In the ruts, I'll see at least some hard material because the soil
around here is stony.  (Around here, too, grade1 is likely to be at
least `highway=service`, since nobody troubles to seal a track that's
used just for tractors or logging trucks.) I also don't see a lot of
ways with `tracktype` in my part of the world, so I don't have good
local examples to go on.
-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[Kevin Kenny]

On Sat, May 30, 2020 at 10:16 AM Mateusz Konieczny via Tagging
 wrote:
> May 30, 2020, 15:46 by wes...@gmail.com:
>> Is highway=path a type of way (wilderness trail or whatever term we use)
>> or a way for non-specified/mixed use?
>
> way for non-specified/mixed use, that due to its unfortunate name is sometimes
> used and interpreted as indicating a wilderness trail
>
> would it be  good summary of a situation?

This thread would not have gone on as long as it has if there were a
consensus on your statement.

Mind you, I'm not arguing the contrary. At this point, I don't know
what it means. Whatever the world decides, there are a lot of things
that will have to be retagged or have more information provided.


To Daniel's list, I'd add objectives:
 - Avoid basing routing decisions on the absence of a tag; every
attribute should have a specific negation available.
 - Avoid requiring mappers to be expert in a specific sport before a
way can be identified as unsuitable for that sport. For instance, one
should not be required to be knowledgeable enough to assess
`mtb_scale` before being able to assert "this way is not suitable for
commuters on road bikes."

Better nuance for hiking trails is really low on my list, except at
the very lowest end of the difficulty scale: can someone NOT prepared
for hiking (for example, using a mobility aid, or wearing high heels,
or with small children in tow) be routed down it? Hiking trail nuance
is also not something that needs to inform routing decisions made by a
computer; at least to me, the idea of using an autorouter to plan a
hike boggles the mind! We have abundant ways already to tag specific
hazards and conditions. I can read.

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Examples at https://wiki.openstreetmap.org/wiki/Key:access

[Kevin Kenny]

On Fri, May 29, 2020 at 11:03 AM Adam Franco  wrote:
> Adjacent to Kevin's home state of New York, here in Vermont we have a 
> slightly more open private-land access laws. While property owners may post 
> no-trespassing signs (access=private) (statute), the default when unsigned is 
> access=permissive for non-motorized crossing of land. To encourage public 
> access of private land the state limits the owner's liability unless the 
> damage or injury is the result of the willful or wanton misconduct of the 
> owner.

New York offers the same indemnification -- non-paying, uninvited
visitors cannot recover from the landowner except in the case of
willful or malicious failure to guard against or warn of dangers. Use
of a public-access easement, or wandering onto unposted land, does not
constitute an invitation. But that's a general protection whether you
post or not - you simply aren't responsible for the safety of
uninvited guests if you don't do anything malicious. (You cant set
traps, or knowingly steer them into danger, but you have no
responsibility to guard them against hazards that exist for other
reasons.)

While non-motorized access to unposted land is not a legal default,
New York offers "ASK PERMISSION SEE LANDOWNER" stickers free of charge
to go on posters indicating that access may be granted to strangers
https://www.dec.ny.gov/docs/wildlife_pdf/askperm.pdf, and similarly
offers a standard-form permission card that landowners may use:
https://www.dec.ny.gov/docs/wildlife_pdf/ask.pdf. Many landowners use
them; they consider law-abiding visitors to be their eyes and ears for
problems with the property. Simple NO TRESPASSING posters serve only
to exclude the people you _want_ to visit, and are no deterrent to
poachers or vandals!

The state will also, in some cases, purchase access easements, usually
offering a corresponding decrease in the assessed value of the land
and hence a decrease in the property taxes. (I'm not all that versed
in those matters. My brother is more up on it than I am. He has
foregone some of his development rights because undeveloped forest
land is taxed at a lower rate; the Boy Scouts lease a trail easement
across his back acreage in the summer; and there's a hunting club that
leases the hunting and fishing rights, so he gets a little bit of
compensation; but he hasn't granted rights to the public at large. I
live in town and don't deal with that sort of thing except as a
hiker.) I've done a fair amount of travel across easements on land
belonging to large timber concerns such as International Paper.

On Fri, May 29, 2020 at 1:06 PM Colin Smale  wrote:
> In the UK it is apparently not required to demonstrate actual damage:
> https://www.inbrief.co.uk/land-law/trespass/
>
> You might like to peruse this document, which is an explainer for members of 
> parliament:
> https://researchbriefings.files.parliament.uk/documents/SN05116/SN05116.pdf

From the latter page: "Where the trespass is trivial, damages may be
nominal and an injunction refused. Where a trespass concerns some use
of the land without causing damage, the damages will be measured in
relation to the value of the defendant’s use." A plaintiff who sues
someone who is unknowingly encroaching and causing no actual damage is
likely to wind up with peppercorn damages. What is the value, after
all, of walking along someone's hedgerow to get to the next field
over?

> If any actual damage is done however, then the damage itself may constitute a 
> criminal offence ("Criminal Damage").
>
> As trespass is a civil tort the police won't turn out to help. You (the 
> landowner) will have to take the trespasser to court, which is an inalienable 
> right. The question is then, how will the magistrate think? What makes a 
> valid claim, and what is a valid defence? As it is not a criminal case, I am 
> not sure if mens rea comes into it. But the "intent" will definitely 
> influence the court. As they say, ignorance [of the law] is no excuse; so 
> pleading that you did not realise it was private property or that you were 
> not allowed to be there will not help, possibly unless you claim that you has 
> misread the boundary on a map, for example.

That is ignorance of the facts, rather than of the law. Ignorance of
law is no defence - you can't offer up, "I didn't know that
trespassing is illegal." Ignorance of fact is, "I didn't know that I'd
left public land." It's an affirmative defence; the burden of proof is
on the defendant to offer evidence of what led to the incorrect
assessment of the facts - for example, the misread boundary that you
mention.

Particularly in the areas that Adam and I discuss, there is so much
public land with complex boundaries that if an owner doesn't post,
it's easy to make the case that you unknowingly crossed the boundary
between public and private domains. The matter is compounded by the
fact that the vegetation and topography of our woods present certain,
ahem, navigational challenges. The 

Re: [Tagging] Examples at https://wiki.openstreetmap.org/wiki/Key:access

[Kevin Kenny]

On Fri, May 29, 2020 at 6:32 AM Colin Smale  wrote:
> In the UK (especially Scotland) land ownership is pretty absolute. Every bit 
> of land is owned by someone, even if that owner is The Crown. The owner has 
> an absolute right to determine who has right of access, except for certain 
> cases, like a Public Footpath or designated open access land that falls under 
> the "right to roam" legislation. A person's house and driveway does not fall 
> under these exceptions, so there is no right of access, except with the 
> landowner's permission. So here we have "access=private". That does not mean 
> you cannot knock on the door, or deliver a parcel however; whether by so 
> doing you are committing civil trespass is not a priori clear - it depends on 
> the circumstances; modelling all these circumstances in OSM is an enormous 
> challenge that I don't think we are looking to solve here.
>
> Despite private ownership, the exceptions I mentioned (public highway, open 
> access) are "access=public" AKA "access=yes". It is illegal to prevent access.
>
> Of course there are rules and limitations in all cases as to the type of 
> access: public footpaths are deemed to be ±1m wide and access is only granted 
> to pedestrians, not to motor vehicles for example.
>
>
>
> I believe that there is a defence to trespass on the grounds of "custom"
> which IMHO would cover deliveries to your door, or someone needing
> emergency help, or door-to-door salesmen (all in the absence of explicit
> signing to the contrary of course).


_Mens rea_, at least in most of the US, is an element of criminal
trespass, and the liability for the civil tort of trespass is limited
to actual damages in most cases. Since most of the key definitions in
this part of the Common Law were established before our legal systems
diverged, I imagine that is so in the UK as well. If you haven't
damaged property by your unauthorized presence, and you haven't been
told that land is private or invaded the curtilage of a dwelling, the
owner has no cause of action. In effect, all they can do is to demand
that you leave; the cause of action doesn't arise until you fail to
comply.

Being told that the land is private can be accomplished with signage,
which is why 'POSTED' and 'PRIVATE ROAD' signs are ubiquitous in the
US.  (And, of course, Louisiana law is different!)

We have no 'right to roam' here other than the fact that you haven't
been trespassing unless you knew or should have known that your
presence was unlawful, and are legally liable only for damage you
cause. (My state also negotiates public access easements with many of
the timber companies, who are willing to tolerate the presence of
hikers in order to get a small tax break.)

This gives rise to a number of paths whose legal status is unclear -
which means that until asked to leave, you're potentially liable only
for damage that you cause. Building fires or camping both tend to be
considered damaging activities intrinsically (although I'm unaware of
any coherent body of law on the matter), and someone carrying a
firearm or a fishing pole can be presumed to be poaching, but simply
walking on a private trail that isn't obviously in the curtilage of a
dwelling, gated, nor signed, is pretty much in the category of
"unlawful, but the law is unenforceable."

If a formal trail winds up falling into that circumstance, and a new
landowner objects, the trail _may_ be relocated, but it's commoner to
negotiate a settlement involving an easement for the trail. In the US,
as in the UK, there are also trails that use nearly-abandoned
rights-of-way from roads that predate the automobile. Until and unless
the landowner successfully pursues an abandonment proceeding in court,
the rights-of-way remain open. For this reason, boundary-line trails
like https://www.openstreetmap.org/way/456137516 may be mismapped if
they're shown as crossing the property line, or the property line may
be mismapped, but it's equally likely simply that the property line is
indefinite and the trespass, if there is one, is tolerated. It's
surely not a reason to abstain from walking a marked path for fear of
trespassing.

The root cultural assumption has changed in my time.  I can recall a
time when few farmers cared about walkers in their fields, as long as
you kept to the field edges or tracks so as not to trample crops,
refrained from disturbing the livestock, and left the gates as you
found them. Few farmers troubled to post. Now there are posters
everywhere, and a general sentiment that 'everything is forbidden
unless explicitly allowed.' Eventually, I expect that the codified law
will come to follow the new belief, so I may be a member of the last
US generation that remembers a customary freedom to roam.

In my state, all navigable waterways belong to the state, and the
definition of 'navigable' arose at a time when trading by canoe was
common, so you pretty much have the right to paddle across anyone's
land, but not to land your 

Re: [Tagging] line=* tag on railway lines

[Kevin Kenny]

On Thu, May 28, 2020 at 3:56 PM Jack Armstrong  wrote:
> I have wondered for a long time...
>
> If the rail is tagged name=* but the railway also has a relation with the 
> same name, isn't this naming something twice? it seems to me the relation is 
> sufficient and the rail itself should not be named?

There are cases where there is a whole hierarchy going on, which may
involve superrelations and the like:

Metropolitan Transportation Authority
Metro-North Railroad
Harlem Division
Wassaic Branch

So it may be the case that there's a part with one name while the
whole has another.  The rail-mappers seem to prefer assigning 'line'
and 'branch' values since that hierarchy is common in their world. But
hierarchical names are sometimes unavoidable. Thinking of my local
bicycle infrastructure, there's a small segment of
(highway=residential) Island View Road that's also routing around an
interruption in a rail-trail (the railbed was destroyed by
construction of a freeway). It's simultaneously 'Island View Road',
the 'Mohawk & Hudson Bike-Hike Trail (lcn)', the 'Erie Canalway (rcn)'
and the 'Empire State Trail (also rcn)' depending on where you are in
the hierarchy.  It's signed for all of them.

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[Kevin Kenny]

My very first attempts at editing with JOSM, some years ago, were
adding hiking paths.  I followed JOSM's templates, with
'Highways->Ways->Path' appearing to be a natural match, and got
`highway=path foot=designated etc.` for the constructed path.

I uploaded the result.

Another mapper gave me a (very mild) scolding, changed them all to
`footway`, and steered me to the JOSM templates for dedicated footway,
dedicated cycleway, bridleway, combined foot/cycleway, and so on.
Since then,I've been using those, which causes `highway=path` to
appear for any combined foot/cycleway, but causes `highway=footway` to
appear for anything from a broad paved path in a city park to a
technical wilderness trail.

According to Florimond, that's correct. According to Daniel, that's
read as an assertion that the technical trail is an urban footway.
According to the Wiki, it depends on what page you read and how far
you get into the comments. According to the mapped data, it varies
considerably according to where you are. (Near me, there's a major
cycleway - paved doubletrack - that's 'highway=path bicycle=designated
foot=yes'. I walk a few km on it nearly every day.) To a data
consumer, it's "oh well, I don't know what it is" and either an
optimistic assumption that it's routable or a pessimistic assumption
that it isn't.

Compounding the issue is that while the `path` preset offered all the
'surface', 'smoothness', 'incline', etc. tags, at the time the
`footway` preset was much more limited. It does now; that's been
fixed. Well, mostly: `footway` and `cycleway` still don't offer ski,
snowmobile, sac_scale, mtb_scale or visibility; those are available
only on `path`. So the confusion appears to run deep, with even JOSM's
presets running both ways - paths get the option to have the 'back
country' options, while cycleway/footway do not, but
combined-foot-and-cycleway is a path.

I'm now trying to make it a practice to supply `surface` and
`smoothness` when I add trails, and `sac_scale` where I think I can
scale it without too much controversy. See my earlier message about
how I've had southern Germans look at what I'd consider a highly
technical (grade 4 on the Yosemite scale) trail, and insist that it's
at most 'mountain hiking'. I think they simply refuse to concede that
technical trails might exist outside the Alps. I hope that's enough to
keep routers from keeping Granny and little kids off the rock
scrambles and road bikes off the trials courses.

But there are a LOT of highway=footway out there with NO other tags,
or just a name. I don't know what a data consumer may safely assume
about these, or for that mapper, what minimum set of information that
a mapper is expected to provide for the path to be routable.

I'm hoping that the minimum doesn't include 'incline'. Some of the
trails I map are full of PUD's (Pointless Ups and Downs).  I don't
want to have to bring a clinometer in order to map them and to split
segments anywhere that the gradient changes, particularly since tools
like Waymarked Trails are perfectly capable of draping the way over a
digital elevation model.

So I return to, 'what's the minimalist set of attributes that we can
use to guide a data consumer, and conversely, the minimum set of tags
that a data consumer needs to recognize?' Specifying every attribute
in excruciating detail is fine if you're trying to map your area
artistically and say as much as possible; it shouldn't be necessary
for a mapper to do so, or for a data consumer to understand
everything, in order to get reasonable approximate results.

On Thu, May 28, 2020 at 2:21 PM Florimond Berthoux
 wrote:
>
> Hello,
>
> That's crazy how much people get confused about the triplets 
> path/footway/cycleway
>
> highway=path for mixed path
> highway=footway for foot path
> highway=cycleway for cycle path
> Nothing to do with surface, localization, or whatever other properties, just 
> there main usage.
> We should not map multiple feature in one tag.
>
> The wiki explain it well :
> https://wiki.openstreetmap.org/wiki/Key:highway
>
> highway footway : For designated footpaths; i.e., mainly/exclusively for 
> pedestrians. This includes walking tracks and gravel paths. If bicycles are 
> allowed as well, you can indicate this by adding a bicycle=yes tag. Should 
> not be used for paths where the primary or intended usage is unknown. [...]
>
> highway cycleway : For designated cycleways. Add foot=* only if 
> default-access-restrictions do not apply
>
> highway path : A non-specific path. [...]
>
>
> Le mer. 27 mai 2020 à 14:00, Daniel Westergren  a écrit :
>>
>>
>>> Would it be wrong to set sac_scale=hiking on an urban footway? I’m worried 
>>> that we’ll get highway=path, foot=designated, cycle=designated, 
>>> surface=paved, width=2.5, lit=yes, rubbish_bins_every=100m, 
>>> sac_scale=hiking.
>>
>>
>> Same with mtb:scale.
>>
>> A footway or cycleway should, in my opinion, never have sac_scale or 
>> mtb:scale, unless we introduce explicit values 

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[Kevin Kenny]

On Tue, May 26, 2020 at 6:59 AM Andrew Harvey  wrote:
> From what I can tell, the ask is a tag for a specific type of way which the 
> person needs experience or preparedness before undertaking. But I'm lost and 
> still not completely understanding what exactly this new tag would cover 
> exactly and what it wouldn't.

I've said repeatedly - but people are not listening - that what's
needed is the opposite. More specific ways to tag the hazards of a
technical trail is the exact opposite of what I want.

A data consumer cannot draw any inference from the absence of a tag.

We already have an enormous cauldron of tag soup to describe
smoothness, surface, width,incline, steps, visibility, tracktype,
overall technicality (sac_scale, mtb_scale), and $LC_DEITY knows what
else, to characterize specific hazards. Many of these (smoothness,
surface, visibility) have ways to characterize freedom from those
hazards. Some (most notably sac_scale and mtb_scale) do not. This lack
is _part_ of the problem, so _part_ of what I want is to be able to
say something like `mtb_scale=0` or `sac_scale=no` - to say, "this way
is non-technical." But that's a very minor issue.

i don't think that it's going to work to have to enumerate every
possible hazard and assert that a way is free from it. Rather, in
general, for a footway, we need a way to assert 'this path is
generally OK for a person with less-than-ideal physical fitness or
small children in tow." For a cycleway, we need a way to assert, "this
path is generally OK for a road bike." This assertion cannot be made
by omitting tags. A router cannot tell the difference between 'the
mapper didn't say anything about difficulties or hazards', and 'the
mapper thinks it's OK.'

(Feel free to stop reading here. The rest of this message tries to add
detail. The key point is "a positive assertion that the given way is
OK for a pedestrian/cyclist of ordinary ability".)



The assertion needs to be as simple as possible.  which is what leads
to the discussion of separating urban paths from technical trails
using a top-level key (and the misconception that there's actually a
difference between `cycleway` and `path`).  I agree with the others
who say that train left the station a long time ago, and we're
unlikely to catch up with it to board it.

What I'm asking for is some minimal set of tags, that we can expect a
mapper to provide as a matter of course, to assert that a way is free
from unusual hazards. To assert that a walker of ordinary ability,
dressed in ordinary street clothes, and perhaps with small children in
tow, can use the path. To assert that a cyclist of ordinary ability,
aboard an ordinary road bike can ride it. Adding more tags to describe
that something does have difficulties or hazards will not help.

Emphasis there is also on the word, 'minimal'. What is the minimal
information that a mapper needs to provide to let a router draw that
conclusion? Obviously, if we were civil engineers assessing trail
safety for people with disabilities, small children, or racing wheels,
we'd have a lot of formal evaluations to conduct. But if I have to
bring a clinometer (or transit and rod, etc.), make the delicate
distinction between pea gravel and compacted-mixed-gravel-with-fines,
or cobblestone and sett, and so on, before I can say, "this is a
regular old path in the city park", it's not going to happen!  The
best I can do is to presume that whoever built the path did the job,
or do the required analysis on a set of ways that's too small to be
really useful.

The other side of the same coin is that I shouldn't need expert
knowledge and a detailed characterization of the hazards to be able to
map, "nope! Not going there today!" We enjoy over-classifying
everything, and making the fine distinctions is wonderful. But how far
would we have got in mapping if a mapper couldn't say, "there's a
bridge here" without needing to know the difference between a
king-post and a bowstring truss?

All of the tags that assert technical hazards are, in the current
scheme, trolltags. We've rejected that sort of thing for cars. We no
longer say `highway=tertiary demolished=yes` or `highway=tertiary
construction=yes` because we recognize that the secondary tag says,
"just kidding! You actually can't drive on this!"  We realized that
routers for cars can't make effective use of an entirely open-ended
set of tags that all say, "don't use this road", and we've changed the
schema to fix it, with things like the lifecycle prefix.  I want the
same level of respect for walkers and cyclists.

It comes down to two basic questions:
- What is the minimum set of information that a mapper needs to
assert, to have a bicycle or pedestrian router assess that a way is
usable by a pedestrian or cyclist of ordinary ability?
- What is the minimum set of information that a data consumer needs to
take into account when making that assessment?

By paying careful attention to eliminating trolltags, we've nearly
answered 

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[Kevin Kenny]

I took the liberty of revising the English translation in
https://wiki.openstreetmap.org/wiki/Key:sac_scale#Values to something
that I hope will be more helpful to English speakers. Some of the
phrases had obviously been machine-translated - the worst was most
likely 'single plainly climbing up to the second grade' which I
changed to 'Isolated easy climbing pitches up to UIAA grade 2'.

My German is not secure, and the original
(https://www.sac-cas.ch/fileadmin/Ausbildung_und_Wissen/Tourenplanung/Schwierigkeitsskala/Wanderskala-SAC.pdf)
is in Süddeutsch, verging on Schwyzertütsch, so please check me out on
it!

On Mon, May 25, 2020 at 7:42 AM Daniel Westergren  wrote:
> In Swedish we have basically "väg", which would translate to road or way, 
> while "stig" would translate to footpath/path/trail,
"Väg" is cognate to the English "way" - go back to the Tenth Century,
and they're the same word. Old Norse 'stígr,' 'wanderer,' appears not
to have survived into English, although one word that we use for the
concept clearly has Norse roots: 'vagabond.' 'Path' is of
West-Germanic origin, and has cognates in German, Dutch, Frisian,
Luxembourgeois, and (!) Finnish, but apparently not the Scandinavian
languages. "Track" came to English from Old French, but is almost
certainly a Norse borrowing. It's related to English words such as
'tread' and 'trek', Norwegian 'trå', and Swedish 'träda'.

> Sorry for having caused a very long, but certainly very interesting and 
> engaging thread on this never-ending topic. If it was discussed this way 12 
> (?) years ago, things would have been simpler. I understand the consensus as 
> although it would have been good, it's probably too late for a separate 
> highway tag for "trail" or whatever we call it and the only way forward is a 
> subtag like "highway=trail"? Although what we need then is a clear definition 
> of what it is and a way to handle all the cases when this subkey will not be 
> used.

Let me reiterate that the subkey that's needed is actually the one
that asserts 'this IS what one would expect of an urban or suburban
footway', rather than 'this is a relatively unimproved "natural"
trail'. We already have many attributes that would indicate that a
trail might be relatively unimproved (`surface=ground`; `incline=*`;
`wheelchair=no`; `width=*`, `smoothness=*`, `sac_scale=*` and so on).
The fundamental problem is that it is not safe to draw any conclusion
from the absence of such a tag. A mapper may have tagged a wilderness
trail as `highway=path` or `highway=footway` and simply not added the
other attributes.

The best way to help the data consumer will be to have a tagging
scheme that allows asserting 'this IS an urban/suburban/front-country
footpath' as well as 'this is a relatively unimproved trail'.  It's
true at the start that providing such a thing will leave most
`highway=path` features ambiguous, but it at least would open a way
forward for disambiguating them. `path=trail` will NOT accomplish that
goal, because it still leaves two choices: 'this is a trail', and
'this is unknown/ambiguous'.
-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[Kevin Kenny]

On Sun, May 24, 2020 at 8:01 PM John Willis via Tagging
 wrote:
> Mapping “where the sidewalk ends” and the trails begin is vital to keep 
> people from being routes where grandma could have a heart attack Climbing a 
> difficult route or break her leg crossing a stream because we routed her on a 
> trail down a ravine rather than on the longer, yet safer sidewalks down along 
> the roads or paths through a local park because there is no way to say “THIS 
> IS A TRAIL, not a walkway through a playground” in OSM.

We do have that: `sac_scale=hiking`; as I understand it, few trails go
beyond 'hiking', so that's at least better than nothing. (It still may
suffer from underestimating the trail, leading city folk to the
sketchy rock scrambles when they're expecting a nice level dirt path,
so try to get the scale at least reasonable.)

What we don't have - at all - is the complement: 'THIS IS INDEED A
PATH'.  When we see 'highway=path', we don't know whether it's indeed
a path, or a hiking trail where the mapper didn't assign an
`sac_scale`.  We need a way to assert 'THIS IS A PATH' that doesn't
depend on the absence of a trolltag.

I can't stress enough that as long as we have the ambiguity, the only
way to 'fail soft' is to support the assertion 'this is relatively
safe', because we can deduce nothing from the absence of a 'this is
dangerous' assertion.

Incomplete information should 'fail soft'.

On Sun, May 24, 2020 at 8:32 PM Andrew Harvey  wrote:

> Agreed, the biggest question is how do you define that criteria for what is 
> going to be tagged a a hiking trail and not a hiking trail.
>
> Eg. if you have a smooth paved track through the rainforest that the 
> authorities created for grandparents and strollers, is that a hiking trail 
> just because it's in a forest area? What about a stroll through the hills of 
> grasslands that have no forest or mountains, is that marked as a hiking trail?

No, just being in a forest doesn't make something a trail.  I think
that it's pretty safe to assume that 'surface=compacted
smoothness=intermediate wheelchair=yes` with a connection to a highway
or parking area not strictly a hiking trail, and there are some trails
near me- even in Wild Forest areas- that are constructed in such a way
to offer wildland access to persons with disabilities. I'd be happy
considering those trails on an equal footing with urban paths.

A hiking trail can be an easy trail through the lowlands. (Those are
rare near me, because the lowlands are mostly either settled and
subdivided, or else sucking swamp, so the mountains are what is left
for hiking trails to go.) I already mentioned that sac_scale discounts
hazards other than mountains (and focused on water, but Graeme can
surely fill in a number of deadlies that are specific to his
continent).

A lot of it comes down to, "would you route mobility-impaired people
or folks with small children in tow down this?"  A wrong decision for
some ambiguous corner case will be mostly harmless. Not having the
information for a dangerous trail might be deadly.

> I think it's too hard to have a reliable criteria for this which can be 
> objectively surveyed, it's much easier to tag each attribute individually on 
> their own independent scale.

The _reductio ad absurdum_: by the same token, because there is
controversy in many locales over which highways should be
`highway=trunk` and which should be `highway=primary`, or which should
be `highway=service` and which should be `highway=track`, all highways
should be tagged just `highway=road` and the relevant attributes
(surface, smoothness, speed limit, number of lanes, ...) should be
mapped instead. Few if any of us think that would be appropriate. Why
can cars get a hierarchy of ways, while hikers, equestrians and
cyclists cannot?

Since the possible set of attributes is open-ended, the result of not
having some sort of categorization is a nightmare for data consumers,
trying to determine how to render a road, or whether the road is
routable in the current circumstances, or where there are 'trails for
hiking near here'. No sensible symbology can map all the possible
attributes, and no sensible router can take all of them into account.
At some point, _someone_ has to make the call of what is considered
suitable, and punting that decision all the way to the end user is
what leads to the sort of accidents that Graeme, John and I have been
discussing.

Even an 'objective' attribute often turns into a controversial
position; consider 'car=no' versus 'car=private'. A lot of mappers
think that 'no' should be reserved for ways on which it's physically
impossible to drive a car: What about the corner case of ways that
could accept only a car with high ground clearance, or a way that a
skilled stunt driver could manage but most drivers could not?  So now
we need to come up with separate tagging indicating the legal status,
versus the physical status, and a detailed physical model of how the
way affects the 

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[Kevin Kenny]

On Sun, May 24, 2020 at 12:53 PM Volker Schmidt  wrote:

> This proposal is not going to fly, unfortunately. As I said before the big 
> issue, at least in central Europe, is the massiv use of highway=path (with 
> the additional "designated" tags) for foot-cycleways. We will have to live 
> with that. The non-foot-cycle "paths" can be handled by surface, smootness, 
> and sac-scale tags.

The point is that you can't draw any inference from the absence of a
tag. We can't assume that because a mapper didn't tag sac_scale, that
a path is passable to small children or disabled people. We might have
to deal with the 'unknown' state for quite a while (and a router can
try to guess from some combination of the other tags), but eventually
we need to enable mappers to make the positive assertion that a path
_is_ accessible to people who aren't skilled hikers - at least to the
extent that urban footways usually are.

The absence of a tag `potrzebie=*` doesn't mean 'there's no potrzebie
here'; it means only `the mapper didn't say anything about potrzebie.'
Drawing the conclusion that 'there's no potrzebie' would require an
explicit `potrzebie=no` or some such.

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[Kevin Kenny]

On Sun, May 24, 2020 at 5:42 AM Sarah Hoffmann  wrote:
> On Sat, May 23, 2020 at 09:58:50PM -0400, Kevin Kenny wrote:
> [Australian grading of hiking trails]
> > And all five of those grades are sac_scale=hiking, which is why I say
> > that's an impossible scale to use for the purpose we're considering.
>
> That's not correct. If you have a look at
> https://wiki.openstreetmap.org/wiki/Key:sac_scale
> you'll notice that only from sac_scale=demanding_mountain_hiking the
> scale starts to have the requirement "basic alpine expericence" and
> "good hiking shoes".
>
> So: Only Grade 1 and 2 are clear sac_scale=hiking. Grade 4 would map
> to sac_scale=mountain_hiking and Grade 5 to 
> sac_scale=demanding_mountain_hiking.
> Grade 3 is a bit inbetween but I'd probably put it under
> sac_scale=mountain_hiking to be on the safe side.
>
> The SAC scale grades 1-3 are quite helpful. It's just the blue scales 4-6
> which are not really applicable in OSM because very few routes of that
> scale would fall under the highway=path classification (even under the
> catch-all definition of OSM).

The first problem with the sac_scale is that it's not got anything at
the low end. For trails in urban and suburban areas, we want to know,
for instance, whether the trail might be accessible to the disabled or
to small children. That's actually the single biggest problem here.
Without delving into a ton of auxiliary information, there's no
difference between an urban footway and a wilderness trail!  For that
reason, 'surface' and 'smoothness' and 'incline' and 'sac_scale' are
all trolltags: they destroy fundamental expectations (at least to
urbanites) of what a 'path' is. (Those false expectations are
responsible for many outdoor accidents in my part of the world - I'm
close enough to several large cities that we get many unprepared
tourists.)

I agree that highway=path and highway=footway are too entrenched, so
we're going to be stuck with trolltags.  In that case, we need fairly
clear and repeatable guidelines for both mappers and data consumers -
right now, trying to figure out, 'do I have an urban footpath or a
wilderness trail' is a complex endeavour, and mappers aren't really in
a position to help. While you can add 'sac_scale' to flag that a path
is unsuitable to small children, disabled people, or less-skilled
hikers, how do we flag that a path _is_ suitable? (The absence of a
tag cannot be the answer, because the absence of a tag conveys at
best, "I don't know." It's best never to draw any conclusion at all
from the absence of a tag.)

Those who aren't hiking geeks may stop reading here, the rest gets
more technical:

One-line summary: I clearly don't understand sac_scale, but my
discussions with the OSMers have done little to clarify it in my mind.

I just reread the `sac_scale` page yet again . I'm afraid that I don't
find it quite as helpful as you do, even in the domain for which it's
intended. It appears to have been awkwardly machine-translated to
English from another language. For example, 'acclivity' and 'facile'
are both Latinate words that a native speaker would use only when
writing in an affected academic style. My university-educated (but
geologically-ignorant) wife didn't even know the word 'acclivity'
without looking it up!

At the higher levels of difficulty, the page focuses on mountain
hazards. There's no consideration for slippery or unstable bog
bridging, stream crossings (rock-hop or ford: and how deep or
fast-moving is the water?); deep mud or quicksand, likelihood of
encroaching vegetation, or beaver activity. All of these present
objective hazards (falls, drowning, hypothermia) that come into
assessing a trail's level of difficulty and danger.

The phrase 'single plainly climbing up to second grade' comes across
as word salad. I have no idea what the word, "single" refers to. What
is "plainly" climbing? I presume that "second grade" is on someone's
scale of rock- or ice-climbing difficulty, but have no idea what scale
to look at to translate to the YDS that's pretty universal in the US.
If it's the UIAA scale, then I can sort of make sense of it: grade II
is roughly equivalent to 5.3 on the Yosemite scale. A hiking trail at
the technical end of things might have a 5.3 move somewhere, if it's
not exposed. If I'm doing anything beyond class 4 (YDS) in an exposed
position, I want a belay and a helmet, and that's no longer hiking!
[Afterthought - I finally found the original German. 'einzelne
einfache Kletterstellen'. Then the following grade (Schwieriges
Alpinwandern) says 'Kletterstellen bis II UIAA', so I guessed right on
UIAA. I suppose that if you're unaware of the context, 'einzeine'
could be single and 'einfache' could be 'plainly', but the translation
of the whole phrase on the Wiki is nonsense. Any objections if I edit
it to something like: "Isolated easy cl

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[Kevin Kenny]

On Sat, May 23, 2020 at 9:11 PM Tod Fitch  wrote:
>
> Being a Sierra Club member in California, it seems to me that the Yosemite 
> Decimal System (YDS) [1], originally created by the Sierra Club is made to 
> order for this. Classes 1 through 3 are basically hiking, 4 is transitional 
> and 5 is technical climbing. My understanding having been exposed to this for 
> decades is slightly different from that in Wikipedia mine are:
>
> 1 - No special gear or equipment needed. If not the equivalent to a city 
> sideway in difficulty, it is very close.
> 2 - Uneven, loose or other surfaces where good hiking shoes are advisable.
> 3 - You may occasionally need to use a hand to steady yourself in difficult 
> areas.
> 4 - Climbing or scrambling but low exposure and/or low risk of injury such 
> that safety equipment like ropes are not required.
> 5 - Climbing requiring technical skills and equipment.
>
> Class 5 was divided into 10 levels (thus a “decimal” system) but has been 
> expanded to well more than 10 sub levels over the years as techniques and 
> gear have evolved. But that is off topic when dealing with hiking trails. I 
> think for most of what I’d map as a trail we are dealing with classes 1 
> through 3. In Kevin’s example system, the trail with a toddler would be a 1 
> and the other two examples would be either 3 or 4.

There are a couple of moves on the second trail that are a technical
difficulty of about 5.4, but the exposed stuff isn't that difficult
and the technical stuff isn't exposed - so class 4 is about right.
Except that the very existence of class 4 is controversial:
https://www.summitpost.org/class-four-is-a-myth-problems-in-yds/891794

The third trail is similar difficulty to the second in summer. At the
time that the picture was taken, I'd call it an M1 - there's a
different classification for-mixed-ice-and-rock. The guidebook says
that trail is hikable from mid-May to mid-October and we were climbing
in December in that pic. We switched a couple of times between
snowshoes and crampons, and brought out the ice axes at least once or
twice.

On Sat, May 23, 2020 at 9:05 PM Andrew Harvey  wrote:
>  https://youtu.be/VKsD1qBpVYc?t=533 I would tag as 
> sac_scale=demanding_mountain_hiking, my rule of thumb is anything where the 
> average person would need to use their hands to get over an obstacle is 
> demanding_mountain_hiking. This is what the wiki says too "exposed sites may 
> be secured with ropes or chains, possible need to use hands for balance".

That's how I'd scale it if I hadn't been scolded for over-grading it.
(The person who scolded me also argued that "need to use hands to get
ahead" for class 4 was a poor translation, and that it would better
read "need to take full body weight on hands".) I actually simply
accepted the scolding and 'forgot' to retag it, so it's still
demanding_mountain_hiking in OSM. One of the guidebooks reads. "the
rock is sound, holds are plentiful and route-finding is
straightforward. Nevertheless, the exposure is dramatic, and less
confident parties may wish to employ a rope" - which sounds like
textbook class-4 if such a thing exists.
-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[Kevin Kenny]

On Sat, May 23, 2020 at 5:42 PM John Willis via Tagging
 wrote:
>
> =path is such a horrible catch-all tag and one that is extremely entrenched - 
> I am surprised no one has implemented a path=trail subtag, similar to 
> sidewalk, so we can separate all the hiking trails and other “hiking” paths, 
> and then apply different hiking limitations you wouldn’t expect to find on a 
> sidewalk or playground way.
>
> Mixing trails and sidewalks in the path key is as horrible as mixing up 
> runways and train tracks in a “highway=not_car” way.

Yeah. But it's so entrenched that trolltags are probably the only way
out of the mess. And sac_scale is _surely_ not the right trolltag! The
problem with sac_scale is that it's an impossible scale. I'm told that
https://youtu.be/VKsD1qBpVYc?t=533 is still only a 2 out of 6 on that
scale, and that https://www.youtube.com/watch?v=3y5_lbQZJwQ is still
only a 3. Note that one misstep on either of those trails can easily
mean death.

Confusion on what to expect from wilderness trails abounds. Hardly a
year goes by without someone from New York City driving up to do one
of the Catskill or Adirondack trails, expecting something like a
developed trail in a suburban setting, and winding up dead, from
either a fall or hypothermia.

This is a `highway=footway surface=ground`:
https://www.flickr.com/photos/ke9tv/34048181 - a toddler can do it
with ease.

So is this: https://www.flickr.com/photos/65793193@N00/3183604743/ -
requires good physical condition, a head for heights, and some
technical hiking skills. Shorter hikers may be at a disadvantage.

And this: 
http://3.bp.blogspot.com/-oOi7vvpUt0Q/VJnktGwmMDI/BoY/xYpcKlxPPqI/s1600/DSC_3880.JPG
- requires winter mountaineering skills and a modicum of technical
equipment (at least snowshoes or skis, ski poles, crampons, ice axe).



-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Fwd: Section numbers in hiking routes

[Kevin Kenny]

> For now, I just want an alternative for the section/segment/leg numbers or 
> refs that are often in the name tag now.
> They are there to get neat ordered lists in tools and applications. That 
> seems to work fine, but it abuses the name tag, which I am told is a problem 
> for searching routines. A name tag should contain a proper name as found on 
> the street, and nothing else, that's the short version of some very long 
> rants I have encountered...
>
> At the moment, I move comments, descriptions, distance and trail refs to the 
> appropriate tags.
> From-via-to information I copy to the from, via and to tags.
> I just need a nice and intuitive tag to copy the ordering information to.

If the section number is an official identifier, then it's a ref (or
possibly an unsigned_ref). There should be no collision because
nothing keeps a superroute from having a ref of its own.

If you're identifying a section number in order to sort the members of
a superroute, Don't Do That.  Keep the superroute in order.
https://www.openstreetmap.org/relation/919642 remains a worked
example; the sections are listed from south to north. Route relations
are ordered; they're not just buckets of members.

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

Re: [Tagging] track vs footway, cycleway, bridleway or path

[Kevin Kenny]

On Fri, May 22, 2020 at 4:31 AM Mateusz Konieczny via Tagging
 wrote:
> It is extremely rare - if there is single access road to a private residence
> then it is a driveway no matter whatever it is paved asphalt road or
> something that requires tractor to pass.
>
> Maybe it would matter in case where there is one road used as driveway and
> second road that may be used to access property but is unused, possibly due to
> poor state.
>
> But that would because one functions as driveway and one not.
> In case of people using worse-quality road as a driveway
> and not using better quality road as a driveway
> the tagging also should follow function and road used as driveway
> should be tagged as driveway.

The case that I scratch my head over is a road whose primary purpose
is farming or forestry, but that is also the path of access to
someone's cabin. You seem to be saying that the presence of a dwelling
trumps all other uses, but that doesn't make sense to me.  Some of the
cabins on inholdings in the forests around here are accessed by ATV or
snowmobile, depending on the season, because the road has deteriorated
beyond what a typical SUV can handle. (No, they don't get Amazon
deliveries.) I also don't want to say that a logging track is a
residential driveway just because there's one guy with a parcel
somewhere fifteen miles off the highway, when the only other traffic
on the track is International Paper's trucks.

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Section numbers in hiking routes

[Kevin Kenny]

On Sat, May 23, 2020 at 1:46 PM Yves  wrote:
> While the original question was about a good tag to record the section 
> number, whick look like a reference, I would be tempted to answer Jo that to 
> know which country you're in, you should look at Your OSM Database!
> Joke aside, such a cross border route makes a good candidate for a super 
> route.

On a cross-border super-route, the individual route relations could
have name=* in the local language. The super-route can have 'name:en',
'name:fr', 'name:de'¸ etc., and I'm guessing that the governing
authority of the super-route probably has a working language, and
'name=*' on the super-route can use it.

I've used super-routes a few times for more pedestrian reasons. (Pun
intended.)  They work well to organize things.  Often, there's a
natural break into segments, even if the segments are informal. That's
what I did with https://www.openstreetmap.org/relation/919642 - cut
the route at the county lines simply because the tools were struggling
with a route relation having as many segments as it would have had
otherwise.   Increasingly, tools such as Waymarked Trails recognize
super-routes and do the correct hierarchical decomposition.

919642 also provides a worked example for having a route that follows
segments of other routes. In many spots in the US, pride of place for
naming and blazing belongs to the trail that was there first. so
https://www.openstreetmap.org/way/111804369 bears the name, "Devil's
Path", not "Long Path", even though the Long Path is over ten times
its length. Sometimes that goes to absurd lengths: I understand it's
now been adjusted, but for decades,
https://www.openstreetmap.org/way/389226405 was blazed as an approach
trail to the Long Trail, because the Long Trail was the senior trail.
https://www.openstreetmap.org/way/389226405 was blazed with the
red-disc-on-a-white-square of the Ramapo-Dunderberg Trail and not the
vertical-white-bar of the Appalachian Trail for the same reason.
(Today, the latter way simply bears both blazes.) Generally speaking,
the major long trails will be at least marked with their own blaze at
junctions and signposts, but may simply carry the reassurance blazes
of another trail. In the Devil's Path example, at
https://www.nynjtc.org/sites/default/files/u9655/946523_10200476422125507_495296326_n.jpg
you see the aqua disc of the Long Path nailed to the sign as an
afterthought. The red disk of the Devil's Path takes precedence. Along
the trail, rather than at junctions, you see just the red markers. as
at https://www.flickr.com/photos/ke9tv/1427814

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

Re: [Tagging] Feature Proposal - RFC - Recreational route relation roles

[Kevin Kenny]

On Thu, May 21, 2020 at 12:42 AM Andrew Harvey  wrote:
> On Thu, 21 May 2020 at 12:35, Warin <61sundow...@gmail.com> wrote:
>> The exclusion of the black trail as a possible 'excursion' in the main
>> route is a judgment call. I'd be very careful about it.
>>
>> Why is one excluded where the other is not? Is that is going to be
>> difficult to explain in a simple way?
>
> It should depend if it's signposted as part of the route or not, since this 
> tagging only applies to signposted routes. If there is an excursion or 
> alternative route that isn't signposted as part of the route then it 
> shouldn't be included in the relation.

It's still tricky. Around here, few trails are actually signposted;
some don't have a sign anywhere! They're marked with paint blazes in
the woods, guideposts in the fields, and cairns above the tree line.

And it's still possible to waymark a side trail as _associated_ with
the main route. The Appalachian Trail, for instance, is marked with a
2x6 inch vertical white bar. Side trails that 'belong' to it are
marked wtih the same 2x6 inch vertical bar, only in blue. The 'belongs
to' association is a judgment call. I know of only one maintaining
club in my broad area that publishes a list, and that's for their
quirky 'hiked the Long Path from side to side' award:
https://www.greenmountainclub.org/the-long-trail/side-to-side/

The excursion may be marked generically, but still be understood to
'belong to' the trail that it leaves. On many preserves around here
(which use a more sophisticated waymarking system than the simple
paint blazes), side trails to campsites and latrines are marked with
little (~10 cm) marker disks bearing the appropriate icon:
https://www.flickr.com/photos/ke9tv/10282365273

Given the statement of purpose, the locals will know what to do, and
the non-locals will argue here on the tagging list about whether a
'properly' tagged object must follow their cultural assumptions.

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Proposal of new tag for technicality of trails for running

[Kevin Kenny]

On Mon, May 18, 2020 at 10:55 AM Volker Schmidt  wrote:
> There is at least one other scale: cai_scale which is similar in concept to 
> sac_scale,but is applied to hiking relations. It's increasingly used in Italy.

The problem with both of these is that they're _alpinism_ scales, not
_hiking_ scales. They basically lump anything that doesn't require the
equipment and skills for technical climbing into the lowest level or
two.

Of course, the problem with grading a trail is that once you're
reasonably skilled and conditioned, they all start to look 'pretty
easy'. To get a fair assessment, you need to ask a guide, rather than
a hiker or climber, to get a clear idea of what the guide would expect
that clients' reactions would be. That's similar to how a ski resort
would grade green/blue/red/black/double-black (or orange, or
whatever...). The instructors, not the skiers, do the grading, and
they compare their ratings with neighbouring resorts.

One scale that's more addressed at hiking has from time to time
enjoyed some popularity in North America. It's a bit too fine-grained
and subjective for OSM, but it gives a better range for _hiking_
difficulty as opposed to _climbing_ difficulty:

1 = Flat and smooth
2 = Flat terrain but uneven treadway, or slight elevation change
3 = Moderate elevation change, but well graded trail, or flat trail
with very rough treadway
4 = Strenuous climbs, but of moderate duration, or short but steep climbs
5 = Lengthy graded climbs, alternating with easier sections
6 = Extended climbs that may last hours or shorter climbs with difficult footing
7 = Includes rock scrambling that is relatively easy and of short duration
8 = Includes rock scrambling that is somewhat challenging
9 = Rock scrambling that is difficult and extended
10 = Use of hands required for extended periods of climbing, footing
precarious, and leaping may be required — not recommended for those
with fear of heights and not in good physical condition. Shorter
hikers may be at a disadvantage

On the SAC scale, all of these are grade 1 or 2!

(Optional: Corrections for such things as mud, encroaching vegetation,
tricky stream crossings, or the likelihood of beaver activity. I can
think of one trail of about 20 km that's all level 2 on the scale
above - except that halfway through it, there's a 30-m-wide river to
cross!)

Even with the alpinism scales, we lack a way to recognize that the
conditions in many places vary seasonally. With one New York trail
that I have in mind, it's class 3+/4 on the Yosemite scale in the
summer - not for a beginner, nor for someone with no head for heights,
but an experienced hiker will have fun.  In winter (and recall that in
the New York mountains, the four seasons are Winter, June, July and
August), it's an entirely different beast: a relatively easy but still
technical ice or mixed-ice climb, probably about a WI2/MI2 depending
on how much ice there is on a particular day.  When I did it, it was
with a party of hikers of varying gear and technical skill, and those
of us who had 12-point crampons and ice axes wound up top-roping those
who had just trail crampons and ski poles. (Which worked out - there
were only a couple of technical ice pitches and everyone made it up
safely.)

On Mon, May 18, 2020 at 11:05 AM Jonathon Rossi  wrote:
> Obviously there isn't a concrete proposal with any proposed tags, however 
> this sounds very subjective (if not using existing observable tagging) and I 
> think a runner's skill will determine the technicality a lot more than the 
> trail itself.

Of course, as I observed above - which is what motivated the 'ask a
guide' remark. Don't sneer at less-skilled hikers, runners, or riders;
try to come up with some sort of assessment of the skill level
required.

> If a trail has steep uphill and downhill sections, I'd split that section out 
> and tag it with incline=*.

You can do that - but I don't think I've ever tagged `incline=*`. As
far as I can tell, that's what digital elevation models are for!

In any case, what you propose burdens both the mapper and the data
consumer with needing to deal with extraordinarily fine detail -
mapping every rock pitch and mudhole - together with the data consumer
needing to have a complex model for how this impacts difficulty. In a
sparsely-populated and necessarily sparsely-mapped region, it doesn't
provide a way to begin by "filling in the canvas with broad brush
strokes."  At least the ten-point scale above offers some guidance.

I'm now thinking of a time that my daughter and I met some flatlanders
on a trail, who were complaining that the guidebook said it was
'easy'.  It was, by the scale of the local trails.  If the guidebook
had instead called it a level 5 (about a 5 km graded route with maybe
600 m of ascent), they'd have possibly had a better idea of what they
were getting into. (They'd totally not be ready for the level 9/10
that would be encountered on a lot of the trails in that particular
wilderness 

Re: [Tagging] relations & paths

[Kevin Kenny]

On Fri, May 15, 2020 at 9:35 AM s8evq  wrote:
> The network key used on hiking/foot/horse/... relations "(...)indicates the 
> scope of the route." 
> (https://wiki.openstreetmap.org/wiki/Key:network#Bicycle.2C_hiking_and_other_recreational_routes),
>  so international, national, regional or local.

And that's not terribly useful in North America, where we wind up
inventing the classification. Except for the National Scenic Trails,
and various state cycle routes, everything is local. Local clubs often
collaborate on joining their hiking trails into longer routes. We tag
'Long Path' with 'rwn' but there's really no regional network;
https://www.openstreetmap.org/relation/919642 is maintained by
multiple clubs, loosely led by New York-New Jersey Trail conference.

The tagging scheme appears to presume that there is a hierarchical
administration of such things, and all the trails will be designated
by some authority - international, national, regional and local would
correspond to a hierarchy like Interstate/US Route; State Route;
County Route on the roads. But US hiking trails simply don't have such
a thing, so it's a bit of a force-fit. Here, it's all organized
bottom-up.
-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] relations & paths

[Kevin Kenny]

On Fri, May 15, 2020 at 9:22 AM Paul Allen  wrote:
> Are those important in all instances or just the examples you gave?  The
> footpaths and bridleways I deal with have references (in official records, not
> on signages) but are not part of a network.

Sorry, I was unclear. Network is important for road (and some cycle)
routes in the US, because if you're going to do anything more than the
most basic support (if, for instance, you want to render pictorial
signs), you need to know the network of a numbered route.

We hack that for the main renderer by putting a `ref=*` like "CR 103"
on the ways, but that's far from ideal, because different counties use
different symbololgy, and it's not guaranteed that a route maintained
*by* a county is entirely *in* the county.  State-level example: About
half of New York State Route 120A
https://www.openstreetmap.org/relation/407958 is in Connecticut. It's
maintained and signed as a numbered New York highway. It's not the
only one. If you look at the same area on
https://kbk.is-a-geek.net/catskills/test4.html?la=41.0435=-73.6807=15,
you'll see that it's rendered with the shield of a New York route and
not the square of a Connecticut one.

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] relations & paths

[Kevin Kenny]

On Fri, May 15, 2020 at 7:31 AM Paul Allen  wrote:
> I've encountered footpaths and bridleways that include farm service roads as
> part of their route.  So far, I've mapped the footpaths as the bits that 
> aren't
> service roads.  That renders the functionality of the ways but doesn't
> encode in any way that the service road is a public footpath.  I did find
> one example of somebody doing it differently: he mapped a bridleway in
> its entirety, including the bit along a service road, and also mapped
> the service road (which coincided with part of the bridleway).  It
> still rendered the service road as a service road on standard carto but
> using the query tool on the bridleway showed the full extent of the
> bridleway.
>
> Using a relation seems like another way of handling the situation.
> Or maybe I'm misunderstanding...

Using a relation is the PREFERRED way of handling that situation.

I have a strong preference NOT to create two ways for the same
physical object, so where a public footpath is on a road - which
happens a lot around here - I map that segment of the road, map the
off-road segments as footways or paths as appropriate, and use the
route relation.

Thus, Old Piseco Road https://www.openstreetmap.org/way/20092775 is
itself tagged '`highway=tertiary` (and has some other rubbish from
TIGER). It's a member of the road route 'Hamilton County Road #24',
and a member of the foot route 'Northville-Placid Trail.'

I don't want to have to dredge up the route information (what does the
waymark look like, etc.) from an enigmatic and tightly encoded `ref=*`
on a way. The relation can have ref, network (this is important),
name, symbol, whatever is needed.  (It should NOT have physical
properties of the route such as `surface` or `smoothness`: those go on
the ways.)  Otherwise, I have a problem with concurrences like Old
Piseco Road. As a trail, it's part of a 'rwn' network. As a road
route, it's part of the network named 'US:NY:Hamilton'. What do I put
in `network=*` if I map it just on a way?

Island View Road (https://www.openstreetmap.org/way/5595536) is part
of multiple relations: Mohawk-Hudson Bike-Hike trail as a foot route,
Mohawk-Hudson Bike-Hike Trail as a cycle route (Note that the two are
different because the cycle route doesn't use the sidewalk in urban
neighbourhoods), Erie Canalway Trail (an unfinished relation, and the
mappers that maintain it have yet to make the split between road and
sidewalk), and the (unmapped as yet) Empire State Trail). (Memo to
self: Downgrade it: It's clearly `residential` and not `tertiary`.)

The Bear Mountain Bridge https://www.openstreetmap.org/way/84620188
hosts two road routes (US 6 and US 202), a cycle route (NY Bicycle
Route 9), and a major foot route (the Appalachian Trail). Obviously,
there's no sensible way to represent all that without the relations.

Moreover, a route relation remains a single object even if the way is
split.  When I split https://www.openstreetmap.org/way/507687342 to
add the bridge, I didn't need to worry about the relations except to
make sure that all three parts stayed in them. And a route relation
can easily be overlaid on existing ways. When they posted orange
markers on https://www.openstreetmap.org/way/509364137, I simply took
the formerly-unmarked trail (which wasn't part of any relation, not
being marked!) and added it to the route relation that I created for
it.

As a data consumer, I have a strong preference to have only one way of
looking for something.  Looking for route information on ways, and
assembling ways that belong to the same route, is tricky. (More
important, it's brittle, and there are a lot of things to go wrong if
the data aren't perfect.) Obviously, it wouldn't be tricky at all if
the route were a single segment, like
https://www.openstreetmap.org/relation/3122185 - but why add a corner
case rather than treating all routes uniformly? So I'm of the opinion,
"if it would need a route relation if something else were concurrent,
or if it were split, then it needs a route relation."

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] relations & paths

[Kevin Kenny]

On Tue, May 12, 2020 at 1:03 PM Peter Elderson  wrote:
> My view is that a route should have an indication on the ground. A sign, a 
> trailhead, something. No verifiable indication whatsoever, then it's not a 
> route.
>
> The length or the number of ways in the route does not make a difference to 
> me.

That's indeed the meaning of 'waymarked' in Waymarked Trails.  If a
trail has a distinguishable waymark (signage, blaze, ducks,
guideposts, whatever is used in a given locale) it gets a relation. No
waymark, it doesn't. Length has nothing to do with it.

I'll bend the rules slightly for named routes that are listed in
multiple guidebooks, because otherwise some major trails would be
lost. The Benton MacKaye Trail is not waymarked in certain wilderness
areas, but is described in numerous guides, named, and maintained to
the extent of occasionally cutting brush, clearing blowdown, and
repairing water bars on the treadway. In general, wilderness trails,
even if nominally waymarked, require good navigational skills, since
trail visibility may be very poor indeed. The more remote trails also
don't have a lot of vegetation control or get a lot of traffic. I've
occasionally gone an entire day without meeting another party -
although that was often 20-30 km from anywhere you can park a car,
which filters out a lot of hikers.

In the US, walking and MTB trails are likely to have only a splash of
paint on trees at intervals.  The blue-green paint blazes seen in
https://www.flickr.com/photos/ke9tv/14018094576 are pretty typical.
The trails that they mark range in length from a few hundred metres
(short access trails leading to parking lots, campsites, views,
whatever) to a few thousand km (the National Scenic Trails). In remote
areas, trails might go a few hundred metres between even paint blazes;
they don't have a lot of reassurance markings. More popular trails, or
ones nearer the 'front country' are likely to have marks frequent
enough that you're always in sight of one.

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

[Kevin Kenny]

On Tue, May 12, 2020 at 8:59 AM stevea  wrote:

> > We in the Massachusetts local community want to have admin_level 6
> > relations for these boundaries, and I personally consider deleting them
> > to be vandalism.
>
> Then let's hear from them and their rather precisely-described to-become 
> arguments, rather than you and your beliefs (nor me and my repetitions of 
> these).  Saying that a dozen of you believe 2 + 2 = 5 (especially as 11 other 
> voices aren't present) doesn't make it so.  Cogent, scholarly, well-presented 
> arguments that address the salient political and legal topics described (in 
> the wiki page, where this more properly belongs, though I'm glad it's getting 
> a hopefully final gasp of exposure here) might be able to describe why 2 + 2 
> might look like 5, in a certain way, in Connecticut, because of x, y and z.  
> But nobody is hearing that and nobody but user:Mashin is saying so.  (At 
> least in wiki and talk-us.  Slack?  That's proprietary.  I avoid secret-sauce 
> walkie-talkies in an open data project, but that's me.  I do hear that people 
> use it to communicate, I wouldn't know what's on it).

I'm surprised at this message. My one line summary of this reply:
'Asked and answered.'

You've heard in some detail from at least me - in the last few days -
regarding counties in Massachusetts and boroughs in New York. (I'm not
speaking to Connecticut or Rhode Island, since I don't understand
their political systems as well.) For both the Massachusetts and New
York cases, while the (non-)counties have ceded most legislative and
executive function to a higher body, they do retain some effective
local government. In New York City, the county courts still exist -
the Great Consolidation had no effect on the judicial branch. The
county courts in New York City are paid by the state, but that's true
of all the other counties as well. In Massachusetts, counties that
have been 'dissolved' continue to elect their own sheriffs and DA's -
who are paid by the state, but whose jurisdiction extends to the
county, as well as retaining their county courts (also paid by the
state).

Therefore, for the Massachusetts situation, you're saying 'lets hear
the arguments' for arguments that you have not answered in public with
more than an enigmatic, 'and so it goes.' Or to some extent, you're
adding a new set of requirements, a specific quantum of 'home rule' -
just how much, I don't grasp - that is required for
`boundary=administrative`.

Should `boundary=administrative` not exist at all in states whose
constitutions have not been amended since 1907 to address _Hunter v
City of Pittsburgh_? They may have functioning counties and cities,
but municipal powers can be overruled by the higher legislature with
the stroke of a pen.  It would be rather an extreme position, although
I suppose a consistent one, to say that if the constitution of the
higher body doesn't guarantee home rule to the lower, that the lower
doesn't exist; but that would have the effect of erasing county lines
in all but a handful of the states.

Does the subordinate body need to support all three branches of
government? Does having its own judiciary, or its own elected justice
department under the executive, suffice? Or must it have the power to
legislate? Its own executive?

What powers must the subordinate body enjoy?
- Structural - Does the subordinate body have the ability to choose
its form of government (within constitutional bounds), adopt and amend
a charter?
- Functional - Does the subordinate body have power to exercise local
self-government - and is that power plenary, or limited to enumerated
matters?
- Fiscal - Does the subordinate unit have the power to determine its
revenue sources, tax, spend, and borrow?
- Personnel - Does the subordinate unit determine the employment rules
and compensation of its employees? May it enter into collective
bargaining agreements?

Is it relevant whether a local government actually exercises all the
discretionary authority with which it is endowed?  (I bring to mind
the extreme case of Sherrill, New York - which functions as a Village,
with most services provided by the Town, but is actually a City, with
a city charter, and could vote at any time to constitute a city
government like any other.)

You've gone beyond the (already controversial) point that 'a
boundary=administrative requires home rule' into a very fine-grained
debate over 'how much home rule is enough'.

Moreover, you're introducing yet more complexity for data consumers.
One key point for the administrative-level hierarchy is that it
provides a fairly simple way to do a consistent rendering among
different jurisdictions. A renderer can look at just the member ways
of a boundary - which are themselves tagged boundary=administrative
with the coarsest relevant admin_level. Unless it wishes to do
something like shade the regions, it may remain entirely ignorant of
the relations. This structure gives the benefit that a state 

Re: [Tagging] relations & paths

[Kevin Kenny]

Waymarked Trails associates waymarks only with routes, and assumes
that any waymarked route, from local to international, will have a
route relation describing it.

Is there a reason that you see route relations for shorter routes as
being 'wrong'?

On Mon, May 11, 2020 at 10:17 PM brad  wrote:
>
> I see a lot of relations, type:route, which are only short
> trails/paths.   This is wrong isn't it?   Do you suppose that folks are
> doing this to get better rendering?
> Brad
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



-- 
73 de ke9tv/2, Kevin

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

[Tagging] Voting procedures (Was: Re: Tag:amenity=motorcycle_taxi not approved)

[Kevin Kenny]

On Fri, May 8, 2020 at 9:06 AM Phake Nick  wrote:
> Given the proportion of opposing comment being raised, I would say "more than 
> what have been discussed", as barely anyone raised the point during the 
> discussion. The only two remotely relevant mentions about it during the 
> discussion process was 1. one user who think there should be a new parents 
> tag that cover both regular taxi and motorcycle taxi, and 2. another who 
> incorrectly assuned "motorcycle taxi" is a combination of two different 
> features just because the term come with a space. That clearly indicate 
> discussion was not sufficient and that the proposal should restart the 
> discussion process.


Our 'yes/no' voting on proposals leads to a pathological phenomenon
that I've seen happen several times.

Someone wants to map a particular feature, and floats an idea for a
tag 'A' on the list.

Several other people counter-propose incompatible tags 'B', 'C', 'D' -
each with its own advantages and disadvantages.

None of these tags garners a clear majority of commenters.

Either the proponent abandons the idea, or else falls back on 'any
tags you like', or actually bites the bullet and makes a formal
proposal, calling the vote.

In the last case, which is already uncommon, the vote fails, because,
if for instance, 'B' becomes the final proposal, all of the supporters
of 'A', 'C', 'D' vote against the proposal.

Any of the other schemes would also have been rejected.

Do we need to refine the system to something like: supermajority that
the feature should be mapped, and preference voting for how to map it?

I will concede that I've never called for a vote on any proposal,
because after testing the waters on this list, I've taken the cowardly
option of falling back to 'any tags you like'. Even though there
appears to be a consensus (recall that consensus is not unanimity!)
that things like 'access=permit' or 'protection_class=*' are small
steps in the right direction, there was clearly enough controversy
over the details that it became obvious to me that a vote on either
proposal would fail.

In many cases the failures truly are ones of metaphysical
understanding. For a taxi service, is the vehicle (car, motorcycle,
pedicab, rickshaw) the essence, and 'for hire' a mere accident, or is
'passenger service for hire' the essence, and the choice of vehicle
the accident? In typical tagging discussions like this one, I often
see several other attributes being proposed as essential, and the
attempt to fit the entire world into a taxonomic tree fails because
nobody can agree which attributes are generic and which are specific.
That inevitably comes of using Platonic tagging to approximate an
Aristotelian understanding of the objects being tagged. Tagging will
always be approximate. The map is not the territory.

I have little sympathy for those who cannot be troubled to comment on
a proposal in progress and then pop up with new objections after the
vote is called. I consider that to be obstructionist behaviour. While
it does not necessarily negate the technical value of the objection,
it is annoying in the extreme. It can also serve as a presumptive (not
determinative!) measure of the technical merit; people with a deep
technical understanding of the issue tend to involve themselves in the
process in a timely manner.
-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] RFC ele:regional

[Kevin Kenny]

My thoughts - trying to be brief, I started writing a much longer
message, but it got disorganized fast:

1. ele=* should always be orthometric.

2. Datum may be supplied with ele:datum=*, defaulting to
'ele:datum=unknown'. Within the regions of the Earth where a datum is
valid, all the datums in common use agree to within a couple of metres
of each other. (Obviously, you wouldn't want to try to extrapolate
NAVD88 onto a different continent!) Accuracy at that level is good
enough for virtually all land and aeronautical applications. How many
elevations in OSM have been determined with precise division of
levels, or with a four-hour integration time on a survey-grade GNSS
station?

3. A key like ele:tidal=* should be considered for nautical uses,
because water depths and bridge heights in tidal regions are measured
relative to tidal elevations.

4. Tidal datum may be supplied with ele:tidal:datum=*. The values for
this key may the local tidal measurements of MLLW, MLW, LMSL, DTL,
MTL, MHW, LWD, MHHW. Default in North America should likely be
'ele:tidal:datum=mllw' because that's how bathymetry is tabulated here
- referenced to local Mean Lower Low Water. Other locales will likely
have other conventions.

Rationale for separate keys: Orthometric and tidal elevations may be
some metres apart, and there would likely be considerable confusion if
the two were to use the same key. (Consider the case of the Bay of
Fundy, where the tidal range is 16 m. Geoid height and MLLW will be
eight metres apart - try to compare 'ele:*' values!

Bridge heights and water depths are not elevations, but elevation
differences, and need further discussion. (How best to call out water
depths on inland waterways, or bridge heights above them?) The Wiki
doesn't appear yet to have a lot about bathymetry.

5. Height-above-ellipsoid COULD be tabulated as ele:ellipsoidal=*
(with datum required), I suppose - but I agree with Greg Troxel that
ellipsoidal elevation has no place in OSM. It's an intermediate
calculation, which we wouldn't be discussing on the 'tagging' list at
all if it were not for the fact that the Android location API
unfortunately exposes it. It's very often tens of metres off from the
actual surface of the sea. It cannot be displayed as anything that an
ordinary user would recognize as an 'elevation' without further
computation; data consumers ought not to be required to resort to such
computations merely to produce a map for popular use, as opposed to a
navigational chart. Since API's like the one to 'vdatum' generally
allow conversion between two arbitrarily chosen reference frames, it's
no more work for the programmer of a data consumer that needs precise
data to convert from the supplied datim than from the ellipsoid.

Those wishing to determine whether a building site is above 19-year
highest high water should really consult a competent engineer, and not
OSM. (Disclaimer: I am an engineer. In a different specialty entirely.
Choice of building site in a tidal region is entirely outside my
professional competence, and it would be unethical and illegal for me
to consult on such a project.)

Those piloting a vessel had better have charts from a competent
authority. For commercial vessels, there are legal chart carriage
requirements that OSM will likely never satisfy.

"Leadsman!" "And a quarter five, over a clay bottom!"

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

Re: [Tagging] RFC ele:regional

[Kevin Kenny]

On Mon, May 4, 2020 at 9:16 AM Greg Troxel  wrote:
> It is a good guess that signs you see are in your
> national vertical datum.  But some (most?) places have multiple datums,
> and it seems very likely that values people have known have been copied
> forward on signs for who knows how long, and there's no way to tell
> which one is meant.This is true on the US for things like mountains
> and "highest point on the masschusetts turnpike" signs -- which lacks a
> datum.

They're also likely obtained by looking at contour lines on a topo,
and are likely to be 10 m away from the actual value, whatever datum
is supposedly in use. (Or they were simply obtained by division of
levels, long before satellite geodesy).  In that case, the choice of
datum is of no significance at all. (But using the ellipsoid is still
Just Plain Wrong.)

I'd wager that virtually all `ele=*` values in OSM are tabulated only
to that level of accuracy. and as long as we say that _some_ modern
vertical datum (say, NAVD 29 or newer) is used rather than the
ellipsoid, we should be Just Fine.

Many peaks in the lists near me (such as Adirondack 46, Catskill 3500)
have their elevations quoted as the highest closed contour line on the
old USGS topos. Since the summits were used only as vertical controls,
their altitudes weren't measured that precisely. Many were used as
horizontal controls, and some of the trig points there are used as
part of a network that measures continental drift, since we have 150
years of data. The state survey of the 1870s was surprisingly good,
and the placement of first-order controls included astrometric
measurement of the deflection of the vertical.

Obligatory Colvin drawing from the state survey:
https://upload.wikimedia.org/wikipedia/commons/9/93/Division_of_Levels_-_Measurement_of_Whiteface_Mountain.jpg
Obligatory photo of Kevin's boots at a trig point
https://flickr.com/photos/ke9tv/9514568039

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] RFC ele:regional

[Kevin Kenny]

On Mon, May 4, 2020 at 8:53 AM Greg Troxel  wrote:
> I'll also say that this alternate datum notion is irregular, in that we
> expect horizontal positions to be transformed from national horizontal
> datums to WGS84, and that putting in a tag to say that coordinates were
> in some other datum would be, I think, considered madness.  Instead, we
> expect people to transform any such data to WGS84.  (And we realize that
> meter level shifts are not that important usually, because measurements
> and source data is rarely that good.)

To muddy the waters further, while WGS84 included a geoid model,
virtually nobody uses it. It's been deprecated for over 20 years.

Elevations quoted as 'WGS84 elevation' (as opposed to
height-above-ellipsoid) are virtually always relative to EGM96,
Generally speaking, published topographic maps will cite separately
which horizontal and vertical datums they use. (Newer stuff might use
EGM 08, but the two agree to less than a meter almost everywhere.

Elevation as height-above-ellipsoid, unless you're using it in the
intermediate results of a GPS calculation, is nonsensical.

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Kevin Kenny]

On Mon, Apr 6, 2020 at 6:37 AM Andrew Davidson  wrote:
>
> On 6/4/20 9:23 am, Joseph Eisenberg wrote:
> > The only thing that the proposal page still needs is a couple more
> > detailed definitions for some of the tags.
>
> Maybe not. A quick read finds this statement:
>
> protect_class=2 will be tagged as boundary=national_park (de facto)
>
> This is a problem because boundary=national_park already exists as a
> generic tag for a conservation area. A quick survey of all of the
> existing boundary=national_park with a wikidata link finds the following
> range of IUCN Protected Area Categories:
>
> Class  Count
> IA   95
> IB   70
> II  848
> III  74
> IV  277
> V   234
> VI  159
> Total  1757
>
> So less than 50% of "National Parks" are Cat II.
>
> I would suggest adding protection_class=national_park and dropping the
> suggestion of using boundary=national_park.

[A side point:]
While I regard IUCN as a fine authority for the definition of the
protection categories, I have found it to be considerably less useful
for the application of the definition. For instance, in my home state
of New York, all Wilderness Areas are tagged as category VI on IUCN's
site. This is surely incorrect; the language that establishes them is
nearly identical to the parallel language in the (US Federal)
Wilderness Act. Motorized travel, harvesting of trees, bicycles, the
erection of permanent structures (there is an exemption for certain
improvements to trails and campsites to protect the rest of the area
from hikers), all are strictly forbidden. Areas protected by NGO's
(e.g., Nature Conservancy, Open Space Institute, Ducks Unlimited) and
land trusts are not listed at all.

[A stronger point:]
I agree with you that boundary=national_park presents us with an
awkward problem: what does it mean? It's a tag that's been around for
a long time, and there are over a thousand objects that bear it. If it
simply means that an area has the phrase, "National Park" (in the
local language) somewhere in its name, it's pretty redundant, and
fails to cover features that are national parks in structure and
function but named differently. If it simply means 'category II
protected area,' then it's surely redundant, but furthermore, half of
the ones we have are mistagged. Perhaps most awkwardly, once we've
chosen to use the tag, 'boundary=national_park', then
'boundary=protected_area' is no longer available to us.

Can we work around the problem simply by allowing 'protection_class'
to apply to 'boundary=national_park' as well as
'boundary=protected_area' and asserting that the default value of
'protection_class' for 'national_park' shall be assumed to be 2
(surely the plurality, if not the majority, of the areas listed
above)?  That could also allow us to choose, for example, 1b for a
national park that is all wilderness, or 6 for one of the porous
national parks in the UK, where most of the land is in private hands
and people continue to live and work inside a park's borders (albeit
under severe constraints as to the uses to which the land may be put).
We could also then state that 'boundary=national_park' should be used
in preference to 'boundary=protected_area' where it applies.

That would also allow us to address Joseph Eisenberg's objection (in
the talk page on the WIki) that the proposal violates the 'one object,
one tag' principle. We could retain established tagging for such
things as 'leisure=nature_reserve' or 'landuse=recreation_ground'
while still indicating that the features enjoy a particular legal
protection, by augmenting the tagging with a 'protection_class'.
'Boundary=protected_area' could then be reserved for the features for
which no existing tagging applies. The inapplicability can come about
for numerous reasons. For instance, 'protected_area' may become the
unifying tag because the protection status is the only salient
feature, or because there is no existing tagging that applies well, or
because the area admits of mixed land uses that share a common
boundary and name.


-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Kevin Kenny]

Does the current version look any better?  Obviously, once we're
seriously stitching things into the Wiki, we'll need to make
individual pages with titles like 'Key:protection_class=recreation',
but of course it's easier to have it all in one place for now.


On Sun, Apr 5, 2020 at 7:24 PM Joseph Eisenberg
 wrote:
>
> The only thing that the proposal page still needs is a couple more
> detailed definitions for some of the tags.
>
> The ones based on IUCN levels already have a fairly good description.
>
> But protection_class=recreation should be clarified - what exactly is
> protected here, and what sort of recreation are we talking about? It
> should be clear how this is different than a leisure=recreation_ground
> or sports_centre or =park.
>
> The tags protection_class=water, protection_class=culture,  and
> protection_class=hazard might need slightly improved definitions too.
>
> Besides that, everything looks pretty good.
>
> -- Joseph Eisenberg
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Kevin Kenny]

I suppose, now.  It seems to be gaining some traction, at long last.
When I floated it, it was not nearly as popular, largely because of
the way it tied into the flood of words exchanged between Adamant(some
digits) and stevea in various media. The discussion at the time shed
more heat than light.

I'm a little intimidated by the process, particularly the
administration of the vote (Who's a qualified elector? Who can serve
as scrutineer?) and the need to stitch the result into the Wiki.  Some
of what's needed for the latter seems to require knowledge of the
Wiki's templating conventions, which appear to be obscurely documented
at best, and with which I'm unfamiliar. (Also, it brings up unpleasant
memories. I've burnt my fingers on Wikipedia in the past.)

I've been hoping against hope that someone will help me with the
mechanics. I'm considerably better at data modeling than I am at
Wiki-gnoming!

On Sun, Apr 5, 2020 at 12:39 AM Joseph Eisenberg
 wrote:
>
> Kevin,
>
> Would you have time to move this proposal forward?
>
> I've been looking at the protected_area classes, and there are several
> that are confusing and overlap with other features, especially
> protected_class = 7, 19, 21, 29, 97, 98, 99.
>
> And several are duplicates of more common tags:
>
> boundary=national_park (de facto) for protect_class=2
>
> boundary=aboriginal_lands (approved) for protect_class=24
>
> landuse=military + military= for protect_class=25
>
> I like the way your proposal has suggested changing these all to more
> memorable and intelligible words as values of "protection_class=",
> like "protection_class=recreation" instead of "21"
>
> -- Joseph Eisenberg
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Kevin Kenny]

On Sat, Apr 4, 2020 at 5:28 AM Florimond Berthoux
 wrote:
> bicycle=yes is an access tag it says only that cyclist has a legal right to 
> ride there.
> «Key:bicycle  Legal restriction for bicycles. » 
> https://wiki.openstreetmap.org/wiki/Key:bicycle
> It doesn't say anything about it difficulties, that the job of mtb:scale key.

The key issue with that approach: how does a mapper who isn't expert
enough to grade accurately the difficulty of a MTB trail, but can
clearly see, 'a road bike wouldn't work here', tag the thing
appropriately?  Simple 'highway=path foot=yes bicycle=yes' invites
routing disasters. I can, and do, add 'surface=ground
smoothness=horrible', but is that enough? How many tags must a router
take into consideration before deciding that a cycleway is actually
usable?

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Kevin Kenny]

On Thu, Apr 2, 2020 at 3:12 PM brad  wrote:
> The trouble with this is that very few trails are 'designated' for
> riding a bicycle.  They are legal for bikes, hikers, and horses.
> Cycleway is a lousy tag for a multiuse trail.  Fortunately most of the
> tagers where I ride, travel, and contribute follow my philosophy.
> The proper tag is highway=path, foot=yes, horse=yes, bike=yes.

Very few trails near me allow both bicycles and horses.  The land
managers seem to believe that it's safer to allow one or the other.
The equestrians appear to appreciate it, since horses are virtually
all used to encountering hikers but many may spook at a bicycle.


-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Kevin Kenny]

On Thu, Apr 2, 2020 at 11:54 AM Greg Troxel  wrote:
> However, around me there is a convention that any
> dirt/unimproved/in-the-woods sort of thing is path, and
> in-town/paved/manicured sorts of are highway=footway.

I started tagging trails as 'path' - and found that the locals
immediately changed them to 'footway' or 'cycleway' except for shared
paths. 'surface' and 'smoothness' are better ways to disambiguate
whether we're talking about a rocky singletrack or an asphalt
rail-trail.

> I am mildly curious how many places there are in mountain bike trails
> that prohibit hikers.   Around me, every trail  that is open at all is
> open to hiking, and some are open to bicycles and horses, some aren't.
> (Additionally some are closed to bicyles and horses when wet.)

As I said in my earlier post, there are some around here that are
specifically posted for MTB use. I don't think hiking on them is
exactly prohibited, but it's surely discouraged. Obviously, you won't
get a ticket for hiking out with a disabled bike or whatever, but you
really shouldn't plan to go hiking there. A number of those trails are
designated for x-c ski in the winter, and hiking on ski tracks would
be extremely inconsiderate, whether it's lawful or not.
-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Kevin Kenny]

On Thu, Apr 2, 2020 at 5:12 AM Volker Schmidt  wrote:
>
> If a highway is mtb:scale=2 it is definitely not a cycleway. It is a 
> highway=path with mtb:scale=2
> If this were to encounter a "cycleway" with mtb:scale=2 , I would consider 
> this an error and retag it as highway=path without hesitation.
>
> I agree, that this is not explicitly stated in the bicycle wiki page, and 
> should be added there, but I would assume that this is the common 
> understanding. Anything else would cause major problems with the huge stock 
> of existing highway=cycleway in OSM that have no mtb:scale tag. Routers for 
> non-MTB bicycles would all need to change and evaluate the mtb:scale tag.
>
> There is already a similar problem with the OpenCycleMap rendering in the 
> sense that it renders a dedicated cycle path in the same way as a path with 
> bicycle=yes. This has the effect that many MTB friends have added bicycle=yes 
> to "normal" hiking paths to make them appear as MTB friendly on the map, but 
> also with the problem that when I look at that map I wrongly see a cycle 
> paths where I would never be able to pass with my loaded touring bike.
>
> Please keep paths that can only be used by MTB clearly different from 
> cycleways that can be used non-MTB bicycles.

A key issue is that mtb:scale can't be the only indication. Otherwise,
we're falling into a trap - which has been a common trap in the past.
It's a trolltag https://wiki.openstreetmap.org/wiki/Trolltag - a
second tag that negates or massively changes the meaning of another
tag. "This isn't what you were expecting of a highway=cycleway: it's a
wilderness trail for highly skilled and adventurous MTB riders!"

Just as bad, though, is the fact that tagging with an mtb:scale
requires technical knowledge of that specific sport. How do I tag,
"this trail is posted for MTB use, and would be impassable to a road
bike?"

I pretty routinely map trails in wild forest areas.  Some of these (a
minority, in the places I go) allow MTB riding; others allow horses, a
very few allow snowmobiles; most are foot- (snowshoe-, ski-) only. I'm
a reasonably skilled hiker (calibration: I've done at least one 200+
km solo trip through the Adirondack Mountains in New York, sometimes
pushing as far as 30 km from the nearest highway).  If I'm using a
grading system that I understand, I can come up with a pretty usable
rating for a hiking trail. I'm not a mountain bike rider. If I were to
assign a definitive scale, I'd get it wrong and possibly put riders at
risk. All I know is that these trails are full of rocks and roots and
not for a road bike.  I don't think there's a combination of tags that
lets me map what I know (bikes lawful, impassable to a road bike)
without needing detailed knowledge that I don't have.

We do indeed have back-country trails around here that are reserved
for cycling - not recommended (or off limits) for hiking.
https://www.mtbproject.com/trail/7017547/elm-ridge-loop is an example
- it's an area that has about 40 km of singletrack reserved for MTB in
the summer and x-c ski in the winter, not in a purpose-built MTB park,
but in a Wild Forest area. I don't map those trails. As I said, I'm
not an MTB rider, and there are places I like better in the winter.

We also, of course, have multilple-use trails, and I've mapped a few
of those - and probably messed up the cycling stuff badly. At least
I've tagged 'smoothness' values in the range of 'very_bad' to
'impassable' on the shared paths. Even looking at that scale on the
wiki, though, I ask things like: what's a 'trekking bike'? Something a
US cyclist would call a 'hybrid' or a 'gravel grinder'? This general
category: 
http://www.cyclingabout.com/wp-content/uploads/2014/01/wpid-Photo-29-Jan-2014-1144-am.jpg
?

Straying from the topic:

Assuming that anyone interested in tagging a feature will have
detailed knowledge of one particular use is a recurring problem. We
have the same issue with whitewater. I've paddled some whitewater, but
I'm surely not competent to grade a stretch of rapids. OSM doesn't
appear to have sound tagging for "there are rapids in the river here"
that would allow mapping by someone who isn't a canoeist or kayaker.

And don't even get me started on sac_scale, where the higher grades
are technical mountaineering, and no longer hiking - at least as I
understand the scale. My understanding is that the Swiss grade 3 is
roughly comparable to French grade 3, or UK 'moderate severe' - which
corresponds to about 5.5 on the Yosemite scale and is something that I
surely wouldn't do without a rope! Those who are familiar with the
scale tell met that this lady is on a Grade 2 trail:
http://www.flickr.com/photos/65793193@N00/3072631007/
https://www.flickr.com/photos/65793193@N00/3183604743/
https://www.flickr.com/photos/65793193@N00/3183606625/
http://www.flickr.com/photos/65793193@N00/3183604309/ On the Yosemite
scale, it's pretty much a Class 3+/4. It's hikable, indeed, it's
blazed as a hiking trail. 

Re: [Tagging] Updating definition and description of place=square

[Kevin Kenny]

On Mon, Mar 30, 2020 at 4:09 AM Martin Koppenhoefer
 wrote:
> The thing is that squares often also serve as addresses and can be somehow 
> seen very similar to streets, so the same as you can live in a street 
> (meaning you live in a house on this street), you could also live on a square 
> (a house bordering this square). At least it works like this in some 
> languages I am aware of.

That's at least an explanation, though, for why it is that squares are
also micro-neighbourhoods, in both New England and old England.  A
square in common speech often encompasses the buildings that front on
it.

It can be in some cases that urban redevelopment has caused the square
to vanish while the name lives on, or that a developer has chosen
'Square' as the name of something else. (There's a strip mall near me
that used to be called St. James's Square.) That, of course, is no
longer a square, any more than Billingsgate is a gate.(*)

(*) Yes, historically, it was the water gate where the Thames left the
City, but that fortification is long gone, and even the fish market
that led to 'billingsgate' as a word for foul language has moved away,
and the word itself faded into obscurity. But Billingsgate remains as
a Ward of the City.

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Updating definition and description of place=square

[Kevin Kenny]

Oh, just another random observation: extending the notion of 'square' to
the buildings that front upon it is not limited to New England. Moreover,
cursed Albion also has 'town squares' that are green space.

One example: Berkeley Square in London.  In form, it's a public garden, but
even the English designate it a town square. As I understand it, an
Englishman would not raise eyebrows at a sentence: "Winston Churchill, as a
child, lived in Berkeley Square.  The Churchills' house, № 48, is the one
entirely residential building remaining there; the rest of the buildings
are all offices of financial concerns, much like the rest of Mayfair." The
only thing there that would sound odd to American ears is that the English
speak of living 'in' a street, while the Americans speak of living 'on' a
street.


On Sun, Mar 29, 2020 at 6:17 PM Volker Schmidt  wrote:

>
>
>
>
> From these 2 examples how squares (I keep using this word although I am
>> not sure it actually applies) are classified (often in names), which is the
>> approach you had thought about?
>>
>
> I thought maybe the bast way to go ahead is to reverse our sequence:
>
> 1) collect a good number of examples of potential squares in different
> countries (could be done in the discussion page of the Wiki's "square"
> page) and for each one let's have:
>
>- location (item in OSM or at least coordinates)
>- reference (e.g. Wikipedia)
>- type of square in in the local language (possibly with an
>explanation in English what that type means)
>- name (and translation to English if the name can be translated)
>- foto
>- description
>- any annotation you feel useful
>
> 2) once completed we look at the collection and try to see whether we need
> a) a new tag in addition to place=square
> or
> b) we can tag all examples with place=square and the addition of *existing
> *specifyeing keys
> or
> c) we can tag all examples with place=square but with the addition of new
> square type keys
>
> Note that this collection will be useful in any case for illustrating the
> wiki, independently of the approach.
>
> *Here is an example:*
>
>
>- location (item in OSM or at least coordinates):
>
> https://www.openstreetmap.org/relation/6029646
> reference:
> https://en.wikipedia.org/wiki/Ludwigskirche#Ludwigsplatz
>
>- type of square in in the local language (possibly with an
>explanation in English what that type means):
>
> Stadtplatz (historisch), (historical) town square
>
>- name (and translation to English if the name can be translated)
>
> Ludwigsplatz - Ludwig's square (named after the protestant church on the
> square, which in turn is named after Ludwig, count of Nassau-Sarbruecken
> )
> images:
> https://upload.wikimedia.org/wikipedia/commons/d/dd/Saarbr%C3%BCcken%2C_die_H%C3%A4user_Am_Ludwigsplatz_14-14a.jpg
>
> https://www.saarland.de/bilder/res_stk/Panorama_SB-Ludwigsplatz_rdax_800x200.jpg4
>
>- description
>
> originally designed as the centre of the town in the 18 century, today
> used partially for a periodic open-air market, partially as pedestrian
> area, some large trees, the residential streets on three sides and the
> baroque palaces are part of the architectonic ensemble
>
>- any annotation you feel useful
>
> at present not tagged as place=square, but I would tag it as such
>
> Volker
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Updating definition and description of place=square

[Kevin Kenny]

So is the key difference between a town square and a village green(*)
the fact that the square is usually paved?

(*) No, I don't abuse 'village green' for 'any green space in a
village'. A lot of the older villages in the eastern US are laid out
roughly on the plan of English villages,  with a green in the center.
The green will typically be surrounded by such buildings as the
school, a church, a post office, a government center, an inn, perhaps
a few shops or private residences.
https://en.wikipedia.org/wiki/Norwich,_Vermont#/media/File:Norwich-VT-Winter-Panorama.jpg
is typical.


By the way, New York City has many squares; among others, the
architects of the grid system planned one for each point where
Broadway crosses an avenue. Verdi Square/Sherman Square, Lincoln
Center, Dante Park, Columbus Circle, Times Square, Herald Square,
Madison Square, Union Square, Washington Square, Sheridan Square,
Tompkins Square, Astor Place/Cooper Square, City Hall Park, Zuccotti
Park, and Bowling Green all come to mind. Some of these are better
modeled as very small `leisure=park`, but most have the property of
being public open spaces where major urban roads converge, that
function as urban gathering places. For instance, is
https://i.pinimg.com/originals/46/ac/ae/46acaefc5e243415deb7badb29b4113b.jpg
a square ? What about
https://en.wikipedia.org/wiki/Union_Square,_Manhattan#/media/File:1_new_york_city_union_square_2010.JPG
?  
https://en.wikipedia.org/wiki/Columbus_Circle#/media/File:ColumbusCirclefromTimeWarnerCenterNYC20050807.jpg
?

Let's not try to bend over backward to make sure that only European
squares qualify!

On Sun, Mar 29, 2020 at 3:10 PM Martin Koppenhoefer
 wrote:
>
>
>
> sent from a phone
>
> On 29. Mar 2020, at 18:24, Greg Troxel  wrote:
>
> Really, it seems like
> you are trying to shoehorn european definitions into US naming when it
> is just not the way it is.
>
>
>
> Frankly, I am not really familiar with the situation in North America 
> (besides some lessons about North American urbanism I have heard 20 years 
> ago). I am aware there are some developments that imitate 19th century 
> architecture, so even if many or most of the traditional city centers have 
> been razed in the sixties, I would still expect to find at least some squares 
> in north america.
>
> If you have a look at the wikipedia article on Times Square, it also mentions 
> its nature as a town square: “ Times Square functions as a town square”
>
> https://en.m.wikipedia.org/wiki/Times_Square
> It is also a model example in that it lies at the junction of import streets 
> and is emphasized by the adjacent architecture.
>
> The existence of squares is not a recent or European invention, for example 
> you’ll find squares in arabic or Chinese cities as well (you’ll indeed find 
> them almost everywhere), here’s a list of some famous squares worldwide: 
> https://en.m.wikipedia.org/wiki/List_of_city_squares
>
> Supposedly we would not want to have different specific top level place tags 
> for neighbourhoods, depending on name components, so using place=square for 
> neighborhoods seems not a sensible interpretation of the tag, I guess we can 
> agree on this?
>
> Cheers Martin
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Route names that aren’t names

[Kevin Kenny]

On Sat, Mar 28, 2020 at 7:17 PM Paul Johnson  wrote:
>> I fully understand the difficulty with rendering only from route
>> relations. I maintain a renderer that does it.  It still needs some
>> serious programming if it is to scale to handle minutely updates
>> against the planet.  The project has, to put it mildly, less than my
>> highest priority, since Paul and Sarah have quite sternly discouraged
>> me from pursuing the approach that I took to the problem. The issue is
>> that the rendering servers are already grievously overloaded, and any
>> new functionality such as this needs to come at essentially zero cost
>> at render time, and only negligible cost at the time of minutely
>> updates. I've not been clever enough to meet that challenge, and while
>> new ideas might come to me, I've so far come up empty.
>
>  Which Paul?  I'm on Team Relation here.  It's been 13 years, relations 
> really need to be treated like any other primative.

Sorry, Paul Norman and Sarah Hoffmann.  I understand what they're up
against, I really do. And they can afford even less time and energy
for this than I can.
-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Route names that aren’t names

[Kevin Kenny]

On Sat, Mar 28, 2020 at 5:57 PM Richard Fairhurst  wrote:

> Sure. NCN 4 is called "NCN 4" in the same sense that the M4 is called the
> "M4". That's fine - plenty of people refer to it that way. But OSM
> convention, dating back 15ish years, is that in situations like this, you
> put the number in the ref alone. The M4 just has ref=M4, not name=M4.

We Yanks follow that convention for route _relations_, where we can
identify the network. Otherwise, it really doesn't work for us,  It's
entirely possible to have intersections between two routes with the
same number that belong to different networks. (Yes, it's confusing,
but we are used to identifying routes as "Interstate 95", "US 9", "New
York 20", "County Road 84",  even in speaking.)  For us to leave
that out would be like you saying the 4 or the 180 for the M4 or the
A180.

You convinced me that refs are not names, so I've been working in my
local area of killing off the use of the ref as the name, even in
cases where the road has no other name: 'ref="CR 104" noname=yes' in
preference to 'ref="CR 104" name="County Road 104"').  But as long as
we suffer with refs on ways, we need at least to make the refs useful.

(That gets tricky when one jurisdiction's road crosses over into
another jurisdiction.  About half of NY 120A
https://www.openstreetmap.org/relation/407958 is in Connecticut but
it's signed and maintained as a New York state highway.)

I fully understand the difficulty with rendering only from route
relations. I maintain a renderer that does it.  It still needs some
serious programming if it is to scale to handle minutely updates
against the planet.  The project has, to put it mildly, less than my
highest priority, since Paul and Sarah have quite sternly discouraged
me from pursuing the approach that I took to the problem. The issue is
that the rendering servers are already grievously overloaded, and any
new functionality such as this needs to come at essentially zero cost
at render time, and only negligible cost at the time of minutely
updates. I've not been clever enough to meet that challenge, and while
new ideas might come to me, I've so far come up empty.

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] landuse meadow getting the right description emphases

[Kevin Kenny]

On Mon, Mar 16, 2020 at 1:46 AM Joseph Eisenberg
 wrote:
>
> In American English, especially in the west, the word “meadow” is used for 
> areas in the high mountains which grow grasses, sedges, annual wildflowers 
> etc in the summer months after the snow melts. They might occasionally be 
> used to graze cattle as rangeland, but usually are only graced by elk.
>
> I think these would be called a “fell” in parts of Britain, but they are 
> somewhat similar to alpine meadows / pastures in the Swiss/Austrian alps, 
> where dairy cattle graze in the summer. Those really are pastures or hay 
> meadows, so perhaps Americans we got that usage from Swiss and Austrian 
> immigrants, and applied it to mountain grasslands?
>
> I agree that alpine “meadows” should be tagged natural=grassland, but don’t 
> be surprised to find some mapped as “landuse=meadow” in the mountains of 
> California and Colorado.

There are also 'wet meadows' - wetlands with sodden soil, but with
neither standing water nor tree cover. I've seen the scrubby ones
called 'laurel meadows' or 'alder meadows' according to the plant
community.  And there are 'ice meadows' along rivers and streams,
where there's no tree or shrub cover because the banks are swept with
ice in the spring floods - they have their own community of
low-growing plants that can tolerate that treatment and are often
found nowhere else.

Yes, these should be tagged as `natural=wetland wetland=wet_meadow`.
or `natural=scrub`, or (I can't find a good tag for ice meadows but
haven't tried to map any yet).

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Add man_made=goods_conveyor to Map Features or vote on the proposal first?

[Kevin Kenny]

On Wed, Mar 11, 2020 at 6:48 PM Joseph Eisenberg
 wrote:
>
> The tag man_made=goods_conveyor was proposed years ago for industrial
> conveyor belts and systems which move goods like mining ore. It is now
> documented as "in use" and used over 4000 times:
>
> https://wiki.openstreetmap.org/wiki/Tag%3Aman_made%3Dgoods_conveyor
>
> "A stationary conveyor system for transporting materials between locations."
>
> "How to map: Draw a way way in the direction of the transport and tag
> it man_made=goods_conveyor. You can add the tag resource=* to indicate
> the material being transported."

Just a quick question. Is it reasonable to support `oneway=no`? I know
of one that serves a lime kiln that hauls coal one way and cement the
other. The discussion on the WIki states, "I think that virtually all
conveyors are unidirectional, and this calls for an unidirectional map
symbol," but that's not universal.

No objection to rendering this!

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

Re: [Tagging] Feature Proposal - RFC - survey_point:benchmark

[Kevin Kenny]

On Sun, Mar 8, 2020 at 8:42 AM Anne-Karoline Distel  wrote:
> I've been surveying benchmarks for the past four months and I would like
> to propose an alternative to benchmark=yes for survey points:
> https://wiki.openstreetmap.org/wiki/Proposed_features/survey_point:benchmark
> The reason being that I would like to also propose
> survey_point:hexagonal_bolt and survey_point:ground_bolt with it.
>
> Definition: Ordnance survey point usually chiselled in stone with its
> typical horizontal bar and arrow below on vertical surfaces, dot with
> arrow below on horizontal surfaces. Now often replaced by hexagonal
> bolts in walls or bolts in the ground.
>
> Thank you for your time,

A 'control station' is any fixed mark used by surveyors to establish a
frame of reference. They're often placed specifically for the purpose
(often called 'monuments' in that case), but visible and stable marks
such as church steeples and fire towers have been used as stations.

In common speech, it's typical to call all the monuments 'benchmarks',
but to be technically correct, a 'benchmark' is limited to a 'vertical
control', a fixed point at a known elevation. The horizontal position
of a benchmark may or may not be established to survey accuracy.

'Ordnance survey' is UK-specific, as is marking benchmarks with the
Broad Arrow (a heraldic pheon, historically used to label Crown
property). The US, for instance, has no Ordnance Survey. We have the
US Coast and Geodetic Survey, the US Geologic Survey, many state
surveys (New York's is under the Department of Environmental
Conservation in the Adirondacks, the Department of Transportation
elsewhere), and many oddball ones
(https://forums.geocaching.com/GC/index.php?/topic/73161-1934-us-supreme-court-border-survey-mark/
- even the Supreme Court has ordered surveys). In the US, many
benchmarks have been placed by private surveys as well, because large
private operators also need coordinate frames. The best known are
perhaps http://www.wintertime.com/OH/GC/Disney/disneymarks.html

There's a fairly comprehensive discussion about the types of markers
used by the US government at
https://www.ngs.noaa.gov/web/about_ngs/history/Survey_Mark_Art.pdf

Right now the `survey_point=*` key is a mess. In fact, I'd write it
off as a total loss. It conflates several ideas:

Purpose:  Vertical control, horizontal control (or both). There are
also 'reference marks' - additional monuments placed to establish the
location of a primary mark lest the primary be lost or destroyed;
'azimuth marks' - used to establish a sighting direction from the
primary mark immune to geomagnetic variation, and stations that were
used in surveys to map the geomagnetic field, the gravitational
potential, the tidal variation, and so on. In addition, some control
stations had 'witness marks' that were placed only to alert people to
the presence of the station.
https://flickr.com/photos/ke9tv/29681317420 is one form these could
take. The trig point that it warns of is
https://flickr.com/photos/ke9tv/29348215163.

Form: I understand that the commonest form of a UK survey mark is a
stone tablet (or lettering and symbols of the same form chiseled in
native stone. While the US has used stone tablets, disc-shaped bronze
tablets are the commonest form here. Other forms frequently observed
are rods, pipes, bolts, drill holes, and clay cones.  In diggable
soil, a second mark was often installed underground, and was actually
the primary reference. The surface mark would be plumbed above it and
offset by a known vertical distance. Some of these
formerly-underground markers have since been exposed by damage. In
addition to form, material might be interesting: is a tablet of stone,
bronze, concrete, fired clay, ...?  Many tablets and rods were affixed
to drill holes by pouring hot lead, Babbitt metal, sulphur or bitumen
in the hole, and sometimes the hole and fill material are all that
remain (and the centre of the hole is still a usable horizontal
control).  You also seem to consider shape important - disc-shaped,
rectangular, or hexagonal tablets may have particular meaning to you?

Accuracy: Many surveys placed markers to different orders of accuracy.
Standards varied by agency and time.

Operator: Who placed the mark? Who now controls it?

(There are no doubt other attributes.)

Since all four of these can vary independently, it seems unwise to
group them all under 'type'

A more-complete description might be: 'BLACK (OD1740) horizontal
trigonometric control station, marked by a copper nail and washer
stamped "N.Y. / V.C.", position established to first-order accuracy
and thought to be of better than normal stability, placed by the
Adirondack Survey (Verplanck Colvin, state surveyor), now controlled
jointly by the National Oceanographic and Atmospheric Administration
and the New York State Department of Environmental Conservation.' or
'ALANDER (MZ2083) geomagnetic station, marked by a disc-shaped bronze
tablet, placed by US Coast and