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

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