Re: [JPP-Devel] SVN: [6596] core/trunk/src/com/vividsolutions/jump/workbench/imagery/ geoimg/GeoImage.java
Ede,Crop operation also uses floats, so I'm not sure it solves the problem. Difficult to guess the impact without a try though.The change may not be trivial as the scale operation which is currently performed at first place is also used to cache a scaled image which can be re-used when scale does not change (pan).Another track : during my test (commented code), I observed that displaying a very small part of the full image without scaling/cropping with jai first was efficient and precise (drawRenderedImage(RenderedImage,AffineTransform)). The problem is with the rendering of the full image. Then, graphics2D.drawRenderedImage is very slow (like the scaling operation with jai). The only way to interpolate the image efficiently when the full image has to be displayed seems to be the subsampling operation with jai. Mixing subsampling for certain scales and normal affine transform for others may do the trick, but it seems over complicated.Another track to be explored is the capability to use subsampled overviews wrapped in geotiff images (as described in Gary's mail about COG geotiff format). May be after migration...Michaël envoyé : 12 octobre 2020 à 21:29de : edgar.sol...@web.deà : OpenJump develop and use Cc: jump-pilot-...@lists.sourceforge.netobjet : Re: [JPP-Devel] SVN: [6596] core/trunk/src/com/vividsolutions/jump/workbench/imagery/ geoimg/GeoImage.javahey Mike,how about cropping first and scaling only the part shown?.. edeOn October 12, 2020 9:19:38 PM GMT+02:00, jump-pilot-svn--- via Jump-pilot-devel wrote:>Revision: 6596http://sourceforge.net/p/jump-pilot/code/6596>Author: michaudm>Date: 2020-10-12 19:19:38 + (Mon, 12 Oct 2020)>Log Message:>--->Keep double parameters as long as possible (does not solve the pb>described in #507) >Modified Paths:>-->core/trunk/src/com/vividsolutions/jump/workbench/imagery/geoimg/GeoImage.java >Modified:>core/trunk/src/com/vividsolutions/jump/workbench/imagery/geoimg/GeoImage.java>===>--->core/trunk/src/com/vividsolutions/jump/workbench/imagery/geoimg/GeoImage.java 2020-10-12>15:05:32 UTC (rev 6595)>+++>core/trunk/src/com/vividsolutions/jump/workbench/imagery/geoimg/GeoImage.java 2020-10-12>19:19:38 UTC (rev 6596)>@@ -37,6 +37,7 @@import java.awt.Rectangle;import java.awt.RenderingHints;import java.awt.geom.AffineTransform;>+import java.awt.geom.NoninvertibleTransformException;import java.awt.image.BufferedImage;import java.awt.image.RenderedImage;import java.awt.image.renderable.ParameterBlock;>@@ -44,10 +45,15 @@import javax.media.jai.JAI;import javax.media.jai.RenderedOp;>+import javax.media.jai.operator.AffineDescriptor; >+import com.vividsolutions.jts.geom.Coordinate;import com.vividsolutions.jts.geom.Envelope;>+import com.vividsolutions.jts.geom.util.AffineTransformation;>+import com.vividsolutions.jts.geom.util.AffineTransformationBuilder;import com.vividsolutions.jump.JUMPException;import com.vividsolutions.jump.feature.Feature;>+import com.vividsolutions.jump.util.Timer;import com.vividsolutions.jump.workbench.imagery.ReferencedImage;>import>com.vividsolutions.jump.workbench.imagery.ReferencedImageException;import com.vividsolutions.jump.workbench.model.Disposable;>@@ -57,7 +63,7 @@>public class GeoImage implements ReferencedImage, Disposable,>AlphaSetting {private GeoReferencedRaster gtr; private int alpha = 255;>- private float last_scale;>+ private double last_scale;private RenderedOp last_scale_img; private Envelope last_img_env; private RenderedImage last_rendering;>@@ -92,6 +98,7 @@>public synchronized void paint(Feature f, java.awt.Graphics2D g,>Viewport viewport)throws ReferencedImageException {>+ //long t0 = Timer.now();try { // update image envelope, either use geometry's or image's // this allows moving the image via geometry movement>@@ -109,17 +116,17 @@// + Integer.toHexString(img.hashCode())); // get current scale>- final float scale = (float) viewport.getScale();>+ final double scale = viewport.getScale();// get current viewport areaEnvelope envModel_viewport = viewport.getEnvelopeInModelCoordinates(); // if nothing changed, no reason to rerender the whole shebang // this is mainly the case when OJ last and regained focus>- if (last_scale == scale && last_img_env instanceof Envelope>- && last_img_env.equals(envImage) && last_vwp_env instanceof>Envelope>+ if (last_scale == scale && last_img_env != null>+ && last_img_env.equals(envImage) && last_vwp_env != null&& last_vwp_env.equals(envModel_viewport)>- && last_rendering instanceof RenderedImage>- && last_transform instanceof AffineTransform) {>+ && last_rendering != null>+ && last_transform != null) {draw(g, null); return; }>@@ -132,7 +139,7 @@// reuse a cached version if scale and img_envelope didn't changed // speeds up panning, window resizing if (last_scale == scale && last_scale_img != null>- && last_img_env instanceof Envelope>+ && last_img_env != null&& last_img_env.equals(envImage)) { img = last_sca
[JPP-Devel] [jump-pilot:bugs] Re: #507 GeoImage and high zoom level
On 10/12/2020 19:27, michael michaud wrote: > There are two problems in GeoImage.paint when using very high level of zoom : > - the image to display is computed with jai transformations like scaling, > subsampling or cropping which use float parameters : at very high levels of > zoom, the lower right corner of the image is not displayed at its right > position compared with vector data which use doubles for transformations. we could use the vector(envelope) calculation results to scale the image. that'd solve the disparity. questions is though which of the two is the more correct one, as i understand that floating point has a higher accuracy than then doubles when talking about small values. >I tried to replace jai transformations usinf floats by other transformations >using doubles (like jai affine transform), but it is much slower. performancewise we might be able to switch scaling algorithms for some operations >It seems that current implementation efficiency is for a large part related to >the use of subsample jai transformation which is way faster than other type of >scaling, but which use float parameters. when we know which is more accurate (float/double) we can can streamline vector/image calculation and the difference would disappear > - the second point, maybe related to the previous one is that zooming finally > ends with an exception : > Caused by: java.lang.IllegalArgumentException: Crop The rectangular crop area > must not be outside the image. > at javax.media.jai.JAI.createNS(JAI.java:1087) > at javax.media.jai.JAI.create(JAI.java:973) > at > com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:298) this should probably be checked beforehand. of course it makes no sense to add a crop if there is nothing to crop ;) --- ** [bugs:#507] GeoImage and high zoom level** **Status:** open **Milestone:** OJ_future **Created:** Mon Oct 12, 2020 05:27 PM UTC by michael michaud **Last Updated:** Mon Oct 12, 2020 05:27 PM UTC **Owner:** nobody There are two problems in GeoImage.paint when using very high level of zoom : - the image to display is computed with jai transformations like scaling, subsampling or cropping which use float parameters : at very high levels of zoom, the lower right corner of the image is not displayed at its right position compared with vector data which use doubles for transformations. I tried to replace jai transformations usinf floats by other transformations using doubles (like jai affine transform), but it is much slower. It seems that current implementation efficiency is for a large part related to the use of subsample jai transformation which is way faster than other type of scaling, but which use float parameters. - the second point, maybe related to the previous one is that zooming finally ends with an exception : Caused by: java.lang.IllegalArgumentException: Crop The rectangular crop area must not be outside the image. at javax.media.jai.JAI.createNS(JAI.java:1087) at javax.media.jai.JAI.create(JAI.java:973) at com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:298) --- Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/jump-pilot/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] SVN: [6596] core/trunk/src/com/vividsolutions/jump/workbench/imagery/ geoimg/GeoImage.java
On 10/13/2020 9:48, Michaud Michael wrote: > Ede, > > Crop operation also uses floats, so I'm not sure it solves the problem. > Difficult to guess the impact without a try though. > > The change may not be trivial as the scale operation which is currently > performed at first place is also used to cache a scaled image which can be > re-used when scale does not change (pan). right, didn't think about that. > Another track : during my test (commented code), I observed that displaying a > very small part of the full image without scaling/cropping with jai first was > efficient and precise (drawRenderedImage(RenderedImage,AffineTransform)). how do you mean? how do you fit the image without scaling/cropping? > The problem is with the rendering of the full image. Then, > graphics2D.drawRenderedImage is very slow (like the scaling operation with > jai). you mean when the full image i visable in the viewport, right? >The only way to interpolate the image efficiently when the full image has to >be displayed seems to be the subsampling operation with jai. Mixing >subsampling for certain scales and normal affine transform for others may do >the trick, but it seems over complicated. isn't that what we do with 2000/2000px special case currently? like a built in overview? > Another track to be explored is the capability to use subsampled overviews > wrapped in geotiff images (as described in Gary's mail about COG geotiff > format). May be after migration... wrapping any image format into a virtual geotiff sounds even more complicated. ..ede ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] [jump-pilot:bugs] #89 label offset should be set according to symbol size
I thgink we can close it. It was more like a feature request than a bug. At that time I was in the need to have a tool like that. Not now. I am goung to save it as Feature request --- ** [bugs:#89] label offset should be set according to symbol size** **Status:** open **Milestone:** OJ_1.16 **Created:** Fri Jul 13, 2007 08:51 AM UTC by Anonymous **Last Updated:** Sun Sep 13, 2020 06:31 PM UTC **Owner:** nobody see email by Geoff: New Vertex Symbols Plugin : 11. July 2007: 3:31 Dear Giuseppe Thank you for your comments. Please see my responses below: geoff Giuseppe Aruta wrote: > Hi Geoff, > > I would like to ask you some questions about your > plugins. These are not requests, but ideas that I had > since I think your plugins is very important for OJ > and I use them quite a lot. > > 1\) Do you plan to add on your vertex plugin the > possibility to change type of symbols according to an > attribute value \(saving rotate according to another > attribute\)? Currently it is only possible to change the symbol orientation according to an attribute value. It might be possible to change the size according to value - though this is more problematical as the ability of the observer to distinguish relative size is less that distinguishing relative rotation \(at least I think it is\!\). Changing the symbol type is probably not practical as is is assumed that the same symbol type applies to all vertices in a layer. This would require \(I suspect\) a change to the core Jump code \(comments from developers please?\). Currently, as you know, the vertex label provides a way of showing a \(numeric\) value at the vertex. > I found an alternative way to it using labels for > symbols \(with extra fonts\); but I still think that, if > this will nicelly completed your plugin which becomes > extremely useful in OJ. > > > 3\) a vertex symbol plugin changed radically the idea > of labels. If people want to use labels with their > symbols they found the difficulties that labels will > be always on the top of them \(expecially with big > sized symbols\). The question is : how difficult is to > influence the label style in order that labels always > stay outside defined size of symbols? > This would require an option in the core to set an offset for the label, according to the size of the symbol. Developers - any ideas? > I thank you in advance for the answer and thanks again > for the good job you make \(very good the idea of WKT > symbols\!\) > > > Peppe > --- Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/jump-pilot/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] [jump-pilot:bugs] #89 label offset should be set according to symbol size
- **status**: open --> closed-invalid - **assigned_to**: Giuseppe Aruta --- ** [bugs:#89] label offset should be set according to symbol size** **Status:** closed-invalid **Milestone:** OJ_1.16 **Created:** Fri Jul 13, 2007 08:51 AM UTC by Anonymous **Last Updated:** Tue Oct 13, 2020 11:08 AM UTC **Owner:** Giuseppe Aruta see email by Geoff: New Vertex Symbols Plugin : 11. July 2007: 3:31 Dear Giuseppe Thank you for your comments. Please see my responses below: geoff Giuseppe Aruta wrote: > Hi Geoff, > > I would like to ask you some questions about your > plugins. These are not requests, but ideas that I had > since I think your plugins is very important for OJ > and I use them quite a lot. > > 1\) Do you plan to add on your vertex plugin the > possibility to change type of symbols according to an > attribute value \(saving rotate according to another > attribute\)? Currently it is only possible to change the symbol orientation according to an attribute value. It might be possible to change the size according to value - though this is more problematical as the ability of the observer to distinguish relative size is less that distinguishing relative rotation \(at least I think it is\!\). Changing the symbol type is probably not practical as is is assumed that the same symbol type applies to all vertices in a layer. This would require \(I suspect\) a change to the core Jump code \(comments from developers please?\). Currently, as you know, the vertex label provides a way of showing a \(numeric\) value at the vertex. > I found an alternative way to it using labels for > symbols \(with extra fonts\); but I still think that, if > this will nicelly completed your plugin which becomes > extremely useful in OJ. > > > 3\) a vertex symbol plugin changed radically the idea > of labels. If people want to use labels with their > symbols they found the difficulties that labels will > be always on the top of them \(expecially with big > sized symbols\). The question is : how difficult is to > influence the label style in order that labels always > stay outside defined size of symbols? > This would require an option in the core to set an offset for the label, according to the size of the symbol. Developers - any ideas? > I thank you in advance for the answer and thanks again > for the good job you make \(very good the idea of WKT > symbols\!\) > > > Peppe > --- Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/jump-pilot/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] [jump-pilot:feature-requests] #271 Extend capaiblities of Cadplan vertex symbology plugin
--- ** [feature-requests:#271] Extend capaiblities of Cadplan vertex symbology plugin** **Status:** open **Created:** Tue Oct 13, 2020 11:11 AM UTC by Giuseppe Aruta **Last Updated:** Tue Oct 13, 2020 11:11 AM UTC **Owner:** nobody see email by Geoff: New Vertex Symbols Plugin : 11. July 2007: 3:31 Dear Giuseppe Thank you for your comments. Please see my responses below: geoff Giuseppe Aruta wrote: > Hi Geoff, > > I would like to ask you some questions about your > plugins. These are not requests, but ideas that I had > since I think your plugins is very important for OJ > and I use them quite a lot. > > 1) Do you plan to add on your vertex plugin the > possibility to change type of symbols according to an > attribute value (saving rotate according to another > attribute)? Currently it is only possible to change the symbol orientation according to an attribute value. It might be possible to change the size according to value - though this is more problematical as the ability of the observer to distinguish relative size is less that distinguishing relative rotation (at least I think it is!). Changing the symbol type is probably not practical as is is assumed that the same symbol type applies to all vertices in a layer. This would require (I suspect) a change to the core Jump code (comments from developers please?). Currently, as you know, the vertex label provides a way of showing a (numeric) value at the vertex. > I found an alternative way to it using labels for > symbols (with extra fonts); but I still think that, if > this will nicelly completed your plugin which becomes > extremely useful in OJ. > > > 3) a vertex symbol plugin changed radically the idea > of labels. If people want to use labels with their > symbols they found the difficulties that labels will > be always on the top of them (expecially with big > sized symbols). The question is : how difficult is to > influence the label style in order that labels always > stay outside defined size of symbols? > This would require an option in the core to set an offset for the label, according to the size of the symbol. Developers - any ideas? > I thank you in advance for the answer and thanks again > for the good job you make (very good the idea of WKT > symbols!) > > > Peppe > --- Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/jump-pilot/feature-requests/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jump-pilot/admin/feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] [jump-pilot:bugs] #291 Problem on drop-down menus
I cannot observe this behaviour any more. It seems that it was solved in the time Closed fixed --- ** [bugs:#291] Problem on drop-down menus** **Status:** open **Milestone:** OJ_1.16 **Labels:** General / Other **Created:** Sat Mar 16, 2013 08:20 PM UTC by Giuseppe Aruta **Last Updated:** Sun Sep 13, 2020 05:42 PM UTC **Owner:** nobody I found this bug on Ubuntu \(12.04\) with OpenJDK 1.6. This bug is not evident on Windows or Mac with Oracle Java. I didn't test right now on Ubuntu with Oracle Java. Description Sometimes Drop-down menu of Open File \(or similar Open Project or Add Raster ayer\) seems to works fine: a\) click on the arrow, b\) drop-down menu remains on the screen and users can choose the type of file. But after using some times "Open Files" or similar \(included Open Wizard\), randomly, drop-down menu stops to work. This is the behaviour: a\) click on the arrow, b\) drop-down menu cames out, c\) if user realise mouse menu, drop down disappears and user cannot do any choice. Drop-down menu remains evident on the screen only if user leaves the cursor on the arrow with left button \(of mouse\) presse: the only way, in this case, to choose type of file is to use keyboard up-down keys with a hand \(using the other to press on the drop-down arrow of the menu. By the time that this behaviour comes out it remains until user closes OJ and reopens it. regards Peppe --- Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/jump-pilot/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] [jump-pilot:bugs] #291 Problem on drop-down menus
- **status**: open --> closed-fixed --- ** [bugs:#291] Problem on drop-down menus** **Status:** closed-fixed **Milestone:** OJ_1.16 **Labels:** General / Other **Created:** Sat Mar 16, 2013 08:20 PM UTC by Giuseppe Aruta **Last Updated:** Tue Oct 13, 2020 11:14 AM UTC **Owner:** nobody I found this bug on Ubuntu \(12.04\) with OpenJDK 1.6. This bug is not evident on Windows or Mac with Oracle Java. I didn't test right now on Ubuntu with Oracle Java. Description Sometimes Drop-down menu of Open File \(or similar Open Project or Add Raster ayer\) seems to works fine: a\) click on the arrow, b\) drop-down menu remains on the screen and users can choose the type of file. But after using some times "Open Files" or similar \(included Open Wizard\), randomly, drop-down menu stops to work. This is the behaviour: a\) click on the arrow, b\) drop-down menu cames out, c\) if user realise mouse menu, drop down disappears and user cannot do any choice. Drop-down menu remains evident on the screen only if user leaves the cursor on the arrow with left button \(of mouse\) presse: the only way, in this case, to choose type of file is to use keyboard up-down keys with a hand \(using the other to press on the drop-down arrow of the menu. By the time that this behaviour comes out it remains until user closes OJ and reopens it. regards Peppe --- Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/jump-pilot/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] [jump-pilot:bugs] Re: #507 GeoImage and high zoom level
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml";> envoyé : 13 octobre 2020 à 12:22de : ede à : "[jump-pilot:bugs] " <5...@bugs.jump-pilot.p.re.sourceforge.net>objet : [jump-pilot:bugs] Re: #507 GeoImage and high zoom levelOn 10/12/2020 19:27, michael michaud wrote:There are two problems in GeoImage.paint when using very high level of zoom : - the image to display is computed with jai transformations like scaling, subsampling or cropping which use float parameters : at very high levels of zoom, the lower right corner of the image is not displayed at its right position compared with vector data which use doubles for transformations.we could use the vector(envelope) calculation results to scale the image. that'd solve the disparity. questions is though which of the two is the more correct one, as i understand that floating point has a higher accuracy than then doubles when talking about small values.the envelope is already used. In my test, I can see the problem on an image wich is exactly 10 000 pixels x 0.2m = 200m. Every corner of the image should be aligned with a grid, either of 100m, 10m, 1m or 0.1m resolution.But when the image size is computed using floats (4 bytes of precision only, which is about 8 digits instead of 16 for doubles) : we get 0.2f * 1f = 2000.298023224 instead of 2000.0 if we use double ()Floating points have always a lower accuracy. Doubles is the standard as far as JTS is concerned, and using floats produce results with a lower accuracy.I tried to replace jai transformations usinf floats by other transformations using doubles (like jai affine transform), but it is much slower.performancewise we might be able to switch scaling algorithms for some operationsIn my tests to scale the image with the full precision of doubles, I did not only switch operations, I completely replaced the usage of jai (scaling/subsampling, cropping) by the usage of Graphics2D.drawRenderedImage(Image, AffineTransform) which probably delegates scaling/interpolation/cropping to awt.With jai, the only scaling method which seems to be very fast is the method using subsampling, and it uses float parameters.It is probably possible to switch between jai and awt method depending on the scale level, but I'm afraid we obtain an illegant code quite difficult to maintain. It seems that current implementation efficiency is for a large part related to the use of subsample jai transformation which is way faster than other type of scaling, but which use float parameters.when we know which is more accurate (float/double) we can can streamline vector/image calculation and the difference would disappearDouble is more accurate for sure, but I don't understand what you mean by "streamlining vector/image calculation".the second point, maybe related to the previous one is that zooming finally ends with an exception : Caused by: java.lang.IllegalArgumentException: Crop The rectangular crop area must not be outside the image. at javax.media.jai.JAI.createNS(JAI.java:1087) at javax.media.jai.JAI.create(JAI.java:973) at com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:298)this should probably be checked beforehand. of course it makes no sense to add a crop if there is nothing to crop ;)Ya, it is probably possible to catch the error. The problem is that the error is thrown in a situation where the image should be shown (and where cropping should be possible), but is not because of the roundings made by floats usage. https://sourceforge.net/p/jump-pilot/bugs/507/";>[bugs:#507] GeoImage and high zoom levelStatus: open Milestone: OJ_future Created: Mon Oct 12, 2020 05:27 PM UTC by michael michaud Last Updated: Mon Oct 12, 2020 05:27 PM UTC Owner: nobodyThere are two problems in GeoImage.paint when using very high level of zoom : - the image to display is computed with jai transformations like scaling, subsampling or cropping which use float parameters : at very high levels of zoom, the lower right corner of the image is not displayed at its right position compared with vector data which use doubles for transformations. I tried to replace jai transformations usinf floats by other transformations using doubles (like jai affine transform), but it is much slower. It seems that current implementation efficiency is for a large part related to the use of subsample jai transformation which is way faster than other type of scaling, but which use float parameters. - the second point, maybe related to the previous one is that zooming finally ends with an exception : Caused by: java.lang.IllegalArgumentException: Crop The rectangular crop area must not be outside the image. at javax.media.jai.JAI.createNS(JAI.java:1087) at javax.media.jai.JAI.create(JAI.java:973) at com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:298)Sent from sourceforge.net because you indicated interest
[JPP-Devel] [jump-pilot:bugs] #385 Paste Layerable fails to work with RasterImageLayer class
Using Ubuntu. Loading an image as RasterImageLayer (Sextante). Using the coomad "Copy selected layer" I have this warning: com.vividsolutions.jts.util.AssertionFailedException: Should never reach here at com.vividsolutions.jts.util.Assert.shouldNeverReachHere(Assert.java:122) at com.vividsolutions.jts.util.Assert.shouldNeverReachHere(Assert.java:111) at com.vividsolutions.jump.workbench.ui.plugin.clipboard.LayerableClipboardPlugIn.cloneLayerable(LayerableClipboardPlugIn.java:71) at com.vividsolutions.jump.workbench.ui.plugin.clipboard.CopySelectedLayersPlugIn.clone(CopySelectedLayersPlugIn.java:85) at com.vividsolutions.jump.workbench.ui.plugin.clipboard.CopySelectedLayersPlugIn.execute(CopySelectedLayersPlugIn.java:68) at com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:344) at java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1967) --- ** [bugs:#385] Paste Layerable fails to work with RasterImageLayer class** **Status:** pending **Milestone:** OJ_1.16 **Labels:** RasterImageLayer **Created:** Mon Jan 19, 2015 05:35 PM UTC by Giuseppe Aruta **Last Updated:** Mon Aug 31, 2020 09:11 AM UTC **Owner:** nobody It seems that Paste Raster layer plugin (of Sextante Raster Image Layer - layer context menu) has no effects on paste a raster layer. It returns a null point exception. See below for error details ava.lang.NullPointerException at com.vividsolutions.jump.workbench.ui.plugin.clipboard.PasteLayersPlugIn.execute(PasteLayersPlugIn.java:96) at com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:342) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341) --- Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/jump-pilot/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] SVN: [6597] core/trunk
Revision: 6597
http://sourceforge.net/p/jump-pilot/code/6597
Author: ma15569
Date: 2020-10-13 12:25:39 + (Tue, 13 Oct 2020)
Log Message:
---
Moved RasterizePlugIn to Raster menu
Modified Paths:
--
core/trunk/scripts/default-plugins.xml
core/trunk/src/org/openjump/core/ui/plugin/tools/generate/RasterizePlugIn.java
Modified: core/trunk/scripts/default-plugins.xml
===
--- core/trunk/scripts/default-plugins.xml 2020-10-12 19:19:38 UTC (rev
6596)
+++ core/trunk/scripts/default-plugins.xml 2020-10-13 12:25:39 UTC (rev
6597)
@@ -744,9 +744,6 @@
org.openjump.core.ui.plugin.tools.generate.LinearReferencingOnSelectionPlugIn
-
- org.openjump.core.ui.plugin.tools.generate.RasterizePlugIn
-
com.vividsolutions.jump.workbench.ui.warp.WarpingPlugIn
@@ -895,6 +892,14 @@
+
+ org.openjump.core.ui.plugin.tools.generate.RasterizePlugIn
+
+
+
+
org.openjump.core.ui.plugin.raster.CreateLatticeFromSelectedImageLayerPlugIn
Modified:
core/trunk/src/org/openjump/core/ui/plugin/tools/generate/RasterizePlugIn.java
===
---
core/trunk/src/org/openjump/core/ui/plugin/tools/generate/RasterizePlugIn.java
2020-10-12 19:19:38 UTC (rev 6596)
+++
core/trunk/src/org/openjump/core/ui/plugin/tools/generate/RasterizePlugIn.java
2020-10-13 12:25:39 UTC (rev 6597)
@@ -65,7 +65,6 @@
import com.vividsolutions.jump.workbench.ui.GUIUtil;
import com.vividsolutions.jump.workbench.ui.GenericNames;
import com.vividsolutions.jump.workbench.ui.LayerNameRenderer;
-import com.vividsolutions.jump.workbench.ui.MenuNames;
import com.vividsolutions.jump.workbench.ui.MultiInputDialog;
import com.vividsolutions.jump.workbench.ui.Viewport;
import com.vividsolutions.jump.workbench.ui.images.IconLoader;
@@ -131,7 +130,7 @@
return RASTERIZE_VECTOR;
}
-@Override
+ /* @Override
public void initialize(PlugInContext context) throws Exception {
context.getFeatureInstaller().addMainMenuPlugin(
this,
@@ -138,7 +137,7 @@
new String[]{MenuNames.TOOLS,MenuNames.TOOLS_GENERATE},
getName(), false,ICON,
createEnableCheck(context.getWorkbenchContext()), -1);
-}
+}*/
public static MultiEnableCheck createEnableCheck(WorkbenchContext
workbenchContext) {
EnableCheckFactory checkFactory = new
EnableCheckFactory(workbenchContext);
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] [jump-pilot:bugs] #385 Paste Layerable fails to work with RasterImageLayer class
Peppe, it appears that in commit 6437, you reverted the fix I did in commit 6399 to fix this bug. Do you remember why you reverted the change I did in clone() method. Thanks --- ** [bugs:#385] Paste Layerable fails to work with RasterImageLayer class** **Status:** pending **Milestone:** OJ_1.16 **Labels:** RasterImageLayer **Created:** Mon Jan 19, 2015 05:35 PM UTC by Giuseppe Aruta **Last Updated:** Tue Oct 13, 2020 11:27 AM UTC **Owner:** nobody It seems that Paste Raster layer plugin (of Sextante Raster Image Layer - layer context menu) has no effects on paste a raster layer. It returns a null point exception. See below for error details ava.lang.NullPointerException at com.vividsolutions.jump.workbench.ui.plugin.clipboard.PasteLayersPlugIn.execute(PasteLayersPlugIn.java:96) at com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:342) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341) --- Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/jump-pilot/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] SVN: [6598] core/trunk/src/org/openjump/core/rasterimage/ RasterImageLayer.java
Revision: 6598
http://sourceforge.net/p/jump-pilot/code/6598
Author: ma15569
Date: 2020-10-14 04:39:56 + (Wed, 14 Oct 2020)
Log Message:
---
Restored method clone() to version 6399 (see bug fix #385 Paste Layerable fails
to work with RasterImageLayer class - discussion)
Modified Paths:
--
core/trunk/src/org/openjump/core/rasterimage/RasterImageLayer.java
Modified: core/trunk/src/org/openjump/core/rasterimage/RasterImageLayer.java
===
--- core/trunk/src/org/openjump/core/rasterimage/RasterImageLayer.java
2020-10-13 12:25:39 UTC (rev 6597)
+++ core/trunk/src/org/openjump/core/rasterimage/RasterImageLayer.java
2020-10-14 04:39:56 UTC (rev 6598)
@@ -263,28 +263,16 @@
@Override
public Object clone() throws CloneNotSupportedException {
-super.clone();
RasterImageLayer raster = null;
-if (this.isNeedToKeepImage()) {
-try {
-raster = new RasterImageLayer(getName(), getLayerManager(),
getImageForDisplay(), getRasterData(null), new
Envelope(getWholeImageEnvelope()));
-} catch (IOException ex) {
-Logger.error(ex);
-} catch (NoninvertibleTransformException ex) {
-Logger.error(ex);
-} catch (Exception ex) {
-Logger.error(ex);
-}
-} else {
-try {
-raster = new RasterImageLayer(getName(), getLayerManager(),
getImageFileName(), getImageForDisplay(), new
Envelope(getWholeImageEnvelope()));
-} catch (IOException ex) {
-Logger.error(ex);
-} catch (NoninvertibleTransformException ex) {
-Logger.error(ex);
-} catch (Exception ex) {
-Logger.error(ex);
-}
+try {
+raster = new RasterImageLayer(getName(), getLayerManager(),
getImageFileName(), getImageForDisplay(), new
Envelope(getWholeImageEnvelope()));
+raster.needToKeepImage = needToKeepImage;
+} catch (IOException ex) {
+Logger.error(ex);
+} catch (NoninvertibleTransformException ex) {
+Logger.error(ex);
+} catch (Exception ex) {
+Logger.error(ex);
}
// clone must produce a layerable with the same name (as for Layer)
not a unique name
if (raster != null) {
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] [jump-pilot:bugs] #385 Paste Layerable fails to work with RasterImageLayer class
Hi Michael, sorry for that. I was working to solve problems on visibility/query on raster layers and I inadvertently reverted your change. I restore it back to 6399 and today I will do some tests Peppe --- ** [bugs:#385] Paste Layerable fails to work with RasterImageLayer class** **Status:** pending **Milestone:** OJ_1.16 **Labels:** RasterImageLayer **Created:** Mon Jan 19, 2015 05:35 PM UTC by Giuseppe Aruta **Last Updated:** Tue Oct 13, 2020 09:10 PM UTC **Owner:** nobody It seems that Paste Raster layer plugin (of Sextante Raster Image Layer - layer context menu) has no effects on paste a raster layer. It returns a null point exception. See below for error details ava.lang.NullPointerException at com.vividsolutions.jump.workbench.ui.plugin.clipboard.PasteLayersPlugIn.execute(PasteLayersPlugIn.java:96) at com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:342) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341) --- Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/jump-pilot/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
