Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] Problem with recognizing geotiff tags - I think 
Hey all,

Okay, I finally see the issue but the language being thrown around is
less pedantically accurate than we need to be to sort our way through
CRS and projection issues. Overall, uDig is doing the right thing with
the image but failing to establish any CRS or projection info so the
units are not set.

Please do file a bug with your example GeoTiff if you can (link at end).
I can use the bug to try to rope Jody and Jesse into a bug fix session.

We need to fix the issue at several levels:
        (1) figure out why we didn't parse your geotiff's metadata
        correctly
        (2) set the CRS/projection information correctly when we fail to
        parse a data set's metadata
        (3) split the CRS and projection setting in uDig
We have a vague plan to fix the last of these but perhaps you will push
us to fix all three.


On Thu, 2007-11-22 at 10:31 -0800, Hugh Jennings wrote:
> When I load this image into a uDig map the CRS indicated is WGS84 with
> no projection.
This is uDig's bad way of saying "I don't know what's going on so i'm
setting a default CRS in the viewer and not re-projecting the data."

> The coordinates reported in the map window are EN and not Lat Long.
Since your image is in UTM, your coordinates *should* be in E/N. The
unit is meters and the numbers are right.

> 
> Is uDig attempting to reproject the image on the fly?
No, in this case it's failing to recognize the info and simply dumping
the image (which is 'projected' according to the listgeo metadata) onto
the screen. There is no active 'projection' going on.
> 
> Do our geotiff's need some further tag to be recognized properly?
I don't know if the geotiff is valid but since listgeo recognizes it
perhaps uDig parsing needs to be fixed.



> Jody Garnett wrote:
> > My understanding is that the image is showing up with data in the 
> > range of 752107, 2590533 (from the screen snap); 
Yes, that's right for UTM. UTM is in meters, but often offset a whole
lot so we don't get negative numbers. From an earlier message:
Corner Coordinates:
    Upper Left    ( 623250.000,2702250.000)
    Lower Left    ( 623250.000,2511800.000)
    Upper Right   ( 847450.000,2702250.000)
    Lower Right   ( 847450.000,2511800.000)
    Center        ( 735350.000,2607025.000)
so to that extent, I don't see any issue. 

> but poor uDig still 
> > thinks the map is in WGS 84 (so the output is invalid). 
What's invalid? 

Actually, I'd guess that uDig knows that it has no idea what the map is.
I bet the renderer is simply defaulting the 'WGS84' state which
currently means "don't project" so we dump the data straight to the
screen; the data itself, within uDig, probably doesn't have any valid
CRS. 

> Indeed it 
> > looks resampling is not happening; the image is just being dumped onto 
> > the screen (which is fine when the map is changed to the right 
> > projection...).

It's not that the map is changed to the right projection, it's that you
are (finally) defining the CRS and projection info for the data within
uDig. The map should look exactly the same (i.e. the rectangular image
will stay rectangular).


> On Thu, 2007-11-22 at 13:37 -0800, Hugh Jennings wrote: 
> Jody is correct here.  I expected to see coordinates in lat long or a 
> coord system of wgs84 UTM zone 39n. 

You should not get coordinates in long/lat if you are in UTM. UTM is in
meters. 

> when I load it in.
> 
> In addition I have noticed that the distance tool gives understandable 
> results once I have set the projection to UTM. Before this any attempt 
> to measure a distance come back with no result.

Right, uDig didn't parse the header right.
> 
> With version 1.2_trunk I get an error message on the map window "Unable 
> to calculate the distance".
> 
> Should this tool normally give a "distance" in decimal degrees or is it 
> intended for no measurements to be given when displaying an unprojected 
> dataset? 

Don't know, we'd have to look at the distance tool code. By the look of
it, the tool is pulling info from the data itself which is why it's
failing. 
> 
> Finally, if you would like I will put together a smaller version of this 
> image with the same geotiff tags for you to test against.

Please, and attach it to a bug in our JIRA.
  http://jira.codehaus.org/browse/UDIG

--adrian

Back to the top