[Talk-us-massachusetts] Would using alt_name help?

[Greg Troxel]

[Alan and I have had a big conversation off list; following up a bit here]

"Alan & Ruth Bragg" <alan.ruth.bragg at gmail.com> writes:

> "The Great Road" is the official name of the main drag in Bedford. Street
> signs are inconsistent, some say "Great Road" others say "The Great Road".
> The MAD street addresses are "Great Road"
> I have set OSM name="The Great Road" and alt_name="Great Road"
>
> I'm hoping the GIS data manipulation software could be set to look at both
> name= and alt_name=?

Certainly, if we have a import processing requirement that the
addr:street field in an address much match a nearby road, then we should
probably consider it a match if it matches one of the alt_names.

However, the point of matching is to look for things that are perhaps
wrong, as part of our duty to ensure that the import is very high
quality.   addr:street matching an alt_name is at least somewhat
irregular, so we probably should be looking at those cases and asking
"is this actually right?".

In this case, your explanation is quite convincing, and I believe this
is a case where the official street name and the addr:street in
addresses are not the same.  And alt_name is appropriate because the
variants are 1) actually names and 2) used to name the road in a
semi-formal or better sort of way, separately from talking about
addresses.

> alt_name is explained here https://wiki.openstreetmap.org/wiki/Names
>
> Alternative name by which the feature is known. If there is a name that
> does not fit in any of the above keys, alt_name can be used, e.g.,
> name=Field Fare Road and alt_name=Fieldfare Road, or name=University Centre
> and alt_name=Grad Pad. In rare cases, the key is used for multiple
> semicolon-separated names, e.g. alt_name=name1;name2;name3, but this usage
> is not preferred.

If the *road itself* is actually known by an alternative *name*, then
alt_name makes sense.  That leaves out two cases where I think alt_name
is inappropriate:

  road is not known by the name, but addresses use it.  (I think "State
  Highway" for US 6 is one of those cases.)

  The alternative reference is not actually a name, such as "Route 6",
  which is a way to represent the information stored in a ref tag.

In the second case, if we can validate that "3850 Route 6" is a
legitimate address as recognized by the local people, local government,
USPS, etc., then I think it's fine to consider that a match for QA
purposes.  But we should not put "Route 6" in an alt_name tag; that's
just spamming the database with something that's already there as
"ref=US 6".

Plus, adding an alt_name of Route 6 fails the OSM general test of "would
we do this for correctness, if we weren't thinking about an import".  So
adding things that don't belong in the name of the import breaches our
duty of import quality.

> On the Cape hundreds of MAD addresses use the route number for sections of
> MA and US highways.
> Route 6 for OSM "Grand Army of the Republic Highway",
> Route 6A for OSM "Cranberry Highway",
> Route 130 for OSM "Forestdale Road",
> Route 28 for OSM "Main Street"

These are all in ref tags. (Interesting that two are US and two state,
and they are written the same way -- but addressing authorities do what
they do and ours is to record not challenge.)  I think we can deal with
this by having a table of pairs of addr:street and ref that are
considered matching (and thus evidence of non-broken addrs) for QA
purposes.  That is the purpose of the matching -- to guard against bad
data, not because there is some rule that addr:name and the way name tag
have to be the same.



Finally, there was some earlier notion that some navigation program does
not find addresses if addr:street and a way's name tag don't match.  Two
thoughts:

  we should (and I will) dismiss this as speculation until we have real
  data

  programs that behave this way are broken, because there's nothing in
  the real world stopping street naming authorities and address
  authorities from being inconsistent.  And we have ample evidence
  already of actual inconsistencies (the Route 6 cases, (The) Great
  Road, and the north/west woodlawn(?) case).

which means I think it's ok to import data when addr:name and a way's
name tag don't match -- as long as we have examined it and believe both
to be correct.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-us-massachusetts/attachments/20180819/563aa06c/attachment.sig>