headers
Andrew Daviel | 2 Jul 2003 05:23

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

On Fri, 20 Jun 2003, John Schnizlein wrote:

> Thank you for the probing questions. Clarification embedded in context:
>
> At 08:38 AM 6/20/2003, Robert Elz wrote:
> >The definitions of altitude in that draft need work.
> >
> >Metres (positive and negative) is simple enough, but relative to
> >what?   Unless I missed it, I could find no definition of what is 0.
>
> Zero is defined by the datum, at least for those we know.
> To cover any cases where it is not, we propose clarifying text as follows:
>    If MU = 1, an AltRes value 0 would indicate unknown altitude.
>    The most precise Altitude would have an AltRes value of 30.
>    Unless otherwise defined by datum, a value of 0 is with respect
>    to mean-low-tide.
>
> >If the assumption is that it is to be "mean sea level" then which sea?
> >If it is to be above (+ or - below) ground level, which ground level
> >within the designated area given by the latitude and longitude (sloping
> >ground).
>
> It is our understanding that mean low tide is well defined, since
> political and personal land-ownership boundaries are based on it.

It depends on the jurisdiction. For instance, it is different in Canada
and the US - one uses mean lower low water and the other uses lowest
normal tide or something as a nautical chart datum.

Defining elevation seems to be more problematic than defining position.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Linsner | 2 Jul 2003 17:04
Picon
Favicon

RE: Fwd: Working Group Last Call: Location Configuration Information for GEOPRIV

Andrew, thank you, this is good information.  To be sure we all
understand each other, please see comments below.  Remember, this
mechanism we are proposing will be most useful for wired network
connections, the easiest type of device to locate (and currently the
largest type of connection used within an enterprise).  Wireless devices
will have to employ a more exotic mechanism possibly at layer 1 or 2 for
a more precise device location.

> It depends on the jurisdiction. For instance, it is different in
Canada
> and the US - one uses mean lower low water and the other uses lowest
> normal tide or something as a nautical chart datum.

For those who are struggling with this, it is not our intention to
(re)define zero altitude.  We are simply attempting to provide a
mechanism for people who understand altitude values to share them
amongst each other via a standardized mechanism.  If one were to receive
such data, it is assumed that they will understand the definition of
zero altitude within the jurisdiction/authority from which the data
originated.  Some map datum define zero altitude, some don't.  For those
that don't, we define mean low tide.

> 
> Defining elevation seems to be more problematic than defining
position.
> If consumer-grade GPS has a horizontal resolution between 5-30 metres,
> that's good enough to give a street or maybe a room in a building. But
the
> vertical resolution may be double that, and that's 3 floors at best,
even
(Continue reading)

Permalink | Reply | 0 comments |
headers
Abbott, Nadine B. | 2 Jul 2003 19:42
Favicon

RE: Working Group Last Call: Location Configuration Info rmation for GEOPRIV

Marc,

FYI and Question:

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;
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Schnizlein | 2 Jul 2003 20:51
Picon
Favicon

RE: Working Group Last Call: Location Configuration Info rmation for GEOPRIV

At 01:42 PM 7/2/2003, Abbott, Nadine B. wrote:

>FYI and Question:
>
>For wireless 9-1-1 calls, the geodetic location is provided from the
>wireless carriers in a binary coded form over SS7 ...

For the same reasons that 2's complement binary is preferred
over binary-coded decimal in computing systems, I prefer it
for the DHCP option. It is worth remembering that the location
option is likely just one of many that have to fit in the
UDP-based DHC protocol. The efficiency of binary numbers fits
the principle of frugality with lightweight protocols.

Having the carrier provide location over its signaling system
is a little different from the model of connected computers.
In the wired-computer mechanism we envision, the edge network 
tells the computer where the wire it plugged into is so that 
it can decide who/what/when/where/how to share this information.

>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.  

The host can use its location information for anything at all, including
emergency calls. We did not design the format to fit the model of SS7.
(Continue reading)

Permalink | Reply | 0 comments |
headers
James M. Polk | 2 Jul 2003 22:13
Picon
Favicon

New ID on Location Information Considerations

Jorge and I have written an Internet Draft addressing the Location 
Information that will/should/might be conveyed within a Geopriv Location 
Object (LO). This document is to start referencable discussions on what can 
be included (regarding the Geopriv Target) in the LO.

This effort is more or less independent from the privacy and security 
efforts that are the primary focus of this WG, but we feel these 
discussions should take place among those of us interested in such aspects 
of Geopriv

