Hi,
an issue was brought to my attention that KML/KMZ can take a lot of time to generate
on larger layers when working off an Oracle backend with a large amount of data.
Looking into it I traced the problem to the lookAt bbox being calculated using a layer wide
bounds calculation (KMLVectorTransformer line 105) when using the KML reflector.
There are two things that should be fixed imho:
- the fact that regardless of whether the LOOKATBBOX parameter has been specified or not,
we end up computing the full bbox of the feature collection
- given that the bbox computation is expensive, we should be looking at ways to avoid it.
Fixing the first is trivial, the second one requires a bit more thinking, but what we can do
at an higher level in the code is see if the lookup bbox has been specified, if not we
can look at the layers involved and leverage the declared bbox instead of making a full
computation.
That’s not something we can always do, but it can be applied in the common case,
that is, when no CQL filter was provided: in such case, aggregate the bbox of all the
involved layers, intersect with the eventual requested bbox, and use that as the
lookat bbox to be used.
Now, this might spur the usual debate on whether we should use dynamic or static
bboxes, but imho the KML codebase is not the place to solve this issue: if we
wanted to have truly dynamic bboxes we should add a flag in the resourceInfo config,
and have a ResourceInfo.boundingBox() query method that depending on the flag
either uses the declared one, or computes on the fly the actual one (and same goes
for the lat/lon bbox).
Opinions?
Cheers
Andrea
–
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
Definitely agree on KML using layer bboxes the same way everything
else does. This is not the place to solve the issue, KML should use
whatever bbox for the whole layer that we normally use. If we do some
cool dynamic bbox improvements for that later then it could use it.
On Thu, Nov 15, 2012 at 1:11 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:
Hi,
an issue was brought to my attention that KML/KMZ can take a lot of time to
generate
on larger layers when working off an Oracle backend with a large amount of
data.
Looking into it I traced the problem to the lookAt bbox being calculated
using a layer wide
bounds calculation (KMLVectorTransformer line 105) when using the KML
reflector.
There are two things that should be fixed imho:
- the fact that regardless of whether the LOOKATBBOX parameter has been
specified or not,
we end up computing the full bbox of the feature collection
- given that the bbox computation is expensive, we should be looking at ways
to avoid it.
Fixing the first is trivial, the second one requires a bit more thinking,
but what we can do
at an higher level in the code is see if the lookup bbox has been specified,
if not we
can look at the layers involved and leverage the declared bbox instead of
making a full
computation.
That's not something we can always do, but it can be applied in the common
case,
that is, when no CQL filter was provided: in such case, aggregate the bbox
of all the
involved layers, intersect with the eventual requested bbox, and use that as
the
lookat bbox to be used.
Now, this might spur the usual debate on whether we should use dynamic or
static
bboxes, but imho the KML codebase is not the place to solve this issue: if
we
wanted to have truly dynamic bboxes we should add a flag in the resourceInfo
config,
and have a ResourceInfo.boundingBox() query method that depending on the
flag
either uses the declared one, or computes on the fly the actual one (and
same goes
for the lat/lon bbox).
Opinions?
Cheers
Andrea
--
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
-------------------------------------------------------
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel