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
<m...@nguyen.cincinnati.oh.us
<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
