Re: [JPP-Devel] Bug fixed for exporting (Sextante/Pirol)-Raster files in OpenJUMP
Hi Stefan, The WorldFileWriter class used by the JPEG writer has the correct pixel offset. @Peppe, I haven't actually tried it, but the code look right. regards, Larry On Sun, Dec 6, 2009 at 3:31 PM, Stefan Steiniger sst...@geo.uzh.ch wrote: Hei Peppe, thanks for looking into it. so - it appears for JPG too? that means it is also a problem of the old framework? mhm.. I think I need to do an additional vector rasterization-overlay check in ArcGIS. stefan Giuseppe Aruta schrieb: Hi Stefan, I confirm your observation in AdbToolbox (Openjump derived) and Skyjump (Jump derived), I loaded a wms with ortophotos and saved them in JPG. Than I reloaded into the workbenck. In both cases there is a shift of 1/2 pixel to NW, as you mentioned. It seems that the problem is on Jump family side. Regards Peppe --- *Ven 4/12/09, Stefan Steiniger /sst...@geo.uzh.ch/* ha scritto: Da: Stefan Steiniger sst...@geo.uzh.ch Oggetto: Re: [JPP-Devel] [Sextante-users] Bug fixed for exporting (Sextante/Pirol)-Raster files in OpenJUMP A: Victor Olaya Ferrero vol...@unex.es Cc: List for discussion of JPP development and use. jump-pilot-devel@lists.sourceforge.net, openjump-us...@googlegroups.com, sextante-us...@lists.forge.osor.eu Data: Venerdì 4 dicembre 2009, 19:26 Hei Victor, no it's only on the OpenJUMP side. So, no problem for you. Images are correctly exported to OpenJUMP (at least it looks like, when I compare for instance points and the rasterized versions. But I haven't really checked that). stefan Victor Olaya Ferrero wrote: Stefan, Is that a bug in the SEXTANTE-OJ Bindings, or a SEXTANTE bug that might affect other users?? A Geotools user recently reported a similar behaviour and a fix (that I haven't updated yet, since it is a quick fix and I still have to test it a bit more). Regards. Victor Hei all, today I discovered a problem with the tif image export for raster files if for instance Sextante raster processing results should be exported. Unfortunately the export function shifted the images by 0.5 pixels towards NW (since the current implementation did not respect that the world file coordinate is given for the center of the first pixel - and not the pixel corner) I did a bug fix an hour ago. I hope that tomorrows nightly build contains this fix. You can see if it works by exporting a loaded tif file (using the load Sextante raster image option) with Save Raster Image from the raster image layer context menu, and reload the file again (using Open.. Sextante Raster...). If there is a shift in both images, then this is a non-fixed version. I am sorry for any troubles that may have occurred (the fastest way may be to fix the world files). stefan PS: As this a severe problem, I will try to make a new OpenJUMP release the next days. ___ Sextante-users mailing list sextante-us...@lists.forge.osor.eu /mc/compose?to=sextante-us...@lists.forge.osor.eu https://lists.forge.osor.eu/listinfo/sextante-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net /mc/compose?to=jump-pilot-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on
Re: [JPP-Devel] Bug fixed for exporting (Sextante/Pirol)-Raster files in OpenJUMP
yep.. it seemed to me too, that jpg is exported correctly. stefan Larry Becker wrote: Hi Stefan, The WorldFileWriter class used by the JPEG writer has the correct pixel offset. @Peppe, I haven't actually tried it, but the code look right. regards, Larry On Sun, Dec 6, 2009 at 3:31 PM, Stefan Steiniger sst...@geo.uzh.ch mailto:sst...@geo.uzh.ch wrote: Hei Peppe, thanks for looking into it. so - it appears for JPG too? that means it is also a problem of the old framework? mhm.. I think I need to do an additional vector rasterization-overlay check in ArcGIS. stefan Giuseppe Aruta schrieb: Hi Stefan, I confirm your observation in AdbToolbox (Openjump derived) and Skyjump (Jump derived), I loaded a wms with ortophotos and saved them in JPG. Than I reloaded into the workbenck. In both cases there is a shift of 1/2 pixel to NW, as you mentioned. It seems that the problem is on Jump family side. Regards Peppe --- *Ven 4/12/09, Stefan Steiniger /sst...@geo.uzh.ch mailto:sst...@geo.uzh.ch/* ha scritto: Da: Stefan Steiniger sst...@geo.uzh.ch mailto:sst...@geo.uzh.ch Oggetto: Re: [JPP-Devel] [Sextante-users] Bug fixed for exporting (Sextante/Pirol)-Raster files in OpenJUMP A: Victor Olaya Ferrero vol...@unex.es mailto:vol...@unex.es Cc: List for discussion of JPP development and use. jump-pilot-devel@lists.sourceforge.net mailto:jump-pilot-devel@lists.sourceforge.net, openjump-us...@googlegroups.com mailto:openjump-us...@googlegroups.com, sextante-us...@lists.forge.osor.eu mailto:sextante-us...@lists.forge.osor.eu Data: Venerdì 4 dicembre 2009, 19:26 Hei Victor, no it's only on the OpenJUMP side. So, no problem for you. Images are correctly exported to OpenJUMP (at least it looks like, when I compare for instance points and the rasterized versions. But I haven't really checked that). stefan Victor Olaya Ferrero wrote: Stefan, Is that a bug in the SEXTANTE-OJ Bindings, or a SEXTANTE bug that might affect other users?? A Geotools user recently reported a similar behaviour and a fix (that I haven't updated yet, since it is a quick fix and I still have to test it a bit more). Regards. Victor Hei all, today I discovered a problem with the tif image export for raster files if for instance Sextante raster processing results should be exported. Unfortunately the export function shifted the images by 0.5 pixels towards NW (since the current implementation did not respect that the world file coordinate is given for the center of the first pixel - and not the pixel corner) I did a bug fix an hour ago. I hope that tomorrows nightly build contains this fix. You can see if it works by exporting a loaded tif file (using the load Sextante raster image option) with Save Raster Image from the raster image layer context menu, and reload the file again (using Open.. Sextante Raster...). If there is a shift in both images, then this is a non-fixed version. I am sorry for any troubles that may have occurred (the fastest way may be to fix the world files). stefan PS: As this a severe problem, I will try to make a new OpenJUMP release the next days. ___ Sextante-users mailing list sextante-us...@lists.forge.osor.eu mailto:sextante-us...@lists.forge.osor.eu /mc/compose?to=sextante-us...@lists.forge.osor.eu mailto:sextante-us...@lists.forge.osor.eu https://lists.forge.osor.eu/listinfo/sextante-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev
Re: [JPP-Devel] Bug fixed for exporting (Sextante/Pirol)-Raster files in OpenJUMP
Hei Peppe, thanks for looking into it. so - it appears for JPG too? that means it is also a problem of the old framework? mhm.. I think I need to do an additional vector rasterization-overlay check in ArcGIS. stefan Giuseppe Aruta schrieb: Hi Stefan, I confirm your observation in AdbToolbox (Openjump derived) and Skyjump (Jump derived), I loaded a wms with ortophotos and saved them in JPG. Than I reloaded into the workbenck. In both cases there is a shift of 1/2 pixel to NW, as you mentioned. It seems that the problem is on Jump family side. Regards Peppe --- *Ven 4/12/09, Stefan Steiniger /sst...@geo.uzh.ch/* ha scritto: Da: Stefan Steiniger sst...@geo.uzh.ch Oggetto: Re: [JPP-Devel] [Sextante-users] Bug fixed for exporting (Sextante/Pirol)-Raster files in OpenJUMP A: Victor Olaya Ferrero vol...@unex.es Cc: List for discussion of JPP development and use. jump-pilot-devel@lists.sourceforge.net, openjump-us...@googlegroups.com, sextante-us...@lists.forge.osor.eu Data: Venerdì 4 dicembre 2009, 19:26 Hei Victor, no it's only on the OpenJUMP side. So, no problem for you. Images are correctly exported to OpenJUMP (at least it looks like, when I compare for instance points and the rasterized versions. But I haven't really checked that). stefan Victor Olaya Ferrero wrote: Stefan, Is that a bug in the SEXTANTE-OJ Bindings, or a SEXTANTE bug that might affect other users?? A Geotools user recently reported a similar behaviour and a fix (that I haven't updated yet, since it is a quick fix and I still have to test it a bit more). Regards. Victor Hei all, today I discovered a problem with the tif image export for raster files if for instance Sextante raster processing results should be exported. Unfortunately the export function shifted the images by 0.5 pixels towards NW (since the current implementation did not respect that the world file coordinate is given for the center of the first pixel - and not the pixel corner) I did a bug fix an hour ago. I hope that tomorrows nightly build contains this fix. You can see if it works by exporting a loaded tif file (using the load Sextante raster image option) with Save Raster Image from the raster image layer context menu, and reload the file again (using Open.. Sextante Raster...). If there is a shift in both images, then this is a non-fixed version. I am sorry for any troubles that may have occurred (the fastest way may be to fix the world files). stefan PS: As this a severe problem, I will try to make a new OpenJUMP release the next days. ___ Sextante-users mailing list sextante-us...@lists.forge.osor.eu /mc/compose?to=sextante-us...@lists.forge.osor.eu https://lists.forge.osor.eu/listinfo/sextante-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net /mc/compose?to=jump-pilot-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Bug fixed for exporting (Sextante/Pirol)-Raster files in OpenJUMP
Hei all, today I discovered a problem with the tif image export for raster files if for instance Sextante raster processing results should be exported. Unfortunately the export function shifted the images by 0.5 pixels towards NW (since the current implementation did not respect that the world file coordinate is given for the center of the first pixel - and not the pixel corner) I did a bug fix an hour ago. I hope that tomorrows nightly build contains this fix. You can see if it works by exporting a loaded tif file (using the load Sextante raster image option) with Save Raster Image from the raster image layer context menu, and reload the file again (using Open.. Sextante Raster...). If there is a shift in both images, then this is a non-fixed version. I am sorry for any troubles that may have occurred (the fastest way may be to fix the world files). stefan PS: As this a severe problem, I will try to make a new OpenJUMP release the next days. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
