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 protected]> wrote: > 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
