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

[Raj Singh]

How do you know you would get back KMZ or MBTiles?
Don't you want to specify an Accept HTTP header to hint to the server that you want that format?
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

---
Raj
The OGC: Making location count.
http://www.opengeospatial.org/ogc/organization/staff/rsingh


On Jul 15, at 6:57 PM, Pat Cappelaere <pat at cappelaere.com> wrote:

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