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

From: Winterbottom, James ^lt;James.Winterbottom@andrew.com>
Date: Wed Jul 11 2007 - 20:23:29 EDT

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
Received on Wed, 11 Jul 2007 19:23:29 -0500

This archive was generated by hypermail 2.1.8 : Wed Jul 11 2007 - 20:23:41 EDT