Re: [Tagging] Two way street, but entry of motor vehicles blocked at one end. Relation correct? Tagging correct?

[Greg Troxel]

Christoph Grenz via Tagging  writes:

> This tagging (a short section marked as oneway) is also quite usual in Germany
> for this case, but restriction=no_entry is slowly becoming popular too.

As usual, I think that

 in the short and medium term, tagging should be done with great
 consideration for existing renderers (routers!)

 in the long term we need to expect renderers to catch up to conensus

 while it's great that we have this free-form tagging, we need to be
 careful not to use it where reasonable renderers (routers) will do the
 wrong thing because their global code doesn't know about what a few
 people are doing that isn't yet consensus


So I think you should absolutely have the oneway section, even if you
also add another tag.  Unless of course there is evidence that the large
majority of routers would do the right thing.  There are a huge number,
but I'd say it's ok if of all the routers on osm.org, osmand, organic
maps, N-1 are ok and 1 fails.  (Or N ok and 0 fail.)

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

Re: [Tagging] Difference between "yes" and "designated" in access tags

[Greg Troxel]

Jass Kurn  writes:

> Need to point out for others reading this than I am in England, and
> influenced by what I believe was likely the original intent of these tags,
> that is mapping of the "English/Welsh, rights of way"
>
> I've always treated " foot|bicycle|horse=yes, as a means of showing I
> confidently believe with evidence available that access is allowed. Done
> with regard to the defaults for tag (eg don't add when highway=footway)

sure

> Designated & Permissive allow me to tag in more detail if evidence is
> available to support tags

yes, but they are totally different

> I use ''designated" for where there is a demonstrable "right of access" eg
> Specific recognisable signage, online usable data, etc, which demonstrates
> a legislative or contractual, rights of way.

I think this is off.  To me, designated means both

  =yes (there is a legal right of access)
and
  there is some official blessing that of all the usable modes, the
  trail is somehow intended for that particular one

IMHO there can be no designated without an underlying =yes.

> I use "permissive" for the common British situation of ways being provided
> on private land, and where the owner has displayed signage to inform the
> public that the way is "Permissive" and not an English/Welsh "Public Right
> of Way". (This should block the private way becoming a "right of way"
> through continuous use.)

That seems super country specific, but I think it's fine.

I see permissive as

  there is no legal right of access, but *it is known* that the
  landowner does not object

which is different than

  It's not a crime to walk because there is no "no trepassing sign".
  (In the US, trespassing is generally not a crime, but only "trespass
  after notice".  In my state, it technically only applies to developed
  land, but ~nobody understands or believes that.)

which should definitely not be signed permissive.


Then, there's a vast grey area.  Driveways for individual houses are
properly signed "acess=private" because

  1) there is no legal right of access

  2) there is no known permissive situation

  3) there is a social convention that while there are generally not "no
 trespassing" signs, that unpermissioned use outside of narrow
 social conventions is not ok and will lead to a no trespass order
 
People often think '=private' requirs a "no trespassing" sign.  That's
wrong; it is simply that there is no legal right of access.

A further complexity is a store parking lot (carpark), or a shopping
center (multiple stores with shared lot/carpark).  Technically this is
private, and there is no legal right of access.  But the culture is such
that public access is completely acceptable, with a few "no distribution
of literature" exceptions that are often signed.  We tend to tag those
are =customers, which is close enough.  Even though that's often
customers/permissive, more towards customers for actually parking, and
very much permissive for walking.

> issues I have are separating "legal right of access" and the ability to
> actually use the way. A common problem with British/Welsh rights of way
> which do not have to be managed to to allow all foot users

access= is 100% about permission.   Physical tags are for physical
situations.

Perhaps you need width=0, or something.

I think the basic issue is that osm does not really have  practice of
tagging 'legally there is a right of access  but there is no passable
path'.  My town has such things; easements laid out but just brush.

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

Re: [Tagging] traffic_signs: human readable values vs. ISO and law codes

[Greg Troxel]

yo paseopor  writes:

> Well, let's start. As you know there are values in traffic sign key that
> are human readable and others that are the ISO code of the country plus the
> code inside the traffic law of every country (from South Africa to USA). It
> is not a big problem...except they are using the same key.

So it is a big problem!

> Probably human readable values are the future of OSM, because you don't
> know very specific knowledge about that. So a newbey mapper can use iD
> Editor and put a maxspeed traffic sign, or can use hazard from a proposal
> from the wiki.
> But in the other hand major use in traffic_sign key are the legal and
> specific values for each traffic sign (or a combination of that). You can
> use the traffic laws of each country or specific presets, plugins and
> styles to edit them without big difficulty, too.
> What can we do? What value has to prevail in OSM: the specific or the
> verbose? What can we do if we want to maintain both of them?
> What do you think about that? With which tags would you separate that
> values?

It seems really obvious that normalized osm words and CC:codepoint are
different things and belong in different keys.

Part of the point is that renderers (including routing engines) and
humans want to see a value that can be interpreted regardless of country
and without having to know that country's laws.

I consider putting codepoints into traffic_sign abuse, and while the
name doesn't matter, traffic_sign_codepoint= seems reasonable, to make
the point that it is the other kind.

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

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

[Greg Troxel]

Minh Nguyen  writes:

>> It's a slippery slope, and pretty soon \pi is 3.
>
> Poor Indiana. ;-) The definition of the foot would apply to the ' and
> ft abbreviations in every context, not just the ele=* key, so I'd
> suggest considering it separately, probably without the formality of a
> vote. The main unit symbol listing has come together more informally
> over the years. [1]
>
> Sooner or later, OpenHistoricalMap will have a lot of fun with this issue...
>
> [1] https://wiki.openstreetmap.org/wiki/Map_features/Units

A fair point that it's generic, and while that page does not say
"international foot", the conversion given is the modern/interntional
one.  So I think we're all set.

I would expect elevations in feet in NGVD29 to be in survey feet.  It's
not so much a special feet for surveying as the definition before the
50s, and too hard to change for horizontal control, while ignorable just
about everywhere else.  But, the difference is tiny, and elevations in
NGVD29 are more or less by definition of poor accuracy anyway.

I'm glad to see the usual suspects are still here!


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

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

[Greg Troxel]

Minh Nguyen  writes:

> Vào lúc 19:50 2024-01-27, Brian M. Sperlongano đã viết:
>> Uh so I did the math, and unless I've got this wrong, the difference
>> between survey feet and international feet for tagging, let's say,
>> Mount Everest, is less than seven one-hundredths of an inch.  So I'm
>> really not even sure why we're discussing it beyond the fact that
>> we're all nerds about this sort of thing.
>
> You got me. :-) The actual proposal doesn't mention the foot's two
> definitions at all, and so far I'm planning to keep it that way.

I think it's important to be definitionally correct, even if it doesn't
really matter.  It's a slippery slope, and pretty soon \pi is 3.

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

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

[Greg Troxel]

Minh Nguyen  writes:

> This proposal is using the ' symbol instead of the deprecated ft
> symbol, but in practice almost every data consumer understands both
> symbols equally. If someone feels strongly that ft would be less
> error-prone, I'd encourage them to start a new proposal that would
> affect other keys as well.

I'm ok with that, but I didn't figure it out from the link.

>>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, no one has ever explicitly tagged a measurement in
> survey feet (as opposed to a survey _on_ feet). As you point out, it's
> a very small difference. I mainly brought it up because I didn't want
> to have to simultaneously propose new unit symbols, which would
> require developer intervention. Some imports have introduced very
> high-precision values, but this is probably not a good practice to
> optimize around.

Agreed; I just meant to add a parenthetical clarification.

> You can definitely count me among those whose eyes glaze over whenever
> datums enter the conversation, as they always seem to when discussing
> nationwide imports these days. I'm glad we have folks like you who get
> it.
>
> Hopefully it's OK to leave these issues out of the proposal's scope; I
> fear it would quickly sink the proposal because we don't have a very
> good handle on the datums that have already been used all over the
> map. We're only now starting to clean up incorrectly transformed GNIS
> features and TIGER boundaries from, what, 14 years ago, to say nothing
> of more recent imports.

Yes, I think it's fine.  All of those issues apply equally to elevations
in meters, and using feet does not make them any worse or harder

>>Practically, people type in numbers from a sign, and this sign was
>>probably copied from some earlier sign, and may be in some ancient
>>datum, and may have been erroneous.   This proposal has no bearing on
>>that, and that's ok.
>
> Yes, I'm very much approaching this key from the perspective of
> documenting what the world says about itself on the ground. More
> mission-critical applications of this elevation data would have their
> work cut out for them...

Sure, but we should be careful because we do not as lat/lon coordinates
of objects the values chiseled in stone on the store front.  We use
measurements and our best guess based imagery, etc.  Elevation 100%
should be a similar process of the mapper's best estimate of the true
value.  Writing down a sign value is acceptable as an approximation of
that.

This is entirely different from using a signed name in the name tag.
The the self-labeled name is by definition the right answer.  With
elevation, it is not.

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

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

[Greg Troxel]

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.

  There is a much more serious problem in that few seem to understand
  that elevation is only meaningful relative to a vertical datum.  OSM
  documents WGS84.  Even fewer understand that this is a mess because
  WGS84 is an ensemble containing a low-accuracy member
  (WGS84(TRANSIT)), and that the only reasonable interpretation is that
  data should be expressed in the most recent realization.

  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.

  Practically, people type in numbers from a sign, and this sign was
  probably copied from some earlier sign, and may be in some ancient
  datum, and may have been erroneous.   This proposal has no bearing on
  that, and that's ok.

  

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

Re: [Tagging] Postal verses locational addresses

[Greg Troxel]

Warin <61sundow...@gmail.com> writes:

> On 12/9/23 03:57, Greg Troxel wrote:
>> The fundamental issue is that there are postal addresses and what might
>> be called "civil addresses" or "physical addresses" ('locational' I
>> understand but is not normal English usage).
> I could not think of a better descriptive 'word' for what I wanted to
> express.

Sure, didn't mean to be unkind.  I understood you and was trying to
suggest something that fits for en_GB and en_US both.  (I am an en_US
native speaker.)

>>   In the US, we also have
>> "911 dispatchable location" which is all about getting there physically
>> and is US-bureaucatic-speak.
>>
>> OSM has decided to tag postal addresses on address points.   I find this
>> an odd choice, and I think it really doesn't mean this, as companies
>> that use PO boxes are not tagged that way, but with the street address.
>>
>> The only fix I think of is to have a separate set of tags paddr: and a
>> rule that those should be set if they are different from the addr: tags
>> (which are postal).  except postcode, which is a postal-only.
>
> Err the zip/postcode in the UK is a (small) physical area. It is used
> by truck delivery drivers to enter into their GPS to find a route to
> the delivery point. See
> https://en.wikipedia.org/wiki/Postcodes_in_the_United_Kingdom

In the UK, yes.  In the US, "zip codes" are not technically a physical
area, even though they act like one and most people don't understand
this.  They are a set of delivery addresses.  They do not always line up
with civil boundaries.  You can be in TownA and have a postal address
that has TownA in it but the zip of TownB because that carrier route
handles your mail.

And, addresses on property deeds, etc. do not have zip codes.  They are
not part of "civil addresses", only mailing.

I am unclear on whether a UK postcode is part of one's civil/legal
address.

> Possibly the OSM addr thinking is based on the UK where the postal
> address is the physical location?There maybe exceptions to this in the
> UK too?

Likely.  Everything in OSM was/is based on UK thinking, and sometimes
that is ok and occasionally it is not.

>> All in all I think it was a mistake to tag postal addresses.  Maybe we
>> can just redefine addr:foo to be the physical address, except
>> addr:postcode is the code assigned by the government/monopoly delivery
>> service.  And then add some mailing address tag for things that need
>> them.
>
> I do think OSM is more of a location data base. Imaging a personal
> visit to these places with addresses quite some distance (miles) away
> .. nasty. And some of them have more than two locations...

Agreed.  And there is also the issue where a physical place has an
address in the normal "drive to it" or "911 dispatchable location"
sense, but has a PO Box in another state that you write to in order to
interact by mail.  IMHO it would be completely unreasonable to tag this
PO box address on a store node as addr:foo.   If somebody wanted to add

  addr_mailing_not_physical:foo

I wouldn't like it but I couldn't say it was super wrong.

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

Re: [Tagging] Postal verses locational addresses

[Greg Troxel]

The fundamental issue is that there are postal addresses and what might
be called "civil addresses" or "physical addresses" ('locational' I
understand but is not normal English usage).  In the US, we also have
"911 dispatchable location" which is all about getting there physically
and is US-bureaucatic-speak.

OSM has decided to tag postal addresses on address points.   I find this
an odd choice, and I think it really doesn't mean this, as companies
that use PO boxes are not tagged that way, but with the street address.

The only fix I think of is to have a separate set of tags paddr: and a
rule that those should be set if they are different from the addr: tags
(which are postal).  except postcode, which is a postal-only.

It is further messy that there are postal addresses, and then addresses
that Fedex, UPS, DHL etc. deliver to.  In the US  mostly the post office
(USPS) maintains a database and people verify/match against it and those
are used as legitimate physical delivery addresses by non-USPS carriers.

All in all I think it was a mistake to tag postal addresses.  Maybe we
can just redefine addr:foo to be the physical address, except
addr:postcode is the code assigned by the government/monopoly delivery
service.  And then add some mailing address tag for things that need
them.

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

Re: [Tagging] Streets with gradually increasing widths

[Greg Troxel]

Kashish via Tagging  writes:

> Now I'm thinking of documenting two solutions on the wiki -
>
> 1. width:start=*/width:end=*, optionally with width=* for the minimum
> width of the street, and with a word of warning about the results of
> editors splitting ways.

"optionally with width=* for the minimum" is not ok.  That encourages
people to just use the other tags, and they will be ignored, leading to
a way with no defined width.  Compatibility with existing data consumers
is hugely important, thousands of times more so that your expanded
tagging.

So if you want to proceed, please leave the existing text, and then
create a proposal for new tags that says clearly "the width= that gives
the min width for the way must be present".

> 2. Splitting the way and using existing width=* etc tags on the
> segments, and noting the benefits of this approach.

That is documenting what I view as long-existing practice, so that's fine.

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

Re: [Tagging] Streets with gradually increasing widths

[Greg Troxel]

Timothy Noname  writes:

> I've always thought actual measurements should be added to an individual
> node and the minimum width should be on the way, splitting the way at
> significant changes.

This is an awesome suggestion.  It allows recording as much data as
anybody wants to measure, and doesn't add any needless complexity.



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

Re: [Tagging] Streets with gradually increasing widths

[Greg Troxel]

BLUF: I strongly object to changing width= from minimum to average.

Kashish via Tagging  writes:

> I recently purchased a laser distance meter, primarily for measuring
> road widths so as to allow better routing for various vehicles. In the
> process, I discovered that some roads can have a gradually
> decreasing/increasing width. The wiki does not cover such situations,
> so I brought it up in the #osm IRC channel.

That's very cool that you are actually measuring width!

> Some mappers (and the wiki) advise that one should map the width at
> the narrowest part of the street. However, this is not always
> desirable. If a vehicle can enter a street up to a certain point to
> reach an address or POI, sufficiently smart routers should (given
> sufficient data) route it along the street accordingly.

True.

> For such situations, I liked pbnoxious' suggestion of using the keys
> width:start and width:end, applied to the concerned way. In addition,
> pbnoxious suggested using width=* to specify the mean/median width. By
> splitting ways and using width:start=* + width:end=*, complex changes
> in width can be mapped.

As always, I like to ask who the data users are and what suits them, and
to think about tags in terms of how they would be read.

My state government has a dataset of roads that includes width.  Their
approach roughly appears to be to split the segments when the width is
substantially different.  This is not particularly different from
splitting when the speed limit changes, or the surface type.

How often are you finding roads that have a linear decrease in width,
such that you would need a start/end pair to represent it?   If you
instead said "split the way when it changes by a meter, and tag width=
for the min", how often does that happen?

Wouldn't it be simpler for everyone to have that increase in split ways
and not have new rules that every router has to implement it?

Or is this really common?

I can see irregular widths, but your proposal doesn't help with those,
only when the width can be well approximated by a line.

> A question was raised about how such a width should be
> rendered. Personally, rendering a gradually increasing/decreasing
> width is not too important for my uses, but can be nice to have in
> more detailed renderers.

Sure, I think that's the least important part.

> If there are no objections, I'lpl add a section about the above to the wiki.

I strongly object, because a data router that uses just width will
conclude that the way is usable when it is not.   It is a basic
principle of tagging that data consumers that read the basic tags rather
than the more complicated tags that are less used should not be misled.

If you want to keep "width=" as the minimum width over the way, and then
add the other things, then I don't see that as really helpful in the
grand scheme, but I don't see it as harmful.  I expect very few
circumstances where it is appropriate, almost no one to tag them, and
almost no routers to implement it.

Have to you talked to people that implement and maintain routers?  What
is their opinion about adding support for this proposal to their
routers?  What did they say about redefining width to be average rather
than minimum?

Have you prototyped a router that does this?  How did it work?



I think it would be great if you represented width better using the
existing scheme, and experimented with width-sensitive routing.  I think
it would be fine for you to add the new start/end tags yourself on some
roads near you and experiment with that.  So I don't mean to sound all
negative.  I just don't see that we have evidence that this is going to
make sense in the overall ecosystem.

Greg

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

Re: [Tagging] [RFC] Feature Proposal - Cell Phone Reception

[Greg Troxel]

Also, from a practical point of view, data points about cell service are
not going to have any relationship to other items in the osm database.
And, they are likely going to be semi-automatically collected, and
people probably want contour lines that are generated from points, not
the points.  There will be conflicting data, and need some averaging.
The OSM data model of a single value at a location just doesn't fit how
one would deal with this data.

Once there is a database with upload and extraction for this data -- and
it seems like there is -- it does almost no good to to anyone to merge
it into OSM, and certainly not enough good to overcome the trouble it
causes.

I note that OSM does not have elevation contour lines.   I am not
advocating adding them, but that information is far easier to deal with,
more clearly defined/measurable, and more useful to many, than cell
service data.

Thus, I see ading cell service information to OSM as basically out of
the question.

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

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

[Greg Troxel]

Minh Nguyen  writes:

> I for one support the drawing of hyperblobs.

Thanks; I was pretty sure I was not alone.

> If we look at our existing repertoire of shop=* values, it's pretty
> clear that we aim for plain language when possible, although we do
> sometimes fall short.
>
> shop=curtain, not shop=window_treatment
> shop=doityourself, not shop=building_material_and_supplies
> shop=furniture, not shop=home_furnishings
> shop=gift, not shop=souvenir or shop=novelty
> shop=haberdashery, not shop=needlework_goods
> shop=second_hand, not shop=used_merchandise
> shop=shoes, not shop=footwear
>
> Industry classification schemes are a better source of inspiration for
> POI classification than individual laws. Unfortunately, the wiki's
> NACE (Europe) [1] and NAICS (North America) [2] correspondence tables
> reveal a lot of gaps in our tagging schemes, but they do give a sense
> of which terms would be well-recognized and maybe how to classify
> them. For what it's worth, the Sporting Goods Retailers subindustry in
> NAICS includes "gun shops". [3]
>
> [1] https://wiki.openstreetmap.org/wiki/Category:NACE
> [2] https://wiki.openstreetmap.org/wiki/NAICS
> [3] https://www.census.gov/naics/?input=gun+shop&year=2022&details=459110

I should be clear that I think we have settled on "shop=gun" and not to
care about e.g. air rifles being different.  I think that's a good
outcome.   My point was just that people seem to be overly fixated on
law in a way that is not similar to how everything else is approached.

Do people realize that in my state, and likely everywhere else, that you
need a special license to sell milk/dairy?  And that there are likely
pages of regulations that define exactly what that means, and how it
must be pasteurzied?  But OSM doesn't care; it's just a food item, and
that's how it should be.


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

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

[Greg Troxel]

Mateusz Konieczny via Tagging  writes:

>> So I find the attention to legal definitions in the present discussion
>> bizarre.
>>
> That is a different situation. 
>
> shop=medical_cannabis would be analogous to shop=firearms
> as it is a legal term (if I understood it right) with variety of differences
> across places and wild changes in its definition over time,

Again this is paying too much attention to the law.

shop=medical_cannabis is

  a shop where you can buy cannabis, but only if you have some kind of
  medical permit/prescription/paperwork

It's true what kind of papers you need varies by jurisdiction, but that
is not relavant to drawing a boundary around the concept.

This is in fact the same difference between

  shop=chemist
  amenity=pharmacy

The first just sells stuff and the 2nd you need paperwork.  Which things
are in which category is an arbitrary matter of law that varies across
time and space.

> and therefore a poor terms to use in OSM (like shop=firearms
> apparently)

"Firearm" is first a technical term, and secondarily (and relatively
recently) a legal one.  The reason that's not a good word to use in a
tag is that many people are 1) unclear on normal usage 2) conclude out
of thin air that we need to worry about legal definitions, rather than
deciding how to draw a hyperblob around some sort of thing that occurs
enough in the real world to be worth naming.


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

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

[Greg Troxel]

Martin Koppenhoefer  writes:

> sent from a phone
>
>> On 24 Jun 2023, at 00:29, Minh Nguyen  wrote:
>> 
>> But if we focus too pedantically on legal status at the expense of
>> common sense, then we've reinvented designation=*, and mappers and
>> data consumers have to find yet another key to express what could've
>> been in highway=*.
>
> oh yes, absolutely, if legal status and common sense/reality are not 
> congruent we should record both.

That isn't that case.  What's going on is that people want to pay
attention to legal definitions of words (whose proper scope is only
reading the law).  Describing reality is actually quite straightforward.

For example:

  https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcannabis

In Massachusetts, as in many US states, such activities are permitted
under state law, but are absolutely prohibited under Federal law.
Despite this, many people, whether due to a desire to deceive or a lack
of understanding, say things like "marijuana is legal in Massachusetts" :-)
However it is not being enforced.

But none of that matters to OSM; if there is a shop that is selling
cannabis, then it is tagged as such, regardless of whether it is a
federal crime but not a state crime, a crime under neither legal regime,
or a crime under both.  And it doesn't matter exactly how either regime
defines what is or is not unlawful.

So I find the attention to legal definitions in the present discussion
bizarre.


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

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

[Greg Troxel]

On June 23, 2023 1:50:58 PM UTC, Martin Koppenhoefer  
wrote:
>Am Do., 22. Juni 2023 um 14:41 Uhr schrieb Greg Troxel :
>
>>
>> Suppose in some other country, bakery is a term that means a shop that
>> primarly sells sausages.  We wouldn't say that this should be
>> amenity=bakery.
>
>
>
>this is why we have agreed to use English words. A "bakery" in English is a
>place that primarily sells bread (and other baked stuff, at least
>generally), so if some other language used the same letters for a word
>"bakery" which had a different meaning, it could not be the one intended in
>OSM because we use English.

English varies by country and sometimes we can't understand each other.  
Changing semantics by regional English is no more reasonable than changing by 
other language word collisions.   My point is that a tag defines a semantic 
concept and that we should strive to have it mean that concept everywhere.   
That is the point, so that data consumers can use it.

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

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

[Greg Troxel]

Martin Koppenhoefer  writes:

> sent from a phone
>
>> On 21 Jun 2023, at 15:52, Greg Troxel  wrote:
>> 
>> It is absolutely the wrong thing to say that shop=firearms means "a shop
>> that sells whatever the local law means by firearms".   This is a
>> general principle in OSM that we define something and then expect
>> mappers to use the OSM definition, not local language.
>
> I am not sure I can subscribe to this. Generally our tags are used
> when the thing meets the local expectations of “such thing”, e.g. an
> amenity=cafe or amenity=pub in England is probably different from
> places with such a tag in Germany. Or a shop=bakery in England will
> not necessarily sell the same kind of bread than one in France.

Of course it won't have the same kind of bread.  But it will still be a
shop that sells primarily things that have been baked, pastry and bread.

Suppose in some other country, bakery is a term that means a shop that
primarly sells sausages.  We wouldn't say that this should be
amenity=bakery.

I think it is

> There is a point where the differences are so big that we decide to
> introduce a new tag (or subtag), but in a case like the arms shop I
> believe the most likely answer for OpenStreetMap is actually "a shop
> that sells whatever the local law means by firearms",

If we pivot to shop=gun, then we have a broader category, and we don't
need to care about law.

With your definition, a shop in my state that sells rifles only would
not be shop=firearms because under local law "firearm" means "handgun".

Note that it's odd to worry about law, and it's wrong to let that drive
tagging which should be independent of government.  Normally shop=foo
defines a concept and it applies whether or not there are any laws about
foos.

> just like a
> highway=motorway is “a highway that the local law means by motorway”.

I don't think that's true at all.  highway=motorway is a road that

  has multiple lanes
  is limited access
  has not at-grade intersections

with the usual "tiny violation doesn't disqualify" caveats.

The word "motorway" is just not used in the US.  Not by people, not in
law, that I've ever seen.   The formal terms are "limited access
highway", which is close but does not require multiple travel lanes.
And then there is "Interstate highway" which is a route signing thing,
which has associated construction standards.  But something can be an
Interstate without meeting them, very very rarely (I hear this about
Alaska).


The whole point of the map is to be used, and for that to be sane, we
need consistent semantics across all countries.   That means not
aligning to local words exactly, and certainly not to legal definitions,
which are arbitrary and sometimes bizarre.

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

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

[Greg Troxel]

"Brian M. Sperlongano"  writes:

> On Thu, Jun 22, 2023, 8:08 AM Illia Marchenko 
> wrote:
>
>> But "freeway" is de facto equivalent of motorway, right?
>>
>
> Freeway is a colloquial term that's only used in some parts of the country
> and only signed as such in some states and often inconsistently. I assure
> you that the on the ground situation is far more complicated.

Agreed.  When someone says that something is a "freeway", there is no
basis to be sure what kind of physical road it is.

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

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

[Greg Troxel]

Graeme Fitzpatrick  writes:

> On Tue, 20 Jun 2023 at 22:11, Greg Troxel  wrote:
>
>>
>>   an air rifle is not a firearm, in English, because there is no
>>   combustion
>
> Unfortunately, in Australia at least, air rifles are actually officially
> classed as firearms! :-(

Sure, that (and warins') are examples of a law defining a word to mean
something different from what the word ordinarily means.  This happens
all the time for all sorts of things, and I don't think we should let
that drive our tagging, which should be about the normal meaning of the
word.

But, if someone applies the tag to a shop whose primary product is air
rifles, regardless of our label, that's not a bad thing, compared to the
other tags someone might choose.

It is absolutely the wrong thing to say that shop=firearms means "a shop
that sells whatever the local law means by firearms".   This is a
general principle in OSM that we define something and then expect
mappers to use the OSM definition, not local language.

As a valid and further crazy definition, in Massachusetts law a
"highway" means any legal road (one with an easement to the public that
includes vehicles).  Almost no one in MA knows that, and would think
highway means either what OSM calls motorway or maybe also trunk, or
would think it means "a road with a state or federal route number".  We
don't It is amusing that OSM tagging is "highway=foo", and it is perhaps
a historical artifact of English law and naming.

If people are saying that the OSM definition for shop=gun/shop=firearms
should be "a shop that primarily sells firearms, by which we mean
devices that emit a projectile via combusion, as well as via compresed
air", because drawing a line around that represents a cluster that both
  - exists in the real world
  - captures an idea that large numbers of people are likely to find
meaningful

that's fine.

I find that tagging discussions tend to be disconnected from considering
the utility of tagging for data consumers.  That is the point, and I
think when that is the main consideration then it will also be
straightforward for mappers.

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

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

[Greg Troxel]

Marc_marc  writes:

> so now that we have a documented tag shop=knives,
> how to tag a shop that sell knives and arcs ? shop=knives;arcs ?
> of course not
> when we have found the right term for this shop, the previous case
> could have been handled in the same way with details in a secondary tag

the basic issue, which you seem to be avoiding, is that any actual shop
sells a variety of things.  We don't (can't and shouldn't) enumerate all
of them; OSM is a map, not a precise inventory database.

What we are doing is agreeing on a set of labels for objects which exist
to some significant extent that people using the map will be able to
grasp those objects and use them for either understanding what is
present, analysis queries, or search.

The point here is not that stores selling knives might sell something
else.  It's that there are a large number of stores whose *primary*
point is to sell knives, and naturally the sell other things that people
who are interested in buying knives might also buy, when selling those
additional items is not burdensome.

This is exactly the same as other stores.  Liquor stores for example
sell non-alcoholic beverages often used for consumption at parties, or
mixers.  They will ~never sell milk, because that requires stock
management for expiration and usually a separate license, which is a
different business operations plan.

Similarly a gun store might sell some outdoorsy or self-defense-ish
knives, because it's easy to stock.  A knife store won't sell guns,
because that's a different level of licensing and paperwork, here, and I
suspect most places.

As for stevea@'s comment about gun vs firearm, I disagree.  firearm is
more technical/precise and gun is less formal.  Yes, the law defines all
sorts of things, often in ways that are contrary to English, and in law
things mean what the law/cases say they mean, not what they normally
mean.  Two examples:

  an air rifle is not a firearm, in English, because there is no
  combustion

  In Massachusetts, firearm in law means handgun.  This is just bizarre
  and totally contrary to English usage, but it's how it is.

We certainly shouldn't encode in tags legal definitions that are
contrary to normal usage.  And of coures, an OSM tag means what we say
it means -- but good practice is to choose words so that mostly reading
the tag causes people to jump to the right conclusion.

I do agree with stevea@'s discussion of singular/plural.   It seems
obvious that each shop value should exist in one form or the other.

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

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

[Greg Troxel]

Marc_marc  writes:

> Does it make sense to create a primary tag for each type of weapon?
> I find it very fragmenting, especially as there will inevitably be
> shops selling 2 items with different primary tags, which merits a
> secondary tag and not a shop=guns;knives

We have grocery and bakery.

Stores that sell firearms and stores that primarily sell knives are
basically distinct entities, even though there is commonality.   Knife
stores are typically either high end kitchen only, or generalists with
kitchen  knives and artisanal knives, along with practical outdoors-type
knives.

>> Create shop=firearms page, describing shop=gun and shop=guns as
>> duplicates of it.
>
> if it's a duplicate, we don't need a dedicated page,
> a redirect is enough.
> but I'm not en english native.

In English, the adjective for the shop tends to be singular, when that
adjective is a noun.  The plural just sounds funny.  For example we have
"car dealer", "grocery store", "grocery store", "cell phone store", etc.
So I am fine with shop=guns being viewed as a typo for shop=gun.

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

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

[Greg Troxel]

Graeme Fitzpatrick  writes:

>> As possible solution, *shop=weapon*
>
> Sorry, but speaking as a recreational shooter, & on behalf of all others,
> we find the use of the term "weapons" for our chosen sporting tools more
> than somewhat offensive - recreational shooters don't use weapons, the
> military does!

In the US, even in Massachusetts, usage is "gun store" (store US vs shop
UK, as usual) if being casual, and "firearms" if being formal.  I have
never heard any (civilian) store be desribed as a "weapons store".
That's a word I heard only in the context of defense contractors and
usually foreign military sales.

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

Re: [Tagging] [Voting] Level crossing train horn usage

[Greg Troxel]

Clay Smalley  writes:

> Voting has started on the proposal to introduce the key crossing:whistle=*.

I find the "optional" to be strange.  Regardless of a "whistles shall
not be blown at this crossing", obviously an engineer can use the horn
at any time if a danger exists.  The bit about work crews is more
complicated, and I can't really tell what the tag means.  Surely there
are actual rules for other than emergency situations, and I really doubt
the rule says "whistle should not be blown unless you feel like it".
And surely there are random other rules that say "in unusual situation X
you must do Y" and we don't therefore say "We can never say Y does or
doesn't happen and therefore have to say it's optional."

> Please vote on the wiki page
> https://wiki.openstreetmap.org/wiki/Proposal:Level_crossing_train_horn_usage

I did, and yes because I think this is better than were we are despite
the above.

However, the instructions said to just add a vote, implying the
user/talk would be autopopulated, and then it wouldn't.  Just a random
comment not really directed at you.


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

Re: [Tagging] road accident memorials

[Greg Troxel]

Anne-Karoline Distel  writes:

> I would like to be able to differentiate memorials for road traffic
> accidents from other memorials along a road, because I'd really like to
> know how many there are. Sometimes, it will be difficult to say without
> local knowledge whether it was that or maybe if the family uses
> "accident" as a euphemism for suicide, of course.

In general I don't think it's possible to  separate "accident" from
"suicide" fully for "motor vehicle crashes", just as it isn't possible
to separate "overdose" from "suicide" for opiod deaths.

I think OSM has to tag what is, and not evaluate things that can't
really be evaluated.  In the northeast US, you find crosses along the
road, often simple white wood that do not necessarily endure more than a
year or so, and occasional metal permanent ones.  And, often a cross
with flowers that is there for 1 to several months - the same thing, but
sometimes too brief to end up mapped (not because it shouldn't be, just
because it has to last long enough for someone who maps these to notice
and get to it).

> I don't know if wayside_cross is used for this in some instances, for
> example, which IMHO it shouldn't be.

I don't follow.  If there is a cross by the road, are you saying that
depending on the beliefs of the people that put it up about cause, then
it should or shouldn't be tagged wayside_cross?

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

Re: [Tagging] road accident memorials

[Greg Troxel]

Anne-Karoline Distel  writes:

> I would say that memorial:cause=traffic_accident would leave the options
> open whether the victim intended to die or not.

OK but IMHO traffic_crash is better.  'accident' is an assertion of no
blame, and there are messy issues of bad luck and negligence.   crash is
objectively what happened.

>>> I don't know if wayside_cross is used for this in some instances, for
>>> example, which IMHO it shouldn't be.
>> I don't follow.  If there is a cross by the road, are you saying that
>> depending on the beliefs of the people that put it up about cause, then
>> it should or shouldn't be tagged wayside_cross?
>
> A historic=wayside_cross does not mark the spot; it is not left in a
> location where someone is buried or died. It is a way to make sure the
> soul of the deceased gets into heaven easier by having passers by pray
> for the soul. You don't have to believe in it, but that's what people
> believed back then (and maybe some still do). I didn't grow up with this
> practise, but this is what Catholic people did in Early Modern Ireland.
> Not every cross by the wayside is a wayside cross. Like so many things
> in the historic category, the tagging is a bit messy. Some examples in
> my area: http://overpass-turbo.eu/s/1vVq
>
> I guess I have a topic for a new video... There are a couple more
> surviving in County Kilkenny, but I want to keep some work for the video.

I see; that's different.  In the US, one typically finds crosses by the
road where presumably the crash occured and nobody thinks it is
necessarily the location of death.   But again, do these have labels?
How do you tell?   Definitely a good thing to explain to everyone.

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

Re: [Tagging] Coach parking

[Greg Troxel]

Colin Smale  writes:

> UK native here...
>
> Looking at the vehicles, a bus would be more spartan, set up for fare
> collection, doors for speedy un/loading etc whereas a coach would
> almost always have only a single door (although some have more), be
> more luxurious, be equipped with seat belts etc. In bus-lover-land
> there are even so-called "Dual Purpose" vehicles which are in between
> being a bus and a coach.
>
> Looking at the usage of the vehicles, a bus would typically be used on
> scheduled services with a predefined timetable and (mostly) predefined
> stops, whereas a coach would often be used on "private hire"
> arrangements for one-off journeys.
>
> Having said that, there are many scheduled long-distance (city to
> city) services using coaches, and buses can also be used for private
> hire. There is also a grey area of express services with multiple
> stops along a predetermined route (I am thinking of the old Green Line
> network for example).
>
> From the perspective of traffic law, a "Bus Lane" may be restricted to
> scheduled services by a licensed operator. Even empty buses returning
> to the depot may not be allowed (as it is not on "active
> service"). Other bus lanes might also allow private hire vehicles, it
> depends on the specific legislation.
>
> My main point being that the way the vehicle is constructed may not be
> enough to determine whether it can use a bus lane or use a coach
> parking area - the circumstances of its use may also be significant.

Thanks.  That is complicated, and it's interesting how close the
bus/coach distinction is to US usage.

For this case, I  think Anne might be asking about a parking lot
(carpark) where buses/coaches can park,  such as at a tourist attraction
type place, where there is either a lot for cars and one for buses, or
one with sections.

I would expect the fare/scheduled/etc. city buses would not park out in
the world, and there would be some sort of depot that is in an
industrial area, for only the buses belonging to that agency.

so to me it sounds like amenity=coach_parking or capacity:coach is
reasonable, leaving the access rules fuzzy  (but no fuzzier than they
are in general)

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

Re: [Tagging] Coach parking

[Greg Troxel]

Anne-Karoline Distel  writes:

> [women's and parent's parking]

I can believe it exists, and it being common in .eu explains why it's in
the josm presets.
> You're right about caravans/ RVs, that should be its own tag as well and
> be rendered. For coaches, I'm in favour of amenity=coach_parking (or
> "bus_parking", if people don't like the term "coach". This might be
> easier for non-native British English speakers), since that's how it's
> done with cars and bicycles.

I would use the normal UK term, as OSM tradition is to use UK English.
It seems coach is for distance and 'bus' is used for within a city as
part of a rapid transit system.  But we need an en_GB native speaker to
opine.

In the US people do use "motorcoach" to refer to a "tour bus" when
trying to make it sound fancy, so I don't think coach_parking will
confuse most en_US speakers.  But e.g. Greyhound calls itself bus.

> On a cynical sidenote, we're gonna need "SUV_parking" soon, because they
> take up so much space.

I guess when you see it in the wild we can talk about how to map it.

In many parking garages in the US, there are spaces labeled "compact car
only" which is a way of saying "this parking space isn't long enough".
But generally there are some of those and many regular and nobody has to
think about it, and I know of no place where you can't park in the
facility at all if you don't have a compact car.

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

Re: [Tagging] Coach parking

[Greg Troxel]

Anne- Karoline Distel  writes:

> I came across a case where someone had added name=coach and name=car
> to amenity=parking, which is obviously not how we do things [snip]

I can't find it either.  I remembered that JOSM presets have a lot more
detail than the wiki.  But I checked, and I don't see anything about
"coaches" (which I think is the word in EU for what we Yanks would call
"bus", a large vehicle that can transport say 40 people).

In JOSM, I see

  spaces overall
  spaces for disabled
  spaces for women
  spaces for parents

but the implication is that these are all car-sized.

I find the women/parents strange, as I have never seen such spaces.  In
the US pretty much everywhere has restricted parking for disabled only
(one has to display a placard which is a government-issued license to
use these spaces, needs a doctor's certification, likely similar
elsewhere).  I am guessing they exist someplace though.

The tags are e.g. capacity:parent=1.

I mention this because one could easily extend and add

capacity:coach=N


Another approach would be, if the parking lot (en:GB: carpark er
coachpark) is for buses/coaches only:

 amenity=coach_parking

This also brings up "Recreational Vehicles", abbreviated RV, which I
think might be "caravan" in en_GB (in en_US, caravan refers to a group
of perhaps related vehicles traveling together).  There are often spaces
for those, as they don't fit in car spaces.




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

Re: [Tagging] Tag government equals emergency defintion

[Greg Troxel]

> The places (stations etc) where the emergency response come from would
> not be an 'office'; "An office is a place of business where
> administrative or professional work is carried out. "  e.g. lawyers,
> accountants, records,

In the US we have the concept of "Emergency Management Agency" which is
at least partly not something like firefighters/ambulance/police.  These
exist at federal, state, county and local levels.  They more or less does
three things:

  planning and training for future emergencies.  Creation of "Local
  Emergency Plan" documents.  Coordinating that lots of people have
  taken a dizzying array of classes.  Perhaps hosting classes.

  operating an Emergency Operations Center where command staff decide
  what various resources are going to do during an emergency.

  has some staff who function more or less like firefighters in that
  they go to locations where emergency services are needed and do urban
  search and rescue, swift water rescue, damage assessment


The first one is definitely office=government government=emergency.  I
think the second one is too.

A facility that houses equipment that personnel from the third case use
as a response base feels like emergency=ses_station.

Sometimes there are facilities that do all three.  There is a federal
facility in New England that is at least both 2&3 and surely they must
do 1.


Overall I think I'm agreeing with Warin here - some functions of "Civil
Defense" (as it used to be called before that was politically incorrect)
are office functions, and some are conceptually similar to fire/rescue
departments.

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

Re: [Tagging] Tagging type of ownership of a road

[Greg Troxel]

stevea  writes:

>> What is a point problem?
>
> Mmm, that IS a good question.

Sorry, I meant that the proposal is a point solution, meaning one that
applies to a very narrow view of the problem.  Basically I meant what
stevea just said.

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

Re: [Tagging] Tagging type of ownership of a road

[Greg Troxel]

Jens Glad Balchen via Tagging  writes:

> I don't know how this works in other countries. The way it works here
> is that the road owner contracts someone to do stuff, that is, to
> actually go out and put down asphalt, cut vegetation, sweep debris,
> clear snow, fix signage, etc. The road owner can split these contracts
> between different contractors. To ensure some level of continuity and
> consistency, the road owner is still the single point of contact for
> the public. The public doesn't know and doesn't care who the
> contractors are.

Sure, that happens here.  By "maintainer" I mean the entity responsible
for maintenance and how the people driving the trucks and wielding the
shovels get paid is a detail that doesn't matter for this discussion.

But, if one entity owns a road, and another entity is responsible in a
large-scale sense for maintenance, that's different.  I mean an example
like

  entity A is a homeowner's association and owns the road

  entity B is the Town Public Works and does maintenance (because even
  though the road is private all the people that live on it pay taxes
  too).

So people call B to say "this road didn't get plowed in the snowstorm
that just finished".

> So in this sense, you could say if the county owns a road, the county
> is in principle both the owner and the operator, and as the operator
> the county has contracted operational tasks to someone else. In this
> case we can safely assume that the owner and operator are the same
> entity. This wasn't historically true in Norway -- there was a
> ten-year period during which the counties owned the roads, but the
> state's road authority was the operator of those roads. This was in
> contrast to municipal roads, where the municipality was always both
> owner and operator. 

It's just like that in MA: there are roads that are "town roads" in most
sense, but the state highway department is the operator.  That's the
designation "state highway".

So really owner is not the same thing as operator.  You just can't
assume that.

> If we look at this from a data perspective, the most important
> information for us to capture /today/ is which public entity type owns
> the road and put this in the ownership tag. The specific entity can be
> derived geographically with probably 100% accuracy. If we have the
> specific entity available in a data set, we can put this in the owner
> tag. If the operator at some point in the future again diverges from
> the owner (like with the county roads), we can put that in operator.

You need to define schema for the code points in "ownership".  They are
far from obvious.

You are defining a rule that one can use "ownership" and admin
boundaries to find a value for "owner".  That's ok, but it needs to be
clearly documented.  It's easy for a human to stick something in and
think they have communicated, but it's much harder for a data consumer
to get it right.

You are defining a rule that "operator" should, if missing, be presumed
to be the same entity as "owner".  That's ok, but it needs to be very
clear.


Basically I am asking you to think through the situation more broadly,
for realities not matching yours and data consumers other than the ones
you are contemplating, and I feel this is too much of a hack for a point
problem.  Maybe you meant all of what I am asking, but it seems very
much too implicit.

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

Re: [Tagging] Tagging type of ownership of a road

[Greg Troxel]

Tod Fitch  writes:

> Greg mentions that in his part of the US the government doesn’t own
> the land along the highway. I don’t believe that is true for most of
> the US. The “right of way” includes a lot more land than just where
> the pavement is located. It includes all land that had to be modified
> to put the road in (side drainage ditches, cuts, fills, etc.). For a
> rural two lane road the pavement is likely only 24 feet wide while the
> right of way is likely to be around 100 feet wide. In rural areas
> there is often a barbed wire fence running along the boundary of the
> right of way making it pretty obvious how wide it is.

Yes, it's like that here.

However, the fee ownership of the land under the road belongs to the
abutters, usually, and there is a wide-ranging easement.  It is then
standard practice to write deeds and survey plans as if the fee under
the road is not owned by the abutter.  But there is actual ownership by
the abutter, which is usually a distinction without a difference.

To figure this out in California you'd have to find the takings
documents for roads and see if it is fee or just easement, and look up a
bunch of laws.  I have not idea how it is - just that it's surprisingly
had to get clarity.

https://malegislature.gov/Laws/GeneralLaws/PartII/TitleI/Chapter183/Section58

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

Re: [Tagging] Tagging type of ownership of a road

[Greg Troxel]

Jens Glad Balchen via Tagging  writes:

> That does seem to capture it when used on roads. I see it's mostly
> used for private roads. Is this tag use undisputed if used with
> national/state/county/municipal? E.g. do people object to it being
> redudant?

You said you didn't like operator, and I suggest stepping back and
considering the world and multiple possible data consumers, not just the
ones currently on the table.

operator= as I understand it should name the entity that is performing
whatever operations make sense for the object.   For a road, that's road
maintenance, snowplowing, debris removal.   operator should in my view
actually name an entity, not say "county".

https://wiki.openstreetmap.org/wiki/Key:owner  seems to be what you are
looking for, to denote ownership.

There seems to be an underlying assumption that the owner is the
operator.  That's likely often true.  But if you want to report issues,
that should go to the operator, not the owner.


You also seem to be looking for "national/state" type key which would
not contain the actual owner, but instead need processing by finding an
admin boundary and then a lookup table.  I'm not sure what's best but I
think we should realize that we are talking about denormalization of the
db vs not and that both approaches have issues.


In my part of the US, the situation is:

  For most roads, the land is not actually owned by the government (even
  though almost nobody understands this).  For some I'm sure it is.

  Usually there is an easement for the road.

  The government would own the pavement placed on the land :-)

  operation/maintenance would be done by a state, county, or
  municipality (admin_level 4/6/8, normally).

  In Massachusetts, Interstate highways are maintained by the state
  government, specifically the agency "MassDOT".

  Most local roads are maintained by cities/towns.

  Some roads are designated and signed "state highway" and are
  maintained by MassDOT.  Some "numbered state highway" are also "state
  highway" and MaasDOT-maintained and some are not so designated, and
  thus maintained by the Town.  Actually it is section by section.  Many
  people are unclear on this.

  There are "private ways" that are much like "public ways" execpt that
  sometimes the town maintains them and sometimes the town does not.  A
  town might do snow removal and debris removal but not pavement
  maintenance on a particular one.

  There are places you can drive which are not even private ways, such
  as service roads at shopping centers, and residential driveways.
  These are maintained by the property owners.







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

Re: [Tagging] Combining "locked=yes" with various access tags

[Greg Troxel]

Mateusz Konieczny via Tagging  writes:

> Feb 25, 2023, 19:58 by g...@lexort.com:
>
>> I am assuming --  but the wiki is unclear -- that
>>
>>  access=private, tagged on barrier=gate
>>
>> means that all modes of travel have a right of access only with
>> permission
>>
> note that some may not physically fit (even with permission your elephant
> may be still not fitting some entrances)

Good point; I was sloppy.

It implies that a mode phsyically fits if it fits on the ways on either
side of the barrier.

>>  and that
>>
>>  access=private
>>  foot=yes
>>
>> means that all modes need permission except for foot which has a legal
>> right to pass.
>>
> note that often foot=permissive would be more accurate
> but foot=yes is used
> (especially common in areas where legal right of way is rare or not
> existing and basically all =yes are actually =permissive)

A fair comment about typical.  I am thinking of a specific place in my
town where the road/track is privately owned, the gate is locked,
motor_vehicle=private but it is actualy true that foot=yes because the
town paid for a deeded easement to the public.

>> With
>>
>>  access=private
>>  foot=yes
>>  locked=no
>>
>> then it's clear that physical passage is possible for all modes.
>>
> not entirely
>
> for example if tagged on highway=footway line then  I would
> not assume that car would fit there

A fair complaint; I meant but did not say that it is possible if the
rules would say it works if the barrier were not there.


> what worse, even if tagged in say highway=service this gate may
> be not large enough to fit a car

highway=service by definition is enough for cars so if there is a gate
on a highway=service that does admit cars on both sides, but is not wide
enough for a car, then I would say this is mistagged and there should be
a short way that is path or whatever.

>>   With
>>
>>  access=private
>>  foot=yes
>>  locked=yes
>>
>> then it says that phsical passage is not possible and hence if people
>> can walk around then it needs a way representing walking around.
>>
> this one is tricky and expecting that it will be used consistently
> will not work well

True, but we have to guess at what is right, and then when users do it
wrong explain and fix.

> +1 to separate bypass ways if matching reality
> not sure how to handle cases where bypass way does not work
> (for example you can crawl under lift gate, it is allowed, you cannot get 
> around it)

I guess that's still a separate way that's path with a height
restriction, even if it overlaps.

>> I realize there have  been "but we can invent complicated bypass tags"
>> but those seem to not interact well with existing data consumers and it
>> does not seem we have consensus.
>>
> +1 though some cases where bypass way does not work are annoying

I think if we let it overlap it's ok.

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

Re: [Tagging] Combining "locked=yes" with various access tags

[Greg Troxel]

Niels Elgaard Larsen  writes:

>>I don't see it that why.  access=private, probably.  access=destination
>>means you can use a way if you decide to go someplace that you need to
>>use the way to get to.  But that's wrapped up with can you.
>
> If a way is access=destination, a router should only take you there if
> you have set your routing destination close by. And if it is your
> destination, most likely you have the necessary keys or someone will let
> you in, because you live there, you are a customer, you are visiting
> someone, you deliver something, you intend to pay for access, etc. 

access=private means if you have permission, and it is reasonable for
routers to assume permission on terminal segments.

access=destination does not require permission.  It means that anyone
has a right to use the road if they choose to travel to a location that
you need that road for.  So (applying my local rules), if there were a
highway=residential access=destination and I wanted to go to the last
house on the road and knock on the door to ask them to vote for me in
the next election, I could do that.   But if it is access=private then
maybe I don't have  a right to do that.

You are talking about a router with a human-entered destination, but the
use of OSM is much broader.  Asking the question: May I drive to this
place, just because I want to, is different than overriding private for
routing when the router is told implicitly that there is permission.



Thanks to all for the locked=no examples.   So a gate with locked=no is
a physical object you have to interact with but it does not physically
block access and should not be deemed, without access tags, to prohibit
access.


I am assuming --  but the wiki is unclear -- that

  access=private, tagged on barrier=gate

means that all modes of travel have a right of access only with
permission, and that

  access=private
  foot=yes

means that all modes need permission except for foot which has a legal
right to pass.

With

  access=private
  foot=yes
  locked=no

then it's clear that physical passage is possible for all modes.  With

  access=private
  foot=yes
  locked=yes

then it says that phsical passage is not possible and hence if people
can walk around then it needs a way representing walking around.

I realize there have  been "but we can invent complicated bypass tags"
but those seem to not interact well with existing data consumers and it
does not seem we have consensus.

Is that were we ended up?


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

Re: [Tagging] Combining "locked=yes" with various access tags

[Greg Troxel]

Niels Elgaard Larsen  writes:

> We have to accept that the tagging is never complete. And when
> surveying, it is often easier to tag "locked" than "access" (we can se
> the lock or try to open the gate but there are often no signs). So the
> tagging might reflect that we know that a gate is usually locked, but
> we do not know who can use the gate.
>
> At least "locked" should imply access=destination or private for
> routers.

I don't see it that why.  access=private, probably.  access=destination
means you can use a way if you decide to go someplace that you need to
use the way to get to.  But that's wrapped up with can you.

It's a little unclear to me what a "locked=no" gate is.  I'm guessing
it's a physical barrier than anyone can easily move out of the way.  So
arguably a barrier without locked shouldn't preclude routing, just a
2-minute delay.

Then there is 'access=' on the barrier.  This doesn't make a lot of
sense to me as in practice access is about the way, and the gate is
either:

  not locked, and not an impediment, but might keep cows in

  locked, and an enforcer of something that is alraedy true

or

  locked, and enforcing no travel when people have a legal right to do
  so.  Still, routers should not attempt to use this.


So maybe:

  foot=yes on a barrier=gate means that a person on foot can pass the
  gate (perhaps by walking around it) with minimal difficulty, such that
  the gate's presence should not affect routing

  barrier=gate locked=no (or no locked, default?) means that all modes
  may physically pass, with a mode-specific typical cost

  barrier=gate locked=yes means that all modes may not pass, unless
  there is a mode-specific foot=yes or bicycle=yes


The real problem is that locked refers to the ability to open the gate,
but many modes pass without opening, and we really care about "can this
mode actually traverse".   so locked=yes is a shorthand for all modes of
travel and we don't have a foot:can-walk-around=yes tag.   Until we deal
with that head on, this is going to be messy.

> According to the wiki, motor_vehicle=no means that motor vehicles are
> not allowed to travel through the barrier. The wiki does not say that
> having a key to the lock changes that.

agreed.


So we need three properties:

  legal right of access, perhaps only needed on ways

  physical ability to pass a gate

  is the gate locked, and if so which modes does that apply to

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

Re: [Tagging] dry swamps

[Greg Troxel]

Warin <61sundow...@gmail.com> writes:

> In which case the OSM meaning of 'wetland' must change to incorporate dry as 
> well as wet.

We need to adopt the professional definitions, not rewrite them roughly
and not really correctly.  Not sure which you are in favor of.

>>   Or if there are
>> trees and AU wetland scientists call it swamp because of the
>> every-few-years flood being dominant, I'm ok with natural=swamp.

> ? flood dominate? Most of the time the 'dry' is dominate.

By dominant I meant the factor that controls the type of plants, not
what is true most of the the time.  That's what dominant means in this
area, as I understand it.

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

Re: [Tagging] dry swamps

[Greg Troxel]

Andrew Davidson  writes:

> On 15/2/23 02:00, Greg Troxel wrote:
>> For wetlands, the definitions in the US:
>>
>> https://www.fws.gov/media/classification-wetlands-and-deepwater-habitats-united-states
>> 
>
> Which is:
>
> In general terms, wetlands are lands where saturation with water is
> the dominant factor determining the nature of substrate development
> and the types of plant and animal communities living in the substrate
> and on its surface. The single feature that most wetlands share is a
> substrate that is at least periodically saturated with or covered by
> water. The water creates severe physiological problems for all plants
> and animals except
> those that are specially adapted for such conditions.
>
>
> The same definition is used in AU:
>
> https://wetlandinfo.des.qld.gov.au/resources/static/pdf/ecology/soils/qw-soil-indicators.pdf
>
>> More or less, a wetland is characterized by being wet for at least a
>> portion of the growing season in a normal year.   And, just because you
>> don't see standing water doesn't mean the soil is not wet.
>
> I assume you are referring to this:

Yes, and I was aware of plant test above and skipped it for simplicity.
Also because it seems that if the plant species are predominately those
adapted for wet, then surely there must often be water.

> If neither plants nor soil is present, then the wetland identification
> must be made strictly on the basis of hydrology. In this case, the
> substrate should be “saturated with water or covered by shallow water
> at some time during the growing season of each year.” Cowardin et
> al. (1979) fully realized how vague this hydrologic definition was
> but, given the lack of detailed hydrologic data from the diversity of
> wetland types, geologic regions, and climatic regions of the U.S.,
> there was no
> way they could have been more specific.
>
> This is a rule of thumb that is used if the plant and soil
> characteristics are not present (or if the information is not
> available). It is a rule based on wetland data from the US. The
> Australian ecosystem is far more fragile and inundation less often
> than annually is enough to make it the dominant factor.

So, if you want to say that wetland scientists in AU consider specific
areas that do not have soil or plants but which are flooded every few
years to be natural=wetland, that sounds fine to tag it as such.  It
won't be swamp, because that's a wetland with trees.  Or if there are
trees and AU wetland scientists call it swamp because of the
every-few-years flood being dominant, I'm ok with natural=swamp.

I do not think we should invent a new tag "dry_swamp", as that's drawing
a distinction that seems not found in the professional literature.

If there is some idea from the literature to adapt, that's ok too, but
the hierarchy of OSM should follow the hierarchy of the literature
(swamp first, subtype is less than annual, to make something up).

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

Re: [Tagging] dry swamps

[Greg Troxel]

Warin <61sundow...@gmail.com> writes:

> The ‘dry swamp’ has no apparent way to tag it. These will not be found
> in Europe, just as you don’t find deserts there.
>
> They have occasional water, not seasonal, not yearly but, say, between
> 5 to 20 years they have water. As such they do not satisfy the OSM
> swamp definitions at all.

They do not satisfy the science definition of wetland either.

> See https://theconversation.com/why-a-wetland-might-not-be-wet-103687
> for more on their characteristics, at least in Australia. OSM has
> access to a imagery source in Australia that maps them, so OSM has a
> legal source for them. What is needed is a tag for them, say,
> ‘natural=dry_swamp’???

It sounds like "Place with trees that is known to flood occasionally"
which is natural=wood (if natural).

> There are ~ 4,000 of these ‘natural=mud’ mapped so far that are in
> fact ‘dry swamps’. Note that the tag natural=mud  wiki says “This tag
> should not be used for areas with intermittent water cover which are
> water covered or completely dry most of the time.” So this tagging is
> incorrect as they are dry most of the time…


As always, I think OSM should look to the professional literature and
adopt their definitions, exactly, rather than trying to invent
categories.

For wetlands, the definitions in the US:

  
https://www.fws.gov/media/classification-wetlands-and-deepwater-habitats-united-states

A broader perspective:

  https://www.sciencedirect.com/topics/earth-and-planetary-sciences/wetland

I am unclear on if "Cowardin" is really an international thing; I more
or less expect it to be as that's how scientists do things.

More or less, a wetland is characterized by being wet for at least a
portion of the growing season in a normal year.   And, just because you
don't see standing water doesn't mean the soil is not wet.

So to me, "dry swamp" is fairly clearly not a wetland and the first
thing is to get a real science opinion about whether it is wetland or
not.  A quick search does not support the idea that the term is used in
English at all.  I would expect a mapper.au could just call their
government, the part that does conservation and wetland rules and talk
to someone.

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

Re: [Tagging] [Talk-us] New MapRoulette Challenge - Add Surface to Highways

[Greg Troxel]

"Brian M. Sperlongano"  writes:

> I am asking for TomTom to be straight with us and answer why they're so
> gung ho about missing surface tagging on motorways. Despite the negative
> reaction in the US, it seems that they're intent on spamming this nonsense
> challenge worldwide, and they *refuse to answer why they're asking the
> community to focus on this*.

I also asked "please explain how you use osm data and how that is
compliant with the license", and didn't see an answer.

Perhaps OSMF-US should approach TomTom management (and other companies)
to talk about the general issues of how companies interact with the
community.

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

Re: [Tagging] service vs. unclassified, conflicting definitions

[Greg Troxel]

Warin <61sundow...@gmail.com> writes:

> I know of a road built for coal trucks by the coal firm tagged as
> 'unclassified' yet it is a 'private road'  not used by cyclist nor
> pedestrians. The road standard is probably above that of
> 'unclassified'. It runs from a coal mine to a power plant, both are
> winding down in operations.

That's an unusual case, but I would agree that unclassified and
access=private is fair.


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] service vs. unclassified, conflicting definitions

[Greg Troxel]

Warin <61sundow...@gmail.com> writes:

> On 1/10/22 20:25, stevea wrote:
>> Makes sense to me, too, Greg.  I don't know if it helps or hinders
>> wider understanding, but I understand what Greg is saying here, and
>> while his perspective is "Eastern USA" (and mine is "Western USA"),
>> these don't seem far apart or even different at all, and there may
>> likely be a further possible refinement here:
>>
>> "unclassified" roads, as a "real legal roads" are "in public," and subject 
>> to traffic rules/laws/ordinances, and
>>
>> "service" roads, as "private driveways, parking lot aisles and other
>> roads not in the public grid of road network" are "on private
>> property" and not (as) subject to traffic rules/laws/ordinances.
>
> That would mean a crash on them would not have road laws applied to it
> .. so the insurance companies could not attribute blame based on road
> laws.. that could get very difficult in court.

This is not an actual problem in practice (mass.us).  Well, traffic
laws and enforcement/liability *are* a mess, but they aren't
differentially messy in this case.

It is true that you have to file an accident report with the police on
real roads, but not for crashes in parkings lots and driveways.   But
liability is from tort law which doesn't care where.  And criminal law
about negligent operation (similar for drunk driving) says:

  https://malegislature.gov/Laws/GeneralLaws/PartI/TitleXIV/Chapter90/Section24

  Whoever upon any way or in any place to which the public has a right of
  access, or any place to which members of the public have access as
  invitees or licensees, operates a motor vehicle recklessly, or
  operates such a vehicle negligently so that the lives or safety of the
  public might be endangered

which means business/shopping driveways/lots count.

But what the law says is not relevant in how we tag.  I didn't really
mean "service is not subject to law".  I meant that here we have a
concept of a legal road (referred to by "way" above) and places where
you can drive which are not legal roads (referred to by the other text).

> I know the old definition of our 'motor traffic act' said something
> along the lines of a road is 'any place open to, or used, by the
> public' .. that includes private driveways, car parks etc etc as they
> are 'used by the public'.

Sure.  It is not surprising that law prohibits negligent behavior on
places the public normally goes, even if that is not a legal road.

But there is still a difference legally in  many places.  Even if not, I
still think that unclassified for things that feel like actual roads and
service for things  that feel like drivways and parking lots, makes
total sense.


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

[Greg Troxel]

Warin <61sundow...@gmail.com> writes:

> On 14/10/22 23:40, Greg Troxel wrote:
>> Warin <61sundow...@gmail.com> writes:
>>
>>> On 13/10/22 02:42, Evan Carroll wrote:
>>> In some places the local authorities have lots to do with landuse and
>>> everything to do with zoning. To the extent of taking people to court
>>> and forcing them to stop their present landuse.
>> Of course they do.  But you are blurring two things:
>>
>>OSM maps actual land use.  OSM does not map zoning.
>>
>>Governments use zoning to control landuse.  So after they have
>>controlled there is an actual landuse to map.
>>
>> So the government using force to control landuse is not something we
>> map.  Given that, I don't see what point you are trying to make.
>
> OSM does not map illegal activity.

Taken to the extreme, perhaps, but we are talking about things that are
done in the open and clearly visible to all.  Landuse, by its nature,
occurs on timescales of months or longer.  It is obvious that the
authorities are just as aware of landuse as a local mapper.

Applied to this discussion, the concept of declining to map landuses
that are contrary to zoning is totally ridiculous.  Just in case you
aren't trolling, I'll substantively reply.

Landuse issues in the US are civil not criminal, and I suspect that's
similar in many places.  The edges of what is permissible under zoning,
or under contractual land use rules, is fuzzy, and difficult to figure
out, even for people that understand the zoning rules.

I'm simply stating the obvious: if there is a shop selling things,
clearly visible to anyone, it's entirely appropriate to put
landuse=retail on the parcel that contains the shop (and not much else
non-shop-related), regardless of zoning, and without even trying to
understand zoning.  Similarly for other landuses.

If the government later shuts down the shop because of zoning, and it's
torn down and a house built, then certainly change the landuse.

But an OSM person looking up zoning and deciding that a shop shouldn't
be there and not mapping it -- is crazy.  An OSM person being
*obligated* to do that is beyond crazy.

Related to "illegal activity", there's another common case in the US
which is shops selling marijanuna (cannibis; not sure of the
international usage), some for medical use, and some for recreational
use.  In many states, the state government issues licenses and taxes
these stores.  People say -- and they are either confused or being
intellectually dishonest, hard to tell -- that such stores are "legal in
Massachustts".  But Federal law entirely prohibits anything to do with
marijanuna, so the activity is not legal -- it is merely not contrary to
state law.  It is thus in a class with export control violations and
evasion of Federal taxes, which are also not specifically prohibited in
state law, but nobody would say those are "legal in Massachustts".  This
week, as for the last several years, Federal drug laws that prohibit
marijanuna aren't being enforced against these stores.  But other
federal laws, even though those acts are *not* contrary to state law,
are still being enforced.  This is all a strange situation, but that's
how it is.  I expect other places have different strange situations.

As far as "illegal" goes, pot shops are vastly more illegal than a use
which is pushing the edge of zoning, but might be found by the Zoning
Board of Appeals to be a preexisting nonconforming use, and thus allowed
to continue, were there to be a complaint.  My area has such tussles,
and nobody can guess how the Board is going to rule, and whether that
ruling, either way, would survive ruling by the courts.  An example is a
used car sales place that later rents out space to store school buses
overnight.  A pot shop is blatantly and clearly a violation of Federal
law, and that is a criminal issue with severe penalties, vs a business
being told "no you can't store buses any more".

So, does OSM have a policy against putting marijauna stores on the map?
A quick check shows a number of them.  Obviously there is no enforced
policy of declining to map stores whose business is unlawful.


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

[Greg Troxel]

Warin <61sundow...@gmail.com> writes:

> On 13/10/22 02:42, Evan Carroll wrote:
>>> There is such a thing as mixed use with our local authorities,
>> residential+commercial. I wouldn't think residential and industrial
>> mixes because of noise and pollution, at least in theory.
>> Landuse has nothing to do with local authorities or zoning.
>
> In some places the local authorities have lots to do with landuse and
> everything to do with zoning. To the extent of taking people to court
> and forcing them to stop their present landuse.

Of course they do.  But you are blurring two things:

  OSM maps actual land use.  OSM does not map zoning.

  Governments use zoning to control landuse.  So after they have
  controlled there is an actual landuse to map.

So the government using force to control landuse is not something we
map.  Given that, I don't see what point you are trying to make.


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

[Greg Troxel]

Minh Nguyen  writes:

> Vào lúc 01:45 2022-10-13, Martin Koppenhoefer đã viết:
>> Often names refer to the whole part of the settlement, but there are
>> also named contiguos, single use developments where adding the name
>> to the landuse seems to "work" (not generally, only in some
>> instances).
>
> The latter is especially prevalent in the U.S., in areas developed
> since the 1950s or so. Master-planned communities, apartment
> complexes, and strip malls figure very large in the American
> landscape. Their names and extents are both objective and verifiable
> on the ground and not just a cartographic convenience.

Agreed.  Perhaps more New England, but someone will have a large chunk
of land (former farm often) and subdivide into house lots.  This is
donei with a subdivision plan that needs planning board approval (to
verify setbacks, lot sizes and frontage, street layout, etc.) and that
~always has a name associated with it, and almost always, that name is
then used to refer to that subdivision.  I don't see that as
place=neighborhood which I would use for something more organic and
older, without a crisp boundary.  With a subdivision plan, a property is
either part of it or not, and it's very easy for anyone to look at the
public records of the subdivision.  These have landuse=residential with
names.


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

[Greg Troxel]

Martin Koppenhoefer  writes:

> Am Mi., 12. Okt. 2022 um 16:25 Uhr schrieb Greg Troxel :
>
>> Part of the issue is that landuse should more or less follow property
>> lines, unless there is some reason why not.
>
>>   a several-acre parcel with
>> a house and some trees is still landuse=residential on all of it,
>
> it depends, if this means a big residential garden or other use that is
> clearly associable with the people living there, then yes, if there are
> other significant uses (particularly commercially relevant uses) like
> breeding animals, growing fruit or vegetables for sale (significantly more
> than the residents use themselves), or some other workplace, the landuse
> could be split, it is up to the discreetion of the mapper.

I agree that if there is commercial use also, then there are likely
going to be two landuses.  That's what I tried to say earlier.  But most
residential properties are not like that.

Around me there are often 0.5 ha to several ha (1 to 5 or maybe 10
acres, for US people :-) parcels that have a house, some lawn, and some
either wetland or forest, where in the wetland or forest, pretty much
nothing happens other than plants grow and wildlife wanders.  I see that
as fitting into the larger residential landuse as it's basically buffer
from neighbors.

I also think the point someone made earlier is valid: landuse is not
just about buildings.




signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

[Greg Troxel]

Nick Santos  writes:

> I'd say if you think it's going to work, build it and show the community
> examples of where it works well and where it doesn't. Discussing the
> hypothetical makes us all revert to our own assumptions rather than looking
> at a real comparison. I'm personally skeptical that a model will work very
> well, because right now, land use tagging appears to fill in for when we're
> missing more detail in the DB already, which suggests to me that to take
> the more detailed data and try to infer the general case is something the
> dataset isn't ready for except, maybe, in some areas.

Well said.  I don't have the energy to continue to engage, but I was
thinking this too.

Don't just build it, but build it, take OSM and remove landuse tags and
then-empty objects, generate the landuse polygons you think can be
created "automatically", and difference them, and then for those that
don't map, post a dataset and people can look at the differences.

> But again, I'm not saying don't build it - just expect serious scrutiny of
> its outputs. I also don't think the existence of a hypothetical better
> method is a reason for others to stop doing it their own way, assuming both
> result in acceptable data - OSM is a project of people adding the edits
> they're willing and able to edit. The methodology is only of concern if the
> result is bad, and I shared my opinion on that above.

Agreed.


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

[Greg Troxel]

Evan Carroll  writes:

>> Part of the issue is that landuse should more or less follow property
>> lines, unless there is some reason why not.  a several-acre parcel with
>> a house and some trees is still landuse=residential on all of it, absent
>> farming or some side industrial business.
>
> Property lines isn't mentioned anywhere in the wiki. Land Use crosses

The wiki is often incomplete or wrong.You are proposing a massive
change in OSM, essentially to deprecated the concept of landuse, and I
think very few people share that view.


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

[Greg Troxel]

Evan Carroll  writes:

> *FOLLOW UP HYPOTHETICAL: *
> I've been thinking about this a lot. I'm arguing here that,
>
> * Landuse for developed land can be better automatically generated when
> there isn't a named polygon.
> * If automatically generated, we can achieve perfect accuracy or quantify
> the margins of errors (the degree to which a buildings adhere to the
> landuse that contains them).

I do not understand 'automatically generated'.  Landuse is about the
primary human use of the land, and that's something that has to be
obeserved, or come from another dataset (as an import) where it was
observed.


> Let us create a new landuse-esque tag called "density"
> Let density come in three flavors, "density=high", "density=low",
> "density=medium"
>
> * Low Density is where you have mostly single story buildings
> * Medium Density is where your buildings average to five or fewer levels.
> * High Density is where most of your buildings have more than 5 levels

That's not landuse in the traditional geography sense; you can have
hi-rise residential and hi-rise office and one is residential and the
other commercial.

And, if the buildings are on the map and labeled with levels, then
there is no need to tag what you are proposing.

> What would be ideal: (a) to have users create these polygons in OSM, or (b)
> to automatically calculate density as a function of the buildings in the
> polygon by referring to building:levels? This is a direct analogy to how I
> see unnamed landuse for developed land.

For density, it seem a, but for landuse it is perfectly reasonable for a
mapper to observe that an area is filled with shops and add a
landuse=retail polygon.  It may be that a building or so within that is
commercial not retail, but that's ok.

>  There is an application for
> landuse, and for density. However, I don't understand why these are better
> left to users rather than automatically generated. If we want to support
> landuse for developed land moving forward, I highly suggest automatically
> inferring it from the contents of polygons created in the method outlined
> in my reply to Joseph Eisenberg. =)

Part of the issue is that landuse should more or less follow property
lines, unless there is some reason why not.  a several-acre parcel with
a house and some trees is still landuse=residential on all of it, absent
farming or some side industrial business.



signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

[Greg Troxel]

Andy Townsend  writes:

> I'd suggest asking them in the changeset about that edit, including
> where they got the data from.  I'd also be perfectly reasonable to ask
> them what the "proprietary sources" were that they used,

Agreed.  It would be more  than reasonable to ask them about the
proprietary source and licensing, and why they haven't  put up a wiki
page with an explanation, paid editing guidelines, if this is
effectively an import, etc.  Those aspects of this at first glance  seem
not ok, to the point where I would not be surprised  if DWG were
throwing a block to get the licensing issues clarified.


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

[Greg Troxel]

Martin Koppenhoefer  writes:

> Actually I do not believe “commercial zone” is a good description of
> landuse=commercial because it implies zoning (prescription, also
> planning i.e. permissible future landuse as opposed to de facto use of
> land) and because it implies a certain scale.

I think we should stay away from zoning.  Around me, there can be a
landuse=retail within an area that is largely in fact
landuse=residential and is also zoned residential.   The magic words are
"pre-existing non-conforming use".

If people want to map zoning, that seems not normal in OSM and another
discussion, but please do not blur zoning into actual landuse.


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

[Greg Troxel]

You are  using "zone" and that confuses me, because in the US zone is
like zoning.

Are we talking about landuse, or regulations for what land can be used
for?

I think it's reasonable to draw landuse=retail if

  it's actually true

  it's named and the boundary is more or less the property lines that go
  with that name

or

  the retail polygon is in some sense maximal in that there are
  generally not adjacent retail areas that could be merged in


I draw such polygons fairly often, but I'm doing it for areas I'm
familiar with and manually, not as a semi-automated edit.And they
line up with parcels, or they cut off parts of them on purpose when I
can see "retail use" on one part, and "conservation use" on wetlands in
the back.


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Better term for unisex

[Greg Troxel]

Zeke Farwell  writes:

> The proposal currently states:
>
>> Meaning of the unisex =yes
>> is currently unclear:
>>
>>- gender neutral facility (as the "unisex" term in English); or
>>- facility that accessible for men and women, either segregated or not.
>>
>> I do not understand what is unclear.  The term unisex is well understood
> among English speakers to mean "gender neutral".  Unisex never refers to a
> gender segregated facility.  A tag gender=unisex meaning "gender neutral"
> would be perfectly clear.  gender=mixed would probably be understood, but
> "mixed gender" is not a commonly used phrase so it would probably have more
> potential for mis-interpretation.  gender=neutral would probably be more
> widely understood, but again, I don't see the issue with gender=unisex.

I find the wiki page confusing, becuase it describes a dispute but
doesn't really describe a set of rules.

Even the description at right "Access to all persons regardless of sex
or gender" is unclear between "people are not treated differently" vs
"people are split based on some characteristic, but all people are
accomodated".

I'll also note that sex and gender, while historically essentially the
same thing, are now talked about as separate, and that it seems
difficult to be accurate in describing the world, both because it is
part of a cultural battle and because if you asked people what bathroom
labels mean it is probably a long complicated conversation with
different answers from different people.  So therefore I think OSM
should stick to recording labels, and perhaps eventually splitting to
record either sex or gender depending on the legal situation of which
one matters in a particular jurisdiction.



signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] service vs. unclassified, conflicting definitions

[Greg Troxel]

stevea  writes:

> Ah, I thought of an exception: a service=alley is (usually, around
> here, in California) a public way, but it IS more "service-" oriented,
> like maybe it only gets used for rare, backyard-access by owners
> (which would be exclusively private use), but maybe it DOES get used
> for trash collection (which would be a public use).

Good point.  I'm fine with service=alley even for public ways, because
while public ways they aren't really part of the road grid in any
meaningful sense.

Trash collection isn't "use by members of the public" though.  Here, if
you pay extra, trash trucks will come up long driveways to the house, vs
you taking bins to the road.  The real point is "if some random person
drives on it just because they feel like it, can the police legitimately
tell them they can't do that."


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] service vs. unclassified, conflicting definitions

[Greg Troxel]

Kevin Broderick  writes:

> Another exception in New England, particularly, is that some states
> (especially New Hampshire and Vermont) have a non-trivial number of
> driveways that are privately maintained but in whole or part legally public
> right of ways. In some cases, three public right of way continues past the
> maintained portion of the driveway as a woods road of some variety; in
> others, they end in someone's yard.
>
> To me, tagging those as driveway with appropriate access info and tagging
> the woods road, where applicable, as track seems appropriate even though
> they are pubic right of ways.

In (central, pretty rural) MA, I know of a 'paved area you can drive on'
that is functionally a driveway, but has a name and is in the state's
road dataset with that name.  It is legally a public way and snow is
plowed by the town.  Whether they will ever pave the crumblying pavement
is an open question :-)

But if they aren't named by the government, then driveway seems right,
with access=yes.




signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] service vs. unclassified, conflicting definitions

[Greg Troxel]

"Shawn K. Quinn"  writes:

> Related to this, I've been tagging the driveways inside apartment
> complexes as service, but a lot of mappers tag them as
> residential. These roads are more similar to shopping mall driveways
> than the type of road I would normally tag as residential; also note
> they almost never have names and are almost never tagged as noname=yes
> when mapped as residential. For a lot of purposes apartments are often
> considered commercial properties for many purposes (eligibility for
> city/county garbage collection, among others) even though they are
> places where people live long term.

I'd say that if the driveways are not open to anyone driving on them by
right, aren't "legal roads", and don't have names (the way things around
me that fit what you're describing), then service=driveway is correct.

(I don't see eligibility for trash pickup etc as very relevant.)


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] service vs. unclassified, conflicting definitions

[Greg Troxel]

Peter Elderson  writes:

> Unclassified, by definition, is a road on the traffic grid suitable
> for motorised vehicles. It is not necessarily paved. Access
> restrictions may apply, and usage may change in time, e.g the road
> still connects, but is legally closed for cars except emergency
> vehicles and people who live along the road. Or, a new railway
> intersects the road and no crossing is provided. In those cases,
> usually the road is still seen as an unclassified road.

Agreed.

And, I see a huge distinction between a "real legal road" that to first
order anyone may drive on (even if some have access=destination rules)
and "service roads" which are often entirely private and do not have
legal road layouts (as reflected in the registry of deeds/cadastre).
Around me there is usually no right of access to service roads.

As another data point, if you have a car crash on a real road, you are
required to file an accident report with the police but if it is in a
parking lot etc. you are not.

So I don't know about the OP's country's laws, but I would suggest
looking at legal definitions of roads, and tending to unclassified for
legal roads and service  for things that are not legally roads, if that
makes sense locally.  In Massachusetts, US, it totally makes sense.


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] Heavily-wooded residential polygons

[Greg Troxel]

stevea  writes:

> We agree.  The issues are both around the different behavior of the
> (Carto) renderer when both landuse=residential and natural=wood are
> combined (and there are highly complex ways they can be and are
> "combined" in the OSM database), and around how mappers understand
> these data should be entered.  Should both natural=wood and
> landuse=residential be "stacked" as two tags on one (multi)polygon?

I would say probably not, as it is highly unlikely, really entirely
unlikely, that an extent of landuse=residential, determined by
aggregation of property with similar use, lines up exactly with an area
that is covered by trees.

> That was and is widely done in cases where heavily-wooded residential
> polygons exist, though a "better" trend (at least around here) is to
> break these apart into two polygons: one explicitly on the
> landuse=residential polygon (glom of parcels which are residential, to
> the area extent where they are), one on the polygon defining the
> extent of natural=wood.

Yes, this is sensible.  Two areas, entirely disconnected spatially, each
defining the area where their property applies.

> Unfortunately, Carto doesn't easily (it does consistently, but the
> rules are complex, having to do with sizes of the underlying polygons)
> render these consistently, requiring frequent "fiddling" by craft
> mappers who are looking for both a desired effect and a visual
> semiotic which richly and accurately conveys what is going on: heavily
> wooded residential landuse.

THat's what I meant by suboptimal, which was a polite word: If there is
semantic markup of "this area is residential landuse" and "this other
area is covered by trees", then the rendering rules should do the same
thing regardless of the precise form of the relation/polygon/etc.  It is
a bug if anyone needs to walk on eggshells to make it come out right.

I don't mean in any sense to say "the people that do Carto are bad
people".  This seems incredibly hard to get right and I don't know how
to fix it.  I just mean that it is a failure of software to be ideal and
a place for improvement, in a descriptive and non-judgemental way.

>> The basic problem here is that it's pretty straightforward to render a
>> map that primarily shows landuse, and it's pretty straightforward to
>> render a map tha primarily shows landcover.  What carto does, and what a
>> lot of people want, is a way to show both of them.
>
> I wouldn't necessarily call it a "basic problem," more like the desire
> of "let Carto display both" doing so in complex ways, which gives rise
> to "well, what are the best practices here?"

I think we agree; I'm saying that designing rendering rules that show
land use and land cover at the same time is 1) hard and 2) beyond what
is typical in cartography.  In other words, the "what are best
practices" question you pose don't have an easy, consistent answer.

>> I would suggest that if tagging heroics are needed there is something
>> suboptimal in the renderer.  I think renderers probably need fancier
>> code to choose which of landuse/landcover to emphasisize depending on
>> local scale.  Or a deconfliction of symbology.
>
> Yes, heroics are sometimes employed, yet even that isn't always enough
> (it is often, but not always).  "Suboptimal" might be too damning, as
> I don't think it is "deficiencies" in the renderer, rather I think
> there are "projected expectations" of the renderer (that it appears
> Carto CAN render "both," so it SHOULD, and it DOES, but in
> sometimes-confusing ways).

I don't know if you are just trying harder than me to be nice, or if we
really see this differently.  I see a rendering plan like a
specification, something like "an area that is both landuse=residential
and natural=wood should have a 40% gray fill with a stipple of tree
icons at 20% green" (making that up, details not the point).  Then,
areas that are covered by each should be like that.  And  the exact form
of tagging should not matter, and people should not feel motivated to
mess around with tagging form to make the renderer work.  Otherwise,
it's a bug to be fixed.  Again, this is hard and I get it that people
with limited time are working on it.

> This is an example of amazing, sometimes
> beautiful things going on in the renderer "driving" whether and how
> OSM should and does enter data.  Yes, there is some "coding (data and
> tagging) for the renderer" going on, but it appears to be in the best
> longer-term interests of good data entering, not simply and only for
> the same of "pretty renderings."  I believe we can get there, an
> attempt to discuss "best practices" (I'll settle for "better
> practices" for now!) is a step in that direction.

As always, there is the question of whether people are really coding
tagging for renderer behavior that is not justified, or whether there is
a sensible semantics in between taggers and interpreters.  I feel like
you have arrived at having to walk on eggshells to make it com

Re: [Tagging] [Talk-us] Heavily-wooded residential polygons

[Greg Troxel]

stevea  writes:

> As I mentioned to Doug I exchanged a couple of emails with
> user:jeisenberg (a principal contributor to Carto) about what was
> going on with some examples of this, and Mr. Eisenberg explained to me
> (in short) that it is a complicated ordering (or re-ordering) of
> layers issue, both Doug and I continue to scratch our heads about what
> "best practice" might be here.  (For "heavily wooded residential"
> polygons, which are frequent in Northern California).  While Doug and
> I both tend towards the preference of the "superimposed look," it is
> not always simple to achieve, due to complexities in the renderer and
> data/tagging dependencies.  And, Doug and I are certainly aware of
> "don't code for the renderer."  However, given that Doug and I are
> fairly certain that others have noticed this, but aren't certain that
> others know what best to do (we don't, either), we ask the wider
> community "what do you think?" and "What are best practices here?"

Agreed this is really hard.

First, I'm going to assume that polygons for landuse=residential do or
are intended to align with property boundaries.  I'm also going to
assume that natural=wood aligns with the actual location of trees, which
is (in mass) almost always not aligned with property boundaries.  I have
thought it an error to have natural=wood tagged on a polygon that shows
conservation land, as the adjacent non-conservation land almost always
similarly has trees (around me).

I would suggest that perhaps a "this land has some trees" landcover tag
(cover != use, strongly agreed) may make sense.  I am not sure you are
talking about this, or not.   I find natural=wood to imply that the land
has none to very little built structures, mostly trees, and the usual
understory plants.   I would definitely not want to use this tag on an
landuse=residential area with houses, but I might use it on the rear
parts of a housing area that are basically trees.   I also would not
want to stop at the subdivision line.

The basic problem here is that it's pretty straightforward to render a
map that primarily shows landuse, and it's pretty straightforward to
render a map tha primarily shows landcover.  What carto does, and what a
lot of people want, is a way to show both of them.

I would suggest that if tagging heroics are needed there is something
suboptimal in the renderer.  I think renderers probably need fancier
code to choose which of landuse/landcover to emphasisize depending on
local scale.  Or a deconfliction of symbology.

To have a way forward, I think we need a coherent design for a style
(not code, but an articulation of how it ought to work, first) that uses
some kind of symbology for landuse and some other kind for landcover.
I naively lean to solid fill, tending to lighter shades, for landuse,
and stipple patterns for landcover.  I think this is what you are suggesting.

It is interesting to think about the 80s USGS topo maps, and surely also
interesting to look at other traditional maps for inspiration.  The USGS
ones were primarily land cover and very little landuse.   But they did
have a gray "house omission tint" in built-up areas, which I'd say is
"this area has many buildings" and is sort of landcover, even though
it's a proxy for landuse.

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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

On 2020-05-08 11:33, Martin Koppenhoefer wrote:

It could be useful when mapping something like a building. You could 
establish a certain elevation as local zero (e.g. the elevation of the 
ground floor) and have all other levels based on this. It is something 
that could also not be needed because of an editor who abstracts this 
(no need to store relative information if some frontend could do it), 
but I would not hinder people from experimenting with it.


I can see wanting to do this, but I think it should not use the ele= 
tag, and this really feels like it needs to be "height above ground 
floor" or something.   It really needs a scheme that is well thought 
out.   I too think it's fine if people do this, as long as they don't 
use the ele= tag, which means something else.




 > ele:regional is about admitting that you don't know

But, it asserts that the value is in some particular datum, and that you
can tell which one from knowing the area.   All of this is untrue.

maybe a particular datum can not be given, but you can be quite sure (as 
sure as you are willing to accept from a tag which pretends it is) it is 
one of those common in the area (which also will not differ a lot, 
probably).


I think we now know that the existing datums don't differ much from 
WGS84 except Belgium, and given the EVRF2007 datum, it seems clear that 
Belgium now will have that and the old one, differing by 2m.

Hence the thing we need to know, we don't, in this case.

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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Martin Koppenhoefer  writes:

> I was not aware there weren't any meaningful differences (when comparing
> some official height references to the German DHHN92 those in wikipedia.de
> with delta information all are within 1m besides Belgium DNG/TAW, which is
> -2.3).

Thanks for looking into this.  It is interesting about Belgium's datum
being so far off, but I'm sure there's some long-ago historical reason
and various datums along the way matched some earlier datum.   Perhaps
relating a nautical datum (tends to be mean low water) with a land datum
(tends to be mean sea level).

> Maybe all we should do is clarify that we are NOT expecting
> ellipsoid heights in ele tags (leaving open the possibility to add
> ele:datum tags)?

I would very much like to clarify that, and it feels like we have
consensus on that point.  I can edit the wiki page to make it clearer,
since we have had a big discussion and there is no one advocating for
ellipsoidal height in OSM.

I am ok with some text about the possible future use of ele:datum to
refer to some other datum, although I think it's preferable for people
to transform, just as it is for horizontal.

> WGS84 uses a 2 dimensional ellipsoidal coordinate system?

WGS84 at its core is a 3-dimensional cartesian system, written XYZ, with
the origin at the center of mass of the earth.  There is a transform to
latitude, longitude, and ellipsoidal height (which is just math and not
a source of errors).   All modern datums are like this.  Note that WGS84
is essentially the same thing as ITRF2014, the current international
datum from the geodesy (since of measuring the earth) community, perhaps
differing by a few mm, perhaps not.

> Wouldn't "natural" height information be based on this ellipsoid? I'm all
> fine with stating we should use geoid heights, but it doesn't necessarily
> seem to be implicit.

It does need to be made clear, as there is ample reason to think there
has been confusion about it in OSM.


ellipsoidal heights are not natural!

To understand this, one has to look to the history of surveying.  Until
the satellite era, horizontal datums and vertical datums were basically
separate.  Horizontal was done by maesured baselines and triangulation.

Vertical was done by 'leveling' which is basically a telescope with a
bubble level, so you transfer horizontally from one place to another,
and then read the difference on a rod, which is basically a giant
measuring stick.  As you move from a tide gauge across a continent, you
keep track of the accumulated differences (and loops, and then you do
least squares).

Implicit in leveling is that two places at the same height are at the
same gravitational potential, and that when you say "height is x m" you
mean that if you measured vertically (along the plumb line) it was x
until you got to where the ocean would flow to if there were a tunnel.
So height as surveyors used it, and the national/regional datums taht
this height is referenced too, have always been about gravity, and the 0
reference level has more or less been at some notion of sea level.
Typical is the mean reading of a tide gauge over 19 years (a sun/moon
cycle).

NAVD88 is referenced to a single tide gauge at Father's Point in
Rimouski, Quebec.  NGVD29 set a number of tide gauges around the
continent at 0 (and this caused distortions).

Satellite techniques just measure position and distance, and not
gravity.  Thus they in their raw form give you ellipsoidal height.  But,
this is not useful for water engineering, because lower elllipsoidal
height is not downhill.  So WGS84 defines a "geoid model" that gives the
height of an equal-gravity surface that more or less corresponds to mean
sea level, compared to the ellipsoid, and except for 1) some buggy
android programs and 2) survey-grade GPS equipment, all GPS (GNSS,
GLONASS, Galileo, BeiDou, etc.) receivers give altitudes in height above
the geoid, because aligning (at the meter level) with the previous
national height datums is important, and having water flow to lower
elevations is important.  And because nobody except national-level
surveyors has ever cared about ellipsoidal heights.

