Re: [JPP-Devel] OpenJump speed improvements
Thanks for all your comments. Stefan, you are correct about (6). It is already present in OpenJump. It just needs to be modified to better support deferred loading. I'm not surprised there is a little confusion about (2). The concept of Layer Tasks and Archives evolved around the same time to solve the problem of transferring styled datasets from one task to another (usually from one user to another). A Layer Task is simply a Task with one layer, however, when transferring data, we know the file path stored in the Task is not going to be correct after it is put in another location. Therefor it occurred to me that if the Task file was named the same as the layer shape file, it would just be one more file that users would dutifully copy along with the five or six others needed to support ESRI Shapefiles. The OpenProjectPlugIn class was modified to add a check a Layer Task to the code that is invoked when a dataset's file is not found. A Merge Task option that supported multiple files was added to the File menu to make it possible to combine these Layer Tasks . The next step was to eliminate the user's manual process of identifying, copying, and merging all of these files, and replace it with the Archive Selected Datasets option. This Layer Tree right-click option saves all of the selected layers as Shapefiles inside a zip file and includes a Layer Task for each. Merge Task was enhanced to be Merge Task/Archive since it was basically the same process with or without the zip file. These Dataset Archives became so popular that we decided to allow saving changes directly to back to the zip file. Since there was a small speed penalty for working directly with zipped shapefiles, we added support for referencing them in a (normal) Task file. The first time you open the task, the zip file is extracted to your local temp directory, so the each subsequent time you open it, the files will be there already extracted. It still takes a little longer to save changes since the zip file must be updated too. This all sounds pretty complicated, but it isn't really. For the user, it just works like expected. We've been using it for quite a while without any problems. Sunburned and Michaël, I hope I have answered why a Layer Task is used instead of a single Task file that referenced the archived layers. I believe that Layer Tasks are more flexible, since you have the option of extracting and loading each layer individually without losing style information. However, with the Merge Task/Archive feature, you can actually do it any way that makes sense to you. Sunburned, you indicated concern that the user might be confused by input/output options on a context menu in the Layer View. You are right, that would be confusing, however I meant the Layer Name panel context menu, where we already have other I/O options. regards, Larry Becker On 6/14/07, Michaël Michaud <[EMAIL PROTECTED]> wrote: > Hi Larry, > > 1 - Sounds good, > 2 - Please, could you explain the need to save one task file per layer. > Isn't one task file enough to save all your selected layers as one > project. Otherwise, the idea to save a bunch of selected file as one zip > file sounds quite good. > 4 & 6 : Sounds good > 5 : Sounds good > > Thank you very much to help getting OpenJUMP in sync with SkyJUMP > > Michaël > > Larry Becker a écrit : > > >Thanks to Michaël for implementing the SkyJUMP rendering > >optimizations. Thanks to his efforts, the nightly build of OJ now > >gets identical redraw benchmark times with SkyJUMP. :-) > > > >There is still one more area where I think improvements are needed. > >SkyJUMP still opens tasks with many layers (100+) four times faster > >than OpenJump. Unfortunately, OpenProjectPlugIn is one of the most > >heavily modified classes in SkyJUMP so it might be hard to find the > >specific mod that gave the speed increase (if it was just one). It > >might be easier to just incorporate all of the mods if everyone agrees > >they are useful. > > > >I'll try to list all of the OpenProjectPlugIn-related SkyJUMP enhancements > >here: > > > >1. When opening a task or loading datasets, the task monitor dialog > >will now display a cancel button which will stop loading the layers. > >This can be important when you suddenly realize that you opened a task > >larger than memory. > > > >2. The open source personal geodatabase: Added a Create Archive > >feature to the right-click layer tree menu. This will archive all > >selected layers to a zip archive. This archive can then be used to > >transport or back up your project and opened using the new Merge > >Task/Archive menu item on the File menu. When opened in this manner, > >any changes to the layers will be saved to the archive with Save > >Selected Datasets.In order to preserve style information, each > >layer file is accompanied by a task file with the same name as the > >layer file. This is referred to as a Layer Task. There may be other > >details involve
Re: [JPP-Devel] OpenJump speed improvements
Hi Larry, 1 - Sounds good, 2 - Please, could you explain the need to save one task file per layer. Isn't one task file enough to save all your selected layers as one project. Otherwise, the idea to save a bunch of selected file as one zip file sounds quite good. 4 & 6 : Sounds good 5 : Sounds good Thank you very much to help getting OpenJUMP in sync with SkyJUMP Michaël Larry Becker a écrit : >Thanks to Michaël for implementing the SkyJUMP rendering >optimizations. Thanks to his efforts, the nightly build of OJ now >gets identical redraw benchmark times with SkyJUMP. :-) > >There is still one more area where I think improvements are needed. >SkyJUMP still opens tasks with many layers (100+) four times faster >than OpenJump. Unfortunately, OpenProjectPlugIn is one of the most >heavily modified classes in SkyJUMP so it might be hard to find the >specific mod that gave the speed increase (if it was just one). It >might be easier to just incorporate all of the mods if everyone agrees >they are useful. > >I'll try to list all of the OpenProjectPlugIn-related SkyJUMP enhancements >here: > >1. When opening a task or loading datasets, the task monitor dialog >will now display a cancel button which will stop loading the layers. >This can be important when you suddenly realize that you opened a task >larger than memory. > >2. The open source personal geodatabase: Added a Create Archive >feature to the right-click layer tree menu. This will archive all >selected layers to a zip archive. This archive can then be used to >transport or back up your project and opened using the new Merge >Task/Archive menu item on the File menu. When opened in this manner, >any changes to the layers will be saved to the archive with Save >Selected Datasets.In order to preserve style information, each >layer file is accompanied by a task file with the same name as the >layer file. This is referred to as a Layer Task. There may be other >details involved with this feature if anyone is interested. > >4. Added support for "deferred loading" of layers. When loading a >task file (.jmp) that contains layers that are not set to visible, >loading of the layer into memory is deferred until the layer is set to >visible. If many of your layers are only used occasionally, this can >speed up task loading tremendously. Note that until made visible, the >layer behaves like a new empty layer. > >5. Support for Layer Reload. Added a right-click Layer Tree option >that allows reloading the selected datasets. This allows you to >revert your geometry changes without reloading the entire task. Style >changes are unaffected. FID numbers are preserved. Any open >attribute views are also refreshed. > >6. Related to Deferred Layer Loading: Modified Open Task so that even >if layers are not visible (i.e loaded), it will still check to see if >their path is valid, and prompt to locate it if not. This prevents >being surprised several months later after you have forgotten where >the file is. > >Comments? > >Larry Becker > > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] OpenJump speed improvements
Larry, Number 1 sounds good. Number 4 sounds really good. Number 5 sounds good. Number 6 sounds good. I'm a little nervous about Number 2. It sounds like a really nifty feature, but I am wondering if we will confuse the user by adding what seems to be input/output to a context menu in the Layer View. I'm also not sure how If I understand the difference between a task and a Layer Task. If we are saving layers and styling information, aren't we really just saving a project file? Why not just zip the project file? I'm sure you have you reasons, I just don't "get" them quite yet. Maybe some of the other developers will comment on Number 2. I want to echo Stefan's thanks to both Larry Becker and Michael Michaud. The Sunburned Surveyor On 6/14/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > Hei Larry > > >Comments? > > > > > not really - except for (2) .. we need to get sure that all necessary > classes are transfered as well. > > For the rest it would turn out to preserve the old i18n-strings (fastest > way may be to make a copy from the old file and copy by hand) and create > some new ones for the new functions. Probably we could do it.. if you want. > > btw... i am not sure about (6) .. there has been also something in OJ > that prompts for the path if the file path is invalid (means i dont know > how much in sync OJ and SkyJump is on that point). > > thanx for your contributions :o) > > stefan > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] OpenJump speed improvements
Hei Larry >Comments? > > not really - except for (2) .. we need to get sure that all necessary classes are transfered as well. For the rest it would turn out to preserve the old i18n-strings (fastest way may be to make a copy from the old file and copy by hand) and create some new ones for the new functions. Probably we could do it.. if you want. btw... i am not sure about (6) .. there has been also something in OJ that prompts for the path if the file path is invalid (means i dont know how much in sync OJ and SkyJump is on that point). thanx for your contributions :o) stefan - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
