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 protected]> wrote: > 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 protected]] > 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 protected] [mailto:[email protected]] *On Behalf > Of *ext Kalle Kuismanen > *Sent:* Tuesday, March 12, 2013 7:22 PM > *To:* [email protected] > *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.**** > > ** ** > > 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**** > > ** ** > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws > > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
