mkmurray wrote:The geocoding done by this new solution will require much manual correction for our ward, as everything clumps along the streets and both mapping providers (Microsoft and Google) don't have the latest streets nor satellite imagery of our community. I don't think this means my addresses are deficient, but just that they prove difficult to geocode with the proximity of all the housing and the missing street data.
Geocoding coverage does vary across localities even within the same geocoding engine and database. And, as Mikerowaved noted, the style of addresses used in the Wasatch Front seems to be problematical.
I am pleased to report that for my ward in Austin, most of the geocoding looks pretty good, at least along the linear dimension. (As it is on Google Maps and Google Earth.) Google's provider for my area apparently supplies parcel-level geocoding records, which are about as good as it gets.
I do wish the geocoding settings in LDSmaps provided a modest setback from the street centerline. I prefer that setting because it clearly shows which side of the street an address is on. This is more than cosmetically significant when doing GIS-based boundary work, because street centerlines are frequently used as unit boundaries. My city's public-domain address geocoding does use such an offset for most addresses. I think this is preferable to pseudo-rooftop coding, which is really parcel centroid coding. The ideal for single-family lots, I think, is to use the parcel frontage to locate the address along the street, and a modest setback. That way you get precision and retain a point useful for automated driving directions.