Subject: Re: [Geopriv] [VCARDDAV] The "geo" URI draft

From: "Alexander Mayrhofer" <[email-masked]>
Date: Tue, 2 Jun 2009 13:24:00 +0200

> >As i just mentioned in the WG session, the draft is
> >
> >http://tools.ietf.org/html/draft-mayrhofer-geopriv-geo-uri-01
> 
> I think this should include optional parameters to indicate 
> the use of 
> non-WGS84 reference systems, including other reference systems for 
> Earth, and those for bodies such as the Moon and Mars.

Andy,

Thanks for the reminder. One of the goals of the "geo" URI (and that was
also welcomed and understood by the GEOPRIV community) is that we keep
the format as simple as possible, so that it can fill the gap between
the "complicated" geo-location formats that allow for multiple reference
systems, and even other bodies besides earth, and the heavily
underspecified "lat,lon" pairs that don't even define which reference
system to use.

I'm therefore tempted to declare both "other reference systems" and
"other bodies besides planet earth" out of scope for the "geo" URI - and
my impression from numerous hallway discussions is that this is also the
concensus of the GEOPRIV group. I haven't seen many people pushing for
alternative reference systems, and only one person (afair) pushing for
representation of coordinates on other bodies.

Let's keep it simple, and usable, please.

Alex

---

From: Simon Perreault <[email-masked]>
Date: Tue, 02 Jun 2009 08:10:30 -0400

Alexander Mayrhofer wrote:
> "other bodies besides planet earth" out of scope for the "geo" URI

Just to clarify the potential implications for Andy: vCard's GEO 
property takes as value any URI. The "geo" URI is just one possibility. 
You would be free to define your own URI scheme that would have the 
features you desire. That would imply writing a draft, similarly to the 
draft defining the "geo" URI.

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Richard Barnes <[email-masked]>
Date: Tue, 02 Jun 2009 08:28:44 -0400

Also, if Martian addresses really become an issue (or even other Terran 
CRSes), I'm sure we could add a "datum" option whose absence indicates 
WGS84.  Extensibility here is pretty trivial, so I'm inclined to stick 
with one CRS for now.

--Richard

Alexander Mayrhofer wrote:
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: Dan Brickley <[email-masked]>
Date: Tue, 02 Jun 2009 15:20:43 +0200

+cc: harry halpin

> draft defining the "geo" URI.

Is it also considered reasonable in the new vCard spec to use http: URIs 
where the value points (indirectly) into a description of a place, such 
that the whole thing is intended to directly identify the place. There's 
an increasing amount of RDF data in the Web that works this way, 
including dbpedia.org and geonames,
eg. see http://www.geonames.org/ontology/

[[
GeoNames is using 303 (See Other) redirection to distinguish the Concept 
(thing as is) from the Document about it.

For the town Embrun in France we have these two URIs :
[1] http://sws.geonames.org/3020251/
[2] http://sws.geonames.org/3020251/about.rdf

The first URI [1] stands for the town in France. You use this URI if you 
want to refer to the town. The second URI [2] is the document with the 
information geonames has about Embrun. The geonames web server is 
configured to redirect requests for [1] to [2].
]]

The equivalent in dbpedia for this place is
http://dbpedia.org/resource/Embrun%2C_Hautes-Alpes
& http://dbpedia.org/page/Embrun%2C_Hautes-Alpes
(derrived from wikipedia data originally)

cheers,

Dan

---

From: Richard Barnes <[email-masked]>
Date: Tue, 02 Jun 2009 09:54:06 -0400

I don't know what the answer to your question is with respect to vCard, 
but it's certainly coherent with what we've been doing in GEOPRIV to 
represent location as a URI.  In these parts, we tend to use the phrase 
"location by reference":
<http://tools.ietf.org/html/draft-ietf-geopriv-lbyr-requirements>

--Richard

---

From: "Marc Berryman" <[email-masked]>
Date: Tue, 2 Jun 2009 09:09:04 -0500

We should adhere to the use of the World Geodetic System 1984 Standard -
WGS84.
Any other geodetic system can be transformed from the WGS84 system. Keep
it simple and standardized so there are no surprises.

Marc Berryman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alexander Mayrhofer
Sent: Tuesday, June 02, 2009 6:24 AM
To: Andy Mabbett; [email-masked]
Cc: GEOPRIV
Subject: Re: [Geopriv] [VCARDDAV] The "geo" URI draft

Andy,

Alex

---

From: Ted Hardie <[email-masked]>
Date: Tue, 2 Jun 2009 09:46:15 -0700

>WGS84.  Extensibility here is pretty trivial, so I'm inclined to stick

Speaking personally, I think this is the right way to go; URI formats
can live a long time, and the emergence of other datums for terrestrial
systems may occur within the lifetime of the scheme.  Add an optional
parameter datum, allow it to take an arbitrary value, and specify
that its absence means WGS84 and you are done.

				regards,
					Ted

---

From: Ted Hardie <[email-masked]>
Date: Tue, 2 Jun 2009 09:52:28 -0700

>it simple and standardized so there are no surprises.

As long as the other datum can be named in a parameter, there are no surprises;
if you see a triple with a named datum in that parameter, you use that datum
to understand the reference.  Else, you use the default--WGS84.

Is it simple?  In the case where WGS84 is in use, yep it is as simple as the
geo URI as currently described.  It is also more extensible--with the URI
syntax giving you the ability to get that extensibility while giving you
a useful default.
			regards,
				Ted

---

From: "Marc Berryman" <[email-masked]>
Date: Tue, 2 Jun 2009 12:02:12 -0500

Agree, extensible and simple.

Marc B
-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Tuesday, June 02, 2009 11:52 AM
To: Marc Berryman; Alexander Mayrhofer; Andy Mabbett; [email-masked]
Cc: GEOPRIV
Subject: Re: [Geopriv] [VCARDDAV] The "geo" URI draft

>it simple and standardized so there are no surprises.

As long as the other datum can be named in a parameter, there are no
surprises;
if you see a triple with a named datum in that parameter, you use that
datum
to understand the reference.  Else, you use the default--WGS84.

Is it simple?  In the case where WGS84 is in use, yep it is as simple as
the
geo URI as currently described.  It is also more extensible--with the
URI
syntax giving you the ability to get that extensibility while giving you
a useful default.
			regards,
				Ted

---

From: Simon Perreault <[email-masked]>
Date: Tue, 02 Jun 2009 14:33:30 -0400

> syntax giving you the ability to get that extensibility while giving you

The problem with this is that usually when an implementation doesn't understand
a URI parameter, it will just ignore it and parse the rest of the URI and use it
as if the parameter wasn't there. In these cases the content would parse as a
WGS84 location but would be wrong.

And I predict that most implementations of the "geo" URI will ignore the
parameter and assume WGS84, given that the parameter will very rarely be present.

This is an interoperability trap.

Simon

---

From: Ted Hardie <[email-masked]>
Date: Tue, 2 Jun 2009 11:54:23 -0700

>WGS84 location but would be wrong.

If it sees a parameter that it doesn't understand, its behavior should be
controlled by the spec.  Some parameters are safe to ignore; some should
cause you to throw an error.  The spec should be crystal clear on which
this is.  If it is not, it's a spec bug.

If the spec is clear about what you should do, and the app doesn't do it,
it is broken.  There have been obvious cases where the common app
pool doesn't do what the spec says and a feature gets dropped as result.
But avoiding extensibility because that *might* happen seems to me
not value extensibility enough.

Sure, we can always mint a new URI scheme to get around the problem later,
but that gives you worse interoperability problems, at least as I see it.
			regards,
				Ted

PS.  I removed the vcarddav list from the cc, after an exchange with one
of chairs; feel free to forward there if you feel it is still important to
cross-post.  I would guess, however, that we should finish this discussion
in GEOPRIV.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 02 Jun 2009 20:06:36 +0100

>parameter and assume WGS84, given that the parameter will very rarely be present.
I tend to agree with Ted. IMHO, it would be better if extensibility can 
be added to the geo URIs now, before they are widely deployed. 
Experience with mailto: URIs suggests that it is much more painful 
adding extensibility after the fact.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 02 Jun 2009 15:09:02 -0400

Ted Hardie wrote, on 2009-06-02 14:54:
> it is broken.

Of course. That's not the point.

The point is that if the spec says that the main content of the URI is to be
parsed according to a parameter, which will very often be absent, but when it is
present the content looks exactly the same as when it is present but does not
mean the same thing at all, then you're setting up an excellent interoperability
trap for naive implementers (you know, the usual kind).

The fact that implementers and their applications would be wrong is irrelevant.

Now, something more constructive:

Making the parameter mandatory, even maybe promoting it to a hierarchy element,
would probably result in better interoperability. How would people feel about this?

geo:wgs84:12.34,56.78
geo:foooo:12.34,56.78

Thanks,
Simon

---

From: [email-masked]
Date: Tue, 2 Jun 2009 15:10:43 -0400 (EDT)

Marc -

Very true - as long as the usage is correctly detailed - perhaps words I
have written and reused on numerous occasions. I need to check the latest
draft of this document.

Thanks

Carl

---

From: Ted Hardie <[email-masked]>
Date: Tue, 2 Jun 2009 12:19:16 -0700

A
>would probably result in better interoperability. How would people feel about this?

Do you mean for this to be in the "authority" section of the URI? 
that would probably look something like geo://wgs84/?12.34,56.78
Note that this uses the "registered name" authority production,
and it treats the lat/long as query elements.  You'd probably really
want to include lat=, long=, and alt= to make that work really
well. 
			regards,
				Ted

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 02 Jun 2009 13:23:02 -0600

> that would probably look something like geo://wgs84/?12.34,56.78

Why not "wgs84:12.34,56.78"? Not as catchy as "geo:", but clear. Those
foooo people can define their own URI scheme later on...

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 2 Jun 2009 21:36:14 +0100

In message <[email-masked]>, Simon Perreault 
<[email-masked]> writes

>draft defining the "geo" URI.

Thank you. Though I could indeed define my own URI scheme, I'm not clear 
how that would contribute to global interpretability for people 
publishing, or parsing non-WGS84 coordinates.

-- 
Andy Mabbett

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 2 Jun 2009 21:39:11 +0100

In message <[email-masked]>, Dan Brickley
<[email-masked]> writes

>GeoNames is using 303 (See Other) redirection to distinguish the
>Concept (thing as is) from the Document about it.
>

That's interesting; but some (notably proponents of RESTful URLs) advise
against using file-type extensions.

Perhaps:

        http://sws.geonames.org/3020251/

        http://sws.geonames.org/3020251/about

would suffice?

-- 
Andy Mabbett

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 2 Jun 2009 21:44:53 +0100

In message <p06240801c64b076a2929@[10.227.68.132]>, Ted Hardie
<[email-masked]> writes

>>WGS84.  Extensibility here is pretty trivial, so I'm inclined to stick

Martin coordinates are already published on the web; I gathered some
examples here:

  <http://microformats.org/wiki/index.php?title=mars-examples&oldid=32233>

in the context of the "geo" microformat.

>parameter datum, allow it to take an arbitrary value, and specify that
>its absence means WGS84 and you are done.

That's exactly my proposal.

-- 
Andy Mabbett

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 2 Jun 2009 21:57:12 +0100

In message
<[email-masked]>, Marc
Berryman <[email-masked]> writes

>We should adhere to the use of the World Geodetic System 1984 Standard
>- WGS84.

WGS84 is indeed a 1984 standard. Its predecessor was issued in 1972.
Who's to say there won't be another revision in, say 2014? Surely we
should allow for such an event?

Also, the forthcoming Galileo system:

        <http://en.wikipedia.org/wiki/Galileo_positioning_system>

will not, I understand, use WGS84.

>Any other geodetic system can be transformed from the WGS84 system.

How would you convert this set of coordinates:

        1.98 S, 353.82 E

to WGS84? (It might help to bear in mind that they're on Mars, not
Earth.)

-- 
Andy Mabbett

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 2 Jun 2009 22:00:25 +0100

In message <[email-masked]>, Simon Perreault
<[email-masked]> writes

>Making the parameter mandatory, even maybe promoting it to a hierarchy
>element, would probably result in better interoperability. How would
>people feel about this?
>
>geo:wgs84:12.34,56.78
>geo:foooo:12.34,56.78

and...

In message <[email-masked]>, Peter Saint-Andre
<[email-masked]> writes

>Why not "wgs84:12.34,56.78"?

Either model would be OK by me; as would:

        geo-wgs84:12.34,56.78
        geo-foooo:12.34,56.78

-- 
Andy Mabbett

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 2 Jun 2009 22:02:40 +0100

In message <[email-masked]>, Andy Mabbett
<[email-masked]> writes

>That's interesting; but some (notably proponents of RESTful URLs)
>advise against using file-type extensions.
>
>Perhaps:
>

On reflection:

        http://sws.geonames.org/about/3020251/

or even:

        http://sws.geonames.org/place/3020251/

        http://sws.geonames.org/about/3020251/

may be better.

-- 
Andy Mabbett
            Says  "NO! to compulsory UK ID Cards":  <http://www.no2id.net/>
            and:  "Free Our Data":  <http://www.freeourdata.org.uk>
                   (both also on Facebook)

---

From: "Tatham Oddie" <[email-masked]>
Date: Wed, 3 Jun 2009 07:15:47 +1000

Hi Andy,

I personally think the datum information should be part of the URI content
and not part of the scheme as proposed by "geo-wgs84:" and "geo-fooo:"

Applications are registered at the OS and browser levels to a particular
scheme, which in this case would be "geo". Pushing datum information to the
scheme means that an application will have to register for every possible
datum that it supports and provide no capacity for it to attempt to handle
other datums. It would be somewhat akin to having each different HTTP
authentication mechanism exposed as "http-basic:", "http-ntlm:", etc.

Further, it would require an additional IANA registration every time a new
datum was considered (http://www.iana.org/assignments/uri-schemes.html).

As such, I'd propose to stick to something like "geo:wgs84:12.34,56.78" and
"geo:foo:12.34,56.78".

Thanks,

Tatham Oddie
au mob: +61 414 275 989, us cell: +1 213 422 7068, skype: tathamoddie,
landline: +61 2 8011 3982, fax: +61 2 9475 5172
my business: tixi.com.au - Ticketing without the dramas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Andy Mabbett
Sent: Wednesday, 3 June 2009 7:00 AM
To: GEOPRIV
Subject: [Geopriv] The "geo" URI draft

and...

        geo-wgs84:12.34,56.78
        geo-foooo:12.34,56.78

---

From: "Carl Reed" <[email-masked]>
Date: Tue, 2 Jun 2009 15:20:38 -0600

Just to jump in:

There is a related ISO TC 211 activity similar to this proposal - but more 
broad reaching (19151 - Geographic information - Logical position 
identification scheme). They already have a level 0 document (first step on 
the ISO standards track). I have to find out if I can share the draft 
document. At a TC 211 meeting last week, I suggested they consider the work 
of the GeoPRIV community. FYI, the submission team has working 
implementations.

Regards

Carl

PS: From the document

1         u-position naming scheme(u-position URI)
The u-position is a logical and seamless spatial reference in the form of a 
label or a code that identifies a location. Naming scheme of the 
u-position(called u-position URI) is defined based on URI syntax and ABNF 
notation, as described in IETF RFC 3986(Uniform Resource Identifier (URI) : 
Generic Syntax) and RFC2234(ABNF: the Augmented Backus-Naur Form). The 
u-Position URI is used to indicate or access spatial information. The 
u-Position URI syntax consists of a hierarchical sequence of four components 
referred to as the scheme, host, port, and path_upos. The scheme, host, 
path_upos are required, and the port is optional. 'path_upos' must begin 
with a slash ("/").

u-Position URI = "upos" ":" "//" host [ ":" port ] path-upos

EXAMPLE: upos://scientists.org:1028/charles_darwin

EXAMPLE: upos://scientists.org/uk1_scientist/charles_darwin

EXAMPLE: upos://164.125.2.5:1028/uk1_scientist/charles_darwin

---

From: "Carl Reed" <[email-masked]>
Date: Tue, 2 Jun 2009 15:25:32 -0600

How about a more generic approach in which the EPSG codes are used instead 
of a specific datum name (which may not have international agreement if 
defined by this group!). The EPSG code for WGS 84 2d is 4326. Or you could 
use the normative name as defined in the EPSG database. There is an online 
registry so that any code/name could be resolved by the application and all 
of the pertinent (and normative) CRS metadata is made accessible.

This is the approach we use in the OGC for any and all CRS references in any 
of our standards - as does ISO and more recently OASIS.

And finally, WGS 84 is not purely a datum. WGS 84 comprises a standard 
coordinate frame for the Earth, a standard spheroidal reference surface (the 
datum or reference ellipsoid) for raw altitude data, and a gravitational 
equipotential surface (the geoid) that defines the nominal sea level.

Cheers

Carl

----- Original Message ----- 
From: "Tatham Oddie" <[email-masked]>
To: "'Andy Mabbett'" <[email-masked]>; "'GEOPRIV'" 
<[email-masked]>
Sent: Tuesday, June 02, 2009 3:15 PM
Subject: Re: [Geopriv] The "geo" URI draft

---

From: Ted Hardie <[email-masked]>
Date: Tue, 2 Jun 2009 14:51:19 -0700

>EXAMPLE: upos://scientists.org:1028/charles_darwin

Well, this may be obvious when or if you can share
the document, but this syntax and example set seems
to be a pointer mechanism for grabbing spatial information,
rather than a mechanism for including it.  The geo
URI that's been discussed here seems to be for URI-format
geo information, rather than a protocol that tells
you where to go get it.

Am I misunderstanding this?
			regards,
				Ted

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 2 Jun 2009 19:27:37 -0500

Gee I like design-by-committee.

This thread seems to have lost sight of the original design goals of this work: cheap and simple.

Now we could worry about the impact of a new coordinate reference systems, but whatever we choose, two things happen: we start paying a price now; we probably get it wrong.

The only think that I am certain we can get right now is a version tag (which it seems that we've started to use datum/CRS tags for recently).  So maybe that's the way to go--an optional version tag that forces the receiver to drop the whole payload if it isn't the expected value.  There's a little cost involved, but at least we know how to do that part right.  

Even then, I'm not convinced that we need to do this given the relative ease with which we are able to convert between different systems.  Of course, to do that with the utmost precision, we'd need to include a time parameter to allow for continental drift adjustments...  And then we can add location type parameters, maybe mood.

As for extraplanetary locations, these aren't really compatible with the idea of "simple".  If we want to go off planet, maybe we wont be able to take our geo: URIs with us.  I can live with that.

Furthermore, <http://microformats.org/wiki/index.php?title=mars-examples&oldid=32233> was used to support an argument for the addition of extraterrestrial positions.  Strange, because it uses a completely different tag to identify the microformat describing a position on Mars; 'mars' instead of 'geo'.  That suggests that if I wanted to identify the Spirit landing site I would use 'mars:-14.5718,175.4785'.  All in all, an elegant solution (thanks Peter :).

--Martin
------------------------------------------------------------------------------------------------
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: Dan Brickley <[email-masked]>
Date: Tue, 02 Jun 2009 23:14:42 +0200

On 2/6/09 22:39, Andy Mabbett wrote:
> In message<[email-masked]>, Dan Brickley

Yup, I'd prefer the latter pattern personally too. But that's a matter 
for geonames really; nothing compels us to read the "." as a filename 
suffix, and it probably is implemented by some kind of db lookup in 
practice.

cheers,

Dan

---

From: Richard Barnes <[email-masked]>
Date: Tue, 02 Jun 2009 20:51:38 -0400

I think this is an OK idea, but not inconsistent with having WGS84 as 
the only CRS in the first draft.  The extension that allows alternate 
CRSes can use the EPSG numbers instead of special names.

--Richard

Carl Reed wrote:
> How about a more generic approach in which the EPSG codes are used 
> instead of a specific datum name (which may not have international 
> agreement if defined by this group!). The EPSG code for WGS 84 2d is 
> 4326. Or you could use the normative name as defined in the EPSG 
> database. There is an online registry so that any code/name could be 
> resolved by the application and all of the pertinent (and normative) CRS 
> metadata is made accessible.
> 
> This is the approach we use in the OGC for any and all CRS references in 
> any of our standards - as does ISO and more recently OASIS.
> 
> coordinate frame for the Earth, a standard spheroidal reference surface 
> (the datum or reference ellipsoid) for raw altitude data, and a 
> gravitational equipotential surface (the geoid) that defines the nominal 
> sea level.
> 
> Cheers
> 
> Carl
> 
> ----- Original Message ----- From: "Tatham Oddie" <[email-masked]>
>> Behalf

---

From: [email-masked]
Date: Wed, 3 Jun 2009 10:13:05 +0100

> As for extraplanetary locations, these aren't really compatible with
> the idea of "simple".  If we want to go off planet, maybe we wont be
> able to take our geo: URIs with us.  I can live with that.
> 
> Furthermore, <http://microformats.org/wiki/index.php?title=mars-
> examples&oldid=32233> was used to support an argument for the 
> addition of extraterrestrial positions.  Strange, because it uses a 
> completely different tag to identify the microformat describing a 
> position on Mars; 'mars' instead of 'geo'.  That suggests that if I 
> wanted to identify the Spirit landing site I would use 'mars:-14.
> 5718,175.4785'.  All in all, an elegant solution (thanks Peter :).

+1

People should remember that 'geo' means 'Earth' ...

Ray

---

From: "Andy Mabbett" <[email-masked]>
Date: Wed, 3 Jun 2009 13:03:49 +0100 (BST)

>> the idea of "simple".

Do you have any evidence to support that claim, or is it merely an opinion?

>>If we want to go off planet, maybe we wont be

We can live with it, but why should we?

Non-terrestial coordinates are already published, and can already be in
apps like Google Moon (evidence on aforementioned microformats page).

>> position on Mars; 'mars' instead of 'geo'.

That was an early brainstorm and was provided merely and explicitly as a
repository of examples of published non-terrestrial coordinates; it is
superseded (as made clear at <http://microformats.org/wiki/mars>) by the
later straw-man proposal (already supported in some microformat parsers)
at:

    <http://microformats.org/wiki/geo-extension-strawman>

which uses "geo" for all bodies.

> People should remember that 'geo' means 'Earth' ...

Etymologically, perhaps, but Geo has "been generalized for the planetary
case", according to GEOdesists from the AstroGEOlogy Team, U.S. GEOlogical
Survey, who map the GEOlogoy and GEOgraphy of other bodies:

    <http://microformats.org/wiki/geo-extension-nonWGS84#thare>

-- 
Andy Mabbett
** via webmail **

---

From: "Andy Mabbett" <[email-masked]>
Date: Wed, 3 Jun 2009 13:10:24 +0100 (BST)

> Non-terrestrial coordinates are already published, and can already be in

I meant to go on to say:

...so why should users (or users' bots) not be able to map, parse and
aggregate them in the same way that they can for terrestrial coordinates?

-- 
Andy Mabbett
** via webmail **

---

From: Dan Brickley <[email-masked]>
Date: Wed, 03 Jun 2009 14:20:07 +0200

> aggregate them in the same way that they can for terrestrial coordinates?

Following this line of thinking, shouldn't we also include imaginary 
planets too, since the Web and human literature contains more references 
to locations on fictional planets than real ones?

But perhaps geo: could be specified for Earth in the meantime?

Could an escape code or sub-namespace be left in the geo: spec, such 
that future revisions could be made without needing to move to a new URI 
scheme?

Dan

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Wed, 3 Jun 2009 15:18:09 +0200

> will not, I understand, use WGS84.

I don't claim to be an expert in reference systems / geopotential models
etc. so please take the following information with caution (Carl? ;) 

I couldn't find any information about the reference system that Galileo
uses on the wikipedia page. However, a bit of research shows that
Galileo seems to use ITRF ("International Terrestrial Reference Frame"),
which, however, seems to be practically identical to WGS84, according to
http://www.dqts.net/wgs84.htm (web site by EUROCONTROL). Also, this
http://www.cambridgeconference.com/2007_conference_information/Conferenc
e%20proceedings/w2_5_cross.pdf presentation notes on slide 15 that
"WGS84 and IRTF are aligned".

Which means that Galileo will use a reference system that is practically
identical to WGS84.

Again, Disclaimer: i'm not an expert in this field.

Alex

---

From: Richard Barnes <[email-masked]>
Date: Wed, 03 Jun 2009 09:29:11 -0400

+1

I'm pretty sure that extraterrestrial coordinates are outside the scope 
of this WG.  Those who are interested should feel free to propose a 
charter update in the future.

--Richard

---

From: [email-masked]
Date: Wed, 3 Jun 2009 15:53:51 +0100

> charter update in the future.

Can't we have a MarsPriv BOF instead? ;-)

Ray

---

From: "Andy Mabbett" <[email-masked]>
Date: Wed, 3 Jun 2009 15:59:55 +0100 (BST)

"Richard Barnes" <[email-masked]> wrote:

> of this WG.

Isn't that a circular argument?

Put another way: if this WG is responsible for GeoURI; and GeoURI should/
could include non-terrestrial coordinates; then it must follow that
non-terrestrial coordinates are within scope.

-- 
Andy Mabbett
** via webmail **

---

From: Richard Barnes <[email-masked]>
Date: Wed, 03 Jun 2009 11:09:24 -0400

> Isn't that a circular argument?

Nope.  The WG is chartered to work on geolocation-specific protocols and 
data formats (interpreting geolocation to mean "Earth"), so even through 
it may be possible for the Geo URI to accommodate other planets, this WG 
isn't the place to work on them (without a change in the charter).

That doesn't mean that a Geo URI for this planet is out of scope.

--Richard

---

From: "Carl Reed" <[email-masked]>
Date: Wed, 3 Jun 2009 09:24:53 -0600

I can check.

Carl

---

From: Ted Hardie <[email-masked]>
Date: Wed, 3 Jun 2009 11:22:24 -0700

>Carl

Both Galileo and GLONASS use datums which are distinct from
WGS84.  PZ-90, which is the datum used by GLONASS,  does differ
from WGS84, though the difference is minor (Wikipedia puts
it as "less than 40cm in any given direction"). 

In some applications, 40cm is significant, and if you can eliminate
an error by noting that the reference datum was PZ-90 rather
than WGS84, it seems useful to me personally to do so. 

To back up a step, I have to ask what we think we're getting
by using a URI here.  This is clearly not a URI intended to be
used to trigger protocol processing; it is instead a way of
capturing the context of the data.  For those of us who use
GPS and systems designed to work with GPS, lat, long, altitude
and WGS84 are the syntax and context for location.  This
group could agree to mint a URI scheme that works only
in that context and it would have a very simple syntax. 

It could instead have a slightly more general syntax and
mechanism for indicating context (the parameter indicating
datum).  I think the latter is more in keeping with the purpose
of URIs.  Shorn of even the possibility of using new or different
datums, I think we will either see other URI schemes,
the same URI schemes used with different datums (thus introducing
invisible differences in reference coordinates).  Though I
usually fall into the "strings are cheap" view of URI schemes,
having a URI proliferation like geo:, geoGLONASS:, geoWGS84-2009:
etc strikes me as unlikely to be a long term win.  And having
folks use the same URI scheme with different but unmarked
datums makes me very concerned indeed.

The parameter method suggested before is easy to specify,
relatively cheap to parse, and it meets my personal test
for simplicity.  I understand it doesn't meet others, but
speaking personally, I think the resistance to it doesn't
match the real likelihood of problems.  Unless someone
builds a parser without reading the spec or referring to
a standard URI library, there's a fair chance they'll get it
right. 

My two cents,
			Ted

---

From: Richard Barnes <[email-masked]>
Date: Wed, 03 Jun 2009 14:34:15 -0400

Ted,

I agree with what you're saying, but the actions implied aren't clear. 
Do you think we should go ahead and define a datum parameter, or just 
not preclude one?  If we do, do we define values, and are clients 
required to process it?

--Richard

---

From: Ted Hardie <[email-masked]>
Date: Wed, 3 Jun 2009 13:37:46 -0700

>not preclude one?  If we do, do we define values, and are clients

I think we should have a datum parameter; I think we can do that
and give it a default value to be assumed when it is not present.
We should define the behavior for clients when they see a parameter
they do not understand. 

The current doc has this syntax:

geo-URI       = geo-scheme ":" geo-path
             geo-scheme    = "geo"
             geo-path      = geo-location

             geo-location   = latitude "," longitude [ "," altitude ]

             latitude       = [ "-" ] 1*2DIGIT [ "." *DIGIT ]
             longitude      = [ "-" ] 1*3DIGIT [ "." *DIGIT ]
             altitude       = [ "-" ] *DIGIT [ "." *DIGIT ]

I think we could generalize this to be
x, y, z, with the datum defining the units
for x, y, z.  Add an optional parameter that
is datum=1*CHAR and specify that
it has a default value of WGS84.  When it is
WGS84, x is degrees with the value limitations
currently in the draft, y is degrees with the
value limitations currently in the draft,
and z is altitude in meters, with the caveats
about *not assuming it means zero when
it is not present*.

Definitions of other datums are left for other
documents.  We could specify a registry (either
an existing registry or an IANA one), but I
personally don't see a great need for that.

Again, just my two cents,
			Ted

---

From: Andy Mabbett <[email-masked]>
Date: Wed, 3 Jun 2009 22:37:55 +0100

In message <p06240814c64c6c0e08eb@[10.227.68.132]>, Ted Hardie 
<[email-masked]> writes

> Shorn of even the possibility of using new or different datums, I 
>think we will
[...]
>invisible differences in reference coordinates).
[...]
>having folks use the same URI scheme with different but unmarked datums 
>makes me very concerned indeed.

Anecdotally, my experience of seeing other editors on Wikipedia enter 
non-WGS84 coordinates into templates intended for WGS84, on numerous 
occasions, is that this is what does happen.

-- 
Andy Mabbett

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 3 Jun 2009 20:18:13 -0500

I can verify.  Galileo will _NOT_ use WGS84, but for all practical purposes, the CRS that they intend to use will be the same.  Differences are likely to be in the order of a centimetre.  

Conversion is in theory necessary, but only for extreme cases.  In most cases, coordinates will be close enough that the difference has no practical impact.

> Behalf Of Carl Reed
> Sent: Thursday, 4 June 2009 1:25 AM
> To: Alexander Mayrhofer; GEOPRIV; [email-masked]

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 3 Jun 2009 20:41:11 -0500

I have no problem with this particular complication, it's not that hard to implement.  I do caution that down this path lies GML.

However, based on Carl's suggestion, this should not be 'datum', but 'crs'.

  e.g. geo:-43,150?crs=xxx

Establish a registry if you see fit, but I don't think that's necessary.  I'd prefer to avoid defining a registry, but mandate the creation of one if ever someone wants to define a new CRS.  Simply indicate that absence of this parameter implies WGS84/EPSG4979/EPSG4326/whatever.

--Martin

> Behalf Of Ted Hardie
> Sent: Thursday, 4 June 2009 6:38 AM
> To: Richard Barnes
> Cc: GEOPRIV; [email-masked]

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 4 Jun 2009 00:28:09 -0500

Does it really matter what Galileo, or any other GNSS, "uses"?

If I buy a Garmin receiver that has GPS internally and it displays a
particular location, I would not expect the quantity displayed to be any
different on a model that is identical other than using Galileo
internally.

The "secret business" between the receiver and the satellites is not the
same as the application/presentation. I believe the discussion is around
a simplified encoding for Internet applications. Why can't we settle,
for now, on a single reference system for Internet applications?

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Thomson, Martin
Sent: Thursday, 4 June 2009 11:18 AM
To: Carl Reed; Alexander Mayrhofer; GEOPRIV; [email-masked]
Subject: Re: [Geopriv] [VCARDDAV] The "geo" URI draft

I can verify.  Galileo will _NOT_ use WGS84, but for all practical
purposes, the CRS that they intend to use will be the same.  Differences
are likely to be in the order of a centimetre.  

Conversion is in theory necessary, but only for extreme cases.  In most
cases, coordinates will be close enough that the difference has no
practical impact.

> > which, however, seems to be practically identical to WGS84,
according
> to
http://www.cambridgeconference.com/2007_conference_information/Conferen
> c

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------

---

From: "Carl Reed" <[email-masked]>
Date: Thu, 4 Jun 2009 11:34:19 -0600

The following is an FYI and is from the lead geodesist at Royal Dutch Shell. 
My understanding of his response is that this is a non-issue for the EM 
domain. In terms of transformations, treated like any other CRS 
transformation.

Cheers

Carl

ITRS is the International Terrestrial Reference System, which is a dynamic 
reference system (we live on a dynamic earth). In principle every year a 
'snapshot' is taken, freezing the Datum and Coordinate System (in ISO 19111 
terms). These "snapshots" are called ITRFyyyy, where 'F' means 'Frame' and 
'yyyy' is the year (realization epoch). You can transform from e.g. IRTF1992 
to ITRF2005 in the same way as transform between any other two datums. See 
the EPSG database for those transformations.

ITRS is a more rigorous solution than WGS 84, which was never defined to 
deal with a dynamic earth surface. However, we know that the earth is 
dynamic, so how does WGS 84 deal with that?
WGS 84 is periodically corrected to bring it in-line with ITRS, the 
'tolerance' being 10 cm.
It means that if you would have an accurate GPS receiver on your roof you 
would see the coordinates 'drift away' slowly over time, with a periodic 
jump as well when WGS 84 is brough in line with ITRS.

Best regards,
Roel

----- Original Message ----- 
From: "Dawson, Martin" <[email-masked]>
To: "Thomson, Martin" <[email-masked]>; "Carl Reed" 
<[email-masked]>; "Alexander Mayrhofer" 
<[email-masked]>; "GEOPRIV" <[email-masked]>; 
<[email-masked]>
Sent: Wednesday, June 03, 2009 11:28 PM
Subject: RE: [Geopriv] [VCARDDAV] The "geo" URI draft

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 9 Jun 2009 13:19:27 +0100

In message <[email-masked]>, Richard Barnes <[email-masked]> 
writes

>The WG is chartered to work on geolocation-specific protocols and data
>formats (interpreting geolocation to mean "Earth"), so even through it
>may be possible for the Geo URI to accommodate other planets, this WG

I presume (and please correct me if I'm wrong to do so) you refer to 
this charter:

         <http://www.ietf.org/html.charters/geopriv-charter.html>

which makes no reference to Earth"; and that your '(interpreting 
geolocation to mean "Earth") refers to your personal interpretation.

Indeed, that charter refers to:

         geographic location information about certain resources or
         entities

which would seem to give ample scope to include the geographic location 
information about resources or entities on the Moon, Mars or wherever.

It goes on to mention:

         management of equipment in the field

for which mapping the current and past locations of the Mars landers 
would seem a perfectly acceptable use-case.

>That doesn't mean that a Geo URI for this planet is out of scope.

I'm not convinced that it means that a Geo URI for, say, Mars is out of 
scope. If it is, then I contend that the determination of the sues of 
GeoURI may well be located in the wrong WG.

-- 
Andy Mabbett

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 9 Jun 2009 13:37:55 +0100

In message <[email-masked]>, Dan Brickley 
<[email-masked]> writes

>planets too, since the Web and human literature contains more 
>references to locations on fictional planets than real ones?

P.S. Please can you point to you evidence for this claim (with specific 
reference to coordinates)? Thank you.

-- 
Andy Mabbett