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

[Rushforth, Peter]

> > 
> >> the only practical way to access them is through a query 
> API, not hypermedia, and how RESTful is that?
> > 
> > *You* don't have to specify a query api, just a format with 
> appropriate link relations.  It's the service implementer's 
> job to figure out how to return (a page of) features.  It's 
> the clients job to pull the feed by following typed links 
> (i.e. 'rel=next').  If *you* try to figure out how to satisfy 
> (all) requests, you're doing the server implementer's job.  
> Why should you care what the URL looks like?
> 
> I get your point, but if every service implementer designs 
> their own way to return (a page of) features, and every 
> client codes to that, I have a hard time envisioning, e.g. a 
> highly performant imagery (or feature) service.

Not sure the Web is the place for that anyway, but what do you 
mean by highly performant?

> I certainly 
> see benefit in this kind of architecture if the goal is 
> behind-the-scenes data crawling,

What is the goal of the data crawling?

> data sharing 

Yes

> synchronization,

Sure, I guess.

> but I can't see the killer client app here. 

Scalable federation and presentation of maps, enabled by open standards.
How is the Web not a killer app?

> Maybe I'm thinking too old-school GIS? 

There is a major difference between Web architecture and GIS, right.


> I'd love to see a 
> fleshed-out example of this. In fact, I'm trying to implement 
> something like this on openpois.net. Problem is I can't 
> figure out the best way to implement the links for clients to follow.
> 
> >> Imagery: hardest (IMHO). What are good resources? 
> > 
> > Tiles?  Why shouldn't a resource be a tile and the 
> representation be a (GeoTiff, whatever)?  As you say, it's 
> the same problem as features.  You request a *resource* in a 
> *format* (aka media type), the server returns a 
> representation, hopefully in that format.
> 
> So tiles would be some grouping of raster cells? I suppose 
> this could be very useful if we standardized on a tiling 
> scheme for the world (something like WMTS but with higher 
> resolution). 

I agree WMTS provides a good framework to think about, however
instead of deciding what the URLs look like as the main effort of 
standardization, think about the resource data model and standardize
the (hypermedia) representations around that.

A tile would be a resource.  You could request a representation of it in any format
supported by a server.  Conventional formats might be: image/jp2, application/gml+xml
application/geo+json or more domain specific sub sub types of those. However,
if we want to have appropriate hypermedia semantics, we need to prioritize
the core hypermedia format, for which IMHO Atom is an excellent base.

Point is, let's not think about what the URLs look like, lets think about
and standardize what the resources and representations look like.  

Regards,
Peter