Ellipsoidal heights are basically used only as internal steps in
surveying, and nobody in the surveying world would ever think to put
them on a sign, or say to the public "the ellipsoidal height of Mount
Washington is X".  (A datasheet for surveyors would say that, but it
would also give the NAVD88 height.  A poll of 1000 surveyors asking
"should we put ellipsoidal height or NAVD88 on the sign" would result in
all 1000 of them looking at you like you were crazy and saying "NAVD88,
of course".)

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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Colin Smale  writes:

> As I mentioned before, the national datums of the Netherlands and
> Belgium differ by over 2m, which for everything connected to water is
> very significant. Waterways often form the border, with bridges that
> cross the border. You cannot use a map/chart (at last for tidal waters)
> if you don't know what datum it uses. 

Thanks.  2m is perhaps significant, and I'm surprised it's that much.  I
would suggest that if people care about that 2m, then they need to
transform to a common height reference.

I would expect that Europe is working on a new satellite-native regional
height system, similar to the new 2020 in Australia and the 2022 one in
North  America, that will basically align heights.

> In OSM we often leave out "obvious" annotations, giving rise to a kind
> of "default" (such as maxspeed in km/h). But there is always a way of
> making it explicit, for those who feel the need. In this case we may
> agree to define "ele" as relative to the "local datum" or WGS84 or
> whatever, but we must always provide a system for making that explicit,
> and (preferably) a means to derive the intended basis for values that
> are not explicitly qualified.

So what do you think about what I've been saying:

  ele is assumed to be in, and should be represented in, WGS84 height
  above geoid (as the international norm, aligned with OSM's horizontal
  datum)

  ele:datum=unknown represents that the mapper doesn't know what datum
  the number they put in ele is expressed in

  ele:datum=EPSG:5703 (as an example for NAVD88), when the mapper really
  does know the datum, and doesn't want to transform to WGS84


I assume you are referring to:

  https://epsg.io/5709

  https://epsg.io/5710

and it seems that the European more modern height datum has already
happened:

  https://epsg.io/5730 (superceded)
  https://epsg.io/5621 (European Vertical Reference Frame 2007)

This looks useful:

  http://euref.eu/documentation/Tutorial2015/t-04-01-Liebsch.pdf

And this all makes me think that an elevation without a datum cannot be
reliably used at the better than 2m level.

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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Martin Koppenhoefer  writes:

> Am Fr., 8. Mai 2020 um 03:26 Uhr schrieb Greg Troxel :
>
>> The notion of "local" has the same problem, and it is also a poor choice
>> of words in that in surveying, "local", refers to coordinate systems
>> established for particular projects or surveys that have no lasting
>> significance.
>
> the "definition" for "ele:local" (in German language on the English talk
> page of the tag) seems to be about this: a local datum based on a local
> reference (i.e. not the same as ele:regional). I am not in any way involved
> in ele:local, just wanted to point it out.

That does sound like what I mean by local.   I would say that heights in
such local systems should not be entered into OSM, and I would find
their use in anything tourist-facing to be very strange.

>> Basically, either you know what datum an elevation is in, in which case
>> you can 1) transform it to WGS84 height above geoid or 2) label it
>> correctly, or you don't know, in which case you should simply *admit
>> that you do not know*.

> ele:regional is about admitting that you don't know

But, it asserts that the value is in some particular datum, and that you
can tell which one from knowing the area.   All of this is untrue.   In
contrast "ele:datum=unknown" is a crisp statement that you don't know
the datum, no more and no less.

As for guessing about regional, data consumers can guess too, but
encoding a guess in a vague way seems really unhelpful.

>> I would also ask: if this is reasonable for height, why isn't it also
>> reasonable for horizontal coordinates?
>
> because we typically have much more horizontal positional information with
> which we can compare. Errors in horizontal position are more evident
> because the relation to the surrounding (alignment, reference, angles,
> axis, proportions, etc.) won't fit. Up to a certain degree (e.g. when other
> information around is missing, and when accurate positional information is
> missing) we also do have and tolerate very approximate horizontal spatial
> information.

I'm talking about things like NAD83 vs WGS84, which is basically a 1m
difference around me.   We either transform or accept the fuzz, but it
would be crazy to label points as being in NAD83.  That's really my point.

> Greg, you wrote we should convert locally signed regional datum elevation
> information to the WGS84:geoid reference. In other context, we do not do
> unit conversions, for example we do not convert speed limits in mph to kph,
> nor do we convert weight information or maxheight information.

This isn't really about units.  Datum is about point of reference, and
the "don't convert" argument applies equally well to horizontal datums.

As I said before, if you want to put something like

information=board
inscription="Mount Washington // Elevation 6288 Feet"

that's totally fine.

> I could imagine doing a "reasonable" conversion (precision the same as
> expected from the original value) if there would be support from the
> tools (e.g.  mobile editors, iD or Josm), but otherwise I would not
> expect the vast majority of mappers doing this conversion at all in
> case of a value read off a sign, and even if they did I would expect
> this conversion step to be error prone (e.g. the mapper won't know
> which is the original datum).

I agree that casual mappers doing conversions is likely too much.

However, I don't see the harm in just entering a signed elevation in
ele= and not worrying about it, or also adding ele:datum=unknown to
represent that the data is not known to have been handled accurately.

My primary objection is not about having a tag to say the datum is
unknown.  What I really don't like is:

  the notion that it is a desired state to have elevations in other than
  the standard OSM datum, and that all data consumers should have to deal
  with this

  any notion that HAE is reasonable in OSM

  marking something as "regional" as if that is clear, when the reality
  is "unknown".  (If I come across a sign in the US with elevation, even
  I, as an elevation nerd, have no idea if it's NGVD29 or NAVD88, or if
  it's just plain bogus, with the number being copied from someone else
  who didn't really know either.)


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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Martin Koppenhoefer  writes:

> Am Fr., 8. Mai 2020 um 03:22 Uhr schrieb Greg Troxel :
>
>>   3) Look up the data sheet and mark it as ele:datum=NGVD29 or
>>   ele:datum=NAVD88 as it turns out.
>
> IIRR, in another mail, you wrote that the difference between these 2 is
> less than a meter, can you confirm this, or did I understand you or
> remember wrong?

Yes,it typically is.

So let me ask you again, since you keep declining to answer this:

  Please give an example of an elevation of a real thing that is
  meaningfully different in one of these "regional datums" (established
  by a country's survey agency) compared to WGS84 height above geoid.
  Identify the regional datum, and identify two values linked with a
  rigorous transformation (such as national survey agencies publish).


Thus far, you have not established that there is an actual problem that
needs to be solved.

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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Peter Elderson  writes:

> Why not use a datum:value pair?
>
> ele=[datum:]value
>
> datum: is optional. If you don't know, just leave it out. Data users can
> assume locally signed or known.

Becuase, as I have said many times and no one seems to be listening, in
OSM we have said that we use WGS84, and thus all elevations must be in
WGS84 (height above geoid), the same way that all horizontal coordinates
must also be in WGS84.

The very notion of putting in elevations in other datums is very
irregular, and it's a path to madness where data in OSM is in varying
reference systems and the data consumer then has to deal and transform.
It seems really obvious that the data should be in the standard OSM
datum and therefore correct.

This entire situation is really blowing up a situation of people who
want to simultaneously not be rigorous, by entering elevations that they
don't have any basis for trusting or knowing the datum, and to be sort
of appearing to be rigorous by labeling them in a way that isn't sound.

I think it's completely fair to have an extra tag that indicates the
elevation value is low quality, so that those mappers that know this and
those data consumers that know this can express and understand this.
But it's also very important for the simple case to remain simple.

Adding datum: into elevation means that every data consumer has to adapt
to the new rule, while ele:datum= does not - those that ignore it
are not harmed.


Other than your proposal making it difficult for data consumers, it
seems equivalent to ele:datum=.

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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Joseph Eisenberg  writes:

> Is there a reason to use this new tag ele:regional instead of ele:local=*
> which is already mentioned on the Key:ele page?

The notion of "ele:regional" is semantically wrong, because there is no
way to map a particular lcoation to a single vertical datum.

The notion of "local" has the same problem, and it is also a poor choice
of words in that in surveying, "local", refers to coordinate systems
established for particular projects or surveys that have no lasting
significance.

I have tended to say "regional datum", because in the US we share NAVD88
with Canada, and because I have the impression that in Europe multiple
countries share a vertical datum.


Basically, either you know what datum an elevation is in, in which case
you can 1) transform it to WGS84 height above geoid or 2) label it
correctly, or you don't know, in which case you should simply *admit
that you do not know*.


I would also ask: if this is reasonable for height, why isn't it also
reasonable for horizontal coordinates?

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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Mark Wagner  writes:

> What about regions where two or more reference systems are in common
> use?  If I copy an elevation from a USGS benchmark and put it in
> "ele:regional", how does an end-user know if it's a recent benchmark
> measured in NAVD 88 or an older benchmark measured in NVGD 29?

They don't, and this is why doing what you ask about is a bad idea.  (I
realize you are asking a mostly rhetorical question.)

The right thing to do is one of

  1) transform the elevation from whichever system it is in to WGS84
  height above geoid.  This is after all what we do with horizontal
  coordinates -- it is not acceptable in OSM to store coordinates in
  some random datum that is not WGS84, and then make up extra tags to
  pretend that's ok.

  2) Use ele:datum=unknown as a clue that the data is not that high
  quality.

  3) Look up the data sheet and mark it as ele:datum=NGVD29 or
  ele:datum=NAVD88 as it turns out.  Keep in mind that this 'on the
  ground' verifiability notion is taken to crazy extremes, and that
  looking up a height in a database is just as legit as reading it off
  the disc.  The physical discs are after all merely a distributed
  database.  If you are encoding "this disc says X", then you are
  reporting a fact you see with your eyes.  But once you report "the
  elevation of this disc is X (because it said so)", then you are making
  assumptions and *you have not actually verified* what you are putting
  into OSM.  In particular you have not verified it any more than
  looking it up in the NGS databse, and arguably you have verified it
  much less.

The next question is:

  If I just put a height that might be NGVD29 or NAVD88 into the db as
  ele, where it is interpreted as WGS84 heigh above geoid, what harm
  is done, and who suffers that harm?

and I would say "close to zero, and anybody who is upset is welcome to
look up the datasheets, transform precisely, and adjust the values in
the osm db, just like anybody who finds nodes that are not placed
correctly in horizontal coordinates is welcome to move them to better
places".


Not addressed at Mark, but I find the insistence that we have a real
problem to be hard to understand.


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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Simon Poole  writes:

> Am 04.05.2020 um 15:19 schrieb Kevin Kenny:
>> Elevation as height-above-ellipsoid, unless you're using it in the
>> intermediate results of a GPS calculation, is nonsensical.
>
> However if you read the argumentation on the Altitude page that was
> exactly the reasoning: store hae and therefore be able to calculate
> datum specific heights easily after the fact.

Yes, but this is a ridiculous stramwan.   HAE and height above wgs84
geoid are equally well defined, but one (height above geoid) is what is
used for height and also happens to be almost matching all civil height
systems.


The real point here is that people want to take data that has a number
but not a datum and enter it and feel good about themelves, instead of
realizing and admitting that they are doing something fundamentally
wrong.  I am perfectly ok with entering a height that has no datum, and
having some meta key that basically says that the height value is
inaccurate, and perhaps "ele:datum=unknown" is good for this, crisply
denoting that the height is without a solid basis.

But, I find it unreasonable that people want to legitimize this sort of
confusion, rather than mark it as confusion as a warning to others.

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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Martin Koppenhoefer  writes:

> So the question is how we can solve this. We could discourage the use of
> the "naked ele" and encourage to always use a more specific subtag, e.g.

But is there significant amounts of data that have ele as ellipsoidal
height, more so than the prevalence of somewhat wrong data in OSM?   If
not, there is nothing to be gained from tag churn.

> - ele:egm96= to mean ele referring to the EGM96 geoid

Again this makes life difficult for data consumers.  Plus it's EGM08
now, and approximately zero people are clear on which of these flavors
they or any device are using.

> - ele:wgs84= to mean ele based on the WGS84 ellipsoid (or maybe

This is very confusing and therefore a bad idea.  Elevation in WGS84 is
obviously, to those who really understand height, intended to mean heigh
above geoid.  Nobody with the slightest respect for existing practice
would ever use the word "elevation" to mean "height above ellipsoid".

And, I don't think we should encourage HAE to be stored in OSM at all.

> "ele:ellipsoid" which would imply the WGS84 ellipsoid?)

Also very confusing, as in the US ellipsoidal heights are often relative
to the NAD83 ellipsoid.  However, people that use them are clear on what
they are doing and they are labeled correctly.

> and whichever height reference system is used, e.g.
> - ele:dhhn92
> - ele:tm75
> and more: https://taginfo.openstreetmap.org/search?q=ele%3A
>
> - ele:regional for "I have no idea but it was written on a sign", could
> still be a way to be expressive about the reliability. For many use cases
> +- 50m is better than no information. We could also keep "ele" for this
> like you suggested, although it wouldn't be explicit then.

This really feels like solving a non-problem.  If you just put what's
on the sign in ele, and don't worry about it, that's ok.  If somebody
else actually makes a valid, hard-core measuremnt, and fixes it, even
better.  But this is just like having approximate horizontal coordinates
- if a hotel is 10m off from where  it should be, that's stil useful and
somebody can and will fix it later.


You still haven't articulated that there is a real problem  to be
solved, or made an argument that my proposal for ele and ele:datum is
unsuitable.


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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Volker Schmidt  writes:

> I am not an expert, but it looks as if the Wiki page Key:ele
>  is not up-to-date.
> I thought that WGS84 uses the EGM96 Geoid, named "WGS84 EGM96 Geoid".
> Hence there should be no difference between WGS84 and EGM96 elevations.

To be somewhat pedantic, EGM96 is a function that takes lat/lon as input
and produces a value which is the offset of the ellipsoid and  the geoid
(equal-gravity surface).   So "EGM96 elevation" is a big awkward.   But,
one uses WGS84 ellipsoidal height and EGM96 to get "WGS84 altitude".

I believe EGM96 was replaced with EGM08:
  https://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/egm08_wgs84.html

But this is basically an update with more precision, so it's very much
the same thing.

> Also it would be helpful, f you could give examples of local elevation
> systems which would need explicit tagging.
> When I see an elevation value on the ground I do not see any reference to
> the reference system, so I cannot know, as a mapper, what reference system
> is at the base of the informaton that I find on the ground. In that respect
> the proposal is not at all clear from a practical perspective.

Completely agreed.  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.  The wikipedia article doesn't address this point :-)

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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Basically I think the whole elevation as height above ellipsoid is
mostly a huge misunderstanding, and I wonder how much support there is
for it.

My memory matches what Martin pointed to: ele= is "height above sea
level".  And, given that layman's terms description, and that OSM is
using WGS84, then it seems really obvious that the particular flavor of
"height above sea level" should be "WGS84 altitude" meaning "height
above the WGS84 geoid".

In the US, ele= tags typically have the NAVD88 height, from GNIS, or
elevations from GPS receivers that do geoid corrections (e.g. Garmin).
(Yes, there's slight fuzz but it's tiny compared to vertical GPS
accuracy.)

The talk page you pointed to says "elevation should be WGS84 because we
use GPS" and then reasons that this must be HAE, even though almost no
GPS receiver used by a mapper (pre android) would have been showing HAE.
In fact, to this day I have not seen a GPS receiver (other than geodetic
survey type ones) display height in HAE (without labeling it as such),
other than buggy android apps.

So it's likely that people were using what their receivers displayed
(height above geoid) and perhaps just thought that was HAE, rather than
really intending to use height values with huge differences from
conventional height datums.

