> 
> On 29.09.2013 13:13, Rahkonen Jukka wrote:
>> Hi,
>> 
>> Direct edit works fine and it is to some extent very easy for users. If for 
>> example a scanned image does not suit with existing data, just select the 
>> geometry and move and resize it to suit it with existing data. If one knows 
>> that georeferencing geometries are selectable this is actually very easy and 
>> intuitive. And I do not know that other GIS programs support such a simple 
>> but powerful way for georeferencing.
> 
> good to hear..
>  
>> The bad thing is that only resize and move are supported. People using 
>> scanned images would immediately ask why images can't be rotated and next, 
>> why images cannot be warped as well.
> 
> i looked into it, also asked on the list about rotation. problem is i can't 
> realy get my head wrapped around
> A. how to interpret the rotation parameters of a world file
I believe that I have never met a world file with rotation parameters in real 
world.  By readind Wikipedia article http://en.wikipedia.org/wiki/World_file 
the rotations in ESRI world file are not rotations but rather the x- and 
y-components of vectors which present the edges of a pixel. And if someone 
needs to create a world file for a rotated there will be a need to know the 
rotation angle and then use cos and sin with correct signs. This is based on 
page http://forums.esri.com/Thread.asp?c=93&f=982&t=63552&mc=1#163268 
"Therefore the rules must be actually
pixel resolution * cos(rotation angle)
pixel resolution * sin(rotation angle)
pixel resolution * sin(rotation angle)
-pixel resolution * cos(rotation angle)"

But the main question is that do we have code in OpenJUMP for rotating raster 
images in-a-fly even if we could resolve how many degrees we should rotate them?

> B. how to easily use the geometries corners to interpet and use for a 
> rotation. currently simply the geometry's envelope is used which is identical 
> to the geometry for level oriented polygons.

We should take two corners of the rotated envelope and calculate the rotation 
angle. It looks like the bounding feature must a box/envelope and not anything 
non-rectangular.
 
> wrt. warping, if you mean free from stretching
No, I meant tool which can also stretch if needed.
> A. can we even do that to geometries in OJ
We have a warping tool for vectors in OpenJUMP and after some reading I would 
not try to implement image warping tool in OJ. Perhaps OJ could be used for 
measuring ground control points from image and feed them for some external tool 
like gdalwarp http://www.gdal.org/gdalwarp.html.

> B. i guess most pictures are scanned maps or the like, so they will most 
> likely properly "warped" already, just need to be positioned within the world 
> coordinate system
> so i'd leave that for now entirely.
Scanned pages from books are more or less rotated but sometimes also skewed. 
However, rectifying such an image needs good set of ground control points and 
good algorithms. QGIS has a nice georeferencer for that. Warping with OJ feels 
so hard that we may want to forget it now, and I do not know if even simple 
rotation could be done easily.
 
>> Supporting rotated images would mean about the same as supporting the 
>> rotation parameters of ESRI world file. I am not sure about warping 
>> on-the-fly, we may have something to that direction in this new feauture 
>> that was added to OJ .1.6.0
>> * adding support for GeoTIFF with transformation matrix georeferencing 
>> courtesy of Nicolas Ribot
> 
> yeah, committed his code
> http://sourceforge.net/p/jump-pilot/code/HEAD/tree/core/trunk/src/com/vividsolutions/jump/workbench/imagery/geotiff/GeoTIFFRaster.java#l100
> but he basically only interprets the tie points and nothing else.
OK. 

>> 
>> Transformation matrix sounds as something that could be created by using the 
>> four corner points of bounding polygon of the image as ground corner poinst.

> thankful for any points.. please see above
You should not judge a book by the cover. Probably I was all wrong with this.
> 
>> 
>> When it comes to direct editing of WKT, polygon as WKT is not friendly for 
>> editing text directly. Enhanced WKT handling so that "BBOX" or "Envelope" 
>> could be used for inputting a box-like geometry would be nice for this use 
>> cas. I have been writing about this earlier because WMS requests contain 
>> BBOXes and possibility to create polygons by writing the BBOX into WKT box 
>> would be practical. As a programming task it is perhaps not ultimately 
>> difficult (If BBOX found, construct a POLYGON and continue).
> 
> you lost me here.. could explain more detailed and give a step by step use 
> case? maybe restricted for the topic at hand, image positioning?

Boundign box of an image is for example POLYGON ((
        -70042 6578602, 
        -70042 7903802, 
        851158 7903802, 
        851158 6578602, 
        -70042 6578602
    ))

User may know the exact extents or user may want to shift the image with some 
exact value. If the WKT polygon is to be used fot that the user must write the 
same coordinates into many places and all correctly.  The same thing as BBOX is 
bbox( -70042 ,6578602,851158,7903802) which would be more easy to edit and 
there is no possibility to make it into a skewed polygon.

>> 
>> I suggest to keep the direct edit of georeferencing geometries even it is 
>> not totally production ready. Is is still a clever way for georeferencing 
>> and it can be made better later. 
> 
> exactly my point, it's so easy and intuitive, in it's limited way. btw. 
> scaling works for the new Referenced Image reader _only_ currently
> 
>>Some documentation would be needed to make clear that only resize and move 
>>are usable at the moment. 
> 
> i would really like to ask you to hack a wiki page, after the dust has 
> settled and i can declare the image layer changes to be release ready.

Perhaps I will do that.

>>I do not believe we can add constraints so that only those two toold could be 
>>used for editing the image layer geometries but that would be a better 
>>immediate solution.
> 
> nope, as it is based on the general geometry editing, which does not support 
> limiting beyond prohibiting editing at all.
> on the other hand it is quite obvious that it doesn't work, isn't it. so user 
> can always undo their latest rotation, or unsupported edit.

Yes, visual feed back is fast and obvious.

> also, there are loose plans to add a "reset position" button to the 
> LayerManager so users can "undo" their customized postion. be aware, that 
> this repostioning will be saved when saving the layer dataset (as jml/shp/..) 
> and restored when opening it.

-Jukka-
 
> thanks ..ede
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> 
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Reply via email to