[Imports] Which Elements of kml to Include

[smocktaylor at gmail.com]

Assuming that the license of the data is compatible, I would drop the
following fields:
* OBJECTID
* AddressID (this may be optional -- if kept, it should be a ref, like
ref:athensclarkaddress or something, if a mechanical import and update
process is to be used)
* ParcelID
* JOINID
* GlobalID

The following fields would be useful, but should not be added to OSM:
* Status (this may be used to filter data, e.g. don't bother adding
addresses that have a status of "don't build")
* Anomaly (this can be useful if the data has an issue, e.g. the actual
road name is "West Main Street" but the street address is "East Main
Street", may be useful as a note)
* Comments (Same as Anomaly, may be useful as a note)

Without a sample, I cannot get more specific.

For example, it is possible that FullAdd might look something like "402
1/2 W MAIN ST" or "402 1/2 E RD".

Beyond that, and I'm guessing,
* StreetName -> `addr:street`
If StreetName doesn't have the suffix, and StreetType looks like "RD"
or "Road", then append the expanded street type to `addr:street`

* `Unit` -> `addr:unit` (you may want to check UnitType, I have no clue
what that looks like)
* `Floor` -> `addr:floor`
* `City` or `POSTALCITY` (use whatever the locals use when giving
directions) -> `addr:city`
* `State` -> `addr:state`
* `zipcode` -> `addr:zipcode`

Beyond that, some common gotchas:
* Dropping special characters (e.g. `/`) or ignoring a field that
includes additional information (e.g., fractions) for
`addr:housenumber`
* Expanding `E`/`W`/`S`/`N` to cardinal directions, when it is the
actual name of the road (check nearby road names -- if a nearby road is
named `F`, then you probably shouldn't expand `E`)
* Not expanding `E`/`W`/`S`/`N` to cardinal directions (i.e., W Main
Street -> West Main Street)
* Not expanding abbreviations (e.g., ST to Street)
* Failing to account for the McNames

On Fri, 2021-01-22 at 12:40 -0500, Ian Van Giesen wrote:
> Hello everyone, 
> 
> I am looking to start eliminating unnecessary tags and joining
> redundant tags from an address .kml file I downloaded from my
> county's website (Athens-Clarke County Gov website). I looked on the
> wiki regarding imports and the kind of data that should remain and
> the kind that shouldn't and I believe I read a page that suggested
> asking here as this process requires good judgment for a high quality
> import. 
> 
> I am including (in the order they appear on the .kml) all possible
> SimpleField names: OBJECTID, AddressID, ParcelID, FullAdd, HouseNum,
> HouseNUmEx, FullHuseNum, PreDir, StreetName, StreetType, PostDir,
> FullStreetName, UnitType, Unit, Building, Floor, City, POSTALCITY,
> State, Zipcode, AddClass, AddType, Status, Anomaly, AddStart, AddEnd,
> EditDate, Comments, JOINID, GlobalID. 
> 
> Based on other imports, could anyone provide guidance on which tags I
> should keep and which I should filter out?
> 
> Thank you very much!
> Ian
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports