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
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Ted Hardie
> Sent: Thursday, 4 June 2009 6:38 AM
> To: Richard Barnes
> Cc: GEOPRIV; vcarddav@ietf.org
> Subject: Re: [Geopriv] [VCARDDAV] The "geo" URI draft
>
> At 11:34 AM -0700 6/3/09, Richard Barnes wrote:
> >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
> >
>
> 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
>
>
> >
> >Ted Hardie wrote:
> >> At 8:24 AM -0700 6/3/09, Carl Reed wrote:
> >>> I can check.
> >>>
> >>> 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
> >>
> >>
> >>
> >>> ----- Original Message -----
> >>> From: "Alexander Mayrhofer" <alexander.mayrhofer@nic.at>
> >>> To: "GEOPRIV" <geopriv@ietf.org>; <vcarddav@ietf.org>
> >>> Sent: Wednesday, June 03, 2009 7:18 AM
> >>> Subject: Re: [Geopriv] [VCARDDAV] The "geo" URI draft
> >>>
> >>>
> >>>>
> >>>>> Also, the forthcoming Galileo system:
> >>>>>
> >>>>> <http://en.wikipedia.org/wiki/Galileo_positioning_system>
> >>>>>
> >>>>> 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/Conferen
> c
> >>>> 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
> >>>> _______________________________________________
> >>>> Geopriv mailing list
> >>>> Geopriv@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/geopriv
> >>> _______________________________________________
> >>> Geopriv mailing list
> >>> Geopriv@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/geopriv
> >>
> >> _______________________________________________
> >> Geopriv mailing list
> >> Geopriv@ietf.org
> >> https://www.ietf.org/mailman/listinfo/geopriv
> >>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
------------------------------------------------------------------------------------------------
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
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
