[OSGeo-Standards] Was: "file" formats. Is: GeoWeb

Sun Jul 14 03:39:40 PDT 2013

Folks,
you are too fast for me. Just sayin'...

Plus - mailing lists are probably no good for long time evolution of
ideas. Put the other way round: Where do we aggregate those ideas we
agree about?

More inline further below...

On 09.07.2013 22:42, Raj Singh wrote:
> Let me jump in with my problem with a Geo-REST. What are the
> resources? The resources are even more fundamental to REST than
> hypermedia because they come first. It was an easy answer for most
> multimedia. You have small resources that are either HTML files,
> images, video, etc. In GIS it's common to have multi-gigabyte files,
> so call them a resource doesn't help -- we have to break them down
> into smaller resources. Here's how I see the problem in various
> areas:
> 
> Web mapping: easiest case. Map tiles are good resources

Not sure whether I agree here. The map tiles are one representation of
the resource. The resource is the source of the data, for example a set
aerials taken at the same time and area, or for a defined region. The
resource also has other representations, for example a meta data record
of the whole thing or of each tile. The documentation of the grid
structure of the tiles is yet another representation of the same resource.

> Vector data: harder. Features are good resources, and a feature
> collection (what we often call a layer) is a good aggregate resource,

Again, not sure whether I can agree. The resource is the collection of
all the features. Then each feature can be queried in different
representations (formats). Just a simple example (not saying that this
is perfect, just for demonstration purposes):
http://data.ordnancesurvey.co.uk/doc/geometry/37256-10

Here you can get a representation of the geometry of the resource (city
area of Southampton in GML).

You can get other representations of the same object (City of
Southampton), for example some "core facts":
http://data.ordnancesurvey.co.uk/doc/7000000000037256

This (hypertext) page contains a wealth of relations (related to). And
so on...

So not sure why vector data would be more difficult than raster?

> but there are usually so many features that the only practical way to
> access them is through a query API, not hypermedia, and how RESTful
> is that?

Actually the term "Web API" in my opinion is just a misnomer for trying
to close something on the Web off of other related things. It is a
result of providers trying to prevent their users from leaving their web
site. If we apply the term "Application Programing Interface" to the Web
then the interface is HTTP. The semantics may change and there will be a
wealth of different formats but what is the reason to implement a
specific query API - or how does it differ from others?

Cheers,
Arnulf

> Imagery: hardest (IMHO). What are good resources? Individual cells?
> Those are pretty useless on their own, and once you implement a query
> API you have the same problem as you do with vector data.
> 
> So group, any good ideas on defining resources for Geo?
> 
> --- Raj The OGC: Making location count. 
> http://www.opengeospatial.org/ogc/organization/staff/rsingh
> 
> 
> On Jul 9, at 3:14 PM, "Rushforth, Peter"
> <Peter.Rushforth at NRCan-RNCan.gc.ca> wrote:
> 
>> Hi,
>> 
>> tl;dr ... apologies!  I'm keeping this to the standards list out of
>> respect for people's in-baskets.
>> 
>> I did not mean to instigate a discussion of file formats.  I have
>> my favourite formats too!  And, I don't want to lecture expert
>> technologists on technology, so I apologize if I seem to be doing
>> that...
>> 
>> Fifteen years ago or so, I thought "Web" Map Service was going to
>> be "it".  It was how I understood you put maps and the Web
>> together. But, it turns out, there's not enough Web in that or any
>> other geo service I know of.  The Web has gone on to scale up
>> exponentially in the interim, leaving behind those parochial
>> services we thought were "Web".  Yet we have kept on repeating the
>> same pattern.  More of the same is not going to help.
>> 
>> REST built the Web, and the GeoWeb needs REST in order to be built.
>> Without REST, there will be no 'Web' in Geo.
>> 
>> The reader's digest nature of REST, as originally specified, and
>> why it is important for geographic services: Hypermedia As The
>> Engine Of Application State is the key constraint identified by
>> Fielding which constitutes REST.  Everything else is just not
>> REST.
>> 
>> The idea behind that constraint is that the specification of a
>> format which contains links (hypermedia), can be 'easier' to
>> standardize than interfaces.   The format can then be served by
>> many servers, and consumed by many clients.  The contract is not
>> between the client and the server.  There are two contracts, one
>> between the client and the format and another between the server
>> and the format.  The result is the de-coupling of client and
>> server.  If I change my web site, you can still read it, iff I
>> respect the contract between the server and the format (html).
>> 
>> In order to 'be RESTful', a client application reads the "file"
>> (really the entire response, including headers) which is
>> transferred to it over HTTP, and, discovering links therein, either
>> follows them, thereby replacing/changing its state, or loads the
>> resource, augmenting/changing its current state.
>> 
>> To try to shorten a long story...
>> 
>> Currently the only RESTful system which matters is the html Web.
>> 
>> It is my personal professional belief that the only practical way
>> to build a GeoWeb is to add map (client) semantics to directly into
>> html, and thereby build it (html) into the GeoWeb. To be clear:
>> add a "geomap" tag to html. Browsers already have a contract with
>> html.  In order to create a GeoWeb, we need to change html and
>> concommitantly, browsers, to a new version of that contract.   We
>> need to specify a browser-provided (js) API for maps around a
>> "geomap" tag.
>> 
>> The interface is http.  Browsers are not going to implement your
>> interface.  The only interface they're going to implement is GET.
>> Browsers are not going to guess / build URI from component
>> hierarchies.  They want links, preferably fully formed.
>> 
>> The service format consumed by the html map client: the only
>> practical way to do this is with hypertext.  The service format(s)
>> must start with hypertext.  I suggest Atom, because it is a
>> widespread (community) standard hypertext base, having
>> (appropriate) collection/member semantics.  GeoRSS(Atom)-GML would
>> be an excellent extensible starting point for a geo service format.
>> It is already gaining traction in the OGC.  I am not a tiling
>> expert, but my instinct tells me that tilesets/tiles would have
>> good collection/member semantics.  What would be needed would be
>> suitable hypermedia constructs for map navigation: link relations
>> (e.g. "east", "west", (c.f. Allan Doyle geo-web-rest)..., "zoomin",
>> "zoomout" etc). Possibly URI templates (they are hypertext too, if
>> the client reads them).
>> 
>> Regarding the contract between servers and format. Web servers
>> already serve arbitrary html.  So that is no problem.  But for Web
>> scale, I suggest an actual "mod_geomap" for apache, which could
>> serve the contents of a tiled filesystem as feeds.  The feed format
>> is the contract for both the server *and* the html client.  That's
>> not to say there could not be a plethora of servers.  There could
>> be, just as there are tomcats, jettys, etc. there will be
>> geoservers, mapservers, arcgis servers, whatever.  Respect the
>> contract and you get to play!
>> 
>> That's my view of the needs for (+/- open source) geo software and
>> open standards.
>> 
>> Regards, and thanks for any feedback, Peter Rushforth
>> 
>> N.B. I made a presentation on this topic to the OGC Mass Market DWG
>> in Dec 2009, but the artifacts seem to be read-protected.  If
>> anyone is interested let me know. P.S. If you reply I may not (be
>> able to) respond until tomorrow.
>> 
>> 
>> _______________________________________________ Standards mailing
>> list Standards at lists.osgeo.org 
>> http://lists.osgeo.org/mailman/listinfo/standards
> 
> _______________________________________________ Standards mailing
> list Standards at lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/standards
> 

-- 
Arnulf Christl (Executive Director)
Open Source Geospatial Software, Data and Services
http://www.metaspatial.net