Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] WMS-C Caching / MapInfo .TAB export

Morning John:

I am back in health today so you can join me on IRC if you have any questions.

I'm not sure how to actually DO a patch from svn (I have been told that's how it's done), but I will have a look at the uDig wiki for the process and release these fixes before moving on.

This should do it on most platforms (even windows):
svn diff > bug_name.patch
 
I have had little success locating the memory leak which is killing the app when pre-loading (into disk cache & memory cache) the entire cache. This is eluding me completely, I have tried to do some profiling on the memory but will no success. One point to note is, I think the "Tiled Rendering System" has a big memory leak. With a few zooms it's easy to more than double the memory footprint of uDig and moving around for a few minutes the entire allocation of memory is used (I have mine set to 1024mb).

That is almost by design; the tiles are held in WeakReferences (which are not cleaned up until the system needs the room). 

Can I be sure we are talking about the same thing here? There are two tiled rendering systems:
- a tiled mode for the uDig renderer (you enable it with a window preferences setting)
- a WMS-C renderer which I think you are debugging now

Notes:

At first I thought this maybe the desired functionality but after looking closely: starting memory is 122,836k (from max extent, on a restart of uDig, using the Tiled Rendering System) zooming in once (zoom-in button) memory footprint goes up-to 134,720k, that's a huge jump when there are no tiles actually retrieved from the tile server, this is only image processing on the client. Changing to NOT using the Tiled Rendering System sees memory down to (restart uDig & at max extend) 111,004k, and a single zoom is 114,324k. Zooming closer with the Tiled Rendering system off yields the same result, memory DOES increased but not as harshly. This is what pointed my initial thoughts to the Tiled Rendering System, I am probably far off :). Can anyone shed light on this? I wonder if this has anything to do with the preloading of the tiles?

See after this comment I get confused; what are you focusing on here? 

SO... After releasing the above fixes, I will, for the time being put aside the pre-loading tiles issue and will start working on the addition of a plug-in that will allow users to specify an "area of interest" from a selected feature (WFS) then an operation that will allow the export of this bounded "area of interest".

This is the section of your work that is pretty specific. Once you have a region of interest we can focus on grabbing just the tiles for that area.
 
Anyone have any suggestions how I should go about representing this in uDig?

Sure; we are now moving into making your custom application (so as programmers we are responsible for scripting together the parts of the udig application to do what we need).

Make a WFS that has a bunch of regions defined in it; make a view that shows these regions in a list; as the user selects one you can provide some information about the region and show that area on the scree (the current region can be placed on the map blackboard and you can make a map mapgraphic to visualize it).
 
I thought it would be nice to allow the User to right click on a feature (or multiple features) then an operation would be to "Add as area of interest" and possibly "Add to Area of interest..." (that would be a wizard, to select an existing AOI). Then a new view "Areas Of Interest" which would look similar to the Layer View but with the WMS-C node as a parent and the features as children of that layer(s).

That seems fine as well; start by making your WFS though - your plugin that contains this stuff will need to make sure the WFS is available in the catalog (you can check during a workbench startup callback if you like). 

Another possibility would be to extend the Layer view to show these Area Of Interest's. This would be the nice way to represent it, but might feel "cluttered" like there is too much going on in there already and might confuse the User?

True; for your application you may not even wish to show the user the layer view (it is not needed unless they have a bunch of other data they need to manage at the same time - which they do not). 

Ok I'll stop now, if you're still reading, great and thanks.

Cheers. 


Fyi, Cameron Shorter (Geospatial Architect here at LISAsoft) has a blog with some more information about our project (http://cameronshorter.blogspot.com/2009/01/loading-tilecache-images-onto-mapinfo_13.html), have a read.

Thanks; I will try and link to that from the uDig blog feed.
Jody

Back to the top