The following is the abstract:

Abstract

    This document describes the Geopriv Location Data Fields of the
    Location Object that MUST be present under what conditions, which
    fields SHOULD be present, and which MAY be present.  This document
    does not address the privacy and security requirements of the
    GEOPRIV Protocol or the privacy and security requirements of the
    GEOPRIV LO Using Protocol.

http://www.ietf.org/internet-drafts/draft-polk-geopriv-location-data-00.txt

comments are encouraged

cheers,
James

                                *******************
                    The answer is "42", what's the question?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Internet-Drafts | 2 Jul 2003 22:15
Picon
Favicon

I-D ACTION:draft-ietf-geopriv-dhcp-civil-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.

	Title		: DHCP Option for Civil Location
	Author(s)	: H. Schulzrinne
	Filename	: draft-ietf-geopriv-dhcp-civil-00.txt
	Pages		: 8
	Date		: 2003-7-2
	
This document specifies a Dynamic Host Configuration Protocol option
for the civil (country, street and community) location of the client.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-geopriv-dhcp-civil-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Morris | 2 Jul 2003 23:23

Re: New ID on Location Information Considerations

Also, FYI, Jorge, Deirdre, and I have submitted an updated version of 
a related I-D:

http://www.ietf.org/internet-drafts/draft-morris-geopriv-core-02.txt

This discusses proposed privacy related elements for the Location 
Object.  There are two main revisions from the prior draft:

  - the proposed ability to be able to set privacy rules for specific 
individuals (instead of specific credential holders) has been 
eliminated, in response to concerns that Henning and others raised.

  - the distinction between "machine-to-machine" and "human readable" 
rules has been rephrased, to make clear that some rules will only go 
between Location Servers, but other rules may be distributed more 
broadly, including possibly to end users.

One point that has not changed but raised some concern on the list is 
the proposal that one can make a privacy rule applicable to a 
specific or repeating time window.  The point was made that this can 
be very challenging to express, but others suggested ways that it 
might be accomplished.  So this time window issue is still an open 
question.

John

At 3:13 PM -0500 7/2/03, James M. Polk wrote:
>Jorge and I have written an Internet Draft addressing the Location 
>Information that will/should/might be conveyed within a Geopriv 
>Location Object (LO). This document is to start referencable
(Continue reading)

Permalink | Reply | 0 comments |
headers
creediii | 3 Jul 2003 02:22
Picon

Re: question about GML 3.0

Jon -

The following feedback from two GML guru's from Galdos. Hope this is of use.

Cheers

Carl

Comments  by David Burggraf (Galdos) on:
---------------------------------------
2.2.1 'location-info' element
"...In order to ensure interoperability of GEOPRIV implementations, it is
necessary to select a baseline location format that all compliant
implementations support (see REQ 3.1). At this time, there is not sufficient
working group consensus within the GEOPRIV WG to award this distinction to
any particular location format. Without applying any particular selection
criteria (apart from REQs 2.5.1), this document works from the assumption
that GML 3.0[14] will be this mandatory format (MUST implement for all PIDF
implementations supporting the 'geopriv' element).

The Geography Markup Language (GML) is an extraordinarily thorough and
versatile system for modeling all manner of geographic topologies and
objects. The simplest package for GML supporting location information is the
'feature.xsd' schema. Various format descriptions (including
latitude/longitude based location information) is supported by Feature (see
section 7.4.1.4 of [14] for examples). This resides here:

urn:opengis:specification:gml:schema-xsd:feature:v3.0
</xs:schema>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Linsner | 3 Jul 2003 02:25
Picon
Favicon

RE: 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,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henning Schulzrinne | 3 Jul 2003 03:22

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

Marc Linsner wrote:

> For those who are struggling with this, it is not our intention to
> (re)define zero altitude.  We are simply attempting to provide a
> mechanism for people who understand altitude values to share them
> amongst each other via a standardized mechanism.  If one were to receive
> such data, it is assumed that they will understand the definition of
> zero altitude within the jurisdiction/authority from which the data
> originated.  Some map datum define zero altitude, some don't.  For those
> that don't, we define mean low tide.

Like the datum, what's wrong with providing an indication of the unit of 
the measurement?

I think it is generally a bad idea to assume that all parties along a 
chain of transmission know what the data meant initially. This only adds 
a modest number of bits to the format, given that the number of choices 
appears to be on the order of two.
Permalink | Reply | 0 comments |

Gmane