[Imports] Importing Buildings and Addresses for Austin, Texas

[Andy Wilson]

On Mon, Nov 9, 2015 at 7:34 PM Paul Norman <penorman at mac.com> wrote:

> On 11/8/2015 8:58 PM, Andy Wilson wrote:
> >
> > If you could find time to look things over, we would really appreciate
> it.
>
> Looking over the wiki documentation, I have a few comments
>
> - The Google group
> (https://groups.google.com/forum/#!forum/atx-osm-import) is currently
> set to private.
>

Didn't realize that. It has been made public.


> - There seems to be inconsistency in how height is being handled. The
> wiki says cm, but the github repo is saying it's to the nearest 10cm.
> Meanwhile, the data that was inadvertently imported early has stuff like
> height=3.9099999999999997
>

This was just resolved today. It will be rounded to 10cm and we'll have to
go back and fix those bad already-imported values. This has been added as a
follow up task.

- There's no mention of merging with existing POIs, e.g.
> osm.org/way/379207894 and osm.org/node/368164079


Good point. I've added that as a follow up/clean up task.


> - How has the accuracy of the city data been assessed?
>

Mostly by visual comparison to aerial and satellite imagery. I've talked to
some people familiar with the project and the QA/QC process that went into
the planimetrics dataset that the building footprints is taken from was
fairly rigorous. The addresses are a monthly export of the dataset that the
city uses to route emergency vehicles.


- You're proposing the changeset tags source=City of Austin; and a
> comment ending with "#atx-buildings-import, source=City of Austin".
>
> I recommend adding an import=yes tag to the changeset, and I'm not sure
> what purpose the end of the comment has. The source is already indicated
> with the source tag, and if you need to track changesets beyond that,
> another tag linking to the import documentation would be better than
> trying to parse the free-form text of the comment tag.
>
> Also, you want to encourage people to use good changeset comments that
> describe what they did, not a bunch of identical comments.
>
> I also found the changeset tag information somewhat buried, I'd
> recommend moving it out of the sub-page
>

I don't remember exactly where that changeset comment came from - I just
copied and amended it from somewhere. We can drop the source from the
comment text.

We will add the import=yes tag to changesets.

Linking to the import docs from changesets also makes sense. Is there a
standard tag to use for this? url?

I agree that good changeset comments are important. In our case, the
process will be uniform across different import pieces so the import
documentation should answer any questions about what was done. We will
definitely note any deviations from that norm, but I think the common case
will have identical information in the comment text.

I'll add changeset tag info to the main import page.


> - You're proposing using a coa:place_id tag. There are four issues with
> this. The first is that there seems no confirmation of stability from
> the city, only uniqueness. I've seen a number of cases where an ID that
> people thought was relatively stable turned out not to be.
>
> The second issue with it is that referencing external keys that can't be
> verified is discouraged.
>


> The third is that any future update workflow has to work with objects
> that don't have this key.
>
> The fourth is that history has shown that IDs like this don't get used,
> and tend to bit-rot because of the above reasons. Other imports have
> proposed or have used keys from external sources, and they never got
> used for updates. Do you have concrete plans here?
>

No real plans on how to use it. This was suggested on the imports-us list
and it sounded like a probably-good idea. I'm okay with dropping it.


Thanks for your help, Paul!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20151110/aa6d4ca3/attachment.html>