Re: [pytroll] pyorbital - 2d swath view?

[Raspaud Martin]

Hi Mikhail,

The plot you see on the presentation has been generated with pyorbital indeed. This is however work in progress, and I still can't get it to output the exact same values a aapp, which is my reference atm.
But if you want to take a look, grab the geoloc branch.
I'll come back to you on how to use this within a couple of hours, when I'll actually be in my office.

Best regards,
Martin

Skickat från min HTC

----- Reply message -----
Från: "Mikhail Itkin" <itk...@gmail.com>
Till: "pyt...@googlegroups.com" <pyt...@googlegroups.com>
Rubrik: [pytroll] pyorbital - 2d swath view?
Datum: mån, mar 18, 2013 07:09

Hello everybody,  a new pytroll user here.
It's nice to find a whole suite for working with weather satellites data, and even written in python!

I started off by using resampling functionality (pyresample) and now I consider using pyorbital. I looked through the code on git, but it still remains a question to me, can it generate 2d arrays with simulated swath observations or does it produce only subsatellite tracks (1d vectors)?
I see in the presentation from the workshop 2012 there is a slide with a 2d field showing cross-track sensor pixel centers, how was that figure actually made? Basically what i need to do is to simulate a 2d swath view from existing TLE files. Is pyorbital a right tool for that?

Thanks,
Mikhail

--
You received this message because you are subscribed to the Google Groups "pytroll" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pytroll+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Martin Raspaud]

On 18/03/13 06:32, Mikhail Itkin wrote:
> Hello everybody, a new pytroll user here.
> It's nice to find a whole suite for working with weather satellites data,
> and even written in python!
>
> I started off by using resampling functionality (pyresample) and now I
> consider using pyorbital. I looked through the code on git, but it still
> remains a question to me, can it generate 2d arrays with simulated swath
> observations or does it produce only subsatellite tracks (1d vectors)?
> I see in the presentation from the workshop 2012 there is a slide with a 2d
> field showing cross-track sensor pixel centers, how was that figure
> actually made? Basically what i need to do is to simulate a 2d swath view
> from existing TLE files. Is pyorbital a right tool for that?

Hi again Mikhail,

First of all, thanks for the kind words :) and welcome to the pytroll wagon!

I just pushed a file called "geoloc_example.py" to the "geoloc" branch
on pyorbital's github. It is a (hopefully) simple example of how to
compute a swath's pixel-centers (2d), using avhrr as an example. They
are even plotted in the end of the script for convenience.

Feel free to try it out and send feedback if there is something unclear.

As mentioned earlier, I can't get the values to match AAPP's exactly,
but the error is with 2km, so it should be fine to use anyway.

Best regards,
Martin

[Rutger]

Hey,

I'm running PyOrbital now for a few months to automatically create overpass maps every day, where i only predict the edge as opposed to Martins example where every pixel is predicted. Its been working flawless so far (if you TLE is good), so i would say PyOrbital is certainly the right tool, especially if you prefer a Python solution.

It might be a nice idea to include the sensor geometries (maybe an 'edge' and 'all pixels' version) for common sensors into PyOrbital, making it a bit easier for people to get things started (which took me quite a while ;)). I could provide NPP and MODIS which i have running here.


Regards,
Rutger

On Monday, March 18, 2013 6:32:52 AM UTC+1, Mikhail Itkin wrote:

Hello everybody,  a new pytroll user here.
It's nice to find a whole suite for working with weather satellites data, and even written in python!

I started off by using resampling functionality (pyresample) and now I consider using pyorbital. I looked through the code on git, but it still remains a question to me, can it generate 2d arrays with simulated swath observations or does it produce only subsatellite tracks (1d vectors)?
I see in the presentation from the workshop 2012 there is a slide with a 2d field showing cross-track sensor pixel centers, how was that figure actually made? Basically what i need to do is to simulate a 2d swath view from existing TLE files. Is pyorbital a right tool for that?

Thanks,
Mikhail

[Martin Raspaud]

On 19/03/13 10:10, Rutger wrote:
> Hey,
>
> I'm running PyOrbital now for a few months to automatically create overpass
> maps every day, where i only predict the edge as opposed to Martins example
> where every pixel is predicted. Its been working flawless so far (if you
> TLE is good), so i would say PyOrbital is certainly the right tool,
> especially if you prefer a Python solution.
>
> It might be a nice idea to include the sensor geometries (maybe an 'edge'
> and 'all pixels' version) for common sensors into PyOrbital, making it a
> bit easier for people to get things started (which took me quite a while
> ;)). I could provide NPP and MODIS which i have running here.

Hi Rutger,

Good idea to add a sensor "catalogue" :) I just pushed a
geoloc_instrument_definitions.py to the geoloc branch in pyorbital with
some avhrr examples.

It would be great if you could contribute your VIIRS and MODIS examples
! Feel free also to correct/complement the doc string describing
instrument definitions.

Best regards,
Martin

[Rutger]

Hey Martin,

Excellent start. I'll give mine a last review and hopefully make a PR before the end of the week. In the future i wouldnt mind adding some different sensor types as well, since AVHRR/VIIRS and MODIS are all whisk-broom sensors. Some push-broom (like Landsat 8 or SPOT) or "digital frame camera's" would add some diversity to the examples.

