The structured data isn't intended for normalization; it's intended to tell you what
we know about the matching address that we found in our database. Our data does not
include unit information, so we're not going to return that in the structured data. 

But it's clear your parser recognizes it as unit information, and this is a feature
request, not a bug request. It seems very bad that the returned data should just
throw away this piece of input entirely; there should at least be an element that
contains that portion of the input that that is clearly being parsed out.

Would it make sense then to change this feature request to return a structure that
represents the parsed address? (As opposed to the result address?)

Yes, that would actually be perfect (and more than I was hoping for) :-)

Well, both are feature requests, but I think that'd make more sense given the meaning
of our current returned structure.

Changing and filing. Thanks for discussing with me.

Pamela asked: "Would it make sense then to change this feature request to return a 
structure that represents the parsed address? (As opposed to the result address?)"

I'd suggest "in addition to" instead of "as opposed to". Add the parsed structure 
but don't change existing behaviour with placemark "p1" etc.

That probably means that the parsed structure should either be the LAST placemark, 
with a suitable id value; or it shouldn't be a placemark at all and some other KML 
element is needed. I don't know what's available in KML. I'm just concerned not to 
break anything that depends on the existing result structure when accommodating an 
enhancement request.

Andrew

Just a note about normalizing addresses: if it's for a shipping address, be careful.
 In general, you should use shipping addresses as specified, not normalize them.

For example, I include both a street address (for Fedex) and a PO box (for USPS) in
my mailing address.  Normalizing will inevitably remove the PO box.  (9-digit ZIP
codes don't help here, I've had mail held doing that--postal workers with poor
eyesight, I think.)  Also, my street address is of the form "123 N 62nd St.", and the
"N" is important (N and S aren't connected), but the map doesn't know that and
geocoding only returns "123 62nd St."

This is tangental but probably important to some people reading this; I've had too
many mail delivery problems due to shippers who think they know better than I do what
my mailing address is.

Changing status of "Accepted" issues to "Acknowledged", to clarify their 
state.

We may not be able to resolve all bugs or fulfill all feature requests, but 
we do thank you for filing them, and we will continually revisit all 
acknowledged issues and evaluate their feasibility. Thanks!