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

[Carl Reed]

Thanks, Pat

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.

Cheers

Carl


-----Original Message----- 
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

Carl,

Here is how it might look like using two RESTful queries with the Open 
GeoSocial API:

Step 1.  Search for GEOSS products for that particular Societal Benefit 
Area/subarea
GET /products
SBA: "disaster:wildland_fires"
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

GET /products
SBA: *
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.

Pat.

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?
>
> 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
> _______________________________________________
> REST.SC mailing list
> REST.SC at lists.opengeospatial.org
> https://lists.opengeospatial.org/mailman/listinfo/rest.sc