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

From: [email-masked]
Date: Wed, 11 Jul 2007 03:42:11 -0400 (EDT)

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: [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Marc Berryman" <[email-masked]>
Date: Wed, 11 Jul 2007 06:38:55 -0500

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
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 11, 2007 2:42 AM
To: Marc Linsner; [email-masked]
Cc: Geopriv
Subject: Re: [Geopriv] Question on draft-linsner-geopriv-relativeloc-01

Just a thought. We need to insure that the definition used in the
document
is unambiguous.

Regards

Carl

----- Original Message -----
From: [email-masked]
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.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 11 Jul 2007 07:47:54 -0400

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

> From: Marc Berryman [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2007 7:39 AM
> To: [email-masked]; Marc Linsner; [email-masked]
> Cc: Geopriv
> Subject: RE: [Geopriv] Question on draft-linsner-geopriv-relativeloc-01
>

---

From: "Marc Berryman" <[email-masked]>
Date: Wed, 11 Jul 2007 06:52:41 -0500

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:[email-masked]] 
Sent: Wednesday, July 11, 2007 6:48 AM
To: Marc Berryman; [email-masked]; 'Marc Linsner';
[email-masked]
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.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 11 Jul 2007 19:23:29 -0500

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

> Sent: Wednesday, 11 July 2007 9:53 PM
> To: Brian Rosen; [email-masked]; Marc Linsner;
> > Good point Carl. As I am sure you are well aware, the preferred
datum
> in
> > referenced by elevation is called a vertical datum. An alternative
is
> to

------------------------------------------------------------------------------------------------
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]

---

From: "Marc Berryman" <[email-masked]>
Date: Thu, 12 Jul 2007 07:12:08 -0500

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:[email-masked]] 
Sent: Wednesday, July 11, 2007 7:23 PM
To: Marc Berryman; Brian Rosen; [email-masked]; Marc Linsner;

Cheers
James

datum
is
> >   utilize locally significant ground level (the ground directly
below

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 12 Jul 2007 16:44:39 -0400

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

> Sent: Thursday, July 12, 2007 8:12 AM
> To: Winterbottom, James; Brian Rosen; [email-masked]; Marc
> Linsner; [email-masked]
> Cc: Geopriv

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 12 Jul 2007 17:13:25 -0500

Hi Marc,

First this is confusing having two Marcs on the same thread... ;)

I am not suggesting converting in any shape or form, and I agree that
current conversion techniques can be problematic and should be avoided.

I am not opposed to the notion of a relative location, I just don't want
both the reference point and the coordinate extension to exist in the
civic schema.

I would like to be able to express the reference point as either a
geodetic point or a civic location. I would like to be able to express
an orientation from the reference for the axies defining the plane in
which the coorindates lie. And finally I would like to be able to use
any of the OGC uom types (or any new measures for that matter), and not
be restricted to simply metres and feet.

All of this could be done quite simply with a compound location type,
and it doesn't muddy the civic location type by adding geodetic
coordinates to it. The end result is that the use-case described in the
above document is addressed, and we have something that can be used in a
general sense too.

Cheers
James 

> Sent: Thursday, 12 July 2007 10:12 PM
> > > the newer NENA specs is WGS 84. I agree that any value for z
should
> be
> > > 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
> > > aside the accuracy of any z values for this argument). One issue
is
> > that
> > > the local emergency services operations. The other main issue
being
> > that
> > > coordinate (Local Elevation = Z - MSL), and then convert this
value
> > into
> > > base height measurements on an ellipsoid of the entire earth,
which

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 13 Jul 2007 10:45:12 -0400

Marc B.,

Let me make an attempt to clear up what I perceive as misconceptions with
respect to this draft.

1) There is no 'conversion' between geo and civic going on here.

2) In this context X, Y, and Z are grid labels with data expressed in feet
or meters, not geo degrees, minutes, seconds.  It's unfortunate that we
humans perform such associations, machines are much better at sorting this
out, the latter will be handling this data >99.999% of the time.  Hence, the
use of different labels might seem appropriate to humans, but labels are
just that, labels.

3) The 'Z' component was added in the 01 version of the draft at the request
of Martin Thomson.  The functionality the authors are proposing has no need
for Z as it has the ability to express the vertical data as floors, which is
an existing tag in the civic schema.  Given the applicability of the
proposal, it's not clear to me the use case for 'Z', but as with all xml
tags, if the receiver doesn't understand, they ignore it, hence we saw no
harm in adding 'Z'.  Future versions of the draft will fix issues with the
datum associated with 'Z'.

4) The current state of technology:  Today you receive a pidf-lo with: US;
IL; Chicago; Main St.; 123; N; 3rd floor.  We are proposing: US; IL;
Chicago; Main St.; 123; N; 3rd floor; refpoint=elevator; 30 feet east; 20
feet south.  BTW, the former is a 'legal 9-1-1' location in the state of
Illinois assuming the 3rd floor is <40,001 sq. ft.  Yes, it would be nice
for the location determination mechanism to cross reference building floor
plans and output a room number, cubicle identity, etc., but this is not
(yet) available with current technology.

5) James Winterbottom has objected to adding these additional tags to the
civic schema, suggesting that a new location type be created instead.

6) Martin Dawson suggested possibly using the existing 'LOC' or 'ADDCODE'
tags to express the reference point and each relative position parameter (as
free flow text?).

7) You appear to be objecting to adding 'degrees, minutes, seconds' type
data to the civic location type.  I hope the above demonstrates that is not
the proposal and your objection is now satisfied.

I hope this helps.

-Marc L.-

> To: Winterbottom, James; Brian Rosen; 
> [email-masked]; Marc Linsner; [email-masked]
> Cc: Geopriv
> 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
> 
> To: Marc Berryman; Brian Rosen; [email-masked]; 
> Marc Linsner; [email-masked]
> Cc: Geopriv
> 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?
> 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
> 
> > just pointing out that we have implementation work on both 
> sides of an 
> > emergency call to use it.
> > 
> > > the newer NENA specs is WGS 84. I agree that any value 
> for z should
> be
> > > boundaries, and elevations must be very accurate and precise; The 
> > > ability to quickly determine the location, in the form of a
> civic
> > > 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
> > > aside the accuracy of any z values for this argument). 
> One issue is
> > that
> > > the local emergency services operations. The other main 
> issue being
> > that
> > > coordinate (Local Elevation = Z - MSL), and then convert 
> this value
> > into
> > > Just thought I would toss that out for consideration,  Marc B
> > >
> > > Marc Berryman, ENP
> > > base height measurements on an ellipsoid of the entire 
> earth, which
> is
> > > document is unambiguous.

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 19 Jul 2007 13:33:40 -0700

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

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 19 Jul 2007 16:46:11 -0400

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

> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Thursday, July 19, 2007 4:34 PM
> To: Brian Rosen
> Cc: Marc Berryman; Winterbottom, James; [email-masked]; Marc
> Linsner; [email-masked]; Geopriv

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 19 Jul 2007 18:25:50 -0500

Sure, but if I've got an application that is asking for, and will only
accept, my country and zip code and all I've got to measure with is a
GPS receiver, then the application isn't going to be sympathetic with me
sending a lat/lon. The application doesn't have to explicitly tell me
that the conversion is permitted before I feel empowered to do it...

I don't think such a rule is enforceable. It's outside the scope of the
object encoding itself in any case.

I think at best it's a rule of thumb which really boils down to send
what you have if it fits the application semantics. Even then, frankly,
if I have reason to trust the geo-routing implementation of a routing
application more than I trust its civic tabular routing engine, I may
also feel empowered to convert anyway... that'd be an example of me
feeling the actual semantics were different to the theoretical semantics
I suppose.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, 20 July 2007 6:46 AM
To: 'Rohan Mahy'
Cc: 'Geopriv'; 'Marc Linsner'
Subject: RE: [Geopriv] Question on draft-linsner-geopriv-relativeloc-01

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

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

> > yielded a civic, send the civic.  If the original location was
measured
> and
> > > Subject: RE: [Geopriv] Question on
draft-linsner-geopriv-relativeloc-
> 01
> > > conflated into a civic address for reasons I have previously
stated "
> > > make were somehow missed. We are on the same page here, so let me
try
> > > conflate an x, y, z location into a civic address. The converting
of
> any
address,
> an
> > > address that is (usually) in a civic form. Ask the local EMS to
roll
> on
person
> who
> > > If a device or a call has a location of x, y, and z, I want the
same
> x,
> > > I want my dispatchers to take the x, y, and z coordinates, and
using
> my
operational
> and
> > > of the work we are doing here, but should always be kept in the
back
> or
> > > Subject: RE: [Geopriv] Question on
draft-linsner-geopriv-relativeloc-
> 01
> > > asked how the use-case provided for the above draft was not
addressed
> by
> > > The problem being described is a general one, not a specific one,
and
> it
> > > > All I am saying is we need to get the message out to the vendors
and
> > > the
> > > > This falls into the education and operations side of the
picture,
> > > > data, and their next equipment purchase should be capable of
using
> it,
> > > > > The ability to quickly determine the location, in the form of
a
> > > > > The location of the floor, in the case of a multi-story
building,
> > > must
> > > > > I think this brings to light several operational issues (we
will
> set
> > > > > the MSL of an area is not part of the normal database
structure
> > > within
> > > > > most of todays CAD and Mapped-ALI systems can not calculate
the
> > > local
> > > > > 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
> > > > > what systems such as GPS do. In aviation, the ellipsoid known
as
> > > World
> > > > > 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
> > > > >         "If the altitude (Z) parameter is expressed, it is
assumed
> > > to
> > > > >   utilize locally significant ground level (the ground
directly
> > > below
----------------------------------------------------------------------
> --
----------------------------------------------------------------------
> --

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 19 Jul 2007 20:31:21 -0400

It's got to be a SHOULD statement, so I think you get what you want.
I agree it's unenforceable.  There is no such thing as protocol police.
I think if the app requires one form or another, it should say you can
convert, but obviously if it's silent you have to convert anyway.
I'm not at all sure how you develop your "trust", but I would say unless you
are certain that the other end won't convert on your conversion, that you
better not convert.  YMMV, and I can't control your implementation.

Do you understand that the probability of an off-by-one error is very high
on a double conversion unless the databases match?  Let me give you an
example.  Some databases put the point of an address at the intersection of
a driveway and a road.  Some put it pretty much at the intersection of the
road and the middle of a building.  Others put the point at the door of a
structure.  Others put them in the approximate center of a building, and
others put them at the center of a parcel.  If you convert twice using
databases with different point bases, you will get off-by-one errors in a
great number of cases.

I think the statement that conversion should not be done unless the app says
its okay is a reasonable way to finish this discussion.  I'd explain why:

Conversion between geo and civic ("geocoding" or "reverse geocoding")
requires a database.  If two conversions are performed using different
databases, the probability of an error on the second conversion is high.
Therefore, conversion should not be accomplished at the client unless it is
certain that it won't be done at the server.  Applications should state
whether conversion at the client is acceptable.

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Thursday, July 19, 2007 7:26 PM
> To: Brian Rosen; Rohan Mahy
> Cc: Geopriv; Marc Linsner
> > > > draft-linsner-geopriv-relativeloc-01
> > > > >
> > > > > No, of course not.
> > > > draft-linsner-geopriv-relativeloc-01
> > > > >
> > > > > draft-linsner-geopriv-relativeloc-01
> > > > > >

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 19 Jul 2007 18:39:54 -0700

Hi Brian,

I think what is needed is a way for us to get the following:

"me" is the client and "you" is the server...
a) give me the first of these formats that you support without doing
any type of conversion
b) give me the first of these formats that you support, even if you
have to do conversion.  Tell me if you converted or not.

Lets say the client really wants a civic.  If the native format was
civic, the client takes it without conversion.  If the native format
was geo, the client should be able to decide whether it trusts the
server's conversion or its own conversion better.  Also, its possible
that the client or the server (or both) don't support conversion at
all.

thanks,
-rohan

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 19 Jul 2007 20:42:36 -0500

Isn't this all a little off topic for this draft now?

> Sent: Friday, 20 July 2007 11:40 AM
> To: Brian Rosen
> Cc: Geopriv; Dawson, Martin; Marc Linsner
> > I'm not at all sure how you develop your "trust", but I would say
unless
> you
> > are certain that the other end won't convert on your conversion,
that
> you
> > Do you understand that the probability of an off-by-one error is
very
> high
> > example.  Some databases put the point of an address at the
intersection
> of
> > a driveway and a road.  Some put it pretty much at the intersection
of
> the
> > road and the middle of a building.  Others put the point at the door
of
> > databases with different point bases, you will get off-by-one errors
in
> a
> > great number of cases.
> >
> > I think the statement that conversion should not be done unless the
app
> says
> > Therefore, conversion should not be accomplished at the client
unless it
> > > GPS receiver, then the application isn't going to be sympathetic
with
> me
> > > I don't think such a rule is enforceable. It's outside the scope
of
> > > > Cc: Marc Berryman; Winterbottom, James;
[email-masked];
> > > > > > To: Winterbottom, James; Brian Rosen;
[email-masked];
and
> Z
> > > > > > make were somehow missed. We are on the same page here, so
let
> me
else
> > > > > > the Dispatching Agency making an informed decision to
convert
> > > > > > 23.75467, -95.3452, 101 meters, and you will get run out of
the
> > > > dispatch
> > > > > > that 23.75467, -95.3452, 101 meters is the 4th floor of a
> building
> > > at
> 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
the
> > > > > > conversion, conflation, or guessing" of that location into
any
> > > type of
and
> > > > > > determination of how to take the x, y, and z location and
> provide
> > > the
> > > > > > 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
> > > > scope
the
Marc
civic
> > > > address
> > > > > > orientation of the WAP, are we going to add orientation in
there
> > > too?
cannot
> be
> > > > > > expressed by using a compound location which subsequently
offers
> > > far
> > > > > > a compound solution and in my previous email on this topic
and
> > > was
> one,
> > > > > > > local 9-1-1 authorities that they need to start thinking
and
> > > > > > developing
> > > > > > > should be encouraged to provide z, and the PSAPs should
start
> > > > > > gathering
> > > > > > > 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
> > > > > > > > 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
> > > > assume
> > > > > > > > The ability to quickly determine the location, in the
form
> of
> > > a
> > > > > > civic
> > > > > > > > address that is used in dispatch, must be readily
> determined,
> > > and;
> > > > > > > > be able to be readily determined based on the MSL and
the
> > > > elevation
the
> > > form
One
> > > issue
> issue
> > > > > > > > elevation of a given Z- value above local MSL for a
given x
> > > and y
> this
> earth,
> > > > > > > > Geodetic System 84 is increasingly used to define mean
sea
> > > level.
> > > > > > > >
> > > > > > > > Just a thought. We need to insure that the definition
used
> > > > > > > > That said, I have a comment/question on Z dimmension.
Sec 4
> > > sez:
> ----
> > > ----------------------
> ----
> > > ----------------------

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 19 Jul 2007 22:40:09 -0400

There is presently no way to mark a location as converted, but I agree we
should have a way. 

I have a problem with "trusts the server's conversion or its own better".  I
fall back on my previous statements; conversion is very bad unless you know
for certain that double conversion is not going to happen.  

Certainly, the basic rule of send me something unconverted if you can, and
convert only if you can't is good.  Applying the rule would not result in
the problem I'm worried about (where you could send something supported
unconverted, but had a "trust" problem).  If one end or the other doesn't
support conversion, the rule works, and you might not have a format that
meets the rule.

Brian
> Sent: Thursday, July 19, 2007 9:40 PM
> To: Brian Rosen
> Cc: Dawson, Martin; Geopriv; Marc Linsner
> > > > > > provide the proper response to the proper location. This is out
> of
> > > > scope
> > > > > > expressed by using a compound location which subsequently offers
> a
> > > far
> > > > > > a compound solution and in my previous email on this topic and
> it
> > > was
> > > > > > very carefully ignored.
> > > > > >
> > > > > > > You wouldn't want us to drop the z from the spec would you?
> You
> > > are
> > > > > > > just
> > > > > > > > If we have a x, y, and z location, then we must be willing
> to
> > > > assume
> > > > > > > > several things, namely:
> > > > > > > > Just a thought. We need to insure that the definition used
> in
> > > the
> > > > > > > > document
> > > > > > > > is unambiguous.
> > > > > > > >
> > > > > > > > Regards
> > > > > > > >
> > > > > > > > Carl
> > > > > > > >
> > > > > > > >

---

From: "Marc Berryman" <[email-masked]>
Date: Fri, 20 Jul 2007 08:06:17 -0500

Let not get conversion of civic to geo for routing purposes confused
with sending the raw information, that is civic for civic and geo for
geo, to the PSAP. It is clearly stated and mentioned many times that you
must send (to the PSAP) what you received with no conversion.

So I do not get bogged down in a wording fight, I will restate.
Converting civic to geo for routing is ok, but I (the PSAP) want the
civic to come in with no conversion if that was the original format, I
want geo to come in as geo if that was the original format.

Marc B

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Thursday, July 19, 2007 6:26 PM
To: Brian Rosen; Rohan Mahy
Cc: Geopriv; Marc Linsner
Subject: RE: [Geopriv] Question on draft-linsner-geopriv-relativeloc-01

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, 20 July 2007 6:46 AM
To: 'Rohan Mahy'
Cc: 'Geopriv'; 'Marc Linsner'
Subject: RE: [Geopriv] Question on draft-linsner-geopriv-relativeloc-01

Brian

measured
stated "
try
of
address,
roll
person
same
using
operational
back
addressed
and
and
picture,
using
a
building,
will
structure
the
be
MSL
as
be
not
assumed
directly