[OSGeo-Standards] Was: "file" formats. Is: GeoWeb
sfkeller at gmail.com
Mon Jul 15 08:52:31 PDT 2013
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?
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,
>> >> 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):
> Very nice.
> Here's another imperfect yet evolving stab at it:
> Standards mailing list
> Standards at lists.osgeo.org
More information about the Standards