<div><div>As I've been out of touch here is a sort of omnibus reply to the last couple of days worth of discussion on SF Addresses.   Thanks for all the ideas and help.<br> </div><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
<div>I would say this is one of the easy imports, there is not too much 
harm it can create. only problem is to merge it with existing data and 
make a decision which one is better. Since this data is probably 
authoritative it might be ok to replace most of the less accurate data 
already in OSM.</div><div>For this reason I would drop any of the nodes in case of a conflict
 but rename the tags to something else like sf_addrimport_addr:*</div><div>a
 survey on the road can check them later and compare with the existing 
addr nodes and decide which one to keep and rename the import tags to 
the real tags</div></blockquote>
<br> I don't think that the data currently in OSM is less accurate than that of the import.  The address data currently in OSM in SF is either on a node for something else like a restaurant or shop or its one of the very few standalone address nodes that have been entered.  <br>
<br>I think that having the data attached to a business is much more valuable than it is alone and don't intend to over write any of that.  <br><br>There are only a couple of little areas comprising maybe half a dozen blocks that have standalone address nodes.  The data thats in there looks like it has been carefully entered and I don't doubt its accuracy especially because I've met one of the mappers that did some of it and she knows what shes doing.  <br>
<br>As such I don't really think its worth having a fall back sf_addrimport_addr: tag for conflicting nodes and would rather just drop the ones from the dataset I'm importing if they conflict.  I definitely will though if anything I come across in the data makes me think it would be worthwhile.<br>
<br></div><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">Do spot-check different neighborhoods. In reviewing the San Bernardino 
County assessor's shapefile, I found that housenumbers, ZIP codes, and 
even street names were missing/wrong in some areas I spot-checked. The 
county's response was that this data was of secondary importance to the 
assessor, understandably - as long as they have all the parcels, and the
 billing address for them, the actual postal address of the parcel is 
not critical info.<br></blockquote><br><div class="gmail_quote">I will spot check different neighborhoods to make sure that they're of equal quality to the blocks I've checked which have mostly been ones local to where I live and work.<br>
<br>I've found no reason to think that any of the data is billing addresses for the parcel instead of the mailing address of the parcel.  I'll keep an eye out for it though.<br><br>As to zip codes I don't plan on putting any in because I haven't found a source for them that I feel would work.<br>
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">As for a demo of the data, yeah, an OSM file would be perfect. Also,<br>
though, I'd keep the previous dataset ID, in case you need to do a<br>
comparison later.<br></blockquote><div><br>I will definitely post an OSM file once I have something a bit closer to being import ready. <br><br>As to the previous dataset ID, in this case the ObjectID, I'm not particularly opposed to keeping it I'm just not sure what we'd gain in this instance and I know there are people who object to having lots of third party IDs in our database.<br>
<br>In this particular instance I think comparisons between OSM and any future SFAddress files can be done equally as well using the addr:housenumber/addr:street combo which should, ideally,  be unique.  As we'll have a fair number of nodes that aren't imported because the address is already "taken" by a business or otherwise already in OSM we'd have to resort to using that sort of matching system anyhow. <br>
</div><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">I don't agree that the other info can be easily, or accurately, derived.
 Addresses near the borders of those polygons are often subject to 
seemingly-arbitrary decisions. The physical location of the centroid of a
 parcel may not be within the same ZIP, city, and/or county polygons as 
their address. I would include the city and ZIP code.<br></blockquote><div><br>Make sense.  I will include the city but as stated above I don't have the ZIPs. <br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
Just wanna say that addressing in SF would be awesome :-)</blockquote><div><br>The goal is to make it so that SF is fully routable.  As we have good (not perfect, but really good)street geometry, junctions, classifications (eg, primary, residential, etc), oneways and names the main things we're lacking are addresses and turn restrictions.  Hopefully we'll get addresses from this import.  As there doesn't seem to be any source for the turn restriction data I've put up a <a href="http://wiki.openstreetmap.org/wiki/San_Francisco_Turn_Restrictions">page on the wiki</a> to help coordinate efforts to map them and put a little dent in it myself to start.  Hopefully some more people join in.  I think getting these two things done will put OSM at a pretty competitive level with any of the commercial data providers with respect to SF.<br>
<br></div></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Hopefully this is helpful, as you'll want to import street names that actually match those in OSM's view of San Francisco.<br></blockquote><div><br>It is helpful, thank you, especially being able to see where many of the differences are.<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;">
<br>
I found some other weird burrs in the data as well, in terms of how it arranges addresses stacked on top of one another in tall buildings. Nothing that can't be dealt with in an import.<br>
<br></blockquote><div><br>If those stacks are actual addresses in use at that location I was planning on leaving them that way.   Do you have other thoughts on how to handle them?  I know in some instances that they're probably not actually stacked, eg, they're for different businesses that have locations along the front of the building but I'm not sure how to deal with that.  In some cases, especially multi-family residences the "stack" is correct in that its at the entrance for all of the addresses in the stack.<br>
<br>Thanks,<br>Gregory Arenius<br> <br></div><br></div>