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

[Minh Nguyen]

Vào lúc 04:08 2024-01-28, Greg Troxel đã viết:

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.


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

--
m...@nguyen.cincinnati.oh.us



___
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

[Minh Nguyen]

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.


--
m...@nguyen.cincinnati.oh.us



___
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

[Minh Nguyen]

Vào lúc 16:01 2024-01-27, Greg Troxel đã viết:

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


Thanks, I added this to the existing examples [1], though the summit 
sign unusually states the elevation in both units.


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.



   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.



   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.


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.



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


[1] https://wiki.openstreetmap.org/wiki/Special:Diff/2654695

--
m...@nguyen.cincinnati.oh.us



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

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

[Minh Nguyen]

This is a second request for comments about documenting the option to 
express an elevation in feet within the ele=* key. Here is the full 
proposal:




The first RFC took place in December 2021 [1], but I put the proposal on 
hold for a couple reasons that are now resolved, as detailed in the 
accompanying forum topic. [2]


If possible, please discuss this proposal on its talk page or in the 
forum topic, which I will be monitoring regularly. Thank you in advance 
for your feedback.


[1] 
https://lists.openstreetmap.org/pipermail/tagging/2021-December/063223.html
[2] 
https://community.openstreetmap.org/t/rfc-documenting-feet-as-an-an-optional-elevation-unit/108543


--
m...@nguyen.cincinnati.oh.us


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

Re: [Tagging] [Talk-GB] Fords and how to provide information to help with routing apps

[Minh Nguyen]

Vào lúc 01:00 2023-07-05, Warin đã viết:

Many 'fords' in Australia are normally dry.

When the river runs high those fords can become impassable for quite 
some time .. weeks..


Those who travel there know this, those that don't .. well the Police 
normally place 'Road Closed' signs out.


This sounds like a situation where the waterway is already tagged 
intermittent=yes, so it stands to reason that the ford would also be 
intermittent=yes. (The two are accessible exclusively of each other.)


--
m...@nguyen.cincinnati.oh.us



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

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

[Minh Nguyen]

Vào lúc 01:47 2023-06-27, Martin Koppenhoefer đã viết:

On 26 Jun 2023, at 20:50, Minh Nguyen  wrote:

For what it's worth, the Sporting Goods Retailers subindustry in NAICS includes "gun 
shops".



what’s the category for multi role combat aircraft or heavy battletanks?


Aircraft artillery manufacturing
https://www.census.gov/naics/?input=332994&year=2022&details=332994

Aircraft dealers
https://www.census.gov/naics/?input=441227&year=2022&details=441227

Military flight instruction training
https://www.census.gov/naics/?input=611512&year=2022&details=611512

Tanks, military (including factory rebuilding), manufacturing
https://www.census.gov/naics/?input=336992&year=2022&details=336992

Military vehicles (except trucks) merchant wholesalers
Tanks and tank components merchant wholesalers
https://www.census.gov/naics/?input=423860&year=2022&details=423860

Heavy equipment operation schools
https://www.census.gov/naics/?input=611519&year=2022&details=611519

Why do you ask? 🤔

--
m...@nguyen.cincinnati.oh.us



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

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

[Minh Nguyen]

Vào lúc 05:14 2023-06-26, Greg Troxel đã viết:

Mateusz Konieczny via Tagging  writes:


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.


I for one support the drawing of hyperblobs.

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

--
m...@nguyen.cincinnati.oh.us



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

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

[Minh Nguyen]

Vào lúc 10:23 2023-06-22, Mateusz Konieczny via Tagging đã viết:

Jun 21, 2023, 15:51 by g...@lexort.com:

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.

Though if some specific term is primarily legal term and has crazy
definitions varying across world - then using a different term is a 
better idea,

if such term is available and is less confusing.


I think that's a good approach in this case. Laws and regulations often 
prefer technical-sounding terms like "weapon" and "firearm" over more 
colloquial terms like "gun" in order to precisely redefine them within 
the scope of a particular law. So when data consumers see "weapon" or 
"firearm", they may be inclined to think we're specifically referring to 
that law, but we send craft-mappers out into the field, not government 
inspectors.


The problem with relying on laws to define the plain meaning of a term 
is that most laws aren't intended to regulate language. A typical law in 
the U.S. comes with a definition section that _redefines_ common words 
so that it can reuse them as shorthand later in the text, but this 
doesn't necessarily bind ordinary people's use of the terminology. If 
the law intends to promote consistent external usage of the term, then 
it'll probably call for signage or perhaps a public awareness campaign.


There was a rather spectacular episode last year when a mapper failed to 
comprehend this nuance and insisted on redefining service=driveway in 
Asia based on a definition in an obscure California law about where city 
governments must build curbs and sidewalks. [1]


[1] 
https://lists.openstreetmap.org/pipermail/talk/2022-September/087734.html


--
m...@nguyen.cincinnati.oh.us



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

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

[Minh Nguyen]

Vào lúc 06:47 2023-06-23, Martin Koppenhoefer đã viết:
I believe the US is an exception then, at least the current wiki 
confirms what I wrote (and in this case I didn't write it myself ;-) ) , 
from highway=motorway:


Typically highway 
=motorway should be 
*_used only on roads with control of access 
_*, or selected 
roads with limited access 
 depending on the 
local context and prevailing convention.


Generally roads with control of access 
 are proclaimed 
in government documents, and have an official status as a controlled 
access road, sometimes this can include the term motorway, freeway or 
expressway among others in the road name. These kinds of roads usually 
have a special designation by the law, with a set of laws specifically 
applied on them. Generally some restrictions are placed on the kind of 
vehicles or traffic which can be on roads which should be classed as 
highway =motorway, such 
as no pedestrians, bicycles, livestock, horses and so on.


There's probably little disagreement over these criteria as guiding 
principles, but the question is how strictly to apply them. I can point 
to technical publications, signs, laws, etc. that definitively state the 
existence of a particular freeway/motorway/expressway, but I can just as 
easily point to exceptions, some of them rather absurd. The definition 
already recognizes this possibility by including some "weasel words" 
(generally, usually). Moreover, if we venture into a region with less 
developed transportation infrastructure, the contrast between a motorway 
and everything else will be stark enough that formalities like signs 
would be completely unnecessary in all cases.


Ultimately, OSM is a geodatabase, not a legal database. The purpose of 
this definition or any other tagging definition is to ensure some degree 
of consistency in what the tag is applied to. 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=*.


--
m...@nguyen.cincinnati.oh.us



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

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

[Minh Nguyen]

Vào lúc 10:44 2023-06-19, Marc_marc đã viết:

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


I'm not sure it's possible to completely escape this situation with any 
shop category. A drive-through liquor store can be famous for its deli 
meats and live fishing bait [1]; a "supermarket" can specialize in 
candy, mattresses, floor tiles, and tool sheds [2]; and a laundromat can 
wash your car while you alternate between the treadmill and tanning bed 
[3]. Not unsurprisingly, there's also a gun store that doubles as a pawn 
shop and gold exchange. [4]


Imagine if shop=* could just take multiple values separated by semicolons...

[1] https://www.openstreetmap.org/way/175820359
[2] https://www.openstreetmap.org/node/10742957305
[3] 


[4] https://www.openstreetmap.org/node/6636023469

--
m...@nguyen.cincinnati.oh.us



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

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

[Minh Nguyen]

Vào lúc 16:26 2023-06-19, Greg Troxel đã viết:

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.


A gun store specializes in firearms and ammo, typically for recreation 
or self-defense. By contrast, a shop=sports 
sport=shooting;hunting;paintball would probably carry clothing and other 
gear, but wouldn't necessarily carry firearms.


"Weapons store" sounds to me like a military surplus store, which might 
sell firearms (and knives), but we already have shop=military_surplus 
for this kind of store.


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] navigational aid relation

[Minh Nguyen]

Vào lúc 02:56 2023-06-18, Martin Koppenhoefer đã viết:



Am Sa., 17. Juni 2023 um 21:48 Uhr schrieb Minh Nguyen 
<mailto:m...@nguyen.cincinnati.oh.us>>:


Here in the U.S., the meaning of an address depends on who's using it.
To the tax authorities, it refers to the whole parcel. To emergency
responders, it's either the building or the beginning of the driveway.
To the postal service, it's the mailbox, which can be at the door, at
the street curb, or even at the neighborhood entrance.



This is probably how these are effectively interpretated / used. If the 
number refers to the whole parcel (tax), isn't this then a valid point 
of view for emergency responders as well? Won't they help you on every 
spot of the parcel, or do they require you go either into the building 
or to the beginning of the driveway before they will rescue you?


Certainly, they want to get to you as quickly as possible, wherever you 
might be. But consider a non-urban scenario: an ambulance responding to 
a call from [1] likely needs to access the house, or at least make it to 
the beginning of the driveway. The address contains "Adams Road", but 
the house is physically located 100 meters closer to State Route 48 (as 
the crow flies). Because it sits on a "flag lot" [2], the parcel's 
centroid is also closer to SR 48. If an ambulance travels from the 
nearest station to the centroid of either the house or the parcel, it 
will be delayed by at least 4 minutes, which can be the difference 
between life and death. [3][4]


This is a mild example that I picked at random. It isn't hard to find 
other examples that would delay an ambulance by tens of minutes as they 
search for a river crossing. These delays have caused enough problems 
that the state has developed a comprehensive address dataset 
specifically for emergency responders that places each point at the 
beginning of the driveway (i.e., at the mailbox). [5]


Obviously, mapping the driveway makes a big difference too. But 
sometimes the most direct driveway is the least accessible option; an 
application might be better off reverse-geocoding the raw coordinates to 
an address and then matching the address to a street. [6]



Mappers here generally treat the address as an attribute of a building,
POI, or something else. [1] 




in Italy, we also treat the address as an attribute of a POI - 
additionally, because from all the possible (assigned) addresses, there 
will often be a principal / official one which the business uses in 
their communications (this is somehow disputed in the community, some 
people do not want to "duplicate" addresses, so they add the poi 
information on the entrance node, which is not fully correct obviously, 
because the POI is usually inside and not on the perimeter, and the 
entrance is not the same as the POI so it goes against the one object 
one element rule. We never use addresses on buildings though.


I think the difficulty is that some software is treating 
addr:housenumber as a primary feature tag in its own right, whereas it's 
actually just a secondary attribute. Unlike other secondary attributes, 
we allow it to stand alone without any other primary feature tag, 
because it's often difficult to describe what exactly is at an address 
using other tags.



So the address point's coordinates don't
necessarily have any relation to where you would navigate to.



IMHO this is a problem, the addresses we add should indeed have a 
relation with where they are assigned to. A postbox with an address that 
is not on the site where the address belongs to, should not get "addr:*" 
tags of the far away place. There is "contact:street", 
"contact:housenumber" and others to add addresses that are elsewhere, as 
referers.


To clarify, in the scenarios I'm describing, the _address_ is relevant 
but not necessarily the coordinates where the addr:housenumber _point_ 
is located.


[1] https://www.openstreetmap.org/way/1182950336
[2] A parcel that is shaped like a flag on a flagpole, the flagpole 
being a narrow strip of land that follows the long driveway to the main 
street.
[3] 15 minutes 
<https://map.project-osrm.org/?loc=39.267173%2C-84.256757&loc=39.282289%2C-84.239237>
[4] 19 minutes 
<https://map.project-osrm.org/?loc=39.267173%2C-84.256757&loc=39.279540%2C-84.238894&loc=39.282289%2C-84.239237>
[5] 
<https://gis1.oit.ohio.gov/OGRIPWeb/WebContent/LBRS/LBRS_Specifications_3_FINAL.pdf#page=6>

[6] https://www.openstreetmap.org/way/34617394

--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] navigational aid relation

[Minh Nguyen]

Vào lúc 21:59 2023-06-16, Volker Schmidt đã viết:
When trying to reach a destination that is defined by a complete address 
(city, street name, house number or name) is that the last meters of the 
route are, potentially,  much different for a 
ciclist/pedestrian/car-driver/delivery-van/ambulance/...
One of the many problems is that we would need for any given address a 
navigation aid for each of the potential means of transport.


I have come across one aspect of this when I noticed that Amazon 
Logistics staff systematically changed access tags on driveways around 
here from "private" to "yes" (or similar).


Micromapping correctly the last meters for all the different means of 
transport is the correct theoretical solution. But is it practical ?


Navigation aid?
In Italy the house numbers are assigned to the pedestrian entrance point 
for the house/business/shop/airport/...


You're quite fortunate that the meaning of an address is unambiguous in 
Italy. At least you can be sure that a pedestrian route will lead to the 
main entrance, even if other modes aren't as well-served. Each country 
has different addressing standards, so what may be sufficient in one 
country might be insufficient in another.


Here in the U.S., the meaning of an address depends on who's using it. 
To the tax authorities, it refers to the whole parcel. To emergency 
responders, it's either the building or the beginning of the driveway. 
To the postal service, it's the mailbox, which can be at the door, at 
the street curb, or even at the neighborhood entrance.


Mappers here generally treat the address as an attribute of a building, 
POI, or something else. [1] So the address point's coordinates don't 
necessarily have any relation to where you would navigate to. But 
addr:street is usually either the name of the street that the building 
faces, or the name of the street that the letter carrier uses to get to 
the mailbox (wherever it is). So at least we know that street is more 
related to the feature than the other nearby streets.


For the majority of cases, that assumption is a good one for navigation, 
but not always. For example, in the suburbs, a house at a street corner 
often has a mailbox at the curb along one street (hence addr:street) -- 
but to get to the front entrance, you use a walkway from a different 
street. To illustrate the point, these examples are fully micromapped 
with mailboxes, entrances, driveways, and walkways:


Mailbox on one street, car and pedestrian entrances on another:
https://www.openstreetmap.org/way/37018678

Mailbox and pedestrian entrance on one street, car entrance on another:
https://www.openstreetmap.org/way/38064995
https://www.openstreetmap.org/way/34618091

Mailbox and car entrance on one street, pedestrian entrance on another:
https://www.openstreetmap.org/way/37018646

Mailbox on one street, car and pedestrian entrances accessible from 
either street:

https://www.openstreetmap.org/way/34618083

Everything on one street, but addr:street names a different street. 
(What's a rule without an exception?)

https://www.openstreetmap.org/way/32602856
https://www.openstreetmap.org/way/34618143

These are trivial cases where getting to the wrong street isn't much of 
a problem for most people, though enough of this misdirection could 
throw a delivery person off schedule. If the style of micromapping in 
these examples becomes widespread enough, then the addr:street-based 
heuristic becomes unnecessary. But that's a herculean task, even bigger 
than mapping all the addresses in the first place.


Take an address in a pedestrian area within a limited-access zone in my 
city.
Take car access. During the night the car access for drop-down is 
somewhere in walking distance outside the pedestrian area, but within 
the limited-traffic zone (which is not active at night). During the day 
it is most likely a park-and-ride location outside the city centre.


This is another good reason why I'd advocate for objectively 
micromapping features that data consumers (whether routers or geocoders) 
could recognize as navigable points or not, depending on the situation. 
For the difficult, indescribable cases, there's already a catch-all site 
relation type.


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] navigational aid relation

[Minh Nguyen]

Vào lúc 11:48 2023-06-15, Sarah Hoffmann via Tagging đã viết:

On Thu, Jun 15, 2023 at 09:38:44AM -0700, Minh Nguyen wrote:

I neglected to mention another common heuristic: the geocoder can
automatically bias the address point toward the street named in addr:street
when coming up with a navigable point. The Mapbox Geocoding API is an
example of a geocoder that does this [1][2], though unfortunately neither
Nominatim nor Pelias has a similar feature so far.