Stepping back from untangling the history, I have three questions about
ele=:

  1) Does anybody think it makes sense to use HAE in OSM, vs "WGS84
  elevation" meaning heigth above geoid?

  2) Are there lots of points in OSM that actually have ele in HAE?  (I
  am unaware of any such points in the US.)

  3) Are there any national height datums that are ellipsoidal height?
  (I think not, because height is very much about water and therefore
  about gravity.)  If not, why is it sensible for OSM to start doing
  this?  IMHO, OSM should follow existing standards and practices of the
  relevant fields in terms of definitions, to the extent that this is
  sensible.



So I would propose:

  adjust ele page to be very clear that this is WGS84 altitude (height
  above geoid) and caution about bad data on some android apps.

  mark Altitude page as an old proposal that has no current support



and if that's off base it would be good to hear from people how it's
off, and why.



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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Following up to myself, a few things I didn't have time to say last
night.

Once we accept that the base notion of ele= means WGS84 geoid height
(meaning the MSL sort of height), and that ellipsoidal heights basically
have no place in OSM, then:

  0) The entire notion of looking at a sign on a mountain and believing
  that is suspect.  I certainly think it's fair to put in a sign object
  with an inscription, as "there is a sign" is a fact.  But on mountains
  here, there is often some number in feet, and it's never clear whether
  that's in NGVD29, or NAVD88.  Often the number doesn't change much and
  it doesn't matter.  But a sign with a number without a datum has to be
  taken with a huge grain of salt.  (As I understand it, most countries
  have a 20s-50s generation height system and an 80s/90s height system,
  and many are moving to a 2020s height system.)

  1) For this proposal to be considered, we need to have examples of how
  different elevations are between "WGS84 altitude" and various national
  height datums.  In the US, the differences are at the meter or so
  level.  So while the ability to enter national datum heights without
  losing accuracy is useful, there is complexity in use to trade off
  against that.  I suspect that differences from most other national
  vertical datum to WGS84 are small.

  2) As always, I am concerned that tagging discussions tend to focus on
  what taggers want to represent and not be so concerned with how data
  consumers uses the tags.  Tags are after all a protocol that is
  written by mappers and read by renderers, routers, etc.  It's
  therefore important that simpler data consumers get sensible answers,
  and that mappers being less precise provide data that is not grossly
  wrong.

  Therefore, if we're going to represent this, I think we should say:

ele=
ele:datum=

  where ELEVATION is some sort of "height above sea level", where the
  main/primary datum is the WGS84/EGM, and if it is in some other datum
  (e.g. NAVD88 in the US and I am seeing various other ones on the
  list), then ele:datum denotes that datum.  This means that if a mapper
  just puts in an elevation, ignoring vertical datum, or if a renderer
  ignores it then nothing terrible happens, just a meter or two of fuzz.
  And, if the mapper is precise, and the renderer deals, then all is ok
  with no loss of precision due to datum issues.


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

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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Peter Elderson  writes:

> Thanks for explaining why my android phone says I am at +38m (+/- 3) in my
> backyard when in fact it is at Dutch sea level -4.4m.

Well, I didn't quite.   The location API returns HAE.For a program
to show that value to a human as "elevation" is buggy.   So in addition
to what I said, you have to add "your software is buggy".   File a bug
with that app!

On Android:

  install GPSTest (available in F-Droid).  It will show two heights.
  One is mislabeled "Alt", when it should say HAE*, and the other is "Alt
  (MSL)" which is the WGS84 sea level type height.
  * I have discussed with the author, but the notion is that people will
be baffled by HAE.  However, I think that's better than
misinterpreting it as a gravity-based height

  install OsmAnd.  In addition to maps, get the "World Altitude
  Correction" map.  This is really the WGS84 gravity model, and when it
  is loaded OsmAnd will convert HAE from Android to height above the
  WGS84 gravity surface
  

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

Re: [Tagging] RFC ele:regional

[Greg Troxel]

Martin Koppenhoefer  writes:

> I’m asking for comments on 
> https://wiki.openstreetmap.org/wiki/Proposed_features/ele:regional

Two big comments:

  First, the current wiki documentation about ele and Altitude should be
  really straigthened out, so that we have a basis for what we are
  comparing to.

  Second, the notion of a single regional vertical datum doesn't really
  work.  In the US, that could be the old NGVD29, or the current NAVD88.
  Plus, we are about to get NATRF2022.  However, all of these are within
  a meter or so, and in terms of vertical data in OSM, that's not really
  a big problem.  So if there is going to be precision, then we should
  follow GIS and have an explicit datum.  I would say an EPSG code is
  sensible -- see the proj package for canonical values.



As for ele/Altitude, there is great confusion out there about "WGS84"
and two separate concepts:

  height above the ellipsoid.  Often written HAE. The ellipsoid is a
  mathematical surface that is NOT a surface of equal gravity.  While
  geodesists and geodetic surveyors use it, and while it's part of the
  calculations within GPS, I am not aware of a single vertical datum in
  use in any country that is relative to the ellipisoid.  Note that
  water does not flow "downhill" when "down" means to a lower value of
  HAE.  Water is hugely important in elevation and mapping.

  height above geoid, or height above a reference equal-gravity surface,
  or height above sea level.  (Yes, I realize that "sea level" is a huge
  can of worms.)   This is more or less what every height system uses or
  intends to use.


In WGS84, one gets from the base computation lat/lon and a height above
the ellipsoid.  This is purely a geometric answer and is totally
disconnected from grravity.  Then, GPS receivers use a gravity model to
compute the offset from the ellipsoid and the reference gravity surface
(which is more or less the "sea level surface"), and they them use that
to get a "height above sea level".  Receivers that display to humans
display this sea level height.  NMEA has that same sea level height.

(Android stands alone in that the API returns height above ellipsoid.
That's not wrong, but it is unusual.  IMHO how Android defines an
interface is irrelevant to OSM's definitions.)


When people say "WGS84 altitude", they mean the height above the WGS84
equal-gravity surface as computed from the ellipsoidal height and the
gravity model.  This is sort of 0m at sea level.  Note that the
ellipsoid can be 100m different from this equal-gravity surface, and is
often significantly different.  It's ~30m in Boston and I hear it's 50m
in Switzerland.  Nobody who says "WGS84 altitude" really means "WGS84
ellipsoidal height".  If they did, they would say "WGS84 ellipsoidal
height".


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

Re: [Tagging] highway=service, service=driveway vs highway=track

[Greg Troxel]

Mike Thompson  writes:

> I have always been under the impression that the highway tag should be
> based off of function.  Recently I have come across a number of cases
> where driveways and residential roads were tagged "highway=track"
> (perhaps because they are unpaved?), e.g. [0].  Before I change these,
> I wanted to check with the rest of the community.

I agree with those who say driveways should be highway=service
service=driveway, unless they are so difficult to drive on that they are
really not recommended in a passengar car.

Not really germane to driveways, but a major distinction, at least
around me (ma.us) is that

  a road is a legal thing, with its own parcel

  a track is an agricultural road, or old time logging road, within a
  parcel

However, drivways are also not legally roads in terms of separate
parcels.


I also agree that this is a problem partially becuase of the default
style not showing dirt roads as dirt.  Whether a road is dirt or paved
is hugely important in all areas where both types exist.  My impresssion
is that England doesn't really have dirt roads because they would be too
muddy.  In New England they are quite common.  My town halfway from
Boston to Worcester has a few and as you go farther out there are more.
I think using track to get a dirt symbol is bad.  But, my impression is
that the symbology plan to short dirt roads on carto is considered too
hard, for reasons that may be valid but that I don't understand.  I
think it's so important that even some ugliness is better than not
showing it.

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

Re: [Tagging] Too many different features lumped together under amenity=social_facility?

[Greg Troxel]

Martin Koppenhoefer  writes:

> apart from workshops, it is this overly broad meaning of "social facility"
> that doesn't make the tag super useful. In the end you will have to add

I agree with this overbroad notion.  I am very much in favor of a
top-level tag with subtags when all of the subthings are clearly part of
some larger concept.  But social_facility seems to be not like that.

I said this in an earlier thread, but "group home" is a loaded word and
it would be good to avoid using it in a way that applies incorrect
connotations.  Specifically, in the US it is not used for a place where
people live because they are unable to care for themselves fully because
of normal aspects of aging (physical inability and dementia).

Also, there are places "independent living", and I think calling those
"social facility" is wrong.   Overall, I'd be in favor of completely
removing the use of social facility in tagging, as it carries too much
baggage and historical confusion compared to its value.

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

Re: [Tagging] insurance health

[Greg Troxel]

On 2020-04-14 21:16, Joseph Eisenberg wrote:

OK, but are there any countries in the world where you can would
normally buy health insurance in the same place as car or home or life
insurance?


I don't know.  Many countries might not even allow this.


If not, then this is a theoretical problem only.


The problem is having a messy namespace with tags that sort of mean the 
same thing, but aren't the same, which makes understanding the data much 
harder, for what I view as no good reason.



"if you  want to  ask "how many insurance offices are there and what
is the breakdown by type", it's much more natural to search one key..."

It's all one key either way ("office"), and database users already are
very accustomed to searching for more than one tag to find a set of
similar things. It only takes a few more seconds to add another tag to
an Overpass-API query.


It's not the time to change the query.  It's the semantic load on 
everything that looks at the data.  Every renderer and search program 
has to learn about this.   That's not so bad in terms of work, but when 
they don't know about it, users get missing results.



But it takes more time for each mapper to add 2 tags instead of one.
Mapper time is the most precious resource in OpenStreetMap: we don't
have enough mappers, and most are working for free, for fun.


I also have to often tag "barrier=wall" "wall=dry_stone".   Should we 
than have "barrier=wall_dry_stone" to save me a few keystrokes?  This 
way becomes madness if taken to the extreme with every detail promoted 
into the top-level tag.


In my mapping of POIs, the big amount time is actually going places. 
The next biggest is having to read the wiki to figure out what tags to 
use for things that I haven't mapped before.   When using vespucci, 
another big thing is actually typing the name correctly.


If there is a preset for "insurance" and  a subtype for what kind, I 
think most people would complete their tagging in seconds.   And this is 
something that isn't super common, and many people mapping it will be 
tagging one, very occasionally.


So I really think this de-normalized tagging, to use db terms, is a 
false optimization that doesn't help anyone.



Let's make things as easy as possible for mappers: one tag for one main feature.


That is begging the question of "main feature", and what's easy.

We have to have summarization or we will have thousands of top-level 
tags.  To me, a business that sells insurance is a kind of thing, and 
sensible to label.   Labeling what kind is perhaps of value, but I don't 
see people shoppingfor health insurance by searching for such places.


And, having a preset with a choice pulldown makes it easy.  Having a 
top-level shop preset choice with 10x the number of things in it is not 
easier, as it becomes too big to scan through.


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

Re: [Tagging] insurance health

[Greg Troxel]

Agustin Rissoli  writes:

> In Argentina we want to correctly tagging offices of companies dedicated to
> what we call prepaid medicine, by paying a monthly fee you access a series
> of medical benefits.
> We are hesitating between these tags:
>
> office=health_insurance
> It has no wiki, it has 185 uses, the majority in Belgium since it was
> created in 2013, they even have a preset in JOSM.
>
> office=insurance + insurance=health
> It has a wiki, curiously created by a Belgian user in 2018, it has 66 uses.
> It is the only documented insurance=* key.

While I see Joseph's point about what is normal, I think that's an
artifact of some, perhaps many societies.

I think if this is an office selling insurance of any kind, it should
have office=insurance and then a subtag.  I don't think it helps map
data users to make a second top-level tag.  Basically I think tags
should follow semantics as much as possible, when that's reasonable.

For what it's worth, around me, also in the US, my impression is that
most "insurance offices" are really "property and casualty insurance
offices".  This is for your car, and your house.  But typically not life
insurance so much, and not health.  (I am not sure about professional
liability and business interruption insurance.)

As always, we should step back and ask "when we add these tags, who will
use them, and why".  I see two points:

  some kind of overall statistics of types of businesses

  wanting to find a particular thing

In the case of office=insurance insurance=health, if that's what you
want, you can find it by searching for that just as well as searching
for office=health_insurance.

But if you  want to  ask "how many insurance offices are there and what
is the breakdown by type", it's much more natural to search one key and
switch on subtag, then to consult some information -- which we don't
really have a way to maintain -- that says office=insurance,
office=health_insurance and office=foo_insurance are all types of
insurance offices.

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

Re: [Tagging] building=public vs. building=civic

[Greg Troxel]

Martin Koppenhoefer  writes:

> While building=public seems defined, I have difficulties with building=civic, 
> which is according to the wiki

public building appears to have its origin as a legal term, and I don't
see it as a type of building at all.  In the US the term might be
"public accomodation" and an example might be the notion that if as part
of what you do the public comes to buy food, watch a play or anything
else like that -- even if it's private property and you charge them, and
could tell disagreeable people to leave -- then you have obligations to
provide access to disabled people.  But this doesn't mean that "public
accomodation" should be any kind of top-level tag; at best it's a minor
property saying if these sorts of rules apply.

> A building hosting any civic amenity (town hall, library, swimming pool).

My sense (en_US) is that this means "some kind of function that is 1)
broadly available to the public and 2) operated by the government".


> For example I’m asking myself whether structures like wastewater
> treatment or recycling centers would qualify as building=civic.

wastewater treatment, no - public is not welcome.  It is industrial.

recycling center; Probably.

> Or shopping malls? Cinemas? Private gyms?

No, all just random private things the public goes to.

> Power stations?

No, public unwelcome.  industrial

> Universities?

No.  Often not government, sometimes is, but it is a thing all by itself
and calling it civic is not helpful.

> Restaurants?

No.  Not government.  We have an amenity=restaurant tag.  Labeling the
building is not helpful.  Plus, often there are multiple things in a
building, and one tenant does not define the building in any useful
sense.

I think building=civic blurs use and government/not and shouldn't be
used *at all*.


To me, this is an example of people searching for tagging, disconnected
from an articulated purpose of how data consumers would use the tags.


> I’ve looked at random internet dictionaries, Cambridge doesn’t have a
> lemma for civic building and defines civic “ of or belonging to a city
> or citizen” (not very helpful I’d say)

It's not helpful.  (Civic also can be used as "civic duty" and "civics class".)

> IMHO the building=civic page should be discussed and improved, ideally
> by giving a definition rather than a list of examples

I think it should be withdrawn entirely.


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

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

[Greg Troxel]

brad  writes:

> How many trails are there that are not shared use?

In my town, most of the town-owned conservation land has rules that say:

  trails shown on the official map may be used by hikers, bicycles and
  horses

  other trails may be used by hikers only


So there are a lot that are not shared use.

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

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

[Greg Troxel]

Snusmumriken  writes:

> On Thu, 2020-04-02 at 22:24 +1100, Andrew Harvey wrote:
>> just usually only a certain kind of bicycle.
>
> Well, that's the problem, if one can't travel on a certain way with a
> general purpose bicycle, then it shouldn't be tagged highway=cycleway 

I agree, and I think this is the point.

We don't use "highway=unclassified" for a road that cannot be used by a
passenger car and is only passable with an extreme-high-clearance 4WD
vehicle.


As for path, I see

  highway=cycleway
and
  highway=path bicycle=designated

as equivalent.  And same for footway/foot=designated.

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.

Basically if you can walk on it in dress shoes, not get dirty, and not
get ticks, it is footway, and if you ought to have hiking shoes, it is
path.

I realize this is controversial, but it's another data point.


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

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

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

[Greg Troxel]

Martin Koppenhoefer  writes:

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

There are lots of things that are like many other things, as many came
from various places.

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

Yes, but that says "functions as", not "meets the picky definition of
the osm tag place=square".  And if written by Americans, those words are
colored by their understanding of meaning.

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

I never had the impression adjacent architecture mattered.

> 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

What I meant is that there are many places with square in the name that
aren't, and I think we're leading to mistagging due to different
understandings of words.  I know the OSM tagging system says that tokens
in tag mean what they are defined, not what they seem to say, but
interpreting the tokens as words with national meaning is too easy.

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

Yes.  Except that "neighborhood" is probably even not quite right.   In
New England usage the indistinct extent of "Foo Square" is much smaller
than what one might call a neighhborhood.

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

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

[Greg Troxel]

Martin Koppenhoefer  writes:

> sent from a phone
>
>> On 29. Mar 2020, at 17:23, Greg Troxel  wrote:
>> 
>> Really it is a place=neighborhood
>> with an indistinct boundary, even if there is a bit of eurosquare there.
>
> the fact there is a neighborhood which takes its name from a square
> does not imply there cannot also be a square at the same time, likely
> with different boundaries.

Yes, but since the name refers to a (small) neighborhood, assigning that
same name to the hard-surfaced gathering place is wrong and making
things up to fit euro notions which do not apply.  Really, it seems like
you are trying to shoehorn european definitions into US naming when it
is just not the way it is.

> Although it could explain why people tag place=square to neighborhoods

I think people tag place=square because they have not been through this
discussion and they assume that place=square is a locality-type tag that
refers to an indistinct named region that is an intersection and the
things near it.  That's what speakers of en_US would assume, not having
read a detailed definition that says otherwise.

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

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

[Greg Troxel]

Paul Allen  writes:

> On Sun, 29 Mar 2020 at 00:55, Greg Troxel  wrote:
>
>> Paul Allen  writes:
>>
>> > I can think of one US city square which has "square" in the name
>> > (not square shaped, though) that is rather well-known.  If you
>> > can't think of it the ball will drop eventually, at midnight on Dec 31st.
>>
>> But is that a place=square?  That is simply an intersection which is
>> called square.  There is no hard-surfaced area for people separate frrom
>> the roads.
>
> The only pictures of it I've ever seen were all full of people standing
> around.  I'll take your word for it.

Probably that's during new year's eve when all the roads are shut down
and there are people in many more places than usual.

I did find a bit of a pedestrian area that fits the Euro definition of
square, on looking further.

But that area is not what is meant by "Foo Square" in the US.  Such
names refer to an indistinct area around the named intersection.
Joseph Eisenberg summed it up well in the Harvard Square case, and I
think the same applies here.

In OSM, there is a way in Times Square with place=square.  However, it
includes roads and bits of sidewalk in some places, so that is not
matching what has been discussed.  Really it is a place=neighborhood
with an indistinct boundary, even if there is a bit of eurosquare there.

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

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

[Greg Troxel]

Joseph Eisenberg  writes:

> "taking "Harvard Square" as an example,
> that refers to an area around the road junctions.  It includes the
> sidewalks, and it includes the businesses and buildings that are on the
> roads that border the center, and even includes things that are perhaps
> 50-100m down side roads, as long as they are sort of part of the same
> logical larger place."
>
> In that case use a place=neighbourhood node, since this is a named
> part of a larger settlement, aka "a neighbo(u)rhood"

That sounds right to me.

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

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

[Greg Troxel]

Paul Allen  writes:

> I can think of one US city square which has "square" in the name
> (not square shaped, though) that is rather well-known.  If you
> can't think of it the ball will drop eventually, at midnight on Dec 31st.

But is that a place=square?  That is simply an intersection which is
called square.  There is no hard-surfaced area for people separate frrom
the roads.

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

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

[Greg Troxel]

Martin Koppenhoefer  writes:

> Am Di., 24. März 2020 um 18:23 Uhr schrieb Greg Troxel :
>
>> So one definition is
>>
>>   a square is an area with an indistinct boundary that is known by a
>>   placename by most locals.
>
> I would rather say "distinct" boundaries".

This leads me to understand how we are not understanding each other!


I think you are saying that the open, typically hard-surfaced, typically
square area that is typically contained within roadways, is exactly the
square.  That one should draw a way around that area, such that no roads
are in the way, and typically no buildings, and then place=square should
be tagged on the way.  In other words, the square is only that area, not
the nearby roads, not the buildings that are across streets from the
square, and not buildings that are 50m down a side street from the
square.

For a US(New England) square, taking "Harvard Square" as an example,
that refers to an area around the road junctions.  It includes the
sidewalks, and it includes the businesses and buildings that are on the
roads that border the center, and even includes things that are perhaps
50-100m down side roads, as long as they are sort of part of the same
logical larger place.  This is what I mean by indistinct, as each shop
farther way is somewhat less "in Harvard Square" (and eventually
somewhat more "in Central Square" as you head towards Boston), but there
is no shop you can point to and say "this is the last shop in Harvard
Square on this side of Mass. Ave."  One would say that a store on one of
those streets is "in Harvard Square".  No one would use the phrase "on
Harvard Square".

So our square is a place, grown up around an intersection, and grounded
by name in that intersection.  Which i think amounts to "Things called
squares in New England are very rarely place=square in OSM, and
certainly having square in the name is not a presumption that it is
place=square."




>> Almost always there are multiple roads intersecting, and typically it
>> has some degree of importance (commerce, cultural, historical, or
>> other) that is locally notable.

> question of size. Small square will typically have less importance than
> bigger ones.

Agreed - just that there is some local in the math sense max of
notability, not that they are equal.

>>   There may or may not be an open area where people can gather.
>
> there must be an open area (a square _is_ an open area), but it may not
> always be possible for people to gather (in particular while the space is
> occupied by traffic, parked vehicles, lawn that is not accessible, a bus
> station, etc.), although in extreme situations (think riots, political
> demonstrations, ...) these spaces could probably be used to gather even if
> it wasn't possible under normal conditions.

I find the notion of an open area to gather being necessary, while it
being ok that they perhaps cannot gather to be very strange.   I think
you don't mean "people could stand in the middle of the street", in
which case every intersection is a square.

>> Typically the name is not primarily associated with the location as
>> a settlement, although almost always people live there.
>
> people will not live on a square, they might be living around the square,
> but you can also find squares in business districts where nobody lives. The
> definition is not about usage, but about spatial configuration.

See above about the polygon on the open space, vs the region.  I
understand you now.

>> To have this make sense, we really need a definition that one can read
>> while standing someplace and declare it to be a square or not a square.
>> I remain quite skeptical.
>
> squares are like streets, but unlike streets which are made to move,
> squares are made to stay.

I don't find that clear enough.  Streets were made for walking and for
horses, and now they are used by cars.

What about a grassy area surrounded by streets.  We call that "town
common" usually (even though people may not bring their animals to graze
on it), but we would not call it a square, almost always.  


I have concluded that we have very few squares in the US, so I am pretty
unconcerned, as long as it's clear that there is no basis for "Foo
Square" to be presumed to be an osm square.

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

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

[Greg Troxel]

[kind of a joke about NY and New England; there is quite the rivalrly]

What I take away from this exchange with you is that it is difficult to
know what "square" means, and this it is unlikely that people will
arrive at similar notions.

Around here, squares are not square.  (Oral tradition is that our roads
used to be cow paths.)   So one definition is

  a square is an area with an indistinct boundary that is known by a
  placename by most locals.  Almost always there are multiple roads
  intersecting, and typically it has some degree of importance
  (commerce, cultural, historical, or other) that is locally notable.
  There may or may not be an open area where people can gather.
  Typically the name is not primarily associated with the location as a
  settlement, although almost always people live there.

but by then it is so watered down, it might as well be place=locality.

To have this make sense, we really need a definition that one can read
while standing someplace and declare it to be a square or not a square.
I remain quite skeptical.



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

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

[Greg Troxel]

Martin Koppenhoefer  writes:

> Am Mo., 23. März 2020 um 18:47 Uhr schrieb Greg Troxel :
>
>> We need it for en_US, too, because in the US, at least in New England,
>> everybody knows what Square means and it is different from what this
>> thread is discussing.
>
> Think about pre-60ies urbanism. And "new urbanism", for example.

Sorry, too confusing!

> Here are some examples in New England (I do not know them from visiting,
> but they are obvious from looking at the map):
> https://www.openstreetmap.org/way/530038747

not tagged as place=square.  not in New England!  (seriously, New York
is not part of New England)

Yes, uses Square in name and fits the eurodef.

> https://www.openstreetmap.org/way/474864229

does not use sqaure in the name and is not place=square.

Not clear if it really functions as a eurodef-square.

> https://www.openstreetmap.org/way/474864229 Union Square

wrong link, but guessing you mean
https://osm.org/go/Zct8XcGSc--?layers=N then that seems like maybe it
fits and is named.

> Also this could be a square:
> https://www.openstreetmap.org/#map=19/39.29345/-76.60253

could be, but it could also just be a bit of grass.

> (sorry no time for more examples now)

That's fine, but the point is not that we have zero things in the US
that meet the Euro definition of square.  It is that we have many things
that have square in the name that do not, and therefore that inhabitants
of the US, or at least New England, do not relate at all to the EURO
definition of square.

Here is the most well known thing named square in New England (six
states):

  https://osm.org/go/ZfI4p0cT9--

and note the green area to the NE is not part of Harvard Square - it is
"Harvard Yard", which is a thing near Harvard Square.


Here's another example of someting with Square in the name that is not a
place=square

https://osm.org/go/ZfI6Neyh0--

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

Re: [Tagging] Addresses with PO Box, and other delivery type addresses.

[Greg Troxel]

Tobias Wrede  writes:

> It seems I have a different understanding of the concept PO
> box. Around here if you have a PO box mail is delivered there and you
> go yourself pick it up, convenient for people who are rarely at home
> or get huge amounts of mail. In more rural areas I have seen letter
> boxes in one central point of a several km2 area or a box/bag at the
> next major road where mail is delivered to. Again you go there
> yourself to pick it up.

This is how it is in the US, too.

> I must admit I fail to understand your kind of PO box. One delivery
> company delivers to the PO box (which address/location is known) and
> then some other guys pick the mail up there and take it to your home
> which they don't know anything about? Sounds strange to me.

Also doesn't happen in the US.  PO boxes belong to the post office, and
only they deliver to them.  Most (all?) online ordering will only allow
shipment to a PO BOX if shipping is via the post office.

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

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

[Greg Troxel]

Joseph Eisenberg  writes:

> That is why we need an actual definition of place=square that isn't
> simply "a town square", because I need to be able to translate it into
> Indonesia, for people who have never seen a European town square. I
> suspect that Japanese and Korean will have the same problem, along
> with many other non-European languages.

We need it for en_US, too, because in the US, at least in New England,
everybody knows what Square means and it is different from what this
thread is discussing.

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

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

[Greg Troxel]

I just looked at this discussion and am a bit baffled.  We do have
notions in OSM that tags mean what they are defined, not what the words
might mean, but I think this situation is even more difficult.

I live in New England, and we have lots of place names "Foo Square".
Perhaps the biggest is "Harvard Square", and basically that's an area
surrounding the junction of some roads, and nearby is a rapid transit
rail ("subway", we call it in Boston) and a college that for some reason
is famous.

Less notably lots of towns have things called squares.   They are
essentially never square, and rarely associated with areas of grass or
other places for people to gather.

There are also lesser squares, basically intersections that didn't used
to be that notable and now have a "Corporal John Smith Memorial Square"
sign.

So my point is that if someone wants to communicate to normal people,
using "square" as a type of object in search is not going to work, at
least in my corner of the US.   Here, people simply map a name "Harvard
Square" to a place.  Someone hearing "Waverley Square" not konwing
anything about it would assume that 1) there are multiple roads and 2)
that whatever Waverley Square is, it is more interesting from some vague
shopping/commerce/civic/historic sense than the things that aren't quite
in it and 3) really they wouldn't assume much more.


So perhaps then if "place=square" is supposed to have some semantics,
then Harvard Square should be "place=locality" and maybe it is.  (Even
if people live there, the name as used doesn't really represent that.)

User interfaces will have to be careful to avoid users being confused
that Foo Square is a type of osm-square.


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

Re: [Tagging] Addresses with PO Box, and other delivery type addresses.

[Greg Troxel]

Joseph Eisenberg  writes:

> I agree with "addr:mail=*" as a tag to add to guesthouses, shops,
> farms and other businesses, as a way to send letters and perhaps small
> parcels, which might be delivered to a PO Box or some rural delivery
> system, rather than to the physical address of the shop, business or
> other public feature.

If a business *publishes* a mailing address, then that seems reasonable,
but it also seems to be veering into OSM as a database of businesses vs
a map.  But I can see the point that the mailing address of a business
is not so different from the website URL and phone number.

> But I would caution against adding this to private house features, due
> to privacy laws in some countries.

Agreed.  At best it would be highly rude, and I think it's important not
to have a general perception bythe world that OSM is rude.  Many people
seem to think that anything they can find out should be published, and I
think mappers need to ask themselves what should be published.

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

Re: [Tagging] Barbecue disposal bins

[Greg Troxel]

Graeme Fitzpatrick  writes:

> Is anyone as irritated as I am by the shortening to 'bbq'.
>
> Sorry, no - it's a standard term, at least around here! :-)

I am irritated by the misuse of barbecue to refer to large class of
anything to do with a grill.  Barbecue properly refers to cooking at low
heat for an extended period of time while drinking beer and issuing
cantankerous opinions, and is quite different from most uses of grills
and charcoal!

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

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

[Greg Troxel]

"ITineris OSM"  writes:

> I need help in tagging a special kind of survey points: geodesic towers.

Are they called "geodetic" towers?

> These are tubular concrete structures, with usual steel triangulation tripods 
> on their top.

Wow, those are pretty big!

> They have the precise benchmark on the ground level, the tower is erected so 
> that it's visible from far, being higher than the trees around.
> They form the base of the national reference grid.

I'm not sure if you mean "benchmark" as vertical control, or if you mean
the horizontal control mark and then the tower is basically over it, to
translate it up along the plumb line.


So the control point is man_made=survey_point.  Then there is a tower
which is physcially notable regardless, and the tourist bit.  OSM's
representation does not really admit multiple primary tags on objects,
except that sometimes they dno't conflict.

I'd put in man_made=survey_point as a node for the thing on the ground,
some survey_point:geodetic_tower=yes subtag on that (to inform those who
care about the survey aspect of that), maybe some kind of height tag,
and then draw a way around the tower and tag that as man_mde=tower
and/or tourism.

I don't think we should try to drag towerness and being an attraction
into the survey_point namespace; it seems easy enough to dneote multiple
properties separately.
[>


>  
>
> They could be tagging as  style="font-family:Courier 
> New,Courier,monospace;">man_made=survey_point because their 
> main purpose is being a geodesic reference point.
>
> However, they could be a  style="font-family:Courier 
> New,Courier,monospace;">man_made=tower, for being a tower 
> emerging from the surface - and to distinguish it from brackets, benchmarks 
> or pavement rivets.
>
> Furthermore, additional functions can be connected to the latter only:
>
> Some of them are tourist attractions, like this 
> https://hu.wikipedia.org/wiki/Cs%C3%B3v%C3%A1nyos#/media/F%C3%A1jl:Csovanyos2014_12.jpg.
>  It is a tower:type=observation.
>
> If it's rigged with GSM and microwave antennae, it's  style="color:#ff;">tower:type=communication.
>
>
>  
>
> (And of course you may add the  style="font-family: Courier New , Courier , 
> monospace;">triangulation_point=yes tagging.)
>
>  
>
> So how would you tag them?
>
>  
>
> Greets,
> Ákos
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
w

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

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

[Greg Troxel]

Anne-Karoline Distel  writes:

> I've been surveying benchmarks for the past four months and I would like

I'm glad to hear that.

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

I think this is blurring two separate concepts: a particular logical
purpose of passive survey control mark, and the form of such a mark.

In the US, we use "benchmark" to refer to a passive mark for elevation,
essentially always by leveling.  We use "triangulation station" for
passive marks for horizontal controls, and I'm not sure but perhaps
ellipsoidal station for those which use GNSS to establish 3d coordinates
relative to the ellipsoid of a datum.

For all of these, the big point is that there's some reference that can
be recovered, and the exact physical form is not that important.

While the above words are guided by my understanding of US practice, the
historical separation of horizontal and vertical control networks and
the move to GNSS and ellipsoidal positions is I think pretty universal.

So I would suggest that there be tags for type/purpose, keeping in mind
that some physical marks were both horizontal and vertical controls.

It makes senes to have further tags for the physical type of mark.
>
> 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.

That sounds very UK specific.   In OSM I think we need to have
descriptions that people everywhere can interpret and make sense of.

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

Re: [Tagging] amenity=faculty?

[Greg Troxel]

Mateusz Konieczny via Tagging  writes:

> Universities may have faculties, that often deserved to be mapped separately.
>
> For example university may take a large area, possibly disjointed area across 
> the city
> but Faculty of dentistry, Faculty of forestry, Faculty of mathematics etc may 
> be
> possible to be mapped as an area/node.
>
> Currently typical way to do that is to either
> - map name on building
> - create fake amenity=university with amenity=university
>
> It seems to me that amenity=faculty would be useful.

Perhaps, but beware that in US English, this is bizarre usage.  Faculty
refers to the set of people that are professors, not a place, and not a
subdivision of a university.

As an example, one well-known University has within in
  School of Science
  School of Engineering
  School of Architecture of Planning
  School of Humanities, Arts, and Social Sciences.
  School of Management
and
  College of Computing

I'm sure other universities contain within them colleges, and I suspect
"school" is fairly common.

Really my point is that "Faculty of mathematics" is going to be
confusing to en_US speakers.  I have no idea if it's used in en_GB, but
I've never heard of it.


To your real point, it does seem make sense to have a tag for a
subdivision of a university.   But, often these sub-parts are
administrative and not physical.

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

Re: [Tagging] Disputed territory mapped as a country

[Greg Troxel]

Martin Koppenhoefer  writes:

> Mateusz, offlist deliberately.

While we're at it, could the list admins fix the BROKEN REPLY-TO?

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

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

[Greg Troxel]

Jmapb  writes:

> Hi all, just noticed this passage on the cycleway=* wiki page (
> https://wiki.openstreetmap.org/wiki/Key:cycleway ):
>
>> For mapping a separate path (on a separate way) dedicated to cycling
>> traffic use highway=cycleway. Foot traffic is restricted on these paths.
>>
>>   *  Do not use highway=cycleway on paths for both cyclist and foot
>> traffic (such as shared paths). Instead use highway=path with
>> bicycle=designated and foot=designated. Add also segregated=yes or
>> segregated=no) as applicable.
>>    * For paths where cycling is not permissible use highway=footway.
>> If cycling is permissible even if it is not signed but legally
>> permissible on a path, use highway=path (and a combination of the
>> segregated key and designated tag as applicable) and not highway=footway.
>
> (This was added by wiki user Aaronsta last May, with no change description.)
>
> Does anyone know if there was a discussion, here or elsewhere, that led
> to this change?

This smells like wikifiddling.

> My own impression over the years has been that mappers use
> highway=cycleway on anything that primarily for bicycle traffic, and add
> access keys for any other permitted traffic. Similarly for
> highway=footway. So "highway=cycleway + foot=yes" and "highway=footway +
> bicycle=designated" are quite common. Is there a general consensus that
> these are better mapped as highway=path?

Overall, I have come to believe that

  highway=cycleway

is *exactly* the same as

  highway=path bicycle=designated

and that any renderer or router that treats them differently is wrong.

However there is the messy issue of default surface values, avoidable by
tagging the surface.

> If so, we might want to consider standardizing the highway=cycleway and
> highway=footway wiki pages with this same rule. And also editing the
> highway=path page, which currently says it's not for use in urban
> situations.

The notion of urban vs not is messy.  I agree that's been part of the
evolving not-really-consensus over the last 10 years.

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