MODIS/TODO

getProduct():
# improvement of automatic sensor detection 
# make a class modisproduct

longer term changes:
- instead of having a ~/.MODISopts file create a directory where to store MODISopts, ftpsettings, product specfic info (instead of using the auxiliary folder)
- what about removing runMrt support?
- reduce the capability of functions eg:
    completely separate getHdf from runGdal (also getProduct, getCollection etc should be removed from those functions.
    This should allow runGdal to run in a more general manner like a input file list that is crunched. This should result in some more lines to code when using runGdal but is also allows more freedom and performance. AND last but not least at all also much easier handling of the package development.
- allow only one product at the time. At that moment is is possible to do runGdal(product="M.D13",... this would process all M.D 13 products in one go by walking down the list produced by getProduct("M.D13"). 
  MOD and MYD should still be run by one call, but not eg: MxD13A1 and MxD13A2. This change would simplify a lot the package development.
- I was quite good to avoid the creation of classes, I am not sure if we really need it...maybe yes? S3 should be enough I guess? 
- Accelerate 'Downloading structure on ...'
- Any file in 'inst/external' no longer required? 

detectBitInfo()
- recent products supported? (see whittaker.raster)

MODISoptions() 
- Check for presence of .netrc file (<-> LP DAAC support)   

runGdal()
- an 'HdfName' argument (just like in getHdf()) could be of advantage in the 
  sense that if one (or numerous) local .hdf file is specified, an online 
  retrieval (of collection, available dates, etc.) is entirely turned off
- include scale factor during SDS extraction?  
- speed up when downloaded hdf / processed tif files are already present
  
getTile()
- add keepGrid (or something along this line), which maintains the MODIS grid location also when using 'extent' (tileH,tileV arelady works like that) 
- interactive polygon drawing via mapedit
  
detectBitInfo()
- update QA information in look-up table
- implement quality control routines for various products?

qualityControl
- method based on maximum value from preceding / current / succeeding image (i.e., from user-defined window) as proposed by Yang et al. (2013, http://dx.doi.org/10.1109/LGRS.2012.2219576)

whittaker.raster()  
- set (optional) thresholds to get rid of too high or low (i.e., outside [-1;1]) values resulting from smoothing spline
- output file names not in agreement with MODIS naming convention (i.e., timestamps start/end at the 5th/11th position rather than 15th/21st)

Take care of MOD16 Collection 105 on NTSG
When no file could be found for particular date (eg. on 2001-06-26 for MOD14A1.006), then output of   runGdal() has an entry like this one:
$`2001-06-26`
character(0)
runGdal() transforms extracted layers to 'outProj' other than specified in MODISoptions() if 'extent' is a shapefile <-> maybe optional?
Download is not possible for Swath products, see eg. https://github.com/MatMatt/MODIS/issues/18
Is 'quiet = ...' etc. specified in runGdal() or getHdf() passed on to MODISoptions? If no, this could be implemented as a temporary change of options (ie. 'save = FALSE')