[Geopriv] RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy?

Marc,

I would like you and James to get your arguments in synch and come back
with a cohesive, uncontradictory response to the concerns that are being
raised here.

You say " is NOT a mechanism for expressing polygons" and have said
before that you see it as a mechanisms for expressing single points
only.

James said " RFC3825 has resolution as part of its solution. This
creates a GML defined Linear Ring.."

These are in direct conflict.
The moment you use the resolution bits to describe a linear ring, you
are specifying a polygon, which by its very definition defines the area
of uncertainty for the host. The coding mechanism described in RFC-3825
for doing this introduces the problems that we have described.

So, either it is a point, in which case the resolution for the most part
should be ignored and a Biz to RFC-3825 is required to say this. Or, it
is an area which is described by the resolution bits, in which case you
need to find a way to eliminate the problems described or accept that it
should not be used in emergency applications.

I am only interested in location representation, and so far I see
conflict amongst the authors of that RFC with regards to what RFC-3825
represents and I see confusion over how the authors are interpreting the
terms uncertainty and confidence with regards to their usage in the
expression to areas.

Cheers
James

> -----Original Message-----
> From: Marc Linsner [mailto:mlinsner@cisco.com]
> Sent: Saturday, 9 September 2006 4:10 AM
> To: 'Clive D.W. Feather'; Winterbottom, James
> Cc: ecrit@ietf.org; geopriv@ietf.org
> Subject: RE: [Ecrit] Location information in emergency
> sessioninitiation,need for time and accuracy?
>
> Could someone please identify any/all application(s) where geo
coordinates
> are used to describe the location of a fixed (e.g. non-mobile) entity
> where
> uncertainty/polygons are expressed? I've reviewed many
aviation/marine
> charts/data (very pervasive use of geo coordinates) that express geo
> locations for fixed objects and I've yet to find any expressed with
> uncertainty. (I'm 70% confident you'll find a runway at x,y,z)
>
> RFC3825:
>
> - is NOT intended to advise a mobile client of it's location (as
suggested
> in the text, it could possibly convey the location of the access
point)
> - is NOT a mechanism for expressing polygons
> - is capable of conveying a 3 dimensional geo point from one entity to
> another via dhcp
> - is capable of expressing the resolution of the shown value
> - is capable of allowing the creator of the object to express
resolution
> values other than what is actually known
> - is an efficient mechanism for passing geo point location values via
dhcp
>
>
> ...............snip....................
>
>
> >
> > 3825 does not explain in normative text:
> > - that the encoding is twos complement (sign and magnitude would
> > probably
> > be more sensible in this context);
>
> As seen in the quote below, it certainly specifies twos complement.
In
> the
> 1960s problems with this representation were identified and resolved
with
> twos complement representation.
> http://en.wikipedia.org/wiki/Signed_number_representations
>
> "Within the LCI described here, Latitude and Longitude are represented
in
> fixed-point 2s-complement binary degrees, for the economy of a smaller
> option size compared to a string encoding of digits in [7]. The
integer
> parts of these fields are 9 bits long to accommodate +/- 180 degrees.
The
> fractional part is 25 bits long, better than the precision of 7
decimal
> digits. The length of each field is 40 bits, 34 of which is the sum
of
> the
> integer (9) and fractional (25) bits, plus 6 bits of resolution."
>
>
> > - how to construct a rectangle that crosses the Prime Meridian or
the
> > equator;
>
> RFC 3825 is not about representing arbitrary rectangles, but about
> representing a geographic location, with explicit indication of the
> resolution of the point.
>
> > - what is the meaning of a value that is, or includes cases, outside
> > the
> > +/-90 or +/-180 range (the SHOULD be in range rule doesn't cut it,
> > here).
>
> One could extrapolate many meanings from values expressed that are
outside
> the SHOULD of the RFC. One of those meanings may be that the value
> expressed is an error. Or a value outside the specified range could
be an
> alias (wrapping the globe) for a value within the specified ranges.
The
> "SHOULD" allows those who understand the complications to violate this
> specification, but warns of unintended consequences.
>
>
> >
> > It's also a bad encoding because it requires boundaries to be
aligned
> > to units of the same size as the boundary. For example, if I want to
> > define an area 2 degrees high, I have to use boundaries that are
even
> > numbers of degrees; there's no way to encode a square, 2 degrees on
a
> > side, centred on 52N 2W.
> >
> > In fact, the *only* encoding I can do for an area centred on that
> > point is a rectangle 4 degrees east-west and 8 degrees north-south.
> > For *any* point, there's only one rectangle with that point at its
> > centre that can be encoded.
>
> Since there is no arbitrary rectangle specified in RFC 3825, it does
not
> require anything about boundaries of any rectangle.
>
> ..................snip............................
>
> -Marc-

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 8 Sep 2006 16:47:05 -0500