HICO level 1b data - latitudes/longitudes not quite correct

[amsayer]

Hi all,

I have another quick question with HICO. I am trying to map a scene (same one as in my last topic, H2011140064744.L1B_ISS), and it's mostly going great, except there appears to be a slight shift in the longitudes (and possibly a smaller in latitudes) from where they should be. This is using the datasets navigation/latitudes and navigation/longitudes.

I have, hopefully, attached an image to the end of this thread, zooming in on part of this scene. So this is at the North end of the Adriatic sea, and you can see the tip of Croatia in the south-east corner and tip of Slovenia in the north-east. There is clearly a shift between where the coastline appears in the image, and where the coastline is drawn, of about 0.02 degrees longitude (i.e. roughly 2 km). The latitude seems less skewed (the lower chunk of the coast lines up ok, but the bit more to the northeast of the image does not quite). I've checked using different reference ellipsoids for the map (did not make a visible differences), and different shoreline databases (this image uses the IDL in-built one but I have also tried the higher-resolution GSHHS database, which ends up lying pretty much on top of the IDL database).

Google Earth says that the lat/lon for the points I have scrawled 'A' and 'B' on (tips of the land) should be 45.49 N, 13.49 E and 45.53 N, 13.56 E respectively. So, confoundingly, these longitudes are about halfway in between where IDL has drawn the coastlines and where the data suggests the coastlines are. This leads me to suspect that (for this scene, at least) the longitudes in the file are off by something around 0.01-0.02 degrees. Note that at the other end of the scene, I see a shift of similar magnitude, and the coasts are very low-lying so there should be no appreciable shift in apparent position due to parallax. Note also that I am pretty confident that the error is not in the mapping software (i.e. it draws the points where it says it does, to within the size of a data pixel).

Do you have any suggestions for what could be going on here? Am I doing something wrong? Or is the HICO geolocation not expected to be accurate to that level?

Thanks,

Andy

[img]ftp://windhoek.nascom.nasa.gov/pub/asayer/foroc_forum.png[/img]

[OB WebDev - norman]

Andy,

When we first started working with these data, the coordinates
were often off by tens of kilometers.  Since then the HICO experts
have improved the geolocation considerably, but it is still not
good to within a pixel.

My understanding is that it is very difficult to get accurate attitude
information for the HICO sensor which is mounted on the large
and somewhat flexible International Space Station whose star
trackers and other attitude determination devices are not
necessarily close to the HICO sensor mount point.

I will have to defer to the HICO team for more specific information
about the current state of HICO geolocation.

Norman

[amsayer]

Hi Norman,

Thanks for your response. Yes, I can imagine that geolocation from the ISS has different challenges than the polar orbiters I am more used to! I hope my comments are not taken as criticism - that is not my intention, and I am continually amazed by how well all this technology and processing systems work given their complexity. It's rather that, as my first time looking at this dataset, I don't yet have a good handle on its intricacies and to what extent discrepancies like this are expected, and what are the result of me doing something wrong. :)

Andy

[OB WebDev - norman]

We of the Ocean Biology Processing Group are
also relatively new to the HICO data stream.
Since we are a small group, we appreciate
when anyone from the science community
calls out issues that we may not have noticed
with HICO (or any of our supported remote
sensing platforms).  Please, continue to let
us know whenever you find something amiss.
The more eyes on a measurement, the better
it is likely to become.

Norman

[tufillaro]

I tried running l2gen with HICO data from the Beam (SeaDAS 7.3) GUI on MacOS El Capitan and ran into errors.
I then tried the same thing with MacOS Yosemite with success.
Any one else have a similar experience? I can look more into it
if there is interest, and would be interest if anyone knows a work around.

[tufillaro]

I wanted to know if there was an update on the HICO l2gen processing
in SeaDAS? The last statement says there was progress toward atm.
corr. with all wavelengths, but that looks like it was a year or
two ago. It looks like, as of SeaDAS 7.3, it is still just picking off
the MERIS bands.

Also, on the various option sections for the processing, is there a
way to determine which options work for which sensors (when using the SeaDAS l2gen GUI)? For instance,
with HICO data, it looks like all the MERIS options are there, but a number
fail to process, and I assume it is just because they are not implemented or
don't make sense for the HICO data.
I guessing this might be true for all the sensors, that is there are option fields that
can be populated in the GUI, but which will cause errors if populated.

[OB.DAACx - SeanBailey]

We do not have access to an "El Capitan" system, so are unable to test the binaries on it.
Once we get access, we'll see what's up (or is it down...).

Sean

[OB.DAACx - SeanBailey]

Not for general release, yet. 
The l2gen code has been modifed to process hyperspectral data (using HICO as the guinea pig),
but we've not put the required tables out yet as they are not yet finalized (and they're massive, so we only want to do it once...)

As for can the GUI tell you which options work for which sensor...no.
While l2gen knows, and will tell you with a very nice fail-to-process result, it's a runtime situation that the GUI just has no hope of getting a handle on.

Sean