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

Im not sure where this fits into the discussion (or how well this message will get sent on this bad network) but I have had a slew of problems with internationalization with both addresses/locations and currencies. Is there a PEAR package for managing multiple currencies? My current tactic I've been using to avoid major problems is to take operations that yield a value of currency ($100 USD or $100 AUS) and combine the like currencies. When I estimate/ship a shipment it's cost can return an array of values keyed by their currency to the sum of values for that currency. Is there any information about countries, regions, cities, or anything available in PEAR? Would a package with such information, if obtained without legal restrictions, be accepted into PEAR? One of the major problems I face right now is not knowing if a shipment will be travelling domestic or international. This seems simple enough, just check the sending country vs the receiving country - but most carriers have more complex rules for this. Here is a long shot, but does anyone know why UPS has about 8 extra pages dedicated to shipments that have to do with Poland? Especially when sending from Poland to Poland! I will take some of the hints from these discussions in my Services_Shipping package(s), which is currently only using US-based shipments, since I have no access to an international XML shipping API with UPS. P.S - My PEAR proposal is more complex than I anticipated. The code has grown to over 3,000 lines and I wanted to ensure I was sumbitted only working code. Should I just submit the code and worry about removing the bad parts later; or be pedantic with the initial proposal? In particular, I'm on the clock and editing this code a lot at work: I can't waste time converting to spaces and back to tabs for my co-workers. This has caused a lot of extra time to prepare my proposal. Cheers, Kristopher Ives On Fri, Aug 1, 2008 at 7:58 AM, Philippe Jausions <pear@11abacus.com> wrote: > Hi Greg, > > Greg Christensen wrote: > > 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 country information or > not, > > etc, etc. > > Yes agreed, ZIP is US-specific so it should not be used as name for > postal codes. Same for state, province, etc.. "region" is more > appropriate globally. > > > 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. > > Firm/company name is really recipient specific, same as person's name > and department within a company. I think it's best left off from a > location-related package. This could be handled by a Structures_Contact > package though. > > I think AddressLine1 and AddressLine2 are confusing because in some > countries the order of information could be reversed for "line 1" and > "line 2". Even for the US it could be confusing, what is "line 1"? Is it > the line with the street name or the one with a Apartment number for > instance? > > If you look at a common mailing label in the US it could look like this: > > John Doe > Apt 1 > 123 Main St > Los Angeles, CA 98765 > > Lines here don't really make sense, because the US Postal Service, would > call "123 Main St" as AddressLine1 and "Apt 1" as AddressLine2. > > The formatting reference guide of the USPS also states that the address > above should actually be formatted: > > John Doe > 123 MAIN ST APT 1 > LOS ANGELES CA 98765 > > But for long addresses it should be: > John Doe > BLDG "A", FL 3, STE 345 > 123 VERY-LONG-WINDING-DEAD-END-NAME ST NW > LOS ANGELES CA 98765 > > One more confusing example? > > John Doe > 123 Main St > PO BOX 876 > LOS ANGELES CA 98765 > > In other countries the address should be written in reverse order with > the most generic location on top: > > Los Angeles CA 98765 > 123 Main St > Apt 1 > John Doe > > So when you're dealing with international addresses line numbers don't > make much sense and could lead to confusion, especially when you're > trying to format the data to print labels... > > -Philippe > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >