<div dir="ltr"><div><br></div><div class="gmail_quote"><div dir="ltr">On Mon, Nov 9, 2015 at 7:34 PM Paul Norman <<a href="mailto:penorman@mac.com">penorman@mac.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/8/2015 8:58 PM, Andy Wilson wrote:<br>
><br>
> If you could find time to look things over, we would really appreciate it.<br>
<br>
Looking over the wiki documentation, I have a few comments<br>
<br>
- The Google group<br>
(<a href="https://groups.google.com/forum/#!forum/atx-osm-import" rel="noreferrer" target="_blank">https://groups.google.com/forum/#!forum/atx-osm-import</a>) is currently<br>
set to private.<br></blockquote><div><br></div><div>Didn't realize that. It has been made public.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- There seems to be inconsistency in how height is being handled. The<br>
wiki says cm, but the github repo is saying it's to the nearest 10cm.<br>
Meanwhile, the data that was inadvertently imported early has stuff like<br>
height=3.9099999999999997<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- There's no mention of merging with existing POIs, e.g.<br>
<a href="http://osm.org/way/379207894" rel="noreferrer" target="_blank">osm.org/way/379207894</a> and <a href="http://osm.org/node/368164079" rel="noreferrer" target="_blank">osm.org/node/368164079</a></blockquote><div><br></div><div>Good point. I've added that as a follow up/clean up task.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- How has the accuracy of the city data been assessed?<br></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- You're proposing the changeset tags source=City of Austin; and a<br>
comment ending with "#atx-buildings-import, source=City of Austin".<br>
<br>
I recommend adding an import=yes tag to the changeset, and I'm not sure<br>
what purpose the end of the comment has. The source is already indicated<br>
with the source tag, and if you need to track changesets beyond that,<br>
another tag linking to the import documentation would be better than<br>
trying to parse the free-form text of the comment tag.<br>
<br>
Also, you want to encourage people to use good changeset comments that<br>
describe what they did, not a bunch of identical comments.<br>
<br>
I also found the changeset tag information somewhat buried, I'd<br>
recommend moving it out of the sub-page<br></blockquote><div><br></div><div>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.</div><div><br></div><div>We will add the import=yes tag to changesets.</div><div><br></div><div>Linking to the import docs from changesets also makes sense. Is there a standard tag to use for this? url?</div><div><br></div><div>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.</div><div><br></div><div>I'll add changeset tag info to the main import page.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- You're proposing using a coa:place_id tag. There are four issues with<br>
this. The first is that there seems no confirmation of stability from<br>
the city, only uniqueness. I've seen a number of cases where an ID that<br>
people thought was relatively stable turned out not to be.<br>
<br>
The second issue with it is that referencing external keys that can't be<br>
verified is discouraged.<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The third is that any future update workflow has to work with objects<br>
that don't have this key.<br>
<br>
The fourth is that history has shown that IDs like this don't get used,<br>
and tend to bit-rot because of the above reasons. Other imports have<br>
proposed or have used keys from external sources, and they never got<br>
used for updates. Do you have concrete plans here?<br></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><div>Thanks for your help, Paul!</div></div></div>