Le 11/10/2011 18:50, G. Allegri a écrit :
I don't know if it's possible with OJ, but with many other GIS
softwares the user has the possibility to pause rendering (and reading
data), adjust zoom levels, symbology, etc., the start rendering again.
Have you examples ?
In our case, i think it would not help. Stopping the renderer will not
stop the query which will return all the queried rows, and throw the >:o
OOM Exception.
I fear that a feature count limit is quite useless depending on the
sequence in which data rows are mantained: they could be spatially
sequential (in some way) but they could be spatially sparse. Let's
suppose they start sequencially from top-left BBOX: in this case you
would render only a region of the whole dataset, and you may miss the
area you're interested in...
The limit may mean : your zoom level is too small, I can't display all
the features, but if you want to go on working, you can hide the layer
or zoom in again.
Useful to know that after an OOM exception, OpenJUMP may become instable
and sometimes unsuable.
My two cents
Michaël
my 2 cents,
giovanni
2011/10/11 Rahkonen Jukka <jukka.rahko...@mmmtike.fi
<mailto:jukka.rahko...@mmmtike.fi>>
Hi,
What do you think, would it be too dangerous to add a possibility
to set a feature count limit for PostGIS datastore layers? I know
I can set scale limit for the layer but if I have zoomed to show
the whole country when adding some layer with millions of features
into OpenJUMP is starts to read the whole PostGIS table and chokes
before it is possible to set the scale limit.
What is dangerous is that user would not always have all the data
from the PostGIS layer on the visible map. Perhaps there should be
a red light burning and warning the user that there is a count
limit set for the layer? Even better if the light burns only if
the feature limit has been reached. Technically it should not be
difficult to set the feature count, just to add "limit
[max_features]" to all the SQL queries if the parameter is set.
-Jukka Rahkonen-
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and
makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
<mailto:Jump-pilot-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
