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

From: "Marc Linsner" <[email-masked]>
Date: Fri, 8 Sep 2006 14:10:19 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 8 Sep 2006 16:47:05 -0500

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:[email-masked]]
> Sent: Saturday, 9 September 2006 4:10 AM
> To: 'Clive D.W. Feather'; Winterbottom, James
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Ecrit] Location information in emergency
> sessioninitiation,need for time and accuracy?
> 
> As seen in the quote below, it certainly specifies twos complement.
In
> digits.  The length of each field is 40 bits, 34 of which is the sum
of
> ..................snip............................

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

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 8 Sep 2006 18:02:16 -0400

James,

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

Please explain why emergency applications are different from other
applications that describe fixed locations using the geo coordinate system.

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 8 Sep 2006 17:11:05 -0500

Marc,

Perhaps the statement should have been, is not suitable for any
application that require a deterministic degree of accuracy, something
to that effect.
I am quite sure that in some circumstances that the encoding scheme is
fine, but I wouldn't want to be my life on it in an emergency, would
you?

James

> Sent: Saturday, 9 September 2006 8:02 AM
> To: Winterbottom, James

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 8 Sep 2006 18:29:12 -0400

> 
> Marc,
> 
> Perhaps the statement should have been, is not suitable for 
> any application that require a deterministic degree of 
> accuracy, something to that effect.
> I am quite sure that in some circumstances that the encoding 
> scheme is fine, but I wouldn't want to be my life on it in an 
> emergency, would you?

I suggest emergency responders would have no problem finding locations
described by RFC3825, it's the same data expressions used by aviation and
marine everyday.  So, unless you travel exclusively by rail, you've probably
already placed you life in the hands of such data representation, I know I
have.

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 8 Sep 2006 17:52:30 -0500

It is interesting that you point this out and I am certainly no expert
in aviation and marine location systems. I will however point out that
from what I have seen that searches at sea and for downed aircraft often
span many thousands of square kilometres, I scarcely think that this
would be acceptable in a domestic wired or wireless phone emergency
situation.

I would also point out that if you have used the same encoding as is
used in those industries it behoves you to have put them in the
references section of the RFC, and to have indicated that the encoding
scheme came from the there in the text somewhere, I certainly couldn't
find any.

Now back to my initial series of questions:

Point or Polygon, single answer please.
How do you intend to address the concern regarding errors.

Cheers
James

> Sent: Saturday, 9 September 2006 8:29 AM
> To: Winterbottom, James

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 8 Sep 2006 19:41:55 -0400

James,

We are obviously talking past each other.  I used the aviation and marine
industries as examples of users of geo coordinates for their respective
navigation applications.  I used that analogy because both those
applications commonly refer to fixed locations (e.g. airport runways, marine
buoys/markers), the same non-mobile type entities served by RFC3825 (the
commonality being 'non-mobile, not the application).  I can't testify
whether these application implementations internally represent data in
binary, octal, decimal, etc.  But I can attest that these applications DO
NOT express any kind of uncertainty association in addition to the location
representations.  My experience with these applications have been with
variable length fields, hence a separate resolution parameter has not been
included.

Resolution, whether expressed in binary, octal, decimal, etc. cannot
represent an arbitrary area/shape.  Hence, RFC3825 cannot express an
arbitrary area/shape as it only includes resolution.

Would you please expand your question concerning errors?  What errors?

-Marc-

> From: Winterbottom, James [mailto:[email-masked]] 
> Sent: Friday, September 08, 2006 6:53 PM
> To: Marc Linsner
> It is interesting that you point this out and I am certainly 
> no expert in aviation and marine location systems. I will 
> however point out that from what I have seen that searches at 
> sea and for downed aircraft often span many thousands of 
> square kilometres, I scarcely think that this would be 
> acceptable in a domestic wired or wireless phone emergency situation.
> 
> I would also point out that if you have used the same 
> encoding as is used in those industries it behoves you to 
> have put them in the references section of the RFC, and to 
> have indicated that the encoding scheme came from the there 
> in the text somewhere, I certainly couldn't find any.
> 
> > > application that require a deterministic degree of accuracy, 
> > > something to that effect.
> > > I am quite sure that in some circumstances that the 
> encoding scheme 
> > > is fine, but I wouldn't want to be my life on it in an emergency, 
> > > would you?
> > 
> > described by RFC3825, it's the same data expressions used 
> by aviation
> and
> > marine everyday.  So, unless you travel exclusively by rail, you've 
> > probably already placed you life in the hands of such data 
> > representation, I
> know I
> > have.
> > 
> > -Marc-
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 8 Sep 2006 20:09:41 -0500

Marc,

In all the examples used in RFC-3825 in the appendix, the way resolution
is used is to express a range in the latitude, longitude and altitude.
This expresses an area or volume, there is no other way to interpret
this. I am past believing that you can't see this.

I am not saying having a resolution parameter is not useful, just the
way that RFC-3825 stipulates it be interpreted.

As for errors please read PIDF-LO profile, it is very clear there.

Cheers
James

> Sent: Saturday, 9 September 2006 9:42 AM
> To: Winterbottom, James

---

From: John Schnizlein <[email-masked]>
Date: Sat, 9 Sep 2006 10:50:46 -0400

> this. I am past believing that you can't see this.

These illustrations are in an appendix to indicate that they are not 
normative.  The point of the appendix is to show what size regions 
different resolutions imply, including deliberately partially hiding 
location by lowering resolution.  This does not change the fact that 
the resolution is SPECIFIED as "number of valid bits in the fixed-point 
value".  As we have explained before, this represents the normal 
scientific/engineering concept of significant figures.

> way that RFC-3825 stipulates it be interpreted.

The way RFC 3825 specifies resolution is just what is necessary to 
implement the principle of significant figures when using a 
fixed-length binary number rather than a variable number (limited by 
the measurement precision) of decimal digits.

> As for errors please read PIDF-LO profile, it is very clear there.

No, it is not.  As explained in the dialog on the GeoPriv list some 
time ago, the errors are in your interpretation of the illustration in 
the appendix of RFC 3825.  RFC 3825 does not specify arbitrary 
geographic polygons, although you seem to insist it should.  Your 
invention of longest matching substrings of boundaries leads to the 
errors you report.  Please stop attributing your erroneous 
interpretation to the different purpose of RFC 3825.

John

>> From: Marc Linsner
>>
>> We are obviously talking past each other.  I used the aviation and
>> marine industries as examples of users of geo coordinates for their
>> respective navigation applications.  I used that analogy because both
>> those applications commonly refer to fixed locations (e.g. airport 
>> runways,
>> marine buoys/markers), the same non-mobile type entities served by 
>> RFC3825
>> (the commonality being 'non-mobile, not the application).  I can't 
>> testify
>> binary, octal, decimal, etc.  But I can attest that these applications
>> DO NOT express any kind of uncertainty association in addition to the
>>
>> location representations.  My experience with these applications have
>> been with variable length fields, hence a separate resolution 
>> parameter
>> has not been included.
>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 9 Sep 2006 17:11:07 -0500

John,

Please!
Normal scientific measurements will say +- half the smallest unit. This
will place a point in the middle somewhere, and you yourself at the very
start of this debate came back with a proposal saying that. 

The fact of the matter is that you are starting in the normative section
of the draft that the resolutions parameters place you with in an area.
If this is what is meant, then I am sorry to say that this but the
PIDF-LO draft is correct and you are plain wrong!

James Polk has stated more than once now that the shape defined in
RFC-3825 is a linear ring polygon. If this is the case then the
calculation in PIDF-LO profile also stand.

Quite frankly what is it that RFC-3825 represents. This part of previous
question you have tactfully ignored.

So I am going to ask you. Point, or area?
If Point, then a clarification draft stipulating this is required.
If an area, then please provide a detailed explanation of how would
re-describe the examples in PIDF-LO profile with references to the
sections RFC-3825 that eliminate the inherent errors.

I am tired of you saying that this is wrong, when it clearly follows
your specification, and you do not provide through the same example
where it is wrong, or provide a reasonable alternative.

BR
James

> From: John Schnizlein [mailto:[email-masked]]
> Sent: Sunday, 10 September 2006 12:51 AM
> To: Winterbottom, James
> Cc: [email-masked]; Marc Linsner; [email-masked]
> Subject: Re: [Ecrit] Location information in emergency
sessioninitiation,
> need for time and accuracy?
> 
>

---

From: John Schnizlein <[email-masked]>
Date: Sat, 9 Sep 2006 20:49:09 -0400

What part of "geographic location of the client" is unclear to you?

It is beyond comprehension how this could be interpreted as a area 
rather than a point, with the resolution of the measurement of that 
point explicitly included in the location information.

Why is this old argument being rehashed in the ecrit WG when if finally 
seemed to die (mercifully) in GeoPriv?

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 9 Sep 2006 20:02:18 -0500

So you are saying that the examples in the appendix of RFC-3825 are
wrong, and that RFC-3825 cannot and never will describe an area?

It didn't die in Geopriv, I was waiting for you to actual come back with
an explanation, what you did was write back an email that was totally
irrelevant to the discussion. So I am still waiting!

> Sent: Sunday, 10 September 2006 10:49 AM
> To: Winterbottom, James
sessioninitiation,

---

From: Andrew Newton <[email-masked]>
Date: Sat, 9 Sep 2006 23:28:38 -0400

At the risk of ending the cordial and praiseworthy correspondence of  
this thread, I would like to interject that I am fairly confused.   
Certainly (pun intended) I should have given much more attention to  
my math and statistics studies when I was younger.

First, my initial confusion about this dealt with the terminology  
being used, which is somewhat a point of contention here.  For the  
life of me, I could not understand why anybody would care to  
communicate their "uncertainty" regarding location information nor  
could I understand why a PSAP would want to know it.  "The building I  
am in is on fire, but I'm only 50% certain that it is my house.  I  
could be at work as well."  That just doesn't make sense.  So I can  
only gather that the word is being used in the context of statistical  
probability about a specific point within a shape.  Is this correct?   
And can somebody point to an actual definition of the word?  Is it  
the same as confidence as is used in probability?

At looking at RFC 3825, I think there may be an issue with  
terminology but I believe the concept is appropriate.  3825 uses the  
term "resolution".  I would have thought resolution would refer to  
the range of numbers allowed in the protocol fields.  Instead, it is  
being used to describe the resolution of the measurement.  That is  
fine.  And the take away from it is that a point in 3 dimensions is  
being expressed.

Now, if the receiver of this information is capable of understanding  
a higher "resolution", then one could start asking questions about  
the probability of where a point (at the receivers highest  
resolution) resides inside the shape that can be taken from the  
senders lower resolution point.  I guess that might be useful if  
first responders are sent to the location given by the higher  
resolution point, find nothing, and are then advised to search a  
perimeter of a specific size.

It turns out that the other document in this discussion does talk  
about this.  From Section 6 of draft-ietf-geopriv-pdif-lo-profile:

    Generally these locations are expressed as a point
    (either in two or three dimensions) and an area or volume of
    uncertainty around the point.  In theory, the area or volume
    represents a coverage in which the user has a relatively high
    probability of being found, and the point is a convenient means of
    defining the centroid for the area or volume.  In practice, most
    systems use the point as an absolute value and ignore the
    uncertainty.

Interchange "uncertainty" and "resolution" and these documents are  
saying the same thing.  Which term is correct?  At present, I'm not  
convinced either is.

All this leaves me with two very big questions.  Since 3825 is  
describing a point in 3 dimensions, why does pidf-lo-profile talk  
about 3825 LCI as being a rectangle in Appendix A?  And if 3825 is  
describing a point, how can its equivalent in GML be a linear ring?   
I would think it would be a GML point (or Position in GML speak).

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 10 Sep 2006 09:11:51 -0500

I can help with the definitions.

Uncertainty: The parameter which defines the area in which the target is
expected to be. An area of uncertainty may be represented as a point
center and a radius. There's nothing special about the center - all
points within the circle defined by the radius are equally likely to be
correct for the target. For example, a location based on the serving
cell of a radio network is no more likely to be correct for the center
of the cell than it is for any other point of coverage of that cell.

Confidence: The probability that the target is actually in that area of
uncertainty. For example, the radius may be provided with 80%
confidence. This means that four out of five times the target will be
somewhere with that circle and one time out of five it will be outside
the circle. That one time out of five the target could be anywhere in
the universe. The circle does not convey anything about the uncertainty
associated with the 20% of cases when the target is outside the circle.

Statistically, given many (actually all) location measurement techniques
are subject to error, an uncertainty area is inevitably associated with
the result. In the above example, the only way to have a higher
confidence (e.g. push it up to 95% so that only one out of twenty
targets are incorrectly located) is to re-evaluate the measurement
technique to work out the larger radius of uncertainty associated with
that higher confidence.

Uncertainty and confidence are actually quite important to emergency
services because:
A) The uncertainty value allows for more reliable routing of calls
occurring close enough to the routing boundaries for the uncertainty to
be significant. There is nothing special about the centroid point - it
is as likely to be the location of the target as any other point within
the area of uncertainty. If significantly more of the area of
uncertainty lies on one side of a boundary, even if it doesn't include
the centroid, then the that is the more reliable route to select.

B) When dispatching first responders, the area of uncertainty tells
emergency services where they need to focus the search.

C) Since no area of uncertainty for a measured location has 100%
confidence, dispatch procedures must also cover the instance where the
target doesn't actually lie within the area of uncertainty. The
confidence provides the likelihood that this is the case and the form
that the contingency procedures take will be governed in part by the
degree of that likelihood.

The geo-coding prescribed in RFC 3825 does not have the ability to
specify arbitrary values of uncertainty or confidence. As such it cannot
provide the benefits described above.

For example: what would the 3825 encoding be if you wanted to specify a
location 100 meters either side of latitude North 52 degrees? Or, to
emphasize the extreme case, what if that was in the UK at 100 meters
either side of zero degrees longitude?

3825 specifically says that the bits not covered by the resolution can
be either one or zero or one. You actually have to try and use this
approach to codify arbitrary location uncertainties such as the above to
see what the problem is.

Cheers,
Martin

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Sunday, 10 September 2006 1:29 PM
> To: Geopriv WG; [email-masked]
> Cc: Marc Linsner; John Schnizlein
> Subject: [Geopriv] I'm 100% certain I Don't Understand
>

---

From: [email-masked]
Date: Mon, 11 Sep 2006 04:36:02 -0400 (EDT)

This conversation peaked my interest. I have just looked at RFC-3825. Not
having been privy to all the original discussions and decisions, I am a
fresh set of "eyes" looking at this document. I think what we have here is
a failure to communicate due to ambiguous semantics in 3825. I may be
wrong in this perception, but . . .

My interpretation is that what is being defined is a uncertainty shape in
which the location of the device falls. As such, it is not truly a point.
A point in Euclidean geometry has no size, orientation, or any other
feature except position. This is the basis of the ISO/OGC definition for a
point geometry.

Take the following example. We draw a point by placing a dot with a
pencil. This dot may have a diameter of 0.2mm, but a point has no size. No
matter how far you zoomed in, it would still have no width.

What this discussion is really about is the fact that a point geometry,
whose location is defined by a lat/long coordinate, also has properties.
These properties include estimates of accuracy and precision. Very simply
stated: If the actual value is 4.321 and you say that it is 4.30, then you
are precise to the first decimal place but inaccurate by .021. There are
also properties of error and uncertainty. All these four properties are
very well defined in the literature. For example see:
http://scidiv.bcc.ctc.edu/Physics/Measure&sigfigs/B-Acc-Prec-Unc.html

So, what I would suggest is that perhaps 3825 be modified to very clearly
disambiguate the semantics of the terms being used. I suspect that what
"resolution" is really referring to is a description of the uncertainty of
the measurement. The point being measured falls somewhere in the area of
certainty. The shape of this area (yes, it is an area/polygon) actually
has a pretty strange shape if one transforms from lat/long to some other
coordinate reference system, such as State Plane.

Regards

Carl

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 11 Sep 2006 04:02:09 -0500

Hi Carl,

Thanks for the input.
I guess as far as I see it, this should go one of two ways.
Either, stipulate RFC-3825 as representing a point only, in which case a
specification is required to make this clear and unambiguous.

Or

A specification is required expressing how to interpret the encoding
scheme such that the problems around the equator, prime meridian and
other arbitrary locations are not encountered.

I don't mind which, but a problem exist and supporters of the RFC-3825
mechanism should seek to resolve it. Until such time as it is resolved
this specification should only be used with a great deal of caution.

Cheers
James

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, 11 September 2006 6:36 PM
> To: Winterbottom, James
> Cc: John Schnizlein; [email-masked]; Marc Linsner; [email-masked]
> Subject: Re: [Geopriv] RE: [Ecrit] Location information in emergency
> sessioninitiation, need for time and accuracy?
> 
------------------------------------------------------------------------
> ------------------------
------------------------------------------------------------------------
> ------------------------

---

From: John Schnizlein <[email-masked]>
Date: Mon, 11 Sep 2006 10:19:40 -0400

> wrong in this perception, but . . .

Why you would claim not to have been in the discussions?

On Jan 23, 2003, at 6:20 PM, Carl Reed wrote:

> Hi Mark
>
> Very good questions and a proper concern. I will pass this question on 
> to a
> real "datum professional". One of our members is the Chairman of the 
> EPSG
> Geodesy group. We also have an entire Working Group dedicated to 
> Coordinate
> Reference Systems (which include datums - horizontal and vertical).
>
> Regards
>
> Carl
>
> ----- Original Message -----
> From: Marc Linsner <[email-masked]>
> To: Carl Reed <[email-masked]>
> Cc: John Schnizlein <[email-masked]>; James Polk 
> <[email-masked]>;
> <[email-masked]>
> Sent: Thursday, January 23, 2003 8:16 AM
> Subject: RE: I-D ACTION:draft-ietf-geopriv-dhcp-lo-option-00.txt
>
>
>> Thank You!  Those of us working on the draft certainly have been
>> looking for a 'datum expert' to help us out!
>>
>> Now you're 'on the hook'! :^)
>>
>> If I'm correct in my intrepretation of the epsg database, it appears 
>> there
>> are 267 datums.  If we use the epsg codes, they require 2 bytes 
>> (actually 14
>> bits) to represent them in binary.  You're implying that lining up 
>> with epsg
>> is the proper thing to do, rather than creating news codes for each 
>> datum
>> under the IANA umbrella.  I'm struggling with the 'rumors on the 
>> street'
>> that some of the datums may never be used - in fact only ~100 are 
>> actively
>> used today.  The part I'm struggling with is to utilize 2 bytes when 
>> only
>> ~100 choices will be in use.
>>
>> Your thoughts one more time, please.
>>
>> -Marc Linsner-
>>
>>
>>
>>> From: Carl Reed [mailto:[email-masked]]
>>> Sent: Wednesday, January 22, 2003 6:15 PM
>>> To: Marc Linsner
>>> Subject: Re: I-D ACTION:draft-ietf-geopriv-dhcp-lo-option-00.txt
>>>
>>>
>>> Hi Marc -
>>>
>>> There is no political issue related to a datum. There is no
>>> "correct" datum for a locale. There can be many datums for a
>>> given location - all of them correct. For example, in the US
>>> many localgovernments deal with WGS 84, NAD 27, and NAD 83 datums.
>>> Many local government planimetric databases are now in NAD 83.
>>> In order for anyone to process a location and make sure that it
>>> is georeferenced with a given planimetric or cadastral database,
>>> the datum needs to be known. This is not a political issue -
>>> simply a reality in the geospatial processing world
>>> - especially one in which interoperability of
>>> spatial data source (static and real time) is required.
>>>
>>> Regards
>>>
>>> Carl Reed

---

From: Andrew Newton <[email-masked]>
Date: Mon, 11 Sep 2006 10:42:38 -0400

> Why you would claim not to have been in the discussions?

At this point, I will put my chair hat on and say that there is no need to 
go down this particular dark alley.

So far, I am only hearing one person claiming that 3825 is inadequate and 
many other voices suggesting that it merely needs clarification.  Certainly, 
3825 would not be the first RFC in IETF history needing clarification.

As part of any clarification effort, I think the community would be well 
served to have 3825 to GML conversion examples.  Not having fully digested 
the requisite amount of morning coffee, I cannot easily judge if GML can 
express uncertainty about a point.  That would "certainly" be helpful.

And as Henning has suggested, we would also be well served by documented and 
agreed upon definitions of these terms.

-andy

---

From: [email-masked]
Date: Mon, 11 Sep 2006 11:07:41 -0400 (EDT)

Because I was not!! I was focusing on other standards related issues at
the time in the OGC and was also looking at PIDF-LO

Pretty simple, yes?

Carl

---

From: [email-masked]
Date: Mon, 11 Sep 2006 11:10:38 -0400 (EDT)

Andrew -

Thank you.

I would be most happy to share this dialogue with the GML experts. That
said, as DHCP is a binary encoding and GML is an XML schema encoding, it
might be better to look to GML and related OGC/ISO standards for guidance
as to how to provide the proper clarification statements in 3825.

Regards

Carl

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 11 Sep 2006 10:18:20 -0500

I am not sure that I know what Uncertainty about a point means.
GML certainly can express areas of uncertainty and that was the purpose
of the geoshapes draft.

I might point out that the problems that Martin T and I have raised with
regards to the encoding scheme in RFC-3825 have come about from exactly
doing what is proposed below. We tried to turn the elements returned by
RFC-3825 into a GML object. So to my mind I am not sure where this
leaves us.

Cheers
James

> Sent: Tuesday, 12 September 2006 12:43 AM
> To: John Schnizlein; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Geopriv] RE: [Ecrit] Location information inemergency
> And as Henning has suggested, we would also be well served by
documented
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit