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
