Subject: [paws] PAWS Location info using RFC5491

From: Kalle Kuismanen <[email-masked]>
Date: Wed, 13 Mar 2013 04:22:09 +0200

Hello everybody,

First of all, thank you for interesting presentations in Orlando, I hope
weather was bit warmer than here in Finland where I was doomed to watch
them.

I'm not sure how much discussion you've had on the method used to describe
location in this draft. So I apologize in advance if this issue is closed.

This draft of PAWS protocol uses JSON syntax, but RFC5491, which is used to
describe location is XML based protocol.
This causes a problem for us implementers, because this hybrid loses
unambiguity i.e. I cannot verify the location entries against json-schema
because it doesn't exist.

As an alternative I think something like following would be useful as a
replacement or an alternative.

Most implementations of geospatial databases understand ISO/IEC
13249-3:2011 WKT and BKT format for geometric representations and there are
a lot of ready made code to handle it.

http://en.wikipedia.org/wiki/Well-known_text#Well-known_binary

so instead of
"location": {
 "point": {
 "center": {"latitude": 37.0005, "longitude": -101.3005}
 } }

one could enter

"location": {
 "wkt": "POINT (101.3005 37.0005)",
 "srid":4326 }

or WKB equivalent. Just a note: (srid 4326 is the id for WGS84)

Advantage of this is that since WKT and WKB are understood by most
geospatial databases there is very little parsing to do, validation is
trivial and as a bonus it can be directly entered as a part of a query.
Protocol covers other geometric shapes.

It doesn't cover ellipse though, but then again it's not very common
feature in geospatial databases and ellipses need to be converted into
polygons anyway to make geospatial queries.

Cheers,
Kalle Kuismanen
Fairspectrum

---

From: <[email-masked]>
Date: Wed, 13 Mar 2013 19:54:29 +0000

One of the authors of the cited RFC was kind enough to respond to this email, and I am forwarding his mail:

From: ext Martin Thomson [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 6:43 AM

Suggestions of this nature are extremely common.  After all, there are very many standardized representations of location.  I'd be surprised if you haven't already had suggestions for GeoJSON, KML, 3GPP TS 23.032, or one of the many other commonly used serializations of location.  WKT is very much unsurprising.

The problem with WKT is that it was developed with SQL in mind.  It's a structured textual format.  That means that processors are required to understand the parsing rules in order to extract the information they need.  Use of WKT in paws would require considerable effort to properly profile the format.  Any advantage gained by those who are implementing with GIS databases is far outweighed by the cost to those implementations that consume the information.

I haven't been tracking paws, so I was encouraged to see that the handling of location was largely sensible and pragmatic.  In the complexity/value trade-off, I might have chosen circle over ellipse, though ellipse is clearly valuable to the extent that it is the natural product of a GPS trilaterator and a good fit for a cell sector coverage area.

Reading through the paws protocol draft, the following jumped out at me:

   confidence:  The location confidence level, as an integer percentage,

      MAY be required, depending on the regulatory domain.  When the

      parameter is optional, its default value is 100.  This values is

      only meaningful when GeoLocation refers to a point.

100 is an invalid value for confidence.  Confidence is an estimate of the probability that the provided uncertainty region includes the measurand.  Claiming a probability of 1 for confidence is never possible in practice.

Setting the value to 100 by default is actually nonsensical.  95 might be a better default if you care about RFC 4119/5985 interactions.  67 would be a better fit for what most GPS trilaterators produce.

That last sentence is directly wrong.  Assuming point positioning, it's never possible to have any more than zero confidence in an estimate that does not have uncertainty.

I was somewhat surprised to see confidence in the draft.  We didn't add it to RFC 5491 because it isn't well understood and it makes things like comparisons difficult.  It's not actually possible, without making assumptions, to compare locations that have different confidence values.

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Kalle Kuismanen
Sent: Tuesday, March 12, 2013 7:22 PM
To: [email-masked]
Subject: [paws] PAWS Location info using RFC5491

Hello everybody,

First of all, thank you for interesting presentations in Orlando, I hope weather was bit warmer than here in Finland where I was doomed to watch them.

I'm not sure how much discussion you've had on the method used to describe location in this draft. So I apologize in advance if this issue is closed.

This draft of PAWS protocol uses JSON syntax, but RFC5491, which is used to describe location is XML based protocol.
This causes a problem for us implementers, because this hybrid loses
unambiguity i.e. I cannot verify the location entries against json-schema because it doesn't exist.

As an alternative I think something like following would be useful as a replacement or an alternative.

Most implementations of geospatial databases understand ISO/IEC 13249-3:2011 WKT and BKT format for geometric representations and there are a lot of ready made code to handle it.

so instead of
"location": {
 "point": {

one could enter

"location": {

Advantage of this is that since WKT and WKB are understood by most geospatial databases there is very little parsing to do, validation is trivial and as a bonus it can be directly entered as a part of a query. Protocol covers other geometric shapes.

It doesn't cover ellipse though, but then again it's not very common feature in geospatial databases and ellipses need to be converted into polygons anyway to make geospatial queries.

Cheers,
Kalle Kuismanen
Fairspectrum

---

From: Vincent Chen <[email-masked]>
Date: Wed, 13 Mar 2013 13:35:48 -0700

Thanks to Martin for the clarifications.

RE: confidence

 - It is included, because some regulators have defined the confidence
level to use for specifying location uncertainty. This parameter was
included to allow for possible variations amongst different regulators.

 - As for the default value for confidence, 95 may indeed be a better
default, if there are no objections on the list.

 - For the PAWS protocol, we are allowing a location to be specified as a
"point" (with uncertainty) or "region", so the last sentence is only
distinguishing between these two options, rather than a physical "point". I
can clarify the language.

On Wed, Mar 13, 2013 at 12:54 PM, <[email-masked]> wrote:

>  One of the authors of the cited RFC was kind enough to respond to this
> email, and I am forwarding his mail:****
>
> ** **
>
> ** **
>
> ****
> Suggestions of this nature are extremely common.  After all, there are
> very many standardized representations of location.  I'd be surprised if
> you haven't already had suggestions for GeoJSON, KML, 3GPP TS 23.032, or
> one of the many other commonly used serializations of location.  WKT is
> very much unsurprising.****
>
> ** **
>
> The problem with WKT is that it was developed with SQL in mind.  It's a
> structured textual format.  That means that processors are required to
> understand the parsing rules in order to extract the information they
> need.  Use of WKT in paws would require considerable effort to properly
> profile the format.  Any advantage gained by those who are implementing
> with GIS databases is far outweighed by the cost to those implementations
> that consume the information.****
>
> ** **
>
> I haven't been tracking paws, so I was encouraged to see that the handling
> of location was largely sensible and pragmatic.  In the complexity/value
> trade-off, I might have chosen circle over ellipse, though ellipse is
> clearly valuable to the extent that it is the natural product of a GPS
> trilaterator and a good fit for a cell sector coverage area.****
>
> ** **
>
> Reading through the paws protocol draft, the following jumped out at me:**
> **
>
> ** **
>
>    confidence:  The location confidence level, as an integer percentage,**
> **
>
>       MAY be required, depending on the regulatory domain.  When the****
>
>       parameter is optional, its default value is 100.  This values is****
>
>       only meaningful when GeoLocation refers to a point.****
>
> ** **
>
> 100 is an invalid value for confidence.  Confidence is an estimate of the
> probability that the provided uncertainty region includes the measurand.
> Claiming a probability of 1 for confidence is never possible in practice.*
> ***
>
> ** **
>
> Setting the value to 100 by default is actually nonsensical.  95 might be
> a better default if you care about RFC 4119/5985 interactions.  67 would be
> a better fit for what most GPS trilaterators produce.****
>
> ** **
>
> That last sentence is directly wrong.  Assuming point positioning, it's
> never possible to have any more than zero confidence in an estimate that
> does not have uncertainty.****
>
> ** **
>
> I was somewhat surprised to see confidence in the draft.  We didn't add it
> to RFC 5491 because it isn't well understood and it makes things like
> comparisons difficult.  It's not actually possible, without making
> assumptions, to compare locations that have different confidence values.**
> **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *ext Kalle Kuismanen
> *Sent:* Tuesday, March 12, 2013 7:22 PM
> *To:* [email-masked]
> *Subject:* [paws] PAWS Location info using RFC5491****
>
> ** **
>
> Hello everybody,****
>
> ** **
>
> them.****
> ** **
> ****
> ** **
> This draft of PAWS protocol uses JSON syntax, but RFC5491, which is used
> to describe location is XML based protocol. ****
>
> This causes a problem for us implementers, because this hybrid loses ****
>
> because it doesn't exist.****
>
> ** **
>
> replacement or an alternative.****
>
> ** **
>
> 13249-3:2011 WKT and BKT format for geometric representations and there
> are a lot of ready made code to handle it.****
>
> ** **
>
> http://en.wikipedia.org/wiki/Well-known_text#Well-known_binary****
>
> ** **
>
> so instead of ****
>
> "location": {****
>
>  "point": {****
>
>  "center": {"latitude": 37.0005, "longitude": -101.3005}****
>
>  } }****
>
> ** **
>
> one could enter****
>
> ** **
>
> "location": {****
>
>  "wkt": "POINT (101.3005 37.0005)",****
>
>  "srid":4326 }****
>
> ** **
>
> or WKB equivalent. Just a note: (srid 4326 is the id for WGS84)****
>
> ** **
>
> Protocol covers other geometric shapes.****
>
> ** **
>
> polygons anyway to make geospatial queries.****
>
> ** **
>
> Cheers,****
>
> Kalle Kuismanen****
>
> Fairspectrum****
>
> ** **
>
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>
>

-- 
-vince

---

From: Kalle Kuismanen <[email-masked]>
Date: Thu, 14 Mar 2013 10:20:00 +0200

Hi all,

Thanks for the clarification. I think it's bit far fetched to say that paws
uses RFC5491. Instead basically paws draft defines the GeoLocation object
in the draft and it is inspired by RFC5491.

One note on Martins response: "Any advantage gained by those who are
implementing with GIS databases is far outweighed by the cost to those
implementations that consume the information."

I don't know if there are any other implementations than the GIS databases
that consume the information. Since WS database pretty much has to be a GIS
database of some sort.

Kalle

On Wed, Mar 13, 2013 at 10:35 PM, Vincent Chen <[email-masked]> wrote:

>> I haven't been tracking paws, so I was encouraged to see that the
>> handling of location was largely sensible and pragmatic.  In the
>> complexity/value trade-off, I might have chosen circle over ellipse, though
>> ellipse is clearly valuable to the extent that it is the natural product of
>> a GPS trilaterator and a good fit for a cell sector coverage area.****
>>
>> ** **
>>
>> Reading through the paws protocol draft, the following jumped out at me:*
>> ***
>>
>> ** **
>>
>>    confidence:  The location confidence level, as an integer percentage,*
>> ***
>>
>> Claiming a probability of 1 for confidence is never possible in practice.
>> ****
>>
>> ** **
>>
>> I was somewhat surprised to see confidence in the draft.  We didn't add
>> it to RFC 5491 because it isn't well understood and it makes things like
>> assumptions, to compare locations that have different confidence values.*
>> ***
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> I'm not sure how much discussion you've had on the method used to
>> describe location in this draft. So I apologize in advance if this issue is
>> closed.****
>>
>> ** **
>>