Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
Paolo, you have not hurt anyone, you were annoying and arrogant, a behaviour that is virtually absent from this mailing list, and I for my part do not want to tolerate it. Anyway, continuing the thread this way is fruitless. This thread is about the QGIS SEXTANTE plugin. From a QGIS perspective, it is just that, a plugin for QGIS with backends to a number of analytical tools. From a GRASS perspective, this is a python version of SEXTANTE with one binding (QGIS) and including a backend to GRASS. I would like to see evolve python SEXTANTE into a more generic python SEXTANTE where it is easy to add more bindings, as in java SEXTANTE. I would also like to help improve the GRASS backend. In order to achieve this, I try to get into contact with people who are actually doing something on python SEXTANTE, i.e. the developers. Ciao, Markus On Tue, May 29, 2012 at 11:31 AM, Paolo Cavallini cavall...@faunalia.it wrote: Il 28/05/2012 21:17, Markus Metz ha scritto: not to java SEXTANTE. While on it (the blaming), I think it is time for Paolo to apologize for his rude [1] comments [2][3][4][5][6][7] earlier in the thread. I'm more than happy to apologize if I have hurt the sensibility of anybody. However, I think there is some misunderstanding, let's try to clarify: -SEXTANTE has two versions now (which are like 2 different projects) -The QGIS version is still unstable, but is a much better software (cleaner design, different things, etc) -It would be great to coordinate both versions, but it has to be done manually. currently, Victor Olaya is putting time on the QGIS version and not in the gvSIG one, so they might get uncoordinated, which Victor do not see as a terrible problem, anyway. -SEXTANTE for gvSIG has more algorithms and is more prepared for that, while SEXTANTE for QGIS has more backends, and is better suited for it. [2] http://osgeo-org.1560.n6.nabble.com/Report-from-ongoing-GRASS-GIS-Community-Sprint-in-Prague-tp4977136p4977385.html the link is wrong, the original source code is at http://code.google.com/p/sextante/source/browse/trunk/soft/bindings/qgis-plugin/src From the link I provided, you can easily find the source code at: http://plugins.qgis.org/plugins/sextante/ so it should be, according to Victor choice: http://sextante.googlecode.com/svn/trunk/ [3] http://osgeo-org.1560.n6.nabble.com/Report-from-ongoing-GRASS-GIS-Community-Sprint-in-Prague-tp4977136p4977411.html Paolo is appropriating python SEXTANTE as the QGIS Python plugin called sextante. See [2] I really do not understand this (see above). What is Python SEXTANTE? Anyway, sending a link and appropriating code seems different acts. [4] http://osgeo-org.1560.n6.nabble.com/Report-from-ongoing-GRASS-GIS-Community-Sprint-in-Prague-tp4977136p4977430.html Paolo is again appropriating python SEXTANTE (Please do nont send bug reports concerning it to other bugtrackers.) as the QGIS Python plugin called sextante. See [2] Bugs concerning the SEXTANTE QGIS Python plugin should be sent to: http://hub.qgis.org/projects/sextante/issues I do not see how this is appropriating anything. [5] http://osgeo-org.1560.n6.nabble.com/Report-from-ongoing-GRASS-GIS-Community-Sprint-in-Prague-tp4977136p4977473.html Paolo: I can correct you :) 1. Paolo was not addressed. 2. The issue has been resolved, no need for any further correction 3. I, not Paolo, gave an explanation and examples for the issue discussed (there is a complete re-write of SEXTANTE in Python). As I explained in a previous mail, Victor Olaya is the person who can best correct anybody on this. I took the liberty of talking on his behalf just because we are in close contact, and he has not subscribed to this list. [6] http://osgeo-org.1560.n6.nabble.com/Report-from-ongoing-GRASS-GIS-Community-Sprint-in-Prague-tp4977136p4977489.html Paolo: ... and join us. Paolo is not a developer of SEXTANTE, but very active for QGIS. Therefore us does obviously not mean SEXTANTE but QGIS. Paolo is again appropriating python SEXTANTE (Please do nont send bug reports concerning it to other bugtrackers.) as the QGIS Python plugin called sextante. See [2] Yes, us means QGIS. We (QGIS) already decided to integrate SEXTANTE into QGIS master as soon as code freeze is over (we are now releasing QGIS 1.8), so the distinction is blurred. [7] http://osgeo-org.1560.n6.nabble.com/Report-from-ongoing-GRASS-GIS-Community-Sprint-in-Prague-tp4977136p4977500.html At this stage of the python version of SEXTANTE, the main objective should be to get a stable version of python SEXTANTE. That is, a generic python SEXTANTE, not just something that works for QGIS and nothing else (with the SEXTANTE/GRASS interface not even working properly, see main comment). Paolo is again appropriating python SEXTANTE (Please do nont send bug reports concerning it to other bugtrackers.) as the QGIS Python plugin called sextante. See [2] Where do you find a
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
Il 28/05/2012 21:17, Markus Metz ha scritto: not to java SEXTANTE. While on it (the blaming), I think it is time for Paolo to apologize for his rude [1] comments [2][3][4][5][6][7] earlier in the thread. I'm more than happy to apologize if I have hurt the sensibility of anybody. However, I think there is some misunderstanding, let's try to clarify: -SEXTANTE has two versions now (which are like 2 different projects) -The QGIS version is still unstable, but is a much better software (cleaner design, different things, etc) -It would be great to coordinate both versions, but it has to be done manually. currently, Victor Olaya is putting time on the QGIS version and not in the gvSIG one, so they might get uncoordinated, which Victor do not see as a terrible problem, anyway. -SEXTANTE for gvSIG has more algorithms and is more prepared for that, while SEXTANTE for QGIS has more backends, and is better suited for it. [2] http://osgeo-org.1560.n6.nabble.com/Report-from-ongoing-GRASS-GIS-Community-Sprint-in-Prague-tp4977136p4977385.html the link is wrong, the original source code is at http://code.google.com/p/sextante/source/browse/trunk/soft/bindings/qgis-plugin/src From the link I provided, you can easily find the source code at: http://plugins.qgis.org/plugins/sextante/ so it should be, according to Victor choice: http://sextante.googlecode.com/svn/trunk/ [3] http://osgeo-org.1560.n6.nabble.com/Report-from-ongoing-GRASS-GIS-Community-Sprint-in-Prague-tp4977136p4977411.html Paolo is appropriating python SEXTANTE as the QGIS Python plugin called sextante. See [2] I really do not understand this (see above). What is Python SEXTANTE? Anyway, sending a link and appropriating code seems different acts. [4] http://osgeo-org.1560.n6.nabble.com/Report-from-ongoing-GRASS-GIS-Community-Sprint-in-Prague-tp4977136p4977430.html Paolo is again appropriating python SEXTANTE (Please do nont send bug reports concerning it to other bugtrackers.) as the QGIS Python plugin called sextante. See [2] Bugs concerning the SEXTANTE QGIS Python plugin should be sent to: http://hub.qgis.org/projects/sextante/issues I do not see how this is appropriating anything. [5] http://osgeo-org.1560.n6.nabble.com/Report-from-ongoing-GRASS-GIS-Community-Sprint-in-Prague-tp4977136p4977473.html Paolo: I can correct you :) 1. Paolo was not addressed. 2. The issue has been resolved, no need for any further correction 3. I, not Paolo, gave an explanation and examples for the issue discussed (there is a complete re-write of SEXTANTE in Python). As I explained in a previous mail, Victor Olaya is the person who can best correct anybody on this. I took the liberty of talking on his behalf just because we are in close contact, and he has not subscribed to this list. [6] http://osgeo-org.1560.n6.nabble.com/Report-from-ongoing-GRASS-GIS-Community-Sprint-in-Prague-tp4977136p4977489.html Paolo: ... and join us. Paolo is not a developer of SEXTANTE, but very active for QGIS. Therefore us does obviously not mean SEXTANTE but QGIS. Paolo is again appropriating python SEXTANTE (Please do nont send bug reports concerning it to other bugtrackers.) as the QGIS Python plugin called sextante. See [2] Yes, us means QGIS. We (QGIS) already decided to integrate SEXTANTE into QGIS master as soon as code freeze is over (we are now releasing QGIS 1.8), so the distinction is blurred. [7] http://osgeo-org.1560.n6.nabble.com/Report-from-ongoing-GRASS-GIS-Community-Sprint-in-Prague-tp4977136p4977500.html At this stage of the python version of SEXTANTE, the main objective should be to get a stable version of python SEXTANTE. That is, a generic python SEXTANTE, not just something that works for QGIS and nothing else (with the SEXTANTE/GRASS interface not even working properly, see main comment). Paolo is again appropriating python SEXTANTE (Please do nont send bug reports concerning it to other bugtrackers.) as the QGIS Python plugin called sextante. See [2] Where do you find a generic python SEXTANTE? Having said that, if this still hurts, I apologize once more: http://www.youtube.com/watch?v=m7mIy97_rlo All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
Il 26/05/2012 20:59, Benjamin Ducke ha scritto: Please report bugs relating to the SEXTANTE GRASS interface to the SEXTANTE bug tracker: http://bugs.gvsigce.org After logging in, switch the selection under Project: (upper right page area) to SEXTANTE: http://gvsigce.sourceforge.net/wiki/index.php/How_to_report_bugs The QGIS client code is just one of several GIS bindings that SEXTANTE supports, but any problems related to calling GRASS modules from SEXTANTE must be fixed in the shared Java code base. Wrong (no java here): http://hub.qgis.org/projects/sextante/issues That is the bugtracker for the gvSIG edition. I know it's confusing: http://hub.qgis.org/issues/5353 Thanks a lot. -- Paolo Cavallini See: http://www.faunalia.it/pc ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
Hi all, I saw on the wiki talk page that there will be some debugging in i.atcorr. One thing I've allways been troubled by is what is the output from the module. I know it's reflectance but the data is scaled to 8 bits. So does it means the 100% reflectance is 255? Cheers Daniel On Sat, May 26, 2012 at 1:08 PM, Markus Neteler nete...@osgeo.org wrote: Greetings from the GRASS GIS Community Sprint 2012 in Prague. With a peak participation of 16 persons, we are proceeding very well. Find the current activity report at: http://grass.osgeo.org/wiki/Talk:GRASS_Community_Sprint_Prague_2012 Photos will be uploaded soon! We are grateful for the support which we have received to organize this GRASS Community Sprint. Special thanks to our sponsors: * GFOSS.it, the Italian OSGeo chapter) - 1400 Euro * Open Source Geospatial Foundation (OSGeo) - 1000 Euro * FOSSGIS e.V. - 1000 Euro * Stefan Sylla, sylla-consult, Frankfurt, Germany - 500 Euro * Lubos Mitas, NC, USA - 200 Euro Best Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
On 05/28/2012 01:44 PM, Paolo Cavallini wrote:
Il 26/05/2012 20:59, Benjamin Ducke ha scritto:
Please report bugs relating to the SEXTANTE GRASS
interface to the SEXTANTE bug tracker:
http://bugs.gvsigce.org
After logging in, switch the selection under
Project: (upper right page area) to SEXTANTE:
http://gvsigce.sourceforge.net/wiki/index.php/How_to_report_bugs
The QGIS client code is just one of several GIS bindings
that SEXTANTE supports, but any problems related
to calling GRASS modules from SEXTANTE must be
fixed in the shared Java code base.
Wrong (no java here): http://hub.qgis.org/projects/sextante/issues
That is the bugtracker for the gvSIG edition.
I know it's confusing: http://hub.qgis.org/issues/5353
Thanks a lot.
SEXTANTE and gvSIG CE share a bug tracker
at http://bugs.gvsigce.org, a decision that
was made together with Victor Olaya a while
ago:
http://sextantegis.blogspot.de/2011/12/important-notice-for-gvsig-users.html
There is no such thing as a gvSIG edition
of SEXTANTE. SEXTANTE is a GIS-independent
library of processing functions written in Java.
Only the gvSIG bindings are gvSIG-specific code.
The GRASS GIS interface was written (in
large parts by myself!) in _Java_ and implemented
in the SEXTANTE _Java_ core libraries. It is _not_
QGIS-specific C++ code. I have spent many months
getting the SEXTANTE GRASS GIS interface into
good shape for _all_ host GIS, including QGIS.
There are now two different bug trackers
that track duplicate issues which have
to be fixed in the Java code base, _not_
the QGIS client code! I have already seen
several entries in the QGIS bug tracker
relating to GRASS, that are already reported
and being worked on at bugs.gvsigce.org.
The same is true for the R and SAGA backends,
both of which are also covered in the official
bug tracker.
Again: SEXTANTE is GIS-independent
and only bugs that refer to the QGIS side
(i.e. the specific bindings for that platform)
should be reported using the QGIS bug tracker.
Bugs that related to running GRASS/SAGA/R from within
SEXTANTE are GIS-independent and should thus be
worked on in one central place.
Of course, you are free to open as many additional
bug trackers, as you like, but this will result
in duplicate efforts, wasted time and resources,
and undermine all the work that has already been
done.
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
On Mon, May 28, 2012 at 2:21 PM, Daniel Victoria daniel.victo...@gmail.com wrote: Hi all, I saw on the wiki talk page that there will be some debugging in i.atcorr. One thing I've allways been troubled by is what is the output from the module. I know it's reflectance but the data is scaled to 8 bits. So does it means the 100% reflectance is 255? Due to an overwhelming agenda I didn't manage to look into this. However, a clear example would be desired in order to better analyse when bad things happen. Could you provide one? thanks Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
Il 28/05/2012 14:33, Benjamin Ducke ha scritto: SEXTANTE and gvSIG CE share a bug tracker at http://bugs.gvsigce.org, a decision that was made together with Victor Olaya a while Hi all. Sorry for the misunderstanding. I am not sure Victor (main SEXTANTE dev, AFAIK) is listening here - if so, he can explain much better. Anyway, I (and I suspect also Marckus) was referring to the QGIS Python plugin called sextante. No shared code with the Java version, AFAIK. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
On Mon, May 28, 2012 at 2:47 PM, Paolo Cavallini cavall...@faunalia.it wrote: Il 28/05/2012 14:33, Benjamin Ducke ha scritto: SEXTANTE and gvSIG CE share a bug tracker at http://bugs.gvsigce.org, a decision that was made together with Victor Olaya a while Hi all. Sorry for the misunderstanding. I am not sure Victor (main SEXTANTE dev, AFAIK) is listening here - if so, he can explain much better. Anyway, I (and I suspect also Marckus) was referring to the QGIS Python plugin called sextante. No shared code with the Java version, AFAIK. I have just compared the QGIS SEXTANTE plugin, the gvSIG SEXTANTE plugin, and the generic SEXTANTE. For example, the contents of the grass/description folder of QGIS SEXTANTE are completely different from gvSIG and generic SEXTANTE. The former has hand-crafted .txt files, the latter have automatically generated (grass command --interface-description) XML files. QGIS SEXTANTE is pure python without any java code, the others are pure java without any python code. There is a dedicated bug tracker for QGIS SEXTANTE, and from a user perspective this is the logical place to report issues for QGIS SEXTANTE, in particular when keeping in mind that the GRASS command interfaces in QGIS SEXTANTE are hand-crafted, see v.buffer.angle.txt, v.buffer.column.txt, v.buffer.distance.txt, v.buffer.minordistance.txt, four different interfaces to the same GRASS command v.buffer. In gvSIG SEXTANTE, there is only v.buffer.xml. How should a user take these differences into account? Report to http://bugs.gvsigce.org and explain that this does not apply to gvSIG SEXTANTE, only to QGIS SEXTANTE? Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
Il 28/05/2012 15:08, Markus Metz ha scritto: There is a dedicated bug tracker for QGIS SEXTANTE, and from a user perspective this is the logical place to report issues for QGIS SEXTANTE, in particular when keeping in mind that the GRASS command interfaces in QGIS SEXTANTE are hand-crafted, see v.buffer.angle.txt, ... How should a user take these differences into account? Report to http://bugs.gvsigce.org and explain that this does not apply to gvSIG SEXTANTE, only to QGIS SEXTANTE? The bugtracker for Sextante as a QGIS plugin is: http://hub.qgis.org/projects/sextante/issues Please do nont send bug reports concerning it to other bugtrackers. Thanks. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
OK, I think I can see my mistake now.
I always assumed that Victor had developed the QGIS bindings
on top of the existing Java libraries, using one of the
available Java to Python bridges or the Java Native Interface
for C++.
However, this does not seem to be the case. The code in:
http://code.google.com/p/sextante/source/browse/trunk/soft/bindings/qgis-plugin/src
does not contain just another binding for SEXTANTE to QGIS (even
though the SVN folder structure suggests this) -- Victor, please
correct me if I am wrong here.
Rather, it looks like it contains a complete re-write of SEXTANTE in
Python (excluding the original SEXTANTE processing tools, which seem
to be only available in their Java versions).
I am entirely unsure how to further maintain a code base in two
different programming languages and how to keep my own work
on the GRASS/SAGA/R interfaces in Java synchronized with this.
Any ideas welcome (but should probably be discussed on the SEXTANTE
user mailing list).
As far as the GRASS code sprint is concerned, please consider
that many people use SEXTANTE under gvSIG, OpenJUMP, GeoTools and
other Java-based GIS at this point, and that they are just as
interested in seeing the GRASS interface improved, as QGIS
users are. For now, I will monitor the QGIS bug tracker and
synchronize any relevant tickets manually with bugs.gvsigce.org.
Best,
Ben
On 05/28/2012 03:08 PM, Markus Metz wrote:
On Mon, May 28, 2012 at 2:47 PM, Paolo Cavallinicavall...@faunalia.it wrote:
Il 28/05/2012 14:33, Benjamin Ducke ha scritto:
SEXTANTE and gvSIG CE share a bug tracker
at http://bugs.gvsigce.org, a decision that
was made together with Victor Olaya a while
Hi all.
Sorry for the misunderstanding.
I am not sure Victor (main SEXTANTE dev, AFAIK) is listening here - if so, he
can
explain much better.
Anyway, I (and I suspect also Marckus) was referring to the QGIS Python plugin
called
sextante. No shared code with the Java version, AFAIK.
I have just compared the QGIS SEXTANTE plugin, the gvSIG SEXTANTE
plugin, and the generic SEXTANTE. For example, the contents of the
grass/description folder of QGIS SEXTANTE are completely different
from gvSIG and generic SEXTANTE. The former has hand-crafted .txt
files, the latter have automatically generated (grass command
--interface-description) XML files. QGIS SEXTANTE is pure python
without any java code, the others are pure java without any python
code.
There is a dedicated bug tracker for QGIS SEXTANTE, and from a user
perspective this is the logical place to report issues for QGIS
SEXTANTE, in particular when keeping in mind that the GRASS command
interfaces in QGIS SEXTANTE are hand-crafted, see v.buffer.angle.txt,
v.buffer.column.txt, v.buffer.distance.txt,
v.buffer.minordistance.txt, four different interfaces to the same
GRASS command v.buffer. In gvSIG SEXTANTE, there is only v.buffer.xml.
How should a user take these differences into account? Report to
http://bugs.gvsigce.org and explain that this does not apply to gvSIG
SEXTANTE, only to QGIS SEXTANTE?
Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
Il 28/05/2012 16:38, Benjamin Ducke ha scritto: does not contain just another binding for SEXTANTE to QGIS (even though the SVN folder structure suggests this) -- Victor, please correct me if I am wrong here. I can correct you :) Rather, it looks like it contains a complete re-write of SEXTANTE in Python (excluding the original SEXTANTE processing tools, which seem to be only available in their Java versions). Some of the tools are being ported. I am entirely unsure how to further maintain a code base in two different programming languages and how to keep my own work on the GRASS/SAGA/R interfaces in Java synchronized with this. Any ideas welcome (but should probably be discussed on the SEXTANTE user mailing list). As far as the GRASS code sprint is concerned, please consider that many people use SEXTANTE under gvSIG, OpenJUMP, GeoTools and other Java-based GIS at this point, and that they are just as interested in seeing the GRASS interface improved, as QGIS users are. For now, I will monitor the QGIS bug tracker and synchronize any relevant tickets manually with bugs.gvsigce.org. I do not see an alternative to manual sync (quite painful and inefficient, I know). All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
I do not see an alternative to manual sync (quite painful and inefficient, I
know).
All the best.
Neither do I, at this point. Manual sync it will be, then
-- argh :(
Sorry if I have been blunt in my reaction to this.
I have put a lot of thought effort into the SEXTANTE-GRASS
interface to get it to work as smoothly as it does now.
I would hate to see this work die a slow death for lack
of shared resources.
But perhaps the two code bases can somehow be kept in sync
-- at least for the most part.
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
Il 28/05/2012 17:18, Benjamin Ducke ha scritto: Sorry if I have been blunt in my reaction to this. I have put a lot of thought effort into the SEXTANTE-GRASS interface to get it to work as smoothly as it does now. I would hate to see this work die a slow death for lack of shared resources. I understand your point very well. I may be biased, but I think this new route is much more efficient, so I would suggest you to follow Victor and join us. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
Hello Paolo, we have put also a lot effort in SEXTANTE and in gvSIG/gvSIG CE. I like a lot these projects and also QGIS and I think it's positiv to see both (SEXTANTE-QGIS and SEXTANTE-gvSIG CE) growing and sharing Knowledge. The situation now is a bit confusing, but much better than 6 months ago: http://sextantegis.blogspot.de/2011/11/kinda-goodbye.html Best regards! Looking forward to see all these projects growing. José -- José Canalejo www.csgis.de I understand your point very well. I may be biased, but I think this new route is much more efficient, so I would suggest you to follow Victor and join us. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
Il 28/05/2012 17:56, José Antonio Canalejo Alonso ha scritto: we have put also a lot effort in SEXTANTE and in gvSIG/gvSIG CE. I like a lot these projects and also QGIS and I think it's positiv to see both (SEXTANTE-QGIS and SEXTANTE-gvSIG CE) growing and sharing Knowledge. The situation now is a bit confusing, but much better than 6 months ago: http://sextantegis.blogspot.de/2011/11/kinda-goodbye.html Ola José. I do not think the situation is very confusing for SEXTANTE: the gvSIG plugin is stable, the QGIS one is under active development. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague - i.atcoor
Crap... I looked out the windows and realized the atcoor vs. flaash comparison I just did had a major flaw. I also have a good linear regression between uncorrected radiance and reflectance from bothe flaash and atcoor. So a linear regression between flaash and atcoor does not mean that atcoor is working like it should, it means that both are correlated to the original radiance image... But my doubth still lives on: What is comming out of the i.atcoor module? We know it's reflectance but does a 255 value means 100% reflectance? Or is it the max reflectance in the image and we are not sure what that value is. Cheers Daniel On Mon, May 28, 2012 at 2:41 PM, Daniel Victoria daniel.victo...@gmail.com wrote: Hi Markus, On the i.atcoor issue, I did a quick comparison of a TM image corrected using i.atcoor (Grass 6.4) and Envi FLAASH, which is based on MODTRAN and should be similar to 6S. A detailed explanation is attached on the PDF file but basically this is what I did: 1) Correct a TM image using the same atmospheric parameters in atcoor and flaash 2) Generate a bunch of random points 3) Results from atcoor and flaash are linearly correlated but regression coefficients are not the same for the different bands. This makes it difficult for comparing the reflectance from i.atcoor with measured reflectance spectra since we are not sure what the max value of from i.atcoor output (255) means. Is it the maximum reflectance (100%)? Or is it the max reflectance in the evaluated image? That is, if the image has a max reflectance of 40%, then the output reflectance image from i.atcoor will put a value of 255 for 40% reflectance. Sorry for the long and confusing email. The good news is that i.atcoor is giving results very well correlated with the ones obtained by a respected atm correction scheme from a comercial package - hurray! We only need to figure out the scale of the output :) Thanks Daniel PS - I changed the subject line so it wouldn't mix with the sextante discussion On Mon, May 28, 2012 at 9:42 AM, Markus Neteler nete...@osgeo.org wrote: On Mon, May 28, 2012 at 2:21 PM, Daniel Victoria daniel.victo...@gmail.com wrote: Hi all, I saw on the wiki talk page that there will be some debugging in i.atcorr. One thing I've allways been troubled by is what is the output from the module. I know it's reflectance but the data is scaled to 8 bits. So does it means the 100% reflectance is 255? Due to an overwhelming agenda I didn't manage to look into this. However, a clear example would be desired in order to better analyse when bad things happen. Could you provide one? thanks Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague - i.atcoor
Daniel Victoria wrote: Crap... I looked out the windows and realized the atcoor vs. flaash comparison I just did had a major flaw. I also have a good linear regression between uncorrected radiance and reflectance from bothe flaash and atcoor. So a linear regression between flaash and atcoor does not mean that atcoor is working like it should, it means that both are correlated to the original radiance image... But my doubth still lives on: What is comming out of the i.atcoor module? We know it's reflectance but does a 255 value means 100% reflectance? Or is it the max reflectance in the image and we are not sure what that value is. [sneaking in because I did some modifications to i.atcorr about a year ago] According to the source code of i.atcorr, the minimum and maximum values coming out of i.atcorr are defined by the output scaling option, oscl in GRASS 6.x, rescale in GRASS 7. The default is 0,255, i.e. by default the smallest possible value is 0 and the largest possible value is 255 and in this case 255 would mean 100%. That means if you want to compare the output of flaash and i.atcorr and want to have identical values if possible, you should use oscl=0,1 for i.atcorr in GRASS 6.x. About the regression, I guess that with a visibility of 58.33 km nothing will change much and the good correlation between uncorrected and corrected bands is not surprising. From my own testing, atmospheric correction becomes interesting with a visibility of 5 km or less. Markus M Cheers Daniel On Mon, May 28, 2012 at 2:41 PM, Daniel Victoria daniel.victo...@gmail.com wrote: Hi Markus, On the i.atcoor issue, I did a quick comparison of a TM image corrected using i.atcoor (Grass 6.4) and Envi FLAASH, which is based on MODTRAN and should be similar to 6S. A detailed explanation is attached on the PDF file but basically this is what I did: 1) Correct a TM image using the same atmospheric parameters in atcoor and flaash 2) Generate a bunch of random points 3) Results from atcoor and flaash are linearly correlated but regression coefficients are not the same for the different bands. This makes it difficult for comparing the reflectance from i.atcoor with measured reflectance spectra since we are not sure what the max value of from i.atcoor output (255) means. Is it the maximum reflectance (100%)? Or is it the max reflectance in the evaluated image? That is, if the image has a max reflectance of 40%, then the output reflectance image from i.atcoor will put a value of 255 for 40% reflectance. Sorry for the long and confusing email. The good news is that i.atcoor is giving results very well correlated with the ones obtained by a respected atm correction scheme from a comercial package - hurray! We only need to figure out the scale of the output :) Thanks Daniel PS - I changed the subject line so it wouldn't mix with the sextante discussion On Mon, May 28, 2012 at 9:42 AM, Markus Neteler nete...@osgeo.org wrote: On Mon, May 28, 2012 at 2:21 PM, Daniel Victoria daniel.victo...@gmail.com wrote: Hi all, I saw on the wiki talk page that there will be some debugging in i.atcorr. One thing I've allways been troubled by is what is the output from the module. I know it's reflectance but the data is scaled to 8 bits. So does it means the 100% reflectance is 255? Due to an overwhelming agenda I didn't manage to look into this. However, a clear example would be desired in order to better analyse when bad things happen. Could you provide one? thanks Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
On Mon, May 28, 2012 at 6:02 PM, Paolo Cavallini cavall...@faunalia.it wrote: Il 28/05/2012 17:56, José Antonio Canalejo Alonso ha scritto: we have put also a lot effort in SEXTANTE and in gvSIG/gvSIG CE. I like a lot these projects and also QGIS and I think it's positiv to see both (SEXTANTE-QGIS and SEXTANTE-gvSIG CE) growing and sharing Knowledge. The situation now is a bit confusing, but much better than 6 months ago: http://sextantegis.blogspot.de/2011/11/kinda-goodbye.html Ola José. I do not think the situation is very confusing for SEXTANTE: the gvSIG plugin is stable, the QGIS one is under active development. Now that the SEXTANTE plugin for QGIS has been demystified and identified as a python version of SEXTANTE, this thread should IMHO be moved to a more appropriate place like the SEXTANTE developers mailing list [0]. QGIS is currently the testbed for the python version of SEXTANTE, but I guess that there would be wider interest in a python version, considering that python becomes ever more popular. As a GRASS developer I want to offer my help to the SEXTANTE developers to get the python SEXTANTE/GRASS interface in a usable shape. Currently it seems to be intentionally broken because of the missing descriptions and, more seriously, because some GRASS module settings were manually changed from their defaults such that the SEXTANTE/GRASS interface will not work for these modules. This applies only to python SEXTANTE, not to java SEXTANTE. While on it (the blaming), I think it is time for Paolo to apologize for his rude [1] comments [2][3][4][5][6][7] earlier in the thread. Markus M [0] http://www.freelists.org/list/sextante-devel [1] http://www.albion.com/netiquette/corerules.html [2] http://osgeo-org.1560.n6.nabble.com/Report-from-ongoing-GRASS-GIS-Community-Sprint-in-Prague-tp4977136p4977385.html the link is wrong, the original source code is at http://code.google.com/p/sextante/source/browse/trunk/soft/bindings/qgis-plugin/src [3] http://osgeo-org.1560.n6.nabble.com/Report-from-ongoing-GRASS-GIS-Community-Sprint-in-Prague-tp4977136p4977411.html Paolo is appropriating python SEXTANTE as the QGIS Python plugin called sextante. See [2] [4] http://osgeo-org.1560.n6.nabble.com/Report-from-ongoing-GRASS-GIS-Community-Sprint-in-Prague-tp4977136p4977430.html Paolo is again appropriating python SEXTANTE (Please do nont send bug reports concerning it to other bugtrackers.) as the QGIS Python plugin called sextante. See [2] [5] http://osgeo-org.1560.n6.nabble.com/Report-from-ongoing-GRASS-GIS-Community-Sprint-in-Prague-tp4977136p4977473.html Paolo: I can correct you :) 1. Paolo was not addressed. 2. The issue has been resolved, no need for any further correction 3. I, not Paolo, gave an explanation and examples for the issue discussed (there is a complete re-write of SEXTANTE in Python). [6] http://osgeo-org.1560.n6.nabble.com/Report-from-ongoing-GRASS-GIS-Community-Sprint-in-Prague-tp4977136p4977489.html Paolo: ... and join us. Paolo is not a developer of SEXTANTE, but very active for QGIS. Therefore us does obviously not mean SEXTANTE but QGIS. Paolo is again appropriating python SEXTANTE (Please do nont send bug reports concerning it to other bugtrackers.) as the QGIS Python plugin called sextante. See [2] [7] http://osgeo-org.1560.n6.nabble.com/Report-from-ongoing-GRASS-GIS-Community-Sprint-in-Prague-tp4977136p4977500.html At this stage of the python version of SEXTANTE, the main objective should be to get a stable version of python SEXTANTE. That is, a generic python SEXTANTE, not just something that works for QGIS and nothing else (with the SEXTANTE/GRASS interface not even working properly, see main comment). Paolo is again appropriating python SEXTANTE (Please do nont send bug reports concerning it to other bugtrackers.) as the QGIS Python plugin called sextante. See [2] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague - i.atcoor
Hi Markus M et al., Thanks!! You answer has removed a long standing doubt of mine. So the 255 output from i.atcoor is 100% reflectance. Great. Now here is another analysis (hope this time correct). I've taken the same random points from before and did a k-means clustering based on the i.atcoor results. I've then compared the average spectral profile for each class (atcoor vs. flaash). Flaash output has been divided by 1 and i.atcoor, by 255 to scale reflectance from 0 to 1. From the graphs we see that the spectral profile for each class is a bit different. Red line is the mean and the gray lines are the spectral profile for all points in that class. For instance, in class 5 (water), flaash has lowered reflectance values on bands 1 and 2 much more then i.atcoor. It appears as thoug Flaash will apply a stronger correction then atcoor, even using high visibility values. Could the different aerosol model used have caused this difference? Flaash used rural aerosol model and i.atcoor used continental... Cheers Daniel On Mon, May 28, 2012 at 3:16 PM, Markus Metz markus.metz.gisw...@googlemail.com wrote: Daniel Victoria wrote: Crap... I looked out the windows and realized the atcoor vs. flaash comparison I just did had a major flaw. I also have a good linear regression between uncorrected radiance and reflectance from bothe flaash and atcoor. So a linear regression between flaash and atcoor does not mean that atcoor is working like it should, it means that both are correlated to the original radiance image... But my doubth still lives on: What is comming out of the i.atcoor module? We know it's reflectance but does a 255 value means 100% reflectance? Or is it the max reflectance in the image and we are not sure what that value is. [sneaking in because I did some modifications to i.atcorr about a year ago] According to the source code of i.atcorr, the minimum and maximum values coming out of i.atcorr are defined by the output scaling option, oscl in GRASS 6.x, rescale in GRASS 7. The default is 0,255, i.e. by default the smallest possible value is 0 and the largest possible value is 255 and in this case 255 would mean 100%. That means if you want to compare the output of flaash and i.atcorr and want to have identical values if possible, you should use oscl=0,1 for i.atcorr in GRASS 6.x. About the regression, I guess that with a visibility of 58.33 km nothing will change much and the good correlation between uncorrected and corrected bands is not surprising. From my own testing, atmospheric correction becomes interesting with a visibility of 5 km or less. Markus M Cheers Daniel On Mon, May 28, 2012 at 2:41 PM, Daniel Victoria daniel.victo...@gmail.com wrote: Hi Markus, On the i.atcoor issue, I did a quick comparison of a TM image corrected using i.atcoor (Grass 6.4) and Envi FLAASH, which is based on MODTRAN and should be similar to 6S. A detailed explanation is attached on the PDF file but basically this is what I did: 1) Correct a TM image using the same atmospheric parameters in atcoor and flaash 2) Generate a bunch of random points 3) Results from atcoor and flaash are linearly correlated but regression coefficients are not the same for the different bands. This makes it difficult for comparing the reflectance from i.atcoor with measured reflectance spectra since we are not sure what the max value of from i.atcoor output (255) means. Is it the maximum reflectance (100%)? Or is it the max reflectance in the evaluated image? That is, if the image has a max reflectance of 40%, then the output reflectance image from i.atcoor will put a value of 255 for 40% reflectance. Sorry for the long and confusing email. The good news is that i.atcoor is giving results very well correlated with the ones obtained by a respected atm correction scheme from a comercial package - hurray! We only need to figure out the scale of the output :) Thanks Daniel PS - I changed the subject line so it wouldn't mix with the sextante discussion On Mon, May 28, 2012 at 9:42 AM, Markus Neteler nete...@osgeo.org wrote: On Mon, May 28, 2012 at 2:21 PM, Daniel Victoria daniel.victo...@gmail.com wrote: Hi all, I saw on the wiki talk page that there will be some debugging in i.atcorr. One thing I've allways been troubled by is what is the output from the module. I know it's reflectance but the data is scaled to 8 bits. So does it means the 100% reflectance is 255? Due to an overwhelming agenda I didn't manage to look into this. However, a clear example would be desired in order to better analyse when bad things happen. Could you provide one? thanks Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user attachment: reflec_1_3.pngattachment: reflec_4_6.png___ grass-user mailing list
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
Markus N wrote: Greetings from the GRASS GIS Community Sprint 2012 in Prague. With a peak participation of 16 persons, we are proceeding very well. sounds fun! sorry to be missing out. Find the current activity report at: http://grass.osgeo.org/wiki/Talk:GRASS_Community_Sprint_Prague_2012 I just added a couple small wishes: two enhancements to the wiki Templates for grass7 addons linking and brittle wikipedia template, and a request for help fixing a bug on the grass7 wx loc'n wizard ellipsoid code (Planets and Moons). Photos will be uploaded soon! We are grateful for the support which we have received to organize this GRASS Community Sprint. Special thanks to our sponsors: * GFOSS.it, the Italian OSGeo chapter) - 1400 Euro * Open Source Geospatial Foundation (OSGeo) - 1000 Euro * FOSSGIS e.V. - 1000 Euro * Stefan Sylla, sylla-consult, Frankfurt, Germany - 500 Euro * Lubos Mitas, NC, USA - 200 Euro kudos indeed :-) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
Greetings from the GRASS GIS Community Sprint 2012 in Prague. With a peak participation of 16 persons, we are proceeding very well. Find the current activity report at: http://grass.osgeo.org/wiki/Talk:GRASS_Community_Sprint_Prague_2012 Photos will be uploaded soon! We are grateful for the support which we have received to organize this GRASS Community Sprint. Special thanks to our sponsors: * GFOSS.it, the Italian OSGeo chapter) - 1400 Euro * Open Source Geospatial Foundation (OSGeo) - 1000 Euro * FOSSGIS e.V. - 1000 Euro * Stefan Sylla, sylla-consult, Frankfurt, Germany - 500 Euro * Lubos Mitas, NC, USA - 200 Euro Best Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
Hi,
sounds like an excellent code sprint!
One quick note:
Please report bugs relating to the SEXTANTE GRASS
interface to the SEXTANTE bug tracker:
http://bugs.gvsigce.org
After logging in, switch the selection under
Project: (upper right page area) to SEXTANTE:
http://gvsigce.sourceforge.net/wiki/index.php/How_to_report_bugs
The QGIS client code is just one of several GIS bindings
that SEXTANTE supports, but any problems related
to calling GRASS modules from SEXTANTE must be
fixed in the shared Java code base.
Cheers and happy hacking,
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
benducke AT fastmail.fm
On Sat, May 26, 2012, at 18:08, Markus Neteler wrote:
Greetings from the GRASS GIS Community Sprint 2012 in Prague.
With a peak participation of 16 persons, we are proceeding very well.
Find the current activity report at:
http://grass.osgeo.org/wiki/Talk:GRASS_Community_Sprint_Prague_2012
Photos will be uploaded soon!
We are grateful for the support which we have received to organize
this GRASS Community Sprint. Special thanks to our sponsors:
* GFOSS.it, the Italian OSGeo chapter) - 1400 Euro
* Open Source Geospatial Foundation (OSGeo) - 1000 Euro
* FOSSGIS e.V. - 1000 Euro
* Stefan Sylla, sylla-consult, Frankfurt, Germany - 500 Euro
* Lubos Mitas, NC, USA - 200 Euro
Best
Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
