[Geopriv] 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-

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 8 Sep 2006 14:10:19 -0400