Subject: Re: [Geopriv] Draft Updates 'GEO TAGS for HTML and HTTP' and Request for re listing in the GEOPRIV Chart

From: "Carl Reed OGC" <[email-masked]>
Date: Mon, 9 May 2005 15:22:17 -0600

Sorry for the delay in responding. I have been traveling for the last five weeks.

I am totally in agreement that a GEO-TAG needs to be as simple as possible but at the same time allow for richer expressions (and the requirement of the implementer). On the simple side, default to WGS 84 and use a simple point geometry (x,y or x,y,z). However, even at that very simple level, it would sure be nice to be harmonized with the interface best practices for things geospatial as defined and agreed to by both the OGC and the ISO TC 211 communities. For example, how the actual geographic (Lat/Long(s)) are expressed. And how z above or below the datum is expressed and what are the units of measurement.

The OGC members have defined a number of interfaces that use http. By way of example, consider the OpenGIS Web Map Service standard. This standard (now also an ISO standard) defines a simple HTTP protocol whereby a client (or another service) can request a map image from one or more map servers. The most basic call defines a coordinate reference system, such as WGS 84, an area of interest, and the map layers required. The results is returned as a PNG, GIF, JPEG etc image. All returned images are georegistered so they can be overlaid. Basically, this is a simple standardized query protocol. Now, drilling in a bit more:

For Coordinate Reference: From the WMS spec EXAMPLE "CRS:84" refers to WGS 84 geographic longitude and latitude expressed in decimal degrees, with longitude ranging from -180 degrees to +180 degrees and latitude from -90 degrees to +90 degrees. This is not much different from Kaegi's proposal (WMS also has more on the semantics) but is now harmonized with the wording with the relevant work of the OGC and ISO. Along the same lines, the OGC uses WGS84 as the default for our http based specs. So, I would not allow any ambiguity. The geo-header must at a minimum be WGS 84. Now, after that, things can get more interesting by allowing the application to specify coordinate systems other than WGS 84 :-)

Now for Vertical Datum. Just as a point of reference, this is actually the WGS 84 Geoid. A new gravitational model was defined in 1996 which provided greater accuracy. This refined geoid is referred to as the WGS 84 EGM96 Geoid. The only reason I bring this up is that groups such as petroleum and mineral exploration groups will want this type of clarity. Does not change the proposed header definition. This is information that should be added.

So, from my perspective, the geo-header definition is very close to much of the work in the OGC. What I would propose (if it is OK) is to share the draft-daviel-kaegi-http-geo-header-05 document with the OGC membership and ask for comments.

"Everything should be made as simple as possible, but no simpler." -Albert Einstein

Regards

Carl Reed
CTO
OGC

----- Original Message ----- 
From: "Egil Kvaleberg" <[email-masked]>
To: <[email-masked]>
Cc: "Carl Reed" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, March 24, 2005 7:00 AM
Subject: Re: [Geopriv] Draft Updates 'GEO TAGS for HTML and HTTP' and Request for re listing in the GEOPRIV Chart

> Carl Reed wrote:
> 
>>Sorry the delay in responding. I need to re-read these documents and then
>>summarize them to the membership of the Open Geospatial Consortium (OGC).
>>The OGC membership has been and is developing interface and encoding
>>standards that enable interoperability and integration of geospatial
>>content and services in a variety of environments, including web services
>>SOAs, enterprise applications, portals, location services stacks, and so
>>forth. I believe that our membership could provide excellent guidance in
>>the context of GEO TAGS for HTML and HTTP.
>>  
>>
> Speaking very much from the sideline here (currently working to organize 
> geographic information in Wikipedia, http://en.wikipedia.org/, via a GIS 
> type extension), I very much see the time is over-ripe for a KISS and 
> straight forward meta tag that  includes the geographic position along 
> with a minimum of extra information.
> 
> These drafts seem to be pretty much spot on for our needs, and the 
> concept also seems to be extendable in the future. In my view, if these 
> drafts can be promoted to a higher status (RFC?) by some simple 
> extensions (like locking to WGS84, and mentioning that there is a 
> privacy concern more or less similar to publishing your street address), 
> them I am personally very much in favor of doing so, instead of waiting 
> for perhaps large and complex solutions to what is really a small problem.
> 
> Regards,
> Egil Kvaleberg
> Oslo, Norway
> 
>

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv