|
|
Three quick comments:
As far as I know, GPS devices produce a point plus (small)
uncertainty, e.g., in the common NMEA output format (http://vancouver-
webpages.com/peter/nmeafaq.txt). The uncertainty is so small and
tends to fluctuate so much that including it in location mapping is
pretty pointless, and it's probably of dubious value even for
dispatch. (When I went geocaching recently with my kids, uncertainty
on a modern SiRF-based device was around 18 - 25', under dense tree
cover.)
That said, I think the complexity of including circles, arc band and
ellipse is minimal. In all cases, the description includes a center
point, which the LoST machinery could easily use to do the actual
lookup. Thus, the additional complexity is mainly parsing these XML
structures, which strikes me as not a big deal.
What gets complex is if a LoST resolver is forced to map shapes to
multiple branches of the tree, what we have discussed in the past as
the "forking" problem. For example, if a geo shape straddles the
boundary between the US and Canada, you really don't want the LoST
resolver gather results from both trees, decide how long it needs to
wait for one or the other, and other issues. This requires
significantly more protocol work, creates additional error conditions
and increases implementation complexity.
A third point relates more to HELD than LoST: It's probably a good
idea to be able to request a specific location profile, in the same
spirit as in LoST, so that if newer, complex shapes can be
accommodated easily in the future. We can then decide whether to
define a LoST-like profile for HELD that only includes the current
geo shapes, without endangering interoperability.
In summary: I'm not opposed to including the three additional shapes,
as long as it is clear that the LoST server MAY use the center point
for mapping.
Henning
On Jul 11, 2007, at 6:58 AM, Hannes Tschofenig wrote:
For GPS usage at the end host only you are certainly right that
circles & ellipse is a good choice. The big question is here:
* is it a big issue to translate them to a point
* does it introduce big error rates
Please also note that we are talking about emergency call routing
in the context of LoST and not about dispatch. To approximate a
circle with a radius of 3 meters with a point might not be a big
problem.
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|