San Jose Basemap (building+address) import

[impiaaa]

Previous work:

• Importing San Jose building footprints into OSM codeforsanjose/OSM-SouthBay#4

Open questions:

• Figure out what to do with condos
• Decide on meters or feet
• Decide on "house" or "detached"
• Which sjc: tags are worth keeping and which should be omitted?
• What is the source data's vintage?

Preprocessing steps (to rewrite in SQL):

• Automatically group or remove large address sites (apartments, hotels, etc.)
• Expand street abbreviations/align with OSM
• Translate OSM tags
• Small parcel, one address, one major building: Single home, put address on building.
• Large parcel, one address, one major building: Possibly site (school, hospital, office). Put address on building or parcel.
• Small parcel, multiple addresses, one major building: Condo or duplex. Leave address points.
• Large parcel, multiple addresses, one major building: Office/apartments/hotel/other development. Delete, merge, or leave depending on clustering
• Large parcel, one address, multiple buildings. Possibly site (school, hospital, office). Put address on parcel.
• Large parcel, multiple addresses, multiple buildings: Possibly settlement (mobile home park). Try to combine addresses with buildings. If common addtl_loc, use for parcel.
• Intersecting building: Condo or unit. Leave address point.

Manual steps:

• Join multi-part buildings

Process:

• Create import/dividing/conflation plan
• Create a wiki page
• Get community buy-in
• Add to Import/Catalogue
• Document acknowledgement
• Import review
• Create dedicated user account(s)

[1ec5]

Figure out what to do with condos

Is the issue that there can be multiple addresses for a given building? If so, it’s fine to map the addresses as points within the building area.

[impiaaa]

If that's what you think is best then that's fine and I can check it off. But I was considering other options:

• Any of the options here, especially combining them with semicolons or using addr:interpolation.
• The Parcel and CondoParcel layers delineate the differently owned parts of the building. This could be used to split the building footprints, each part of which could get its own address.
• Instead of completely splitting the buildings, each split part could become building:part.

[1ec5]

Any of the options here, especially combining them with semicolons or using addr:interpolation.

The downside to tagging the addresses on an overall building, separated by semicolons, is that we lose some precision and don’t say where in the building a specific address is located. That’s fine if the source data isn’t very precise, but it sounds like we have more precise data than that.

The Parcel and CondoParcel layers delineate the differently owned parts of the building. This could be used to split the building footprints, each part of which could get its own address.

This is a good option as long as the adjoining areas share nodes. (This is something JOSM can help with too.)

Instead of completely splitting the buildings, each split part could become building:part.

This is also a good option as long as the building part areas share nodes with the containing building areas.

[impiaaa]

That’s fine if the source data isn’t very precise, but it sounds like we have more precise data than that.

A separate concern would be apartment buildings (and hotels‽) that actually list every single unit without specific positioning, but I figured those would have to be merged or filtered out regardless.

This is a good option as long as the adjoining areas share nodes.

They do, but some parcels very slightly overlap buildings from other parcels, so we'd have to have some way of ignoring those. Actually, the address-joining script would benefit from an expanded parcel threshold as well…

This is also a good option as long as the building part areas share nodes with the containing building areas.

Well, that's the problem. The CondoParcel layer outlines buildings on its own, and the nodes don't line up exactly with the buildings layer. We'd have to take an extra step to align them.

[1ec5]

I started a draft proposal on the wiki. As we figure out the preprocessing steps and decide on the questions above, we should document the decisions on the wiki page.

[1ec5]

Decide on meters or feet

F4Map only supports height tags in meters, not feet. 🤷‍♂

[impiaaa]

* Decide on meters or feet

Checked again, and unless something is happening in the SQL import, building heights are in feet to two decimal points and minimum increments of 0.01, so converting to meters with the same precision should be fine. Although, there are some buildings with very small or even ≤0 height, so I need to check what's wrong with those.

Edit: Building elevations are similar: two digits after the decimal point, and a minimum of 0.01 increment. There is one building with elevation 0, and two with elevation at -880.

[impiaaa]

What is the source data's vintage?

In BuildingFootprint, there is a field "LASTUPDATE" that can have the values 2014/06/13, 2008/12/19, or 2008/12/18. Not every building has that field set but we might just want to assume nothing is newer than 2014.

In Site_Address_Points, there is a field "LastUpdate" that ranges from 20180318183848 (guessing 2018/03/18 18:38:48) to 20190427170340 (guessing 2019/04/27 17:03:40).