[Imports] Proposed import: Cupertino, California

Frederik Ramm frederik at remote.org
Fri Oct 16 06:16:36 UTC 2015


Hi,

On 10/16/2015 06:23 AM, Eric Jiang wrote:
> I have requested building footprint and address data from the city of
> Cupertino, California, and written some scripts to process it for
> import into OSM. It would be great if you could read over the proposal
> on the wiki, which also contains links to the data and scripts:
> 
> https://wiki.openstreetmap.org/wiki/Cupertino_import
> 
> Cupertino is a pretty small city and their data looks to be relatively
> high quality. I would like to hear from you any concerns or problems
> that I can try to fix.

Your wiki page says:

1. Merge addresses with building footprints. (See scripts in Github repo)
2. Manually import one neighborhood at a time to resolve conflicts with
existing data.
3. Survey any suspicious data

Do you have the manpower to do 2 and 3, or is there a danger of these
steps being reduced to cursory glances ("it can still be fixed later")?
I would recommend to not import anything suspicious in the first place
because that will drastically reduce the incentive to survey ;)

Regarding the data, it looks ok so far (not everyone may be prepared to
run your code to see what it does - perhaps provide a "compiled" OSM
file for review?). I would suggest to not add building=yes to inner
rings of building relations. Also the source data seems to contain
information about the height of the buildings, and I'm pretty sure the
OSM 3D crowd would much appreciate if that were imported too.

Some houses, e.g. 20425 Via Paviso, look really skewed (just as if I had
traced them manually and then forgot to let the editor make it square).
Some are a bit over-noded IMHO, like 21102 Tamarind Court. It seems that
the more nodes a footprint has, the more likely it is to be a little
dodgy - perhaps manual verification should be concentrated on these
larger things.

I din't immediately see many building-intersects-existing-street cases
(one example 10361 Ann Arbor Avenue) but of course these must be
carefully fixed in the manual import process (which may often mean
fixing existing OSM data).

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"



More information about the Imports mailing list