Regards,
Rutger

[Mikhail Itkin]

Thank you Martin!

The example makes it certainly very easy to start with pyorbital, all I need to get it running. I am working now with AMSU/MHS, but it seems easy to change the scan geometry from AVHRR to AMSU.

Regards,
Mikhail

[Raspaud Martin]

Hi Mikhail,

Yes, adding amsu shouldn't be too complicated. When you do, it would be nice if you contributed the instrument definition :)

Best regards,
Martin

Skickat från min HTC

----- Reply message -----
Från: "Mikhail Itkin" <itk...@gmail.com>
Till: "pyt...@googlegroups.com" <pyt...@googlegroups.com>
Kopia: "Raspaud Martin" <martin....@smhi.se>
Rubrik: [pytroll] pyorbital - 2d swath view?

[Adam Dybbroe]

Rutger,

Indeed, it would be nice to have other sensor types describe in pyorbital, like the ones you indicate. That would opens up for another user community! You shall be very welcome! :-)
For the time being it would be great if you add VIIRS and MODIS as well. I have only been following Martin's great work on the side line and trying to give some encouragements. I looked into the examples yesterday and agree that it is very useful. If, as it seems, we are having a navigation accuracy meeting that of AAPP (for AVHRR) it opens up the door for a purely python based AVHRR level-1 processor. That is a nice bonus! :-)

-Adam

--
You received this message because you are subscribed to the Google Groups "pytroll" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pytroll+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

-- 
Adam Dybbroe,
Satellite Remote Sensing Scientist,
Numerical models and Remote Sensing,
Core Services, Swedish Meteorological and Hydrological Institute (SMHI)
www.pytroll.org
nwcsaf.smhi.se
www.smhi.se

[Mikhail Itkin]

Hi Rutger,

I looked at your earlier posts and make_maps code, your approach is neat. The problem i'll be working on is somewhat similar, I need to pick the area which intersects with NOAA overpasses, shapes and patches seems like the right way to do it.

Mikhail

[Rutger]

Hey Mikhail,

Good to hear, if you have any questions about it, just post it here. Note that the code i posted a while ago was very preliminary and contained some mistakes in it, use it with care. The VIIRS scan-geometry had some minor mistakes and also the 'isday' function to filter out nighttime geometries was completely wrong (it didn't take the longitude properly into account so only worked at GMT 0 :)).

I found that the calculation of the granule footprint (PyOrbital+Matplotlib patch generation) was very slow (CPU intensive i guess), so i you have more than 1 area of interest it pays off to store the final geometry/patch for re-use, i simply 'pickled' a dict. If your not interested in visual output, there probably are many (potentially better/faster) alternatives for Matplotlib to check the intersection.

One point which is still stort of on my to-do list is check for the 'best' orbit. At higher latitudes there are often several orbits covering the area of interest, it would be nice to pick the orbit with for example lowest overall sensor zenith angle or something.


Regards,
Rutger

[Mikhail Itkin]

Ok, here is what I came up with for AMSU-A (based entirely on Martins code, full example script attached):

def amsua(scans_nb):

   

    scan_len  = 30 # 30 samples per scan

    scan_rate = 8 # single scan, seconds

    scan_angle = -48.3 # swath, degrees

    sampling_interval = 0.2 # single view, seconds

    sync_time = 0.00355 # delay before the scan starts, seconds

    # build the instrument

    samples = np.vstack(((scan_points - (scan_len*0.5-0.5)) / (scan_len*0.5) * np.deg2rad(scan_angle),

                       np.zeros((len(scan_points),)))).transpose()

    samples = np.tile(samples, [scans_nb, 1])

    # building the corresponding times array

    offset = np.arange(scans_nb) * scan_rate

    times = (np.tile(scan_points * sampling_interval + sync_time , [scans_nb, 1])

             + np.expand_dims(offset, 1))

    return ScanGeometry(samples, times.ravel())

Numbers come from the NOAA KLM guide. Haven't really tested it against any reference yet, so please don't be surprised if it's not very precise.

AMSU-B should be very similar except that it scans three times faster than  AMSU-A.

Regards,

Mikhail

[Mikhail Itkin]

Thanks for the comments, Rutger, will keep them in mind. 

Visualization isn't that important at this step, the real work will be masking parts of the raster data using shapefiles generated from the swath outlines. Probably osgeo packages will be enough. But the idea of generating shapes comes from your earlier post, somehow i didn't think of it before (it's too long since i had my gis classes :)

Best,

Mikhail

[Martin Raspaud]

On 22/03/13 04:08, Mikhail Itkin wrote:
> Ok, here is what I came up with for AMSU-A (based entirely on Martins code,
> full example script attached):

[...]

> Numbers come from the NOAA KLM guide. Haven't really tested it against any
> reference yet, so please don't be surprised if it's not very precise.
> AMSU-B should be very similar except that it scans three times faster than
> AMSU-A.

Hi Mikhail,

Thanks a lot for the contribution ! I'll add it to the definitions.

Best regards,
Martin