Hello,
I downloaded the source code and was wondering if the PostGIS
datastore has the ability to call the PostGIS function <<simplify(geom,
level)>> calculating the level parameter based on the scale (simplify
more when far away, till no simplification when zoomed near enough) -
this would speed up dramatically the rendering time.
Any ideas about
such feature? Is it already possible?
Cheers,
Filippo
Hi Filippo,
Currently there is no facility to do this... but as you say would be a pretty useful option to speed up performance. Adding it into the datastore would not be too hard but significant... could always throw a feature request in for it.
-Justin
fidinata@anonymised.com wrote:
Hello,
I downloaded the source code and was wondering if the PostGIS datastore has the ability to call the PostGIS function <<simplify(geom,
level)>> calculating the level parameter based on the scale (simplify more when far away, till no simplification when zoomed near enough) - this would speed up dramatically the rendering time.
Any ideas about such feature? Is it already possible?
Cheers,Filippo
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,46a9f87a263167082231907!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
This is the kind of optimization that was performed in the shapefile renderer; it would be nice to have the facility for PostGIS as well.
One plan was to introduce "per query" hints - in this case the hint would be "scale"; the PostGIS datastore could make use of the simplify function if the "scale" hint was around.
Jody
Hi Filippo,
Currently there is no facility to do this... but as you say would be a pretty useful option to speed up performance. Adding it into the datastore would not be too hard but significant... could always throw a feature request in for it.
-Justin
fidinata@anonymised.com wrote:
Hello,
I downloaded the source code and was wondering if the PostGIS datastore has the ability to call the PostGIS function <<simplify(geom,
level)>> calculating the level parameter based on the scale (simplify more when far away, till no simplification when zoomed near enough) - this would speed up dramatically the rendering time.
Any ideas about such feature? Is it already possible?
Cheers,Filippo
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,46a9f87a263167082231907!
fidinata@anonymised.com ha scritto:
Hello,
I downloaded the source code and was wondering if the PostGIS datastore has the ability to call the PostGIS function <<simplify(geom,
level)>> calculating the level parameter based on the scale (simplify more when far away, till no simplification when zoomed near enough) - this would speed up dramatically the rendering time.
Any ideas about such feature? Is it already possible?
Not possible, but we already thought about this, yes. The reason we don't have this right now is both resources and handling API changes.
Resource trouble is that basically no one has an explicit mandate to
make Geoserver faster, but we have mandates for new functionalities
and less bugs instead (meaning we can sneak in low cost speedups, but
not bigger changes).
API side is a little longer to explain. Suffice it to say that we
have a uniform API to access data, the DataStore API, and that we
have an interface, Query, used to filter data, state which attributes
have to be read, and so on. To support "in datastore" generalization
we would have to expand the Query interface to support that notion,
and that would break the interface, since all implementors would
have to expand their own Query implementations (if they aren't using
the standard implementation).
Breaking an API requires a PMC vote, and someone willing to do the
work of updating the code and get down into the sql encoders to
alter the "select" clause building code. That person would also have
to be familiar with projections, since the simplification params
would have to altered according to the current projection (and they
would be different from area to area of the current map, so we would
need a way to guess the biggest deformation as well... think about
an UTM projection, deformation is null around the central meridian,
and increases as x^2, x being the distance from that meridian).
So, long story short, I think we're looking for a volounteer doing all
the needed work, a change of priorities that put performance at the same level of other things, or someone sponsoring the effort with money.
Cheers
Andrea