RE: [dhcwg] Working Group Last Call: Location Configuration Information for GEOPRIV

Yes, we did look at the T1.628 geo-loc format. As John Schnizlein
already stated, we found it to be inefficient in many respects. We also
discussed other uses of our newly described format and decided it needed
to be able to define a higher resolution than what is allowed by T1.628.

The new format: better than 7 decimal places of degrees of resolution;
ability to identify floors of a building (something that is impossible
for a PSAP to accomplish with a simple altitude value); ability to state
the resolution (accuracy) of the location value from 1/6 of the globe to
~3mm. All this in only 16 bytes!

The bottom line: The application at the PSAP will need to be able to
interpret the new format. Interpretation of this format should be
relatively easy for today's class of cpus. At this point, looking at
the length of the data object should be a good clue for a GIS
application programmer to decide which format they're dealing with. Or,
a few short subroutines to run against the object will be able to decide
in a short time the format. I don't foresee the need to do any
conversion outside of the PSAP GIS mapping software. If a network
routing node needs to perform a lookup based on the new format,
conversion to the needed format for lookup will be easy at that point
also or by the lookup service provider. After all, MS Word can
understand text, word, html, rtf, etc. docs; a $50K GIS package should
be able to handle a couple of different data formats.

-Marc Linsner-

 
> For wireless 9-1-1 calls, the geodetic location is provided from the
> wireless carriers in a binary coded form over SS7 (ISUP or TCAP/E2,
> carried
> in Calling Geodetic Location parameter; see ANSI T1.628-2000 for the
> coding
> of the CGL--similar, but not the same as the DHCP-LO). The location
> information is processed by an E9-1-1 Database for delivery to Public
> Safety
> Answering Points (PSAPs).
> The geodetic location information that is provided to 9-1-1 Public
Safety
> Answering Points via queries to these E9-1-1 DBs uses the following
NENA
> formats:
>
> Longitude:
> 11 bytes; Numeric;
> Longitude/X coordinate. Right Justified; pad field with zeros to left
of
> decimal degrees. +long: east of Greenwich; -long: west of Greenwich.
(Can
> be used
> for wireline as well as wireless) Sample: +000.######
>
> Latitude
> 10 bytes; Numeric;
> Latitude/Y coordinate. Right Justified; pad field with zeros to left
of
> decimal
> degrees. +lat: north of equator; -lat: south of equator. (Can be used
for
> wireline as well as wireless) Sample: +00.######
>
> Elevation
> 5 bytes; Numeric;
> Elevation/Altitude indicated as height above mean sea level, measured
in
> meters (Can be used for wireline) Sample: #####
>
> Datum
> 2 bytes; alphanumeric;
> Specifies the map projection and coordinate system recommended for the
> display of the Longitude and Latitude coordinates. Two systems are
> commonly used for North America. The code 83 identifies North American
> Datum for 1983 (NAD83). Code 84 identifies the World Geodetic System
> for 1984 (WGS84). Other codes may be added as additional datum become
> available through authorized entities.
> Where x =
> 83 = NAD83
> 84 = WGS84
>
>
************************************************************************
**
> **
> ***********
>
>
> For a 9-1-1 call, if IP devices are populated with coordinate
information
> in
> a different format from that expected by PSAP mapping applications,
then
> somewhere between caller and PSAP, the geodetic location information
> provided by the DHCP location object procedures will need to be put
into a
> format that can be processed by PSAP applications. If you assume that
the
> location object information is routed via the E9-1-1 DBs, perhaps the
> conversion could be performed there. If you envision that geodetic
> location
> is carried with the call establishment signaling, where do you assume
that
> the conversion between the DHCP-LO format and the formats expected by
PSAP
> applications will take place?
>
> Thanks,
> Nadine Abbott
> Telcordia Technologies
>
Received on Wed Jul 2 20:39:07 2003