RE: [Geopriv] ResponseTime

From: Dawson, Martin ^lt;>
Date: Tue Aug 28 2007 - 19:05:31 EDT

Nope - but better than just using the point. Nice to agree on something. Gee - I didn't realize I wasn't trying to understand. Maybe you're saying that experience is relevant in making a decision? Hard to tell. Anyhow, I still think that the use of geo-location will become more sophisticated over time. You might not call it "wrestling" - gosh, it's a metaphor, I didn't think it had a terribly specific interpretation. I very much doubt that the procedures, understanding, and infrastructure associated with reported location is now cast in stone. Cheers, Martin ________________________________ From: Brian Rosen [] Sent: Wednesday, 29 August 2007 8:40 AM To: Dawson, Martin; Stuard, Doug; 'Roger Marshall';; Winterbottom, James Cc: 'GEOPRIV' Subject: RE: [Geopriv] ResponseTime Martin I've spent a bunch of time on this trying to understand what is going on. You might try doing the same. There certainly are people out there in PSAP land who don't understand what confidence and uncertainty mean: they tie them together in "error". However, you will note that EVERYONE says the same thing: "within 100M 95% of the time" for example. That is confidence and uncertainty. They really do get it. They ignore confidence completely in the app. They mostly ignore uncertainty. That's the truth. For the folks who really understand these things, it's not ignorance; they don't have anything useful they can do with the information. Every caller is questioned about location the same way; they don't change their questions based on uncertainty. Is probably is more due to the fact that there is less variation in emergency calling because there are government mandates, but the reality is they ignore it. There isn't any wrestling because they all do it the same way. There isn't a request for feature enhancements on their CPE or CAD system vendor's list. They have a single standard (well, it's two standards) and that's the end of the story. Again, they really truly understand what the values mean. They don't see any way to actually use them. Worse, I talked to some commercial LBS app vendors and THEY IGNORE THE VALUE TOO. I have yet to find anyone that uses confidence. The only use I have seen for uncertainty is display, and as I said, most people turn it off. I actually agree with you on routing. At the moment, we're in the minority. Given a choice, most KNOWLEDGEABLE people would still choose the center point and route on that. I have some hope we can use uncertainty in routing. I have no hope for any use for confidence. Note that if I change confidence to a higher value, likely I will expand the size of your circle. That would change routing of course, but the confidence VALUE is completely ignored; only the uncertainty is useful. Of course, for routing, I do in fact want a high confidence, and the consequent higher uncertainty. If I choose a route based on a really small uncertainty, but it's wrong half the time, I don't do very well, do I? Brian ________________________________ From: Dawson, Martin [] Sent: Tuesday, August 28, 2007 5:59 PM To: Brian Rosen; Stuard, Doug; Roger Marshall;; Winterbottom, James Cc: GEOPRIV Subject: RE: [Geopriv] ResponseTime I don't quite get that... on the one hand the message is that uncertainty should be provided at 90% but, on the other hand, the message is that uncertainty is not even considered or used. Typically a location with an ellipse of uncertainty will have the same center. The ellipse will just be bigger for greater confidence. If all that's looked at is the center, then why does it matter what the confidence is? I think PSAPs are only just learning how to use geodetic location information. Procedures haven't really started to be optimized yet. If you get an area of uncertainty at 90% confidence, then the correct interpretation is that there is a 90% chance of the caller being somewhere within that area. No one point within that area is more likely than any other point in that area; in particular, there is nothing special about the center. However every point in the area is nine times more likely to be correct than every point outside that area. So - if I was asking my caller for observations pertaining to their location (nature of the structures, landscape etc) then I'd be best advised to look for a correlation with their observations with GIS information pertaining to the geography within that area of uncertainty. I certainly shouldn't be focussing my attention on the center of the uncertainty and I should probably give 90% of my attention to all the points within the area of uncertainty at least initially before looking outside that area. Procedurally, the same sort of thinking should apply to a structured on-the-ground search for dispatch based on the area of uncertainty returned. Your opinion below doesn't resonate well with the opinion that there isn't "wrestling" going on. What's the rationale for dispatching to the "point"? For a real-world application of uncertainty, the routing problem should be considered. If I have an area of uncertainty at 90% confidence overlaid on three routing area borders, then I have a better chance of getting the routing right if I pick the route that most of the area of uncertainty lies within. This is particularly emphasised where the center of the uncertainty may actually lie in the route that only has a tiny fraction of the area of uncertainty overlaid on it. E.g. given the following area of uncertainty at 90% confidence, which is the best destination zone to route to? Cheers, Martin ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2]

Geopriv mailing list

Received on Tue, 28 Aug 2007 18:05:31 -0500

This archive was generated by hypermail 2.1.8 : Tue Aug 28 2007 - 19:15:36 EDT