On 29.09.2013 19:09, Rahkonen Jukka wrote: >> >> 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)"
A. what center is it rotated around? B. how would i calculate the angle from the WF values? sorry, my trigonometry went to by cigarettes long time ago. > > 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? java jai has http://download.java.net/media/jai/javadoc/1.1.3/jai-apidocs/javax/media/jai/operator/RotateDescriptor.html and we probably would need http://download.java.net/media/jai/javadoc/1.1.3/jai-apidocs/javax/media/jai/operator/WarpDescriptor.html to warp the image according to it's geometry pendant. >> 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. it doesn't have to, just implemented it that way, as it was easiest to do. how would one calculate the rotation angle from an rotated geometry? >> wrt. warping, if you mean free from stretching > No, I meant tool which can also stretch if needed. you can already scale freely, did you notice? >> 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. as mentioned above, there is image warping avail in java already. the interpolation algorithms are not very good though. > >> 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. true, although i would at least try to do it, with your help, and if only for the fun of it. > >>> 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. or not.. as i understand it for now http://docs.oracle.com/javase/1.4.2/docs/api/java/awt/geom/AffineTransform.html can be fed the wkt values nearly directly and would scale & rotate in one go. >> >>> >>> 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 see, bounding box are two points (via 4 ordinates) defining a rectangle, which could easily be used to modify the image geometry. hmm, maybe worth a ImageLyrMgr button? like the reset one? > >>> >>> 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. > thx.. 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
