<div dir="ltr">Thanks Jason and Serge,<div><br></div><div>To address the 5 occurrences of the word "will" on the wiki page, "will" means "Expressing the future tense", ie consensus happens prior to commencement of work, which is the primary motivation for this discussion.  The stated target completion date is the end of 2013, but I'd frankly like the work to be done (well) before the October editathon.  Once work starts I'd be glad to update the wiki page to use present tense ;-).</div>
<div><br></div><div>The LWG has not seen this, as I was not aware of that requirement, and assumed the Import US group provided comprehensive guidance. </div><div><br></div><div>On address points, they are "available" via online scanned parcel maps of the city; I am not committing to hand transcribing some 29,000 points.  I'd suggest that exercise as a future editathon/MapRoulette project via the Tasking Manger or similar.  If consensus is that building outlines are not useful without addresses, please explicitly state that now to save time and effort.  Again, I am not proposing individually adding address points; this proposal is for building outlines (and perhaps land use updates) only.</div>
<div><br></div><div>WRT to PA land use, those polys are already in the OSM DB, and many appear rather rough.  The city has a reasonable set of shapes, for example, there are about 56 parks, and it seems useful to improve them where possible.  If the plan is to remove them from OSM across the board, I will drop the idea.</div>
<div><br></div><div>I will investigate outline simplification, and will handle the dups and intersections as I process the buildings.</div><div><br></div><div>Good point on the rooftops, I saw no level attribute, but will revisit.  If there is no obvious way to remove; I'll again handle by removing as updates are applied via JOSM.</div>
<div><br></div><div>On the subject of including ids and future updates, the idea that ids are not very useful appears to be in conflict with the notion of continuing maintenance.  The IDs are apparently persistent, and therefore are useful for future update efforts.  Removing the source ids seems to add complexity to future update efforts.  While I understand no method is perfect, not including them when present seems suboptimal.  How about paloalto_ca:id for the id tag ?</div>
<div><br></div><div>I will switch to changeset level source tagging, and change the tag text to "City of Palo Alto CA 0713", unless something else is preferred.</div><div><br></div><div>On processing, I loaded a csv file of the data into PostGIS, validated geometry, then extracted a shapefile containing only the useful columns and filtered for outlines that are proper polygons via ogr2ogr.  I then generated the osm file from the resulting shapefile via ogr2osm.</div>
<div><br></div><div>Again, thanks for the quick feedback; it is appreciated.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 22, 2013 at 8:17 AM, Serge Wroclawski <span dir="ltr"><<a href="mailto:emacsen@gmail.com" target="_blank">emacsen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, Jul 22, 2013 at 10:25 AM, the Old Topo Depot<br>
<<a href="mailto:oldtopos@novacell.com">oldtopos@novacell.com</a>> wrote:<br>
<br>
<br>
</div><div class="im">> The city of Palo Alto, CA has released a set of building outlines, and I've<br>
> created an .osm file from that data at<br>
> <a href="https://github.com/oldtopos/PaloAltoCA" target="_blank">https://github.com/oldtopos/PaloAltoCA</a><br>
<br>
</div>Comments on the osm file at the bottom.<br>
<div class="im"><br>
> A wiki page discussing this proposal can be reviewed at<br>
> <a href="http://wiki.openstreetmap.org/wiki/Palo_Alto,_California/Buildings_Import#Data_Transformation_Results" target="_blank">http://wiki.openstreetmap.org/wiki/Palo_Alto,_California/Buildings_Import#Data_Transformation_Results</a><br>

<br>
</div>John,<br>
<br>
The purpose of this list, and this group, is to work collaboratively<br>
and also to build consensus, so I'm glad you're bringing this import<br>
up.<br>
<br>
One question that is looming large in my mind is the question of<br>
timeframe, and feedback, since there is a lot of "will" language in<br>
the wiki.<br>
<br>
How much time will you give us for participatory feedback?<br>
<br>
Now onto some questions.<br>
<br>
The license for this data is "interesting"- in that it has a lot of<br>
terms in it which I don't understand, because I suspect they have a<br>
different meaning in legalease than they do in plain English.<br>
<br>
Has the LWG seen this license?<br>
<div class="im"><br>
> This import does NOT include comprehensive address points, which is not<br>
> currently available as an easily imported dataset.<br>
<br>
</div>This question of the value of building outlines without their<br>
corresponding addresses comes up very often.<br>
<br>
Building traces are very high in terms of data density, but without<br>
something like an address, they can be very noisy with little benefit.<br>
Is there a plan to get addresses, or at least address interpolation<br>
data, to go alone with the high density data?<br>
<div class="im"><br>
> The city also as has a land use polygon dataset (among others) that I'll use<br>
> to update existing shapes once this import has been approved.<br>
<br>
</div>We've discussed landuse, especially in California, and found it to be<br>
of very low quality. There seems to be a growing consensus in this<br>
group that landuse isn't that valuable in general. I'm still somewhat<br>
neutral on this topic, but I'm increasingly persuaded not only by the<br>
arguments that have been presented, but by the compelling evidence<br>
that landuse imports have been especially bad in the US.<br>
<br>
On the OSM file, I echo Jason's sentiments.<br>
<br>
The overlapping buildings is really confusing to me. I don't<br>
understand what that is- can you explain it?<br>
<br>
As Paul Norman and others have pointed out in the past, including a<br>
source_id on an object does not really help- so it's not generally<br>
encouraged (and I'd argue for its removal). Source tags on objects,<br>
too, is generally not needed, as we can get that same information from<br>
the changeset.<br>
<br>
My other question is regarding your conflation process and the future.<br>
<br>
Your github contains the output file, but is it possible for you to<br>
share how you derived at that data?<br>
<br>
Also, I'm thinking about in a few years, if the city has a new<br>
dataset, how it would be possible to conflate the datasets between<br>
what is in OSM and what's in the new dataset, both adding new<br>
building, and removing buildings which have been deleted from the new<br>
dataset, or even buildings which were removed from OSM but still<br>
appear in the city data?<br>
<br>
Some of this will need to be handled by manual review, but the<br>
question is- based on working with this data, do you have any thoughts<br>
to share about it?<br>
<span class="HOEnZb"><font color="#888888"><br>
- Serge<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>John Novak<br>585-OLD-TOPOS (585-653-8676)</div><div><a href="http://www.linkedin.com/in/johnanovak/" style="color:rgb(17,85,204);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)" target="_blank">http://www.linkedin.com/in/johnanovak/</a></div>
<div>OSM ID:oldtopos</div><div>OSM Heat Map: <span><a href="http://yosmhm.neis-one.org/?oldtopos" target="_blank">http://yosmhm.neis-one.org/?oldtopos</a></span></div><div>OSM Edit Stats:<a href="http://hdyc.neis-one.org/?oldtopos" target="_blank">http://hdyc.neis-one.org/?oldtopos</a></div>

</div>