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
