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

[Rushforth, Peter]

Hi Stefan,

I agree AtomPub is an excellent starting point.  I think OGC is tinkering
with Atom encodings, but it is the hypermedia approach that I seek to
encourage.  One step at a time, however.

It's great that AtomPub does not mention URI structure, parameters or anything
of that nature, as it helps readers come to grips understanding services
by virtue of a media type.

If you negotiate the URL I sent below for application/xml or application/atom+xml,
you will see that it is based on an AtomPub service.

Regards,
Peter


> -----Original Message-----
> From: Stefan Keller [mailto:sfkeller at gmail.com] 
> Sent: July 15, 2013 11:53
> To: Rushforth, Peter
> Cc: Arnulf Christl; standards at lists.osgeo.org
> Subject: Re: [OSGeo-Standards] Was: "file" formats. Is: GeoWeb
> 
> Hi Peter
> 
> Just to backup my hints to AtomPub: I looked into the AtomPub spec.
> and realize that it even contains means to encode collections.
> 
> Has there ever been any evaluation (within OGC WGs) on why 
> NOT putting geospatial data formats into AtomPub?
> 
> Yours, Stefan
> 
> BTW: AtomPub is a nice example of a Web/REST best practice - 
> even that it never mentions REST. It has been designed by 
> well known people like Tim Bray (XML), Sam Ruby (HTML5), Mark 
> Nottingham (HTTPbis WG) and Roy Fielding himself :-).
> 
> 
> 2013/7/15 Rushforth, Peter <Peter.Rushforth at nrcan-rncan.gc.ca>:
> > 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
>