[Imports] Miami-Dade County building import

[Levente Juhász]

Hi Clifford,

Thanks for your effort on checking the data! Comments inline.

Picking just one of the sample file I noticed that the street address is
> abbreviated and no tag addr:city.
>
> NE 18th Avenue should be Northeast 18th Avenue
>

According to the Wiki, addr:city is not needed in general "if there are
valid border polygons" - which is the case in Miami-Dade. These entries
were not populated because "city" is missing from the county's address
dataset, though. Nominatim will have no trouble finding the right city
based on addr:housenumber and addr:street. (e.g. see an address without
city:
https://nominatim.openstreetmap.org/search.php?q=1180+sw+137th+ave+miamI&polygon=1&viewbox=
)
As for the abbreviated prefixes, it just didn't seem natural to spell out
Northeast. Both the County and USPS list street prefixes in an abbreviated
format so I think that should be considered the "official" address.
However, we see your point. And since all streets in OSM seem to have names
like "Northeast 18th Avenue", we are going to compile with this existing
notation and will spell out all prefixes as well. So Northeast 18th Avenue
it is!

(OFF: And while this is outside of the scope of our import, it raises some
interesting questions. Of course they shouldn't be addressed here but in a
different thread instead. I haven't received a single mail saying
"Northeast 18th Avenue". They're all sent to "NE 18th Ave". Also,
abbreviated addresses are used in official documents, like government IDs
and so on. So why not using the official US address in OSM instead of
spelling out everything?)


> Another sample I noticed that a building outline was made of of two
> polygons with two different objectids. See objectid 75375 and 54910
> in mia_building_1541.osm. It didn't appear that any of the buildings had
> addresses.
>

Good catch! They're errors in the official building dataset. However, these
buildings you found are to be manually reviewed in a Tasking Manager job
(hence the name mia_building_1541.osm, that stands for the US census block
group id 1541). In any case, just checked on the whole dataset and there
are only a couple hundred building pairs where the boundary is shared at
some level (these cases also contain those where buildings outlines really
share a common border). Just to be on the safe side, flagging all of them
for manual review as these can be easily corrected by a human in a Tasking
Manager job. Of course there will be detailed instructions on how to do
this, and it will also be illustrated on screen at Maptime meetups.
In those files, addresses are not assigned to buildings but rather are
attached as individual nodes. So it's going to be the reviewer who decides
whether it's appropriate to assign the address to the building or they
should be uploaded as nodes (if there are multiple nodes overlap with the
same building).


> I'd recommend not doing a scripted upload instead break the data into
> small chunks for use in Tasking Manager. It means you'll have to spend more
> time recruiting new mappers, but it will be well worth the effort.
>

Thanks, we've decided to take a vote on Monday at the next MaptimeMIA
meetup [1]. So we will either
- proceed with the original plan of bulk uploading buildings with no
detected conflicts + manually reviewing the remaining ones
- or drop the bulk upload idea and proceed with entirely a community import
process.

Cheers,
Levente

[1] http://www.meetup.com/Maptime-Miami/events/232730098/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20160727/dafe7b7d/attachment.html>