Robin's Blog
A remote-sensing PhD student talking about interesting things…
Show MenuHide Menu

Category Archives: IDL

Beware: Latitude/Longitude co-ordinates in ENVI may not be in WGS-84

May 10, 2013

Summary: When you use the Pixel Locator or Cursor Location/Value tool in ENVI, the latitude and longitude co-ordinates given are based on the datum that the image is in, not necessarily WGS-84.

This may be obvious to some people, but it wasn’t to me – and I thought that if I got confused then some other people probably would too – hence this article. I often use the Pixel Locator dialog box in ENVI to find a specific location in the image by entering the X and Y pixel location (referred to in ENVI as Samples and Lines) or the map co-ordinates of whatever co-ordinate system the image is projected into (for example, the Ordnance Survey National Grid):

ENVI_PixelLocator_OSGB

Alternatively, you can click the button with the arrows on it, and enter a location in latitude and longitude:

ENVI_PixelLocator_LatLon

Very handily, all of these values are updated as you move around the image manually – so this dialog can also be used as an equivalent of the Pixel Location/Value window – as shown below.

ENVI_CursorLocValue

This all sounds fine – but the problem is that the latitude/longitude values that are shown are calculated using the datum that is defined for the image. You can see this in the image below, where the latitude and longitude value is displayed, and the datum is listed above it:

ENVI_PixelLocator_LatLon_Annotated

This seems like a sensible thing to do, but it makes comparison with latitude and longitude co-ordinates from other sources very difficult – as nearly all other latitude and longitude co-ordinates are provided in the WGS-84 datum. Locations from GPS systems are always in WGS-84, and locations on web maps, in GIS systems and most other sources of latitude and longitude co-ordinate systems are very frequently in WGS-84.

So, this raises two questions:

What effect does this have?

Well, I haven’t yet done a full investigation of this (sometime I will sit down and write some code to do some proper testing), but when I found the problem it was causing offsets of around 100-200m – which can be quite significant in many applications.

What can we do about this?

There is a way to tell ENVI to use WGS-84 as the datum for calculating its latitude and longitude values, but it is a bit fiddly. Basically, when you’re in the Pixel Locator dialog before you switch to the latitude/longitude display, click the Change Proj… button and then select click the Datum button to select a new datum. Then switch to the latitude/longitude display, and you’ll find that the datum is listed as WGS-84, and the values will be correct in the WGS-84 datum:

ENVI_PixelLocator_WGS84

Unfortunately, this means that the map co-ordinate values (for example, the Ordnance Survey Grid References) will now be wrong, and you’ll need to switch back to the original datum to get those to be correct. Also, I can’t find a way to get the Cursor Location/Value dialog to display WGS-84 latitudes and longitudes.

I actually found this while designing a lecture and practical session for MSc students at the University of Southampton on using the ENVI API in IDL. While writing a code example for the students on finding the pixel value at a specific lat/lon co-ordinate, I found that my results came up between ten and twenty pixels away from the place I thought they would (I was using 10m SPOT imagery), and I got different results from my IDL code and ENVI – even though my IDL code was using the ENVI API! Luckily I managed to find out what the problem was – and could therefore explain it to my students, and hopefully stop them running in to the same problem as me. It may be that I’m being silly here, and everyone naturally realises what ENVI does, and thinks it is the right thing to do – but it definitely confused me, so maybe it will helped you.

How to: Solve the ‘Ctrl-Space (auto-complete) not working’ problem in Eclipse

November 15, 2011

This problem is known by various names such as:

  • Ctrl-Space doesn’t do anything in Eclipse!
  • Why can’t I get auto-complete to work properly in Eclipse?
  • I’ve just set up a new University computer and things don’t work like they do on my laptop (maybe that one’s just me…)

It’s actually very simple to solve, but the problem is actually nothing to do with Eclipse. First of all, let’s see what the problem is:

You’ve just installed Eclipse, are starting to do some programming in it, and want to use the very handy auto-complete feature. So, you type part of a function name and press Ctrl-Space, waiting for the magic to work and the rest of the name to be automatically typed….but it doesn’t happen!

In the image above (which unfortunately doesn’t include the cursor) I had typed ST, and pressed Ctrl-Space to autocomplete it but nothing happened.

When trying to fix this myself, I went in to the Eclipse options (Windows->Preferences, then General->Keys) and tried to find the command for auto-complete. Helpfully, it’s not called autocomplete or anything like that – it’s called Content Assist. This showed me that, as I expected, Content Assist was assigned to Ctrl-Space:

So why wasn’t Eclipse picking this up? I tried setting the key for Content Assist manually, but when I deleted the text in the key binding box and pressed Ctrl-Space, it showed that only Ctrl registered – somehow the spacebar press was being ‘eaten up’ by something else. What could it be?

The simple answer is: the Windows language services utility – obvious really! This seems to be set by default (at least some of the time) to switch between languages by using Ctrl-Space. On my personal computer I only have one language set up (English (UK)), but on the university computers there are loads – French, German, Italian, Chinese (simplified) etc. You can find out what languages you have set up by going to Control Panel -> Region and Language -> Keyboards and Languages (tab) and then Change Keyboards (again, how obvious…). You’ll see a list of languages installed – remove any that you don’t want (click the language and then click the Remove button) until you only have the ones you want left. That fixed it for me, but you can also check the Advanced Key Settings tab to make sure that none of the keyboard shortcuts that are set include Ctrl-Space.

Once you’ve done that, Ctrl-Space should work nicely

Please use sensible colours in your maps

November 2, 2011

If you are creating maps then for goodness sake

Use sensible colours! 

I was helping some undergraduates with some work the other day, and they decided to use the following colour scheme for representing river depth:

  • Deep water: Red
  • Medium-depth water: Bright green
  • Shallow water: Pink
Why did they do this? Well, either they were the default values used by the software they were using (unlikely), or they just chose randomly. Not a good idea.
If you look you’ll find a huge amount of literature about this (I should put some references here but I can’t really be bothered at this time at night), and it really makes your maps a HUGE amount more useable if you’re using sensible colours. For example:
  • Deep water: Dark blue
  • Medium-depth water: Medium-blue
  • Shallow water: Light blue
Why is this sensible? Well it makes sense on a number of levels – water is normally shown as blue (so it’s obviously some kind of water), and the different levels of colour imply some sort of ordering. With the original colours above there is no inherent ordering – is green ‘higher’ or ‘lower’ than red? Of course, red and green being used for ‘incorrect’ and ‘correct’ on a different map would be very sensible…

Isn’t it hard work to come up with nice colour schemes for all of your maps? Nope not at all – ColorBrewer has done it already! If you haven’t used this website already I urge you to do so, it provides a number of carefully-chosen colour-schemes designed for various different purposes. For representing river depth you’d probably want to use one of the blue Sequential schemes, but there are also Diverging schemes for data that goes off in two directions, as well as schemes for representing Qualitative data (those that have no explicit ordering). What’s more you can tell it to only show schemes that are color-blind-friendly, photocopier-safe etc, and it’ll produce a preview for you with various map styles (labels, cities, coastlines etc). All in all it’s very impressive, and very useful.

Plugins and extensions are available for a number of pieces of software to allow ColorBrewer colours to be easily used. These include an ArcGIS plugin (see the bottom answer for how to install with ArcGIS 10), R package, Python module and IDL routines.

Get more detailed messages for maths errors in IDL

August 26, 2011

I’ve just discovered something that I feel I must share here – partly to make more people aware of it, and partly so I don’t forget it. In the IDL programming language you will sometimes find your program interrupted by a line saying something like:

% Program caused arithmetic error: Floating divide by 0

Sometimes it will be obvious where the error is – but often you can spend ages looking for it (just like with segfaults in C…). What I only just found out is that if you run the command

!EXCEPT=2

At the IDL prompt before running your program you will get a far more informative error message like

% Program caused arithmetic error: Floating divide by 0
% Detected at JUNK 3 junk.pro

The key thing is that this tells you what line the error occurred on (line 3 of junk.pro in the above example) – which helps you to narrow down the problem far more quickly.

More details on the values that !EXCEPT can take is available here – basically the options are no messages, unhelpful messages and helpful messages.

This is very useful – but just beware that running with !EXCEPT=2 all the time will slow down your code, so only do it if you need to for debugging purposes.