Subject: Geopolitical vs. geospatial location definition

From: Scott Keagy <[email-masked]>
Date: Wed, 03 Jul 2002 16:28:21 -0700

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        [email-masked]
>----------------------------------------------

Regards,

Scott Keagy, CCIE# 3985
Product Manager, Enterprise Voice and Video Business Unit
Cisco Systems, Inc.
tel:+1-408-902-3902
mailto:[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 04 Jul 2002 04:03:19 -0400

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:
> 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:
> (Ignore the parts that don't refer to street addresses and 
> bldg/room/floor location description).
> 
> 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.
> 
> 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.
> 
> 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
>