<div class="gmail_quote">On Thu, Dec 9, 2010 at 8:06 PM, Gregory Arenius <span dir="ltr"><<a href="mailto:gregory@arenius.com">gregory@arenius.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div class="im"><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>A few comments...<br>
<br>1) San Francisco explicitly says they do not have building outline data. :( So, I suppose we get to add buildings ourselves. I do see that SF does have parcels. <br>
<br>
For DC, we are attaching addresses to buildings when there is a one-to-one relation between them. When there are multiple address nodes for a single building, then we keep them as nodes. In vast majority of cases, we do not have apartment numbers but in some cases we have things like 1120a, 1120b, 1120c that can be imported. Obviously, without a buildings dataset, our approach won't quite apply for SF.<br>
</div></div></blockquote><br></div><div><br>We mostly only have building shapes drawn in downtown where its unlikely there will be many one-to-one matches. I wish we did have a building shape file though, that would be great. I have thought about using the parcel data but I'm not sure thats as useful. <br>
</div></div></blockquote><div><br>Agree, not sure how useful parcels are for us.<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div>
<br></div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>
<br>2) I don't consider the addresses as noise. The data is very helpful for geocoding. If the renderer does a sloppy job making noise out of addresses, the renderings should be improved. <br></div></div></blockquote>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div><br>3) Having looked at the data catalogue page, I do have concerns about the terms of use and think it's best to get SF to explicitly agree to allow OSM to use the data.<br>
<br><a href="http://gispub02.sfgov.org/website/sfshare/index2.asp" target="_blank">http://gispub02.sfgov.org/website/sfshare/index2.asp</a><br></div></div></blockquote></div><div> <br>What terms in particular caused you concern? I'll need to know if I'm going to ask for explicit permission. A while back I posted the previous terms to talk legal and they pointed out problems. The city changed the license when I pointed out that it cause problems for open project (apparently that was in the works anyway). I thought those problems were removed. I had a conference call with one of the <a href="http://datasf.org" target="_blank">datasf.org</a> people the helps make city datasets available and an assistant city attorney prior to those changes and I was told that unless specifically noted otherwise in the dataset that the data was public domain. I do understand that that isn't in writing though.<br>
<br>If there is a problem with the terms though there is still a good chance the city would give us explicit permission to use the data; they seemed excited about the prospect of some of it ending up in OSM.<br></div></div>
</blockquote><div><br>I don't know enough to assess but concerned about the "click" to agree. Also concerned about the possibility of switching to ODBL and contributor terms and want to make sure the data would be compatible with those. I think it helps to have explicit permission (e.g. e-mail) for use in OSM (agree that we can use dual-licensed under CC-BY-SA and ODBL) on file.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div></div><div class="im"><div>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>4) If you can get explicit permission, then I suggest breaking up the address nodes into smaller chunks (e.g. by census block group), convert them to osm format with Ian's shp-to-osm tool, and check them for quality and against existing OSM data (e.g. existing pois w/ addresses) in JOSM before importing. QGIS and/or PostGIS can be useful for chopping up the data into geographic chunks. This approach gives opportunity to apply due diligence, to check things, and keep chunks small enough that it's reasonably possible to deal with any mistakes or glitches.<br>
</div></div></blockquote></div><div><br>I had been planning on using shp-to-osm to break it in to chunks by number of nodes but doing it geographically makes more sense. Do you think census block size is best or maybe by neighborhood or aim for an approximate number of nodes in each geographic chunk?<br>
</div></div></blockquote><div><br>With buildings, our data was a bit denser. I did some by census tract and found some were too big for the OSM API and JOSM whereas census block group has worked well. With just nodes, I think you could do somewhat larger chunks.<br>
<br>Cheers,<br>Katie<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>
<br>Cheers,<br>Gregory Arenius<br></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Katie Filbert<br><a href="mailto:filbertk@gmail.com">filbertk@gmail.com</a><br>@filbertkm<br>