Hi Jukka, all,

The maxFeature parameter should be available from NB (svn 2500).
Now, addDatastore plugin should also be able to preserve z values.

Please, test and report any problem,
I did not test anything else than PostGIS Driver.
Would be useful to test other plugins.

Michaël

Le 11/10/2011 22:59, Rahkonen Jukka a écrit :
> Hi,
>
> I would say that the limit should be per query.  General option for 
> everything or even per connection is too course.  Points are not as heavy as 
> polygons, features with few attributes easier than those loaded with 
> attributes.  Even using the WHERE filter for the same database table can make 
> difference.  Short and simple ditches may come from the same waterway table 
> than bir rivers.  Perhaps it could be just one more selection in Data Store 
> Layer dialogue. Now we have Connection; Dataset; Geometry; Where and the new 
> one could be Limit:
> Limit is a PostGIS word but officially we do not have other data store 
> drivers which integrates with the native PostGIS one. I know one exception: 
> SIS Oracle driver makes a new Data Store and Oracle is using "WHERE rownum<x" 
> instead of "limit x".  Therefore users of SIS db plugin might wonder why 
> limit does not work. Documentation should help in this situation if there is 
> nobody to fix the SIS plugin.
>
> -Jukka-
>
>
> ________________________________________
> Lähettäjä: Michaël Michaud [michael.mich...@free.fr]
> Lähetetty: 11. lokakuuta 2011 22:41
> Vastaanottaja: jump-pilot-devel@lists.sourceforge.net
> Aihe: Re: [JPP-Devel] Add feature count limit to dynamic PostGIS layers
>
> Hi Jukka,
>
>> 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.
> Interesting,
>> 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.
> Where do you thing the parameter would have to be set : general option
> (option panel), per connection, or per query ?
> About the danger of not having all the data in the visible layer, I
> think the dynamic datastore management is already dangerous.
> Running a process against a layer will make you feel you 're running it
> against the whole postgis table, but instead, you will run it against
> the visible part of the table only.
> That said, red light would be a plus for the use case you are describing.
>
> Michaël
>> -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
>> 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
>
>


------------------------------------------------------------------------------
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World&#153; now supports Android&#153; Apps 
for the BlackBerry&reg; PlayBook&#153;. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Reply via email to