Re: [Geopriv] RFC 3825 Updates

From: Andrew Newton ^lt;andy@hxr.us>
Date: Thu Feb 01 2007 - 20:48:31 EST

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.
>
>
>
> Hope this information is of use.
>
> Regards
>
> Carl
>
> ----- Original Message ----- From: "Marc Linsner" <mlinsner@cisco.com>
> To: "'Thomson, Martin'" <Martin.Thomson@andrew.com>
> Cc: <geopriv@ietf.org>
> 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
>> Geopriv@ietf.org
>> https://www1.ietf.org/mailman/listinfo/geopriv
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 1 Feb 2007 20:48:31 -0500

This archive was generated by hypermail 2.1.8 : Thu Feb 01 2007 - 20:49:03 EST