Subject: Re: [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: Peter Saint-Andre <[email-masked]>
Date: Tue, 02 Jun 2009 06:00:35 -0600

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

+1

Peter

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

---

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: 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: [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: 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: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: 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: Ted Hardie <[email-masked]>
Date: Tue, 2 Jun 2009 14:51:19 -0700

At 2:20 PM -0700 6/2/09, Carl Reed wrote:
>
>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

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

>EXAMPLE: upos://scientists.org/uk1_scientist/charles_darwin
>
>EXAMPLE: upos://164.125.2.5:1028/uk1_scientist/charles_darwin
>
>
>----- Original Message -----
>From: "Andy Mabbett" <[email-masked]>
>To: <[email-masked]>; "GEOPRIV" <[email-masked]>
>Sent: Tuesday, June 02, 2009 3:02 PM
>Subject: [Geopriv] [VCARDDAV] The "geo" URI draft
>
>

---

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

---

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

------------------------------------------------------------------------------------------------
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: "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