[OSGeo-Standards] Was: "file" formats. Is: GeoWeb
Peter.Rushforth at NRCan-RNCan.gc.ca
Mon Jul 15 09:19:56 PDT 2013
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.
> -----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
More information about the Standards