Subject: [Geopriv] Heading, bearing, and cousins (singh-geopriv-pdif-lo-dynamic)

From: Cullen Jennings <[email-masked]>
Date: Tue, 7 Nov 2006 17:45:13 -0800

I think you might want to tighten up some of the definitions about  
the data. In particular, bearing might be a slightly odd term here -  
people seem to have a lot of definitions of of it. It is also not  
clear to me if you want the direction i am pointing (in which case I  
might use heading) or the direction I am traveling (in which case I  
don't know what I would use but Track Made Good comes to mind). If we  
are deriving direction from changes in locations we probably don't  
want heading. Anyways, I don't know exactly what we want or how to  
phrase it but I think the definitions leave too much unspecified as  
they are.

I have seen some similar things that separated the vertical and  
horizontal speed - don't know but that might useful here too.

I would prefer to see only one unit of measure (probably the SI  
units) but perhaps I am missing the requirements ... I think this  
would reduce the odds of interoperability bugs and make it easier to  
implement. It's not like the stuff on the wire is meant for human  
reading in raw form.

I think the acceleration definition needs to be changed.

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 07 Nov 2006 17:53:29 -0800

Hi Cullen,

you are essentially asking not to follow the definition and description 
outlined in GML.

Regarding units of measurements: I have no problem with selecting one 
item, for example #m/s.

Cullen Jennings wrote:
> 
> I think you might want to tighten up some of the definitions about the 
> data. In particular, bearing might be a slightly odd term here - people 
> seem to have a lot of definitions of of it. It is also not clear to me 
> if you want the direction i am pointing (in which case I might use 
> heading) or the direction I am traveling (in which case I don't know 
> what I would use but Track Made Good comes to mind). If we are deriving 
> direction from changes in locations we probably don't want heading. 
> Anyways, I don't know exactly what we want or how to phrase it but I 
> think the definitions leave too much unspecified as they are.
> 
> I would prefer to see only one unit of measure (probably the SI units) 
> but perhaps I am missing the requirements ... I think this would reduce 
> the odds of interoperability bugs and make it easier to implement. It's 
> not like the stuff on the wire is meant for human reading in raw form.

> I think the acceleration definition needs to be changed.

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 7 Nov 2006 18:39:18 -0800

On Nov 7, 2006, at 5:45 PM, Cullen Jennings wrote:

> the data. In particular, bearing might be a slightly odd term here  
> - people seem to have a lot of definitions of of it. It is also not  
> clear

We're using the GML terminology, which presumably is derived from the  
navigational terminology:

In navigation, a bearing is the clockwise angle between a reference  
direction (or a datum line) and the direction to an object.

Unless otherwise specified, the reference direction is generally  
understood to be magnetic North, in which case the term compass  
bearing is also used.

(Wikipedia)

> to me if you want the direction i am pointing (in which case I  
> don't know what I would use but Track Made Good comes to mind). If  
> we are deriving direction from changes in locations we probably  
> don't want heading. Anyways, I don't know exactly what we want or  
> how to phrase it but I think the definitions leave too much  
> unspecified as they are.
>

It would indeed be nice if we could refer to a standard GIS  
"dictionary" for these terms.

> would reduce the odds of interoperability bugs and make it easier  
> to implement. It's not like the stuff on the wire is meant for  
> human reading in raw form.
>

I agree that having a single mandatory-to-implement unit is helpful.

> I think the acceleration definition needs to be changed.

Yes; something like

The rate at which an object's velocity changes with time.

is more physically correct (this one is from a NASA glossary, but  
probably can be found in any physics text book).

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 7 Nov 2006 19:01:54 -0800

Perhaps I just need to read more of the GML stuff - I did not mean to  
redefine the stuff in GML and want to reuse GML. I was more talking  
about the text in section 1 where we have the definitions such as

  acceleration:

       This element specifies the rate (usually rapid) at which  
something
       happens.  Similarly to the <speed> and the <elevation> element  
the
       <acceleration> element conains a 'uom' (Units Of Measure)
       attribute, which is a reference to a reference system for the
       amount.

I'd be surprised to find this in GML but there or not, I suspect we  
need something that is more implementable.

On Nov 7, 2006, at 5:53 PM, Hannes Tschofenig wrote:

> Hi Cullen,
>
> you are essentially asking not to follow the definition and  
> description outlined in GML.
>
> Regarding units of measurements: I have no problem with selecting  
> one item, for example #m/s.
>
> Cullen Jennings wrote:
>> - people seem to have a lot of definitions of of it. It is also  
>> not clear to me if you want the direction i am pointing (in which  
>> case I might use heading) or the direction I am traveling (in  
>> which case I don't know what I would use but Track Made Good comes  
>> to mind). If we are deriving direction from changes in locations  
>> we probably don't want heading. Anyways, I don't know exactly what  
>> we want or how to phrase it but I think the definitions leave too  
>> much unspecified as they are.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 07 Nov 2006 19:00:40 -0800

>> to me if you want the direction i am pointing (in which case I might 
>> use heading) or the direction I am traveling (in which case I don't 
>> know what I would use but Track Made Good comes to mind). If we are 
>> deriving direction from changes in locations we probably don't want 
>> heading. Anyways, I don't know exactly what we want or how to phrase 
>> it but I think the definitions leave too much unspecified as they are.
>>
> 
> It would indeed be nice if we could refer to a standard GIS "dictionary" 
> for these terms.

The current terms are taken from the GML defined "dictionary".

Ciao
Hannes

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 7 Nov 2006 19:03:21 -0800

I somewhat agree of that definition of bearing  - however what you  
are talking about here is not the angle to some other object - I  
think we are talking about either the direction you are pointing or  
the direction you are traveling both which are generally refereed to  
in navigation by other terms than bearing. I'm suspect that some  
people reading the current draft would have put "true bearings" not  
"compass bearings".

I think we are all on the same page of let's use the standard terms  
from navigation and just a bit of tweaking may be required to get the  
right one.

On Nov 7, 2006, at 6:39 PM, Henning Schulzrinne wrote:

>> not clear
> We're using the GML terminology, which presumably is derived from  
> the navigational terminology:
>
>> might use heading) or the direction I am traveling (in which case  
>> I don't know what I would use but Track Made Good comes to mind).  
>> If we are deriving direction from changes in locations we probably

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 7 Nov 2006 19:23:20 -0800

Cullen,

The bearing in the Wikipedia and GML definition seems to be the same:  
it describes the current direction of a moving object.  I don't see  
the difference between "direction of pointing" and "direction of  
travel". The only difference is one of time frame - a sail boat may  
be heading west, but tacking north. Is that your concern?

I'm biased towards re-using as much of GML terminology and structure  
as we can, although I find the acceleration definition a bit too  
"liberal arts", rather than "physics".

Henning

On Nov 7, 2006, at 7:03 PM, Cullen Jennings wrote:

> the direction you are traveling both which are generally refereed  
> to in navigation by other terms than bearing. I'm suspect that some  
> from navigation and just a bit of tweaking may be required to get  
> the right one.

---

From: [email-masked]
Date: Wed, 8 Nov 2006 07:57:48 -0500 (EST)

This is a correct interpretation of bearing. This definition is actually
derived from surveying and is well understood in the geo-community. I will
get more specifics from Ron Lake, one of the GML editors. The OGC also
uses two related documents for defining units of measurement (UoM) and
Observations and Measurements. GML uses UoM directly and is associated
with O&M.

FYI, GML is in the final stages of approval by ISO to be an internatinal
standard.

Regards

Carl

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 8 Nov 2006 16:32:40 -0600

I think that the existing definition is sufficient for describing object movement, although I have some concerns with the implementation that I will get to.

Cullen has raised a good point that I think has been missed, aside from what you have already discussed.  There is value in returning a value for "direction of travel", which is obviously related to the speed; however, there are applications in LBS where the direction that someone is looking is also relevant.  Applications already deployed for cellular networks in Japan have a feature where the user points their handset at a building and the application can tell them what they are pointing at.

Then you also have an "azimuth" that describes where the person is "pointing" (124 degrees from north at 10 degrees elevation):

  <azimuth uom="degrees urn" srsName="some urn">
    124 10
  </azimuth>

However, I think that the reference system would need to be defined somewhere.

As far as the point that Hannes raised, I think that if you are going to use the GML elements, you need to actually use them, not clone and own.  The namespace introduced in the draft was totally unnecessary, since the elements are defined in the "http://www.opengis.net/gml" namespace.  It's a different story if you are doing new things.

Carl, since you appear to be interested, can you explain why "gml:location" is defined as a mandatory element in "MovingObjectStatusType" when it is deprecated?  This would appear to be an error in the specification.

My other concern is with the units of measure urns that you are using - I think that there is a misunderstanding that "#m" is defined somewhere in the GML specification.  This is not the case.  The use of "#m" was noted as something that could be done as a convenience, where the definition is included in the instance document and tagged with gml:id="m".  I used OGC/EPSG urns in the geoshape document for degrees and metres; these can be used here as well.

Cheers,
Martin

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, 8 November 2006 2:23 PM
> To: Cullen Jennings
> Cc: [email-masked]
> Subject: Re: [Geopriv] Heading, bearing,and cousins (singh-geopriv-pdif-
> lo-dynamic)
> 
> Cullen,
> 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 10 Nov 2006 17:44:52 -0500

Thomson, Martin wrote:
> I think that the existing definition is sufficient for describing
> object movement, although I have some concerns with the
> implementation that I will get to.

Thanks for your comments.

> 
> Cullen has raised a good point that I think has been missed, aside
> from what you have already discussed.  There is value in returning a
> value for "direction of travel", which is obviously related to the
> speed; however, there are applications in LBS where the direction
> that someone is looking is also relevant.  Applications already
> deployed for cellular networks in Japan have a feature where the user
> points their handset at a building and the application can tell them
> what they are pointing at.
> 
> Then you also have an "azimuth" that describes where the person is
> "pointing" (124 degrees from north at 10 degrees elevation):
> 
> <azimuth uom="degrees urn" srsName="some urn"> 124 10 </azimuth>
> 

Is there really a need to distinguish the two in practice? The 
'direction of travel' for a stationary object or person seems to be the 
same to the azimuth you propose.

As I noted, there can be a difference in time scales, essentially the 
difference between the average direction and the instantaneous 
direction. (When driving from NY to SF, I'm heading west, on average, 
but my car may at any given instant point anywhere on the compass rose.)

However, that seems hard to capture, since this information is 
meaningless without further information - such as "what's the 
integration horizon for this? does this reflect the past ten minutes or 
the planned travel for the next hour?"

> 
> As far as the point that Hannes raised, I think that if you are going
> to use the GML elements, you need to actually use them, not clone and
> own.  The namespace introduced in the draft was totally unnecessary,
> since the elements are defined in the "http://www.opengis.net/gml"
> namespace.  It's a different story if you are doing new things.

We'll fix that depending on the outcome of the discussion in the 
paragraph below. We can't just adopt the specification as is, for the 
reason you mention below.

> 
> Carl, since you appear to be interested, can you explain why
> "gml:location" is defined as a mandatory element in
> "MovingObjectStatusType" when it is deprecated?  This would appear to
> be an error in the specification.
> 
> My other concern is with the units of measure urns that you are using
> - I think that there is a misunderstanding that "#m" is defined
> somewhere in the GML specification.  This is not the case.  The use
> of "#m" was noted as something that could be done as a convenience,
> where the definition is included in the instance document and tagged
> with gml:id="m".  I used OGC/EPSG urns in the geoshape document for
> degrees and metres; these can be used here as well.

If there's a reference that defines m/s and other common units, that 
would be helpful.

> Cheers, Martin

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Tue, 14 Nov 2006 17:11:43 -0700

As some additional information, in GML 3.1.1 (also ISO 19139), there is a section (14.5) that describes how to express dynamic. This section deals with relation of the moving object to time, its history, how to express a moving object (or collection of objects) using GML. From the GML document:

If the feature represents a moving object such as a ground vehicle or a ship, then the track property comprises a sequence of MovingObjectStatus elements. For example, a dynamic feature such as a cyclone may have a gml:track property such as shown in the following fragment (apologies for the lack of indentation):

<gml:track>

<gml:MovingObjectStatus>

<gml:validTime><gml:TimeInstant>

<gml:timePosition>2005-11-28T13:00:00</gml:timePosition>

</gml:TimeInstant></gml:validTime>

<gml:location><gml:Point>

<gml:pos>140. -35.</gml:pos>

</gml:Point></gml:location>

<gml:speed uom="#kph">12.</gml:speed>

<gml:bearing>

<gml:CompassPoint>SE</gml:CompassPoint>

</gml:bearing>

</gml:MovingObjectStatus>

<gml:MovingObjectStatus>

<gml:validTime><gml:TimeInstant>

<gml:timePosition>2005-11-28T14:00:00</gml:timePosition>

</gml:TimeInstant></gml:validTIme>

<gml:location><gml:Point>

<gml:pos>140.1 -34.9</gml:pos>

</gml:Point></gml:location>

<gml:speed uom="#kph">23.</gml:speed>

<gml:bearing>

<gml:CompassPoint>ESE</gml:CompassPoint>

</gml:bearing>

</gml:MovingObjectStatus>

</gml:track>

Also, the GML directions schema is used to express orientation, direction, heading, bearing or other directional aspects of geographic features. Along with time and units of measurement, there are quite a few ways in which movement of a mobile object can be expressed.

Now, from ISO 19107 - Features:

Bearing:  Bearing is a data type used to represent direction in the coordinate reference system. In a 2D coordinate reference system, this can be accomplished using a "angle measured from true north" or a 2D vector point in that direction. In a 3D coordinate reference system, two angles or any 3D vector is possible. If both a set of angles and a vector are given, then they shall be consistent with one another.

Angle as related to the above definition of Bearing:  In this variant of Bearing usually used for 2D coordinate systems, the first angle (azimuth) is measured from the first coordinate axis (usually north) in a counterclockwise fashion parallel to the reference surface tangent plane. If two angles are given, the second angle (altitude) usually represents the angle above (for positive angles) or below (for negative angles) a local plane parallel to the tangent plane of the reference surface.
And direction as related to this definition of Bearing: In this variant of Bearing usually used for 3D coordinate systems, the direction is express as an arbitrary vector, in the coordinate system.

Cheers

Carl

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 14 Nov 2006 21:20:12 -0600

Henning,

Apologies about the formatting, I am travelling and my mail client is somewhat lean.

H> Is there really a need to distinguish the two in practice? The 
H> 'direction of travel' for a stationary object or person seems to be the 
H> same to the azimuth you propose.

Yes, there is a need.  This is an actual application that is used in Japan, and it has been for a while.  I read about it in the press a while back.  You point your phone at a building and the phone tells you things about what you are pointing at.  What if you are on the bus?  What if you are just walking?  Saying that you are both moving at 0m/s towards the building and moving at 22m/s along the road is either confusing or outright wrong.

H> As I noted, there can be a difference in time scales, essentially the 
H> difference between the average direction and the instantaneous 
H> direction. (When driving from NY to SF, I'm heading west, on average, 
H> but my car may at any given instant point anywhere on the compass rose.)

This is a good point, and maybe you need to specify what these parameters refer to.  Either instantaneous velocity, or something over a longer interval.  Until now, I had assumed that this was an instantaneous measurement, since that is what we deal with in positioning systems.  The location is for a specific point in time, as is the velocity.  Maybe you can say that more general information can be derived by a client by subscription, or by explicit request, which includes the requisite supplementary information.

H> However, that seems hard to capture, since this information is 
H> meaningless without further information - such as "what's the 
H> integration horizon for this? does this reflect the past ten minutes or 
H> the planned travel for the next hour?"

> namespace.  It's a different story if you are doing new things.

H> We'll fix that depending on the outcome of the discussion in the 
H> paragraph below. We can't just adopt the specification as is, for the 
H> reason you mention below.

> degrees and metres; these can be used here as well.

H> If there's a reference that defines m/s and other common units, that 
H> would be helpful.

I don't have my EPSG database on hand here, so I can't say for sure if they include that, but we might actually have to define our own.  That should be so hard, it's just a URN.  The EPSG ones are nice if we can use those.

Ta,
Martin

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Wed, 15 Nov 2006 10:49:20 -0700

Am back from Chile.Will check on your question regarding ""gml:location" is 
defined as a mandatory element in "MovingObjectStatusType" when it is 
deprecated?  This would appear to be an error in the specification."

Cheers

Carl

----- Original Message ----- 
From: "Henning Schulzrinne" <[email-masked]>
To: "Thomson, Martin" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, November 10, 2006 3:44 PM
Subject: Re: [Geopriv] Heading, bearing,and cousins 
(singh-geopriv-pdif-lo-dynamic)

> Is there really a need to distinguish the two in practice? The 'direction 
> of travel' for a stationary object or person seems to be the same to the 
> azimuth you propose.
>
> difference between the average direction and the instantaneous direction. 
> (When driving from NY to SF, I'm heading west, on average, but my car may 
> at any given instant point anywhere on the compass rose.)
>
> However, that seems hard to capture, since this information is meaningless 
> without further information - such as "what's the integration horizon for 
> this? does this reflect the past ten minutes or the planned travel for the 
> next hour?"
>
>>
> We'll fix that depending on the outcome of the discussion in the paragraph 
> below. We can't just adopt the specification as is, for the reason you 
> mention below.
>
>>
> If there's a reference that defines m/s and other common units, that would 
> be helpful.
>
>
>>
>> Cheers, Martin
>>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 16 Nov 2006 20:48:10 -0500

Thanks for the additional information. One of the issues we had to  
deal with in the draft is to avoid replicating <location> for moving  
objects where we don't care about the track itself, just current  
speed and bearing (and maybe other directional information). It is  
somewhat unclear on how best to accomplish this.

On Nov 14, 2006, at 7:11 PM, Carl Reed OGC Account wrote:

> As some additional information, in GML 3.1.1 (also ISO 19139),  
> there is a section (14.5) that describes how to express dynamic.  
> This section deals with relation of the moving object to time, its  
> history, how to express a moving object (or collection of objects)  
> using GML. From the GML document:
>
> If the feature represents a moving object such as a ground vehicle  
> or a ship, then the track property comprises a sequence of  
> MovingObjectStatus elements. For example, a dynamic feature such as  
> a cyclone may have a gml:track property such as shown in the  
> following fragment (apologies for the lack of indentation):
>
> <gml:track>
> <gml:MovingObjectStatus>
> Also, the GML directions schema is used to express orientation,  
> direction, heading, bearing or other directional aspects of  
> geographic features. Along with time and units of measurement,  
> there are quite a few ways in which movement of a mobile object can  
> be expressed.
>
> Bearing:  Bearing is a data type used to represent direction in the  
> coordinate reference system. In a 2D coordinate reference system,  
> this can be accomplished using a "angle measured from true north"  
> or a 2D vector point in that direction. In a 3D coordinate  
> reference system, two angles or any 3D vector is possible. If both  
> a set of angles and a vector are given, then they shall be  
> consistent with one another.
>
> Angle as related to the above definition of Bearing:  In this  
> variant of Bearing usually used for 2D coordinate systems, the  
> first angle (azimuth) is measured from the first coordinate axis  
> (usually north) in a counterclockwise fashion parallel to the  
> reference surface tangent plane. If two angles are given, the  
> second angle (altitude) usually represents the angle above (for  
> positive angles) or below (for negative angles) a local plane  
> parallel to the tangent plane of the reference surface.
> And direction as related to this definition of Bearing: In this  
> variant of Bearing usually used for 3D coordinate systems, the  
> direction is express as an arbitrary vector, in the coordinate system.
>
> Cheers
>
> Carl
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 16 Nov 2006 21:08:14 -0500

On Nov 14, 2006, at 10:20 PM, Thomson, Martin wrote:

>
> Yes, there is a need.  This is an actual application that is used  
> in Japan, and it has been for a while.  I read about it in the  
> press a while back.  You point your phone at a building and the  
> phone tells you things about what you are pointing at.  What if you  
> are on the bus?  What if you are just walking?  Saying that you are  
> both moving at 0m/s towards the building and moving at 22m/s along  
> the road is either confusing or outright wrong.
>

This makes sense, although it does raise the issue of measurement  
interval.

> This is a good point, and maybe you need to specify what these  
> parameters refer to.  Either instantaneous velocity, or something  
> over a longer interval.  Until now, I had assumed that this was an  
> instantaneous measurement, since that is what we deal with in  
> positioning systems.  The location is for a specific point in time,  
> as is the velocity.  Maybe you can say that more general  
> information can be derived by a client by subscription, or by  
> explicit request, which includes the requisite supplementary  
> information.

I think the instantaneous direction is probably the only easily  
derivable information. The recipient can derive the general direction  
of travel by comparing a few location samples.

> I don't have my EPSG database on hand here, so I can't say for sure  
> if they include that, but we might actually have to define our  
> own.  That should be so hard, it's just a URN.  The EPSG ones are  
> nice if we can use those.

I looked at http://www.epsg.org/ and didn't see anything obviously  
related, just the well-known CRS data.

---

From: "Moore, Lyn E" <[email-masked]>
Date: Fri, 17 Nov 2006 13:40:54 +1100

Hi All

The product Martin was writing about is GVid by GeoVector Corporation.

Lyn Moore
Telstra Corporation, Australia

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Friday, 17 November 2006 1:08 PM
To: Thomson, Martin
Cc: [email-masked]
Subject: Re: [Geopriv] Heading, bearing,and cousins

On Nov 14, 2006, at 10:20 PM, Thomson, Martin wrote:

>
> Yes, there is a need.  This is an actual application that is used in 
> Japan, and it has been for a while.  I read about it in the press a 
> while back.  You point your phone at a building and the phone tells 
> you things about what you are pointing at.  What if you are on the 
> bus?  What if you are just walking?  Saying that you are both moving 
> at 0m/s towards the building and moving at 22m/s along the road is 
> either confusing or outright wrong.
>

>
> Ta,
> Martin
>
> ----------------------------------------------------------------------

> --------------------------
> ----------------------------------------------------------------------

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

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 18 Nov 2006 21:32:56 -0500

Let me explain my recollection of navigation terms is the following  
example (note this draft is about things that are relevant to  
navigation more than GIS - GML is more about GIS navigation).

A river if flowing south at 1 m/s while a swimmer is pointing west  
and summing at 1 m/s. There is a boat NE of the swimmer. None of  
these directions are magnetic - they all are relative to true north  
pole.

The swimmers "true heading" is west while their "track over ground  
true" is south west. The "true bearing" to the boat is North East.

Heading refers to the direction you are traveling ignoring unknown  
currents/winds and can be true or magnetic.

Track over ground is the direction you are traveling taking into  
account currents/winds and is defined to be direction from previous  
fix to current locations - this definition nicely avoids the problem  
of what time span the direction is integrated over. It's the previous  
reliable fix. This is typically in true but can be in magnetic too.

Bearing is the angle from you to some other object and can be in true  
or magnetic.

Now, if I have all these terms wrong - I'm fine for someone to point  
out the correct ones. If you want me to find references for these, I  
probably can (or at least can find a reference with the correct ones  
- this was done off a somewhat vague memory - I used to know this  
stuff :-). But I do think the draft needs to provide somewhat precise  
definition about what values get put in it. I will point out that  
most GPS units do not have a magnet or gyro compass and can only  
really provide track information. However, this is not as useful as  
the an actual heading provided my magnetic compass which lots of GPS  
units have or laser gyro stuff which is likely to become more common  
in the future and is already available in many settings. A device  
that does only magnetic heading can't necessarily provide true as it  
often won't know the mapping. I think it would be useful for the  
draft to support both magnetic and true headings based on what a  
device can produce and I think it should also be able to provide true  
track if that is what it can produce.

Bearings could be used for applications, such as I am pointing my  
cell phone at a building over there, what building is it? However,  
that seems like something different than what this draft is working on.

I'm not sure I see a problem with just using m/s and degrees for the  
units - anything else seems more complicated and I'm not sure I see  
the benefit but perhaps I am just on the wrong course here.

Cullen <with my individual contributor hat on>

On Nov 16, 2006, at 9:08 PM, Henning Schulzrinne wrote:

>> phone tells you things about what you are pointing at.  What if  
>> you are on the bus?  What if you are just walking?  Saying that  
>> you are both moving at 0m/s towards the building and moving at 22m/ 
>> s along the road is either confusing or outright wrong.
>>
>
>> positioning systems.  The location is for a specific point in  
>> time, as is the velocity.  Maybe you can say that more general  
> derivable information. The recipient can derive the general  
> direction of travel by comparing a few location samples.
>
>
>>
>> I don't have my EPSG database on hand here, so I can't say for  
>> sure if they include that, but we might actually have to define  
>> our own.  That should be so hard, it's just a URN.  The EPSG ones  
>> are nice if we can use those.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 18 Nov 2006 22:29:07 -0500

Thanks for the input. I agree that bearing, referring to static  
position, is probably slightly off course for "dynamic" data, as  
useful as it might be in general.

For units, I also agree: the default should be m/s and it's not clear  
we really need a units designator, assuming the numbers can be  
expressed in exponential notation (otherwise, expressing the speed of  
your favorite sci-fi vehicle may become burdensome). Fathoms per  
fortnight aren't terrible useful.

The problem with the suggestion is that we're likely to stray from  
GML at this point.

On Nov 18, 2006, at 9:32 PM, Cullen Jennings wrote:

> fix to current locations - this definition nicely avoids the  
> problem of what time span the direction is integrated over. It's  
> the previous reliable fix. This is typically in true but can be in  
> magnetic too.
>
> Bearing is the angle from you to some other object and can be in  
> true or magnetic.
>
> Now, if I have all these terms wrong - I'm fine for someone to  
> point out the correct ones. If you want me to find references for  
> these, I probably can (or at least can find a reference with the  
> correct ones - this was done off a somewhat vague memory - I used  
> to know this stuff :-). But I do think the draft needs to provide  
> somewhat precise definition about what values get put in it. I will  
> point out that most GPS units do not have a magnet or gyro compass  
> and can only really provide track information. However, this is not  
> as useful as the an actual heading provided my magnetic compass  
> which lots of GPS units have or laser gyro stuff which is likely to  
> become more common in the future and is already available in many  
> settings. A device that does only magnetic heading can't  
> necessarily provide true as it often won't know the mapping. I  
> think it would be useful for the draft to support both magnetic and  
> true headings based on what a device can produce and I think it  
> should also be able to provide true track if that is what it can  
> produce.
>
> I'm not sure I see a problem with just using m/s and degrees for  
> the units - anything else seems more complicated and I'm not sure I  
> see the benefit but perhaps I am just on the wrong course here.
>
>
>>> you are both moving at 0m/s towards the building and moving at  
>>> 22m/s along the road is either confusing or outright wrong.
>>>
>>
>>> over a longer interval.  Until now, I had assumed that this was  
>>> an instantaneous measurement, since that is what we deal with in

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 18 Nov 2006 23:17:26 -0500

On Nov 18, 2006, at 10:29 PM, Henning Schulzrinne wrote:

> For units, I also agree: the default should be m/s and it's not  
> clear we really need a units designator, assuming the numbers can  
> be expressed in exponential notation (otherwise, expressing the  
> speed of your favorite sci-fi vehicle may become burdensome).  
> Fathoms per fortnight aren't terrible useful.
>

Agree with all the above - including we don't want to be in conflict  
with how GML does it. I'm not up enough on what GML  does here to  
know how to balance this.

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Mon, 20 Nov 2006 12:55:13 -0700

And of course to make things interesting, from the Boating gloassary of 
terms:

BEARING - The direction of an object expressed either as a true bearing as 
shown on the chart, or as a bearing relative to the heading of the boat

and from Navigation

In navigation, a bearing is the angle between the direction to an object and 
a reference direction. Unless otherwise specified, the reference direction 
is generally understood to be magnetic North, in which case the term compass 
bearing is also used. If navigating by gyrocompass, the reference direction 
is true north. In stellar navigation, the reference direction is that of the 
North Star, Polaris.
en.wikipedia.org/wiki/Bearing_(navigation)

and from a glossary of aeronautical terms:

Bearing (BRG). Direction on a compass; Synonyms: direction; Symbols: B; 
Typical Units: rad, deg; and Direction: bearing

And from surveying

A surveying term used to designate direction. The bearing of a line is the 
acute horizontal angle between the meridian and the line. The meridian is an 
established line of reference. Azimuths are angles measured clockwise from 
any meridian.

Do we have a semantics issue here?

Cheers

Carl

----- Original Message ----- 
From: "Cullen Jennings" <[email-masked]>
To: <[email-masked]>
Cc: "Martin Thomson" <[email-masked]>; "Henning Schulzrinne" 
<[email-masked]>
Sent: Saturday, November 18, 2006 7:32 PM
Subject: Re: [Geopriv] Heading, bearing,and cousins 
(singh-geopriv-pdif-lo-dynamic)

> example (note this draft is about things that are relevant to  navigation 
> more than GIS - GML is more about GIS navigation).
>
> A river if flowing south at 1 m/s while a swimmer is pointing west  and 
> summing at 1 m/s. There is a boat NE of the swimmer. None of  these 
> directions are magnetic - they all are relative to true north  pole.
>
> The swimmers "true heading" is west while their "track over ground  true" 
> is south west. The "true bearing" to the boat is North East.
>
> Track over ground is the direction you are traveling taking into  account 
> currents/winds and is defined to be direction from previous  fix to 
> current locations - this definition nicely avoids the problem  of what 
> time span the direction is integrated over. It's the previous  reliable 
> fix. This is typically in true but can be in magnetic too.
>
> Bearing is the angle from you to some other object and can be in true  or 
> magnetic.
>
> Now, if I have all these terms wrong - I'm fine for someone to point  out 
> the correct ones. If you want me to find references for these, I  probably 
> can (or at least can find a reference with the correct ones  - this was 
> done off a somewhat vague memory - I used to know this  stuff :-). But I 
> do think the draft needs to provide somewhat precise  definition about 
> what values get put in it. I will point out that  most GPS units do not 
> have a magnet or gyro compass and can only  really provide track 
> information. However, this is not as useful as  the an actual heading 
> provided my magnetic compass which lots of GPS  units have or laser gyro 
> stuff which is likely to become more common  in the future and is already 
> available in many settings. A device  that does only magnetic heading 
> can't necessarily provide true as it  often won't know the mapping. I 
> think it would be useful for the  draft to support both magnetic and true 
> headings based on what a  device can produce and I think it should also be 
> able to provide true  track if that is what it can produce.
>
> Bearings could be used for applications, such as I am pointing my  cell 
> phone at a building over there, what building is it? However,  that seems 
> like something different than what this draft is working on.
>
> units - anything else seems more complicated and I'm not sure I see  the 
> benefit but perhaps I am just on the wrong course here.
>
>
>>> while back.  You point your phone at a building and the  phone tells you 
>>> things about what you are pointing at.  What if  you are on the bus? 
>>> What if you are just walking?  Saying that  you are both moving at 0m/s 
>>> towards the building and moving at 22m/ s along the road is either 
>>> confusing or outright wrong.
>>>
>>
>>> parameters refer to.  Either instantaneous velocity, or something  over 
>>> a longer interval.  Until now, I had assumed that this was an 
>>> positioning systems.  The location is for a specific point in  time, as 
>>> is the velocity.  Maybe you can say that more general  information can 
>>> be derived by a client by subscription, or by  explicit request, which 
>>> includes the requisite supplementary  information.
>>
>> derivable information. The recipient can derive the general  direction of 
>> travel by comparing a few location samples.
>>
>>
>>>
>>> I don't have my EPSG database on hand here, so I can't say for  sure if 
>>> they include that, but we might actually have to define  our own.  That 
>>> should be so hard, it's just a URN.  The EPSG ones  are nice if we can 
>>> use those.
>>

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Mon, 20 Nov 2006 12:36:28 -0700

Cullen -

One quick note before I respond in more detail: GML is not about GIS :-) GML 
has a much broader context in terms of being able to express 
location/geography. The Geography Markup Language (GML) is the XML grammar 
defined  to express geographical features. Features can be the traditional 
points, lines, and polys. They can also be images, tracks, observations, 
POIs, addresses or any type of location enabled content.

Not to be picky, but we (OGC) have moved away from being GIS centric and 
into all things geospatial. So, that is why this dialogue is of interest to 
me. If we need to extend/revise GML to insure that all information 
communities that need to encode geography can do so, then such input is very 
much appreciated.

Cheers

Carl

----- Original Message ----- 
From: "Cullen Jennings" <[email-masked]>
To: <[email-masked]>
Cc: "Martin Thomson" <[email-masked]>; "Henning Schulzrinne" 
<[email-masked]>

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 22 Nov 2006 11:18:03 -0800

Hi,

A few quick points inline.

> Yes, there is a need.  This is an actual application that is used in Japan, and it has been for a while.  I read about it in the press a while back.  You point your phone at a building and the phon…

I saw my cousin use an application in Japan that oriented a map on his
phone based on the direction he was currently pointing.  I have no
idea if this is the same or different application, but it was very
compelling for getting oriented and presenting the initial "turn
right" step in a list of directions.

> This is a good point, and maybe you need to specify what these parameters refer to.  Either instantaneous velocity, or something over a longer interval.  Until now, I had assumed that this was an i…

For the applications cited, instantaneous is interesting.  i will also
point out that an explicit "pull" of a location reference would be a
very nice way to get the appropriate instant here.

> H> the planned travel for the next hour?"

This is an example of the kind of data that I decided to omit from
location filters, but is very much in the same spirit.

thanks,
-rohan

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 22 Nov 2006 14:33:56 -0500

> very nice way to get the appropriate instant here.
No Rohan, this is a subscription.  You want a fast update of the map and the
actual location you are in the map.  It's not a one shot transfer of
information.

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 22 Nov 2006 12:14:46 -0800

Hi Brian,

No, for *this* application, you come out of the train station and you
press the "orient" button and you get oriented.  The map does not move
around as you rotate the phone subsequently.  When you make a turn you
press the "next" button which rotates the map according to the
directions, not which way you are pointing.  It strikes me that moving
the map in this context could be really annoying from a human factors
perspective.

I can certainly imagine other applications where a subscription would
be useful, but for this use case a subscription frankly sucks.

thanks,
-rohan

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 22 Nov 2006 15:37:18 -0500

The version of this app I saw was continuously changing as you move, not
necessarily in orientation, but in position.  The button press got you data
on what you were pointing at.  Perhaps there are different versions of
roughly the same app.

Brian

> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Wednesday, November 22, 2006 3:15 PM
> To: Brian Rosen
> Cc: Thomson, Martin; [email-masked]; Henning Schulzrinne

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 22 Nov 2006 22:31:12 +0100

Hi Carl,

as Henning stated, we have considered this approach and saw problems. It 
looks nice in the GML document but when put into SIP and the PIDF-LO it 
has some issues.

These design issues are, in fact, described in Appendix A of
http://tools.ietf.org/wg/geopriv/draft-singh-geopriv-pidf-lo-dynamic-00.txt

Ciao
Hannes

Henning Schulzrinne wrote:
> Thanks for the additional information. One of the issues we had to deal 
> with in the draft is to avoid replicating <location> for moving objects 
> where we don't care about the track itself, just current speed and 
> bearing (and maybe other directional information). It is somewhat 
> unclear on how best to accomplish this.
> 
>> As some additional information, in GML 3.1.1 (also ISO 19139), there 
>> is a section (14.5) that describes how to express dynamic. This 
>> section deals with relation of the moving object to time, its history, 
>> how to express a moving object (or collection of objects) using GML. 
>> From the GML document:
>>
>> If the feature represents a moving object such as a ground vehicle or 
>> a ship, then the track property comprises a sequence of 
>> MovingObjectStatus elements. For example, a dynamic feature such as a 
>> cyclone may have a gml:track property such as shown in the following 
>> fragment (apologies for the lack of indentation):
>>
>> <gml:track>
>> <gml:MovingObjectStatus>
>> direction, heading, bearing or other directional aspects of geographic 
>> features. Along with time and units of measurement, there are quite a 
>> few ways in which movement of a mobile object can be expressed.
>>
>> coordinate reference system. In a 2D coordinate reference system, this 
>> can be accomplished using a "angle measured from true north" or a 2D 
>> vector point in that direction. In a 3D coordinate reference system, 
>> two angles or any 3D vector is possible. If both a set of angles and a 
>> vector are given, then they shall be consistent with one another.
>>
>> Angle as related to the above definition of Bearing:  In this variant 
>> of Bearing usually used for 2D coordinate systems, the first angle 
>> (azimuth) is measured from the first coordinate axis (usually north) 
>> in a counterclockwise fashion parallel to the reference surface 
>> tangent plane. If two angles are given, the second angle (altitude) 
>> usually represents the angle above (for positive angles) or below (for 
>> negative angles) a local plane parallel to the tangent plane of the 
>> reference surface.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 22 Nov 2006 22:31:42 +0100

Hi Martin,

I would like to ask you two things:

a) Why do you think that we do not use GML elements? In fact we do.
There might be a bug in the namespace usage though.

b) It is stated in the draft that we need to lookup the URNs for the 
UOMs. If you have a pointer to the place where they are listed please 
let me know. I searched (at http://www.epsg.org/ and at 
http://ocean.csl.co.uk/experimental/index.php) but I could not find 
them. Note that I don't want to use an abbreviation, such as #kph, but 
rather the complete URN and I would like to state the mandatory to 
implement URNs. This should simplify interoperability.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 22 Nov 2006 22:31:58 +0100

Hi Carl,

for the terms used in the draft I thought I copied them from the GML 
specification (and forgot to put a reference to the respective section). 
But now I am unable to find them again.

I am happy to use these terms but can you provide me with a reference 
just to avoid having the same problem again?

Ciao
Hannes

Carl Reed OGC Account wrote:
> BEARING - The direction of an object expressed either as a true bearing 
> as shown on the chart, or as a bearing relative to the heading of the boat
> 
> and from Navigation
> 
> In navigation, a bearing is the angle between the direction to an object 
> and a reference direction. Unless otherwise specified, the reference 
> direction is generally understood to be magnetic North, in which case 
> the term compass bearing is also used. If navigating by gyrocompass, the 
> reference direction is true north. In stellar navigation, the reference 
> direction is that of the North Star, Polaris.
> A surveying term used to designate direction. The bearing of a line is 
> the acute horizontal angle between the meridian and the line. The 
> meridian is an established line of reference. Azimuths are angles 
> measured clockwise from any meridian.
> 
> ----- Original Message ----- From: "Cullen Jennings" <[email-masked]>
> To: <[email-masked]>
>>>> both moving at 0m/s towards the building and moving at 22m/ s along

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 22 Nov 2006 18:26:57 -0600

Hi Hannes,

a) This is what you have:

     xmlns:temp="urn:ietf:params:xml:ns:temporal1"
...
             <temp:speed uom="#kph">12</temp:speed>

But it would be sufficient to use <gml:speed uom...  That would obviate the need for section 5 entirely.

b) I haven't got access to MS Access right now, which is the best way to get to the EPSG database.  However, given my search on the Ocean page, I can't find any speed units.  This is a derived unit, and there are rules for defining derived units in GML.  You should provide a correct derivation and identify that derivation with a URN.  Maybe you can ask me later, when I'm not ridiculously busy and I can help with the construction of the derivation.

Ta,
Martin

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Thursday, 23 November 2006 8:32 AM
> To: Thomson, Martin
> Cc: Henning Schulzrinne; Cullen Jennings; [email-masked]
> > As far as the point that Hannes raised, I think that if you are going to
> use the GML elements, you need to actually use them, not clone and own.
> The namespace introduced in the draft was totally unnecessary, since the
> elements are defined in the "http://www.opengis.net/gml" namespace.  It's
> a different story if you are doing new things.
> >
> "MovingObjectStatusType" when it is deprecated?  This would appear to be
> an error in the specification.
> >
> > My other concern is with the units of measure urns that you are using -
> I think that there is a misunderstanding that "#m" is defined somewhere in
> the GML specification.  This is not the case.  The use of "#m" was noted
> as something that could be done as a convenience, where the definition is
> included in the instance document and tagged with gml:id="m".  I used
> OGC/EPSG urns in the geoshape document for degrees and metres; these can
> be used here as well.
> >
> > Cheers,
> > Martin
> >

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 22 Nov 2006 15:56:18 -0500

Glad to hear GML is expanding (or already includes) this scope - it  
makes it easier for work like GEOPRIV.

I think the definitions you have below sound like mostly consistent  
terminology for bearing with exception that if the true/magnetic  
issues is not specified, looks like some of them assume magnetic  
while some might assume true.

On Nov 20, 2006, at 2:55 PM, Carl Reed OGC Account wrote:

> And of course to make things interesting, from the Boating  
> gloassary of terms:
>
> BEARING - The direction of an object expressed either as a true  
> bearing as shown on the chart, or as a bearing relative to the  
> heading of the boat
>
> and from Navigation
>
> In navigation, a bearing is the angle between the direction to an  
> object and a reference direction. Unless otherwise specified, the  
> reference direction is generally understood to be magnetic North,  
> in which case the term compass bearing is also used. If navigating  
> by gyrocompass, the reference direction is true north. In stellar  
> navigation, the reference direction is that of the North Star,  
> Polaris.
> Bearing (BRG). Direction on a compass; Synonyms: direction;  
> Symbols: B; Typical Units: rad, deg; and Direction: bearing
>
> And from surveying
>
> A surveying term used to designate direction. The bearing of a line  
> is the acute horizontal angle between the meridian and the line.  
> The meridian is an established line of reference. Azimuths are  
> angles measured clockwise from any meridian.
>
> Cc: "Martin Thomson" <[email-masked]>; "Henning  
> Schulzrinne" <[email-masked]>
> Subject: Re: [Geopriv] Heading, bearing,and cousins (singh-geopriv- 
> pdif-lo-dynamic)
>
>
>>
>> Let me explain my recollection of navigation terms is the  
>> following example (note this draft is about things that are  
>> relevant to  navigation more than GIS - GML is more about GIS  
>> navigation).
>>
>> A river if flowing south at 1 m/s while a swimmer is pointing  
>> west  and summing at 1 m/s. There is a boat NE of the swimmer.  
>> None of  these directions are magnetic - they all are relative to  
>> true north  pole.
>>
>> The swimmers "true heading" is west while their "track over  
>> ground  true" is south west. The "true bearing" to the boat is  
>> North East.
>>
>> account currents/winds and is defined to be direction from  
>> previous  fix to current locations - this definition nicely avoids  
>> the problem  of what time span the direction is integrated over.  
>> It's the previous  reliable fix. This is typically in true but can  
>> be in magnetic too.
>>
>> somewhat precise  definition about what values get put in it. I  
>> will point out that  most GPS units do not have a magnet or gyro  
>> compass and can only  really provide track information. However,  
>> this is not as useful as  the an actual heading provided my  
>> magnetic compass which lots of GPS  units have or laser gyro stuff  
>> which is likely to become more common  in the future and is  
>> already available in many settings. A device  that does only  
>> magnetic heading can't necessarily provide true as it  often won't  
>> know the mapping. I think it would be useful for the  draft to  
>> support both magnetic and true headings based on what a  device  
>> can produce and I think it should also be able to provide true   
>> cell phone at a building over there, what building is it?  
>> However,  that seems like something different than what this draft  
>> is working on.
>>
>> the units - anything else seems more complicated and I'm not sure  
>> I see  the benefit but perhaps I am just on the wrong course here.
>>
>>
>>>> Yes, there is a need.  This is an actual application that is  
>>>> used  in Japan, and it has been for a while.  I read about it in  
>>>> the  press a while back.  You point your phone at a building and  
>>>> the  phone tells you things about what you are pointing at.   
>>>> What if  you are on the bus? What if you are just walking?   
>>>> Saying that  you are both moving at 0m/s towards the building  
>>>> and moving at 22m/ s along the road is either confusing or  
>>>> outright wrong.
>>>>
>>>
>>>> parameters refer to.  Either instantaneous velocity, or  
>>>> something  over a longer interval.  Until now, I had assumed  
>>>> that this was an instantaneous measurement, since that is what  
>>>> we deal with in positioning systems.  The location is for a  
>>>> specific point in  time, as is the velocity.  Maybe you can say  
>>>> that more general  information can be derived by a client by  
>>>> subscription, or by  explicit request, which includes the  
>>>> requisite supplementary  information.
>>>
>>>> our own.  That should be so hard, it's just a URN.  The EPSG  
>>>> ones  are nice if we can use those.
>>>
>>> I looked at http://www.epsg.org/ and didn't see anything  
>>> obviously related, just the well-known CRS data.
>>>
>>>
>>>>
>>>> Ta,
>>>> Martin
>>>>
>>>> ------------------------------------------------------------------- 
>>>> -- ---------------------------
>>>> ------------------------------------------------------------------- 
>>>> -- ---------------------------
>>>> [mf2]
>>>>
>>>
>>>

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 23 Nov 2006 18:40:04 +0100

I wonder how and when this extended GML scope is going to help us with the work on (singh-geopriv-pdif-lo-dynamic).

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: Cullen Jennings [mailto:[email-masked]] 
> Gesendet: Mittwoch, 22. November 2006 21:56
> An: Carl Reed OGC Account
> Cc: [email-masked]; Martin Thomson; Henning Schulzrinne
> Betreff: Re: [Geopriv] Heading, bearing,and cousins

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 23 Nov 2006 20:04:16 -0500

Just FYI - I did not mean to imply we should wait for this work. I  
don't have opinions on this one way or the other - what they are  
trying to do in this draft is pretty trivial and I think could be  
resolved with a few sentences.

On Nov 23, 2006, at 12:40 PM, Tschofenig, Hannes wrote:

> I wonder how and when this extended GML scope is going to help us  
> with the work on (singh-geopriv-pdif-lo-dynamic).
>
> Ciao
> Hannes
>
>