in reply to Monks' Maps!

Latitude and Longitude could be exclusionary to those that don't want to be zeroed in on.

If the field format is agreed upon, and it is flexible, we are in business

I propose this: 3-letter country code, 2 letter state code, and 5 digit zip). That way, the field can be broken down by varying degrees, and people can input the level of detail that they are comfortable with.

E.g. USAMA02126

This lacks flexibility (very United.S(c)entric, though, b/c I am unsure how state and zip codes would apply to the rest of the world.

Update: I agree that Longitude/Latitude seem like a much better idea as long as the trailing zeros are an option.

-OzzyOsbourne

Replies are listed 'Best First'.
(jcwren) RE: (2) Monks' Maps!
by jcwren (Prior) on Oct 16, 2000 at 21:28 UTC
    I disagree.

    Latitude and longitude are absolute, lend themselves to easy super-imposition upon a map (coordinate conversion is trivial), and degree of accuracy is controlled by the user. If you want to be a little hazy about where you are, don't provide the significant digits.

    For the record, I have a fair amount of experience with this, dealing with moving map displays and GPS based tracking systems under APRS. Attempting to implement a system such as you're describing makes it quite a nuisance, and is too U.S.-centric.

    Not to mention, my ZipCode is 2 years old, and *still* isn't in half the ZipCode-to-whatever converters. Nextel tried to tell me I don't exist, based on my ZipCode. I had to use a nearby one so they could process my order.

    --Chris

    e-mail jcwren
[reply]
      Nextel tried to tell me I don't exist, based on my ZipCode. I had to use a nearby one so they could process my order.

      <Peter Pan>
      (claps hands) I believe! I believe in jcwren!
      </Peter Pan>

[reply]
RE: RE: Monks' Maps!
by Fastolfe (Vicar) on Oct 17, 2000 at 01:14 UTC
    You don't have to provide precise longitude/latitude information. Replace digits with zeros for the level of ambiguity you want. When building maps with this information, assume all trailing zero digits are meant to be ambiguous, and plot something in the vicinity, perhaps a circle around the area.
[reply]
      Perhaps the aquisitions interface can provide a lower-left and upper-right (or vice versa) bounds, so you can be in an arbitrary rectangle of your own resolution.

      -- Randal L. Schwartz, Perl hacker

[reply]
        We discussed this slightly in the Chatterbox.. These are a few options that would permit position ambiguity:
        1. Use trailing zeros in the latitude/longitude to represent the degree of ambiguity. While most efficient as far as storing data, this is inaccurate where people actually live at a longitude/latitude that ends in one or more zeros. A workaround would be to put a 1 at the end of the number to force it to be interpreted as a literal precise position. Since we aren't anal about expressing this information in the most efficient method possible, one of the options below is probably more desirable, and less of a "hack".
        2. Use latitude/longitude, with a "degree of precision" field, either expressed in a radius form (say, I'm within 15 miles of this location), or representing the number of significant digits in the latitude/longitude.
        3. Use latitude/longitude for those that want to be precise, but make an alternate method available for those that don't. Things such as grid square references are standard ways of referring to manageable areas of land that still provide enough information to tell what city (or what area of a city) a person lives in.
        4. Use an ambiguous method to deal with everyone's position. This would be simplest/most efficient, but would prevent anyone from specifying a precise location. A simple text field for a grid square reference would be adequate.
        There are also other means of identifying location, such as area codes, zip codes, city names, etc.
[reply]

In Section Perl Monks Discussion