Nice thoughts Andrea. A few responses in line. In general we considered
most all of this out of scope for geopackage 1.0, but it is of interest for
many. And I think a next testbed should lead to modifications of geopackage
and service specs. Some people have talked about a 'geopackage service',
but I'd rather see it just be integrated in lots of other specs.
On Sat, Jul 13, 2013 at 8:13 AM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Fri, Jul 12, 2013 at 3:48 PM, Justin Deoliveira
> <jdeol...@opengeo.org>wrote:
>
>> +1 on the module
>>> As a curiosity, why wms? Is this going to produce tiles in the
>>> geopackage? Or does the geopackage embed styles as well?
>>> I guess the real question is, why wms and not wfs output format?
>>>
>>
>> Yeah, the package can actually contain three types of tables, vector,
>> raster, and tiles. So wms seemed the best fit but certainly nothing
>> stopping wfs and wcs output formats.
>>
>> Afaik there is nothing describing styles in the package but it would be a
>> useful extension i think.
>>
>
> Thinking a bit out loud about the existing services and what a geopackage
> output might mean for them (warning, I did not have a look at what the
> geopackage module does, so I'm really just thinking out loud):
> * wfs wise, it's clear we want to extract raw vector data, so geopackage
> with the requested feature collections inside the package should be the
> natural fit
>
Definitely the most straightforward.
> * wcs wise, the rasters seem the good fit, although a flat tiling scheme
> might be of interest in case we want to allow fast extraction of a certain
> subset of flat data.
> And I'm also wondering about out usual n-dimensiona raster approach
> which is really made of stacked rasters associated to a tuple of dimension
> values,
> wondering if an how that would be a fit for the geopackage construct
>
Yeah, for 1.0 we actually ended up punting on rasters. Like we say very
little about them, since we just didn't have the expertise to do them
really well, as it opens up a whole bunch of questions. So we just have
some slight guidance that says you could use a feature table to store
blobs. My hope was we'd get more experimentation in the market with
rasters, see what people would want to do with them. So I think/hope
geopackage should give us enough to come up with an approach that makes
sense for raster / wcs output. I don't think anyone had thought about the
n-dimensional raster stuff though. Which makes me glad we didn't try to say
anything about it, as I'm sure it would have not included anything that
smart. We just had no great raster experts in the initial group. Would be
great to get you and/or Simone on the next round where we do tackle it.
> * wmts wise, it seems like a nice way to get not a single tile, but a
> "sub-pyramid" of tiles fitting a certain bounding box and a certain set of
> zoom levels. However, there is no such a thing in WMTS as a multi-tile
> request, so I guess the protocol would have to be extended with a new
> operation, GetTiles I suppose
>
Interesting. Yeah, would make sense to extend it a bit for that operation.
> * wms wise, there is plenty of interpretation. The meaning of a GetMap is
> clear, we want a painted, styled map out of the request, the usual criteria
> for selecting an output for WMS is that styles have a say in what you
> generate. This is true for all image formats, and also true for the less
> visual GeoRSS, in which the style still has a say in what you get back
> depending on the scale dependencies and filters contained in the styles.
>
> So... what is geopackage for wms?
> * a package containing the same raster I would get from a image/png
> request.... the strictest match, but not very useful
>
Yeah, given de-emphasis on raster in the spec I'd say it wouldn't mean this
- it's much more about tiles.
> * a package containing tiles to represent that map, maybe for a bunch of
> zoom levels around the requested one... sounds better, gives a way to look
> at the map once disconnected, and yet still ends up missing the
> GetFeatureInfo ability
>
The best approach I've seen for this is mapbox's UTFGrids.
http://www.mapbox.com/developers/utfgrid/
> * a package containing the ingredients to build the requested map, raw
> vector, raw raster, and the associated styles. For a disconnected client
> that's probably the most interesting of the outputs, provided that it can
> be interpreted client side... so the styles would have to be SLD, which
> would probably finally raise it from "that thing that GeoServer and Deegree
> use to drive the map painter" to something actually useful :-p
>
Yeah. Realistically though I think we'd be better served by having it be a
standardized CSS, as that's where the world is going. In the short term I
think style will be something different implementations add on, a vendor
specific thing.
> Still, even in this case the styles should have a say, so I'd expect the
> output package contents to only contain the vectors that are really visible
> in the map (not all of them), and possibly a raster that's not only cut to
> the bbox, but maybe also reduced in resolution (and this also makes me
> wonder if the vectors should be generalized as well?)
>
>
Yeah, seems like those are the two main possibilities - give me tiles, and
give me data/styles to make it myself.
> In all of the above examples there is still a large elephant in the room:
> all of the above requests are synchronous, and yet the package is capable
> of hosting large downloads. Yet, as far as I understand it, it cannot be
> generated in a streaming fashion, so there is a risk that the HTTP
> connection
> dies and fails while the geopackage is being written (that's especially
> true for the partially connected scenario for which the geopackage is
> designed for).
> So... maybe WPS is overall a better fit, in that it has the ability to
> support asynchronous requests, and the client is free to go its merry way
> and maybe temporarily disconnect from the net while the server is
> preparing the output.
>
>
Interesting, I hadn't considered that. I wonder if in WFS we can use those
new weird precomputed queries in some way to help.
That said I do hope that the core geopackage is simple enough to generate
in a streaming fashion. Just write the blobs out, don't need full sqlite.
Not sure if that's true though, would love insight from Justin if the
current thing is streaming. But even if it is streaming there's still the
risk the http connection dies.
> Well... enough ranting I guess? :-p
>
> Cheers
> Andrea
>
>
>
>
>>
>>> Cheers
>>> Andrea
>>>
>>>
>>> --
>>> ==
>>> Our support, Your Success! Visit http://opensdi.geo-solutions.it for
>>> more information.
>>> ==
>>>
>>> Ing. Andrea Aime
>>> @geowolf
>>> Technical Lead
>>>
>>> GeoSolutions S.A.S.
>>> Via Poggio alle Viti 1187
>>> 55054 Massarosa (LU)
>>> Italy
>>> phone: +39 0584 962313
>>> fax: +39 0584 1660272
>>> mob: +39 339 8844549
>>>
>>> http://www.geo-solutions.it
>>> http://twitter.com/geosolutions_it
>>>
>>> -------------------------------------------------------
>>>
>>
>>
>>
>> --
>> Justin Deoliveira
>> OpenGeo - http://opengeo.org
>> Enterprise support for open source geospatial.
>>
>
>
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