You need to remember that routers are only one kind of client of
Geocoders and certainly not the most important by far. While a nice
gimmick, I certainly wouldn't consider it a main task of a geocoder to
return a routeable point. The main task is to return the place/object you
were searching for. In that sense, the root of the issue is that
routers usually underspecify their search query. If the query is
'airport Frankfurt', then the airport is what the geocoder returns. One can't
expect the geocoder to determine that what you actually wanted is the
street closest to the main entrance or the parking or the main bus stop.
'parking near airport frankfurt' does yield results although we'd have
to do something about priority ordering.


To be clear, all this talk about "navigable points" is about something 
that would supplement, not replace, the centroid coordinate that a 
geocoder already returns. If an end user searches for "airport 
Frankfurt", what Nominatim returns is quite sufficient for centering the 
map on the airfield. However, nowadays, the user also expects to see a 
row of buttons for navigating to a specific terminal, parking lot, or 
tram stop. This was not the case several years ago, but all you have to 
do is look at the most popular navigation applications to see why this 
topic keeps coming up.



Then again, none of this complexity is necessary if OSM has a publicly
accessible driveway or footpath leading right up to the building. A router
should consider that driveway or footpath to be part of the most direct
route.


Exactly. It would be kind of counter-productive to add all this
functionality to a geocoder. A good router has all the right
data structures to make an informed decision about the navigation start point
and also the information about mode of transport etc. A geocoder's
data structures are rather unsuitable to solve these examples.

The initial examples of Florian are quite telling in that way. The
closest road to
https://osm.zz.de/dbview/?db=addresses-nrw&layer=namemismatch#51.98796,8.57338,17z
would in fact be the service way right next to the buildings. The fault
is with the router who does not include non-accessible roads to
determine the access and thus finds the wrong road. If it would create a
full routing network that includes inaccessible service roads and footways,
it would be able to make the right decision and bring the car to the gate.


I agree that routers should consider inaccessible service roads more 
than they do now. However, this would not be a panacea. For one thing, 
if the router finds the nearest inaccessible service road to an airport 
centroid, more often than not, it will be along a vehicle service road 
(VSR) for ground support equipment, surrounded by taxiways or even runways.


Nominatim returns a centroid for the San Francisco International Airport 
that's about 80 meters from a VSR used only by airfield maintenance 
crews; this is the closest road. [1] The restricted entrance that most 
directly leads to the VSRs is almost 4 kilometers from the domestic 
terminal's front entrance. [2] (This is a real service road. Last week, 
from my armchair in Economy, I watched a maintenance vehicle wait at a 
stop sign on the VSR as my plane passed by.)


In more mundane cases, footways could definitely help a router send a 
ride-sharing driver directly to a drop-off point (albeit at the expense 
of a driver or cyclist needing to park their vehicle). This 
functionality is often lumped together with the idea of multimodal 
routing, but unlike true multimodal routing, it doesn't require looking 
up route schedules and timing transfers.



I'm not sure if there is any router around which does something even marginally
more clever than determining the closest road to the centroid. This even goes
as far as this:
https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=43.28293%2C5.38709%3B43.29579%2C5.38222#map=16/43.2885/5.3889
(starting point given as: "47, Rue du Rouet, Marseille")


Routers can only be more clever if they have more context. You gave an 
address to Nominatim, but all you ultimately gave to GraphHopper was a 
coordinate pair. For all GraphHopper knows, you need a route that begins 
on the Tunnel du Prado Carénage because you're already walking down that 
tunnel. (highway=trunk doesn't imply anything about foot=*.)


OSRM and Valhalla allow you to pass in a "

Re: [Tagging] navigational aid relation

[Minh Nguyen]

Vào lúc 08:29 2023-06-15, Sebastian Gürtler đã viết:

You only would have to change the wiki page Key:entrance and encourage
people to allow single nodes with the tag entrance=yes and addr:xyz
(like this: https://www.openstreetmap.org/node/10979019687) if it is not
obvious where the entrance to the property is. (What happened before for
the whole row of houses you still can see if you plan a route to "Am
Rehwinkel 19, Bielefeld" (from the point you are led to you don't see
any entrance nor the house due to a high hedge, and you sometimes see
people walking down the Voltmannstraße looking for entrances...
Difficult, because you would have to turn in "Am Rottmannshof" to get to
"Am Rehwinkel" ;-) )


I neglected to mention another common heuristic: the geocoder can 
automatically bias the address point toward the street named in 
addr:street when coming up with a navigable point. The Mapbox Geocoding 
API is an example of a geocoder that does this [1][2], though 
unfortunately neither Nominatim nor Pelias has a similar feature so far.


Essentially, even if the address point corresponds to a rooftop, it can 
figure out where the driveway entrance or freestanding mailbox is likely 
to be. Typically, this is pretty crude, just a matter of finding the 
point on the named street that's closest to the address point.


In your example, the entrance is on Am Rehwinkel not only because the 
address names Am Rehwinkel, but also because there's a hedge along 
Voltmannstraße. Ideally, a geocoder would compute a visibility graph to 
determine the most accessible street, blurring the lines between a 
geocoder and a router.


Then again, none of this complexity is necessary if OSM has a publicly 
accessible driveway or footpath leading right up to the building. A 
router should consider that driveway or footpath to be part of the most 
direct route.


[1] https://docs.mapbox.com/api/search/geocoding/#forward-geocoding 
(search for "routing")
[2] 
https://github.com/mapbox/MapboxGeocoder.swift/blob/10c497840c9e1142194563f402ddc903310a935d/Sources/MapboxGeocoder/MBPlacemark.swift#L446


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] navigational aid relation

[Minh Nguyen]

Vào lúc 00:26 2023-06-14, Florian Lohoff đã viết:

Management Summary:
  In navigation/routing the point the router is routing to is the nearest
  point on the routable network from the poi/address we like to navigate
  to. The nearest point may not be a location where the address/poi can be
  reached from.
  I suggest a navigational aid relation hinting the link between
  geocoding and router to use a different point on the routable network.


I agree that there is a need for geocoders to produce more 
routing-friendly locations than the centroid. Navigable points are 
nothing new in the field of location services. Most geocoders already do 
this, including some that are often used with OSM-based maps, although 
none are open source as far as I can tell.


I've written something of a white paper on the subject of navigable 
points. [1] The short story is that most scenarios would be well served 
by micromapping in OSM combined with some clever heuristics in the 
geocoder, without the need for a new relation type. I've provided some 
example OverpassQL queries to prove the concept, but in reality a 
serious data consumer would perform spatial queries or traverse the 
relation hierarchy more directly, without the help of a separate API.


With this heuristics-based approach, we can take advantage of the large 
and growing body of data that's implicitly optimized for routing. 
Mappers generally wouldn't have to familiarize themselves with routing 
engines; they can just map what they observe, but in greater detail.


When none of the heuristics applies, the last resort can be a site 
relation, using each relation member's role to clarify why the 
application might want to present the member as an option. I've used 
site relations in a few cases where a spatial query won't turn up any 
useful results.


For example, a nearby American football stadium [2] has multiple parking 
lots, but all of them are off-site, on the grounds of an amusement park, 
a college, and some office parks. A driver would only be interested in 
the parking lot that corresponds to the ticket they purchased. The 
parking lots are members of a site relation with the stadium. [3] We 
have no hope of precisely modeling ticket classes in OSM, but the 
application can simply list the lots by name and let the user choose 
manually.


Unfortunately, I'm unaware of any OSM-based data consumer that 
implements these heuristics, but routers aren't the only reason to map 
building entrances or site relations.


[1] 
https://wiki.openstreetmap.org/wiki/User:Minh_Nguyen/Navigating_between_entrances

[2] https://www.openstreetmap.org/way/296503400
[3] https://www.openstreetmap.org/relation/14507813

--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] date not in YYYY-MM.DD format should go into a sufix edtf ?

[Minh Nguyen]

Vào lúc 14:56 2023-05-29, Marc_marc đã viết:
a contributor change to wiki to tell that "For dates that cannot be 
expressed in -MM-DD format, such as approximate or uncertain dates, 
or times of day, use the end_date:edtf=* key in addition to this key. "


did you agree with that ?
start_date if full of not -MM-DD including Cxx for historical monument


This was in the section titled "OpenHistoricalMap", so the intention was 
not to provide guidance on tagging in OSM. OHM has long preferred EDTF 
over the "questionable, contentious or controversial" ad-hoc scheme that 
the start_date=* page has described for OSM. I added this passage about 
EDTF because sometimes OHM mappers get confused, entering the ad-hoc 
format in start_date=* and end_date=* and expecting it to do something. [1]


After making that change, I realized it was really confusing to have 
both OSM and OHM guidance about start_date=* or end_date=* on a single 
page, because the two projects have fundamentally different approaches 
to dealing with historical data (and for good reason). I split out a 
separate page for the OHM guidance so that the OSM guidance can be 
clearer to OSM mappers. Fortunately, these differences are confined to 
only a few keys. Otherwise, OHM has been following OSM's tagging 
conventions to a tee.


Having tried to use both formats in both projects, I do think EDTF is 
the better format overall, and I wouldn't mind seeing it used in OSM. 
However, the ad-hoc format does have one advantage in being able to 
express dates in the Julian calendar directly, rather than making 
mappers perform the conversion themselves.


[1] https://github.com/OpenHistoricalMap/issues/issues/547

--
m...@nguyen.cincinnati.oh.us



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

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

[Minh Nguyen]

Vào lúc 08:54 2022-12-30, Jmapb đã viết:

On 12/30/2022 2:22 AM, stevea wrote:
I agree with Mateusz here:  whether to tag a way after the name of a 
route which includes it (if it didn't have a name=* tag beforehand) 
isn't a "one size fits all" situation.  It's difficult to describe 
what the right thing to do is in all cases.


I've also generally avoided doing it on bridges, lest the trail name be 
mistaken for a bridge name. (I know bridge:name=* exists but plenty of 
mappers still use name=*.)


I've found that mappers are less inclined to put bridge names in name=* 
once enough man_made=bridge areas are mapped in the vicinity. Granted, 
it's much less common for mappers to bother mapping bridge areas for 
pedestrian and bike bridges. That requires considerably more squinting 
at aerial imagery.


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Foot / sidewalk access tagging

[Minh Nguyen]

Vào lúc 17:29 2022-12-18, Zeke Farwell đã viết:
On Sun, Dec 18, 2022 at 6:33 PM Minh Nguyen 
<mailto:m...@nguyen.cincinnati.oh.us>> wrote:


Vào lúc 15:00 2022-12-18, Zeke Farwell đã viết:
 > I'll try to answer the original question as succinctly as
possible.  As
 > I understand it, the combination foot=no + sidewalk=separate means
 > walking is not allowed at all on this street and the sidewalk
belonging
 > to this street is mapped as a separate way.  Since the sidewalk
belongs
 > to the street, foot=no applies to it as well.  It must be a sidewalk
 > where walking is not allowed since walking is not allowed
anywhere on
 > this street.

Does any router actually interpret access tags as you're describing?

It seems like quite a stretch that a router would automatically infer a
sidewalk's access tags from some parallel roadway,


Perhaps I should not have aimed for brevity.  I would not expect a 
router or any other data consumer to infer access tags from a parallel 
way.  In my theoretical sidewalk where walking is not allowed I would 
expect the separately mapped sidewalk way to also be tagged with 
foot=no.  In case it's not clear, I mean this as a joke and I don't 
expect this would actually be sensible tagging anywhere, but who knows.  
Essentially I'm just saying I don't think putting foot=no on the main 
roadway when sidewalks are mapped separately is helpful.  Just tag 
sidewalk=separate.


Joke's on me then! :-D

If foot=no is problematic for use cases like the one that Brian 
described, then foot=use_sidepath would be more precise for saying, "No 
feet *here*, but see also: separate sidewalk."


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Foot / sidewalk access tagging

[Minh Nguyen]

Vào lúc 15:00 2022-12-18, Zeke Farwell đã viết:
I'll try to answer the original question as succinctly as possible.  As 
I understand it, the combination foot=no + sidewalk=separate means 
walking is not allowed at all on this street and the sidewalk belonging 
to this street is mapped as a separate way.  Since the sidewalk belongs 
to the street, foot=no applies to it as well.  It must be a sidewalk 
where walking is not allowed since walking is not allowed anywhere on 
this street.


Does any router actually interpret access tags as you're describing?

It seems like quite a stretch that a router would automatically infer a 
sidewalk's access tags from some parallel roadway, not least for the 
reason that we lack an established method to associate the sidewalk with 
the way. [1] (sidewalk=separate refers to a sidewalk way, but there's 
nothing in the other direction.) It would be something of a first for 
OSM that you could download a complete extract within a certain bbox, 
including any relation memberships, and the footways along the edges of 
this bbox could be subject to a tag that hasn't been downloaded yet.


Compounding matters, there are places where cyclists are prohibited from 
using sidewalks and other places where cyclists are required to use 
sidewalks when present. What should a router do if somehow it is able to 
determine the parallel roadway and finds a bicycle=no on it? What other 
access keys of the unconnected roadway are relevant to routing on a 
sidewalk? What about other things that are "part of the street", such as 
busways?


[1] https://community.openstreetmap.org/t/6255

--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

[Minh Nguyen]

Vào lúc 07:54 2022-12-02, Tobias Knerr đã viết:

On 02.12.22 15:02 Mateusz Konieczny wrote:

If it is second case of preprocessing being impossible -
why do massive duplication and ask to duplicate ref value
AND name value AND highway value?


The duplication-free solution of referencing the road's way ID as 
is_sidepath:of = w4087515 is going meet some resistance from people 
pointing out the need for, and current lack of, editor support to make 
such values usable.


To clarify, the proposal calls for is_sidepath:of=* to be set to a road 
classification consistent with highway=*. It uses the combination of 
is_sidepath:of=*, is_sidepath:of:name=*, and is_sidepath:of:ref=* to 
unambiguously^H^H^H^H less ambiguously identify the nearby roadway. This 
is similar to the street:name=* key that mappers in a few cities have 
been using, but with the added benefit of resolving ambiguity when there 
are similarly named streets running parallel. (Is this a big enough 
problem to require the full set of tags?)


If the proposal had called for is_sidepath:of=* to refer to another way 
by its ID, I think we'd be howling about how way IDs are unstable and 
that we've reinvented relation membership, but in the inverse direction.


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

[Minh Nguyen]

Vào lúc 08:44 2022-12-02, Mateusz Konieczny via Tagging đã viết:
I have good news! There is preprocessing solution for large (nearly 
all?) simple cases,

written in Kotlin and is a part of StreetComplete.

StreetComplete would be able to handle cases listed in its sidewalk 
detection
(used to skip sidewalk/cycleway quests in presence of nearby separately 
mapped sidewalk

- note that in new versions this quests are disabled by default as overlays
are intended to replace them)

You can test how it works by finding place where roads have no 
sidewalk=* tags
and there are separately mapped sidewalks, navigate there in 
StreetComplete and

disable all quests except sidewalk/cycleway.

You will get them on matching roads - except ones with detected nearby 
sidewalks.
You can also tweak filter rules to enable sidewalk and cycleway quest 
for all roads
to skip tag based filtering (which skips some roads unlikely to have 
cycleways

or sidewalks or already tagged with sidewalk* and cycleway* tags)

This code would handle with slight modifications vast majority of cases.
Simplest one would be enlarging default buffer and other parameters.
Possible changes include taking into account cycleway*=separate tags and
sidewalk*=separate tags to search for larger distance if sidewalk was 
not found

and other obvious tweaks - all examples listed here would be handled.


Are you referring to this code? [1] A running time of O(n^3) is not 
necessarily something others would consider a solution. Imagine a router 
running this algorithm over a whole continent or planet when building 
the routing graph. Yet it's also too sensitive to where a way happens to 
be split. Either the footway or the roadway could be split at arbitrary 
points for arbitrary reasons or no reason at all.


A more general algorithmic solution may be feasible, but it would 
probably look much more like Skeletron [2], which conflates dual 
carriageways, or the map matching algorithms in various routing engines, 
which are normally used to align GPS traces to the road network. These 
approaches are overkill for StreetComplete but may be a good fit for a 
routing engine. The edge cases in [3] would require walking the routing 
graph to some extent. This is something the Overpass API was originally 
designed to do, so it isn't inconcievable, but it isn't purely a 
trigonometric problem.


Yes, it will take some effort to write or adapt this code. But this 
proposal asks

mappers to manually preprocess millions of sidewalk sections.
Just currently marked footway=sidewalk (small part of all separately 
mapped sidewalks)

have 3 300 000+ sections.
Lets take optimistic 5s per section, initial tagging that alone would 
consume
4695 hours of mapping (and also software costs to allow such efficient 
mapping!).

And likely 5s per way is very optimistic.
Add to that all separately mapped sidewalks without footway=sidewalk.


For what it's worth, this would be a similar scope of work as adding 
name=* to each of the sidewalk ways, just as with dual carriageways. 
Mappers in some cities are already systematically adding name=* to 
sidewalk ways, but it hasn't really caught on globally, maybe because of 
how it clutters a typical map. (But a renderer could simply avoid 
labeling footway=sidewalk.)


Inevitably, there will be unhandled edge cases regardless of the 
algorithm. Maybe a compromise would be to treat is_sidepath:of=* as an 
override for difficult cases only, similar to name:pronunciation=*. The 
benefit over name=* is that nothing changes for a renderer unless they 
opt into processing the new key.


[1] 


[2] https://github.com/migurski/Skeletron/
[3] 



--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

[Minh Nguyen]

Vào lúc 02:08 2022-12-01, Volker Schmidt đã viết:
This proposal is incorrectly giving the impression that it is in the 
spirit of the crossing:markings tag.
This tag was meant to complement and refine the existing tagging of 
crossings in some cases, but certainly not to replace, wholesale the 
"crossing" key
The crossing:markings key describes the painting on the road surface, 
not the legal situation for the traffic participants, and it also leaves 
out the vertical signals (which BTW here in Italy have precedence over 
the horizontal signs in case of conflict)


The logical analogue to the successful crossing:markings=* proposal 
would be a proposal for a crossing:signals=* key that introduces options 
beyond what mappers can already express (in a Babelesque manner) using 
the various crossing=* tags -- without impinging on the entrenched 
interests behind crossing=zebra/uncontrolled/marked.


I'm working on such a proposal, in part to close a gap that mappers in 
my region experience acutely. [1] Unfortunately, I didn't manage to 
complete it before this more aggressive proposal went to an RfC. I just 
hope this proposed deprecation doesn't poison the well for 
crossing:signals=* once it's ready. The original 2019 proposal for 
crossing:signals=* made the same mistake of touching the sensitive 
crossing=* key.



Also what is the meaning of crossing=no?


crossing=no is for where the road geometry etc. would suggest a 
pedestrian crossing but there isn't one. Some jurisdictions have 
standard signs for this situation. It's probably more common in regions 
where there are laws against jaywalking. If we're really serious about 
deprecating crossing=*, then a more systematized tag could be 
not:highway=crossing, now that the not:* prefix is fairly well-established.
[1] 
https://wiki.openstreetmap.org/wiki/Proposed_features/Crossing_signalization


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

[Minh Nguyen]

Vào lúc 23:01 2022-11-28, Martin Koppenhoefer đã viết:

On 29 Nov 2022, at 00:52, Minh Nguyen  wrote:

Even if it weren't for iD's long-gone preset, I don't think an ostensibly 
global tag should be defined based on the narrow provisions of a specific 
country's laws.



I don’t think this is about a specific country, although it is not about all 
countries there are many of them that apply the concept and that seem to have 
decided on the feature in 1949 in an international agreement.


No zebras were harmed in the drafting of either the 1949 Geneva Protocol 
on Road Signs and Signals [1] or the 1978 Vienna Convention on Road 
Signs and Signals [2]. Neither treaty mentions this species by name, but 
the national laws of some parties to the Vienna Convention do define 
zebra crossings.


For example, the UK requires zebra crossings to have alternating stripes 
as well as belisha beacons. [3] Other countries, such as Vietnam, use 
the term "zebra" specifically for the striped marking pattern 
(crossing:markings=zebra), by contrast with two parallel lines 
(crossing:markings=lines), but make no other provisions apart from what 
any crossing would have. [4] Meanwhile, here in the U.S., which is not a 
party to the convention, we walk on a distinct species of "zebra 
crossing" that has slanted stripes. What was the problem with 
crossing_ref=zebra again?


What you seem to be suggesting is that the definition of crossing=zebra 
should favor the regulations of some parties to the Vienna Convention 
over other parties to the convention, let alone other countries that use 
the term "zebra" to refer to something slightly different. This is 
unsustainable. At one point, it might've been reasonable to justify the 
use of one national definition as a historical accident, based on 
squatter's rights. But since then, for better or worse, that definition 
has been overwhelmed by usage that we can't characterize as cleanly.


Mappers benefit when they can be confident that others will look at 
their tagging later on and interpret it consistent with their original 
intention. Someone using crossing=zebra today shouldn't be under any 
illusion that it means anything more specific than a marked crossing in 
practice. In that light, crossing=zebra deserves to be given the same 
deference as crossing=marked.


[1] 
<https://treaties.un.org/doc/Treaties/1953/12/19531220%2000-10%20AM/Ch_XI_B_1_2_3.pdf>

[2] https://unece.org/fileadmin/DAM/trans/conventn/signalse.pdf#page=7
[3] 
<https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/851465/dft-traffic-signs-manual-chapter-6.pdf#page=127>
[4] 
<https://luatvietnam.vn/giao-thong/quy-chuan-ky-thuat-qcvn-41-2019-bgtvt-bao-hieu-duong-bo-186000-d3.html>, 
p. 20; search for "vạch ngựa vằn", literally "zebra stripes"


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

[Minh Nguyen]

Vào lúc 15:18 2022-11-28, Martin Koppenhoefer đã viết:

crossing:markings is just about this, road markings, and while 
crossing_ref=zebra wasn’t documented for a long time, people that added it 
around here told me it was about the presence of road markings as well.

Crossing=zebra is about a zebra crossing, it implies also vertical signs- in 
some jurisdictions and some conditions at least - and it implies that there 
aren’t traffic signals.
Neither crossing:markings nor crossing_ref (as it is applied here) say anything 
about traffic signals. Here you will usually have zebra markings on signal 
controlled crossings, but they aren’t zebra crossings of course, still 
crossing:markings=zebra applies. And many of them have the crossing_ref=zebra 
tag (I ignore this tag, it does not follow any consistent logics here, 
definitely not a tag I would want to base navigation decisions on). Maybe they 
are when the signals don’t work (not sure about it, the law here requires 
vertical signs for zebra crossings, unless at road intersections).


As you may be aware, iD used crossing=zebra for its Crosswalk preset 
between 2014 and 2019, during which the vast majority of occurrences 
were added. [1] So whatever it may have originally meant has already 
been diluted to the point that you're probably better off supplementing 
the tag with something more explicit if you care about the additional 
nuances you're describing here. In general, crossing_ref=* is supposed 
to be a localized, holistic approach to classifying crossings. If 
crossing_ref=zebra is itself too diluted, then perhaps you could use a 
different value. Unfortunately, it's a Monday, so all I can think of at 
the moment is crossing_ref=zebra2. XD


Even if it weren't for iD's long-gone preset, I don't think an 
ostensibly global tag should be defined based on the narrow provisions 
of a specific country's laws. But as you're only defending 
crossing=zebra from deprecation, rather than promoting its usage over 
less provincial tags, an alternative to deprecation would be to give up 
on crossing=* having any machine-readable meaning on its own and allow 
it to be an any-tags-you-like situation, similar to ref=* on ways.


[1] https://wiki.openstreetmap.org/wiki/Special:Diff/2396877#iD
[2] 
https://wiki.openstreetmap.org/wiki/Proposed_features/Crossing_signalization


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

[Minh Nguyen]

Vào lúc 04:55 2022-11-28, Martin Koppenhoefer đã viết:
Just because there is a now a way to map crossing markings separate from 
other properties, does not imply all the tagging we have is not needed 
any more, rather I would see "crossing:markings" as implicit, for 
example on a "crossing=zebra".


If we keep crossing=zebra around based on the argument [1] that it takes 
fewer keystrokes or clicks than adding crossing_ref=zebra or 
crossing:markings=zebra without using a preset, then this undermines the 
arguments against railway=tram_crossing, railway=tram_level_crossing, 
and probably some other contentious, de facto tags that are essentially 
shortcuts for tagging combinations without additional semantic value.


I think the more salient question is whether the impact to muscle memory 
and software is worth the elegance of this proposal in its current 
state. Some other recent proposals have encountered difficulty because 
the tradeoff wasn't good enough. For us to make an informed decision, we 
need to know to what extent this change will affect editors, renderers, 
and routers. This touches on an ongoing discussion in the community 
forum about the additional hurdles a proposal must clear if it attempts 
to deprecate something that's in use. [2]


[1] 


[2] https://community.openstreetmap.org/t/5661

--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Minh Nguyen]

Vào lúc 10:44 2022-11-23, Zeke Farwell đã viết:
A 100+ message thread on the mailing list is no better than on 
Discourse.  The problem is people spending too much time writing many 
long messages, and not enough time reading and thinking.  Much as I 
would love if everyone could learn to write concisely, this will 
probably always happen on any platform.


If only I could +1 this post without spamming everyone.

--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] species:language to loc_name:language

[Minh Nguyen]

Vào lúc 08:22 2022-11-21, Carlos Sánchez đã viết:
In a lot of cases, users are using local names in the values for species 
and genus keys.
This is an error as genus and species only exist in latin. For 
local/vulgar name users should use another key or be obtained using the 
wikidata information.


I suggest changing species:language to l 
oc_name:language as 
for the same species there exists a huge variability of common names, 
not only differing by language.


Wiki for species:wikidata: Key:species:wikidata - OpenStreetMap Wiki 

Wiki for species: Key:species - OpenStreetMap Wiki 

Use of the key species: Resultados de la búsqueda | OpenStreetMap 
Taginfo 


loc_name=* is for the local name of the feature itself, in other words, 
the local version of name=*. Some famous trees are known by proper 
names, but that's different than the (common) name of the species as a 
whole.


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Minh Nguyen]

Vào lúc 22:07 2022-11-19, Graeme Fitzpatrick đã viết:




On Sun, 20 Nov 2022 at 15:38, Minh Nguyen 
<mailto:m...@nguyen.cincinnati.oh.us>> wrote:



There are some ways to draw attention to a wiki talk page comment in
general. For example, if I add {{ping|Fizzie41}} to my comment, you'll
get a notification, including by e-mail if you've set that up. If your
comment concerns the veracity of an article, you can add {{dubious}} or
{{disputed}} to the article, which will link to the talk page.


Thanks!

Had never heard of those hacks!

I know that I keep getting advised whenever somebody makes a change to a 
page that I've commented on / edited, so I thought that should also 
apply to others?


You've probably set the preference to automatically add edited pages to 
your watchlist, as well as the preference to e-mail pages when a page on 
your watchlist changes. Neither of these preferences is enabled by default.


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Minh Nguyen]

Vào lúc 18:17 2022-11-19, Graeme Fitzpatrick đã viết:

I do have some concerns about the talk pages though.

Over time, I've asked quite a few questions on various talk pages, 
seeking clarification of tag details, or whether this tag would apply in 
these circumstances etc.


I doubt as many as 10% ever get a response :-(


Oh yes, to be clear, I meant the talk page of the proposal in question. 
An active proposal's proposer is typically quite responsive to questions 
on that talk page; otherwise, the proposal stands very little chance of 
passing, and it wouldn't be because of where the announcements are posted.


There are some ways to draw attention to a wiki talk page comment in 
general. For example, if I add {{ping|Fizzie41}} to my comment, you'll 
get a notification, including by e-mail if you've set that up. If your 
comment concerns the veracity of an article, you can add {{dubious}} or 
{{disputed}} to the article, which will link to the talk page.


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Minh Nguyen]

Vào lúc 17:24 2022-11-19, Matija Nalis đã viết:

On Sat, 19 Nov 2022 12:12:22 +0100 (CET), Cartographer10 via Tagging 
 wrote:

This proposal makes sure there are 2 required platforms where people have to 
announce it. That way people have the
choice to follow one of the two channels of their choice to get updated on 
proposals. It is up to the proposal author
to announce it on other channels to increase the reach.


I'd at least put in a requirement that if proposal author announces the 
discussion in X extra channels (i.e. anywhere
more than Tagging ML), that they must follow ALL that X extra channels and 
summarize in Wiki Talk page all points that
have been risen (including those that they think don't matter or disagree with. 
Especially those!) and THEN have extra
RFC period after all those X channels have been summarized, before proceeding 
to the Voting.

Because, someone has to do that summarizing work for extra channels to make 
sense, and it is IMHO only fair that would
be proposal author (expecting that EVERYBODY will do that SAME task is both 
extremely wasteful, hugely unrealistic,
and likely to lead to few participating members willing to do that becoming 
burned out prematurely).


There are already other communication channels announcing proposals 
independently of the formal requirements. You've mentioned weeklyOSM 
(which has a comments section) and I've mentioned OSMUS Slack. 
Practically speaking, no one can fully understand the discussion in 
every community. That's a much higher bar than just announcing something.


For example, I think it would be perfectly reasonable to alert OSM Japan 
Slack about my next proposal, but my nonexistent Japanese skills would 
be catastrophically inadequate to capture the sentiment there. It would 
be better to candidly state upfront that I'm unable to respond to 
individual comments there and direct interested mappers to the wiki talk 
page, where hopefully others can engage as necessary.


All too often, a proposal announcement on this list ends with an 
exhortation to comment on the wiki talk page, inevitably leading to a 
long thread here instead. Where is the requirement to summarize the 
tagging list thread, for the benefit of ordinary mappers who will be 
voting but can't easily follow Mailman's deeply nested threads split 
across monthly archives? After all, the proposal guidelines have never 
required _voters_ to subscribe to the tagging list.


Maybe a better model would be for each community to take some of the 
burden off the proposal and have one or more self-appointed liaisons 
handle announcements and communicate the most salient ideas back to a 
single source of truth (the wiki, or wherever we decide to hold votes in 
the future). This would apply to the tagging list as well as the 
community forum.


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] care services

[Minh Nguyen]

Vào lúc 04:12 2022-11-19, Georges Dutreix via Tagging đã viết:
My question is for a unique company providing different services for 
assistance at home, but the goal is not healthcare. Probably 
office=home_aide could be good, I am questionning english native 
speakers for the right word. In french we call that "service à la 
personne", and I found for translation "home care".


Ah, that explains the confusion. Around here, "home care" would 
typically refer to in-home supportive services for the ill, elderly, or 
those with disabilities, although it isn't strictly about healthcare.


Judging from [1], I think English has analogous terms for the economic 
sector as a whole (personal services) and for individual occupations 
within that sector (nanny, handyman, tutor, personal assistant), but I'm 
unsure if there's a set phrase for a business that offers a wide variety 
of these services at large.


"Personal services" has several definitions, some of them quite broad. 
It can mean beauty salons, tattoo artists, and the like. Alternatively, 
it can include any professional practice, including accounting and law. [2]


[1] https://fr.wikipedia.org/wiki/Services_à_la_personne_en_France
[2] https://en.wikipedia.org/wiki/Personal_service_corporation

--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Minh Nguyen]

Vào lúc 17:39 2022-11-18, Matija Nalis đã viết:

That way, maximum reach will be accomplished, and all "people could decide for
themselves where they wish to communicate". So instead of say 30 messages on
tagging mailing list for some proposal, we can have 5 messages on tagging ML, 2
on Discourse, 4 on telegram (1-2 in each of the groups), 2 on Discord, 3 on
IRC, 3 on Matrix, 2 on Mastodon, 2 on Slack, 2 on Reddit, 2 on facebook,
1 on twitter and 2 on OSM Diary of proposer. Do you spot the problem here?
Because I do.


No one has seriously proposed to make a Twitter announcement part of the 
standard operating procedure for RfCs or votes, whereas someone did 
seriously propose Discourse. Even a slippery slope can have some tactile 
paving. ;-)



I'd rather that Tagging ML + Discourse Tagging category become properly
integrated (i.e. that one participate using EITHER channel, and see all
comments from BOTH channels) - as I noted in linked github issue on proposal
talk page.

Like, for example, I'm reading and writing this on NNTP (Usenet News) gateway
news.gmane.io, which *is* properly integrated with tagging mailing list.
Everything I write here, people will see in their Mail clients, and everything
they reply I will see in my News client.


I'm writing this from Thunderbird hooked up to Gmane's NNTP gateway. I 
set it up over a decade ago and never again subscribed to a Mailman list 
in the normal way when I had a choice. I even enjoyed using Gmane's Web 
interface back when it was still online.


Yet I recognize that such an arcane configuration cannot possibly get us 
closer to a goal of ensuring that tagging discussions reach and engage a 
broad cross section of ordinary mappers and data consumers. That must be 
our goal; otherwise, the most electorally successful tagging proposal 
could still fail to gain traction among the audiences that matter most, 
undermining the proposal process. Any temporary fragmentation ahead of a 
vote would be secondary to that problem.



That same level of integration could (hopefully will?) be accomplished with
Discourse - so people will see the SAME messages whether there use Discourse
HTTPS, Email SMTP, or News NNTP interface.

Which solves the whole issue, without raising tensions. Win-win for everyone.


As a baby step, I just set up an "abuse filter" on the wiki that will 
tag any change to the |status=, |draftStartDate=, |rfcStartDate=, 
|voteStartDate=, or |voteEndDate= parameters on a feature proposal page. 
Rest assured, editing one of these parameters won't send you to the 
headmaster's office for abusing any privileges, but you can filter 
Special:RecentChanges, Special:Watchlist, etc. to show only these changes:




and you can click the "Atom" link in the sidebar to get a feed to add to 
your feed reader. I've taken the liberty of subscribing OSMUS Slack's 
#proposals channel to this feed. Perhaps someone can even set up a bot 
on Twitter, while that's still a thing.


This isn't quite what either of us are envisioning, and I personally 
don't consider RSS feeds to replace that human touch. But it could make 
it easier for some of us to keep track of proposals. If the feed gets 
noisy, let me know and I can tighten up the abuse filter's rules.


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] care services

[Minh Nguyen]

Vào lúc 10:51 2022-11-17, Philip Barnes đã viết:

On Thu, 2022-11-17 at 19:21 +0100, Georges Dutreix wrote:


Le 17/11/2022 à 18:52, Philip Barnes a écrit :

I have used office=home_care for a care company.


I found as well amenity=personal_service used 110 times
Would be "amenity" better than "office" for this case ?


Personal services and Care are not really the same thing.

Care could probably fit into heathcare.


I've mapped the office of a home care provider (just a desk) as 
healthcare=home_care, but something in office=* would make sense too.


https://www.openstreetmap.org/node/8710988857

--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Minh Nguyen]

Vào lúc 14:51 2022-11-13, Brian M. Sperlongano đã viết:
You're using the wrong metric.  The standard for a proposal, which 
purports to change tagging standards that affect *the entire community*, 
should be to advertise it as widely as possible.  With the new forums 
picking up interest and activity, it is entirely appropriate to say to a 
proposer "...and please also post a notice on the forum" to ensure 
maximum visibility and participation.  The new forums are attracting a 
global audience, rather than the few regional enclaves hosted on the old 
forums.  And, with the new forum linked to your osm.org  
user account, it's neatly tied into the existing OSM infrastructure and 
doesn't require special software or accounts to access.


I also appreciate the accommodation in the proposal for people 
uncomfortable with one platform or another. Asking fellow mappers for 
help is healthy. In fact, some of the best proposals lately (by the 
elusive metric of consensus among voters) have been collaborations among 
multiple mappers. If a mapper needs help to spread the word, they should 
say so.


I don't view this as a "first step towards moving to the forums" that 
the proposal author probably does -- I view it as a recognition that the 
forum has attracted enough interest and maturity in its short existence 
that it's appropriate to demand to proposal authors that they also make 
an announcement post there.  Now, over time, if we find that interest 
has waned in the new forums, or on the flip side, if the forums come to 
largely supplant the mailing lists, we can easily make the decision 
later to eliminate the cross-posting requirement and pick a winner if 
and when this occurs.


And by that point, it won't really be picking a winner; it'll be a 
recognition that mappers will've voted with their feet.


But before we get that far, I recommend that the proposal's title be 
adjusted slightly. The current title implies that discussions would 
start "moving" to the new forums, which implies a loss of activity here. 
That's no longer on the table, so "Announce proposals to the new forum" 
would suffice.


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] amentiy=donation_centre?

[Minh Nguyen]

Vào lúc 19:02 2022-11-12, Graeme Fitzpatrick đã viết:




On Sun, 13 Nov 2022 at 10:37, António Madeira 
> wrote:


I don't know of any charity which buys items to then resell or
distribute them, although that can happen in some obscure situation.


There's that international thing appearing again!

In Australia, /every/ (or at least the vast majority?) charity shop 
takes your no longer needed clothes, toys, kitchenware etc to sell, & 
then use the resulting money to fund their activities. Very few of the 
donated items are ever passed directly to the homeless / needy.


Right, this is true in the U.S. in the vast majority of cases. Some 
charities like Goodwill have an additional charitable aspect of 
employing underprivileged and disabled people to staff the back 
operations, sorting and preparing the goods for retail.


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] amentiy=donation_centre?

[Minh Nguyen]

Vào lúc 12:06 2022-11-12, António Madeira đã viết:

There's office=charity and shop=charity.
I think the second one corresponds to what you're looking for.


Maybe, but only if there's some tag to clarify that the shop=charity 
only accepts items as opposed to selling them. Apparently we avoided 
overloading some other similar tags in that manner: for example, "cash 
for gold" shops are often tagged shop=collector or shop=gold_buyer 
rather than shop=pawnbroker.


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] amentiy=donation_centre?

[Minh Nguyen]

Vào lúc 11:26 2022-11-12, Timothy Noname đã viết:

I think people already use
Amenity=recycling
Recycling_type=container or centre
And then specify whether it takes clothes and shoes etc
Recycling:clothes=yes


Long ago, I helped to promote this overloading of amenity=recycling in 
the U.S. At the time, I was thinking of organizations like USAgain or 
Planet Aid that only operate donation bins stationed in parking lots. 
[1] It seemed like an apt analogy: you "recycle" clothes by placing it 
in one of these bins. (Read those quote marks with a hint of irony.) 
recycling=clothes;shoes seemed adequate for expressing any difference 
from, say, a plastic bottle recycling bin.


However, over time, I've come to second-guess this analogy. For one 
thing, there's a fundamental difference between a recycling bin that 
would divert its contents to an industrial recycling facility and a 
clothes donation bin that would divert its contents to a second-hand 
store or homeless shelter, even if some percentage does wind up in the 
same landfill. Underscoring this difference, in the U.S., you get an 
income tax deduction for donating goods, but not for recycling the same 
goods. So someone searching for one really isn't searching for the other.


Making matters worse, it was only a matter of time before we had to 
stretch this analogy further to cover the exact same kind of donation 
bins that chains like The Salvation Army and Goodwill operate alongside 
their brick-and-mortar second-hand stores. And even further for the 
donation-only centers they also run out of converted storefronts, a far 
cry from conventional recycling centers. [2] I've mapped one that only 
takes donated cars [3], but recycling_type=centre recycling:cars=yes 
feels like a very counterintuitive way to describe a car donation 
center. To me, "recycling center for cars" sounds like a euphemism for a 
junkyard.


In hindsight, I probably should've promoted something like 
amenity=donation that could apply to both bins and centers, just like 
amenity=recycling.


[1] 
https://github.com/osmlab/name-suggestion-index/commit/19ca12fa9bfe4c017681dc0bf7baf4919d1ecbb1

[2] https://www.openstreetmap.org/way/71501049
[3] https://www.openstreetmap.org/way/42425057

--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Feature Proposal - Voting - Healthcare 1.1 - General comment

[Minh Nguyen]

Vào lúc 04:43 2022-11-06, bkil đã viết:

That's an interesting problem. Does the mediawiki API support CORS? If
yes, we could easily create a very simple third party GUI form for it
just for voting or adding a new comment on the talk page.


In addition to the osm-proposals site, Martin is developing a MediaWiki 
extension that would make it easier to vote on a proposal. [1][2][3]


[1] 

[2] 

[3] 



--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Proposal process [was: healthcare]

[Minh Nguyen]

Vào lúc 03:26 2022-11-06, 
m...@marcos-martinez.net đã viết:
Some time ago I asked Alexander Borsuk (Organic Maps). The context was 
the debate on the "contact" controversy but it can be extended to other 
less heated topics... (The conversation was in the open OM Telegram 
channel and can be found by everyone, so I am not disclosing opinion, 
subject to privacy)


The key sentences for me are:

"A bigger problem is different public transport schemes, where it’s way 
harder to write a “converter” from one into another. For example, subway 
map in Vienna was missing because local community decided that it’s ok 
to have two different level platforms in one stop_area. That is really a 
pain."


"...the proper way would be to merge into multiple values for one chosen 
tag (and filter duplicate values, of course). That’s a bit of a hassle, 
but it is solvable."


"Of course it is easier if all tags have the same scheme. Then we don’t 
spend our time on the scheme differences, focusing on a better product 
instead."


Let me ask you then: Can you provide evidence or a few examples in which 
tag standardization is harmful or represents any disadvantage?


Data consumers aren't a monolith. Churn in our tagging schemes can break 
existing software and harm end users in the real world, unless we set up 
migration paths and raise awareness. Conversely, if we don't clean up 
our tagging schemes at all, then we make it harder for developers to 
adopt new kinds of OSM data effectively.


Fortunately, there aren't too many high-profile examples of tagging 
churn deliberately breaking data consumers. This community has been 
careful to preserve backwards compatibility -- you might say too 
careful. One example I'm aware of is that, for years, the definition of 
highway=trunk in the United States had differed from the global 
definition, focusing on physical characteristics, but since last year 
there has been an effort to harmonize the definition and shunt the 
physical characteristics over to expressway=yes. [1] This will require 
changes to some routers such as Valhalla that include highway=trunk in 
the "Avoid Highways" option, under the assumption that this tag 
consistently indicates an expressway.


Sometimes breakage happens unintentionally. Several years ago, I and 
other mappers in the U.S. and Canada started using 
restriction=no_left/right_turn_on_red to indicate a turn-on-red 
restriction, which up to that point had no established tagging. [2] This 
*_on_red suffix briefly broke OSRM, which had been relying on an obscure 
clause that someone inserted into the restriction=* page stating that 
data consumers could ignore everything after the no_* or only_* prefix. 
Since turn-on-red restrictions are very common in downtown areas, these 
restrictions effectively made it impossible to route through these 
areas. Whoever added this clause to the wiki had good intentions for 
making OSM easier and more elegant to use, but data consumers noticed it 
before mappers did. Ironically, it was a premature optimization: OSRM 
ultimately required nothing more than a one-line change. [3]


To the extent that we care about both new and existing data consumers, 
we should strive to balance their disparate needs. One reason that 
dual-tagging grace periods last so long is that we don't have a very 
clear understanding of who all is using OSM and how, but we know of 
plenty of software that's still in use but no longer maintained. 
Software engineers refer to Hyrum's law [4] as shorthand for the fact 
that churning an API will always break someone, even for the silliest of 
reasons. [5]


Breaking changes are sometimes unavoidable, but there should be a 
convincing reason for the breakage when the stakes are high. Otherwise, 
the impact to OSM's reputation would be higher than any upfront 
messiness, which we already mitigate by providing a critical mass of 
data that you can't find anywhere else. Sometimes a convincing reason 
could be that the old tag is getting in the way of mapping things we 
want to map but can't express using existing tags. The 
crossing:markings=* proposal didn't deprecate crossing=* [6], but I 
think future proposals could chip away at crossing=*, as we find that 
there are more crossing configurations that we can't express using that 
key alone.


[1] https://wiki.openstreetmap.org/wiki/United_States/Highway_classification
[2] https://wiki.openstreetmap.org/wiki/No_turn_on_red
[3] https://github.com/Project-OSRM/osrm-backend/pull/4811
[4] https://www.hyrumslaw.com/
[5] https://xkcd.com/1172/
[6] https://wiki.openstreetmap.org/wiki/Proposed_features/crossing:markings

--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Using restriction and restriction:vehicle for the same restriction relation should be discouraged

[Minh Nguyen]

Vào lúc 00:23 2022-11-06, 
easbar.m...@posteo.net đã viết:
Ok, sure, as far as I am concerned it doesn't have to be `unrestricted` 
and could just as well be `none` or `no`.


But at least there seems to be consensus that
a) The `except` tag could/should be replaced with such a 
`no/none/unrestricted` value for the `restricted:` key


"Replaced" is too strong for now. I'd suggest pairing it with except=* 
until after a transition period, because the except=* key is already so 
entrenched among data consumers. The consequences of missing an 
exception are pretty severe. Dual tagging also mitigates the fact that 
this discussion has only involved a few of us. You never know what 
concerns will come out of the woodwork after the fact.


The length of the transition period is an open question. See the other 
thread about deprecating amenity=hospital in favor of healthcare=hospital...


b) Using `restriction:` and `restriction` for the same relation should 
be discouraged except for using `restriction:xyz=no/none/unrestricted`


This is an interesting way of putting it, that a key should have only 
one possible value, apart from conditionals. But I guess we already have 
some keys like that, such as noname=*.


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Feature Proposal - Voting - historic

[Minh Nguyen]

Vào lúc 18:16 2022-11-04, Martin Koppenhoefer đã viết:



On 4 Nov 2022, at 13:17, Marc_marc  wrote:

our "sister" project (wikipedia) has no problem defining what is an anecdote and what is 
"relevance from a historic viewpoint",
I don't see why we should have any issue doing it.



Mappers are working fundamentally different from wikipedia authors, because 
they are recording observations, first hand study, while wikipedia work means 
working with sources. Original research is explicitly frowned upon in wikipedia 
while it is at the basis of mapping. We do not have relevance criteria as a 
hurdle for inclusion of things, we only require them to exist. I do not say 
relevance does not exist, but it is less important for our mapping. We are 
creating “categories” of things by applying tags, and I do not believe it would 
be helpful to have different main categories for the same thing, depending on 
its historic relevance, hence I do not believe redefining the “historic” key in 
this direction would be helpful for the project.


I think this point would be every bit as applicable to our other sister 
project, OpenHistoricalMap, which works with both published sources (for 
the past) and observations (for the present). So far, OHM has hewn to 
OSM's tagging schemes, including the historic=* tags that are almost 
always anachronistic.


For example, most historic=manor weren't historic the moment they were 
completed. A historic=battlefield may not have been historic until the 
tide turned in a larger campaign. I would expect historic=citywalls to 
be less common in OHM than barrier=city_wall.


Both historic=* and heritage=* make a value judgment, but heritage 
designations are made by historical societies and government agencies. 
Who are we to make a similar designation as mappers?


Maybe both OSM and OHM could live with historic=* being a misnomer as 
(wait for it) a historical accident, but if someone is coining a tag and 
they're choosing between historic=* and another suitable key, I'd advise 
them to pick the other key.


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Feature Proposal - Voting - historic

[Minh Nguyen]

Vào lúc 09:36 2022-11-04, Anne-Karoline Distel đã viết:
The point I was trying to make is that in the iD editor, the field 
"inscription" comes up as a default and is mis-used for descriptions. I 
would like to see a way to prevent that.


Obviously, a signpost has an inscription, but that field maybe comes up 
for signpost which I would presume is the primary key. I usually map 
signposts/ guideposts in situ rather than in iD, so I don't know off the 
top of my head what fields come up for it.


The Inscription field is only included in certain presets. The only 
non-historic=* presets that have this field are:


amenity=bench (hidden by default)
amenity=clock display=sundial
amenity=lounger
cemetery=grave
man_made=cross
man_made=obelisk
man_made=survey_point (hidden by default)
marker=*
tourism=artwork artwork_type=bust

It is also included in the preset for historic=*. However, that fallback 
preset only appears if the feature isn't tagged with anything else that 
matches a preset. It won't appear for example on a feature tagged 
historic=manor or a feature tagged building=detached historic=aircraft. 
It isn't included in the preset for tourism=information 
information=guidepost.


You can verify which fields are included in which presets by searching 
the id-tagging-schema repository. [1] As Mateusz said, please open an 
issue in this repository if you believe the field is included in any of 
these presets inappropriately. If you have evidence that users 
frequently confuse Inscription with Description, please include it in 
your bug report.


Off the top of my head, one solution could be to make Inscription an 
initially hidden field on some of these presets where an inscription is 
less likely, or to make Description an initially visible field alongside 
Inscription. As far as I can tell, there's nothing strictly limiting 
inscription=* to historic inscriptions, so I think it would be 
reasonable to use it on the traffic_sign=* node of a nonstandard sign 
[2] or on a historically unremarkable advertising=sign.


[1] https://github.com/openstreetmap/id-tagging-schema/search?q=inscription
[2] 
https://commons.wikimedia.org/wiki/File:Sidewalk_regulatory_sign,_Mill_Street,_Peninsula,_Ohio.jpg


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Using restriction and restriction:vehicle for the same restriction relation should be discouraged

[Minh Nguyen]

Vào lúc 00:02 2022-11-01, 
easbar.m...@posteo.net đã viết:
Thanks, Minh. Yes, there is no way to indicate an order of precedence 
between relations. But I also do not understand yet why this should be 
needed. It would be sufficient to have one relation per 'turn', i.e. for 
any combination of members with role from/via/to there would be one 
relation. And for a given transportation mode we could check the 
restriction value for this transportation mode for each turn. An order 
of precedence would only be needed if there were multiple (restriction) 
relations using the same from/via/to members, but I don't see why this 
would be necessary?


Of course there could still be contradicting relations, like an 
'only_left_turn' relation paired with an 'only_right_turn' relation (and 
different to-members according to these directions). But that has 
nothing to do with the transportation modes.


So do you think there should or there should not be mixed restriction 
relations?


Regarding https://www.openstreetmap.org/relation/10650926:

```
restriction=no_right_turn
except=bus;bicycle
except:network=Q1140138;Q7407040
```

This would be a 'conditional except' and for it seems like another 
indication that the 'except' tag should be replaced by the conditional 
restriction tag? This would be more in line with what we do for 
'access', maybe something like:


```
restriction=no_right_turn
restriction:bus=unrestricted
restriction:bicycle=unrestricted
restriction:conditional=unrestricted @ network=Q1140138;Q7407040
```


I do like this idea for its elegance. I goofed up above, intending to 
add both except:network and except:network:wikidata, but you get the 
gist. Perhaps "unrestricted" could be simplified to just "none" for 
consistency with maxweight:*=none, which has been suggested for 
representing some weight restriction exceptions signposted in the U.S. [1]


This restriction:*=unrestricted idea would probably need to be paired 
with except=* usage for some time, just in case. Turn restrictions are 
so critical to routing that we should be very careful about introducing 
a new representation for exceptions. Back when 2013 when the 
type=restriction:* and day/hour_on/off syntaxes were deprecated, there 
wasn't any appreciable usage of turn restrictions for routing yet, but 
now there are a lot of users who rely on turn restrictions, especially 
in complex environments like the ones we're discussing.


[1] 
https://wiki.openstreetmap.org/wiki/Special:PermanentLink/2428787#United_States


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Using restriction and restriction:vehicle for the same restriction relation should be discouraged

[Minh Nguyen]

Vào lúc 01:07 2022-10-29, Tobias Knerr đã viết:
On 29.10.22 07:13 easbar.m...@posteo.net 
wrote:
I like your idea of not using the except tag but rather something like 
restriction:value=unrestricted. Actually that would be the first 
useful combination of restriction and restriction:vehicle that I have 
heard of. But unfortunately this is neither mentioned in the wiki nor 
does it seem to be used that way.


Yes, this is something that would require a proposal to introduce, it's 
not established practice at this point. The reason I mention it in this 
discussion is indeed that it would be one example where restriction and 
restriction:vehicle on the same relation could meaningfully coexist. So 
I wonder if a wording could be used that would leave this door open for 
the future, e.g. by discouraging "different types of restriction on the 
same relation" (or some better wording to the same effect).


I'm still wondering: Do we ever need different restriction values for 
different vehicles, or for different conditions, for the same relation?


No, with the exception of the "unrestricted" concept I mentioned, this 
should never be necessary. Even if there is an obscure real-world 
situation with different restrictions on the same turn (same 
from-via-to) for different vehicles, it could be modelled with separate 
relations.


For context, this question came up the other day in the iD bug tracker. 
[1] It was unclear how an editor should depict a mixed-restriction 
relation. If it's unclear for editors, it's certainly unclear for routers.


In a sense, this is actually a common phenomenon: trucks must exit to a 
weigh station but cars may not. Or cyclists must turn right from a bike 
lane to a bike path but cars may not. However, these restrictions are 
already represented by access restrictions on the ways themselves -- no 
need for relations. Normally, way-based restriction tagging breaks down 
when the restriction depends on the direction of approach, but that 
would require separate relations anyhow.


One potential issue with relying on separate relations is that there's 
no way to indicate an order of precedence explicitly. For example, at 
one of San Francisco's most prominent intersections, an "except Muni" 
sign modifies a no left turn sign, exempting one bus operator that comes 
from the west, but not AC Transit. [2] At the same intersection, "no 
right turn except Muni and SamTrans" exempts both bus operators that 
routinely come from the south. [3]


Most of the bus routes in this part of town follow strict paths, so I 
just coined an obscure except:network=* tag and called it a day. [4] But 
this experience leads me to suspect there may be places where the 
real-world restrictions turn our usual access key hierarchy [5] on its 
head. Unfortunately, there's nothing to say that one relation takes 
precedence over another relation with the same members. (Incidentally, 
this is why I've shied away from proposing that we use relations to 
track overlapping parking lane restrictions.)


[1] https://github.com/openstreetmap/iD/issues/9337#issuecomment-1283492156
[2] 
https://commons.wikimedia.org/wiki/File:City_of_San_Francisco_(Unsplash).jpg

[3] https://www.mapillary.com/app/?pKey=4265238293573050
[4] https://www.openstreetmap.org/relation/10650926
[5] https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation

--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Tagging of community mailboxes (cluster maiboxes)

[Minh Nguyen]

Vào lúc 02:28 2022-10-23, Martin Koppenhoefer đã viết:



sent from a phone


On 23 Oct 2022, at 02:03, wolfy1339 via Tagging  
wrote:

Here's a picture for reference, 
https://upload.wikimedia.org/wikipedia/commons/0/0d/CanadaPostCommunityMailboxes15.jpg



for this kind, informal=yes should not be added, obviously

This looks pretty official


Cluster mailboxes are also common in the U.S. at both residential and 
commercial sites. [1] They're identical to that photo above in both form 
and function. [2] Only the ones owned by USPS would have a logo, but 
privately owned clusters are served exactly the same. A passer-by can 
drop letters in the "Outgoing Mail" slot if they want; it'll get 
delivered, but this capability isn't widely advertised because it's 
usually only convenient for those who receive mail at the cluster.


I've been tagging cluster mailboxes as amenity=letter_box, using the 
semicolon-delimited list in post:housenumber=* or post:unit=* to 
indicate that there are many slots. [3] However, I haven't given any 
thought to the outgoing mail slot, or to the numbered lockers for 
incoming parcels. If it's important enough to indicate all these 
functions of the box, then I guess there could be multiple coincident 
nodes with layer=* corresponding to the slots' relative vertical positions.


[1] https://faq.usps.com/s/article/What-is-a-Cluster-Box
[2] https://www.mapillary.com/app/?pKey=952588085280506
[3] https://www.openstreetmap.org/node/8357017189

--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Feature Proposal - Approved - migration to use belarusian as default language in Belarus for tagging

[Minh Nguyen]

Vào lúc 21:56 2022-10-15, bkil đã viết:

Why did I get a private message about this?


I think they've been reaching out to everyone who's edited any of the 
relevant keys (name, destination, etc.) in Belarus to make sure there 
are no surprises. They must've cast a very thorough net.


--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Lyft and nameless sectioning in OSM

[Minh Nguyen]

Vào lúc 05:45 2022-10-15, Greg Troxel đã viết:


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


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.


To demonstrate that this isn't merely a consequence of U.S. law or the 
federal system, consider that OSM is a key source of information about 
informal settlements -- favelas in Brazil, Kibera in Kenya, colonias 
along the Mexico-U.S. border, and countless other examples -- that might 
be described as "illegal" from a certain point of view but which clearly 
meet this project's verifiability standard. This information belongs on 
the map.


There's also the issue of desire paths and informal trails, which in 
some cases represent an accumulation of unauthorized activity. Yet we 
have a well-used informal=* key, and there's even discussion among the 
U.S. community about affirmatively indicating non-informal trails to 
better clarify this distinction.


The actual reason we don't "map zoning" is that we don't aim to copy any 
planning or zoning map verbatim. OSM aims to map the present as opposed 
to (sometimes aspirational) plans about the future. A zoning map by its 
nature describes what kind of construction project will be approved 
going forward, while acknowledging that existing landuse may differ. We 
don't have a tag to say "residential landuse but all these retail 
buildings got grandfathered in". Unfortunately, people regularly come to 
OSM and naïvely copy their local zoning map without regard for this 
distinction, because it's often the only readily accessible landuse-like 
map available from the local authorities.


Another reason, possibly specific to the U.S., is that typical zoning 
terminology doesn't line up with OSM landuse terminology. For example, a 
"commercial" zone might consist of retail storefronts, and a "light 
industrial" zone might consist of warehouses, parking lots, and tire 
stores. An inexperienced mapper copying off the zoning map would tag 
these areas as landuse=commercial and landuse=industrial, respectively. 
On the other hand, if a landuse=residential area happens to line up with 
an area labeled "heavy industrial" on a zoning map, it's worth 
double-checking whether our data is erroneous or outdated.


--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Lyft and nameless sectioning in OSM

[Minh Nguyen]

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.


Going back to the original topic about Houston, the northwestern corner 
of the metropolitan area has already been blanketed in named landuse 
areas (coincidentally) aligned to a combination of property lines and 
easements. The relatively few unnamed landuse areas are compact and 
logical, apart from the gas station conflation mentioned earlier.


This style of mapping helps users orient themselves on any map that 
labels the landuse areas and adds value where the likes of Google 
regularly get it wrong by copying verbatim from planning maps. [1][2] As 
far as I know, Lyft has been careful not to disturb any named landuse 
areas or map coarse landuse areas that are redundant to them.


[1] https://lists.openstreetmap.org/pipermail/talk-us/2013-June/011131.html
[2] 
https://www.nytimes.com/2018/08/02/technology/google-maps-neighborhood-names.html


--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Lyft and nameless sectioning in OSM

[Minh Nguyen]

Vào lúc 10:56 2022-10-12, Evan Carroll đã viết:

But in some places,
mappers have been more rigorous about respecting each building's
architectural origins.


This is all 100% new to me.  Where is it documented that a "shop" in a 
detached house should be mapped as a detached house, and not a shop? 
Where is the notion of "architectural origins" documented. I thought we 
could treat the wiki as authoritative and everything else not in the 
wiki as a wrong or mistaken, or unsupported?


To be clear, I'm not saying the building shouldn't be dual-tagged as a 
shop or that a separate shop=* node shouldn't be mapped within it. This 
is only about building classification. For example, some mappers would 
tag a house converted into a barbershop as:


building=detached
building:use=retail
shop=hairdresser

Various parts of the wiki do mention this distinction in passing 
[1][2][3], but I'm not surprised that you came to the opposite 
conclusion when looking at other wiki pages. The wiki has a lot of 
inconsistencies. That fact alone should dissuade you from treating any 
one wiki page as authoritative.


I would caution against interpreting the wiki overall as a binding 
document. Many tag description pages are the product of a formal feature 
proposal process, but many more are created ad hoc with the intention of 
describing prevailing usage. Sometimes that effort falls short or veers 
into advocacy. It is useful to point out discrepancies between the wiki, 
actual usage, and software support. These discussions can lead to 
harmonization, but the starting point should be first principles like 
end user expectations or legal distinctions, not the mere fact that a 
wiki without an enforcement mechanism documented something a certain way 
many years ago.


Personally, I find the distinction between building=* and building:use=* 
to be pretty fussy. It's hard enough to get mappers to include a 
building=* tag at all when mapping a retail building as a shop=*. But I 
recognize that at least it helps 3D renderers choose a somewhat 
believable model to represent a building when minutiae like roof shapes, 
windows, and doors haven't been mapped.


[1] https://wiki.openstreetmap.org/wiki/Special:PermanentLink/2418589
[2] 
https://wiki.openstreetmap.org/wiki/Special:PermanentLink/2357589#Tagging
[3] 
https://wiki.openstreetmap.org/wiki/Special:PermanentLink/2411986#Converted_buildings_used_as_apartments


--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Lyft and nameless sectioning in OSM

[Minh Nguyen]

Vào lúc 09:12 2022-10-12, Evan Carroll đã viết:

if you have x number of detached residences occupied by offices,
it is not a landuse=residential


Then it's mistakenly tagged. You do not use `building=detached` for 
shops and offices. Per the wiki, 
https://wiki.openstreetmap.org/wiki/Tag:building%3Ddetached 



 > A detached house is a free-standing residential building usually 
housing a single family. Known as a/single-family home/in the United 
States, a/single-detached dwelling/in Canada, a/separate house/in New 
Zealand and/Maison individuelle/in France.


It includes the _function_ of the building.


Strictly speaking, building=* is about the building's original function 
inasmuch as it influenced the building's construction, whereas 
building:use=*, a much less common key, closely reflects the building's 
current occupants. A building=detached could very well be functioning as 
a nonresidential dentist's office or insurance agency.


This distinction is not very evenly applied in practice. For example, 
many modern American church buildings are architecturally 
indistinguishable from commercial buildings or retail storefronts, but 
many get tagged as building=church anyways, because there's so much 
variety in religious architecture anyways. Some renderers like osm-carto 
infer prominence from building=church, befitting a boxy Texas megachurch 
without a steeple that nonetheless dominates the surrounding neighborhood.


Similarly, a layperson may find it difficult to discern that a detached 
house was long ago converted from a firehouse, so they tag it as 
building=detached instead of building=fire_station. But in some places, 
mappers have been more rigorous about respecting each building's 
architectural origins.


--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Lyft and nameless sectioning in OSM

[Minh Nguyen]

Vào lúc 07:58 2022-10-12, Marc_marc đã viết:

Le 11.10.22 à 20:48, Andy Townsend a écrit :

That was added in https://www.openstreetmap.org/changeset/127101982 , 


I am surprised that no one is concerned about the compatibility
between its proprietary source and osm


Lyft's policy lead has clarified to the U.S. community and in various 
changeset comments that the proprietary sources consist street-level 
imagery collected by their drivers, plus aerial imagery they've licensed 
from a vendor for the purpose of mapping in OSM. [1][2] They're 
asserting that they already have the requisite rights to contribute this 
data to OSM. Personally I've been satisfied about the licensing aspect, 
but IANAL.


Verifiability is another matter, but then again, I've lost count of the 
times I've justified my own edits on the basis of "survey" or "local 
knowledge". From what I've seen, whenever another mapper contests an 
edit on the basis of publicly available imagery, Lyft does provide 
access to the specific street-level image that they used. [3][4] This 
has actually convinced me to retain more of my field surveying notes and 
photos, whereas previously I often deleted them after uploading the 
changes to OSM.


[1] 
https://osmus.slack.com/archives/C029HV951/p1631799042255700?thread_ts=1630357887.047200&cid=C029HV951
[2] 
https://osmus.slack.com/archives/CCJ2P6KCH/p1640163087244900?thread_ts=1640129896.237000&cid=CCJ2P6KCH

[3] https://www.openstreetmap.org/changeset/110957115
[4] https://www.openstreetmap.org/changeset/121425257

--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Feature Proposal - RFC - Historic

[Minh Nguyen]

Vào lúc 07:16 2022-10-12, Marc_marc đã viết:

approving that "historic=* is about "with historical significance"
doesn't change anything about already existing historic=value
without historical significance. existing tags always remain
unless someone has the courage to try to make progress on the issue
and depreciated a specific tag is a completely different matter
from approving a key.

it will simply help the creation of the next historic=value
to be done with the right key instead of believing that it is
positive to have a mess in the historic key


Keys that go through the feature proposal process are usually either 
freeform keys, accepting arbitrary values like human-readable text or 
numbers, or allow a fixed, coherent set of values.


In the latter case, there may be an escape hatch for "user-defined 
values", but I don't think the implication is normally that every future 
value is automatically covered by the same proposal. The approved key 
proposal can inform us about whether the value fits with the rest of the 
key's values -- just as an unapproved but well-written key description 
page can -- but the value still needs to be considered on its own merits.


As far as I can tell, the proposal is to ratify the existing contents of 
the key description page. I don't get the impression that, compared to 
the status quo, approving this proposal would meaningfully change the 
decision tree for someone coining a new value, or someone building an 
editor or renderer for that matter. It would be a different story if 
there's a controversy surrounding what tthe key description page says, 
or if the proposal changes the key's scope somehow, for example to 
better accommodate the everything-is-history approach of 
OpenHistoricalMap. [1]


[1] 
https://community.openstreetmap.org/t/feature-proposal-rfc-historic/3910/10


--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Lyft and nameless sectioning in OSM

[Minh Nguyen]

Vào lúc 18:27 2022-10-11, Shawn K. Quinn đã viết:
If, like me, you want to see fewer unnamed landuse areas in your 
backyard, map more named landuse areas corresponding to retail and 
residential developments. These areas not only reduce the pressure to

"fill in" the map visually but also add information about the shape
of these developments that's often difficult to obtain from other map
services.


What I'd like to see less of is the use of dubious tag combinations like 
this:


landuse=retail
amenity=fuel
shop=convenience
name=Exxon

or whatever the brand might be. First, the convenience store and fuel 
should be separately tagged; I tag the fuel canopy (or an area near the 
pumps if no canopy)  as being the fuel station, and the building as the 
convenience store (which also gets the address data if  known). 
Convenience stores may be inside a landuse area, but shouldn't be tagged 
on the same way as a landuse area as I understand it.


Dual-tagging a landuse area as a POI might make sense in some cases, but 
I agree that dual-tagging the entire property as a gas station would be 
misleading. In the U.S., a gas station is usually an amenity of a 
convenience store or auto mechanic, not the other way around.


Anyhow, I was suggesting mapping combinations like the following:

Apartment complex: landuse=residential residential=apartments name=*
Mobile home park: landuse=residential residential=trailer_park name=*
Residential subdivision: landuse=residential residential=single_family 
name=*

Office park: landuse=commercial name=*
Strip mall: landuse=retail name=*

Non-landuse alternatives wouldn't be as precise or informative or enjoy 
as much existing software support. Along with quasi-landuse areas like 
amenity=hospital and leisure=park, typical American sprawl would have 
enough of this more specific kind of landuse area to ward off the 
broader kind to some extent.


--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Lyft and nameless sectioning in OSM

[Minh Nguyen]

Vào lúc 14:06 2022-10-11, Evan Carroll đã viết:
This is also really well said, and we should not overlook that I'm new 
to OSM and don't know of the time when buildings were not mapped. I see 
all buildings mapped, and wonder why I need a container to tell me that 
all things in it are that which it contains to some arbitrary subjective 
precision. I can't imagine making a technology that would use this 
as-is. I can imagine answering the problem differently, with a technical 
solution. It sounds like your opinion is _they're less useful now then 
ever_. If so, is the community hostile to deprecation? Is there no 
precedent for saying "this is no longer useful" let's ditch it, or 
automate it.


If you find manually mapped, unnamed landuse=* areas to be superfluous, 
you'll just love abutters=*, a key that as of 2008 was just as common as 
landuse=*. It remains for when there isn't even enough available 
information to map a proper unnamed landuse=* area manually, let alone 
algorithmically.


Even where buildings have been thoroughly classified, lots of urban 
neighborhoods are dominated by apartment blocks with ground-floor retail 
along major thoroughfares. As the multi-landuse proposal was rejected 
[1], I suspect people are making different judgment calls based on what 
they perceive to be the more prominent of the two uses.


None of this is particularly relevant to Houston, but I don't think 
there's any precedent or mechanism for formally deprecating a broadly 
defined tag in only the places that satisfy certain criteria. Some local 
communities try to dissuade mappers from using certain tags or mapping 
addresses in a certain manner, but it doesn't involve proscribing a 
practice as well-known as unnamed landuse. The closest thing I can think 
of was the situation around population=* in China, now resolved. [2][3]


If, like me, you want to see fewer unnamed landuse areas in your 
backyard, map more named landuse areas corresponding to retail and 
residential developments. These areas not only reduce the pressure to 
"fill in" the map visually but also add information about the shape of 
these developments that's often difficult to obtain from other map services.


[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Multiple_landuse
[2] https://lists.openstreetmap.org/pipermail/tagging/2021-May/061449.html
[3] https://wiki.openstreetmap.org/wiki/Proposed_features/china_population

--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] RFC - More sensible values for fountain=*

[Minh Nguyen]

Vào lúc 01:22 2022-10-11, Marc_marc đã viết:
the namespace isn't needed, it's just a bad pratice due to a missing 
feature in iD (another editor uses taginfo combinations to propose the 
most relevant values, iD on the other hand proposes everything often 
without filter, but as I said, it is not a reason to invent shop:brand 
or shop:name, it is a point which must be improved in iD and not by the 
abuse of namespace)


I wouldn't pin the blame on iD for the development of namespaces. The 
main reason iD uses some namespaced keys is because they're 
well-established, for example crossing:light. Another reason is to avoid 
homonymous keys [1] in some cases where the consequence is more severe 
than just some irrelevant suggestions in the taginfo-powered suggestion 
list.


The need to filter taginfo values has often helped to make a decision 
between two reasonable alternatives in the absence of some other 
deciding factor. But if iD were as contrarian as you describe, then it 
would insist on iteratively refining e.g. religion=christian with 
christian=* rather than presenting the user with an unfiltered 
denomination=* field to keep Buddhist denominations from showing up.


The idea of namespacing keys comes up all the time by mappers uninvolved 
with the iD project (see contact:*). The most salient one in my opinion 
is that sometimes the manufacturer or model only applies to part of a 
mapped feature, especially in the case of a dual-tagged feature. For 
example:


* man_made=flagpole is tagged with flag:name=* rather than name=* 
because the name of the flagpole, if there is one, would differ from the 
name of the flag flying on it.


* siren:model=* was probably coined because it emergency=siren is often 
dual-tagged on a man_made=utility_pole node, the pole having a different 
make and model than the siren.


* The recently approved crossing:markings proposal encourages the use of 
surface:colour=* as a less ambiguous alternative to colour=*.


These keys came from the database, or the wiki, but not originally from 
iD. In any case, there's a draft proposal to consolidate the various 
make and model-related keys. [2]


[1] https://wiki.openstreetmap.org/wiki/Homonymous_keys
[2] 
https://wiki.openstreetmap.org/wiki/Proposed_features/Manufacturer_and_Model


--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] RFC - A broad look at fountains

[Minh Nguyen]

Vào lúc 03:08 2022-10-09, Peter Neale via Tagging đã viết:
A tap is a device to control the flow of whatever liquid (or gas, I 
suppose) is coming out.  Potable water, non-potable water; lemonade; 
petrol (gasoline), Oxygen, whatever...


I think you're joking about the lemonade, but here's the world's largest 
fountain drink cup, now mapped in OSM:


https://www.guinnessworldrecords.com/news/commercial/2017/8/largest-soft-drink-achieved-in-missouri-491025
https://www.openstreetmap.org/way/1102693755

At least in American English, a "fountain drink" is one that comes from 
a soda fountain at a fast food restaurant. Speaking of soda fountains:


https://www.huffpost.com/entry/dr-pepper-soda-fountain-claire-daniels_n_58f0f9f7e4b0da2ff8603e89

And for the indoor mappers in the room:

https://www.insider.com/worlds-largest-chocolate-fountain-opens-at-lindt-shop-in-switzerland-2020-9

(What a world we live in!)

--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] RFC - A broad look at fountains

[Minh Nguyen]

Vào lúc 23:50 2022-10-08, stevea đã viết:

On Oct 8, 2022, at 11:44 PM, Graeme Fitzpatrick  wrote:

On Sun, 9 Oct 2022 at 16:36, stevea  wrote:


Disagree, some are are the same feature .. taps can be drinking water .. or 
'not suitable for drinking' (legal CYA?), 'recommend you boil' (more CYA?), and 
'not suitable for drinking' (you really would not drink this stuff, just look 
and smell it!)


Yes, taps CAN be drinking water, but not necessarily are.

Don't know if it's an Oz-only thing, but we have some taps (both in parks & 
some private properties) that are coloured purple to show that they are connected 
to a separate recycled water grid, so the water should NOT be drunk.

https://www.westernportwater.com.au/wp-content/uploads/2015/06/Recycled-Water2.jpg


Yes, Graeme, in California (USA) we have exactly these (such as my golf course example).  While there is no "purple means don't 
drink" color-coding here, there seems to be a state law (or something just as firm) that if a publicly-accessible "water 
tap" dispenses water which is NOT safe to drink (and again, these are no particular color), there MUST be a sign that says 
"non-potable" or "do not drink" or "using reclaimed water" or has the "international red 
circle-with-a-slash-means no and a picture of a human drinking water" icon...or ALL of the above.


In California, any pipe or tap carrying recycled water is legally 
required to be colored purple. [1] For water from other sources, "Do Not 
Drink", "No Beber", or sign PS-013 [2] would be posted. Indoors, the 
Uniform Plumbing Code, a national standard, specifies a particular shade 
of purple paint for non-potable water pipes when the building also has 
potable water pipes. [3]


drinking_water=no is already approved for non-potable water, and there 
are non-Boolean values and drinking_water:legal=* if you'd like to split 
hairs. I'd expect that a tag for fountains and a tag for drinking 
fountains would both imply a default value for drinking_water=* by 
default, but the default should be overridden when more is known about 
the water source.


With a tag for water taps in general, it isn't as clear. But as a data 
consumer or user, I wouldn't be eager to assume that an outdoor tap is 
potable without more context. I've been to cemeteries in swampy New 
Orleans that have taps signposted "Water for Flowers" and never once 
considered that they might be hooked up to the municipal water system 
and maintained to the standard of a public drinking fountain.


[1] 
https://www.waterboards.ca.gov/drinking_water/certlic/drinkingwater/documents/lawbook/rwstatutes_20170113.pdf#page=30

[2] https://commons.wikimedia.org/wiki/File:MUTCD-CA_PS-013.svg
[3] https://forms.iapmo.org/email_marketing/codespotlight/2017/Aug3.htm

--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Deprecation proposal: man_made=drinking_fountain

[Minh Nguyen]

Vào lúc 04:22 2022-10-08, ael via Tagging đã viết:

On Sat, Oct 08, 2022 at 09:52:46AM +0200, Martin Koppenhoefer wrote:


sent from a phone


On 8 Oct 2022, at 07:55, Warin <61sundow...@gmail.com> wrote:

Example Tom Bass Wall Fountain, Sydney, Australia 1963. Nicknamed "The Urinal" 
for obvious reasons!



according to a british mapper, this is not a fountain but a water feature 🤷‍♂️


Yep. Definitely not a fountain. As for what it is, some sort of
artistic installation. And water feature doesn't seem a bad description
among others for want of a better term.

But I was just trying to feed in that calling these things fountains is
not natural in everyday British English. Feel free to ignore.
The one term which is natural, drinking_fountain, I gather at least
one person wants to deprecate.


Interesting, I wonder if British English might sometimes use the term 
"fountain" more loosely, even if it has a stricter formal meaning. Here 
in the U.S., upward motion is certainly characteristic of fountains, but 
artists have a tendency to bend the rules. My favorites are the ones 
that look like waterfalls:


https://commons.wikimedia.org/wiki/File:KellerFountainSummer2010.JPG

In fact, countless "fountains" are technically statues. Since the 
fountain already rises above the streetscape, it creates the same effect 
without pointing a jet of water directly upwards:


https://commons.wikimedia.org/wiki/File:The_Genius_of_Water_-_panoramio.jpg
https://commons.wikimedia.org/wiki/File:Bethesda_Fountain_at_Central_Park,_New_York_City_-_panoramio.jpg

Maybe this concept isn't completely foreign to the UK, given the names 
of some fountains in England?


https://commons.wikimedia.org/wiki/File:Steble_Fountain_in_action_-_geograph.org.uk_-_720965.jpg
https://commons.wikimedia.org/wiki/File:The_Diana_Fountain_in_Bushy_Park_-_panoramio.jpg

If a 2D renderer were to depict such installations with ⛲️ instead of 
🚿, I probably wouldn't be concerned about users getting confused. But a 
3D renderer probably would need more specificity regardless of the 
top-level tag. It cracks me up to see F4Map depict the statue-fountains 
above as a very wet Venus de Milo, thanks to dual tagging with 
monument=statue.


--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Deprecation proposal: man_made=drinking_fountain

[Minh Nguyen]

Vào lúc 03:04 2022-10-05, Warin đã viết:


On 5/10/22 08:25, Minh Nguyen wrote:

Vào lúc 11:54 2022-10-04, Jass Kurn đã viết:
I've just noticed there is a bubbler tag being promoted? Which 
appears to be an American English term for a British English drinking 
fountain. Why promote another term, and use an American English term. 
What was wrong with calling a drinking fountain a drinking fountain?


To clarify, "bubbler" is a distinctively regional term in Boston, 
Rhode Island, and Wisconsin. Elsewhere, it's either "drinking 
fountain" or "water fountain". [1]



No. 'Bubbler' is also used in Australia. And possibly elsewhere is the 
world.


Sure, I was just clarifying that "bubbler" isn't _the_ American English 
term for these devices. Sorry for distracting from the more substantive 
concern about "fountain", unqualified. It does feel a bit like 
economizing on keystrokes.


(For what it's worth, I think standardizing on English vocabulary and 
one English dialect's spelling pattern has benefited the project in 
terms of predictability. But expecting consistent use of British English 
vocabulary is already kind of a lost cause, considering the existing 
subset of approved tags and the reality that no one dialect of English 
has a word for everything.)


--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Deprecation proposal: man_made=drinking_fountain

[Minh Nguyen]

Vào lúc 11:54 2022-10-04, Jass Kurn đã viết:
I've just noticed there is a bubbler tag being promoted? Which appears 
to be an American English term for a British English drinking fountain. 
Why promote another term, and use an American English term. What was 
wrong with calling a drinking fountain a drinking fountain?


To clarify, "bubbler" is a distinctively regional term in Boston, Rhode 
Island, and Wisconsin. Elsewhere, it's either "drinking fountain" or 
"water fountain". [1]


Personally, I could live with a "bubbler" tag, because it sounds 
hilarious to me (a Midwesterner living in the West), much like calling a 
roundabout a "rotary". [2]


[1] http://dialect.redlog.net/staticmaps/q_103.html
[2] http://dialect.redlog.net/staticmaps/q_84.html

--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Terminology primary feature, main tag, etc..

[Minh Nguyen]

Vào lúc 10:36 2022-10-02, martianfreeloader đã viết:

Hi,

I'm unsure if I'm using correct terminology. I have come across these 
terms in the OSM ecosystem:


- primary feature [1]
- main key [2]
- primary key [3]
- feature tag [4]

1) Are these synonyms (except for the key/tag distinction)?

2) Is *one* of these terms "official" OSM speek with a clear definition?
(as is the case for things like "node", "way", "relation", "key", 
"value", "tag", "changeset")


"Primary feature" appears in the Collective Database Guideline Guideline 
[sic] and Geocoding community guideline, which clarify the terms of use 
under the ODbL. [1][2] "Feature type" appears in the Horizontal Map 
Layers community guideline. [3]


[1] 
https://wiki.osmfoundation.org/wiki/Special:PermanentLink/3980#The_Guideline
[2] 
https://wiki.osmfoundation.org/wiki/Special:PermanentLink/4907#How_does_the_guideline_relate_to_other_existing_guidelines?
[3] 
https://wiki.osmfoundation.org/wiki/Special:PermanentLink/3982#The_Guideline


--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Feature Proposal - RFC - Require proposal announcements to be made on the new forum instead of the mailing list

[Minh Nguyen]

Vào lúc 11:04 2022-09-24, Mateusz Konieczny via Tagging đã viết:

My question was about getting notifications of new topics -
to avoid missing RFC/vote.


By the way, the wiki also has tools for keeping track of RfCs and votes 
under way. For example, you can track recent changes to any proposal 
page that says it's under way. [1] This page can be filtered to just the 
latest revision of each page, or just pages that are or aren't on your 
watchlist. There's also an RSS feed. Special:RecentChangesLinked can do 
this for inbound links to any page on the wiki.


It isn't the same as getting an invitation to participate in a vote 
delivered to your inbox, but on-wiki solutions are also worth 
investigating for those who don't subscribe to the lists for various 
reasons. The DynamicPageList extension would enable us to maintain a 
feed of new proposals without any maintenance overhead [2], but in the 
meantime, maybe someone would be interested in maintaining one manually 
as part of the main page's "News" section?


[1] 
https://wiki.openstreetmap.org/wiki/Special:RecentChangesLinked/Category:Proposed_features_under_way

[2] https://wiki.openstreetmap.org/wiki/Talk:Wiki#DynamicPageList_extension

--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Tagging sewage treatment basins

[Minh Nguyen]

Vào lúc 09:42 2020-12-18, Martin Koppenhoefer đã viết:
Am Fr., 18. Dez. 2020 um 12:32 Uhr schrieb Paul Allen 
>:


I'm not entirely happy with natural=water being applied to either sewage
treatment or slurry.  Neither are natural and neither store water.



neither am I, not for the question of how "natural" they are (ship has 
sailed) but because I would not consider "slurry" to be "water", 
although they contain mostly water (looking at the parts) - 10% sulfuric 
acid is also mostly water. Milk is also mostly water, as is beer.


I'm glad I'm not alone in stubbornly avoiding the troll-tagging of 
tailing ponds and pig lagoons as natural=water. I'm fine with putting 
most reservoirs under natural=water, but this tag doesn't have to hold a 
monopoly on bodies of liquid. After all, clorinated pool water is mostly 
water, but we use leisure=swimming_pool as has been mentioned. A marsh 
is mostly covered by naturally collecting water, but there's 
natural=wetland and a whole wetland=* tagging scheme for that.


Most paper maps I've come across have treated bodies of water as 
distinct from bodies of other liquids, if they show the latter at all. 
For example, the USGS topographic maps cited earlier in this thread make 
no distinction between natural lakes and dammed reservoirs, but tailing 
ponds have completely different symbology. [1] If a renderer were 
unprepared to give special treatment to tailing ponds, I personally 
think it would be better for the renderer to omit them than to render 
them as bodies of water. That might require an altogether different 
primary tag like man_made=reservoir, since it's so common to render 
landuse=reservoir just like natural=water.


landuse=reservoir is an unintuitive tag for water-filled reservoirs, 
anyways. The pedant in me wants to double-map a reservoir as two areas: 
a landuse=reservoir area for the land underneath and a coincident, 
connected natural=water area for the H2O above it. But people complain 
about connecting landuse areas to other features, so I'll have to wait 
until April Fool's Day. ;-)


[1] 
https://pubs.usgs.gov/gip/TopographicMapSymbols/topomapsymbols.pdf#page=4


--
m...@nguyen.cincinnati.oh.us


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

Re: [Tagging] Mapping bicycle-only turn lanes

[Minh Nguyen]

Vào lúc 14:08 2020-12-08, Mateusz Konieczny via Tagging đã viết:

Mapper in Poland run into a tricky case and asked for help.

I am forwarding this a bit weird case.

Photo is at
https://commons.wikimedia.org/wiki/File:Krak%C3%B3w_Brodzi%C5%84skiego_(5).jpg 


and depicts

- contraflow bicycle lane
- bicycle-only left turn lane (signed left turn)
- general purpose lane (unsigned turn)

How this should be tagged?

Following is my idea but...

highway, name, lit=yes, surface=asphalt etc
oneway=yes
oneway:biycle=no
lanes=1 (as bicycle lanes are not counted)
vehicle:lanes:forward=no|yes
bicycle:lanes:forward=designated|yes
turn:bicycle:lanes:forward=left|
turn:lanes:forward=|
vehicle:lanes:backward=no
bicycle:lanes:backward=designated





cycleway:left=lane
cycleway:right= - there is left turn lane only, so 
cycleway:right=lane would be
not entirely correct but there is a left turn lane, cycleway:right would 
be worse


I've always understood the cycleway:left/right=lane to refer to the 
presence of a bike lane on one side of the physical roadway or the 
other, regardless of the direction that lane travels. After all, the 
keys aren't cycleway:forward/backward. For example, in a country that 
drives on the right, a contraflow bike lane on the right side of the 
roadway would be tagged cycleway:right=opposite_lane, not 
cycleway:left=lane.


A *:lanes key might be one way to clarify the layout of that part of the 
road: cycleway:left=lane cycleway:left:lanes=2. But note that the turn 
lane tagging you suggested above is distinct from the considerations 
around cycleway:*; your suggested tagging for turn lanes seems 
reasonable to me.


[1] https://taginfo.openstreetmap.org/keys/cycleway%3Aright%3Alanes

--
m...@nguyen.cincinnati.oh.us


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

Re: [Tagging] Animal trails

[Minh Nguyen via Tagging]

Vào lúc 16:32 2020-11-30, Warin đã viết:
I would not encourage the use of the tag 'animal' as it is a real mess! 
See taginfo for the variety of values that have no coordination. Example 
animal=wellness ... for which animals and then the problem of tagging 
that... terrible.


animal=wellness is a terrific example of conflicting key usage [1] 
between "It is for ___ animals" [2] and "It is a ___ for animals" [3]. 
It looks like there's already been an effort to deconflict this usage, 
with amenity=animal_boarding now pairing with animal_boarding=* and 
amenity=animal_training with animal_training=*. Meanwhile, access 
restrictions use freestanding keys like horse=* and dog=*, and the 
hazard=animal_crossing proposal currently would use hazard:animal=* or 
hazard:species=*. [4] If these "It is for ___ animals" usages are out of 
favor, then there would be no conflict in adopting highway=path 
animal=yes cow=yes or animal=path cow=yes for a cowpath.


Regardless, informal=yes seems especially appropriate for these 
animal-made paths.


[1] https://wiki.openstreetmap.org/wiki/Homonymous_keys
[2] https://wiki.openstreetmap.org/wiki/Proposed_features/Dog_training
[3] https://wiki.openstreetmap.org/wiki/Animals
[4] https://wiki.openstreetmap.org/wiki/Proposed_features/hazard

--
m...@nguyen.cincinnati.oh.us


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

Re: [Tagging] lanes - is "parking allowed" a parking lane?

[Minh Nguyen]

Vào lúc 06:17 2020-11-19, Tobias Zwick đã viết:

Hello all

First of all, in the past, we have explored many edge cases for the 
lanes-tag in various discussions and I am happy that for the most part, 
it seems to be quite well defined by now. However, there is one edge 
case which is not uncommon at all but still unclear or awkward to tag. 
Look at this:


https://westnordost.de/misc/2or1lanes.jpg

It is a residential road marked clearly for 2 lanes, so it seems obvious 
to tag it with lanes=2. But on the other hand, you'll notice that there 
are parking cars on the right side that effectively render the right 
lane unusable. These parking cars would (currently) be tagged I believe as


parking:lane:right=parallel
parking:lane:right:parallel=on_street

And the wiki states

 > And the following lanes should be excluded:
 > [...] Parking lanes [...]

So here is an ambiguity in the documentation. On the one hand, if the 
road has marked lanes, the number of marked lanes should be tagged, on 
the other hand, there are these kind of "parking lanes" which do not 
have their own space marked as a parking lane but simply absorb the 
space assigned to normal car traffic. In OSM tagging, these are also 
"parking:lane"s as far as I know.


We need to dissolve this ambiguity by defining a way how to distinguish 
between these two cases:


https://westnordost.de/misc/parallel_parking_lane.png
(1) a dedicated parallel parking lane. This lane should not count as a 
lane in the lanes-tag.
(2) (parallel) parking is allowed (and used). This should be irrelevant 
for the lane count.


My suggestion would be
(1) parking:lane:*:parallel = lane
(2) parking:lane:*:parallel = on_street

Maybe especially those who recently involved themselves with parking 
lane tagging out and about and its documentation could also state their 
point of view here. According to the wiki edit history, looks like at 
least Mateusz Konieczny, Supaplex030 and Minh Nguyễn were active.

What do you think?

There is also at least one data consumer I know about that is using 
parking lane information and displays it visually,
https://github.com/dabreegster/abstreet it would be good to know how 
they interpret and visualize the data.


I'm not intimately familiar with the highway engineering standards and 
driving rules in Vienna Convention countries, but I wonder if case (2) 
is (literally) an edge case where we can tag it as a parking lane but 
not count it separately in lanes=*. After all, the roadway doesn't have 
any purpose-built infrastructure for parking, even if that's what people 
are doing.


For high-resolution renderers, maybe we need some variation on 
lane_markings=* to indicate that the parking lane specifically is 
unmarked. Or maybe a way to explicitly indicate that two lanes overlap. 
There are other cases of overlapping lanes, like turning movements that 
overlap with bike lanes [1] and often require turning vehicles to sneak 
around vehicles going straight. [2]


[1] 
https://nacto.org/publication/urban-bikeway-design-guide/intersection-treatments/combined-bike-laneturn-lane/
[2] 
https://www.latimes.com/archives/la-xpm-2003-may-27-me-wheel27-story.html "You 
can drive side by side for a mile in the same lane, as long as it’s 
large enough."


--
m...@nguyen.cincinnati.oh.us


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

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

[Minh Nguyen]

Vào lúc 14:27 2020-05-13, Joseph Eisenberg đã viết:
At the US talk mailing list and 
https://wiki.openstreetmap.org/wiki/Talk:United_States_admin_level 
 
there has been discussion about whether or not certain features should 
be tagged as administrative boundaries in the States of Connecticut, 
Rhode Island and Massachusetts.


Thanks for everyone who has weighed in so far in this thread. By way of 
an update, the counties in Connecticut have regained their 
boundary=administrative and admin_level=6 tags. The regional councils of 
government (RCOGs) are currently tagged boundary=COG, and some of the 
mappers involved have shown interest in enriching Wikidata with the 
legal nuances of these administrative structures instead of making them 
boundary=administrative relations.


While all these States have counties, in some cases most of the 
government functions have been lost, and are handled by the State 
(admin_level=4) or Town/City government (admin_level=8).


However, I have the impression that in some countries, certain local 
administrative boundaries do not actually have "home rule", or the 
ability to make their own laws, for example in French-infuenced areas?


I think this is even clearly the case in some parts of the U.S. There 
are named but unorganized territories that never had a government of 
their own in the first place. For example, Todd County, South Dakota, is 
coextensive with an Indian reservation and doesn't have its own county 
government, but common sense would call for it to be mapped as an 
administrative boundary, for consistency with the surrounding organized 
counties.


There are also cities where neighborhood boundaries are so well-defined, 
well-known, and well-used that we can map them as administrative 
boundaries. In some cities, these neighborhoods have no councils or only 
advisory councils, but what matters more is that the city government and 
residents understand these boundaries to be the main formal way to 
divide locations within the city.


On the other hand, paper townships that were created as legal fictions 
to facilitate annexation shouldn't be mapped as administrative 
boundaries. After all, OSM is a resource for understanding geography, 
not the nuances of the legal system.


What is the minimum qualification for a boundary to be considered a 
boundary=administrative with an admin_level in your country?


