Re: Interest in data-type class for location / address?

I have had similar problems defining "address" structures in the past, specifically challenges like Philippe suggested with "international" addresses (being in the US myself). I have also used the USPS web services as previously mentioned for address verification and zip code related lookups. Not to divert, but the "street address" is not the only piece of the structure that is diverse. You're going to run into the same challenges with zip codes and postal codes, states and provinces, whether or not to include couontry information or not, etc, etc. As for "street address" clarity, I do think the structure presented by the USPS in their web services is reasonable. They use AddressLine1 and AddressLine2, and an optional "FirmName". Disregarding "FirmName" for now, AddressLine1 (or with PEAR formatting: addressLine1) may be generic enough to cover anything. Much like addressLine2 works well for "secondary units." As we are still talking about "addresses" and "line" may generic enough to simply mean information, and still represents the overall structure of an address. On 7/31/08, Philippe Jausions <pear@11abacus.com> wrote: > Brett Bieber wrote: > > On Thu, Jul 31, 2008 at 12:03 PM, Philippe Jausions <pear@11abacus.com> > wrote: > >> > >> I'm looking for input for a package that would deal with locations and > >> addresses in a generic manner for PEAR packages. The idea would be to > >> have an interface (and class reference implementation) to handle > >> location-related data such as street address, country, region code, post > >> office box, poste restante status and so on. > >> > >> Since this kind of data is rather used often, wouldn't it make sense to > >> have a dedicated package for it? > >> > >> For my own usage, I've already started putting something together, and > >> you can review it here: > http://pear.11abacus.com/package/Structures_Location > > > > My only request would be a little more abstract thinking about the > > term 'Location' - in some instances this may not always refer to a > > location you can ship a package or mail a letter to. > > Indeed, at first I had 2 interfaces Structures_LocationInterface and > Structures_Location_PostalAddressInterface (which extended the former). > But I decided to lump them together for simplicity sake. > > I agree that location doesn't equate mailing address, just like city of > residence (A) doesn't necessarily equate the city of the post office (B) > making mail delivery for city (A). They are often the same though. > > > For example, a location may be simply - a greenspace/park, the park > > fountain, the apex of a mountain, a geo-cache etc. I see that you have > > getGeodetic etc, but also getStreetAddress etc. I would suggest some > > restructuring to handle some of these details in separate classes. > > "Street address" is used loosely. Some countries don't even use street > addresses per-se to deliver mail, or as you pointed out the location may > not be on a street, or even on land (offshore oil rig for instance.) > That being said, I think that "streetAddress" would be more easily > understood than locationReference for instance. I'm opened to suggestion > though. getLocationName()? getPrimaryLocator()? > > How about the secondary unit, as in apartment, building, floor, etc > numbers. > > Would it be a big issue if you had to put "ABC Park" in streetAddress > and "John Q. Auditorium" as "secondary unit"? I don't think we should > make too much distinction between a street address and a non-street > location, it might clutter the interfaces. I went with "streetAddress" > as it's very common term. > > > class JohnDoeAddress implements Shippable, StreetAddress, > PersonalResidence > > class GreenSpace implements SpatialData, LatitudeLongitude > > The question is how far should this be detailed for a PEAR package, and > how much should be left to the application? For example a Shippable > location may not actually be acceptable for UPS (or other similar > carriers) if it's a PO Box, but it would be perfectly fine for regular > mail delivery. > > > --- this represents some short sighted thinking about the issue, but I > > think this should be considered before assuming any location has a > > street address. > > Hence the call for input ;-) > > -Philippe > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >