Subject: Re: [Geopriv] RFC 3825 Updates

From: "Carl Reed OGC Account" <[email-masked]>
Date: Thu, 1 Feb 2007 16:25:53 -0700

Sorry for the late posting on this topic. It is also slightly off topic as I 
do not discuss DHCP and uncertainty.

The work of the OGC is getting more and more into the realm of interfaces 
and encodings for sensor networks - and this work definitely bleeds into the 
consumer space. For example, the work we have done for GeoRSS. At the end of 
the day, a location enabled cellular device is a sensor and the cellular 
network an extensive sensor system. So, OGC work on Observations and 
Measurements might be of interest. There is an OGC Best Practices document 
title "Observations and Measurements". It is related to/harmonized with GML 
and is a key component of a suite of candidate OGC standards for interfaces 
and encodings for sensors.

>From the O&M document:

Observations focus on the data collection event. An Observation event serves 
to assign a value to a property of a feature. If the property is 
non-constant, the value may be a coverage. The results of a set of 
observations of different properties on the same feature of interest may 
provide a complete description of the feature instance. Alternatively, the 
results of a set of observations of the same property on a set of different 
features provide a discrete coverage of that property over a domain composed 
of the geometry of the feature set. The other properties of the Observation 
are metadata concerning the estimation of the value(s) of a property on a 
feature of interest.

In particular, Observations concern properties (e.g. shape, color) whose 
values are determined using an identifiable procedure, in which there is a 
finite uncertainty in the result. This may be contrasted with properties 
whose values are specified by assertion (e.g. name, owner) and are therefore 
exact. The observation instance provides "metadata" for the property 
value-estimation process.

Now, there is also an ISO Metadata standard (19115) in which a variety of 
properties related to quality and uncertaintly are defined.

Hope this information is of use.

Regards

Carl

----- Original Message ----- 
From: "Marc Linsner" <[email-masked]>
To: "'Thomson, Martin'" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 05, 2007 7:45 AM
Subject: RE: [Geopriv] RFC 3825 Updates

> Martin,
>
>>
>> When have cellular telephone contexts been involved in this
>> discussion?  The point has always been that there is
>> uncertainty in the measurement of a position.  That doesn't
>> change, in any context.  The only bearing that cellular
>> telephony has on the topic is that they solved that problem
>> years ago and have since moved on.
>>
>
> Could you please identify consumer geo applications outside of the 
> cellular
> telephone context where uncertainty (error in measurement) is expressed?
>
> In my limited exposure, I've looked at marine and aviation, neither of 
> which
> express uncertainty as a separate entity.
>
> What isn't clear to me is the value of conveying uncertainty in the 
> context
> that DHCP serves.
>
> -Marc-
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv 

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Andrew Newton <[email-masked]>
Date: Thu, 1 Feb 2007 20:48:31 -0500

Carl,

Thanks for having the patience to deal with awkward IETF  
discussions.  It should be obvious to anyone reading 3825 discussions  
why I wanted the OGC to do the Geoshapes work.  If I may summarize  
your point: any act where a measurement is taken will have  
uncertainty, unlike the act of asserting a name.  For example, the  
act of measuring the lat/long for the Washington Monument will have  
uncertainty, but the act of naming the Washington Monument does not.

My understanding of the 3825 controversy is as follows:

1) Somewhere along the way, it was determined that the lat/long  
measurement in RFC 3825 would be expressed as a linear ring in GML.   
I don't think that is correct.  It is a point.  And I think this is  
the root of the controversy.

2) Because of the above, the ability to express resolution of the  
fixed binary values in RFC 3825 has been confused with a perceived  
necessity to also communicate uncertainty when delivering RFC 3825  
information.

3) John's binary LCI draft is an attempt to clarify this, by showing  
how to convert those fixed length 1's and 0's into infinite length  
ASCII digit strings usable for things like GML.  However, it is still  
a point.  There is no uncertainty involved.

4) The perceived necessity to communicate uncertainty information  
arises from the fact that many systems that measure the location of  
mobile devices do this today.  However, the authors of RFC 3825 have  
pointed out that RFC 3825 is not applicable to those use cases.  It  
is intended only to provide the location of fixed, wired devices.   
While there is no denying that there is uncertainty in the lat/long  
measurement of a fixed, wired device, the utility for conveying that  
information is small.  Or in other words, either you know its lat/ 
long, or you don't.

That's how I understand things.

-andy

On Feb 1, 2007, at 6:25 PM, Carl Reed OGC Account wrote:

> Sorry for the late posting on this topic. It is also slightly off  
> topic as I do not discuss DHCP and uncertainty.
>
> The work of the OGC is getting more and more into the realm of  
> interfaces and encodings for sensor networks - and this work  
> definitely bleeds into the consumer space. For example, the work we  
> have done for GeoRSS. At the end of the day, a location enabled  
> cellular device is a sensor and the cellular network an extensive  
> sensor system. So, OGC work on Observations and Measurements might  
> be of interest. There is an OGC Best Practices document title  
> "Observations and Measurements". It is related to/harmonized with  
> GML and is a key component of a suite of candidate OGC standards  
> for interfaces and encodings for sensors.
>
>> From the O&M document:
>
> Observations focus on the data collection event. An Observation  
> event serves to assign a value to a property of a feature. If the  
> property is non-constant, the value may be a coverage. The results  
> of a set of observations of different properties on the same  
> feature of interest may provide a complete description of the  
> feature instance. Alternatively, the results of a set of  
> observations of the same property on a set of different features  
> provide a discrete coverage of that property over a domain composed  
> of the geometry of the feature set. The other properties of the  
> Observation are metadata concerning the estimation of the value(s)  
> of a property on a feature of interest.
>
> In particular, Observations concern properties (e.g. shape, color)  
> whose values are determined using an identifiable procedure, in  
> which there is a finite uncertainty in the result. This may be  
> contrasted with properties whose values are specified by assertion  
> (e.g. name, owner) and are therefore exact. The observation  
> instance provides "metadata" for the property value-estimation  
> process.
>
> Now, there is also an ISO Metadata standard (19115) in which a  
> variety of properties related to quality and uncertaintly are defined.
>
>
>
> ----- Original Message ----- From: "Marc Linsner" <[email-masked]>
>> In my limited exposure, I've looked at marine and aviation,  
>> neither of which
>> What isn't clear to me is the value of conveying uncertainty in  
>> the context
>> that DHCP serves.
>>
>> -Marc-
>>

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 1 Feb 2007 20:12:43 -0600

3825 defines a point and an additional "resolution" parameters.

The salient question then, if all that is intended to be communicated is
the point, is what would the sender be intending to communicate with the
resolution parameters - and what is the recipient of that information
supposed to interpret it as meaning?

Certainly - it doesn't have to mean uncertainty; it could be conveying
an extent (an area), as is described in the examples in the A.1 section
of the RFC. Either way, it's not just a point.

What use, for example, should the OGC make of the resolution parameters
in coming up with a GML representation of the 3825 encoding?

Cheers,
Martin

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Friday, 2 February 2007 12:49 PM
To: Carl Reed OGC Account
Cc: [email-masked]; Marc Linsner; Thomson, Martin
Subject: Re: [Geopriv] RFC 3825 Updates

Carl,

-andy

------------------------------------------------------------------------------------------------
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: Andrew Newton <[email-masked]>
Date: Thu, 1 Feb 2007 21:45:12 -0500

> supposed to interpret it as meaning?

As I said, the information is to aid in conversion of 1's and 0's to  
ASCII digit strings, such as what you would find in GML.

> of the RFC. Either way, it's not just a point.

Well, there is no doubt about it.  That appendix is confusing.  It  
seems to talk about how one would interpret a lower resolution point  
with higher resolution values, ending up with an area in the higher  
resolution values -- which it shouldn't do.  I think the purpose of  
the appendix is to demonstrate change in the resolution parameters  
relative to distances humans more readily understand.

> in coming up with a GML representation of the 3825 encoding?

Once they have their lat/long values, none -- they throw the  
resolution parameters away (i.e. the resolution parameters are not be  
represented explicitly in GML).

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 1 Feb 2007 20:49:12 -0600

There seems little point in providing resolution parameters if all they
mean is that subsequent digits should be interpreted as zero (ignoring
for a moment that the text actually says they could be either one or
zero - meaning the encoding represents a set of points). The sender
could just set them to zero in the encoding in the first place - meaning
the resolution parameters are superfluous.

Cheers,
Martin

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Friday, 2 February 2007 1:45 PM
To: Dawson, Martin
Cc: Carl Reed OGC Account; [email-masked]; Marc Linsner; Thomson,
Martin

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 1 Feb 2007 20:50:56 -0600

Here is a quote from section 2.1 of RFC-3825 relating to how resolution
parameters are to be used:

" The examples in the appendix illustrate that a smaller value in the
   resolution field increases the AREA within which the device is
   located."

This does not seem to imply a point to me, since this is normative text.

Cheers
James

---

From: Andrew Newton <[email-masked]>
Date: Thu, 1 Feb 2007 21:59:17 -0500

> the resolution parameters are superfluous.

If you are trying to get me to agree that at this point the argument  
gets into a matter of taste, then you have succeeded.  But then  
again, I'm not an expert in this field... not even close.

As the argument goes, what does 39.000000000 tell you that 39.0 does  
not?  It tells you that the measurement was 39.000000000 and not  
39.000000001.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 1 Feb 2007 22:01:50 -0500

> This does not seem to imply a point to me, since this is normative  

To me, it implies that somebody made a mistake.  If it isn't, then I  
am confused.

-andy

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 1 Feb 2007 21:08:48 -0600

You are implying the use of significant figures.  This is a common, but not especially precise, means of expressing uncertainty.

I’ve posted this reference previously, but I find that it helps.

http://www.av8n.com/physics/uncertainty.htm

You can also find numerous articles on uncertainty in measurement all over the web.

________________________________

From: Andrew Newton [mailto:[email-masked]] 
Sent: Friday, 2 February 2007 1:59 PM
To: Dawson, Martin
Cc: [email-masked]; Marc Linsner; Thomson, Martin
Subject: Re: [Geopriv] RFC 3825 Updates

If you are trying to get me to agree that at this point the argument gets into a matter of taste, then you have succeeded.  But then again, I'm not an expert in this field... not even close.

As the argument goes, what does 39.000000000 tell you that 39.0 does not?  It tells you that the measurement was 39.000000000 and not 39.000000001.

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 1 Feb 2007 21:11:23 -0600

This is not a mistake, the specification clearly attempts to represent
an area, and one of the authors at least has clearly expressed this more
than once.

The statement in section 2.1 of the document makes the examples in the
appendix normative, not informative as it describes how to use the
fields.

RFC-3825 has clear errors and problems that cannot simply be corrected
with an informative document as is currently being proposed.

From: Andrew Newton [mailto:[email-masked]] 
Sent: Friday, 2 February 2007 2:02 PM
To: Winterbottom, James
Cc: Dawson, Martin; [email-masked]; Marc Linsner; Thomson, Martin
Subject: Re: [Geopriv] RFC 3825 Updates

   located."

To me, it implies that somebody made a mistake.  If it isn't, then I am
confused.

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 1 Feb 2007 21:17:10 -0600

This is more fundamental than just taste.

My good mate Euclid tells me that a point has no area - its actual
coordinates can only be represented by real numbers of infinite length.
The concept of conveying "resolution" is conveying an uncertainty/area
and that is not compatible with the position that the intent is to just
convey a point. As soon as you claim to be communicating resolution then
you are also communicating an area.

If the intent in sending 39.000000000 plus 8 digits of  "resolution"
parameter is to indicate that the actual value is 39.0xxxxxxxx then what
is being communicated is that the actual value is considered to be
somewhere between 39.000000000... and 39.011111111...

It is common practice to send encodings of real number quantities in
protocols whose inherent precision is constrained by the encoding rules
- conversion to a real quantity assumes proceeding digits are zero.
Adding another parameter to further (artificially?) constrain the
protocol's encoding precision serves no value - it's not something I've
seen in other protocols - and, as above, carries a contradictory
interpretation.

If there's no useful information in the resolution parameters then it
would make sense to remove them. If the intent really is to convey
resolution then the fact that the current definition is not useful for
communicating arbitrary absolute extents will need to be confronted.

Cheers,

Martin 

 

If you are trying to get me to agree that at this point the argument
gets into a matter of taste, then you have succeeded.  But then again,
I'm not an expert in this field... not even close.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Fri, 2 Feb 2007 03:46:07 -0500

I suspect that if your company's payroll department and your bank  
communicated your paycheck with an insufficient amount of resolution,  
you'd by unhappy about that.

I think there is a difference between giving the uncertainty of a  
measurement derived from a set of separate measurements and giving  
the resolution of a single measurement.  There is a difference between:

   I took a measurement and got 39.00000 on the nose.

and

   I took three measurements.  They are 39.00000, 39.00001, and  
38.99999.

-andy

On Feb 1, 2007, at 10:08 PM, Thomson, Martin wrote:

> You are implying the use of significant figures.  This is a common,  
> but not especially precise, means of expressing uncertainty.
>
>
>
> If you are trying to get me to agree that at this point the  
> argument gets into a matter of taste, then you have succeeded.  But  
> then again, I'm not an expert in this field... not even close.
>
>
>
> As the argument goes, what does 39.000000000 tell you that 39.0  
> does not?  It tells you that the measurement was 39.000000000 and  
> not 39.000000001.
>
>
>
> -andy
>
>
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 2 Feb 2007 04:43:49 -0500

> It is common practice to send encodings of real number quantities  
> in protocols whose inherent precision is constrained by the  
> encoding rules – conversion to a real quantity assumes proceeding  
> digits are zero. Adding another parameter to further  
> (artificially?) constrain the protocol’s encoding precision serves  
> no value – it’s not something I’ve seen in other protocols - and,  
> as above, carries a contradictory interpretation.
I'm curious how you would do this with fixed-point binary numbers,  
unless you add a length or mask parameter of some sort.

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 2 Feb 2007 07:54:05 -0500

Could I ask the chairs to figure out a way to stop this incessant bickering?

I have an opinion about the matter, but so what, we have a lot of opinions.
What we need is a rough consensus on whether 3825 is useful as is, or needs
to be changed.  

We have heard all of these arguments over and over, and I don't think we are
changing anyone's mind here.

Maybe we should ask for a hum in Prague.  Maybe we should ask for comments
from people who haven't weighed in.  Maybe we should seek more outside
experts.  But just to continue to have Martin D, Martin T and James W
repeating the same thing over and over, while John S, Marc L and
occasionally Henning (who doesn't need an initial to distinguish him from
any other Henning) repeat the same thing over and over isn't getting us
anywhere.

Oh, just for the record, while I think some of the wording in 3825 was
poorly chosen, I see the value in the resolution parameter, understand how I
use it to construct a PIDF-LO with geoshapes, don't think uncertainty has a
practical value in the DHCP location configuration use case, and don't think
3825 needs to be changed.

Brian

________________________________________
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Friday, February 02, 2007 4:44 AM
To: Dawson, Martin
Cc: GEOPRIV WG
Subject: Re: [Geopriv] RFC 3825 Updates

It is common practice to send encodings of real number quantities in
protocols whose inherent precision is constrained by the encoding rules -
conversion to a real quantity assumes proceeding digits are zero. Adding
another parameter to further (artificially?) constrain the protocol's
encoding precision serves no value - it's not something I've seen in other
protocols - and, as above, carries a contradictory interpretation.
I'm curious how you would do this with fixed-point binary numbers, unless
you add a length or mask parameter of some sort.

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 2 Feb 2007 07:29:29 -0600

Please then, Brian, tell me what useful information you think the resolution parameters convey to you as the DHCP client in terms of understanding the nature of the point location?
 
And, for the record, the argument that uncertainty - or area associated with location - is somehow only pertinent to mobile access networks is quite bogus as far as I'm concerned. If the DHCP server can only associate an approximate location with a particular end point then it's totally appropriate to provide uncertainty for that location regardless of whether the end point is mobile or fixed.
 
It's obvious to anyone who actually wants to see it that there has been a switch in the stated intent of this RFC and the resultant verbal gymnastics are down to considerably more than just poorly chosen words.
 
Cheers,
Martin

From: Brian Rosen [mailto:[email-masked]]
Sent: Fri 2/2/2007 11:54 PM
To: 'Henning Schulzrinne'; Dawson, Martin
Cc: 'GEOPRIV WG'
Subject: RE: [Geopriv] RFC 3825 Updates

Brian

---

From: Andrew Newton <[email-masked]>
Date: Fri, 2 Feb 2007 10:00:21 -0500

> Could I ask the chairs to figure out a way to stop this incessant  

Brian, the incessant bickering is the sound of the sausage being made  
in the IETF.  Besides, this list has been a little quiet of late.

> changing anyone's mind here.

That's exactly why I gave my observations, so that new voices could  
be heard on this.  I agree that the usual voices in this argument  
have come to a stalemate.

> 3825 needs to be changed.

Thanks very much for giving your opinion (I'm rather shocked you  
withheld it in the first place :) ).  Just one question, do the  
values conveyed in 3825 constitute a point or an area?

-andy

---

From: Andrew Newton <[email-masked]>
Date: Fri, 2 Feb 2007 10:02:32 -0500

On Feb 2, 2007, at 8:29 AM, Dawson, Martin wrote:

> And, for the record, the argument that uncertainty - or area  
> associated with location - is somehow only pertinent to mobile  
> access networks is quite bogus as far as I'm concerned. If the DHCP  
> server can only associate an approximate location with a particular  
> end point then it's totally appropriate to provide uncertainty for  
> that location regardless of whether the end point is mobile or fixed.

If the National Park Service gave the coordinates of the Washington  
Monument as X,Y plus or minus N, you wouldn't find that odd?

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 2 Feb 2007 11:07:04 -0500

> values conveyed in 3825 constitute a point or an area?
A point

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 2 Feb 2007 11:47:23 -0500

Let me try a new angle that just might bridge the point vs. area  
discussion. I think both somewhat miss the point (sorry). We need to  
think probabilistically, not deterministically.

For all measurements, we're talking about a probability distribution  
of measurements. There are three cases:

(1) The probability of being outside the area is zero. This is only  
true if the area circumscribes, say, a property line and there is no  
realistic chance that a device associated with that area can be  
outside that area. This has nothing to do with measurement errors as  
such, just physical limitations of where, say, Ethernet sockets are.  
Obviously, even in buildings with DHCP, this is sometimes fuzzy,  
e.g., if there's a wireless hotspot that radiates outside the  
building. Nothing is said about the likelihood distribution within  
that area.

A fuzzed (privacy-obfuscated) area is a special case. In other words,  
the actual measurement is much more precise than what's conveyed, so  
the object is (virtually) guaranteed to be somewhere inside the  
indicated ranges of coordinates, with equal probability.

(2) The circle or other area describes a probability distribution  
induced by measurement errors. In almost all cases, this really means  
that x%, for some large x (say 90 or 95, but could be 66 in some FCC  
regs), of the time the true location is indeed inside that area and  
for (100-x)% it is outside. This seems to be the typical definition.  
However, nothing is said about the probability distribution within  
that area - the recipient of the information has to assume that the  
likelihood of the object being at any given point within the area is  
equal.

In reality, the latter isn't often quite true. Thus, the most likely  
location is close to the centroid of the area. However, just having  
an area doesn't tell you one way or the other.

(3) A point with an uncertainty region. Here, the assumption is that  
the highest-probability location is at the point, with an uncertainty  
region of the x% kind around it. This is the typical measurement  
uncertainty/significant figures case.

Thus, the answer is not "point or area", but "both".

Unfortunately, 3825 and many other specs are often unclear what  
assumptions they make on the probability distribution. 3825 addresses  
both the fuzzed case and (3), but the probability interpretation  
differs.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 2 Feb 2007 12:16:27 -0500

I was asked if I considered 3825 to convey a point or an area.  I believe it
conveys a point, and not an area.  

I think the "fuzzing" is irrelevant to the discussion.  3825 describes how
an endpoint gets location from its local access network.  There is no
mechanism, and no requirement for a mechanism to intentionally "fuzz" the
location originating in the access network, and being conveyed to the
endpoint.  The endpoint may subsequently "fuzz" what it does with that
location, but that wouldn't use DHCP.  The appendix is completely irrelevant
to location configuration using DHCP.

3825 does not have the syntax, and I do not believe there is a requirement,
for a way for DHCP to convey an area of any kind.

I don't understand the distinction you are making between 2 and 3.  A point
with circular uncertainty seems to be what 2) is describing, and yet that is
what 3) describes.  If you have a (known) measurement error, you express
that as uncertainty.  No one has proposed another way to represent
measurement error.  As you note, uncertainty is almost always defined as
equal probability within the area, even if the measurement mechanisms have a
different error characteristic.

Brian

> Sent: Friday, February 02, 2007 11:47 AM
> To: Brian Rosen
> Cc: GEOPRIV WG

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 2 Feb 2007 12:28:02 -0500

> different error characteristic.

The difference is the probability distribution. Picture it one- 
dimensionally, since that's easier.

One version is a flat (uniform) distribution. The object is equally  
likely to be anywhere on that line segment. (For the x% case, the CDF  
across that segment would add up to less than 1.)

Another is the non-uniform distribution. This is where the center of  
the line segment has the highest probability density. Think of a  
Gaussian distribution with the typical bell shape.

These are very different descriptions. If somebody told you their  
location by giving you the first version, you would search for them  
in some pattern, but it didn't matter where you started and what  
search pattern you used. In the second case, you'd be much better off  
starting in the middle of the area, since the probability of finding  
them around the center is much higher than elsewhere.

Same holds in two (and three) dimensions.

Henning
(at a point somewhere in the Terminal 4 area at LHR)

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Sat, 3 Feb 2007 09:14:25 -0700

Maybe I am a bit naive on the subject of DHCP and location conveyance, but 
jumping in again and following up on my previous posting regarding 
observations and measurements.

In both the analogue (traditional paper mapping) digital GI world, issues 
related to expressing the uncertainty of a coordinate location, or the 
boundary of a polygon, or the "fuzziness" of a land-use classification still 
receives considerable attention. Some of the discussion get pretty esoteric 
(like "Coupling fuzzy sets theory and GIS-based cellular automata for 
land-use change modeling"). So much time and effort is spent on these 
discussions because an expression of "fit for use" is often a key 
requirement in how an application or user determines whether the spatial 
data are of sufficient quality to be used. The OGC has just initiated a new 
Data Quality working group to focus on providing a common semantic for 
expressing the quality (accuracy, resolution, etc) for spatial content. No 
trivial task.

Anyway, geographers and cartographers tend to try to simplify such 
discussions so that we can actually provide a simple measure of uncertainty 
for any location content.

The following is from a GI website in Canada. This  document references an 
excellent paper by a group of geographers and posted at the Colorado 
University website 
(http://www.colorado.edu/geography/gcraft/notes/error/error_f.html). Notice 
that accuracy and uncertainty are coupled and not resolution and 
uncertainty.
Data accuracy and uncertainty
Data accuracy is an statement of how closely a bit of data represents the 
real world. It applies to geographical information in all these ways:
  a.. What features have been omitted ?
  b.. What non-existent features are represented ?
  c.. How correct is their classification ?
  d.. How current is the data ?
  e.. How far away is a map feature from its actual location in the world ?
This last, or 'locational' accuracy is of interest here, and is generally 
stated in terms of uncertainty. Locational accuracy includes :
  a.. absolute accuracy: How close is the location on the map or data 
representation to its real location on the earth ? For example, '95% of the 
well locations are within 50 metres of their surveyed locations'.
  b.. relative accuracy: How similar is a shape on the map or data 
representation to the shape of the object on the earth. For example, 
'cutblock boundaries do not vary by more than 10 metres from their actual 
shape'.
These are separated because a map object may have a very accurate shape, but 
not be registered (located) correctly.
A rigorous statement of accuracy will include statistical measures of 
uncertainty and variation, as well as how and when the information was 
collected. Spatial data accuracy is independent of map scale and display 
scale, and should be stated in ground measurement units.

So, at the end of the say, this is why we see statements such as:
At a scale of 1:100,000, the horizontal accuracy is good to ± 166.67 feet

This means that when we see a point on a map we have its "probable" location 
within a certain area. The same applies to lines. So, a discussion of 
precision or resolution may be the wrong approach. Perhaps what is really 
needed is just a simple statement of horizontal and vertical accuracy.
Beware of the dangers of false accuracy and false precision, that is reading 
locational information from map to levels of accuracy and precision beyond 
which they were created. This is a very great danger in computer systems 
that allow users to pan and zoom at will to an infinite number of scales. 
Accuracy and precision are tied to the original map scale and do not change 
even if the user zooms in and out. Zooming in and out can however mislead 
the user into believing--falsely--that the accuracy and precision have 
improved.

----- Original Message ----- 
From: "Henning Schulzrinne" <[email-masked]>
To: "Brian Rosen" <[email-masked]>
Cc: "'GEOPRIV WG'" <[email-masked]>
Sent: Friday, February 02, 2007 10:28 AM
Subject: Re: [Geopriv] RFC 3825 Updates

> Another is the non-uniform distribution. This is where the center of  the 
> line segment has the highest probability density. Think of a  Gaussian 
> distribution with the typical bell shape.
>
> location by giving you the first version, you would search for them  in 
> some pattern, but it didn't matter where you started and what  search 
> pattern you used. In the second case, you'd be much better off  starting 
> in the middle of the area, since the probability of finding  them around 
> the center is much higher than elsewhere.
>