Subject: [Geopriv] 10 minute review of linsner-relativeloc

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 22 Apr 2007 22:36:01 -0500

http://tools.ietf.org/html/draft-linsner-geopriv-relativeloc-00

I don't really have time to comment in more detail[*], but there are a few things that spring to mind...

I'm OK with the concept, but question the inclusion of the fields in the civic form.  We have discussed this before in other contexts - in effect, this creates a new coordinate reference system based on a civic address.  This isn't useful for a GIS system, but it could be for dispatch or something similar.

For the reference position, some convention needs to be defined to identify a point.  As stated in the draft, civic addresses rarely describe a point, they more often describe an area of some size (country, state, city...building, room).  I'd prefer to see some convention used to establish a point.  The centre of the area should suffice in most cases.

On that theme, the reference point is unnecessary.  It is also arbitrary in how it is interpreted.

I see no reason to prevent the use of three dimensions.  Simply allow for altitude to be omitted.

In the forward-compatible case, the addition of the fields could result in an error.  A client that does not support these fields could interpret the rest of the civic location as the complete information.  This could be dangerously wrong in the case where the distance values are large.

My preference would be to use a different container for the relative position:

  <civicRelative>
    <civicAddress>...</civicAddress>
    <relativePosition>...</relativePosition>
  </civicRelative>

That would imply that for backward compatibility reasons you would also include a second civic address that includes an address that is accurate (and is also immune from the problem described above).  I can think of ways to get that to work with DHCP, but I'll leave that to the reader to work out.

There is no encoding for the relative position for DHCP.

There is no XML definitions for the new fields.

   "Differing from global positioning coordinate systems,
   distance from the starting point is expressed as a 2 dimensional
   measurement instead of geographic coordinates."

"global positioning coordinate systems" use Cartesian coordinates too.  This sentence is somewhat redundant.

Cheers,
Martin 

[*] This is brief because I'm taking leave, starting Wednesday, and I'm busied out.  Expect no further communication from me...until September.
------------------------------------------------------------------------------------------------
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: "Carl Reed OGC Account" <[email-masked]>
Date: Mon, 23 Apr 2007 10:16:26 -0600

This is more an adjunct to this linsner document discussion.

The topic of defining a general coordinate model has become extremely 
animated in the OGC. This is because the geo, imagery, sensor and location 
services industries have various requirements and mechanisms for modeling 
coordinates.

Specifically, from our meeting notes:

"We did meet this evening and there was an agreement among the ~12 dozen 
people attending that we should form a group to develop a common approach to 
coordinates across all of the relevant application domains, including:

1.    Coverages and features (in particular non-spatial coordinates)
2.    Moving bodies (rigid bodies)
3.    The ISO 19107 Revision. (Features and geometry)
4.    Linear Referencing Systems - a form of location by referencing.
5.    3DIM – built structures – GeoEngineering (including local coordinate 
systems)
6.    Geodesy – ISO 19111 (ISO 19111:2003 defines the conceptual schema for 
the description of spatial referencing by coordinates)"

Therefore, any input, use cases, or requirements from this group would be 
very much appreciated. FYI, this work should not cause any changes in how 
GML currently express coordinates in relation to the GML Geoshape/PIDF-LO 
application schema.

Now I need to read Marc's document :-)

Carl

----- Original Message ----- 
From: "Thomson, Martin" <[email-masked]>
To: "GEOPRIV WG" <[email-masked]>
Sent: Sunday, April 22, 2007 9:36 PM
Subject: [Geopriv] 10 minute review of linsner-relativeloc

> I'm OK with the concept, but question the inclusion of the fields in the 
> civic form.  We have discussed this before in other contexts - in effect, 
> this creates a new coordinate reference system based on a civic address. 
> This isn't useful for a GIS system, but it could be for dispatch or 
> something similar.
>
> For the reference position, some convention needs to be defined to 
> identify a point.  As stated in the draft, civic addresses rarely describe 
> a point, they more often describe an area of some size (country, state, 
> city...building, room).  I'd prefer to see some convention used to 
> establish a point.  The centre of the area should suffice in most cases.
>
> In the forward-compatible case, the addition of the fields could result in 
> an error.  A client that does not support these fields could interpret the 
> rest of the civic location as the complete information.  This could be 
> dangerously wrong in the case where the distance values are large.
>
> That would imply that for backward compatibility reasons you would also 
> include a second civic address that includes an address that is accurate 
> (and is also immune from the problem described above).  I can think of 
> ways to get that to work with DHCP, but I'll leave that to the reader to 
> work out.
>
> [*] This is brief because I'm taking leave, starting Wednesday, and I'm 
> busied out.  Expect no further communication from me...until September.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 23 Apr 2007 20:21:14 +0200

Hi Carl, Martin, Marc,

with respect to geodetic location information I thought that George 
Percivall told us (at the SDO Emergency Services workshop) that GML 
already provides combound location information whereby this 
functionality can be used by defining a new coordinate reference system 
where the GML document would carry two location information elements:

I could imagine that civic location could also be handled in the same 
fashion since GML provides extensibility features.

Ciao
Hannes

_______________________________________________
Hannes Tschofenig
Nokia Siemens Networks GmbH & Co. KG

Phone: +49 (89) 636 40390
Fax: +49 (89) 636 48000
E-Mail:[email-masked]
_______________________________________________

Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRA 88537
WEEE-Reg.-Nr.: DE 52984304
Persönlich haftende Gesellschafterin / General Partner: Nokia Siemens 
Networks Management GmbH
Geschäftsleitung / Board of Directors: Joachim Malterer, Lydia Sommer
Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRB 163416 

Carl Reed OGC Account wrote:
> animated in the OGC. This is because the geo, imagery, sensor and 
> location services industries have various requirements and mechanisms 
> for modeling coordinates.
>
> "We did meet this evening and there was an agreement among the ~12 
> dozen people attending that we should form a group to develop a common 
> approach to coordinates across all of the relevant application 
> domains, including:
>
> 5.    3DIM – built structures – GeoEngineering (including local 
> coordinate systems)
> 6.    Geodesy – ISO 19111 (ISO 19111:2003 defines the conceptual 
> schema for the description of spatial referencing by coordinates)"
>
> Therefore, any input, use cases, or requirements from this group would 
> be very much appreciated. FYI, this work should not cause any changes 
> in how GML currently express coordinates in relation to the GML 
> Geoshape/PIDF-LO application schema.
>
> ----- Original Message ----- From: "Thomson, Martin" 
> <[email-masked]>
>> I'm OK with the concept, but question the inclusion of the fields in 
>> the civic form.  We have discussed this before in other contexts - in 
>> effect, this creates a new coordinate reference system based on a 
>> civic address. This isn't useful for a GIS system, but it could be 
>> for dispatch or something similar.
>>
>> identify a point.  As stated in the draft, civic addresses rarely 
>> describe a point, they more often describe an area of some size 
>> (country, state, city...building, room).  I'd prefer to see some 
>> convention used to establish a point.  The centre of the area should 
>> suffice in most cases.
>>
>> In the forward-compatible case, the addition of the fields could 
>> result in an error.  A client that does not support these fields 
>> could interpret the rest of the civic location as the complete 
>> information.  This could be dangerously wrong in the case where the 
>> distance values are large.
>>
>> That would imply that for backward compatibility reasons you would 
>> also include a second civic address that includes an address that is 
>> accurate (and is also immune from the problem described above).  I 
>> can think of ways to get that to work with DHCP, but I'll leave that 
>> to the reader to work out.
>>
>> "global positioning coordinate systems" use Cartesian coordinates 
>> too. This sentence is somewhat redundant.
>>
>> Cheers,
>> Martin
>>
>> [*] This is brief because I'm taking leave, starting Wednesday, and 
>> I'm busied out.  Expect no further communication from me...until 
>> September.

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 23 Apr 2007 16:30:38 -0400

Martin,

in-line.... 

> I'm OK with the concept, but question the inclusion of the 
> fields in the civic form.  We have discussed this before in 
> other contexts - in effect, this creates a new coordinate 
> reference system based on a civic address.  This isn't useful 
> for a GIS system, but it could be for dispatch or something similar.

The intent is not to create a standard by which all GIS systems use for
computation.  As stated in the draft, this information is an extension to
the included civic address information.  Location determination/expression
via this mechanism is very much similar to the already defined 'room',
'seat', 'additional code' in that some/most GIS systems wouldn't/can't
utilize the data, but as you point out, it is useful for dispatch.

> 
> For the reference position, some convention needs to be 
> defined to identify a point.  As stated in the draft, civic 
> addresses rarely describe a point, they more often describe 
> an area of some size (country, state, city...building, room). 
>  I'd prefer to see some convention used to establish a point. 
>  The centre of the area should suffice in most cases.

Since the reference point is only locally significant, I question why this
needs standardization?

> also arbitrary in how it is interpreted.

We assume interpretation by a human knowledgeable to the local environment
such that the data makes sense to them.  In this use case, without a
reference point, the relative position is useless.

> Simply allow for altitude to be omitted.

Current implementations are able to determine 'floor' of a building.  We see
no need to extend that to other vertical measurements.

> 
> In the forward-compatible case, the addition of the fields 
> could result in an error.  A client that does not support 
> these fields could interpret the rest of the civic location 
> as the complete information.  This could be dangerously wrong 
> in the case where the distance values are large.

I'm assuming your fear is that a wireless hotspot at 123 Main St. would
convey a civic location as 123 Main St. <refpt>front
door</refpt><relpos><X>-120</X><Y>560</Y></relpos> such that the resultant
location is now at 456 Third St.  I will add words to the effect that the
resultant values conveyed via relative location SHOULD adhere to the
boundary of the corresponding civic location information.   

> That would imply that for backward compatibility reasons you 
> would also include a second civic address that includes an 
> address that is accurate (and is also immune from the problem 
> described above).  I can think of ways to get that to work 
> with DHCP, but I'll leave that to the reader to work out.

I believe it would destroy the usefulness of the use case to provide the
information in a different container.  I would like to hear others on this
topic.

> There is no encoding for the relative position for DHCP.

We expect that to happen also.

> There is no XML definitions for the new fields.

Please send text.

> "global positioning coordinate systems" use Cartesian 
> coordinates too.  This sentence is somewhat redundant.

Noted

Thanks,

-Marc-

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 23 Apr 2007 18:45:33 -0500

That is true Hannes, but you need a few things before that is possible.  That includes a precise anchor point, then coordinate axes and so forth.  It could be difficult to provide an unambiguous representation.  Expressing that in GML, using a civic address as a baseline might work, but it could also turn out to be quite complex.  That's why I'm not totally opposed to the concept of a simpler representation. 

Cheers,
Martin

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Tuesday, 24 April 2007 4:21 AM
> To: Carl Reed OGC Account
> Cc: Thomson, Martin; GEOPRIV WG
> Subject: Re: [Geopriv] 10 minute review of linsner-relativeloc - adjunct
> conversation and call for input
> 
> Hi Carl, Martin, Marc,
>

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Tue, 24 Apr 2007 15:26:59 -0600

Marc -

Apologies for the length of this email.

I have asked the OGC members to review components of the document. The 
following are some comments on how you are defining "relative location". I 
am expecting other comments as well.

One quick comment from me: In your description of X and Y and the associated 
example:

<REFPT>corner_office</REFPT>

   <RELPOS>

      <X>23</X>

      <Y>51</Y>

There are "well-known" coordinate reference systems (I believe what you are 
calling "geodetic systems) that are left handed as opposed to right handed 
(reversed from what we consider normal).  An example is the use of reverse 
Lo-Gauss in South Africa. Just something to be aware of.

Also, the following from me: You use measurement unit (MU) in the 
description of relative position. I would suggest changing this to Units of 
Measurement (UoM). This is the semantic that POSC, EPSG, the OGC, IEEE, IEC 
ISO, and other international standards groups use as best practice. 
http://www.posc.org/ebiz/Guidelines/UOMFinalRecs.html for examples. And 
there are ISO/IEC document that provides normative guidance on what the UoM 
codes are.

The following comment is from an OGC member with the suggestion is that you 
provide additional clarification as to the "best use" of this approach. This 
is so that the implementer understands that your recommended approach SHOULD 
NOT be used for cases in which the location as defined by "relative" is too 
far to the "anchor" point or for cases in which highly accurate relative 
positions are to be located. All has to do with the curvature of the earth. 
As the OGC member states:

The suggested standard approach works as long as you are "close" to the 
origin. Close is probably on the order of 5 to 10 miles. Once you get 
further than that, the curvature of the Earth messes with "right angle" 
measures <and the accuracy of the relative position>. That is, if X is an EW 
or (x,0) vector and Y is a NS or (0,y) vector, the (X+Y)!=(Y+X). Assuming 
you are north of the equator, and both numbers are positive, X+Y (go east 
then north) will be slightly west of Y+X (go north then east). The farther 
north you are the shorter a degree of longitude is.

    Essentially the scale east-west changes in proportion to the cosine of 
the latitude (going to zero at the poles), while the north-south does not 
change at all (until you reach the pole, and then it simply runs out). Now 
for short distances, you would not notice, but it does eventually show up.

    If they want to fix this they need to specify which direction first. I 
might suggest always measure EW first then NS, although that is just me. As 
stated above, stay close and you won't be able to measure the difference.

    If they do not want to specify primary direction, then they need to 
emphasize limits on the distances from the origin. No locating the tip of 
Pisa's Leaning Tower to the nearest centimeter using the center of the North 
Tower on Tower Bridge in London as an origin.

    Oddly enough, if they go bearing and distance (polar coordinates), and 
use great circles, it works okay, but you get a little counter intuitive, 
because we think of direction in rhumb lines on a Mercator Map, and Great 
Circle routes confuse folks. Again for short distances are okay and closely 
match line-of-sight.

Now, I am also suggesting the following. Perhaps an informative annex that 
shows how to compute the error for any latitude.

For each distance and bearing, compute the latitude and longitude of the 
second point using the exact spherical formula:

LAT, LON GIVEN DISTANCE (d*R) AND AZIMUTH (tc)
lat2=asin(sin(lat1)*cos(d)+cos(lat1)*sin(d)*cos(tc))
IF (cos(lat)=0)
  lon2=lon1      // endpoint a pole
ELSE
  lon2=mod(lon1-asin(sin(tc)*sin(d)/cos(lat1))+pi,2*pi)-pi
ENDIF

Then compute the distance using the approximate formula:

PLANAR APPROXIMATION
x = (lon2-lon1)*cos(lat1)*pi/180
y = (lat2-lat1)*pi/180
d = R * sqrt(x^2 + y^2)

Then compute the relative error, that is,

  (approx. distance - actual distance)/(actual distance)

Obviously, even at 50 kilometers from the anchor point, the relative error 
is minimal at the equator but becomes significant at the higher latitudes, 
like in Scandanvia. Reason I bring this up is that beyond issues of locating 
an asset, there may be legal implications if a location computed for a 
relative position is used in a "not fit for purpose" application and their 
are legal consequences if the relative error is not provided. Just a 
thought.

Cheers

Carl

----- Original Message ----- 
From: "Marc Linsner" <[email-masked]>
To: "'Thomson, Martin'" <[email-masked]>; "'GEOPRIV WG'" 
<[email-masked]>
Sent: Monday, April 23, 2007 2:30 PM
Subject: RE: [Geopriv] 10 minute review of linsner-relativeloc