[OSGeo-Standards] Was: "file" formats. Is: GeoWeb
Carl Reed
creed at opengeospatial.org
Mon Jul 15 12:56:55 PDT 2013
Peter -
Wow! Thanks so much. I will need a little time to digest :-)
Regards
Carl
-----Original Message-----
From: Rushforth, Peter
Sent: Monday, July 15, 2013 1:05 PM
To: Carl Reed
Cc: standards at lists.osgeo.org
Subject: RE: [OSGeo-Standards] Was: "file" formats. Is: GeoWeb
Carl,
Thanks for your idea. Of course you realize this is Web GIS, and not
simple web-find-me-the-data-and-i'll-take-it-from-there Web. That's OK,
too!
It will be a pleasure to hopefully show you it's possible to do.
But having done that, let's acknowledge that what's being discussed here
is not Web GIS, since there are many capable Enterprise GIS systems
available supplied
by OGC membership, but that the dominant need, and what we're talking about
in
this thread, is a simple, open, accessible, scalable linked-data GeoWeb.
If you will acknowledge that I will acknowledge that I've fudged the
question
a little for want of motivation/time. Hopefully it's enough to give you the
idea, at least, and not provoke the crowd into a frenzy ;-).
The media type here (named in honour of you!), is an extended AtomPub type,
without going into the rules for processing the media type, which
of course are specific to that type. You can imagine those rules being
specified
as part of media type registration.
So here goes:
GET http://example.org/SEVIRI/images HTTP/1.1
Host: example.org
Accept:
application/atom+xml;profile="http://creed.example.org/";q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
HTTP/1.1 200 OK
Date: Mon, 15 Jul 2013 17:09:23 GMT
Server: Apache/2.2.15 (Red Hat)
Content-Type:
application/atom+xml;type=feed;profile="http://creed.example.org/"
<feed xml:base="http://example.org/SEVIRI/images/">
<totalResults>2857</totalResults>
<collection href="./">
<title type="text">images</title>
<accept/>
<categories>
<category scheme="urn:corrine:landcover" term="forest" label="Forest
area" frequency="446">
<link href="-/(urn:corrine:landcover)forest" rel="collection"/>
</category>
<category scheme="urn:thesaurus:subject" term="forest-fire"
label="Forest fire" frequency="12">
<link href="-/(urn:thesaurus:subject)forest-fire"
rel="collection"/>
</category>
...
</categories>
<link rel="api"
type='application/atom+xml;type=feed;profile="http://creed.example.org/"'
href="."
tref="./{+categoryQuery}?fwzl={lon}&xghlfl={lat}&uoiaimp={radius}&qzscml={published}">
<!-- the following template variable values are specific to this
media type i.e. expected -->
<!-- NOTE THE API PARAMETER NAMES HAVE BEEN OBFUSCATED TO FORCE THE CLIENT
TO PROCESS THE MEDIA TYPE :-) -->
<!-- in other words, the contract is between the client and the
media type, not between the -->
<!-- client and the server api -->
<categoryQuery>...</categoryQuery>
<lon>...</lon>
<lat>...</lat>
<radius>...</radius>
<published>...</published>
</link>
</collection>
...
</feed>
GET
http://example.org/SEVIRI/images/-/(urn:corrine:landcover)forest/(urn:dc:subject)forest-fire/?fwzl=32.12341&xghlfl=34.823488&uoiaimp=2000&qzscml=2007-08-25
HTTP/1.1
Host: example.org
Accept:
application/atom+xml;profile="http://creed.example.org/";q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
<feed xml:base="http://example.org/SEVIRI/images/">
<totalResults>2</totalResults>
<collection href="./">
...
</collection>
<entry>...</entry>
<entry>
...
<link rel="enclosure" href="http://example.org/SEVIRI/images/47"
type="image/jp2"/>
<content><gmd:MD_Metadata>...</<gmd:MD_Metadata></content>
</entry>
</feed>
Hope this helps.
Regards,
Peter
> -----Original Message-----
> From: Carl Reed [mailto:creed at opengeospatial.org]
> Sent: July 15, 2013 12:20
> To: Rushforth, Peter; Arnulf Christl
> Cc: standards at lists.osgeo.org; REST SC
> Subject: Re: [OSGeo-Standards] Was: "file" formats. Is: GeoWeb
>
> All -
>
> Still following the discussion and still fuzzy on the topic.
> I am a pragmatist and like concrete examples to work from.
>
> I just happened to find this example from an INSPIRE related
> presentation:
>
> Find images taken by the SEVIRI satellite on August 25, 2007
> which contain fire hotspots in areas which have been
> classified as forests according to CORINE Land Cover, and are
> located within 2km from an archaeological site in the Peloponnese.
>
> Very real world and a very typical geospatial
> query/processing workflow.
>
> Anyone want to take a shot at what a series of RESTful
> request/responses might look like?
>
> Thanks
>
> Carl
>
>
> -----Original Message-----
> From: Rushforth, Peter
> Sent: Monday, July 15, 2013 9:34 AM
> To: Arnulf Christl
> Cc: standards at lists.osgeo.org
> Subject: Re: [OSGeo-Standards] Was: "file" formats. Is: GeoWeb
>
> Hey Arnulf,
>
> > Arnulf>
> > Raj>>
> >
> > >> 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.
> >
> > Although it sounds stupid to say "the earth" is the resource, we're
> > talking about the GeoWeb anyway so it's not so stupid, I
> think. When
> > you think about the resource - representation duality, any
> subset can
> > equally be considered a representation of it, be that a
> tile, a group
> > of tiles, a tilematrixset, or a FeatureCollection representation of
> > any of those things.
> > So the representation notion doesn't simply cover the
> format aspect,
> > it also allows us to push the understanding of "the earth"
> > how to interact with the resource into the format, hence
> the value of
> > "east"
> > "west" etc., which become part of a "what you can expect in this
> > format"
> > specification i.e. a media type registration.
>
> What I would like to see is that the service metadata portion
> of the interaction goes away. In a hypermedia solution, it
> would have to be described by an extra media type, hence
> would complicate implementations without obvious benefit.
>
> It would be ideal to define a media type which could be used
> to describe a portion of the earth (all of it or some of it), which:
>
> - can encode coordinates in one projection, with a default
> value if not specified
> - projection could be negotiated by mime type, perhaps via a
> "projection"
> media type parameter
> - has a notion of tilematrixset, tilematrix, tile potentially
> as resources
> - has a base hypermedia media type (#atom)
> - leverages encoding and modelling work done in OGC (#gml)
> - has map-related link relations like east, west etc.
> - has link relations for tilematrixset, tilematrix, tile,
> featurecollection, feature (#wmts)
> - potentially includes named URI Templates which can help
> with advanced use, although to keep it simple one should try
> to avoid templates as much as possible as they require an
> advanced level of hypermedia processing. Fully-formed links
> and header metadata is preferable.
> - is readable without an IDE (#kthanksjsonbuhbye).
>
> >
> >
> > >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
> >
>
> Very nice.
>
> Here's another imperfect yet evolving stab at it:
>
> http://geogratis.gc.ca/api/en/nrcan-rncan/ess-sst
>
> Cheers,
> Peter
> _______________________________________________
> Standards mailing list
> Standards at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/standards
>
>
More information about the Standards
mailing list