==Overview==
Synthetic Aperture RADAR (SAR) data requires significant processing after acquisition. Since SAR tends to be a very specialized field, there are very few open source applications that specialize in manipulating processed data, much less processing raw data. The goal of this project then would be:
* Create as generic as possible a SAR Level 0 product processor using the Range-Doppler Algorithm
* Enhance and extend GDAL's capabilities for reading Level 0 (only) products from a variety of platforms (one point worth investigating is some airborne platforms such as the CV-580)
* Use GDAL to serialize the resulting image data, be it a GeoTIFF or some other format desired (COSAR, JPEG, who knows, with GDAL there is lots of flexibility)
There are presently no open source applications that are capable of processing Level 0 products, and this is something people have indicated they would desire in the past.

==Proposed Schedule==
TBD

==Implementation Details==
===Initial Goals===
# Establish a library providing basic mathematical functionality needed: Fast Fourier Transforms, certain types of filter kernel generation, matrix operations, interpolations, chirp generation, etc... as needed (and as can be borrowed from elsewhere)
# Ensure that GDAL is up to reading Level 0 SAR data for RADARSAT-1 (this will be the initial test platform) data.
# Design a system that is flexible and modular so that a variety of processing algorithms can be implemented in the future such as Omega-K and SPECAN.
===Range Doppler Algorithm===
# Implement the majority of the Range Doppler Algorithm, both documented in Ian Cummings and Frank Wong's book, as well as in a variety of technically significant papers.
::* Range FFT/matched filter generation
::* Range Cell Migration Correction
::* Azimuth FFT
::* etc...
===Image Processing Toolkit===
* If time permits, provide a set of tools designed for manipulating SAR data, such as tools for assisting in anomaly detection.

==Benefits of this Project==
Presently, purchasing a raw SAR processor is an expensive and often challenging task -- the software either has performance issues, has bugs or just simply doesn't hit the right niche for your application. A benefit of an open source SAR processor being available is that the software can be easily modified to suit specific purposes and for experimentation with processing algorithms. As well, supporting new platforms would be easy since the processing pre-requisites would already be completed and easily accessible to all!

==People Who Might Be Interested==
* There has been talk for years within Defence Research and Development Canada of the potential for an Open Source SAR processor.
* Canada Centre for Remote Sensing
* Commercial users (the cost of a SAR processor as it stands is not insignificant)

==Licensing==
The SAR Processor (currently nicknamed OpenSAR) will be licensed under the GNU General Public License v2 with potential MIT/X style licensing for organizations that need it (such as Government organizations).

==Who Am I?==
I am an undergraduate student at [http://www.carleton.ca/ Carleton University]. I am very interested in Synthetic Aperture RADAR from both a processing problem perspective and an applications perspective. I'm very interested in computer sight and have done several experiments involving facial recognition and creating new colour spaces, for example those based on Log Opponents for the purpose of facial identification. As well I've done some work on computer vision applications with regards to Captchas, most recently work on the captchas for MySpace and Digg. My love for SAR and image processing applications can probably be traced back to the fact that my father has been doing research in this field as long as I remember. I suppose apples don't fall far from the tree...
With regards to SAR I have done some work on my own library for reading RADARSAT-1 (and generic) Level 0 products, which can be found on [http://www.cowpig.ca my homepage]. As well, I have started work on OpenSAR, however, due to time constraints I have been unable to work on it as much as I would have liked to.
As far as programming languages, I am fluent in C[++], Java and Ada. I'm fairly familiar with Lisp, OCAML and Haskell, but I still like to write with those languages while keeping a detailed reference by my side. As well I can muddle my way through most other programming languages given time.
Being very interested in image processing applications, it seems appropriate that I'm an avid photographer. However, unlike the work I enjoy doing in my spare time on computer sight, I prefer to take a more old-fashioned approach and still trust my Nikon FM2n (135 format) and my Bronica SQ-A (medium format) film cameras more than I trust a digital camera. Some of my photos can be found [http://www.flickr.com/photos/flyingspores on my Flickr site], however, it has been awhile since I updated it (and I really need a new scanner!).

'''this is still a work in progress'''

GDAL SoC Ideas/SAR Processor

2007-03-20T21:59:56Z

Wiki-Vachonp: Created... work in progress

GDAL SoC Ideas

2007-03-08T07:23:36Z

Wiki-Vachonp: Added SAR Processor Proposal (hope nobody thinks I'm too crazy!)

GDAL/OGR Related ideas for the [[Google Summer of Code]] 2007:

# Write an OGC WMS (Web Map Service) driver, likely somewhat modelled on the WCS driver implementation.
#* [http://portal.opengeospatial.org/files/?artifact_id=1081&version=1&format=pdf WMS Specification]
#* [http://svn.osgeo.org/gdal/trunk/gdal/frmts/wcs WCS Code]
#* [http://www.gdal.org/gdal_drivertut.html GDAL Raster Driver Tutorial]
# Extend the existing KML vector feature writer to also support reading KML, and otherwise generalize this driver.
#* [http://svn.osgeo.org/gdal/trunk/gdal/ogr/ogrsf_frmts/kml writer code]
#* [http://www.gdal.org/ogr/drv_kml.html driver docs]
#* [http://www.gdal.org/ogr/ogr_drivertut.html OGR Driver Tutorial]
# Implement a raster reader/writer for KML.
#* [http://earth.google.com/kml KML Docs]
#* [http://www.gdal.org/gdal_drivertut.html GDAL Raster Driver Tutorial]
# Generally implement new file format drivers for geospatial raster or vector formats not already supported by GDAL/OGR. [http://www.gdal.org/gdal_drivertut.html GDAL Raster Driver Tutorial], [http://www.gdal.org/ogr/ogr_drivertut.html OGR Driver Tutorial], [http://www.gdal.org/formats_list.html Existing Raster Formats], [http://www.gdal.org/ogr/ogr_formats.html Existing Vector Formats]
# Implement GeoPNG/GeoJPEG by embeding coordinate system and geotransformation information (possibly in GML) as chunks in PNG and JPEG files (see GML JP2 for a model of how this might be done).
#* [http://portal.opengeospatial.org/files/?artifact_id=13252 GMLJP2 Specification]
#* GMLJP2 Code: [http://svn.osgeo.org/gdal/trunk/gdal/gcore/gdaljp2metadata.cpp gdaljp2metadata.cpp] [http://svn.osgeo.org/gdal/trunk/gdal/gcore/gdalgmlcoverage.cpp gdalgmlcoverage.cpp]
#* [http://svn.osgeo.org/gdal/trunk/gdal/frmts/png PNG Driver (using libpng)]
#* [http://svn.osgeo.org/gdal/trunk/gdal/frmts/jpeg JPEG Driver (using libjpeg)]
# Extend the OGR SQL parser to support some OGC SQL spatial function operators.
# New feature Clip to Extents of other raster, paying attention to nodata (take Raster A, and clip out/erase all areas for which Raster B does not extend to or has nodata values)
#* Utilize the rasterization algorithm that is part of [http://svn.osgeo.org/gdal/trunk/gdal/apps/gdal_rasterize.cpp gdal_rasterize.cpp]
# New feature to Clip by Polygon, as above but use a vector polygon for the selection area(s)
# OGR WFS read driver
# Design a SAR (Synthetic Aperture RADAR) "Processor" using GDAL as a data reader/processed data writer
#* Provide enhancements to relevant drivers (and potentially write new drivers) for reading new/common unprocessed SAR data sources, including metadata support where needed
#* Implement an end-to-end Range-Doppler Algorithm processor for platforms where processing details are available