[OSGeo-Standards] [REST.SC] Was: "file" formats. Is: GeoWeb
creed at opengeospatial.org
Tue Jul 16 07:29:10 PDT 2013
I searched for Open GeoSocial API. Found an excellent slide set but no
actual API definition.
Also, correct me if I am wrong, but there would be nothing to prevent using
existing OGC standards in the behavior based approach you are suggesting.
From: Pat Cappelaere
Sent: Monday, July 15, 2013 4:57 PM
To: Carl Reed
Cc: Rushforth, Peter ; Arnulf Christl ; REST SC ; standards at lists.osgeo.org
(OSGeo) ; Frye Stuart ; Mandl Dan ; Karen Moe (GSFC-4070)
Subject: Re: [REST.SC] [OSGeo-Standards] Was: "file" formats. Is: GeoWeb
Here is how it might look like using two RESTful queries with the Open
Step 1. Search for GEOSS products for that particular Societal Benefit
Target: lat: 37.4 long: 22.1
Product Type: imagery:*
On-demand products come back…
Select the one from the SEVIRI instrument server with hot_spots processing
algorithm using WCPS and follow the link to execute behavior
Step 2: Get Layer from CORINE Land Cover
Target AOI: lat: 37.4 long: 22.1
Product Type: maps:layers:CORINE
Select the resulting link and follow it.
You would get two KMZ (or MBTIles ) files to display on your mobile device.
On Jul 15, 2013, at 12:20 PM, "Carl Reed" <creed at opengeospatial.org> wrote:
> 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?
> -----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,
>> >> 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
> - 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):
> Very nice.
> Here's another imperfect yet evolving stab at it:
> Standards mailing list
> Standards at lists.osgeo.org
> REST.SC mailing list
> REST.SC at lists.opengeospatial.org
More information about the Standards