Re: [GRASS-dev] Interest in GSoC 2016

[Pietro]

Hi Ondřej,

On Thu, Mar 17, 2016 at 7:45 PM,   wrote:
> My idea was to generalize GUI Code for Qt-based GUI. Nowadays, Qt (PyQt) is
> increasingly used (look at QGis, for example) and I think it would be better
> to have minimally the roots of GUI in Qt. It’s also much easier to maintain
> with new features. Work with design is also much more user-friendly. It
> seems that in the future, it can be nice shortcut to change something in the
> GUI.

I like the idea, and I think could be strategic for the long run,
especially because it is not clear to me if and when Phoenix (the
wxPython for python3) will be ready (and from my superficial
understanding of the GRASS problem on OS X El Captain Wx it seems part
of the issue), instead both pyQt and pySide support python3 (I think
we should build a GUI compatible with both binding. Consider that
GRASS is already working with Python3 (with except of the ctype stuff)
what it is critical (imho) it is the GUI.

I do like the idea of Vaclav to share a core of functionalities of the
GUI (between Wx, Qt, Jupyhter, etc). This shared functionalities
should go in /lib/python/grass/{gui|somethingelse}. This should allow
us to reduce duplication and the number of code that must be
maintained.

I think that we should also consider to split GRASS and its
functionalities, but I open a separate thread on this.

Best regards

Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] OSGeo-SoC 2016 application

[Yang, Bo (yangb2)]

Dear Soeren and Luca,

First, let me introduce myself again to Soeren. My name is Bo Yang, a Ph. D. 
student in the Department of Geography, University of Cincinnati, OH, USA.  I 
have a bachelor degree in Mathematics and MS in Computer Science. I am really 
interested in OSGeo-SoC2016. It would be a great opportunity if I can make 
contributions as well as learn to become an open-source developer.

Currently I have an idea based on my MA thesis project: Spatio-temporal fusion 
of multi-scale data with in a cokriging framework.
This project extends traditional cokriging method for blending spatial data 
sets with different temporal sampling frequency and spatial resolution 
(density). It can be used for both raster data and vector data, effectively 
fill in data gaps due to severe weather condition, instrument malfunction, or 
other reasons, filtering out data noise, and generate reliable results at both 
high spatial resolution and high temporal frequency with associated uncertainty 
estimates.

Soeren, I noticed you are the author of r.series.interp. I discussed a little 
with Luca, I agree this project is highly related to the package. So I am 
writing to ask if you are interest in mentoring this project. Currently I have 
the preliminary python code for the raster fusion attached(ImageFusion_SoC.py). 
It was written during my master degree, so it is sort of rough and haven't been 
re-constructed to OOP yet. But it runs well for fusion MODIS and Landsat data. 

I attached an fusion example for NDVI[0] images.  The program is able to blend 
Landsat TM/ETM+ NDVI image (30m) with MODIS NDVI image (250m)[1]. The NDVI can 
be calculated from the combination of the red band (Band 3 of Landsat TM or 
ETM+ multispectral imagery, or Band 1 of MODIS multispectral imagery) and near 
infrared band (Band 4 of Landsat TM or ETM+ multispectral imagery, or Band 2 of 
MODIS multispectral imagery). MODIS data has been resampled to 270m to 
co-registered with Landsat pixels. 

I selected a relatively cloud free period (07/19/2002-07/29/2002) to 
demonstrate the fusion process, the study region is Lake Tahoe region, NV, USA. 
Both Landsat and MODIS NDVI images need to be converted to ASCII file, source 
data can be found here[2]. Text files start with "A" are daily MODIS NDVI 
images and "lt5ndvi_0716" is the Landsat TM data. The goal of this example is 
to fuse daily MODIS NDVI images with a Landsat NDVI images (30m) to generate 
images at 30 m spatial resolution for everyday, using spatio-temporal cokriging 
method. Namely, I intend to use a single high resolutions Landsat NDVI images 
to sharpen daily time series MODIS images. Also the program is able to fill in 
the missing value. I artificially generated a missing data region in each input 
MODIS image and we can see the result fill in the missing data region very 
well. One good application of this algorithm is to fill in the gaps in the 
Landsat ETM+ images after 2002 due to the sensor's malfunction. 

The fusion module is attached, it need an input exponential/Gaussian model 
parameter which was calculated via semi-variogram fitting module. I did export 
the parameters in the attached text file for this case so the fusion module can 
be run independently. To run the program quickly, just put attached text file 
and source data[2] in the working folder and apply it to line22 of the fusion 
module. Of course other MODIS data can be used for this program if converted to 
ASCII files. There are two fusion methods, first one (line 330: 
fusion_with_covariable) is used for the MODIS data, which can sharpening and 
fill-in the missing data values. Second one is cokriging which incorporated the 
fine Landsat image as co-variable, it can achieve much better sharpening result 
as well as fill-in missing data values. Both method generated the gap filled 
result at 30m spatial resolution.

Please let me know if you have and comments or suggestions. Luca, thank you for 
sending me the compile method and programming manual. I normally used windows 
OS, and Eclipse + Pydev as primary IDE. I am going to look into the manual and 
GRASS codes. Any more advice would be greatly appreciated.

Best regards,
Bo Yang



[0] https://en.wikipedia.org/wiki/Normalized_Difference_Vegetation_Index
[1] https://lpdaac.usgs.gov/dataset_discovery/modis/modis_products_table/mod09gq
[2] 
https://drive.google.com/folderview?id=0B25sQdmthpGJS0JOdEh5cDd4S1k=sharing

-Original Message-
From: Luca Delucchi [mailto:lucadel...@gmail.com] 
Sent: Wednesday, March 16, 2016 11:18 AM
To: Yang, Bo (yangb2) ; Sören Gebbert 

Cc: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] OSGeo-SoC 2016 application

On 16 March 2016 at 04:49, Yang, Bo (yangb2)  wrote:
> Hi Luca,
>

Hi Bo Yang,

> Thank you for the reply and info. It is great if you could co-mentor this 
> project. I would be more interest in implementing my spatio-temporal fusion 

[GRASS-dev] ASTER radiance, top-of-atmosphere reflectance and temperature

[Carlos Grohmann]

Hi all,

A couple of weeks ago I was having problems with i.aster.toar [1]. after
Nikos' input with his bash script for calculation radiance and reflectance
for ASTER images, I made a python version that calculates radiance,
reflectance (VNIR/SWIR) and temperature (TIR). Output of temperature can be
in Kelvin, Celsius or Fahrenheit.

The user can process all bands ('all'), pre-defined subsets (vnir, swir,
vnswir, tir) or a choice of bands.

Radiance is calculated by default, while reflectance and temperature are
optional.

I'd appreciate if anyone could test it.

best

Carlos



[1] https://lists.osgeo.org/pipermail/grass-user/2016-February/073762.html
-- 
Prof. Carlos Henrique Grohmann
Institute of Energy and Environment - Univ. of São Paulo, Brazil
- Digital Terrain Analysis | GIS | Remote Sensing -

http://carlosgrohmann.com
http://orcid.org/-0001-5073-5572

Can’t stop the signal.


i.aster.toa_rrt
Description: Binary data
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.rgb: syntax error, unexpected $end, expecting VARNAME or NAME or STRING

[Vaclav Petras]

On Fri, Mar 18, 2016 at 10:10 AM, Markus Neteler  wrote:

>
> ok. But another error occurs (missing error handling if the output
> names were selected to be identica):
> ...
>
> Perhaps there is an elegant solution to catch the (user) error above?


Isn't this an issue for every module? I'm not sure if we have a general
solution (as in the previous case).
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev