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
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
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
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
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
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
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
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
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
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
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
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
12 matches
Mail list logo
