[Imports] [Imports-us] Miami Address Import
Greg Troxel
gdt at lexort.com
Wed Sep 19 12:24:02 UTC 2018
Mateusz Konieczny <matkoniecz at tutanota.com> writes:
> 16. Sep 2018 21:47 by 354lbr at gmail.com <mailto:354lbr at gmail.com>:
>
>
>> * The import will add about 500,000 addresses in Miami-Dade County, Florida over the course of several months. > (...)
>> * The addresses don't have suffixes. Main Street East would have
>> "addr:street"="Main Street". This resulted from a transformation
>> error, and will most likely be fixed before uploading.
> Please, please, do not import addresses without fixing this.
Even more strongly, I think that an import with any kind of structural
data problem is against the guidelines and simply must not happen.
Please consider this an objection until that issue is resolved. But
also note that I don't object to the import if done well.
It is the duty of those proposing an import to explain how they have
validated the data so that there is a good basis for confidence that
there are no structural data problems.
Of course, it may be that 1 in 10000 points has a typo, or 1:10K
addresses are misplaced by 100m. That's ok, but anything that is wrong
at scale is not ok.
Also, I don't follow "data transformation error". Best practices for
imports are to have software (that can be run repeatedly, without human
clicking) that takes the published data to be imported and the current
state of osm, and produces changeset files, and reports of matches,
mismatches, and other QA information. So if the problem is in the
source data, it needs to be fixed there - or the problematic addresses
skipped in this phase for now. If it's in the processing code, that
needs to be fixed and rerun.
More information about the Imports
mailing list