Subject: RE: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26

From: "Roger Marshall" <[email-masked]>
Date: Thu, 31 Mar 2005 11:10:41 -0800

Don't neglect other valid "non city" contexts, such as unplotted
agricultural fields, roads, and out-buildings, mountain slopes, and
desert expanses.  Each of these could be modeled the same as open water,
except the added component of elevation becomes more important.

I agree that early (geo or reverse geo) conversion requires some sort of
flag stating that one's a derivation, rather than a measurement.  Both
location systems (civic & geo) are not equivalent, geodetic is a general
solution, whereas civic is only valid within a specific context (e.g.
improved areas within North America).

The bigger problem is as Brian stated, "how you route the call",
especially in the context of mobility.  If we can solve mobility, then
static and nomadic solutions fall out more easily.  

Here's an example use case: Let's say a caller is mobile, and initiates
a call while in transit.  Either one of two things is true, either the
lat/lon used for routing is stale (was measured some prior point in
time), or the call takes ~15s to initiate, since a "current" lat/lon
must be generated.  If I was drifting as sea, with nothing else to do, I
may put up with a 15 second delay, although neither is optimal.

Until GPS fixes are obtainable in the sub-second range, a more practical
solution is required to support mobility - one in which routing is done
quickly (sub-second), and is done based on context appropriate location
information, such as an AP location (WiFi), serving tower location
(2-3G), etc.  To do this requires a location infrastructure, even for
devices with GPS inside.

Roger Marshall

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: Thursday, March 31, 2005 10:05 AM
To: 'Michael Hammer (mhammer)'; 'Mark Scharaga'; [email-masked]
Subject: RE: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26

Yes.  I have always thought that "responder" is a much wider group of
agencies than police/fire/ems, and it's true that coast guard, and
mountain
rescue would be very happy to be dispatched to GPS coordinates.
Fire/rescue
boat is an interesting case.  The boats undoubtedly have GPS.  The
systems
that dispatch them can't, at present, deal with geo, but that is
changing.

"Non city" doesn't compute.  Even in the most rural environment, police,
fire and ems dispatch is to a civic address.  

This is all beyond the problem at hand, which is how do you route the
call.
I think we're agreeing that you route with the original (most accurate)
form
of the location, whatever that is.  If you happen to have a converted
version, and you want to send that, fine, as long as you mark it as
such.
The PSAP may have to be able to convert, both from geo to civic and from
civic to geo, but that is beyond ecrit scope.

Brian

> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Thursday, March 31, 2005 12:48 PM
> To: Brian Rosen; Mark Scharaga; [email-masked]
> Subject: RE: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26
> 
> Brian,
> 
> I agree with your no-conversion stance, but you need to take non-city
> situations into account.  And there may also be various forms of
> emergency service, e.g. fire/rescue boat, that aren't constrained to
> streets.
> 
> Mike
> 
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]
> >On Behalf Of Brian Rosen
> >Sent: Wednesday, March 30, 2005 8:46 PM
> >To: 'Mark Scharaga'; [email-masked]
> >Subject: RE: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26
> >
> >Chairs may decide this thread is no longer in scope.
> >
> >Mark
> >
> >Please tell me how you expect a fire truck to be dispatched to
> >a lat/lon.
> >It's possible to tell them to go to 1/2 mile north of some
> >cross street on some other street, but you don't give them a lat/lon.
> >
> >When a call taker answers a call, one of the first things they
> >ask you, besides what is wrong, is where you are.  You don't
> >read off your GPS coordinates.  They don't insist on a street
> >number, but they are looking at a map that has street numbers
> >marked on it, and they often have software that is showing the
> >"closest" address to the reported lat/lon.  They have to enter
> >a street address into their systems in one way or another.
> >
> >The coordinates are not "more important".  They are probably
> >more accurate than any conversion from lat/lon to civic,
> >because you can't add accuracy with a conversion, you can only
> >decrease accuracy.  This is why I don't like conversion.
> >Sometimes, as with dispatch, you need to convert.
> >
> >The rule I like is "send whatever the original data was
> >determined".  If the data was originally measured, as with
> >GPS, then send geo.  If the data was originally entered as a
> >street address, send a civic.  If you have some converted data
> >also, send that, but mark it as converted from the other form
> >and send the original first.  NEVER convert, and send only the
> >converted data.  Don't assume you know what the other end needs.
> >
> >Brian
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]]
> >On Behalf
> >> Of Mark Scharaga
> >> Sent: Wednesday, March 30, 2005 5:55 PM
> >> To: [email-masked]
> >> Subject: [Ecrit] Re: Ecrit Digest, Vol 2, Issue 26
> >>
> >> Folks,
> >>
> >> A large number of PSAPs use mapping and CAD systems to
> >display closest
> >> route and streets to a location. THe dispatcher has to make the
> >> determination if that information is correct, as there are
> >times (more
> >> often in rural areas) where the actual caller maybe on a
> >lake or river
> >> and the closest road could be miles away.
> >>
> >> THe coordinates of the caller are actually more important than the
> >> physical street address. However, in the traditional landline call
> >> scenario the PSAP uses the street address and whatever info they
can
> >> get from the caller to make the proper unit responses occur. With
> >> mobile callers most mapping systems display the actual
> >location of the
> >> caller, not resolved to the closest location. There are some
systems
> >> that do try to resolve the coordinates to an actual street address.
> >> During my career I strongly advised against any system that did
this
> >> due to probability of error.
> >>
> >> Mark
> >>
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/ecrit
> >>
> >
> >
> >
> >
> >_______________________________________________
> >Ecrit mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/ecrit
> >
> 

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Mark Scharaga" <[email-masked]>
Date: Thu, 31 Mar 2005 14:40:48 -0500

In the current wireless call delivery structure the 
carriers use a class of service field to denote the 
service the PSAP is receiving on that call. This tells the 
dispatcher that the call is either phase 0, I or II and 
may or may not be "rebid" or "redipped" for the LAT/LON 
coordinates.  Maybe there should be a similar method or 
action for GEO or Civic?

Mark Scharaga
President- Maxim Technology Solutions
www.maximtsc.com
888-288-3059 X101

On Thu, 31 Mar 2005 11:10:41 -0800 "Roger Marshall" 
<[email-masked]> wrote:

> Don't neglect other valid "non city" contexts, such as 
>unplotted agricultural fields, roads, and out-buildings, mountain 
>slopes, and desert expanses.  Each of these could be modeled the 
>same as open water, except the added component of elevation becomes more important.

I agree that early (geo or reverse geo) conversion
requires some sort of flag stating that one's a 
derivation, rather than a measurement.  Both location 
systems (civic & geo) are not equivalent, geodetic is a 
generalsolution, whereas civic is only valid within a 
specific  context (e.g. improved areas within North 
America).
  
  The bigger problem is as Brian stated, "how you route
the call", especially in the context of mobility.  If we 
can solve mobility, then static and nomadic solutions fall 
out more easily.
Here's an example use case: Let's say a caller is mobile, 
and initiates a call while in transit.  Either one of two 
things is true, either the lat/lon used for routing is 
stale (was measured some prior point in time), or the call 
takes ~15s to initiate, since a "current" lat/lon must be 
generated.  If I was drifting as sea, with nothing else to 
do, I may put up with a 15 second delay, although neither 
is optimal.
  
Until GPS fixes are obtainable in the sub-second range,
a more practical solution is required to support mobility 
- one in which routing is done quickly (sub-second), and 
is done based on context appropriate location information, 
such as an AP location (WiFi), serving tower location 
(2-3G), etc.  To do this requires a location 
infrastructure, even for devices with GPS inside.
  
Roger Marshall

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 31 Mar 2005 14:04:54 -0600

Mark

The CoS field is populated by "the network" in the wireless case, correct?

This field would be in the PIDF-LO message body (part) in the SIP INVITE, 
which is not modified by "the network" in transit to the PSAP, so how/why 
would you trust the endpoint to enter the right field value?

At 02:40 PM 3/31/2005 -0500, Mark Scharaga wrote:
>In the current wireless call delivery structure the carriers use a class 
>of service field to denote the service the PSAP is receiving on that call. 
>This tells the dispatcher that the call is either phase 0, I or II and may 
>or may not be "rebid" or "redipped" for the LAT/LON coordinates.  Maybe 
>there should be a similar method or action for GEO or Civic?
>
>
>Mark Scharaga
>requires some sort of flag stating that one's a derivation, rather than a 
>measurement.  Both location systems (civic & geo) are not equivalent, 
>geodetic is a generalsolution, whereas civic is only valid within a 
>specific  context (e.g. improved areas within North America).
>
>the call", especially in the context of mobility.  If we can solve 
>mobility, then static and nomadic solutions fall out more easily.
>Here's an example use case: Let's say a caller is mobile, and initiates a 
>call while in transit.  Either one of two things is true, either the 
>lat/lon used for routing is stale (was measured some prior point in time), 
>or the call takes ~15s to initiate, since a "current" lat/lon must be 
>generated.  If I was drifting as sea, with nothing else to do, I may put 
>up with a 15 second delay, although neither is optimal.
>
>a more practical solution is required to support mobility - one in which 
>routing is done quickly (sub-second), and is done based on context 
>appropriate location information, such as an AP location (WiFi), serving 
>tower location (2-3G), etc.  To do this requires a location 

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented