Re: Geopolitical vs. geospatial location definition

There is an additional reason that civic location (I think that's the
term...) are needed - in many cases, such as the location of network
devices in offices, location information will need to be entered by
humans, which are very unlikely to get long/lat right. It is also easier
to provide human-meaningful imprecision in that space. For example,
providing a postal code, city or country is all that's needed for
demographics or other identification purposes, but this doesn't
correspond neatly to any easily-specified boundary in long-lat. This
also avoids some of the need for various randomization and fudging
techniques. Specifying "New York" instead of having to specify random
points within the five boroughs seems much easier for a human to observe
and trust. (How would I know that my device isn't just accidentally
providing random long/lat that (in)conveniently average out to my
precise location?)

Scott Keagy wrote:
> Where do you all see as the most appropriate place to specify a location
> format required to support a specific application? In thinking in
> particular about E9-1-1 support in North America, and the location
> formats specified by the National Emergency Numbers Association in the
> document NENA 02-010:
> http://nena.org/9-1-1TechStandards/Standards_PDF/NENA_02-010.PDF
>
> (Ignore the parts that don't refer to street addresses and
> bldg/room/floor location description).
>
> As another example of emergency location information format (that is
> different because of country-specific methods of describing a street
> address and location) , take a look at the IPND in Australia:
> http://www.telstra.com.au/ipnd/docs/Ipndus1.1.7.pdf
>
> I'm sure the CGALIES folks in Europe will come up with a different
> version for E1-1-2 (which will be more challenging given the number of
> countries and street address formats encompassed there)... not to
> mention every other part of the world that establishes an emergency
> location identification mechanism.
>
> There is a real need for a geopolitical reference for location info,
> rather than just lat/long/alt. Consider that a police officer responding
> an emergency from a university dorm room may have a difficult time using
> the lat/long/alt to find the correct room (even if the accuracy and
> precision is good enough). I suspect there is a general class of
> applications that would like a geopolitical location reference as
> opposed to a geo-spatial location reference. We can call that area out
> of scope for us, and rely on other black boxes to translate lat/long/alt
> to street addresses or other location formats, but this is something
> that I think makes more sense to have built into the geopriv
> architecture with some sort of a distributed authority for format
> specifications. Maybe something as simple as a protocol field to specify
> format type (and make the field big enough to support at least a
> separate format for street addresses in every country in the world), and
> an assignment by IANA of numbers used for format types.
>
> That way, specific applications have a method to explicitly define how
> to morph geo-priv to their specific requirements without needing to
> reinvent the wheel, and other groups can piggy-back on that work when
> they are satisfied with a format that already exists. Also, it allows
> other standards orgs to come up with the most appropriate format for
> their applications, and frees the geopriv group from trying to think of
> the format needs of everybody in the world.
>
> Alternatively, we can hash out a set of XML tags that attempt to be a
> superset of every element in a street address definition across the
> globe, and figure out how to handle conflicting nesting or ordering
> rules between geographies. I think this approach would be extremely
> challenging and in the end not live up to expectations.
>
> Following the points raised by Jorge in the msg below, the different
> GSM/CDMA other specification groups can each have their own territory if
> their is a logical reason to keep these separate and it does not present
> an obstacle to the ubiquitous availability of the intended application.
> In the case of wireless phones however, I suspect that wireless users
> expect that their use of CDMA or GSM should not affect the availability
> of the location info for emergency calls or other location-based
> services (and hence should not require different location format types).
>
> Regards,
> Scott
>
> At 08:10 AM 6/26/2002 +0200, Cuellar Jorge wrote:
>
>> In Section 4.2 there is a short list of groups that may have
>> defined certain formats for location information. Although
>> the list is not meant to be all-inclusive, and it is just a
>> suggestion, the problem is that in appearance favors one
>> wireless specification group (3GPP) over another (3GPP2),
>> and implicitly one wireless technology (GSM) over another
>> (CDMA). That wasn't the intent. The sentence should be
>> supplemented by inclusion of 3GPP2. (Any further suggestion
>> for this list, as well as any comment to the draft is also
>> welcome.)
>>
>> Regards,
>>
>> Jorge
>>
>> --------------------------------------------
>> Dr. Jorge R Cuellar T +49 89 636-47 585
>> Security
>> CT IC 3
>> Siemens jorge.cuellar@mchp.siemens.de
>> ----------------------------------------------
>
>
>
> Regards,
>
> Scott Keagy, CCIE# 3985
> Product Manager, Enterprise Voice and Video Business Unit
> Cisco Systems, Inc.
> tel:+1-408-902-3902
> mailto:skeagy@cisco.com
Received on Thu Jul 4 04:08:44 2002