<div dir="ltr">Sure, if adding villages as admin_level=8 is relatively easy, I would prefer this solution instead of adding addr:suburb.<br>When mentioning "not allowed" to import zipcodes, I was expressing my suspicions that MassGIS may probably not have rights to distribute the zip-code data, though, it is just my guess</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 5, 2019 at 8:04 PM Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yury Yatsynovich <<a href="mailto:yury.yatsynovich@gmail.com" target="_blank">yury.yatsynovich@gmail.com</a>> writes:<br>
<br>
> Not sure. Western Mass doesn't have counties as admin_level 6 because, as<br>
> the note says, that "there is effectively no county-level government here".<br>
<br>
That is bogus, and I consider the deletion vandalism.  It may be true<br>
that the county government is empty, but counties are still a thing, and<br>
people know what county they are in, and it matters.  You have to put<br>
down what county you live in on all sorts of government forms, including<br>
searching for health insurance on the connector.  When you cross town<br>
lines the signs say what county you are in, at least when changing<br>
counties.  The Army cares about counties and has a program of getting<br>
information about disaster status per county, via the Military Auxiliary<br>
Radio System.  So I think Franklin and Hampshire county still matter and<br>
should have a level6 (because that's how we spell county in osm :-) on<br>
the map.<br>
<br>
And agreed that the named villages of many towns do not have separate<br>
governments.  Nor do wards and precincts, which is the other thing<br>
people say belong in 9 and 10.<br>
<br>
So if county deletionism prevails, we should not have level9.  But<br>
really we should have counties.<br>
<br>
> My suggestion would be to include addr:suburb for the cases when two or<br>
> more identical addresses exist within a city<br>
<br>
I strongly object to addr:suburb.  There is no established usage of<br>
anything named a suburb in Massaschusetts at all.  It does not appear in<br>
addresses.  We should not be trying to grab random notions from OSM that<br>
map to the way addresses are in other parts of the world and use them as<br>
part of fitting a database model to the osm model.   So far, I haven't<br>
seen an address that is more than just a word in the town slot -- partly<br>
because everything in the US expects names to be<br>
<br>
  house-number road-name<br>
  town-name, state-name  zip-code<br>
<br>
so addresses that don't fit  that pattern are too awkward and aren't<br>
assigned.<br>
<br>
<br>
>>>> 2. While checking the ???Street Name Mismatches??? is there anything we<br>
> should do on the google spreadsheet if it seems like the MAD name is wrong?<br>
><br>
> I was recording what is written on the street sign (column "What is written<br>
> on street signs?") and, if OSM is wrong, correcting the street names in<br>
> OSM. The cases when MAD is wrong can be corrected automatically before the<br>
> import<br>
<br>
If MAD is wrong it would be helpful to talk to the town officials that<br>
send data to MAD, separately from the process of mapping known MAD<br>
erroneous names to the correct names (for variances in spelling and<br>
spacing and other minor stuff where it's really really obvious that it's<br>
the same name, munged).<br>
<br>
> Indeed, it also happens that different spelling can be seen on different<br>
> street signs along the same street within the same town. In such cases I<br>
> add a note to the Google spreadsheet that both names are possible.<br>
> It would be great, if we had lists with official street names to<br>
> resolve/automatically correct such spelling/punctuation discrepancies.<br>
<br>
MAD is an official list of names; it came from the towns.  It's just<br>
that official lists have errors.<br>
<br>
>>>> 4. Were the street names in MAD originally in all caps or should we<br>
> notify the local assessor???s office if the capitalization is wrong in the<br>
> google spreadsheet? i.e.: "J a McDermott Circle" or "Oconnor Drive"<br>
><br>
> Wrong capitalization of names in the Google Spreadsheet (like "Oconnor<br>
> Drive") is a result of my code's' imperfection -- I've been recording such<br>
> cases and adding to the dictionary in the code to improve it. But, true,<br>
> absence of, say, " ' "- sign (shouldn't it be "O'CONNOR DRIVE" in the<br>
> capital case instead of "OCONNOR DRIVE"?) might be worth reporting. But,<br>
> again, how do we know that the official street name is not "OCONNOR DRIVE"?<br>
<br>
I think this is tough, and it's a really interesting question if street<br>
names are upper case only or if they are mixed.  Pretty obviously MAD<br>
thinks they are upper.   I don't know what the towns think when they<br>
assign them.<br>
<br>
<br>
>>>> 5. I have also noticed other weirdness such as where the Humarock<br>
>>>> section of Scituate uses Marshfield???s Zip code. Do Zip codes matter for<br>
>>>> the MAD import?<br>
<br>
zip codes are a post office thing that organizes delivering mail, and no<br>
more.  It is perfectly ok for a street in one town to have the zip code<br>
of an adjoinging town.  But the town name should match the town it is<br>
in.<br>
<br>
> So far I'm keeping zip codes in the files for import, but not using them<br>
> for any matching and, as wiki says, we are probably not allowed to import<br>
> zip codes.<br>
<br>
I don't follow "not allowed".  We have permission from MassGIS - are you<br>
saying that you think MassGIS doesn't really have rights to distribute<br>
zip code information?  Or that OSM shouldn't have zip codes?  Or ???<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Yury Yatsynovich</div>