Geopolitical vs. geospatial location definition

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 Wed Jul 3 19:29:02 2002