Re: [JPP-Devel] Question about loading an image on OJ workbench via Layer.class
Don't know if this is any useful info, but the original JUMP was able to read JPG and PNG... but I don't remeber that it did read TIFF (ok, just seeing that in JUMP 1.2 TIFF support was added). If you look at the code, it should be also possible to see that Jon Aquino wrote the classes. (or worst case, one can still check out the original JUMP here: http://www.vividsolutions.com/jump/ ) http://www.vividsolutions.com/jump/javadoc/com/vividsolutions/jump/workbench/imagery/package-summary.html I am also not sure if it makes sense to keep working on that. Because it did not head the flexibility and generics of Sextante. However, perhaps you can find a gem. One nice thing I still remember was the first projection plugin, Jon Aquino wrote. On 03/17/2015 06:19 AM, edgar.sol...@web.de wrote: a. no, ReferencedImagesLayer is the older non-sextante image framework simply showing and positioning images. no more no less. yes, everything in org.openjump.core.rasterimage is sextante compatible raster code. b. depends on what you want to do. generally there is a wish to unify OJ raster support into one API only (Jukka), so we might decide to retire ReferencedImagesLayer and it's descendants. before we do that i want to take a closer look at Alberto's changes and check if we can convince it to load more formats. what exactly ddo you wanna do and why _don't_ you wanna use the RasterImageLayer for it? ..ede On 17.03.2015 08:10, Giuseppe Aruta wrote: Hi Ede a) so com.vividsolutions.jump.workbench.imagery.ReferencedImagesLayer is also a Pirol derived class? I used to know that all the framework into org.openjump.core.rasterimage was Pirol. I exclude RasterImageLayer: I know how to save/load raster file using thiss class (I added a support RasterImageIOUtils class on OJ to expole all those I/O methods). I image that the answer to my question is the class ReferencedImagesLayer. b) Exploring ReferencedImagesLayer as you mentioned, I found ReferencedImageFactoryFileLayerLoader and GeoImageFactoryFileLayerLoader. First class has createLayer(layerManager, uri) method. Should I use that to load a TIF file? thanks Peppe 2015-03-16 20:38 GMT+01:00 edgar.sol...@web.de: you mean like the other other image framework beside pirol/sextante com.vividsolutions.jump.workbench.imagery.ReferencedImagesLayer ? ..ede On 16.03.2015 20:34, Giuseppe Aruta wrote: Hi all, I want to build a plugin that programatically load an image file into OJ workbench through Layer.class (not RasterImageLayer.class). For instance a layer that I already know the path (ex. D:/temp/test.tif, or jpg, or png). I am working around a simple OJ affine warp transformation plugin for images. Do we have some defined methods (like as in RasterImageIO.class or GridFloat.class for Sextante layers)? Or is there an OJ class that could be used as a sample? Thanks for replay. Peppe -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Dive into the World of Parallel Programming The Go Parallel
Re: [JPP-Devel] Question about loading an image on OJ workbench via Layer.class
Hi Ede a) so com.vividsolutions.jump.workbench.imagery.ReferencedImagesLayer is also a Pirol derived class? I used to know that all the framework into org.openjump.core.rasterimage was Pirol. I exclude RasterImageLayer: I know how to save/load raster file using thiss class (I added a support RasterImageIOUtils class on OJ to expole all those I/O methods). I image that the answer to my question is the class ReferencedImagesLayer. b) Exploring ReferencedImagesLayer as you mentioned, I found ReferencedImageFactoryFileLayerLoader and GeoImageFactoryFileLayerLoader. First class has createLayer(layerManager, uri) method. Should I use that to load a TIF file? thanks Peppe 2015-03-16 20:38 GMT+01:00 edgar.sol...@web.de: you mean like the other other image framework beside pirol/sextante com.vividsolutions.jump.workbench.imagery.ReferencedImagesLayer ? ..ede On 16.03.2015 20:34, Giuseppe Aruta wrote: Hi all, I want to build a plugin that programatically load an image file into OJ workbench through Layer.class (not RasterImageLayer.class). For instance a layer that I already know the path (ex. D:/temp/test.tif, or jpg, or png). I am working around a simple OJ affine warp transformation plugin for images. Do we have some defined methods (like as in RasterImageIO.class or GridFloat.class for Sextante layers)? Or is there an OJ class that could be used as a sample? Thanks for replay. Peppe -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Manage new attribute types BOOLEAN and LONG in jml and shp drivers
Hi Jukka, Yes caching the field size of a shapefile is a five years old patch from Larry Becker. I think it is quite useful as it makes possible to preserve the schema of shapefiles created outside OpenJUMP. Michaël Le 17/03/2015 14:08, Rahkonen Jukka (MML) a écrit : Hi, Please stop this investigation line, there is a bug but in another place. I was testing by saving new results every time to same existing shapefile. When I made the first save I had value “1234567890” in “integer_attribute”. Therefore it received format Number(10.0). The bug is that if I edit the field in OpenJUMP to contain value “12345678” and save the result with the same shapefile name, the field is still Number(10.0). If I save it with a new name the field will be correctly Number(9.0). Conclusion: OpenJUMP must be keeping some field definitions cached and reused, or just updating the data of dbf file but not headers of something else as funny. -Jukka- *Lähettäjä:*Rahkonen Jukka (MML) [mailto:jukka.rahko...@maanmittauslaitos.fi] *Lähetetty:* 17. maaliskuuta 2015 14:57 *Vastaanottaja:* jump-pilot-devel@lists.sourceforge.net *Aihe:* Re: [JPP-Devel] Manage new attribute types BOOLEAN and LONG in jml and shp drivers Hi, Find attached. Data contains: property name=integer_attribute1234567/property but OpenOffice shows that the dbf field is defined as integer_at,N,10,0 However, I made a quick test with one point and only one attribute and it worked as you describe. Could it be that existence of some other fields may lead to wrong result from your field length test? -Jukka- *Lähettäjä:*Michaël Michaud m.michael.mich...@orange.fr mailto:m.michael.mich...@orange.fr *Lähetetty:* 17. maaliskuuta 2015 14:36 *Vastaanottaja:* jump-pilot-devel@lists.sourceforge.net mailto:jump-pilot-devel@lists.sourceforge.net *Aihe:* Re: [JPP-Devel] Manage new attribute types BOOLEAN and LONG in jml and shp drivers Jukka, In last revision, OJ checks the dataset first If there is no value larger than 999 999 999 or lesser than -99 999 999, it should use N(9,0) but if the integer attribute contains values needing more than 9 digits, it will choose the field width accordingly (10 or 11). The same should happen for longs (18 by default and 19 or 20 or 21 if needed). I made a small test to confirm that a integer attribute containing a simgle value '123456789' is saved as N(9,0) and read back as an Integer. If you have a counter example, please, send it to me in jml format. Michaël Le 17/03/2015 11:34, Rahkonen Jukka (MML) a écrit : Hi, This must be some programming language magic, but even I can see in your code for r4341 and I on testing with corresponding snapshot: else if (maxlength = 9) fields[f] = new DbfFieldDef(columnName, 'N', 9, 0); OJ is still creating Integer field as (10.0). As a result a roundtrip with OpenJUMP is now changing data type write into shp - open back with OJ - what used to be integer is now Long. In the same way, Long is saved as (19.0) even the plan was to make it (18.0). I have verified this with OpenOffice Calc which is nice because I can also edit the format by hand, and with GDAL: This is how GDAL sees the fields now: string_att: String (6.0) char_attri: String (14.0) varchar_at: String (17.0) longvarcha: String (21.0) text_attri: String (14.0) boolean_at: String (1.0) bit_attrib: String (1.0) smallint_a: Integer (6.0) tinyint_at: Integer (6.0) integer_at: Integer64 (10.0) long_attri: Real (19.0) bigint_att: Real (19.0) decimal_at: Real (33.16) numeric_at: Real (33.16) bigdecimal: Real (33.16) float_attr: Real (33.16) double_att: Real (33.16) real_attri: Real (33.16) date_attri: Date (10.0) time_attri: Date (10.0) timestamp_: Date (10.0) object_att: String (1.0) -Jukka- MichaëlMichaud wrote: Jukka, OK, I tried to implement it more or less as described in your previous mail, One other drawback with this change is that all previous shapefiles containing integers and saved as N(11,0) will now be read back as longs. Let me now if someone think this can be a problem, Michaël Le 16/03/2015 10:39, Rahkonen Jukka (MML) a écrit : Hi Michaël, My test file can now be successfully saved and read to/from shape and JML. I made also a test with GDAL-dev versions with the created shapefile ogrinfo -so -al datatype_test.shp INFO: Open of `datatype_test.shp' using driver `ESRI Shapefile' successful. Layer name: datatype_test Geometry: Point Feature Count: 1 Extent: (310.00, 406.00) - (310.00, 406.00) Layer SRS WKT: (unknown) string_att: String (6.0) char_attri: String (14.0)
Re: [JPP-Devel] Question about loading an image on OJ workbench via Layer.class
a. no, ReferencedImagesLayer is the older non-sextante image framework simply showing and positioning images. no more no less. yes, everything in org.openjump.core.rasterimage is sextante compatible raster code. b. depends on what you want to do. generally there is a wish to unify OJ raster support into one API only (Jukka), so we might decide to retire ReferencedImagesLayer and it's descendants. before we do that i want to take a closer look at Alberto's changes and check if we can convince it to load more formats. what exactly ddo you wanna do and why _don't_ you wanna use the RasterImageLayer for it? ..ede On 17.03.2015 08:10, Giuseppe Aruta wrote: Hi Ede a) so com.vividsolutions.jump.workbench.imagery.ReferencedImagesLayer is also a Pirol derived class? I used to know that all the framework into org.openjump.core.rasterimage was Pirol. I exclude RasterImageLayer: I know how to save/load raster file using thiss class (I added a support RasterImageIOUtils class on OJ to expole all those I/O methods). I image that the answer to my question is the class ReferencedImagesLayer. b) Exploring ReferencedImagesLayer as you mentioned, I found ReferencedImageFactoryFileLayerLoader and GeoImageFactoryFileLayerLoader. First class has createLayer(layerManager, uri) method. Should I use that to load a TIF file? thanks Peppe 2015-03-16 20:38 GMT+01:00 edgar.sol...@web.de: you mean like the other other image framework beside pirol/sextante com.vividsolutions.jump.workbench.imagery.ReferencedImagesLayer ? ..ede On 16.03.2015 20:34, Giuseppe Aruta wrote: Hi all, I want to build a plugin that programatically load an image file into OJ workbench through Layer.class (not RasterImageLayer.class). For instance a layer that I already know the path (ex. D:/temp/test.tif, or jpg, or png). I am working around a simple OJ affine warp transformation plugin for images. Do we have some defined methods (like as in RasterImageIO.class or GridFloat.class for Sextante layers)? Or is there an OJ class that could be used as a sample? Thanks for replay. Peppe -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Manage new attribute types BOOLEAN and LONG in jml and shp drivers
Hi, This must be some programming language magic, but even I can see in your code for r4341 and I on testing with corresponding snapshot: else if (maxlength = 9) fields[f] = new DbfFieldDef(columnName, 'N', 9, 0); OJ is still creating Integer field as (10.0). As a result a roundtrip with OpenJUMP is now changing data type write into shp - open back with OJ - what used to be integer is now Long. In the same way, Long is saved as (19.0) even the plan was to make it (18.0). I have verified this with OpenOffice Calc which is nice because I can also edit the format by hand, and with GDAL: This is how GDAL sees the fields now: string_att: String (6.0) char_attri: String (14.0) varchar_at: String (17.0) longvarcha: String (21.0) text_attri: String (14.0) boolean_at: String (1.0) bit_attrib: String (1.0) smallint_a: Integer (6.0) tinyint_at: Integer (6.0) integer_at: Integer64 (10.0) long_attri: Real (19.0) bigint_att: Real (19.0) decimal_at: Real (33.16) numeric_at: Real (33.16) bigdecimal: Real (33.16) float_attr: Real (33.16) double_att: Real (33.16) real_attri: Real (33.16) date_attri: Date (10.0) time_attri: Date (10.0) timestamp_: Date (10.0) object_att: String (1.0) -Jukka- Michaël Michaud wrote: Jukka, OK, I tried to implement it more or less as described in your previous mail, One other drawback with this change is that all previous shapefiles containing integers and saved as N(11,0) will now be read back as longs. Let me now if someone think this can be a problem, Michaël Le 16/03/2015 10:39, Rahkonen Jukka (MML) a écrit : Hi Michaël, My test file can now be successfully saved and read to/from shape and JML. I made also a test with GDAL-dev versions with the created shapefile ogrinfo -so -al datatype_test.shp INFO: Open of `datatype_test.shp' using driver `ESRI Shapefile' successful. Layer name: datatype_test Geometry: Point Feature Count: 1 Extent: (310.00, 406.00) - (310.00, 406.00) Layer SRS WKT: (unknown) string_att: String (6.0) char_attri: String (14.0) varchar_at: String (17.0) longvarcha: String (21.0) text_attri: String (14.0) boolean_at: String (1.0) bit_attrib: String (1.0) smallint_a: Integer64 (11.0) tinyint_at: Integer64 (11.0) integer_at: Integer64 (11.0) long_attri: Real (21.0) bigint_att: Real (21.0) decimal_at: Real (33.16) numeric_at: Real (33.16) bigdecimal: Real (33.16) float_attr: Real (33.16) double_att: Real (33.16) real_attri: Real (33.16) date_attri: Date (10.0) time_attri: Date (10.0) timestamp_: Date (10.0) object_att: String (1.0) Notice that all the short integers are interpreted as long integers (Integer64) and the long ones as Reals. Perhaps you should consider to make the numbers a little bit shorter? According to this ticket http://trac.osgeo.org/gdal/ticket/3615 ever a number with 10 digits (10.0) can be too big as an Integer. I suppose that the biggest Integer is 4,294,967,29. And numbers with 20 digits can be bigger than Long integers if they are 18,446,744,073,709,551,615. GDAL shp driver http://www.gdal.org/drv_shapefile.html is behaving this way when it creates numeric fields : · Integer fields without an explicit width are treated as width 9, and extended to 10 or 11 if needed. · Integer64 fields without an explicit width are treated as width 18, and extended to 19 or 20 if needed. I made some tests about what GDAL does in reading. It appears to reports numbers only up to (9.0) as Integers and up to (18.0) as Long Integers. I wonder if it would be better to change the shapefile writer of OpenJUMP to create Integer fields by default as (9.0) and change format into (10.0) only if integer field contains values between 1,000,000,00 and 4,294,967,29. Bigger values than the upper limit should not be accepted into integer field because they are invalid everywhere. There seems to be another issue with Long integers in the shapefiles. Long integers can need up to 20 digits but the standard dBase format has an 18 digit limit for numbers http://www.clicketyclick.dk/databases/xbase/format/data_types.html.http://www.clicketyclick.dk/databases/xbase/format/data_types.html Some version has extended that to 20 numbers. Because of best possible interoperability I think that OpenJUMP should create the Long fields as (18.0) by default and (19.0) or (20.0) only if needed. -Jukka Rahkonen- Michaël Michaud wrote: Hi Jukka, Thank you for the test and sorry for the exceptions. I just completed with BIGINT, TIME and NUMERIC. Shapefile driver will not really handle all these types. I've just handled long and boolean in a specific way. Other types are just mapped to old types. This is how new types are supposed to be converted to dbf then back to OpenJUMP : CHAR, VARCHAR, LONGVARCHAR, TEXT, STRING, OBJECT - C- STRING FLOAT, DOUBLE, REAL, NUMERIC, DECIMAL, BIGDECIMAL - N(33,16) - DOUBLE TINYINT, SMALLINT, INTEGER - N(11)
Re: [JPP-Devel] Question about loading an image on OJ workbench via Layer.class
Thanks for the answer Stefan. I will go on working using Sextante, and try to find a solution for the open issue (transparency, ect) 2015-03-17 16:26 GMT+01:00 Stefan Steiniger sst...@geo.uzh.ch: Don't know if this is any useful info, but the original JUMP was able to read JPG and PNG... but I don't remeber that it did read TIFF (ok, just seeing that in JUMP 1.2 TIFF support was added). If you look at the code, it should be also possible to see that Jon Aquino wrote the classes. (or worst case, one can still check out the original JUMP here: http://www.vividsolutions.com/jump/ ) http://www.vividsolutions.com/jump/javadoc/com/vividsolutions/jump/workbench/imagery/package-summary.html I am also not sure if it makes sense to keep working on that. Because it did not head the flexibility and generics of Sextante. However, perhaps you can find a gem. One nice thing I still remember was the first projection plugin, Jon Aquino wrote. On 03/17/2015 06:19 AM, edgar.sol...@web.de wrote: a. no, ReferencedImagesLayer is the older non-sextante image framework simply showing and positioning images. no more no less. yes, everything in org.openjump.core.rasterimage is sextante compatible raster code. b. depends on what you want to do. generally there is a wish to unify OJ raster support into one API only (Jukka), so we might decide to retire ReferencedImagesLayer and it's descendants. before we do that i want to take a closer look at Alberto's changes and check if we can convince it to load more formats. what exactly ddo you wanna do and why _don't_ you wanna use the RasterImageLayer for it? ..ede On 17.03.2015 08:10, Giuseppe Aruta wrote: Hi Ede a) so com.vividsolutions.jump.workbench.imagery.ReferencedImagesLayer is also a Pirol derived class? I used to know that all the framework into org.openjump.core.rasterimage was Pirol. I exclude RasterImageLayer: I know how to save/load raster file using thiss class (I added a support RasterImageIOUtils class on OJ to expole all those I/O methods). I image that the answer to my question is the class ReferencedImagesLayer. b) Exploring ReferencedImagesLayer as you mentioned, I found ReferencedImageFactoryFileLayerLoader and GeoImageFactoryFileLayerLoader. First class has createLayer(layerManager, uri) method. Should I use that to load a TIF file? thanks Peppe 2015-03-16 20:38 GMT+01:00 edgar.sol...@web.de: you mean like the other other image framework beside pirol/sextante com.vividsolutions.jump.workbench.imagery.ReferencedImagesLayer ? ..ede On 16.03.2015 20:34, Giuseppe Aruta wrote: Hi all, I want to build a plugin that programatically load an image file into OJ workbench through Layer.class (not RasterImageLayer.class). For instance a layer that I already know the path (ex. D:/temp/test.tif, or jpg, or png). I am working around a simple OJ affine warp transformation plugin for images. Do we have some defined methods (like as in RasterImageIO.class or GridFloat.class for Sextante layers)? Or is there an OJ class that could be used as a sample? Thanks for replay. Peppe -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
Re: [JPP-Devel] Question about loading an image on OJ workbench via Layer.class
On 17.03.2015 12:31, Giuseppe Aruta wrote: I wanted to check a couple of alternatives: 1) (going back to poit f) Reload the result layer as ReferencedImagesLayer because you hope that the ReferencedImage API is faster? 2) move all the process from RasterImageLayer to ReferencedImagesLayer. In this case I could modify the original Jump AffineTransformationPlugin in order to work ether with vector layers or with ReferencedImagesLayer. sounds reasonable. as you might know, ReferencedImagesLayer is just a plain Layer with geometries and an attribute with an image path. because of it's special style it renders the image into mapview. an idea i didn't follow up to realize was to realtime scale and rotate the images via their respective bbox geometry. currently you can edit the geometry but the image renderer will ignore the changes.. nope.. just tested it agn, it will respect scaling but not rotation of the geometry. the code is in the paint() method of the respective ReferencedImage implementations (GeoImage, GeoTIFFImage, AbstractGraphicImage). have fun ;) the idea was to add rotation and then to export the georeferencing as world file or even tagged tiff later. ..ede -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Question about loading an image on OJ workbench via Layer.class
I already used RasterImageLayer.class. I attached to this mail a plugin sample for a simple raster affine transformation. *Please test it with the latest OJ snapshot* as this plugin depends on some enhancements I did a couple of days ago on OJ saving raster. The plugin is located on RasterWarp menu It allows to do a simple affine transformation (move, resize, rotate and partially stretch) on an image. It needs 3 warping vectors and uses a class already embedded into OJ (import com.vividsolutions.jump.warp.AffineTransform) plus JAI warping classes. It is a minimal plugin, far away from a true Image georeferencer. But enough stable and useful to do a simple georeferencing of an image. How it works: a) load an image using Sextante Raster loader b) draw one, two or three warping vectors (from Menu Warp) depending the type of deformation you want c) select the raster on the layer tree d) click on RasterWarpAffine transformation e) a new raster file is saved on OS/TEMP folder f) image file is reloaded as RasterImageLayer (Sextante) on the workbench. The original raster layer is hidden. This plugin works fine, except for a bug that was introduced with the new Alberto's changes: the alpha channel now is displayed as black and it is not possible to set that color to transparent (check on OJ bugs, I already opened a couple of them). If the image is rotated or streched, that black colar is visible on the workbench and it is not possible to hide it. I wanted to check a couple of alternatives: 1) (going back to poit f) Reload the result layer as ReferencedImagesLayer 2) move all the process from RasterImageLayer to ReferencedImagesLayer. In this case I could modify the original Jump AffineTransformationPlugin in order to work ether with vector layers or with ReferencedImagesLayer. Regarding the wish to unify OJ raster support into one API = RasterImageLayer. I totally agree. It make things more simple (at least for me) but I feel we need to improve some aspects: a) loading an image via ReferencedImagesLayer is more faster that via RasterImageLayer - in many case I observed that the difference is at least of an order of magnitude. b) if I load several image via RasterImageLayer and I just zoom form one to another, it takes time to display the s next. c) And of coarse the bug-tickets. I hope my explanation was enough detailed. Peppe 2015-03-17 10:19 GMT+01:00 edgar.sol...@web.de: a. no, ReferencedImagesLayer is the older non-sextante image framework simply showing and positioning images. no more no less. yes, everything in org.openjump.core.rasterimage is sextante compatible raster code. b. depends on what you want to do. generally there is a wish to unify OJ raster support into one API only (Jukka), so we might decide to retire ReferencedImagesLayer and it's descendants. before we do that i want to take a closer look at Alberto's changes and check if we can convince it to load more formats. what exactly ddo you wanna do and why _don't_ you wanna use the RasterImageLayer for it? ..ede On 17.03.2015 08:10, Giuseppe Aruta wrote: Hi Ede a) so com.vividsolutions.jump.workbench.imagery.ReferencedImagesLayer is also a Pirol derived class? I used to know that all the framework into org.openjump.core.rasterimage was Pirol. I exclude RasterImageLayer: I know how to save/load raster file using thiss class (I added a support RasterImageIOUtils class on OJ to expole all those I/O methods). I image that the answer to my question is the class ReferencedImagesLayer. b) Exploring ReferencedImagesLayer as you mentioned, I found ReferencedImageFactoryFileLayerLoader and GeoImageFactoryFileLayerLoader. First class has createLayer(layerManager, uri) method. Should I use that to load a TIF file? thanks Peppe 2015-03-16 20:38 GMT+01:00 edgar.sol...@web.de: you mean like the other other image framework beside pirol/sextante com.vividsolutions.jump.workbench.imagery.ReferencedImagesLayer ? ..ede On 16.03.2015 20:34, Giuseppe Aruta wrote: Hi all, I want to build a plugin that programatically load an image file into OJ workbench through Layer.class (not RasterImageLayer.class). For instance a layer that I already know the path (ex. D:/temp/test.tif, or jpg, or png). I am working around a simple OJ affine warp transformation plugin for images. Do we have some defined methods (like as in RasterImageIO.class or GridFloat.class for Sextante layers)? Or is there an OJ class that could be used as a sample? Thanks for replay. Peppe -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and
Re: [JPP-Devel] Manage new attribute types BOOLEAN and LONG in jml and shp drivers
Jukka, In last revision, OJ checks the dataset first If there is no value larger than 999 999 999 or lesser than -99 999 999, it should use N(9,0) but if the integer attribute contains values needing more than 9 digits, it will choose the field width accordingly (10 or 11). The same should happen for longs (18 by default and 19 or 20 or 21 if needed). I made a small test to confirm that a integer attribute containing a simgle value '123456789' is saved as N(9,0) and read back as an Integer. If you have a counter example, please, send it to me in jml format. Michaël Le 17/03/2015 11:34, Rahkonen Jukka (MML) a écrit : Hi, This must be some programming language magic, but even I can see in your code for r4341 and I on testing with corresponding snapshot: else if (maxlength = 9) fields[f] = new DbfFieldDef(columnName, 'N', 9, 0); OJ is still creating Integer field as (10.0). As a result a roundtrip with OpenJUMP is now changing data type write into shp - open back with OJ - what used to be integer is now Long. In the same way, Long is saved as (19.0) even the plan was to make it (18.0). I have verified this with OpenOffice Calc which is nice because I can also edit the format by hand, and with GDAL: This is how GDAL sees the fields now: string_att: String (6.0) char_attri: String (14.0) varchar_at: String (17.0) longvarcha: String (21.0) text_attri: String (14.0) boolean_at: String (1.0) bit_attrib: String (1.0) smallint_a: Integer (6.0) tinyint_at: Integer (6.0) integer_at: Integer64 (10.0) long_attri: Real (19.0) bigint_att: Real (19.0) decimal_at: Real (33.16) numeric_at: Real (33.16) bigdecimal: Real (33.16) float_attr: Real (33.16) double_att: Real (33.16) real_attri: Real (33.16) date_attri: Date (10.0) time_attri: Date (10.0) timestamp_: Date (10.0) object_att: String (1.0) -Jukka- **Michaël Michaud wrote: Jukka, OK, I tried to implement it more or less as described in your previous mail, One other drawback with this change is that all previous shapefiles containing integers and saved as N(11,0) will now be read back as longs. Let me now if someone think this can be a problem, Michaël Le 16/03/2015 10:39, Rahkonen Jukka (MML) a écrit : Hi Michaël, My test file can now be successfully saved and read to/from shape and JML. I made also a test with GDAL-dev versions with the created shapefile ogrinfo -so -al datatype_test.shp INFO: Open of `datatype_test.shp' using driver `ESRI Shapefile' successful. Layer name: datatype_test Geometry: Point Feature Count: 1 Extent: (310.00, 406.00) - (310.00, 406.00) Layer SRS WKT: (unknown) string_att: String (6.0) char_attri: String (14.0) varchar_at: String (17.0) longvarcha: String (21.0) text_attri: String (14.0) boolean_at: String (1.0) bit_attrib: String (1.0) smallint_a: Integer64 (11.0) tinyint_at: Integer64 (11.0) integer_at: Integer64 (11.0) long_attri: Real (21.0) bigint_att: Real (21.0) decimal_at: Real (33.16) numeric_at: Real (33.16) bigdecimal: Real (33.16) float_attr: Real (33.16) double_att: Real (33.16) real_attri: Real (33.16) date_attri: Date (10.0) time_attri: Date (10.0) timestamp_: Date (10.0) object_att: String (1.0) Notice that all the short integers are interpreted as long integers (Integer64) and the long ones as Reals. Perhaps you should consider to make the numbers a little bit shorter? According to this ticket http://trac.osgeo.org/gdal/ticket/3615ever a number with 10 digits (10.0) can be too big as an Integer. I suppose that the biggest Integer is 4,294,967,29. And numbers with 20 digits can be bigger than Long integers if they are 18,446,744,073,709,551,615. GDAL shp driver http://www.gdal.org/drv_shapefile.html is behaving this way when it creates numeric fields : ·Integer fields without an explicit width are treated as width 9, and extended to 10 or 11 if needed. ·Integer64 fields without an explicit width are treated as width 18, and extended to 19 or 20 if needed. I made some tests about what GDAL does in reading. It appears to reports numbers only up to (9.0) as Integers and up to (18.0) as Long Integers. I wonder if it would be better to change the shapefile writer of OpenJUMP to create Integer fields by default as (9.0) and change format into (10.0) only if integer field contains values between 1,000,000,00 and 4,294,967,29. Bigger values than the upper limit should not be accepted into integer field because they are invalid everywhere. There seems to be another issue with Long integers in the shapefiles. Long integers can need up to 20 digits but the standard dBase format has an 18 digit limit for numbers
Re: [JPP-Devel] Manage new attribute types BOOLEAN and LONG in jml and shp drivers
Hi, Find attached. Data contains: property name=integer_attribute1234567/property but OpenOffice shows that the dbf field is defined as integer_at,N,10,0 However, I made a quick test with one point and only one attribute and it worked as you describe. Could it be that existence of some other fields may lead to wrong result from your field length test? -Jukka- Lähettäjä: Michaël Michaud m.michael.mich...@orange.fr Lähetetty: 17. maaliskuuta 2015 14:36 Vastaanottaja: jump-pilot-devel@lists.sourceforge.net Aihe: Re: [JPP-Devel] Manage new attribute types BOOLEAN and LONG in jml and shp drivers Jukka, In last revision, OJ checks the dataset first If there is no value larger than 999 999 999 or lesser than -99 999 999, it should use N(9,0) but if the integer attribute contains values needing more than 9 digits, it will choose the field width accordingly (10 or 11). The same should happen for longs (18 by default and 19 or 20 or 21 if needed). I made a small test to confirm that a integer attribute containing a simgle value '123456789' is saved as N(9,0) and read back as an Integer. If you have a counter example, please, send it to me in jml format. Michaël Le 17/03/2015 11:34, Rahkonen Jukka (MML) a écrit : Hi, This must be some programming language magic, but even I can see in your code for r4341 and I on testing with corresponding snapshot: else if (maxlength = 9) fields[f] = new DbfFieldDef(columnName, 'N', 9, 0); OJ is still creating Integer field as (10.0). As a result a roundtrip with OpenJUMP is now changing data type write into shp - open back with OJ - what used to be integer is now Long. In the same way, Long is saved as (19.0) even the plan was to make it (18.0). I have verified this with OpenOffice Calc which is nice because I can also edit the format by hand, and with GDAL: This is how GDAL sees the fields now: string_att: String (6.0) char_attri: String (14.0) varchar_at: String (17.0) longvarcha: String (21.0) text_attri: String (14.0) boolean_at: String (1.0) bit_attrib: String (1.0) smallint_a: Integer (6.0) tinyint_at: Integer (6.0) integer_at: Integer64 (10.0) long_attri: Real (19.0) bigint_att: Real (19.0) decimal_at: Real (33.16) numeric_at: Real (33.16) bigdecimal: Real (33.16) float_attr: Real (33.16) double_att: Real (33.16) real_attri: Real (33.16) date_attri: Date (10.0) time_attri: Date (10.0) timestamp_: Date (10.0) object_att: String (1.0) -Jukka- Michaël Michaud wrote: Jukka, OK, I tried to implement it more or less as described in your previous mail, One other drawback with this change is that all previous shapefiles containing integers and saved as N(11,0) will now be read back as longs. Let me now if someone think this can be a problem, Michaël Le 16/03/2015 10:39, Rahkonen Jukka (MML) a écrit : Hi Michaël, My test file can now be successfully saved and read to/from shape and JML. I made also a test with GDAL-dev versions with the created shapefile ogrinfo -so -al datatype_test.shp INFO: Open of `datatype_test.shp' using driver `ESRI Shapefile' successful. Layer name: datatype_test Geometry: Point Feature Count: 1 Extent: (310.00, 406.00) - (310.00, 406.00) Layer SRS WKT: (unknown) string_att: String (6.0) char_attri: String (14.0) varchar_at: String (17.0) longvarcha: String (21.0) text_attri: String (14.0) boolean_at: String (1.0) bit_attrib: String (1.0) smallint_a: Integer64 (11.0) tinyint_at: Integer64 (11.0) integer_at: Integer64 (11.0) long_attri: Real (21.0) bigint_att: Real (21.0) decimal_at: Real (33.16) numeric_at: Real (33.16) bigdecimal: Real (33.16) float_attr: Real (33.16) double_att: Real (33.16) real_attri: Real (33.16) date_attri: Date (10.0) time_attri: Date (10.0) timestamp_: Date (10.0) object_att: String (1.0) Notice that all the short integers are interpreted as long integers (Integer64) and the long ones as Reals. Perhaps you should consider to make the numbers a little bit shorter? According to this ticket http://trac.osgeo.org/gdal/ticket/3615 ever a number with 10 digits (10.0) can be too big as an Integer. I suppose that the biggest Integer is 4,294,967,29. And numbers with 20 digits can be bigger than Long integers if they are 18,446,744,073,709,551,615. GDAL shp driver http://www.gdal.org/drv_shapefile.html is behaving this way when it creates numeric fields : · Integer fields without an explicit width are treated as width 9, and extended to 10 or 11 if needed. · Integer64 fields without an explicit width are treated as width 18, and extended to 19 or 20 if needed. I made some tests about what GDAL does in reading. It appears to reports numbers only up to (9.0) as Integers and up to (18.0) as Long Integers. I wonder if it would be better to change the shapefile writer of OpenJUMP to create Integer fields by default as (9.0) and change format into (10.0) only if integer field contains values between
Re: [JPP-Devel] Manage new attribute types BOOLEAN and LONG in jml and shp drivers
Hi, Please stop this investigation line, there is a bug but in another place. I was testing by saving new results every time to same existing shapefile. When I made the first save I had value 1234567890 in integer_attribute. Therefore it received format Number(10.0). The bug is that if I edit the field in OpenJUMP to contain value 12345678 and save the result with the same shapefile name, the field is still Number(10.0). If I save it with a new name the field will be correctly Number(9.0). Conclusion: OpenJUMP must be keeping some field definitions cached and reused, or just updating the data of dbf file but not headers of something else as funny. -Jukka- Lähettäjä: Rahkonen Jukka (MML) [mailto:jukka.rahko...@maanmittauslaitos.fi] Lähetetty: 17. maaliskuuta 2015 14:57 Vastaanottaja: jump-pilot-devel@lists.sourceforge.net Aihe: Re: [JPP-Devel] Manage new attribute types BOOLEAN and LONG in jml and shp drivers Hi, Find attached. Data contains: property name=integer_attribute1234567/property but OpenOffice shows that the dbf field is defined as integer_at,N,10,0 However, I made a quick test with one point and only one attribute and it worked as you describe. Could it be that existence of some other fields may lead to wrong result from your field length test? -Jukka- Lähettäjä: Michaël Michaud m.michael.mich...@orange.frmailto:m.michael.mich...@orange.fr Lähetetty: 17. maaliskuuta 2015 14:36 Vastaanottaja: jump-pilot-devel@lists.sourceforge.netmailto:jump-pilot-devel@lists.sourceforge.net Aihe: Re: [JPP-Devel] Manage new attribute types BOOLEAN and LONG in jml and shp drivers Jukka, In last revision, OJ checks the dataset first If there is no value larger than 999 999 999 or lesser than -99 999 999, it should use N(9,0) but if the integer attribute contains values needing more than 9 digits, it will choose the field width accordingly (10 or 11). The same should happen for longs (18 by default and 19 or 20 or 21 if needed). I made a small test to confirm that a integer attribute containing a simgle value '123456789' is saved as N(9,0) and read back as an Integer. If you have a counter example, please, send it to me in jml format. Michaël Le 17/03/2015 11:34, Rahkonen Jukka (MML) a écrit : Hi, This must be some programming language magic, but even I can see in your code for r4341 and I on testing with corresponding snapshot: else if (maxlength = 9) fields[f] = new DbfFieldDef(columnName, 'N', 9, 0); OJ is still creating Integer field as (10.0). As a result a roundtrip with OpenJUMP is now changing data type write into shp - open back with OJ - what used to be integer is now Long. In the same way, Long is saved as (19.0) even the plan was to make it (18.0). I have verified this with OpenOffice Calc which is nice because I can also edit the format by hand, and with GDAL: This is how GDAL sees the fields now: string_att: String (6.0) char_attri: String (14.0) varchar_at: String (17.0) longvarcha: String (21.0) text_attri: String (14.0) boolean_at: String (1.0) bit_attrib: String (1.0) smallint_a: Integer (6.0) tinyint_at: Integer (6.0) integer_at: Integer64 (10.0) long_attri: Real (19.0) bigint_att: Real (19.0) decimal_at: Real (33.16) numeric_at: Real (33.16) bigdecimal: Real (33.16) float_attr: Real (33.16) double_att: Real (33.16) real_attri: Real (33.16) date_attri: Date (10.0) time_attri: Date (10.0) timestamp_: Date (10.0) object_att: String (1.0) -Jukka- Michaël Michaud wrote: Jukka, OK, I tried to implement it more or less as described in your previous mail, One other drawback with this change is that all previous shapefiles containing integers and saved as N(11,0) will now be read back as longs. Let me now if someone think this can be a problem, Michaël Le 16/03/2015 10:39, Rahkonen Jukka (MML) a écrit : Hi Michaël, My test file can now be successfully saved and read to/from shape and JML. I made also a test with GDAL-dev versions with the created shapefile ogrinfo -so -al datatype_test.shp INFO: Open of `datatype_test.shp' using driver `ESRI Shapefile' successful. Layer name: datatype_test Geometry: Point Feature Count: 1 Extent: (310.00, 406.00) - (310.00, 406.00) Layer SRS WKT: (unknown) string_att: String (6.0) char_attri: String (14.0) varchar_at: String (17.0) longvarcha: String (21.0) text_attri: String (14.0) boolean_at: String (1.0) bit_attrib: String (1.0) smallint_a: Integer64 (11.0) tinyint_at: Integer64 (11.0) integer_at: Integer64 (11.0) long_attri: Real (21.0) bigint_att: Real (21.0) decimal_at: Real (33.16) numeric_at: Real (33.16) bigdecimal: Real (33.16) float_attr: Real (33.16) double_att: Real (33.16) real_attri: Real (33.16) date_attri: Date (10.0) time_attri: Date (10.0) timestamp_: Date (10.0) object_att: String (1.0) Notice that all the short integers are interpreted as long integers (Integer64) and the long ones as Reals. Perhaps you should
Re: [JPP-Devel] Manage new attribute types BOOLEAN and LONG in jml and shp drivers
Hi Ede, The problem is the opposite. Changing schema is conscious choice but when user saves data to an existing shapefile the changed schema may not be saved because old field definitions Number(X.Y) and maybe also Character(X) are cached. DBF has only Number and Double for numbers http://www.clicketyclick.dk/databases/xbase/format/data_types.html and all the OJ data types must be mapped into Number(X.Y) format. What happens if user changes existing Number(10.0) that old OJ versions read as Integer but new one as Long into Integer, Tiny, or Small? Will the number format change or not? Should it change? -Jukka Rahkonen- Lähettäjä: edgar.sol...@web.de edgar.sol...@web.de Lähetetty: 18. maaliskuuta 2015 0:40 Vastaanottaja: OpenJump develop and use Aihe: Re: [JPP-Devel] Manage new attribute types BOOLEAN and LONG in jml and shp drivers well, changing schema is a conscious choice. but anyway, how about warning on save that the column definitions have changed? but why the worries? i understand that this does not deviate from the standard or did i get wrong? ..ede On 17.03.2015 23:29, Rahkonen Jukka (MML) wrote: Hi, Preserving field sizes of existing shapefiles makes sense (well, in case of Save as... I am not sure, perhaps even then) and probably did not leave to any trouble when we had only string, integer, and double types. But now if user wants to edit schema and change long-integer-small-tiny etc. and save the edited shapefile the result may be a shapefile with different field sizes than what user may believe. Users are rather helpless because they can never see the field sizes of shapefiles which are opened or which will be created. I do not really know what would be the best behaviour but I think that before we make the next stable release we should find some logical or at least documented solution. -Jukka- Michaël Michaud wrote: Hi Jukka, Yes caching the field size of a shapefile is a five years old patch from Larry Becker. I think it is quite useful as it makes possible to preserve the schema of shapefiles created outside OpenJUMP. Michaël Le 17/03/2015 14:08, Rahkonen Jukka (MML) a écrit : Hi, Please stop this investigation line, there is a bug but in another place. I was testing by saving new results every time to same existing shapefile. When I made the first save I had value “1234567890” in “integer_attribute”. Therefore it received format Number(10.0). The bug is that if I edit the field in OpenJUMP to contain value “12345678” and save the result with the same shapefile name, the field is still Number(10.0). If I save it with a new name the field will be correctly Number(9.0). Conclusion: OpenJUMP must be keeping some field definitions cached and reused, or just updating the data of dbf file but not headers of something else as funny. -Jukka- Lähettäjä: Rahkonen Jukka (MML) [mailto:jukka.rahko...@maanmittauslaitos.fi] Lähetetty: 17. maaliskuuta 2015 14:57 Vastaanottaja: jump-pilot-devel@lists.sourceforge.netmailto:jump-pilot-devel@lists.sourceforge.net Aihe: Re: [JPP-Devel] Manage new attribute types BOOLEAN and LONG in jml and shp drivers Hi, Find attached. Data contains: property name=integer_attribute1234567/property but OpenOffice shows that the dbf field is defined as integer_at,N,10,0 However, I made a quick test with one point and only one attribute and it worked as you describe. Could it be that existence of some other fields may lead to wrong result from your field length test? -Jukka- Lähettäjä: Michaël Michaud m.michael.mich...@orange.frmailto:m.michael.mich...@orange.fr Lähetetty: 17. maaliskuuta 2015 14:36 Vastaanottaja: jump-pilot-devel@lists.sourceforge.netmailto:jump-pilot-devel@lists.sourceforge.net Aihe: Re: [JPP-Devel] Manage new attribute types BOOLEAN and LONG in jml and shp drivers Jukka, In last revision, OJ checks the dataset first If there is no value larger than 999 999 999 or lesser than -99 999 999, it should use N(9,0) but if the integer attribute contains values needing more than 9 digits, it will choose the field width accordingly (10 or 11). The same should happen for longs (18 by default and 19 or 20 or 21 if needed). I made a small test to confirm that a integer attribute containing a simgle value '123456789' is saved as N(9,0) and read back as an Integer. If you have a counter example, please, send it to me in jml format. Michaël Le 17/03/2015 11:34, Rahkonen Jukka (MML) a écrit : Hi, This must be some programming language magic, but even I can see in your code for r4341 and I on testing with corresponding snapshot: else if (maxlength = 9) fields[f] = new DbfFieldDef(columnName, 'N', 9, 0); OJ is still creating Integer field as (10.0). As a result a roundtrip with OpenJUMP is now