I realize you were asking about other countries for a sense of 
perspective, but since I only have local knowledge in the U.S., here's 
an attempt at defining a set of principles for distinguishing 
administrative boundaries from non-administrative boundaries or 
non-boundaries in the U.S. (not necessarily applicable elsewhere):


* _A boundary may be disputed or undemarcated, but it should be 
delimited._ Otherwise, we would lead data consumers to misrepresent a 
subjective or poorly defined boundary as a crisp, objective line. We 
should not map the indeterminate boundaries of neighborhoods in many 
cities, nor ZIP codes, which are actually delivery routes.


* _OSM is a map, not an org chart._ If a district exists solely for a 
government entity to divide its workforce or allocate resources, it 
shouldn't be mapped as a boundary in OSM, even if it's possible to draw 
each district's territory. Examples of unmapped boundaries might include 
divisions of a state department of transportation and a city's police 
precincts. However, it would be a great idea to map the DOT's depot and 
each precinct's police station as POIs.


* _Administrative boundaries are designated by government authorities, 
not private entities._ A retail or residential development may have many 
of the trappings of a municipality, such as welcome signs or a 
homeowner's association that regulates front door colors. But with some 
rare exceptions, they aren't administrative boundaries because nothing 
changes about your relationship to the government depending on which 
side of the property boundary you stand on. Fortunately, named landuse 
areas can represent these boundaries decently. A religious group might 
divide a state into dioceses and parishes, but even if we were to map 
their boundaries, they would deserve a different boundary=* tag with a 
parallel level hierarchy.


* _Administrative boundaries are intended for the general public's 
everyday use, not for specialists._ It's common for junior high 
geography teachers to teach students about administrative boundaries but 
not more specialized boundaries. Welcome signs are a strong sign that a 
boundary is intended for the general public. A specialized boundary 
tends to be strongly associated with a particular government agency 
rather than the government as a whole. Examples of specialized 
boundaries are the Census Bureau's census-designated places and census 
tracts (for demographers), the Office of Management and Budget's 
metropolitan statistical are

[Tagging] Automated check cashing machines

[Minh Nguyen]

In the United States, there's a network of automated check cashing 
machines called SAM. The machines are usually found inside grocery 
stores and look like ATMs. Unlike conventional ATMs, they have no access 
to the banking network: they accept checks (or traveler's checks or 
money orders) and spit out cash. Whereas check cashing stores also offer 
payday loans (hence shop=money_lender), these machines only cash checks, 
and they aren't stores per se.


Since SAM has enough locations in the U.S., it would be a candidate for 
addition to name-suggestion-index, but first I'd like to get some 
feedback about the best way to tag it:


https://github.com/osmlab/name-suggestion-index/issues/2909

--
m...@nguyen.cincinnati.oh.us


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

Re: [Tagging] Fuel octane ratings: RON versus AKI

[Minh Nguyen]

On 2019-07-19 17:24, Minh Nguyen wrote:
Compounding the matter, for several years, the fuel:* wiki page has 
specified that octane ratings must be expressed in RON, which is used in 
more countries. [3] In a few countries including U.S., octane ratings 
are only posted in RON, not AKI.


This was a typo: I meant to say that, in a few countries including the 
U.S., octane ratings are only posted in *AKI*, not in RON.


--
m...@nguyen.cincinnati.oh.us


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

[Tagging] Fuel octane ratings: RON versus AKI

[Minh Nguyen]

This week's weeklyOSM [1] included a suggestion to minimize the number 
of fuel:* subkeys, which reminded me that the fuel tagging situation in 
the United States is actually quite complicated. The same generic grade 
of gasoline ("regular", "mid-grade", "premium") may have a different 
octane rating at one gas station than the station across the street, and 
each state has a different standard for the minimum octane that may be 
labeled with a particular grade. [2] What would be sold as premium 
gasoline in Alaska would be regular in South Carolina.


Compounding the matter, for several years, the fuel:* wiki page has 
specified that octane ratings must be expressed in RON, which is used in 
more countries. [3] In a few countries including U.S., octane ratings 
are only posted in RON, not AKI. Converting between AKI and RON would 
require knowing the MON, which AFAICT isn't published anywhere. 
Wikipedia does offer estimates for regular and premium grade, but they 
aren't reliable or specific enough to use as subkeys. [4]


I've updated the wiki page with statistics demonstrating that octane 
ratings are consistently mapped based on AKI in the U.S. [5] (If I'm 
wrong about this, then OSM is a better resource for finding unlawful 
stations than lawful stations.) It stands to reason that mappers would 
tag what they can plainly see rather than learn the intricacies of 
metrology.


From a data consumer's perspective, it's unfortunate that there's no 
single worldwide standard. But I think more data consumers would need to 
differentiate between different grades in the same region than across 
national boundaries. If we do want to remove the current ambiguity, we 
could define separate fuel:ron_* and fuel:aki_* subkeys, but that seems 
like a lot of work for little gain.


[1] http://weeklyosm.eu/archives/12232
[2] https://en.wikipedia.org/wiki/U.S._State_Fuel_Octane_Standards
[3] https://wiki.openstreetmap.org/wiki/Special:Diff/1033280
[4] https://en.wikipedia.org/wiki/Octane_rating#Measurement_methods
[5] https://wiki.openstreetmap.org/wiki/Key:fuel#United_States

--
m...@nguyen.cincinnati.oh.us


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

Re: [Tagging] Test prep centres and cram schools as amenity=prep_school?

[Minh Nguyen]

On 2019-07-06 14:20, marc marc wrote:

Le 06.07.19 à 15:17, Joseph Eisenberg a écrit :

provide after-school additional instruction


why it isn't still a school with another min_age/max_age
or any additional tag ?


For much the same reason that an acupuncturist's office isn't tagged 
amenity=doctor. If we establish an education=* key with a wide range of 
possible values, like healthcare=*, then that's a different story. But 
amenity=school is commonly understood by mappers and data consumers as 
an institution that provides a certain kind of educational instruction. 
We have dedicated tags for amenity=kindergarten/college/university, and 
kindergartens have more in common with elementary schools than these 
often retail-like establishments.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Tagging] Maxweight wiki page changes

[Minh Nguyen]

On 2019-07-06 04:49, Colin Smale wrote:
It is an intrinsic danger of international projects that words mean 
different things to different people. Hence the importance of keeping 
things objective, and recording facts, rather than judgements. It's 
about what things ARE, not what they are CALLED. It really doesn't 
matter if the tag uses "unladen" or "empty" or "tare" or indeed 
"abc001". What is important is that the chosen tag is well-defined, so 
people can translate the data to what it does (or does not) imply.

For example (my definition):
Bogie = composite of 2..n axles sharing a common load-bearing mechanism. 
Not to be confused with a Close-Coupled Axle Group where each axle has 
its own independent load-bearing mechanism.
With unladen/tare/empty, this is probably not exactly the same as kerb 
weight (Mass In Running Order), which includes things like fuel in the 
tank. Or is it "dry weight" without even the weight of the brake fluid? 
Is it defined as weight, or is it actually legally speaking mass? Which 
value is most easily accessible for mappers? Which value is most useful 
to data consumers?


This is an important point. Your average non-British layperson mapping 
businesses who happens to come across a weight restriction sign won't 
initially know the distinction between an axle and a bogie (guilty as 
charged), let alone tare and dry weight, so there's quite a risk of 
mistagging. Editor fields with human-readable labels can mitigate this 
risk somewhat, but after a modicum of research, I'm still unsure as to 
whether the signposted "empty weight" differs from "curb weight".


Personally, as an American, I don't have a problem with calling it 
either "empty" or "unladen" weight. I initially confused bogies with 
axles on the wiki, owing to "tandem" being much more common here, but I 
still find "unladen" to be self-explanatory, if slightly exotic. Maybe 
I've spent too much time pondering the maximum airspeed velocity of 
certain birds.


Are there any jurisdictions that make a distinction between specific 
definitions of "tare", "empty", "curb", or "dry" weight in weight 
restrictions? If not, there's no need to overdefine the tag. We already 
handwave about the definition of maxweight: does it refer to the weight 
of the portion of the vehicle currently on the bridge, or the entire 
vehicle? Different jurisdictions probably have differing definitions 
while using similar signs. Even the difference between empty and gross 
weight is insignificant for most trucks. [1]


To account for empty weight restrictions, a navigation application would 
have to ask the trucker their empty weight or perhaps the truck's 
make/model/configuration. It seems to me that the more important 
consideration is whether the application presents the user with the 
correct terminology. Whether the underlying data is based on uniform 
definitions internationally would be more important for analysis use 
cases, I suppose, but anyone trying to shoehorn the U.S. system of 
weight restrictions into a coherent international system is in for a 
world of hurt. [1]


[1] 
https://www.energy.gov/eere/vehicles/fact-621-may-3-2010-gross-vehicle-weight-vs-empty-vehicle-weight

[2] https://wiki.openstreetmap.org/wiki/Key:maxweight#United_States_2

--
m...@nguyen.cincinnati.oh.us


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

Re: [Tagging] Test prep centres and cram schools as amenity=prep_school?

[Minh Nguyen]

On 2019-07-06 06:17, Joseph Eisenberg wrote:

In May, yumean1119 suggested tagging Japanese "cram schools" as either
office=educational_institution + education = cram_school
or amenity=prep_school

And then iD and the name_suggestion_index started using amenity=prep_school


I added some test prep center and cram school chains to NSI [1] because 
I was dismayed at seeing so many of them tagged as ordinary schools. [2] 
The naming is admittedly unfortunate, but on the bright side, there 
doesn't seem to have been much confusion with college preparatory 
schools. Yay for presets. [3]


The NSI entry means it's easier for mappers to identify individual cram 
schools as being affiliated with these chains, as opposed to being 
college preparatory schools. So if there is consensus on a replacement 
tag, the existing features can be migrated either manually or 
automatically with more confidence than before.


[1] https://github.com/osmlab/name-suggestion-index/pull/2630
[2] http://overpass-turbo.eu/s/KuE
[3] https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dprep_school


I think that "education=*" is not yet supported as a key, so we should
use either amenity= or office= with "=tutoring" - for cram schools
that provide after-school additional instruction, an "=test_prep" for
facilities that only provide preparation for certain tests, like
Kaplan in the USA.


office=tutoring isn't a great fit, because then we can't easily 
distinguish these centers (some of which are just as large as 
neighborhood elementary schools) from independent tutors' offices.


Another term for these establishments is "supplementary education 
center", but that risks confusion with some other kinds of supplementary 
education. [3] And despite the "school" in "cram school", some of these 
establishments are educational institutions only inasmuch as acupuncture 
is healthcare [4], which is to say, debatable.


Incidentally, there's already a documented after_school tag used with 
kindergartens and childcare centers. [5] Not all test prep centers are 
after-school programs -- some are geared toward professional 
examinations -- but I think the overlap suggests that we should just go 
with something in amenity=* until we get around to overhauling 
everything with an education=* key.


[3] https://en.wikipedia.org/wiki/Supplementary_school
[4] 
https://wiki.openstreetmap.org/wiki/Key:healthcare#Specialities_for_healthcare.3Dalternative

[5] https://wiki.openstreetmap.org/wiki/Key:after_school

--
m...@nguyen.cincinnati.oh.us


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

Re: [Tagging] The actual use of the level tag

[Minh Nguyen]

On 2019-01-20 05:49, Tobias Zwick wrote:

Hi there,

In the wiki, the level tag is defined to be a 0-based-index so that
level=0 is the ground floor, i.e. at the street level. In other words, a
two-storey mall with no basement will have shops at level=0 and level=1.

This is intuitive for (at least) Europeans, people from Commonwealth
countries and parts of Asia as this coincides with common language.
However, in at least the USA, Canada, Japan, Korea, China and most
probably more regions, the floor at street level is denominated as the
"1st floor" in common language. In other words, it is a 1-based-index.


The numbering system can also vary by region within a country. Northern 
and central Vietnam uses a zero-based system while southern Vietnam uses 
a one-based system, and somehow both are national standards. [1] I'm 
unsure if there's a well-defined boundary between the two systems, but 
if there is, I like to think someone has built a building straddling the 
two, just to mess with us.


[1] https://en.wikipedia.org/wiki/Storey#East_Asian_schemes

--
m...@nguyen.cincinnati.oh.us


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

Re: [Tagging] weight limit in short tons

[Minh Nguyen]

On 2019-01-26 15:27, Warin wrote:

The only problem is the 'ton'.

I n the USA 2,000 pounds
In the UK 2,240 pounds.


Resolving this? units 'ton us' and 'ton uk' ???


I've been converting to pounds (lbs), which avoids this ambiguity with 
precise conversions. Apparently I'm not alone. [1] But I'd welcome a 
well-supported convention for U.S. tons so that data consumers don't 
have to guess whether the sign is expressed in pounds or tons.


[1] https://taginfo.openstreetmap.org/tags/maxweight=1%20lbs

--
m...@nguyen.cincinnati.oh.us


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

[Tagging] shop=chemist as "Drugstore" for Walgreens, CVS, Rite Aid, etc.

[Minh Nguyen]

Recently, iD was changed so that shop=chemist is labeled as "Drugstore" 
for American English users (and continues to be labeled "Chemist" for 
British English users). [1] An American mapping a Walgreens, CVS, or 
Rite Aid who searches for "drugs" will see the following choices, in order:


* Drugstore (shop=chemist, marked with a shopping cart icon)
* Pharmacy (amenity=pharmacy, marked with a pill bottle)

Meanwhile, searching for "pharmacy" -- a synonym of "drugstore" in 
American English -- produces only the amenity=pharmacy preset.


The rationale is that amenity=pharmacy should be used only for pharmacy 
counters (which can be found at both drugstores and inside 
supermarkets), while shop=chemist should be used for full-service 
drugstores that *may* contain pharmacy counters. Currently, this is at 
odds with the wiki and longstanding practice, which stipulates that a 
shop=chemist *may not* fill prescriptions.


This change to iD came about due to a discussion in the Name Suggestion 
Index project, which is the component in iD that suggests tags when you 
fill in a commonly used name. [2] I happened to notice the change 
because it caused Transifex to prompt me to update iD's Vietnamese 
localization. To my knowledge, there has been no discussion on the 
mailing lists or formal proposal on the wiki, though the iD maintainer 
intends to edit the wiki to match iD's interpretation. iD is the only 
software that has made this change.


On the one hand, I've come around to liking the proposal, because it 
makes it easier for data consumers to distinguish between pharmacy 
counters and full-fledged drugstores. On the other hand, I think it's 
problematic because an American mapping a Walgreens or CVS could 
potentially tag a "drugstore" and be unaware that they'd need to 
separately map the pharmacy counter in order to indicate that 
prescriptions may be filled on-site.


Currently, amenity=pharmacy is far and away more common than 
shop=chemist in the U.S. as a way to tag drugstores. Certainly anyone 
retagging amenity=pharmacy to shop=chemist would be careful to add an 
additional amenity=pharmacy POI where the pharmacy counter would be. 
(For a typical Walgreens or CVS, it'd be next to the drive-through 
canopy.) However, I have little faith that the average iD user would 
know to do the same, since the word "drugstore", like "pharmacy", 
implies the sale of prescription drugs.


I've hashed out many of these points in [3], but I think the discussion 
needs to involve the wider OSM community now. There's little chance of 
data consumers and other editors updating their logic if the change is 
only discussed in the iD project.


[1] https://github.com/openstreetmap/iD/issues/3201
[2] https://github.com/osmlab/name-suggestion-index/issues/30
[3] https://github.com/openstreetmap/iD/issues/3213

--
m...@nguyen.cincinnati.oh.us


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