I completely agree with keeping the discussion on list–I was in a rush this morning and forgot to hit reply all. My out-of-context replies are below, followed by the discussion that occurred off-list.
Using an ‘r’ before a string in python just denotes that it is a raw string, so special characters such as backslashes will be ignored. This is just a habit because until recently I had to use Windows at work.
I followed your other posting about your NITF woes…that sounds rough. I’m happy my data came as geotiffs!
My reasoning behind making it more generic is so that it could eventually become a WV2 variant of the i.landsat.toar/i.aster.toar modules. Once the generic tool is done it could still be scripted to process a large number of individual scenes.
Could you send me a copy of your metadata file? It looks like our imagery differs in the amount of processing applied, but I haven’t been able to find any references for the WV-2 processing levels so far. It’s definitely more difficult to find the necessary information for privately operated satellites. It would be great to see the other potential metadata forms for the generic toar tool.
Thanks again,
Eric
On Thu, Jul 18, 2013 at 6:56 AM, Nikos Alexandris <nik@nikosalexandris.net> wrote:
It seems it’s complicated. In the XML file for the image I am working with,
13APR10075059-M1BS-500060446050_05_P003.XML
there is no “EARLIESTACQTIME” string (referring to line 119 in your script).
I will have to postpone it a bit with testing. It’s a common secret all
these constanctly changing metadata strings… A bit frustrating some times.
Best, Nikos
Hi!
On Thursday 18 of July 2013 06:04:40 Eric Goddard wrote:
On line 211 in the main() function you have to specify the path to the
WorldView-2 source directory that contains all of the imagery, IMD
files, XML files, etc.
In the “version” I downloaded from gist, there is probably a typo/leftover:
imageryPath = r"/path/to/imagery/folder"
If I am wrnog, I can’t see how “r” could be useful now – I am just about to try.
In my GRASS setup I used r.external to link all
of the files in that path. If the original TIF file in the imagery
path was 12OCT19171330-M3DS_R1C1-052823926030_01_P001.TIF, for
example, the raster name in grass would be
x2OCT19171330-M3DS_R1C1-052823926030_01_P001.; the
metadata file that is associated with that tif is
12OCT19171330-M3DS-052823926030_01_P001.XML.
I guess I will need to adjust various stuff. I have only .ntf files. Of course, I converted 'em in GeoTiffs but I’d like to see how it plays with NITF containers and SUBDATASETs.
The AssociateMetaDataWithRaster() function takes the list of grass
rasters (acquired in line 213), and creates a dictionary that has the
grass raster name as the key and the XML file as the value.
Ok.
The loop starting at line 219 goes over each raster, calls the
ExtractVariablesFromMetadata() function (in which the first argument
is the path to the xml file for the raster, and the second is the band
number) and uses the lxml library to search for and extract the
variables from the XML metadata document.
Sound nice.
Thanks for going over it, Nikos. A coworker and I spent hours combing
through it and we couldn’t find any mistakes in the math (not to say
there aren’t any of course!); I’m all out of ideas for what could be
going wrong.
Myself, I am just a DIY scripter. If I bomb into anything obvious, of course I’ll point it out.
I’m currently working on a more generic version in which
you specify the image and the path to the xml file to make it easier
to test.
Yes, it’ll be much better. I too have a lot of hardcoded stuff in my scripts. But, it doens’t make too much sense in the end/long run.
Sorry for the strange python spacing too…Vim configuration
gone wrong :).
Hey, thanks a lot.
N
ps- just my humble opinion, better to keep discussion on-list.
