Re: [JPP-Devel] Feature collections modified by default
Stefan Steiniger wrote:
Hi,
finally I'm getting back to this.
playing save is what we should do.
For creating new layers I am most often using context.addLayer() - so
why not adding the flagging there instead of changing all plugins?
An option would be to create a second addLayer() method with a boolean
parameter for flagging if the new layer is modified.
However, this wouldn't work for
context.getLayerManager().addLayerable(..) - which is used for
(Sextante) Rasters. I.e. needs changes there too.
ok. I've attached patch which changes the following:
* new feature collections are again unmodified by default
* PlugInContext has an added addLayer method taking a
featureCollectionModified parameter for convenience
* when OpenJUMP is closed, and no layers have been modified, it still
asks whether you want to really exit the workbench
What are the opinions on this?
Thanks, Andreas
--
l a t / l o n GmbH
Aennchenstrasse 19 53177 Bonn, Germany
phone ++49 +228 18496-0 fax ++49 +228 1849629
http://www.lat-lon.dehttp://www.deegree.org
Follow deegree on Twitter: http://twitter.com/deegree_org
Index: src/language/jump.properties
===
--- src/language/jump.properties(revision 1994)
+++ src/language/jump.properties(working copy)
@@ -1701,6 +1701,7 @@
ui.WorkbenchFrame.committed-memory = Committed Memory
ui.WorkbenchFrame.continue = Continue
ui.WorkbenchFrame.dataset = Dataset
+ui.WorkbenchFramw.do-you-really-want-to-close-openjump = Do you really want to
close OpenJUMP?
ui.WorkbenchFrame.do-you-want-to-close-them-also = Do you want to close them
also ?
ui.WorkbenchFrame.exit = Exit
ui.WorkbenchFrame.exit-jump = Exit OpenJUMP
Index: src/language/jump_en.properties
===
--- src/language/jump_en.properties (revision 1994)
+++ src/language/jump_en.properties (working copy)
@@ -1663,6 +1663,7 @@
ui.WorkbenchFrame.committed-memory = Committed Memory
ui.WorkbenchFrame.continue = Continue
ui.WorkbenchFrame.dataset = Dataset
+ui.WorkbenchFramw.do-you-really-want-to-close-openjump = Do you really want to
close OpenJUMP?
ui.WorkbenchFrame.do-you-want-to-close-them-also = Do you want to close them
also ?
ui.WorkbenchFrame.exit = Exit
ui.WorkbenchFrame.exit-jump = Exit OpenJUMP
Index: src/language/jump_de.properties
===
--- src/language/jump_de.properties (revision 1994)
+++ src/language/jump_de.properties (working copy)
@@ -1664,6 +1664,7 @@
ui.WorkbenchFrame.committed-memory = Verwendeter Speicher
ui.WorkbenchFrame.continue = Weiter
ui.WorkbenchFrame.dataset = Datensatz
+ui.WorkbenchFramw.do-you-really-want-to-close-openjump = Wollen Sie OpenJUMP
wirklich beenden?
ui.WorkbenchFrame.do-you-want-to-close-them-also = Wollen Sie diese ebenfalls
schliessen?
ui.WorkbenchFrame.exit = OpenJUMP beenden
ui.WorkbenchFrame.exit-jump = JUMP Beenden
Index: src/com/vividsolutions/jump/workbench/plugin/PlugInContext.java
===
--- src/com/vividsolutions/jump/workbench/plugin/PlugInContext.java
(revision 1994)
+++ src/com/vividsolutions/jump/workbench/plugin/PlugInContext.java
(working copy)
@@ -155,6 +155,16 @@
return getLayerManager().addLayer(categoryName, layerName,
featureCollection);
}
+public Layer addLayer(
+String categoryName,
+String layerName,
+FeatureCollection featureCollection,
+boolean featureCollectionModified) {
+Layer l = getLayerManager().addLayer(categoryName, layerName,
featureCollection);
+l.setFeatureCollectionModified(featureCollectionModified);
+return l;
+}
+
public void addLayerSextanteRaster(
String categoryName,
RasterImageLayer raster) {
Index: src/com/vividsolutions/jump/workbench/model/Layer.java
===
--- src/com/vividsolutions/jump/workbench/model/Layer.java (revision 1994)
+++ src/com/vividsolutions/jump/workbench/model/Layer.java (working copy)
@@ -115,9 +115,6 @@
getBasicStyle().setLineColor(defaultLineColor(fillColor));
getBasicStyle().setAlpha(150);
setFeatureCollection(featureCollection);
- // michaelm [2009-02-20] consider that a new layer is modified
- // so that a confirmation is asked before application closing
- featureCollectionModified = true;
}
/**
Index: src/com/vividsolutions/jump/workbench/ui/WorkbenchFrame.java
===
--- src/com/vividsolutions/jump/workbench/ui/WorkbenchFrame.java
(revision 1994)
+++ src/com/vividsolutions/jump/workbench/ui/WorkbenchFrame.java
(working copy)
@@ -1270,9
Re: [JPP-Devel] Selectionstyle Patch
Hi Matthias, The code does indeed look much more efficient, however it still doesn't default to the old selection behavior, so I'm not sure how users outside your organization are going to react to the change. I don't like it as well as the current method which outlines the handles. Also there seems to be a problem with point selection feedback. Selected points just seem to disappear for me. regards, Larry On Fri, Jul 30, 2010 at 11:34 AM, Matthias Scholz m...@jammerhund.de wrote: Hi, please can Larry or any other check my modifications again? Now I've solved the problem that the previous saved settings are restored from blackboard. The modifications in the AbstractSelectionRenderer should now smart enough, so that we have no performance problems and can set the properties with setter methods. It would be nice and important for my users if we can integrate the patch in the upcoming release. Regards Matthias Hi Larry, please see the attached file. There is one problem at the moment. After loading a file or project the AbstractSelectionRenderer use the default settings. So you must go to the options an click OK in the SelectionStyllingOptionsPanel. This is because during construction of the SelectionStyllingOptionsPanel instance there is no LayerViewPanel instance an so on no RenderingManager available. Is there a Listener which is fired if the RenderingManager is available or if a layer was added or a file was loaded??? Regards Matthias Hi Matthias, I'm pretty sure that the right place to add setSelectionLineColor, setSelectionPointSize and setSelectionPointForm is AbstractSelectionRenderer since that is where the associated variables are declared. You will have to remove /final /from HANDLE_WIDTH. The real trick is getting the reference to FeatureSelectionRenderer to use the sets. I think this can be done with RenderManager by passing FeatureSelectionRenderer.CONTENT_ID.toRenderManager.getRenderer(). regards, Larry On Sun, Jul 11, 2010 at 7:58 AM, Matthias Scholz m...@jammerhund.demailto: m...@jammerhund.de wrote: Hi Larry, can we do the following? - add some setSelectionLineColor, setSelectionPointSize and setSelectionPointForm to com.vividsolutions.jump.workbench.ui.renderer.Renderer interface - implement simple setter in com.vividsolutions.jump.workbench.ui.renderer.FeatureCollectionRenderer, wich is the parent of AbstractSelectionRenderer which is the parent of FeatureSelectionRenderer, SelectionBackgroundRenderer, PartSelectionRenderer, LineStringSelectionRenderer - change the AbstractSelectionRenderer for using this variables while paint() - in a PlugIn in the OptionsPanel I can get the Renderer with context.getLayerViewPanel().getRenderingManager().getRenderer() call and the I can change the values whith the setter I'm not sure if the Renderer interface is the right place for the setter methods??? Please tell me your opinion, before I start. Any other suggestions are welcome! Regards Matthias I don't see an obvious solution. For one thing, it is unclear how your plugin would affect the interoperability of SelectionBackgroundRenderer, PartSelectionRenderer, and LineStringSelectionRenderer which uses constructors to select different feedback mechanisms. Larry On Sun, Jun 27, 2010 at 3:00 PM, Matthias Scholz m...@jammerhund.de mailto:m...@jammerhund.de mailto:m...@jammerhund.de mailto:m...@jammerhund.de wrote: Hi Sunburned Surveyor and Larry, sorry for my late reply, but i had no time to code last week :-( I agree with Larry's remarks. My question went toward the concrete implementation, as I currently do not have enough knowledge about the internals of OJ. At the beginning I would to build a plugin, but I do not know how to tell the AbstractSelectionRenderer, how he should render with my settings or with the old default one. So actually I have no idea how to integrate the plugin in the rendering process? At this point I need your help. I hope you understand my terrible english ;-) Matthias I haven't looked at the code Mathias provided. It sounds like Larry's provided some great comments. I hope the changes can be made so Mathias code can be integrated. If Mathias needs help making the mods Larry has suggested, he can let me know. The Sunburned Surveyor On Mon, Jun 21, 2010 at 6:28 AM, Larry Becker becker.la...@gmail.com mailto:becker.la...@gmail.com mailto:becker.la...@gmail.com mailto:becker.la...@gmail.com wrote: Hi Matthias, My concern about code efficiency is that this is
Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization
Hei Alberto, I changed the RasterImageLayer class to allow for dynamic loading. I haven't tested fully if it works as expected. Can you have a look. With respect to this I chose now some arbitrary values for maxPixelsForFastDisplayMode so we can change it... I have also added the changes to read ASCII grids. Also if you want I can give you write access to our SVN. I think you will do the right thing... ;) next I will look at the coloring. Have a good 2 weeks (holidays I assume ;). stefan Alberto De Luca wrote: Stefan, thank you for your plug-in, I'm looking forth to have a look at it. And about trasparency, I believe that something can be done with the RasterImageLayer class, I'll give it a try... I'll be away for 2 weeks, so I hope I'll be able to get back to this stuff when I'm back. Alberto On 05/08/2010 19:05, Stefan Steiniger wrote: Hei Alberto, i-loading small images: interesting proposal, need to look at it when I have time. (still hoping for the weekend) ii-coloring: the coloring is similar to what I did based on Paul Plouy's code - so I guess this is the way to go. I zip all classes and attach them. It contains also a color editor from pirol, but I didn't use it yet. iii-Transparency for no-data is also an open issue - don't know if that info is somewhere stored with RasterImageLayer. In Sextante it is... cheers, stefan Alberto De Luca wrote: Stefan, thank you for your quick reply. A couple of things about raster display: 1) when panning, only small images are reloaded. To avoid this, in RasterImageLayer.java we could just call #setNeedToKeepImage(true) when the following condition is true (around line 300): this.origImageWidth * this.origImageHeight) RasterImageLayer.getMaxPixelsForFastDisplayMode() // faster display (uses more RAM) for small images This way, we'd speed up the display of small images without the risk of finishing memory up. 2) The parameter maxPixelsForFastDisplayMode has a fixed value of 25. Maybe we could make this value dependent on available memory, so the concept of small image won't be absolute but dependent on system resources. With respect to raster symbology, I'd be interested to see your work. I've done a bit of work on raster symbology myself, it's just preliminary work, but I'd like to share it with you to see if it can be useful. I'm attaching here just a simple plug-in (source and jar in the rar archive) that allows to chose from a list of color models and repaints the selected raster consequently using a stretch renderer. There is only one color model available, and the color values are hardcoded. So you just select a raster layer from the layer list, start the plug-in from the tools menu, pick a color model and hit ok. The only problem is that you need to zoom in or out to see the changes in raster symbology! There used to be a method in the RasterImageLayer class, #forceRepaint that did the refresh, but I can't find it anymore... Plus I need to figure out how to show nodata cells as transparent. If you find this approach acceptable, I'd like to extend the tool so to allow the user to create and edit color models, both for stretched renderers and for class renderers. The models would then be saved as ascii filed (xml maybe). Alberto On 04/08/2010 18:57, Stefan Steiniger wrote: Hei Alberto, I hope to integrate your changes towards the weekend - if that works for you. And yes, I noticed too that the images are (most often) read for very pan or zoom operation to save memory. I discovered this when I did the coloring of the image and when I did a pan all the colors where gone - so I need to set layer.setNeedToKeepImage(true); and then it is not reloaded from file. However, so the easy fix may be to just set this option right after loading the file in #loadImage(). But then we might run into memory problems if several images are loaded... need to think about it. but if you have suggestions let me know. stefan Alberto De Luca wrote: Stefan, I had a look at your work, it seems great. To carry it a bit further I wrote a new class (GridAscii) to add reading capabilities for the ESRI ASCII GRID format. Consequently, I modified the following classes: AddRasterImageLayerWizard.java RasterImageLayer.java SelectRasterImageFilePanel.java I also did a bit of clean-up to the GridFloat class: following your work, I replaced the double[][] array with a Raster object. So you can now read the raster directly from GridFloat (and GridAscii as well) without need of any conversion. You can find all the java files attached to this email. It seems to me that the RasterImageLayer class makes a very conservative use of memory, favouring disk access to memory consumption. I was doing some tests using a 2000x2000 ASCII GRID file (roughly 35 MB on disk) and noticed that it is read 2 times from disk
Re: [JPP-Devel] Feature collections modified by default
Hi, ok. I've attached patch which changes the following: * new feature collections are again unmodified by default * PlugInContext has an added addLayer method taking a featureCollectionModified parameter for convenience * when OpenJUMP is closed, and no layers have been modified, it still asks whether you want to really exit the workbench What are the opinions on this? Thanks to have worked on this problem. If I understand correctly, proposed change are : 1 - OpenJUMP will always asks for confirmation before closing. 2 - OpenJUMP will still inform the user that some layers have been modified if these layers have really been modified (not just created) 3 - Programmer can now create new layers as unmodified or as modified layers (see below my remark) 4 - Existing plugin produce unmodified layers. There is point 3 that I dislike for the following reason : If we have not a clear policy about what is a modified layer, we'll soon have half newly created layers considered as modified and half considered as unmodified, thus confusing the user and introducing inconsistencies. To solve my initial problem, I think I can rely on the getDataSourceQuery which returns null for layers which are not yet saved to disk. My proposition is to let you change everything you put in the patch except the new method in PluginContext (there is also a typo in the key added in language files and in confirmClose method) I can see if a test on every Layer.getDataSourceQuery in the WorkbenchFrame.confirmClose method can solve my initial problem, by informing the user there is still one, or to, or n layers without datasource. What do you think ? Side note : in both cases, the solution is added at the Layer level and does not take raster into account. I wonder if modification status and dataSource should be shared by all AbstractLayerable ? But this is another question... Michaël Thanks, Andreas -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ 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 Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization
I actually just see that the Properties dialog of the raster layer has a transparency checkbox stefan Stefan Steiniger wrote: Hei Alberto, I changed the RasterImageLayer class to allow for dynamic loading. I haven't tested fully if it works as expected. Can you have a look. With respect to this I chose now some arbitrary values for maxPixelsForFastDisplayMode so we can change it... I have also added the changes to read ASCII grids. Also if you want I can give you write access to our SVN. I think you will do the right thing... ;) next I will look at the coloring. Have a good 2 weeks (holidays I assume ;). stefan Alberto De Luca wrote: -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization
me again, I don't have javax.swing.GroupLayout where is that from? I have only GridBagLayout from java.awt.* stefan Stefan Steiniger wrote: I actually just see that the Properties dialog of the raster layer has a transparency checkbox stefan Stefan Steiniger wrote: Hei Alberto, I changed the RasterImageLayer class to allow for dynamic loading. I haven't tested fully if it works as expected. Can you have a look. With respect to this I chose now some arbitrary values for maxPixelsForFastDisplayMode so we can change it... I have also added the changes to read ASCII grids. Also if you want I can give you write access to our SVN. I think you will do the right thing... ;) next I will look at the coloring. Have a good 2 weeks (holidays I assume ;). stefan Alberto De Luca wrote: -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ 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 Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Feature collections modified by default
Hei Michael, Side note : in both cases, the solution is added at the Layer level and does not take raster into account. I wonder if modification status and dataSource should be shared by all AbstractLayerable ? But this is another question... mhm.. interesting did not think about this either. Right now everything done in Sextante, which produces a new raster layer, will create a new (tif) file (in the windows temp folder) and then loads this file. So basically these files continue exists - but the user doesn't know about it. There is also no properties dialog as for the vector layers. So the user doesn't know if the image/raster is saved somewhere or not. Well, I guess adding here a dialog may not be the hardest task if time is given ;) stefan Michaël -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization
Hei Alberto, ok.. I have a problem here. I needed to revert some changes (dynamic loading etc). I am not sure what is going on, but if I do now some calculations I don't get proper reference to the rasters/layerable. So sometimes I have no reference and in other instance after the processing is done and results are returned... those results are shifted. It even happens with the convert to polygons function. Interestingly this faulty behaviour is visible when I open the raster color editor. if it contains no further elements, just the name, then something is wrong. However, if I use from the raster layer context menu the function: Export Envelope as geometry, then I get the correct reference back. not sure what happens here... stefan Stefan Steiniger wrote: me again, I don't have javax.swing.GroupLayout where is that from? I have only GridBagLayout from java.awt.* stefan Stefan Steiniger wrote: I actually just see that the Properties dialog of the raster layer has a transparency checkbox stefan Stefan Steiniger wrote: Hei Alberto, I changed the RasterImageLayer class to allow for dynamic loading. I haven't tested fully if it works as expected. Can you have a look. With respect to this I chose now some arbitrary values for maxPixelsForFastDisplayMode so we can change it... I have also added the changes to read ASCII grids. Also if you want I can give you write access to our SVN. I think you will do the right thing... ;) next I will look at the coloring. Have a good 2 weeks (holidays I assume ;). stefan Alberto De Luca wrote: -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ 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 Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ 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 Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
