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
* 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
* 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
* 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
* 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
* 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
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?)
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.
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
