just an update: I made a quick test, using the normal highlight. This is not really slowing down things. If I disable the result table creation the map is rendered quite fast with the default highlight, even when 6 or 7000 features are returned. The JSON string returned however is close to 2 MB! So you need to work on the result display, maybe create a plugin for displaying the result in the table in chunks of a few 100.
armin On Wed, Aug 25, 2010 at 2:31 PM, Armin Burger <armin.bur...@gmail.com> wrote: > If you want to try the highlight method with the 2 files I put in the > zip file, you need to limit the number of features to be returned for > the result table. Just try setting it to 100. The highlight using the > querymap will nevertheless highlight *all* found features. So I guess > it should make a difference. > > I would also guess that the pure transfer of 5000 features as JSON > string (I guess more than 1 MB) and converting them via JavaScript to > HTML is at least as much slowing down the display as the adding of the > features to the map. Just try the difference between browsers like IE > (very slow) and Chrome (very fast). Also I'm wondering how it makes > sense to display more than a few 100 in the result table. > > You could also disable the display of the result table and just see > what's the difference between the 2 highlight methods. You need to > disable some parts in the JavaScript files pm.query.js (and define the > /javascript/src/ folder in the config XML as the JS location to be > used. > > try adding something like > > $.extend(PM.Query, > { > parseResult: function(jsonRes, tplName, container) {} > }); > > in the "custom.js" file of your config dir (probably > "config/default"). After query you need to slightly pan the map to > reload the map with the highlight. If this is acceptable fast then the > bottleneck is really the JSON parsing and HTML table creation. If so, > you could tweak the JS functions for only displaying a few 100's at a > time and having buttons for swapping to the next set. > > Also for your shapefile, I guess you created a spatial index using the > shptree tool ... > > Just some ideas > > Armin > > PS: a query via a unregular polygon is currently not implemented but > could be done using some of the drawing methods of the measure > function (or the draw plugin from Thomas Raffin) together with a > modified query. But the code was not designed for modular use and you > would need to make some code duplications... > > > On Wed, Aug 25, 2010 at 11:12 AM, Chris Jackson <webturt...@gmail.com> wrote: >> Armin >> >> Tried your code and timed the two selection techniques with a 5000 feature >> limit querying a shapefile - both about 8.5 mins!!! - so no real performance >> gain using the old code. Takes ~45sec with a 1000 feature limit and about >> 13 secs with a 500 feature limit (working from a low performance test >> server). I do wonder what the difference between by querying shapefile vs >> PostGIS would be with a 5000 feature limit, but unlikely to be able to do >> that at this end :o(. >> >> Also does the query code count the matching features before looping through >> them or just loop and cut off when the feature limit is reached? - it would >> be useful to see the number of features selected (and total possible >> matching features) at the top of the results table (ie. 500 of a possible >> 4050 features selected) - this would then inform users that they have >> 'missed' results due to the imposed feature limit (more important when using >> the search or query editor plugins). >> >> Other thoughts - have you tried to tie in users drawing a polygon and it as >> the query extents or use of a circular buffer select with the user defining >> the distance? >> >> I am still continually impressed with what has been done with P.Mapper - so >> thanks! >> >> Chris >> >> On 24 August 2010 21:43, Armin Burger <armin.bur...@gmail.com> wrote: >>> >>> Chris >>> >>> something that came into my mind was the use of queryMap. I had not used >>> it since eternities because it became obsolete to me using the p.mapper >>> highlighting method. I made a quick test and it would need just a few >>> lines in query.php and map.php to change/add. >>> >>> Note that this will only work for selects, not identifies or searches >>> (this would require some more changes). And I have currently no plans >>> for changing to this solution, it might be faster in case of lots >>> returned values, but has less flexibility. And it would not work with >>> the current way of searching in Postgis layers. >>> >>> If you're interested, I put the files at >>> http://www.pmapper.net/dl/querymap.zip >>> >>> You need to define a querymap entry in the map file like >>> >>> QUERYMAP >>> COLOR 255 255 0 >>> STATUS on >>> STYLE hilite >>> END >>> >>> also set <highlightSelected> in the XML config file to 0. >>> >>> I have not modified anything to remove the highlight but I can tell you >>> what to modify in case you would like to use this solution. >>> >>> armin >>> >>> On 24/08/2010 16:58, Chris Jackson wrote: >>> > Hi all >>> > >>> > One of the underlying datasets in my P.Mapper app is a model grid (many >>> > thousand cells) in a shapefile. The data displays nice and quick when >>> > just >>> > viewing, but if I allow the user to select say 5000 cells (using the >>> > select >>> > by rectangle tool or even the seach tool) it is very (extremely) slow to >>> > redraw with the highlighted cells. Doing the same task in a very old >>> > ArcGIS >>> > server web app was much quicker (admittedly the data was in SDE/MS SQL). >>> > So >>> > my question is what is the best way to improve performance? Does using >>> > a >>> > shapefile just not cut it when selecting so much data? Has anyone got >>> > P.Mapper to work with a mapfile containing a layer where the data is >>> > within >>> > a MS SQL 2005 db with the MSSQLSPATIAL add-on (using OGR)? Or are >>> > there >>> > other better approaches to use or settings (inc. PHP) to tweak? >>> > >>> > Many thanks >>> > Chris >>> > >>> > ------------------------------------------------------------------------------ >>> > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program >>> > Be part of this innovative community and reach millions of netbook users >>> > worldwide. Take advantage of special opportunities to increase revenue >>> > and >>> > speed time-to-market. Join now, and jumpstart your future. >>> > http://p.sf.net/sfu/intel-atom-d2d >>> > _______________________________________________ >>> > pmapper-users mailing list >>> > pmapper-users@lists.sourceforge.net >>> > https://lists.sourceforge.net/lists/listinfo/pmapper-users >>> > >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program >>> Be part of this innovative community and reach millions of netbook users >>> worldwide. Take advantage of special opportunities to increase revenue and >>> speed time-to-market. Join now, and jumpstart your future. >>> http://p.sf.net/sfu/intel-atom-d2d >>> _______________________________________________ >>> pmapper-users mailing list >>> pmapper-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/pmapper-users >> >> > ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ pmapper-users mailing list pmapper-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pmapper-users