RE: [Geopriv] Question on draft-linsner-geopriv-relativeloc-01

From: Brian Rosen ^lt;br@brianrosen.net>
Date: Thu Jul 19 2007 - 16:46:11 EDT

Okay, but I think you would have to say that this rule applies unless the
application specifically says it doesn't.

The problem is dual conversion using different databases.

Suppose I measure a geo, convert to a civic and send it to you.
Suppose you convert to geo and don't use the same database I have.

The error can be VERY significant. So, unless you know that conversion can
never happen at the other end, or you know that the same conversion database
will be used, you should not convert.

Brian

> -----Original Message-----
> From: Rohan Mahy [mailto:rohan.mahy@gmail.com]
> Sent: Thursday, July 19, 2007 4:34 PM
> To: Brian Rosen
> Cc: Marc Berryman; Winterbottom, James; creed@opengeospatial.org; Marc
> Linsner; peter_blatherwick@mitel.com; Geopriv
> Subject: Re: [Geopriv] Question on draft-linsner-geopriv-relativeloc-01
>
> Hi Brian,
>
> I think that's a fine rule for emergency applications. I don't think
> that rule will necessarily apply for all other applications however.
>
> thanks,
> -rohan
>
>
> On 7/12/07, Brian Rosen <br@brianrosen.net> wrote:
> > Nice response.
> >
> > May I summarize?
> >
> > NEVER CONVERT, EVER. If the original way the location was determined
> > yielded a civic, send the civic. If the original location was measured
> and
> > yielded a geo, send the geo. Never, ever, convert.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Marc Berryman [mailto:MBerryman@911.org]
> > > Sent: Thursday, July 12, 2007 8:12 AM
> > > To: Winterbottom, James; Brian Rosen; creed@opengeospatial.org; Marc
> > > Linsner; peter_blatherwick@mitel.com
> > > Cc: Geopriv
> > > Subject: RE: [Geopriv] Question on draft-linsner-geopriv-relativeloc-
> 01
> > >
> > > James,
> > > I think your response of, " personally don't want to see X,Y and Z
> > > conflated into a civic address for reasons I have previously stated "
> is
> > > a valid response, but the interpretation of the points I was trying to
> > > make were somehow missed. We are on the same page here, so let me try
> to
> > > clarify.
> > >
> > > I (too) do not want any application, software, or anything else to
> > > conflate an x, y, z location into a civic address. The converting of
> any
> > > coordinate received at the PSAP should always be the responsibility of
> > > the Dispatching Agency making an informed decision to convert the
> > > location into a local address for dispatching.
> > >
> > > My fire, police, and EMS will only respond to a dispatchable address,
> an
> > > address that is (usually) in a civic form. Ask the local EMS to roll
> on
> > > 23.75467, -95.3452, 101 meters, and you will get run out of the
> dispatch
> > > center, give them 123 S Main St, 4th floor, and they will roll.
> > >
> > > There must be a human element involved, at the local level, a person
> who
> > > is very familiar with the local geography, to make the determination
> > > that 23.75467, -95.3452, 101 meters is the 4th floor of a building at
> > > 123 S Main St, rather than the adjacent highway overpass. We have run
> > > into issues in the past with coordinates being converted into
> incorrect
> > > local addresses by some software, which lead to delayed response and a
> > > quick change of policy.
> > >
> > > If a device or a call has a location of x, y, and z, I want the same
> x,
> > > y, and z delivered to the PSAP. I do not trust any "transformation,
> > > conversion, conflation, or guessing" of that location into any type of
> > > civic address.
> > >
> > > I want my dispatchers to take the x, y, and z coordinates, and using
> my
> > > local (and constantly updated) spatial data make a local and informed
> > > determination of how to take the x, y, and z location and provide the
> > > responding agency a location which they can be dispatched too.
> > >
> > > The point that started this thread was there are several operational
> and
> > > educational issues that play a part in this. Highly accurate local
> > > spatial data, that includes MSL elevation data, and training the end
> > > users (the dispatchers in this case) how to use this information to
> > > provide the proper response to the proper location. This is out of
> scope
> > > of the work we are doing here, but should always be kept in the back
> or
> > > our minds.
> > >
> > > Thanks,
> > > Marc
> > >
> > > -----Original Message-----
> > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> > > Sent: Wednesday, July 11, 2007 7:23 PM
> > > To: Marc Berryman; Brian Rosen; creed@opengeospatial.org; Marc
> Linsner;
> > > peter_blatherwick@mitel.com
> > > Cc: Geopriv
> > > Subject: RE: [Geopriv] Question on draft-linsner-geopriv-relativeloc-
> 01
> > >
> > > I personally don't want to see X,Y and Z conflated into a civic
> address
> > > for reasons I have previously stated. Measurements from wifi devices,
> > > particularly if they are directional will be associated to the
> > > orientation of the WAP, are we going to add orientation in there too?
> > > Once we start down this road, where do we stop?
> > >
> > > I remain totally unconvinced that the same functionality cannot be
> > > expressed by using a compound location which subsequently offers a far
> > > greater degree of flexibility for other applications. I specifically
> > > asked how the use-case provided for the above draft was not addressed
> by
> > > a compound solution and in my previous email on this topic and it was
> > > very carefully ignored.
> > >
> > > The problem being described is a general one, not a specific one, and
> it
> > > requires a general solution.
> > >
> > > Cheers
> > > James
> > >
> > > > -----Original Message-----
> > > > From: Marc Berryman [mailto:MBerryman@911.org]
> > > > Sent: Wednesday, 11 July 2007 9:53 PM
> > > > To: Brian Rosen; creed@opengeospatial.org; Marc Linsner;
> > > > peter_blatherwick@mitel.com
> > > > Cc: Geopriv
> > > > Subject: RE: [Geopriv] Question on
> > > draft-linsner-geopriv-relativeloc-01
> > > >
> > > > No, of course not.
> > > > The z-value is an very big part of the next "big" step in improving
> > > > emergency response. We must have the z-value, do not even consider
> > > > removing it!
> > > >
> > > > All I am saying is we need to get the message out to the vendors and
> > > the
> > > > local 9-1-1 authorities that they need to start thinking and
> > > developing
> > > > data and applications that can make use of the z-value.
> > > >
> > > > This falls into the education and operations side of the picture,
> that
> > > > is the point I was trying to get across.
> > > >
> > > > Marc B
> > > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > > Sent: Wednesday, July 11, 2007 6:48 AM
> > > > To: Marc Berryman; creed@opengeospatial.org; 'Marc Linsner';
> > > > peter_blatherwick@mitel.com
> > > > Cc: 'Geopriv'
> > > > Subject: RE: [Geopriv] Question on
> > > draft-linsner-geopriv-relativeloc-01
> > > >
> > > > Okay, but the standard definitely wants to define z, and
> > > implementations
> > > > should be encouraged to provide z, and the PSAPs should start
> > > gathering
> > > > z
> > > > data, and their next equipment purchase should be capable of using
> it,
> > > > right?
> > > >
> > > > You wouldn't want us to drop the z from the spec would you? You are
> > > > just
> > > > pointing out that we have implementation work on both sides of an
> > > > emergency
> > > > call to use it.
> > > >
> > > > And of course PIDF-LO will be used for applications other than
> > > emergency
> > > > call where z is already used and important.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Marc Berryman [mailto:MBerryman@911.org]
> > > > > Sent: Wednesday, July 11, 2007 7:39 AM
> > > > > To: creed@opengeospatial.org; Marc Linsner;
> > > > peter_blatherwick@mitel.com
> > > > > Cc: Geopriv
> > > > > Subject: RE: [Geopriv] Question on
> > > > draft-linsner-geopriv-relativeloc-01
> > > > >
> > > > > Good point Carl. As I am sure you are well aware, the preferred
> > > datum
> > > > in
> > > > > the newer NENA specs is WGS 84. I agree that any value for z
> should
> > > be
> > > > > height above MSL, which brings up other issues on a local scale.
> > > > >
> > > > > If we have a x, y, and z location, then we must be willing to
> assume
> > > > > several things, namely:
> > > > > The local geography, the structures, street centerlines,
> > > > jurisdictional
> > > > > boundaries, and elevations must be very accurate and precise;
> > > > > The ability to quickly determine the location, in the form of a
> > > civic
> > > > > address that is used in dispatch, must be readily determined, and;
> > > > > The location of the floor, in the case of a multi-story building,
> > > must
> > > > > be able to be readily determined based on the MSL and the
> elevation
> > > > > above the floors above the referenced elevation.
> > > > >
> > > > > I dare say that, at least in my case, the x, and y is not a
> problem,
> > > > but
> > > > > the ability to determine the location of the z value in the form
> of
> > > > say
> > > > > the 3rd floor, is not (yet) part of our data structure.
> > > > >
> > > > > I think this brings to light several operational issues (we will
> set
> > > > > aside the accuracy of any z values for this argument). One issue
> is
> > > > that
> > > > > the MSL of an area is not part of the normal database structure
> > > within
> > > > > the local emergency services operations. The other main issue
> being
> > > > that
> > > > > most of todays CAD and Mapped-ALI systems can not calculate the
> > > local
> > > > > elevation of a given Z- value above local MSL for a given x and y
> > > > > coordinate (Local Elevation = Z - MSL), and then convert this
> value
> > > > into
> > > > > a floor based on the building that the x and y is referencing.
> > > > >
> > > > > Just thought I would toss that out for consideration,
> > > > > Marc B
> > > > >
> > > > > Marc Berryman, ENP
> > > > > Geographic Information Systems
> > > > > Greater Harris County 9-1-1 Emergency Network
> > > > > Houston, Texas (713) 407-2254
> > > > > mberryman@911.org
> > > > >
> > > > > -----Original Message-----
> > > > > From: creed@opengeospatial.org [mailto:creed@opengeospatial.org]
> > > > > Sent: Wednesday, July 11, 2007 2:42 AM
> > > > > To: Marc Linsner; peter_blatherwick@mitel.com
> > > > > Cc: Geopriv
> > > > > Subject: Re: [Geopriv] Question on
> > > > draft-linsner-geopriv-relativeloc-01
> > > > >
> > > > > Perhaps the semantics for the expression of a z value should be
> > > > grounded
> > > > > in geodesy best practices, such as feet above mean sea level. MSL
> is
> > > > > defined as the zero elevation for a local area. The zero surface
> > > > > referenced by elevation is called a vertical datum. An alternative
> > > is
> > > > to
> > > > > base height measurements on an ellipsoid of the entire earth,
> which
> > > is
> > > > > what systems such as GPS do. In aviation, the ellipsoid known as
> > > World
> > > > > Geodetic System 84 is increasingly used to define mean sea level.
> > > > >
> > > > > Just a thought. We need to insure that the definition used in the
> > > > > document
> > > > > is unambiguous.
> > > > >
> > > > > Regards
> > > > >
> > > > > Carl
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: peter_blatherwick@mitel.com
> > > > > To: Marc Linsner
> > > > > Cc: Geopriv
> > > > > Sent: Friday, July 06, 2007 1:16 PM
> > > > > Subject: [Geopriv] Question on draft-linsner-geopriv-relativeloc-
> 01
> > > > >
> > > > >
> > > > >
> > > > > Hi Marc, list,
> > > > >
> > > > > First, I find this draft to be marginally useful. There will be
> > > some
> > > > > cases where such relative offsets are helpful, but I expect not
> too
> > > > > many.
> > > > >
> > > > > That said, I have a comment/question on Z dimmension. Sec 4 sez:
> > > > > "If the altitude (Z) parameter is expressed, it is assumed
> > > to
> > > > > utilize locally significant ground level (the ground directly
> > > below
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Geopriv mailing list
> > > > > Geopriv@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/geopriv
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Geopriv mailing list
> > > > > Geopriv@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/geopriv
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Geopriv mailing list
> > > > Geopriv@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/geopriv
> > >
> > > ----------------------------------------------------------------------
> --
> > > ------------------------
> > > 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
> > Geopriv@ietf.org
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 19 Jul 2007 16:46:11 -0400

This archive was generated by hypermail 2.1.8 : Thu Jul 19 2007 - 16:46:28 EDT