Subject: Request For A Formal URN Namespace: "geo"

From: "Sean B. Palmer" <[email-masked]>
Date: Sun, 9 Sep 2001 17:30:28 +0100

This is a request for a formal URN namespace per section 4.0 III of RFC
2611. File attached as <<urn-geo.txt>>.

After playing around with a lot of coordinates etc., I wondered if there
were any URI schemes or URN namespaces that would let me refer to them on
the WWW. After some seraching I couldn't actually find any, although I
wouldn't be suprised if someone has already proposed/registered such a
scheme.

I remember Larry referening a paper by Michael Gorlick [1] which is about
the closest thing to this that I could find, although that proposes domain
names rather than URNs. Anyway, comments are most welcome.

Cheers,

[1] Linked from http://www.ics.uci.edu/IRUS/twist/twist99/program.html

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .

---

From: Larry Masinter <[email-masked]>
Date: Sun, 9 Sep 2001 12:54:10 -0700

There's actually been quite a bit of activity in IETF
on spatial location designations of all sorts, beyond
the one reference I gave before:

BOF & pointer to its mail archives:
  http://www-nrc.nokia.com/ip-location/
Newly chartered IETF working group:
  http://www.ietf.org/html.charters/geopriv-charter.html
including Internet draft for initial requirements

http://www.ietf.org/internet-drafts/draft-rosen-geopriv-requirements-00.txt

The working group and discussions around it have had
quite a focus on the privacy issues surrounding protocols
that might trade geographic information about the devices
(and thus users) at the endpoints.

Note that the geopriv charter says:
  " the working group will select an already standardized format to
recommend
   for use in representing location per se"

so the assumption is that there are other (non-IETF)
standards that the IETF group will make reference too.
I wouldn't want to see the "geo" URN scheme choose a
different representation than the geopriv working group,
at least without some analysis and justification.

Larry
--
http://larry.masinter.net

---

From: Al Gilman <[email-masked]>
Date: Sun, 9 Sep 2001 23:06:29 -0400

>at least without some analysis and justification.

I'm pretty sure that altitude is undefined without specifying what model you
are using for the shape of the zero altitude surface.  Latitude could show
similar effects.

The documents of the Open GIS Consortium might help, here.  [Google that]

Al

>Larry
>--
><http://larry.masinter.net/>http://larry.masinter.net
>

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 10 Sep 2001 07:47:57 +0200

--On 2001-09-09 23.06 -0400 Al Gilman <[email-masked]> wrote:

> I'm pretty sure that altitude is undefined without specifying what model
> you are using for the shape of the zero altitude surface.  Latitude could
> show similar effects.
>

It's just extremely important that the datum is chosen and specified in
extreme detail. Also the grammar needs to be defined in great(er) detail.

The devil is really in the details regarding location specifications.

   paf

---

From: "Arnold G. Reinhold" <[email-masked]>
Date: Mon, 10 Sep 2001 21:50:00 -0400

>The devil is really in the details regarding location specifications.

If I can make a somewhat far out suggestion, it might be appropriate
to include hooks for locations outside the Earth's atmosphere.
Internet standards that succeed tend to have much longer lives than
their designers anticipate. There is already an Internet presence on
the International Space Station.  The next generation of Amateur
Radio satellites will likely include Web cams and other remote
sensors that will be Web accessible.  Various initiatives for private
access to space are underway and these may also extend the reach of
the Internet.

It is possible to specify the location of an object in Earth orbit by
giving the coordinates of the point on Earth directly below the
object and distance from the Earth's surface, but that is not a very
useful representation in most cases. Keplerian elements would be
better.  A simple encoding for different coordinate regimes might
work along the following lines

"s3"  within the Earth's atmosphere

"s3o" Earth orbit

"s3-1" Lunar surface

"s3-1o" Lunar orbit

"so" Solar orbit

etc.

Arnold Reinhold

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 11 Sep 2001 07:40:02 +0200

--On 01-09-10 21.50 -0400 "Arnold G. Reinhold" <[email-masked]>
wrote:

> A simple encoding for different coordinate regimes might work along the
> following lines
>

Much better, but I guess this is what you try to do, is to map to a
coordinate system / datum instead of "handwaving" like you do.

I.e. I hope you really were in the case of "s3" thinking of something like
WGS84.

See http://www.wgs84.com/wgs84/wgs84.htm about some of the issues I talk
about. I.e. should WGS84, ITRF, ETRF or something else be used for s3 above?

How will you handle local coordinate systems like RT90 used in Sweden?

   paf

---

From: "Arnold G. Reinhold" <[email-masked]>
Date: Tue, 11 Sep 2001 08:50:42 -0400

>How will you handle local coordinate systems like RT90 used in Sweden?

I guess I was thinking of something like "s3.WGS84" or "s3.se.RT90"
to designate a coordinate system.

Clive D.W. Feather added:

>In message <v04210112b7c2d9e1dc5b@[192.168.0.2]>, Arnold G. Reinhold
><[email-masked]> writes
>>better.
>But you also need to give update formulae for those elements; very
>few bodies stay in the same Keplerian orbit for long.

I am not saying what the right reporting format for each regime
should be, I am just reserving a namespace for each one.

>>A simple encoding for different coordinate regimes might
>Etc.
>Firstly, there's an obvious break between objects:
>- stationary on a large body, for which lat/long works
>- moving close to a large body (land, sea, or air transport), for which
>  you need lat/long plus a formula for the motion
>- in orbit around a large body, in which case you need orbital data.

That is exactly what I was trying to say. You can break the solar
system down into separate regimes and then decide on which coordinate
system to use for each.

>
>>"s3-1o" Lunar orbit
>
>The Moon's gravitational field is particularly non-uniform, and
>nothing stays in the same orbit for long.
>
>You also need to consider transitional orbits. And non-ballistic
>trajectories (e.g. for solar sails).

And you might want to treat special cases like geosynchronous orbits
and Lagrange points (L1-L5) etc. differently. All I am proposing is
including hooks that would allow you to do so.

While we are at it, it might also be a good thing to include a
standard for reporting attitude (e.g. Euler angles) for an object
along with its position. This would be particularly useful for
airborne or space borne cameras and other directional sensors.

Arnold Reinhold

---

From: "Clive D. W. Feather" <[email-masked]>
Date: Tue, 11 Sep 2001 07:19:33 +0100

>useful representation in most cases. Keplerian elements would be

But you also need to give update formulae for those elements; very few 
bodies stay in the same Keplerian orbit for long.

Etc.

>"s3-1o" Lunar orbit

The Moon's gravitational field is particularly non-uniform, and nothing 
stays in the same orbit for long.

"This ain't ... um, this *is* rocket science."

-- 
Clive D.W. Feather    | Internet Expert      | Work: <[email-masked]>
Tel: +44 20 8371 1138 | Demon Internet       | Home: <[email-masked]>
Fax: +44 20 8371 1037 | Thus plc             | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address

---

From: "Clive D. W. Feather" <[email-masked]>
Date: Tue, 11 Sep 2001 07:13:21 +0100

This document proposes the "geo" namespace, which enables people
   to refer to geographical locations based upon a latitude and a
   longitude.

You limit this to latitude and longtitude (plus height). If you included
an indicator *saying* it was lat-long, then other systems (e.g. UK
National Grid) could be included as well. In other words, say:

    urn:geo:latlong/1:2:3E,4:5:6N

then allowing:

    urn:geo:ukgrid/TQ123456

         location   =  hms / pnt

Firstly, why does the HMS/decimal choice have to be made at this level ?
Since you are allowing alternate forms at all, why not allow one
coordinate to be one form and one the other ?

         hmslatc    =  ( d89 ":" [ d60 ":" d60 ] ) / "90:00" [ ":00" ]
         hmslongc   =  ( d179 ":" [ d60 ":" d60 ] ) / "180:00" [ ":00" ]

There are often good reasons for wanting to specify a longtitude greater
than 180 degrees and, more rarely, a latitude greater than 90 degrees.
Why forbid this ?

Why no leading zeroes ? Why can't I use decimal fractions of second, or
even of a minute ? Equally, older sources use thirds and fourths. Why
can't I use those ? In other words, what's wrong with:

    location = angular lat "," angular long [ "," height ]
    angular = *( integer ":" ) float
    integer = 1*DIGIT
    float = integer [ "." *DIGIT ]

    The first term in an "angular" is in units of degrees, while each
    succeeding term (separated by colons) is in units 1/60 that of the
    previous one; the resulting values are added.

    In canonical form, all terms except the first are strictly less than
    60, have no leading zeroes, and do not end with a decimal point. The
    total value is not greater than 90 for the latitude and 180 for a
    longtitude.

         height     =  [ "-" ] dx0 *d [ "." *d dx0 ] ( "m" / "ft" )

Is that UK and US standard feet (0.3048 metres) or US survey feet (3937
feet equal 432 metres) ? They aren't the same.

      Each coordinate location is a unique point in 3 dimensional
      space. Uniqueness is guaranteed by the syntax of latitudes and
      longitudes, which has been developed over many years.

Which reference grid are you going to use ? There are several. Even the
location of the Greenwich Meridian is not that well defined.

      The height 0
      is given by sea level.

But is height measured along the gravitational vertical, along a line
extending through the centre of the earth, or along a normal to your
reference surface ? All three can produce different values.

      Identifiers without a height component are taken to identify the
      point on the surface of the earth at that location.

This is not always a unique value.

Things that a location reference should also be able to indicate:
* What is the precision of the measurement (and where does the stated
  coordinate lie within that precision; UK grid references always give
  the south-west corner of the error square) ?
* What is the *size* of the referred-to rectangle, which might not be
  the same as the precision ?
* Sometimes I want to give height above ground, not above sea level.
  Or height measured using some standard mechanism (e.g. aircraft above
  a certain altitude use altimeter readings with 1013kPa set,
  irrespective of the actual air pressure at sea level).

---

From: Toby Speight <[email-masked]>
Date: Tue, 11 Sep 2001 17:22:41 +0100

0> In article <575456.1000108077@localhost>,
0> Patrik A. Fältström <URL:mailto:[email-masked]> ("Patrik") wrote:

Patrik> --On 2001-09-09 23.06 -0400 Al Gilman <[email-masked]> wrote:

>> I'm pretty sure that altitude is undefined without specifying what
>> model you are using for the shape of the zero altitude surface.
>> Latitude could show similar effects.

Patrik> It's just extremely important that the datum is chosen and
Patrik> specified in extreme detail.  Also the grammar needs to be
Patrik> defined in great(er) detail.
Patrik>
Patrik> The devil is really in the details regarding location
Patrik> specifications.

For some background reading on this subject, try the Ordnance Survey's
"A guide to coordinate systems in Great Britain"[1], which also has
much of relevance to other regions.

[1] <URL:http://www.badc.rl.ac.uk/coordinates/ordnance_survey/OSGB.pdf>