Re: [Tagging] Default access for service=driveway?

2020-12-22 Thread Adam Franco
> 1. Should a routing engine automatically assume that something tagged a
> "driveway" is not suitable for through traffic?

For motor vehicles through traffic seems inappropriate by default, but for
pedestrians I would think it is generally ok. Bicycles are somewhere

The case Frederik originally asked about is a "private residential
property" where a corner-cutting service=driveway may be used to tag a
driveway that is conventionally part of the "private sphere" of that
residence. The challenge is that the same service=driveway tagging is also
used by driveways to commercial, government, and other types of property
that are in the "public sphere" by convention have fewer conventional
restrictions against pedestrian access.

My state (Vermont, USA) has open-access laws that generally allow
non-motorized travel over un-posted land. That said, in my small town and
rural area the convention is *usually* to avoid walking & biking on most
driveways of private residences, especially when those driveways go right
next to a house. Driveways of businesses, churches, apartment complexes,
and similar entities are regularly used as shortcuts by pedestrians.
Driveways to university buildings, government buildings, parks, and museums
are even more likely to be used by pedestrians and bicycles as either
shortcuts or normal travel routes.

I've been trying to think of defaults that would still allow access across
the "public sphere" driveways I mentioned above and not encourage private
residential driveway access, but so far haven't hit on a workable


On Tue, Dec 22, 2020 at 6:04 AM Martin Koppenhoefer 

> Am Di., 22. Dez. 2020 um 10:16 Uhr schrieb Frederik Ramm <
>> The private residential property has two driveways (highway=service,
>> service=driveway) entering it from different sides, thereby enabling
>> people to save a few metres by walking through, rather than around, the
>> property.
>> These driveways do not have an access=private (or access=destination)
>> tag or anything like that.
>> Questions:
>> 1. Should a routing engine automatically assume that something tagged a
>> "driveway" is not suitable for through traffic?
> I am unsure about this. If we encourage this interpretation we will have
> to review about 5.5 million driveways (which currently do not have an
> access tag) [1] . While I would assume that a driveway is typically private
> access (or destination), the tag isn't always used in this way,
> particularly in the country side and with long driveways. The wiki
> esplicitly states: "There is no defined default access tag for driveways,
> so data consumers have to guess if you do not add an access tag."
>> 2. If you map such driveways, would you add access=private (or
>> access=destination) in OSM...
>> 2a. ... even if there is no specific signage locally?
> if it is legally (or physically, e.g. gate) the situation, yes
> 2b. ... if there is a sign that says "access to houses X,Y,Z" without
>> saying that other access is forbidden?
> it depends on the specific situation, in tendency yes
>> 2c. ... if there is a sign that says "private driveway"?
> depends again on the situation (there may be private driveways which can
> be used, I would look for a "no access" sign or similar, in absence of such
> signage it is not always clear. for example some such signs are put because
> the owner doesn't want other vehicles to be parked, or to reject
> responsibilities, but you can walk through)
> Cheers,
> Martin
> [1]
> ___
> Tagging mailing list
Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Hazards (frost heave?)

2020-12-03 Thread Adam Franco
*hazard=frost_heave, hazard=bump?*

One of the common road hazards I encounter and would like to tag are large
frost heaves that occur at consistent locations every year. A few roads in
my region like VT-17 and NY-8 have poor roadbeds and get damaged by frost
heaves the first winter after repaving. These roads often have several
hundred yards of nice smooth and fresh pavement, then 2"-8" frost heaves
with cracks that reappear in the same places year after year.

Some examples:

   - VT-17: section A
   , section B
    (with "BUMP"
   sign), section C
   - NY-8: section A
   section B

This has been previously mentioned in an OSMUS Slack thread
 in regard to
smoothness=*, but tagging particularly bad (and often permanent) heaves may
be preferable as other sections of the roadway may be smooth and freshly

Signage on these tends to be inconsistent, often using phrasing like
phrases. In some locations the signs are permanently mounted, while other
locations get folding signage. As these are point features with varying
placement of signage, I would suggest mapping them as nodes on a roadway at
the heave position with something like hazard=frost_heave. Alternatively,
hazard=bump may be applicable to other situations worldwide for dangerous
bumps caused by something other than freeze/thaw cycles.


On Wed, Nov 25, 2020 at 8:27 AM Brian M. Sperlongano 

> Comment is requested on the proposal "hazard", which describes hazardous
> or dangerous features.  This tagging was first proposed in 2007, and I have
> adopted the proposal with permission from the original author.  Thanks to
> the various folks that assisted in the development of this proposal prior
> to this RFC.
> The key "hazard" has achieved over 28,000 usages, and it is proposed to
> formalize usage of the most popular values of this key while deprecating
> less-popular synonyms.  In addition, this proposes to deprecate
> protect_class=16 in favor of the hazard key.
> ___
> Tagging mailing list
Tagging mailing list

Re: [Tagging] Deprecate water=pond?

2020-11-12 Thread Adam Franco
I'm wondering if rather than deprecating water=pond, it would be better to
keep it as a value with overlapping usage to lake (like river/stream) and
instead focus tagging on the actual differences between different bodies of

I'd suggest two new tags that get at the heart of what I've been hearing
people suggesting as distinctions between all these water-bodies other than
size, their origin (natural or human-made) and whether they are naturally
flowing at their outlets, have human-created outlet controls, or no outlet
(in the case of endorheic basins
 or some quarries):

   - origination=natural/artificial
   - outlet_control=natural/artificial/no-outlet

*(I wanted to use "origin", but that is currently used for goods from

These could of course be sub-tagged if desired to add more specificity.

   - origination:natural=glaciation
   - origination:natural=landslide (if a natural dam was formed by a
   - origination:natural=beavers
   - origination:artificial=quarry
   - outlet_control:natural=bedrock
   - outlet_control:natural=soil
   - outlet_control:natural=beavers

Here are a few examples of lakes, ponds, and reservoirs that I'm familiar
with that seem useful for this discussion:

*Abbey Pond, Middlebury, Vermont*: OSM
This pond appears to have been scoured out during the last glaciation
period and drains over a hard-rock ledge. It appears to not be very deep,
but the presence of the ledge ensures that this pond will exist until
silted in or the land is re-formed by glaciers. At the same time, beaver
activity just upstream of the rock-ledge has raised the water level by 1-2
meters. This I would tag as:

   - water=pond
   - origination=natural
   - origination:natural=glaciation
   - outlet_control=natural
   - outlet_control:natural=beavers

*Crystal Lake, Beulah, Michigan:* OSM
, photo
, outlet dam photo

This large 3-mile x 9-mile lake was scoured out alongside Lake Michigan
during the last glaciation period. It's origin is very natural. It's water
level sat about 43 feet higher than Lake Michigan until 1873 when an
attempt at digging a transportation canal spectacularly failed dropped the
lake level by about 20'. (source 1
Today the lake-level is controlled by an artificial outlet dam

(really a weir) with its level changed seasonally. While this is by every
definition a naturally formed lake, it is today controlled by humans.

   - water=lake
   - origination=natural
   - origination:natural=glaciation
   - outlet_control=artificial
   - outlet_control:artificial=weir

A decorative human-made pond that empties over a rocky berm with no
operable level-control structures might be tagged with

   - water=pond
   - origination=artificial
   - outlet_control=natural

A totally natural lake with no human intervention might be:

   - water=lake
   - origination=natural
   - outlet_control=natural
   - outlet_control:natural=bedrock

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 ".

On Thu, Nov 12, 2020 at 2:52 PM Paul Allen  wrote:

> On Thu, 12 Nov 2020 at 19:30, Joseph Eisenberg 
> 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

Re: [Tagging] Crossing tagged on both way and node (was: What does bicycle=no on a node means?)

2020-10-17 Thread Adam Franco
As someone who renders a driving-focused map
 of [the most twisty] roadways, I
specifically have done exactly what Volker describes (looking at
highway=crossing nodes only).

To provide an example, my renderer walks down each vehicle-legal way and
demotes the curviness weighting for a distance in each direction whenever
it encounters a highway=crossing node on that way (or nodes with
highway=stop, highway=traffic_signals, barrier=traffic_calming, etc). This
particular map doesn't care about the geometry of footways, sidewalks,
paths, or buildings, so it can look at a much reduced data-set of just
vehicle-specific highways. If highway=crossing nodes aren't available and
crossings are only indicated on intersecting ways, then I'd have to add a
preprocessing step to build a list of all nodes that are members of a
highway=crossing way and then add that to the list of nodes tagged with
highway=crossing. I guess it's not an impossible task, but it is much more
simple to just look at nodes that are also members of the
vehicle-accessible highway ways.

I know OsmAnd can be configured to alert drivers of upcoming crossings (and
stop signs), but do not know if that router works only with nodes on the
ways of the current route or also does matching on crossing ways.

On Thu, Oct 15, 2020 at 1:06 PM Volker Schmidt  wrote:

> I don't know what the routers need, to be honest.
> I have adopted the approach happily because of the frequent two-stage
> approach. First the main road is mapped with foot/bicycle crossings as
> nodes , and at a later stage someone else may add the foot/cycleway
> details  - I did not occur to me that there may be an advantage in removing
> at that stage the already existing crossing node.
> I would also naively assume, that a car-only router does not need to
> inspect any of the foot/cycleways in the map, and can use the
> highway=crossing nodes as an indication to add small delays inthe routing.
> Anyone in the router business listening in on this conversation?
> On Thu, 15 Oct 2020 at 17:39, Jmapb via Tagging 
> wrote:
>> On 10/13/2020 6:30 PM, Kevin Kenny wrote:
>> On Tue, Oct 13, 2020, 17:41 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. 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.
>> 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.
>> I've always been surprised to see a footway=crossing/cycleway=crossing
>> way with the intersection node tagged as highway=crossing. There's only a
>> single physical crossing, so this seems contra to the
>> one-feature-one-element rule.
>> A highway=crossing node makes sense in an area without mapped
>> footways/cycleways. But if the crossing ways are mapped, routing software
>> will need to examine the intersection node and scan the properties of all
>> highways intersecting there. It seems to make tagging the node itself
>> redundant.
>> Are there really routers that require the node be tagged as well?
>> Jason
>> ___
>> Tagging mailing list
> ___
> Tagging mailing list
Tagging mailing list

Re: [Tagging] Rio de la Plata edit war

2020-08-04 Thread Adam Franco
It seems to me that the main underlying conflict is that (at least in the
default Carto rendering on a few years ago) the Rio Plata
was getting rendered as land at low-zooms and South America simply looks
wrong when such a large water area is rendered as land. is a very
long issue thread that addresses this land/water rendering problem,
starting first with some of the Great Lakes not rendering, then expanding
to cover other water areas. I'm not familiar enough with the Carto code to
know the current state of things, but would this rendering issue still be
present today if the coastline was drawn from Punta del Este to Punta Rasa
as muralito suggests? If this rendering issue has been addressed then it
feels to me like the stakes of the "coastline" tagging placement become
much lower.

My impression is that low-zoom renderers seem to often interpret
"coastline" as "the junction between land and 'big water'" whereas people
standing on land looking at water might often interpret "coastline" as
solely "the junction between land and ocean/sea" and may not want to
include rivers, estuaries, canals, navigation channels, salt-marshes,
protected bays, and other features that sit a little bit away from where
ocean waves are crashing on the beach. While usually these features are
small enough to ignore at low-zoom, Rio Plata, the Saint Lawrence estuary
, Long
Island Sound,
Sound ,
and others are big enough to be visible at low-zooms qualify as "big water"
connected to the ocean even if they aren't fully ocean themselves.
Similarly does the "coast" shift out to include barrier islands and enclose
the protected waters behind them? Looking at current mapping it does
sometimes and doesn't other times.

All that said, there are probably many other data consumers who aren't able
to leverage the techniques used by Carto and would like to make their own
decisions about how to render the distinctions between land, fresh water,
and big salty water. Being able to tag an estuarine environment with its
own tags could allow data consumers to make their own choices about
rendering and placement. Some potential use cases:

   - A general purpose renderer like Carto would probably want to display
   estuaries as water to make the land shape more closely match low-zoom
   satellite imagery. Most traditional general-purpose maps care more about
   the distinction between land and water rather than what the properties of
   the water are

   - A marine ecology map might wish to render oceans and estuaries, but
   hide rivers and land-based features from display.

   - A map focused on rivers might want to highlight the distinction
   between purely fresh-water rivers and estuaries in a more pronounced way
   than a general-purpose map would want to.

Joseph previously suggested dedicated estuary tagging:

On Tue, 4 Aug 2020 at 06:43, Joseph Eisenberg 

> I have previously proposed that estuaries should be mapped by extending
> the coastline upstream to the limit of the estuary, and also mapping the
> area of the estuary as water with water=estuary

Unfortunately, only a waterfall or dam is going to provide the kind of
hard-lined transition point between ocean and river that would allow a
"coastline" way to cut across the water without ambiguity as to its
placement. All other transitions points on every river-mouth (estuary or
otherwise) are going to be ever changing with rainfall and tides and at
best will only ever be an agreed-upon average or culturally defined
placement. It is simply impossible to verifiably map an ever-shifting
gradient with a single line across the water.

I'd suggest that estuaries get their own tagging as areas (maybe with
sub-sections covering differing properties like tidal influence, salinity
thresholds, etc) and let the "coastline" cross it wherever local mappers
agree a good average threshold is met. The estuary areas should have their
extent based on physically defined thresholds like "average annual salinity
greater than x%" or "average current dominated by ocean-flow vs
river-flow".  Data consumers can then be free to use the mapped "coastline"
line or ignore it where it crosses an estuary, including the greatest
extent of the estuary in their interpretation of "coast" or the most
Tagging mailing list

Re: [Tagging] How are protected_area (and national_park) boundaries determined?

2020-06-23 Thread Adam Franco
> On Tue, Jun 23, 2020 at 11:40 AM Rob Savoye  wrote:
[...] While I do use parcel maps on fire calls, adding all these boundaries
> to OSM would be silly. I agree that mapping the outer boundary is all
> that's needed.

My main use of maps of National Forests is planning backcountry trips that
include dispersed camping. Knowing which parts are *actually*
owned/administered by the Forest Service is really important information. I
don't want to plan a whole trip only to discover when I hike in that my
ideal riverside camping destination is actually on a private inholding
posted with No Trespassing signs and that I'll need to hike a few more
hours to get back onto a FS-parcel where camping is allowed.

It is sounding more and more like both boundaries are useful and that they
really are two separate things. While both are related to the same abstract
concept of a particular National Forest and would have the same name=*,
they are different things in terms of their extent, meaning, and impact.
Mapping them with two objects is really the only way to come close to
capturing their nuances without implying falsehoods (protection in urban
areas/inholdings where there is none) or losing the legally authorized
boundary completely.

On Tue, Jun 23, 2020 at 8:18 AM Joseph Eisenberg 
> wrote:

1) The boundary declared by Congress (the legislature), which includes
> large areas of private land and whole towns in many cases

It's not clear to me what tagging is most appropriate for this boundary,
but the current practice of boundary=national_park seems at least not-wrong
if maybe incomplete.

> 2) The actual land owned by the Federal Government of the United States
> within that declared boundary.

For these areas boundary=protected_area + protect_class=6/* is both
accurate and should be sufficient.
Tagging mailing list

Re: [Tagging] Examples at

2020-05-29 Thread Adam Franco
On Fri, May 29, 2020 at 9:48 AM Kevin Kenny  wrote:

> 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.

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

Going back to driveways and private roads, most Vermont Towns are loath to
take on the additional maintenance burden of access roads to just a few
houses and so a large number of small roads and shared driveways are signed
"Private" or "PVT" on the street sign. (Example of PVT
) This indicates
that maintenance of the road
 is the
responsibility of the private land-owners and the Town is not responsible
for it. Residents on private roads that serve 3 or more houses may also
petition their Town to take on maintenance and make it a public road. The
"Private" designation in this fashion does not imply access restrictions,
only maintenance responsibilities. Unfortunately, some mappers in my area
have been blanket-tagging all of these as access=private which I believe to
be a mistake. The TIGER import also tagged all of these as access=private.
Many people in rural areas like their privacy and going up a road serving
several houses without going to one of those houses may prompt inquiry, but
it is is not prohibited until you are told to leave by sign, verbal, or
other clear indication. I'm fine with tagging these access=destination as
that seems to fit better than access=private.

Privately owned roads where owners clearly don't want public access are
often gated and/or be posted with "Private, no trespassing" signs and these
are what I think should be tagged access=private. If all driveways/private
roads are tagged with access=private, then that distinction becomes
impossible to disambiguate.

On Fri, May 29, 2020 at 9:48 AM Kevin Kenny  wrote:

> 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 

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

2020-05-21 Thread Adam Franco
For those who missed it, a related discussion was just had on this list
about differentiating mountain-biking trails from cycleways.
See the resulting proposal for path=mtb and
threads from April in Tagging:

On Thu, May 21, 2020 at 8:51 AM Andy Townsend  wrote:

> On 21/05/2020 10:50, Mateusz Konieczny via Tagging wrote:
> Similarly anyone creating
> highway=footway + danger="you will be shot" + "access=no" + foot=yes"
> should probably switch to pickpocketing, telemarketing or other less
> harmful activity.
> While "danger" isn't a much used tag (and I'm sure wasn't a serious
> suggestion here - ),
> sometimes "foot=yes" is correct and other tags need to be taken into
> account.  I've used the area around
> as an example of that
> before.  Here "foot=yes" is correct - there is a legal right of access.  "
> sac_scale
> =demanding_alpine_hiking"
> also makes sense here I think.
> I take Frederik's reference to Andy Allan's point about "a
> multi-billion-dollar-revenue organisation that were rendering anything with
> a highway tag the same as their most minor road style" but frankly there's
> simply no solution to that - presumably "highway=dangerouspath" (to make up
> a nonsensical value) or
> would still
> get shown as a "road".
> Map styles need to be clear about what they're showing and what they're
> not showing and people using maps need to be able to read maps so that they
> understand what they're being told.  This isn't really a tagging issue,
> unless OSM mappers aren't using appropriate other tags when they should
> (sac_scale, trail_visibility, surface, etc.)
> Best Regards,
> Andy
> ___
> Tagging mailing list
Tagging mailing list

Re: [Tagging] Is there any tagging scheme for carillons already?

2020-05-07 Thread Adam Franco
These large bell-instruments their own terminology with a Carillon being
defined as having 24+ bells:* "A carillon-like instrument with fewer than
23 bells is called a chime
." *(ref
Wikipedia/Carillon ) with the
exception of *"Instruments built before 1940 and composed of between 15 and
22 bells may be designated as 'historical carillons.'"* (ref
Wikipedia/Carillon )

It seems that tagging these instruments under a overarching category might
be good. Something like: man_made=bells + bells=carillon for the larger
instruments and man_made=bells + bells=chime for the smaller ones. Those
"historical carillons" could get either one or their own value for bells=.
This would avoid the potential confusion of calling something with 14 bells
a "carillon" which would be inaccurate.

On Thu, May 7, 2020 at 11:22 AM Joseph Eisenberg 

> +1 to using man_made=carillon or =bells.
> Don’t use attraction because that is for carousels and roller coasters and
> similar things in amusement parks, mostly.
> —Joseph Eisenberg
> On Thu, May 7, 2020 at 8:18 AM Martin Koppenhoefer 
> wrote:
>> sent from a phone
>> > On 7. May 2020, at 16:26, wrote:
>> >
>> > But maybe I will start a proposal with attraction=carillon for tagging
>> carillons which are operated as an attraction, but then the definition of
>> that has to be very clear, I think.
>> I am all for tagging carillons, if you like with all the details like
>> material, number of bells, melodies that are commonly played and at which
>> times, etc., but please do not use the “attraction” key. tourism=attraction
>> is a questionable tag (how would it be verified/what is an objective
>> criterion on distinguish between something being or not yet, an
>> attraction?), and it does generally more harm than help to describe the
>> world (because it renders a name and many people are not encouraged to push
>> it further and actually describe what the thing is).
>> Just leave it open whether a carillon is an attraction or not, and map:
>> “here’s a carillon”. Suitable keys I would examine could be amenity or
>> man_made, there could also be a property like carillon=yes/no to indicate
>> there’s a carillon at a place (e.g. a tower).
>> If you are interested in tagging additional detail it seems better to
>> create a distinct object than adding a property to something else.
>> Cheers Martin
>> ___
>> Tagging mailing list
> ___
> Tagging mailing list
Tagging mailing list

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

2020-04-05 Thread Adam Franco
> On Sun, Apr 5, 2020 at 3:49 AM Andrew Harvey 
> wrote:
> ...
Although that feels most logical to me, since the sentiment here is
> strongly against this view about highway=cycleway including mountain bike
> tracks, I'm proposing instead:
> Designed/mostly used for city cycling (excluding mountain biking) ->
> highway=cycleway
> Designed/mostly used for mountain biking (excluding city cycling) ->
> highway=path + path=mtb
> Not designed for any specific mode/mixed use -> highway=path

Thank you for putting together this  highway=path + path=mtb suggestion,
Andrew. This is first suggestion on this thread that has felt like a good
direction forward. First and foremost, mountain bike trails are paths,
anything further is a qualifier that adds precision, but not a

In contrast, proposals to change to leisure=track feel wrong because these
are routable ways and dropping highway=* removes them from the routable
network. Similarly, fiddling with access tags to imply mountain-biking
trails feels like adding too much inference and dual-purpose to these tags
that then complicate the access scheme. In general, I think expanding the
path=* key would be a good way to add additional precision for other
"special purpose" paths.

I'm a long-time mountain biker and also a bicycle commuter, so I can
sympathize with both camps. While my area (Vermont, USA) has some
special-purpose mountain-bike trails (with ramps and the like) that are
built at ski areas, most of our trails are built and cut by and for
mountain bikers, but are also used by trail-runners and walkers. The "built
for mountain bikers" part means that they have been sculpted to follow the
terrain in a way that is fun on a mountain bike, with turn radii and grades
that allow a flowing cadence. Often elevation gains/drops are managed to
optimize for time coasting downhill, rather than dropping steeper than is
needed only to have to climb again. These trails are also usually great for
hiking/running, but also feel great on a bike. In contrast, a trail "built
for hiking" might not worry about twisting between some large jumbled rocks
that tires simply can't traverse, or might use steep, straight grades and
stairs that "waste" elevation gains in a way that is less-fun on wheels.
Long story short the vast majority of specialized mountain-bike trails *are*
highway=path, they are just a particular flavor of highway=path.

I would strongly support a formalized proposal based on what you put


On Sun, Apr 5, 2020 at 3:49 AM Andrew Harvey 

> Thanks for everyone's good feedback and discussion. I feel we are getting
> closer to a conclusion.
> Before this discussion my view on how it should work was:
> Designed/mostly used for vehicles, forestry, agriculture, bush fire trucks
> (known as fire trails in Australia) -> highway=track
> Designed/mostly used for walking (including hiking) -> highway=footway
> Designed/mostly used for bicycles (including mountain biking) ->
> highway=cycleway
> Designed/mostly used for horses -> highway=bridleway
> Not designed for any specific mode/mixed use (no formal designation) ->
> highway=path
> Although that feels most logical to me, since the sentiment here is
> strongly against this view about highway=cycleway including mountain bike
> tracks, I'm proposing instead:
> Designed/mostly used for city cycling (excluding mountain biking) ->
> highway=cycleway
> Designed/mostly used for mountain biking (excluding city cycling) ->
> highway=path + path=mtb
> Not designed for any specific mode/mixed use -> highway=path
> The reasoning behind this takes into consideration:
> bicycle= as an access tag should refer to any class of bicycles by
> default. Today I was walking a track which had a no bicycles sign, meaning
> all types of bikes are disallowed. Conversely bicycle=yes just means that
> bicycles are legally/physically allowed, it does not indicate suitability
> by a specific type of bicycle. I don't think I've ever seen signage which
> says no mountain bikes but you can use a road bike, or vice versa. If there
> is then we should use sub bicycle access tags like road_bike=, mtb=, bmx=
> etc. You could have a path which is clearly a mountain bike track but
> officially bicycles are not allowed. So based on this we can't use these
> kinds of access tags to define the type of path they must be kept
> independent.
> Not all mountain bike tracks are mtb=designated. Many paths are built for
> and used mostly by mountain bikes, key giveaways are jumps, corner banks
> and other technical features, but not officially signposted or marked for
> use by mountain bikes. Conversely the track could be signposted for use by
> mountain bikes but not actually be a mountain bike track, eg. it could be
> highway=track which is not a mountain bike track, but indicated as a way
> for use by mountain bikes so mtb=designated.
> So I'm proposing the access tags bicycle= refer to any/all bicycles. 

Re: [Tagging] RFC rewritten proposal Via_ferrata_simplified

2019-03-06 Thread Adam Franco
On Tue, Mar 5, 2019 at 8:04 PM Kevin Kenny  wrote:

> Slightly off topic: vie ferrate are not a familiar thing in the
> mountains near me.
> Does
> count?

I wonder this as well. I don't have any direct experience with Via
Ferratas, but reading these two pages makes me think that the term seems to
be used for more involved routes than a short set of stairs or hand-holds:


I'm interested if those with more familiarity think a short segment of iron
steps/hand-holds (and not the extra protection cable) or only a short
length of optional protection rope/cable would qualify for
Tagging mailing list

Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?

2019-01-22 Thread Adam Franco
As someone who has mapped a lot of landcover & landuse
 in my local area,
I welcome sorting out the confusion that is the current state of
natural=wood/landuse=forest. Many parcels around me are managed for
forestry purposes but don't have trees currently while others had been
cleared at one point, but have returned to forest due to neglect and are
not managed for timber production.  My current practice is to map areas
covered in trees as landcover=trees + natural=wood, but I'd love to drop
the natural=wood if landcover=trees was rendered. Generally, I don't
imagine that I'd map much landuse=forestry, which is probably a good thing
as I don't often know which land is managed for productive forestry and
which is more negligent forest succession. In cases where the management is
known and is important to be known, then landuse=forestry becomes a useful
tag as it is unambiguous as to what it means.

I hope that a shift toward landuse=forestry would also include a shift
toward landcover=*, in particular landcover=trees as the rightful clear
designation that "there are trees here". Here is an old landcover=* proposal
might be resurrected and updated.

I'm not sure if I would want landuse=forestry to be rendered by default or
if so, how I would like it to be styled. Generally in my region, areas
managed for forestry are more parcel boundaries than anything equating the
land-cover on the ground, so renderings that include iconography like trees
are problematic if those icons overlap and conflict with other land covers.
I see landuse=forestry as something more useful for custom maps or maybe
something that would be rendered as a subtle modifier to more-visible
land-cover renderings which are more directly visible and impactful when
traversing the landscape.


On Tue, Jan 22, 2019 at 2:39 PM Paul Allen  wrote:

> On Tue, 22 Jan 2019 at 18:14, David Marchal  wrote:
> Your landuse=forestry proposal seems good to me: it is clear enough, and
>> the transition process you describe here seems consistent with what I know
>> about such transitions which already happened. If I understand you, the
>> main problem for landuse=forestry is to include it in the standard style to
>> not discourage its use,
> Yup.  If it rendered, people who read this list would use it.  If enough
> people used it, editors
> would offer it as a preset (for iD somebody would have to raise the issue
> on github since
> Bryan Housel recently announced he was no longer following this list).  A
> couple of vicious
> circles there.
> but style devs rejected adding its rendering before its use spread a bit.
> I don't know if they have rejected this specific idea, or even if they
> were asked.  It's just
> that they often require that a tag has been used sufficiently in the wild
> before they consider
> adding it.
> Some sort of vicious circle, in fact?
> As I said, two of them.  It won't be widely used until editors offer it as
> a preset and it
> renders.  So we're at an impasse.  A proposal to introduce it that
> suggests dual-tagging
> until it takes off enough for editors and carto to support it seems the
> only way forward -
> not guaranteed to succeed but it might.
> I might even write the proposal myself.  But only after I get a feel for
> the mood here.  So
> far nobody has heaped scorn on the idea, which is a good sign, but I'd
> like to see a little
> more support first because if people here don't see it as sensible then
> neither will
> most ordinary mappers.
> --
> Paul
> ___
> Tagging mailing list
Tagging mailing list

Re: [Tagging] Building names, historical/original owner?

2018-12-15 Thread Adam Franco
On Fri, Dec 14, 2018 at 11:46 AM Jmapb  wrote:

> IMO it's fine to use old_name=* even without name=* -- to record the fact
> that it used to be known as the Johnson House, but there's no current name
> in common use. J

Thanks all for the feedback. I guess I'll use old_name=* for these. The
names may be currently applicable but not in common use, sort of an
alternate name used mostly by historians. alt_name=* seems to be equally
valid, but a little less precise.
Tagging mailing list

[Tagging] Building names, historical/original owner?

2018-12-14 Thread Adam Franco
I have a question about `name=` and variants of names. I've been reading a
lot of local history and in the architecture/history world, houses are
generally named for the first resident that they were built for. E.g.
"Johnson house" and are referred to in this way even after many generations
of new owners. After adding a few of these names to the `name=
` tag I realized that this
might be problematic as `name=` seems to be given higher rendering priority
than house number (at least on and, potentially
causing wayfinding confusion as addresses disappear and long-dead owners
names start popping up.

For some of these buildings they are commonly referred to by the public
using this historical-owner name. For example the "Osborne house"
  in my town was referred to
as such in public meetings and newspapers several years ago when it was
picked up and moved. It now has a new address as a result of this move.

In many other cases buildings are locally referred to by their current
address or current occupant. Especially in the case of a building taken up
by a single business, locals will simply refer to the building as the
" building".  The historical-owner name is still valid
and interesting for cross-referencing historical materials, but it likely
isn't well known and in many cases and wouldn't be useful for wayfinding as
it would not be found on signage.

What are folks thoughts about these historical-owner building names when
they aren't well-known? Should they go in a `description=
` tag, `alt_name=
`, or some other tag?

Thanks for any insight you can provide.
Tagging mailing list

Re: [Tagging] Another multipolygon question

2018-10-24 Thread Adam Franco
My pleasure, Dave! I'm glad to have helped even a little. :-)

Here's another short (2:25) video showing how I use the Relation Editor
window to sort and find disconnected segments:


On Wed, Oct 24, 2018 at 9:35 AM Dave Swarthout 

> They say a picture is worth a thousand words and IMO that video says
> bushels about mapping relations. I was always a bit scared when fooling
> with them because as it turns out, their reputation is worse than the
> reality. The Reltoolbox is similar to the normal relation editor as Kevin
> points out but for me it makes the task ever so much faster. You can move
> along picking up pieces of whatever multipolygon you're constructing and it
> just magically adds them. I have one place where the same way is used for a
> place=island with its name, a NWR boundary, a wood multipolygon and a sand
> multipolygon. Freakin' awesome! I've learned more in the past day while
> mapping islands in the Kodiak Archipelago than in the past 5 years of
> working with multipolygons.
> Now all we need is a video tutorial showing how to analyze one during a
> debugging episode. Talk abut sorting, perhaps, an a walk through of a
> session where there is a "gap" in some relation that you cannot locate.
> What techniques and/or tools would one use in that case? And what about
> those little squiggles that appear at the end of each member's line in the
> relation editor. I know they indicate connectivity (a closed loop?) but
> what do you do if there is a problem, a "gap."??
> Anyway, thanks again to Adam. You've advanced my understanding immensely.
> Dave
> On Tue, Oct 23, 2018 at 10:39 PM Kevin Kenny 
> wrote:
>> On Mon, Oct 22, 2018 at 12:36 PM Adam Franco 
>> wrote:
>>> Hi Dave, all,
>>> Based on this discussion I just recorded this short tutorial
>>> <> of how I use JOSM and its Relation
>>> Toolbox plugin to to add adjoining land-cover areas as multipolygons with
>>> shared boundary ways to reduce duplication and overlapping ways.
>> Thanks for recording that! Now I don't have to. :)
>> Your workflow is essentially the same as mine, except that I use the
>> regular old relation editor to add and delete ways. Works well enough for
>> me, and I think it's only one or two clicks more than what you're doing. I
>> also make a lot of use of 'replace geometry' from utlilsplugin2, since a
>> lot of what I'm editing was born as imports and is being replaced with
>> updated data from the same sources. Yes, I'm very careful not to step on
>> the work of local mappers when I do it.
>> Depending on what's going on in the field, I might have called that
>> hedgerow a tree_row or a hedge and used a linear feature to map it.
>> Similarly, at breaks in tree cover for things like power lines and
>> pipelines, I might use man_made=cutline. Speeds up the process a little bit
>> more. For what it's worth, I tend to restrict the 'cutline' tag to a
>> standard (in NY) four-rod right-of-way; if the cutting is larger than that,
>> it gets a polygon.
>> Hopefully this will begin to show that for complex landcover, or
>> similarly complex admin boundaries, that multipolygons with shared ways are
>> actually quicker and easier to maintain than simple areas.  I know that
>> they're still controversial, even among experienced mappers, but for
>> something complicated like West Point
>>, with a whole bunch of
>> shared borders, rights-of-way cut out of it and what not, I'd be really
>> handicapped without shared ways.  I didn't get very far on the landcover
>> because I seldom map landcover other than in my own neighbourhood or when
>> fixing other people's mistakes.
>> ___
>> Tagging mailing list
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at
> ___
> Tagging mailing list
Tagging mailing list

Re: [Tagging] Another multipolygon question

2018-10-22 Thread Adam Franco
Hi Dave, all,

Based on this discussion I just recorded this short tutorial
 of how I use JOSM and its Relation Toolbox
plugin to to add adjoining land-cover areas as multipolygons with shared
boundary ways to reduce duplication and overlapping ways.

The area I'm editing, is replete with examples of this type of mapping:

The tools used are:
* JOSM editor -
* "Relation Toolbox" JOSM plugin -

Documentation on MultiPolygons in the OSM wiki:

For some reason I've gotten hooked on mapping landcover in my area and
spend a lot of time adding multipolygons to do so. I find them vastly
easier to manage, update, and fix than simple closed ways with overlapping
edges (how I started). As I show in the video, adding detail usually just
means splitting exiting ways and adding/subtracting using the Relation

Hope this helps someone -- let me know if there are particular cases or
questions and I'd be happy to record another video covering other


On Mon, Oct 22, 2018 at 8:47 AM Paul Allen  wrote:

> On Mon, Oct 22, 2018 at 5:27 AM Dave Swarthout 
> wrote:
>> Great. But what are you actually doing when you "sort the members" of a
>> relation? And after sorting, how does one "ensure the members are
>> connected"?
> Sorting something like a bus route ensures that the various ways that
> constitute it are connected
> nose-to-tail.  This is what "ensures the members are connected" and
> ensures they are connected
> in a sensible fashion.  Sorta.  It may not do a good job if the route
> traverses the same way in the
> same direction more than once.
> I've noted with dismay the lack of debugging support for relations. For
>> example, I will get an error message when trying to upload an edited
>> relation but when I ask JOSM to Zoom to the error, the display zooms out
>> enough to include the entire relation with no clue as the where the actual
>> problem is. Same thing when you ask to "jump to the next gap". Good luck on
>> that also. Maybe it's just me?
> Nope, it's not just you.  I too have problems getting my head around
> JOSM.  I use it when I have to,
> to merge or split areas (such as when I find out that a large forest that
> somebody else mapped
> has two named chunks).  It's probable I find it hard to use because I
> don't use it enough, which means
> I don't use it much, which means...  But I also have to admit that I find
> Java programs in general are
> not a good fit with how my mind expects things to work and they all give
> me a steeper learning curve
> than non-Java programs.  Which means I try not to use them much, which
> means...
> --
> Paul
> ___
> Tagging mailing list
Tagging mailing list

Re: [Tagging] areas of risk

2018-08-17 Thread Adam Franco
What areas are "dangerous" is very much a matter of race and class in the
USA and likely in many other parts of the world.

For example, there are wealthy mostly-white neighborhoods in many American
suburbs where a person-of-color just walking or driving through is cause
for residents to (injustly) call the police. This can VERY dangerous for
these people of color and has resulted in the police shooting completely
innocent people.

Similarly, a plaza where many pockets are picked may be "dangerous" for
unsuspecting tourists fiddling with their cameras, but be safe for locals
who aren't staring at the vistas. It also may have no crime during certain
hours or when a police officer happens to be monitoring the area.

Many places may seem dangerous to outsiders, but are totally comfortable
for locals. In other places, no one messes with the wealthy foreign
tourists, but locals are subjugated to inhumane and dangerous conditions
that place them at extreme risk.

Another "risk" case would be an area where a civil war or conflict has
divided who controls what land. Either side of the line of control may be
incredibly risky for people affiliated with the other side but not to the
supporters of those in control.

Overall, if a level or perception of risk is very dependent on who you are
and what your background is, then it is going to be a fraught thing to try
to map.  Similarly, past crimes are not a guarantee of future crimes.

As was mentioned above, if you don't feel comfortable giving specific
examples, then it is pretty impossible to have a discussion of the merits
of the idea.

On Fri, Aug 17, 2018 at 2:57 PM, seirra  wrote:

> well like i said, i meant more for specific things that aren't just
> generalisations where it may actively  prevent you from doing something or
> where it is a regular occurrence. i don't personally see the race/class
> related aspect, but as previously said i respect that others feel it is
> there and thus should be avoided (i hope i'm not offending, although i
> respect the final decision i really don't understand)
> On 08/17/18 18:30, Paul Johnson wrote:
> Then you're just splitting class and race hairs.
> On Fri, Aug 17, 2018, 11:20 seirra  wrote:
>> there can be notable areas though, outside of what may usually be expected
>> On 08/17/18 16:03, Paul Johnson wrote:
>> On Thu, Aug 16, 2018, 16:35 seirra  wrote:
>>> hmmm i do see the point there about racial/class bias... i was thinking
>>> more about areas that were known crime spots/had associated illegal
>>> activities people may want to avoid(to the point there are regular police
>>> patrols at night)? also places where getting a phone out could lead to it
>>> being stolen? i've heard that can be an issue in some areas. just wasn't
>>> sure if any of those scenarios really deserved tagging because i didn't
>>> really feel there was a bias there? either way just wanted to check (sorry
>>> if this shows up as a double post, i saw there was a reply to mailing list
>>> option i should be using, i get the impression the first time didn't send)
>> At that point, you're just avoiding cities in general, as crime rates
>> tend to increase proportionally to population density.
>> ___
>> Tagging mailing 
>> listTagging@openstreetmap.org
>> ___
>> Tagging mailing list
> ___
> Tagging mailing 
> listTagging@openstreetmap.org
> ___
> Tagging mailing list
Tagging mailing list

Re: [Tagging] Missing access value (access=license / authorization?)

2018-08-08 Thread Adam Franco
On Wed, Aug 8, 2018 at 8:11 PM, Kevin Kenny 

> I haven't forgotten. I'm just going through a crunch time at work, and
> haven't had time to draft the thing formally.

As mentioned by Paul earlier in this thread, it looks like you already put
together a pretty solid draft two years ago (assuming you are ke9tv in the
wiki as well):

Reading through this proposal it looks like it captures most of what has
been discussed in this thread so far. Maybe it just needs a once over to
ensure that it all still fits.

Alternatively, maybe you meant drafting a formal *announcement* of the
proposal. :-)

On Wed, Aug 8, 2018 at 8:11 PM, Kevin Kenny 

> On Tue, Aug 7, 2018 at 10:11 PM Graeme Fitzpatrick
>  wrote:
> >
> > Yep, Kevin's proposal solves a lot of problems.
> >
> > Let's try to push it along & get it approved.
> I haven't forgotten. I'm just going through a crunch time at work, and
> haven't had time to draft the thing formally.
> ___
> Tagging mailing list
Tagging mailing list