[GRASS-dev] r.water.fea in grass 6.3

[Yann Chemin]

Hello all,

Anybody has ported r.water.fea to 6.x version?

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

Re: [GRASS-dev] winGRASS Self Installer Package

[Yann Chemin]

Hey Marco,

Thanks a million to go this way...
Many Windows people around here in Asia will be really happy to "just click"
to install wingrass. It will make the trainings easier for all especially to
tell them to give it away to friends...

Windows people get really bugged by this "new" GIS software that does so
much for free. i.e. "how come we did not know about it before?" :-)

Yann


On 06/03/2008, Marco Pasetti <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'm preparing a winGRASS self installer package, but I'm not sure about
> what
> files include in the package from PostgreSQL and SQLite install;
> Since now I included only libpq.dll (for PostgreSQL) and libsqlite3-0.dll
> (for SQLite); unfortunately I'm not able to use database instructions in
> GRASS, so I cannot know if some files are required or not! While SQLite is
> a
> very light utility (for all files), PostgreSQL requires lot of space
> (quite
> 30 MB!!!) for a complete inclusion in a GRASS self contained package.
>
> Can someone help me, please?
>
> Marco
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] WinGRASS-6.3.0RC5 Self Installer

[Yann Chemin]

Hi Marco,

Phew! What a job!
Congrats, it was a long awaited installation software.

I wish I could download the installation file, but it seems the server is Kaput.
If I can get a hand on it, I'll try to host it in my Institute for
Asian downloads.

Let see,
Thanks again,
Yann

On 11/03/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
> Hi all,
>
> I just finished to prepare and test the installer of WinGRASS-6.3.0RC5; I
> guessed to finished it two or three days ago, but I had some unexpected
> problems to fix;
> BTW, I have some other thinhs to explain, so, let's come with order
>
> 1) I updated the Building Guide with instructions on how to create a self
> contained package; see
> http://trac.osgeo.org/grass/wiki/BuildingOnWindows
>
> 2) I made a document that explain the content and usage of pre-released
> http://grass.fsv.cvut.cz/wiki/data/MSYS_Environment_080303.zip
> I uploaded it to
> http://www.webalice.it/marco.pasetti/grass/MSYS_Environment_080303_README.txt
>
> 3) WinGRASS Installer:
>
> I temporarily uploaded it to
> http://www.laser4000.it/temp/WinGRASS-6.3.0RC5-Setup.exe
> Please, someone could upload it to a GRASS server space? thanks
>
> Now let's come to the installer:
>
> 3.1) Unfortunately, I didn't complete all the things I planned to do, that
> is it still doesn't support installation paths containing blanks; if you
> select a path with blanks, the installer detects it and abort install.
> Actually, I preferred to not completely abort install process, but simply
> ask to re-entry the install path, but the installer script language (NSIS)
> doesn't support this feature; so, when you select a path with blanks and
> press "proceed" button, it display a warning message asking to "not select
> paths with blanks" and the aborts installation. It a minor problem, but I
> would feel better if I solved it
>
> 3.2) Installation procedure dinamically creates three different files, in
> order to reflect installation path selected by user:
>
> - grass63, to let start GRASS from MSYS console)
> - .grassrc6, to avoid usual error message at first GRASS launch
> - grass63.bat
>
> 3.3) Installer creates a complete "standard" windows installation, with
> registry key entries, shortcuts (desktop and menu) and automated uninstall
> procedure. If you also access "add/remove programs" menu, you can see GRASS
> install informations item. About shortcuts, installer automaticallt creates:
>
> - Start menu GRASS folder with link to grass63.bat and msys.bat
> - Desktop link to grass63.bat
>
> 3.4) During install procedure you can also select to download and install
> Spearfish sample database. By the way, standard procedure sets the prebuilt
> "demolocation" as standard location.
>
> 3.5) Final notes: I tested it, also in the uninstall procedure, and it works
> fine for me (NVIZ included, with Tcl-Tk 8.5.1 support).
> I also added a README.txt file, please read it and tell me if I made errors.
> I post its content (that also describes the content on this GRASS release)
>
> GRASS 6.3.0RC5 - Technology preview release candidate 5
> --
>
> INTRODUCTION:
> 
> GRASS (Geographic Resources Analysis Support System) is a free, open source
> Geographical information system (GIS) capable of handling raster,
> topological vector, image processing, and graphic data.
> GRASS is released under the GNU General Public License (GPL). The GRASS
> Development Team is a multi-national group consisting of developers at
> numerous locations. GRASS is one of the eight initial Software Projects of
> the Open Source Geospatial Foundation.
> GRASS GIS main web site: http://grass.osgeo.org/
>
> WinGRASS:
> -
> WinGRASS is a GRASS Development Team Project, concerning Windows Native
> Binary porting of latest technology previews of GRASS 6.3.0.
> The current release, based on GRASS 6.3.0RC5 (Technology preview release
> candidate 5), has been built on a i686 machine under MinGW environment.
> WinGRASS contains parts of the following open source softwares and
> libraries:
>
> Software/library (release):
>
> - MSYS (1.0.11)
> - Flex (2.5.4a-1)
> - Bison (2.1)
> - Zlib (1.2.3)
> - Libpng (1.2.24)
> - Libtiff (3.8.2)
> - Xdr (4.0)
> - Freetype (2.3.5)
> - FFTW (3.1.2)
> - PDCurses (3.3)
> - PROJ.4 (4.6.0)
> - GEOS (2.2.3)
> - PostgreSQL (8.2.6)
> - SQLite (3.5.6)
> - GDAL (1.5.0) *
> - Tcl/Tk (8.5.1)
>
> *with GEOS, PostgreSQL and SQlite support enabled
>
> All the previous softwares and libraries have been built from sources on a
> i686 machine under MinGW environment, with the exception of MSYS, provided
> by MinGW Project on SourceForge.NET (http://www.mingw.org/msys.shtml), and
> Flex and Bison, provided by GnuWin32 Project on SourceForge.NET
> (http://gnuwin32.sourceforge.net/).
>
> The current release of GRASS 6.3.0RC5 has been built with the following
> configuration:
>
> GRASS is now configured for: i686-p

Re: [GRASS-dev] WinGRASS-6.3.0RC5 Self Installer

[Yann Chemin]

Hi Marco,

have been trying to download all day,
cannot get an answer from the server...

Anybody mirrored it already?

Yann


> 3) WinGRASS Installer:
>
> I temporarily uploaded it to
> http://www.laser4000.it/temp/WinGRASS-6.3.0RC5-Setup.exe
> Please, someone could upload it to a GRASS server space? thanks
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] WinGRASS-6.3.0RC5 Self Installer

[Yann Chemin]

Hey Marco !

This rocks... Introduction to GIS will be MUCH simpler with this...

Thanks!
Yann

On 11/03/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I just finished to prepare and test the installer of WinGRASS-6.3.0RC5; I
> guessed to finished it two or three days ago, but I had some unexpected
> problems to fix;
> BTW, I have some other thinhs to explain, so, let's come with order
>
> 1) I updated the Building Guide with instructions on how to create a self
> contained package; see http://trac.osgeo.org/grass/wiki/BuildingOnWindows
>
> 2) I made a document that explain the content and usage of pre-released
> http://grass.fsv.cvut.cz/wiki/data/MSYS_Environment_080303.zip
> 
> I uploaded it to
> http://www.webalice.it/marco.pasetti/grass/MSYS_Environment_080303_README.txt
>
> 3) WinGRASS Installer:
>
> I temporarily uploaded it to
> http://www.laser4000.it/temp/WinGRASS-6.3.0RC5-Setup.exe
> Please, someone could upload it to a GRASS server space? thanks
>
> Now let's come to the installer:
>
> 3.1) Unfortunately, I didn't complete all the things I planned to do, that
> is it still doesn't support installation paths containing blanks; if you
> select a path with blanks, the installer detects it and abort install.
> Actually, I preferred to not completely abort install process, but simply
> ask to re-entry the install path, but the installer script language (NSIS)
> doesn't support this feature; so, when you select a path with blanks and
> press "proceed" button, it display a warning message asking to "not select
> paths with blanks" and the aborts installation. It a minor problem, but I
> would feel better if I solved it
>
> 3.2) Installation procedure dinamically creates three different files, in
> order to reflect installation path selected by user:
>
> - grass63, to let start GRASS from MSYS console)
> - .grassrc6, to avoid usual error message at first GRASS launch
> - grass63.bat
>
> 3.3) Installer creates a complete "standard" windows installation, with
> registry key entries, shortcuts (desktop and menu) and automated uninstall
> procedure. If you also access "add/remove programs" menu, you can see GRASS
> install informations item. About shortcuts, installer automaticallt creates:
>
> - Start menu GRASS folder with link to grass63.bat and msys.bat
> - Desktop link to grass63.bat
>
> 3.4) During install procedure you can also select to download and install
> Spearfish sample database. By the way, standard procedure sets the prebuilt
> "demolocation" as standard location.
>
> 3.5) Final notes: I tested it, also in the uninstall procedure, and it works
> fine for me (NVIZ included, with Tcl-Tk 8.5.1 support).
> I also added a README.txt file, please read it and tell me if I made errors.
> I post its content (that also describes the content on this GRASS release)
>
> GRASS 6.3.0RC5 - Technology preview release candidate 5
> --
>
> INTRODUCTION:
> 
> GRASS (Geographic Resources Analysis Support System) is a free, open source
> Geographical information system (GIS) capable of handling raster,
> topological vector, image processing, and graphic data.
> GRASS is released under the GNU General Public License (GPL). The GRASS
> Development Team is a multi-national group consisting of developers at
> numerous locations. GRASS is one of the eight initial Software Projects of
> the Open Source Geospatial Foundation.
> GRASS GIS main web site: http://grass.osgeo.org/ 
>
> WinGRASS:
> -
> WinGRASS is a GRASS Development Team Project, concerning Windows Native
> Binary porting of latest technology previews of GRASS 6.3.0.
> The current release, based on GRASS 6.3.0RC5 (Technology preview release
> candidate 5), has been built on a i686 machine under MinGW environment.
> WinGRASS contains parts of the following open source softwares and
> libraries:
>
> Software/library (release):
>
> - MSYS (1.0.11)
> - Flex (2.5.4a-1)
> - Bison (2.1)
> - Zlib (1.2.3)
> - Libpng (1.2.24)
> - Libtiff (3.8.2)
> - Xdr (4.0)
> - Freetype (2.3.5)
> - FFTW (3.1.2)
> - PDCurses (3.3)
> - PROJ.4 (4.6.0)
> - GEOS (2.2.3)
> - PostgreSQL (8.2.6)
> - SQLite (3.5.6)
> - GDAL (1.5.0) *
> - Tcl/Tk (8.5.1)
>
> *with GEOS, PostgreSQL and SQlite support enabled
>
> All the previous softwares and libraries have been built from sources on a
> i686 machine under MinGW environment, with the exception of MSYS, provided
> by MinGW Project on SourceForge.NET (http://www.mingw.org/msys.shtml
>  ), and Flex and Bison, provided by
> GnuWin32 Project on SourceForge.NET (http://gnuwin32.sourceforge.net/
>  ).
>
> The current release of GRASS 6.3.0RC5 has been built with the following
> configuration:
>
> GRASS is now configured for: i686-pc-mingw32
> Source direc

[GRASS-dev] changing code to output point vector from old site system (r.sim.water)

[Yann Chemin]

Hello list,

anybody could pin-point where I should start reading to change an old
site system to a new point vector?

I am in to upgrade the point ouput of r.sim.water

! Never programmed with vectors before

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

[GRASS-dev] opening any RS/GIS file in their original format directly in GRASS...

[Yann Chemin]

Hello list,

many first time users get a little bit "estranged" by the scientifically
robust way of starting GRASS by setting up a DB/location/mapset.

While the "create location from georeferenced file" button in TCLTK gui (not
yet in wxpython it seems) is an very nice step,
I would like your ideas about the feasibility of a CLI command similar to
"grass63 rs_image.tif" or "grass63 shapfile.shp" possibly having a
right-click option: "open with... => Grass63" like you can see in many OSes
these days.

The idea would be to create a temporary location (if not already there and
compatible) from this image/GIS_cover data,  import it , load layer(s), and
display it(them).

One more step could be creating a png out of it, with title, arrow, scale
etc... as a thumbnail view of the dataset.
Don't know, the extents and date/time (if any) could be added in a kind of
default location holding footprints of already opened data with standard
grass metadata (r.info) available on click over a given footprint... Of
course with the thumbnail available somehow directly in the footprint as
hyperlink, or as display option (visible/hidden), or just a hyperlink in the
metadata, or if metadata can be reformatted (automatically) to html, then
embed the thumbnail it...

Many people face a large amount of datasets these days, and knowing
where/when/what is each is a challenge.

sorry, started as a simple idea, ended in a kind of cataloging project...

Have a nice day,
Yann
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] first users main trouble

[Yann Chemin]

Hi all,

just though to say one thing that first users have trouble with.
In itself it is not a problem for half of them after few days of GRASS GIS,
but the remaining part  just cannot get used to it.

When processing is done, they think their new map is going to be displayed
automatically (it is part of the  processing to display output).

linked to this, they have hard time imagining that two-three windows make
one software (I know, Windows users they are), I have to expelain that most
GIS/RS software work this way, and that it has strong advantages (dual
monitors for example, one for processing and one visualizing), and I prefer
it that way as many of us I guess.

Just adding a little bit on what wall very first GIS users are banging...
Yann
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] opening any RS/GIS file in their original format directly in GRASS...

[Yann Chemin]

Did not catch it there,
thanks for pointing it out Martin!

Yann

On 14/03/2008, Martin Landa <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> 2008/3/14, Yann Chemin <[EMAIL PROTECTED]>:
>
>
> > While the "create location from georeferenced file" button in TCLTK gui
> (not
> > yet in wxpython it seems) is an very nice step,
>
>
> this is implemented in wxPython GUI as part of the location wizard [1].
>
> [snip]
>
> Martin
>
> [1]
> http://grass.gdf-hannover.de/wiki/WxPython-based_GUI_for_GRASS#Location_wizard
>
>
> --
> Martin Landa  * http://gama.fsv.cvut.cz/~landa *
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] first users main trouble

[Yann Chemin]

Yes Benjamin,

2 third or more are generally non-GIS non-geographical background and
Windows users.
Remaining ArcGIS/ArcView and sometimes i got chance with a couple of BSD
teaching guys.
Also, for the first time I saw a person (in Thailand) coming up with an
Ubuntu laptop, made things easier In Laos, no Internet, major amount of
viruses on computers... sorry... not the topic.

I do recognize the power of GRASS by all means, I am just trying to get
people started up faster. From Null() to G_anything().

:-)



On 14/03/2008, Benjamin Ducke <[EMAIL PROTECTED]> wrote:
>
>
> >
> > Just adding a little bit on what wall very first GIS users are
> banging...
> > Yann
>
>
> Are they really first time GIS users? Or first time GRASS users?
> If they have had exposition to other GIS before, chances are it will
> have been ArcGIS or MapInfo -- i.e. a Desktop GIS. If it was a
> Workstation class GIS, such as ArcInfo or IDRISI, they should have
> far less trouble,
>
> GRASS being rather of the Workstation type, Currently, GRASS does not
> try  to emulate the heavily interactive Desktop GIS workflow too much,
> as it only gets in the way of (semi-) automated and mass data processing
> for which GRASS is the ruling champion.
>
> Benjamin
>
> >
> >
> > 
> >
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>
> --
> Benjamin Ducke
> Senior Applications Support and Development Officer
>
> Oxford Archaeological Unit Limited
> Janus House
> Osney Mead
> OX2 0ES
> Oxford, U.K.
>
> Tel.: ++44 (0)1865 263 800
> [EMAIL PROTECTED]
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] r.watershed problem

[Yann Chemin]

Hi,

I am trying to get streams out of srtm map of Mekong Basin.
my laptop is 2 Gb RAM and enough HDD space. I tried with and without
-m flag, same result. Any idea/suggestion?

thanks
Yann

GRASS 6.3.svn (Sub1):~/tmp/grass/gui/wxpython/gui_modules >
r.watershed --overwrite [EMAIL PROTECTED]
stream=mekong_streams threshold=5 -m
SECTION 1 beginning: Initiating Variables. 5 sections total.
WARNING: No such file or directory
WARNING: cseg_open(): could not write segment file
WARNING: No such file or directory
WARNING: cseg_open(): could not write segment file
WARNING: No such file or directory
WARNING: cseg_open(): could not write segment file
WARNING: category information for [mekong_streams] in [test] missing or invalid

GRASS 6.3.svn (Sub1):~/tmp/grass/gui/wxpython/gui_modules > r.info mekong_srtm
 ++
 | Layer:mekong_srtmDate: Sat Mar 15 17:22:25 2008|
 | Mapset:   test   Login of Creator: yann|
 | Location: Sub1 |
 | DataBase: /home/yann/GRASSDATA |
 | Title: ( mekong_srtm ) |
 | Timestamp: none|
 ||
 ||
 |   Type of Map:  raster   Number of Categories: 3058|
 |   Data Type:CELL   |
 |   Rows: 16923  |
 |   Columns:  9558   |
 |   Total Cells:  161750034  |
 |Projection: Latitude-Longitude  |
 |N: 24:02:14.65386NS: 9:56:05.856936N   Res: 0:00:02.88  |
 |E: 108:39:25.435332EW: 100:41:31.550028E   Res: 0:00:02.999 |
 |   Range of data:min = -28  max = 3058  |
 ||
 |   Data Description:|
 |generated by r.mapcalc  |
 ||
 |   Comments:|
 |if(mekong == 1, srtm_sea, null())   |
 ||
 ++
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] ported to 6.x: r.hydro.CASC2D (in grass-addons)

[Yann Chemin]

Hi all,

ported in v6.x r.hydro.CASC2D some time back, and tested it this week-end,
it seems to work well for water depth calculations.

Anybody who is more able to test it is most welcome,
it is in Grass-addons under the gipe directory.

If you feel like bringing it back to main GRASS tree, I'll remove it
from the add-ons one.

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

Re: [GRASS-dev] r.watershed and swap memory

[Yann Chemin]

Hi Ivan and Helena,

149,040,000 Cells for the srtm 90m of Mekong river.
computer is on 8Gb RAM.
About 65 % done after 43.x hours, r.watershed basically does it, it seems.
Of course efficiency is a problem here, but it does it.

yes r.terraflow goes to /tmp, that is considered a bug to me, not an
enhancement...
The location from which we have the GRASS dataset is generally the
best guess for large empty Disk space.

Cheers,
Yann




On 19/03/2008, ivan marchesini <[EMAIL PROTECTED]> wrote:
> Dear Helena,
>  Thank you very much for your answer...
>  my problems are:
>
>  * is the flowdirection output produced by r.terraflow suitable for basin
>  creation (like I can do with the drainage map created by r.watershed and
>  given as input to r.water.outlet)? Because this is my final target...
>  It seems to me that r.terraflow outputs aren't useful for basin
>  delineation... or I'm wrong?
>
>  * I'm really interested in testing TerraSTREAM but, probably due to my
>  fault, I wasn't able to obtain a login and password...
>
>  many many thanks
>
>  Ivan
>
>
>
>
>
>
>
>  Il giorno mar, 18/03/2008 alle 09.33 -0400, Helena Mitasova ha scritto:
>
> > Ivan - you may talk to Yann on this list before you buy more memory -
>  > he is trying to do the same as you , but with a bigger DEM and 8GB of
>  > memory (Yann I hope it is OK with you that I am revealing this here).
>  > My experience with large DEMs (up to 10,000x10,000) has been that I
>  > had to split the area into sections that were about
>  > 2000x2000 on 1GB memory computer) to get it done (I was able to do
>  > that for Panama because of its shape - many small watersheds rather
>  > than a single big one) - it took me several days to do that.
>  > Then I ran r.terraflow and I got it in 3 hours.
>  >
>  > Yann says that r.terraflow did not work for him - now I remember what
>  > the problem was when I tried to run it recently -
>  > it needs a LOT of hard drive space which is not a problem these days,
>  > BUT the default has been changed
>  > to /tmp which for my linux box is only 2GB or so. But when running
>  > r.terraflow you can define where
>  > you want the temporary files to be written - so give it something
>  > with a lot of space (tens of gigabytes at least)
>  > and it should run. I think that the default should be changed to
>  > where it was - I think it is the regular grass tmp where people
>  > usually have a lot of space for the data.
>  >
>  > If even that does not work you can give a try to brand new
>  > TerraSTREAM - see the link below
>  > (and let me know whether it works for you),
>  >
>  > Helena
>  >
>  >   TerraSTREAM provides a series of components that
>  > perform flow modeling and terrain analysis tasks on very large digital
>  > elevation models and works equally well on TIN and grid DEMs. The
>  > algorithms
>  > used in the libraries have provable efficient performance in the
>  > worst case,
>  > even on very large terrains that do not fit in the main memory of the
>  > computer.
>  > TerraSTREAM 0.2 comes with direct GRASS and ArcGIS support as well as
>  > a simple
>  > standalone graphical user interface and powerful command line tools
>  > that can be
>  > used alone or integrated into most GIS environments by scripting. For
>  > more
>  > information about this release and for contact information, visit
>  > http://madalgo.au.dk/Trac-TerraSTREAM/.
>  > The TerraSTREAM 0.2 users guide is available here:
>  > http://madalgo.au.dk/Trac-TerraSTREAM/wiki/UsersGuide .
>  >
>  >
>  >
>  > On Mar 18, 2008, at 5:32 AM, ivan marchesini wrote:
>  >
>  > > Dear Grass Users and Developers, sorry for cross posting but we
>  > > hope the
>  > > argument can be of interest for all and we hope someone can give us a
>  > > solution to this problem..
>  > >
>  > > We have this kind of problem:
>  > > * a large DEM (15000 cells)
>  > > * an ordinary computer (2 GB ram)
>  > > * we must obtain the drainage map using r.watershed (without changing
>  > > resolution), because then we need to be able to calculate the upstream
>  > > basin for each cell (r.water.outlet).
>  > > * we have tried r.watershed straigth (but after few seconds a memory
>  > > allocation problem crashed the program)
>  > > * we have tried the "-m" option but after 4 days of work it is
>  > > still at
>  > > 0%.
>  > > * giving up the last option, because it takes too long, we have
>  > > monitored the ram usage by means of "free -m" and we have seen that
>  > > r.watershed rapidly saturate the ram and then, after a little usage of
>  > > swap (20 mb) crashes..  so it seems that r.watershed doesn't use swap
>  > > memory... (and is then unuseful, as we did, to increase the swap
>  > > memory)
>  > > * we have tried to modify
>  > > "Swappiness" (http://www.gentoo.it/doc/memory.html#doc_chap5) but
>  > > without success... the error is still the same
>  > >
>  > >
>  > > so at this point:
>  > > * is adding ram to the computer the only solution?
>  > > * if yes, how c

Re: [GRASS-dev] r.watershed and swap memory

[Yann Chemin]

Hi Hamish,

my mistake, forgot to include that htop one:

VIRT 6323Mb
RES 5232Mb

noted the terraflow options, i am just waiting for this r.watershed
experiment to conclude...

Yann

On 19/03/2008, Hamish <[EMAIL PROTECTED]> wrote:
> Yann Chemin wrote:
>  > 149,040,000 Cells for the srtm 90m of Mekong river.
>  > computer is on 8Gb RAM.
>  > About 65 % done after 43.x hours, r.watershed basically does it, it
>  > seems.
>  > Of course efficiency is a problem here, but it does it.
>
>
> how much RAM is the process using? (check with `top`, VIRT RES SHR)
>
>
>
>  > yes r.terraflow goes to /tmp, that is considered a bug to me, not an
>  > enhancement...
>  > The location from which we have the GRASS dataset is generally the
>  > best guess for large empty Disk space.
>
>
> note these r.terraflow options:
> memory   Main memory size (in MB)
>  default: 300
> STREAM_DIR   Location of intermediate STREAMs
>  default: /var/tmp
>
>
>  by making memory= larger the required tmp file space should be smaller.
>  you can set STREAM_DIR= somewhere else if you like.
>
>
>
>  Hamish
>
>
>
>
>   
> 
>  Never miss a thing.  Make Yahoo your home page.
>  http://www.yahoo.com/r/hs
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] strange for loop bug

[Yann Chemin]

Hello,

I am writing a raster module for image processing, and the
for(col=0;colhttp://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: strange for loop bug

[Yann Chemin]

Hi again,

Well, this was a gcc-4.3.1 20080321 version for Debian

I tried gcc-4.2.3 also for Debian and it crashed while giving the
processed pixel to outrast[col]...

Finally went to gcc-4.1.3 20080308 version for Debian (4.1.2-21) which
is working fine...

maybe of any use
Yann

On 01/04/2008, Yann Chemin <[EMAIL PROTECTED]> wrote:
> Hello,
>
>  I am writing a raster module for image processing, and the
>  for(col=0;col  number of lines of code inside is 239 lines. If i reduce the number of
>  functions inside to a simple copy of an input raster, the number of
>  line being 15 less, then it does not seg fault.
>
>  The error is basically the variable col becoming a very large negative
>  number, which is constant for a compilation, may not be the same
>  actually in all modifications of the code tested.
>
>  The interesting thing is that it processes through 77 rows of Null
>  pixels (sending outrast[col] to G_set_d_null_value(..)) and when it
>  comes to the first real data processing, it gives the output value to
>  outrast[col], goes up the loop and at that moment, col passes from
>  1450 to -2085319823.
>
>  Anybody has any experience of similar event?
>  Any idea what could corrupt a for() loop variable?
>
>  I am also going to change gcc version in case it is a gcc bug.
>
>  Thank you,
>
> Yann
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.watershed and swap memory

[Yann Chemin]

hi,

just to complete the comment on r.watershed, large dataset, and large RAM...
After 5+ days I stopped the processing, it seemed that it was becoming
slower and slower with time (i.e. increment of percent), while holding
nearly same memory consumption.

I would guess it was searching something more and more elusive...
Don't know much about the algorithm though.

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

[GRASS-dev] heavy processing and memory

[Yann Chemin]

Hello,

Attached is the processing time by percentage of completion of an
energy balance function using some iteration process.
Each cell processing is independent, the code follows r.example and
typical raster algorithm functions like ndvi and other simple
pixel-based equations.

The processing of a Landsat 5TM image takes 4.19hours on a Desktop computer.
The interesting thing I would like to ask is about the apparent
non-linearity of the processing curve. Is it normal?

Thank you,
Yann


-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
<>___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] SVN error in Add-Ons

[Yann Chemin]

Hi,

While doing a couple of updates this afternoon, suddenly svn refused updates,
saying this:

# svn ci -m "fix bug"
svn: Commit failed (details follow):
svn: Unrecognized URL scheme for
'https://svn.osgeo.org/grass/grass-addons/gipe/r.out.vic'

Anybody could check the server please?
Yann

-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] SVN error in Add-Ons

[Yann Chemin]

Hi,

just woke up,
yes still a problem. Same problem.

Yann

On 14/04/2008, Frank Warmerdam <[EMAIL PROTECTED]> wrote:
> Yann Chemin wrote:
>
> > Hi,
> >
> > While doing a couple of updates this afternoon, suddenly svn refused
> updates,
> > saying this:
> >
> > # svn ci -m "fix bug"
> > svn: Commit failed (details follow):
> > svn: Unrecognized URL scheme for
> > 'https://svn.osgeo.org/grass/grass-addons/gipe/r.out.vic'
> >
> > Anybody could check the server please?
> >
>
>  Yann,
>
>  Is this still a problem for you?  Have you heard if it happens to others
> too?
>
>  Best regards,
>  --
> ---+--
>  I set the clouds in motion - turn up   | Frank Warmerdam,
> [EMAIL PROTECTED]
>  light and sound - activate the windows | http://pobox.com/~warmerdam
>  and watch the world go round - Rush| President OSGeo, http://osgeo.org
>
>


-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] SVN error in Add-Ons

[Yann Chemin]

svn diff works fine.

??? (at a loss here)

On 15/04/2008, Hamish <[EMAIL PROTECTED]> wrote:
> Yann Chemin wrote:
>  > While doing a couple of updates this afternoon, suddenly svn
>  > refused updates, saying this:
>  >
>  > # svn ci -m "fix bug"
>  > svn: Commit failed (details follow):
>  > svn: Unrecognized URL scheme for
>  > 'https://svn.osgeo.org/grass/grass-addons/gipe/r.out.vic'
>
>
>
> Hi,
>
>  FWIW, I saw a similar error message a few days ago but then it was
>  because I miss wrote the directory name, like
>
>  https://svn.osgeo.org/grass/trunk/...
>   instead of correct:
>  https://svn.osgeo.org/grass/grass/trunk/...
>
>  works for me:
>
>  $ svn co https://svn.osgeo.org/grass/grass-addons/gipe/r.out.vic \
>
> grass-addons/gipe/r.out.vic
>
>
>
>
> if I put a typo in the addons dir structure I get the error:
>   svn: URL '.../grass/grass-addon/...' doesn't exist
>
>  if I put a typo in the project name I the less helpful error:
>   svn: PROPFIND request failed on '/gras/grass-addons/...'
>   svn: PROPFIND of '/gras/grass-addons/...': 405 Method Not Allowed
>  (https://svn.osgeo.org)
>
>
>
>  maybe try the checkin with full path and filename from the grass-addons
>  "root" dir? try with a fresh checkout?
>
>  does "svn diff" work?
>
>
>  ?
>
> Hamish
>
>
>
>
>   
> 
>  Be a better friend, newshound, and
>  know-it-all with Yahoo! Mobile.  Try it now.  
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
>


-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] SVN error in Add-Ons

[Yann Chemin]

I tried a fresh check out and it seems that it runs into the same problem...

# svn co https://svn.osgeo.org/grass/grass-addons/
svn: Unrecognized URL scheme for 'https://svn.osgeo.org/grass/grass-addons'
#

I suppose that svn got allergic to https as you suggested, but I did
not see that subversion got upgraded recently in my box... Definitely
not while I was working.

Still not clear...

On 15/04/2008, Frank Warmerdam <[EMAIL PROTECTED]> wrote:
> Yann Chemin wrote:
>
> > Hi,
> >
> > just woke up,
> > yes still a problem. Same problem.
> >
>  ...
>
> >
> > >
> > > > # svn ci -m "fix bug"
> > > > svn: Commit failed (details follow):
> > > > svn: Unrecognized URL scheme for
> > > >
> 'https://svn.osgeo.org/grass/grass-addons/gipe/r.out.vic'
> > > >
> > >
> >
>
>  Yann,
>
>  I just tried a commit in this area and it seems to work fine.  I suspect
>  your svn client does not support https (compiled without it), though I
>  can't think of any reason this would have recently changed.
>
>  I did:
>
>  [EMAIL PROTECTED] svn checkout
> https://svn.osgeo.org/grass/grass-addons/gipe/
>  r.out.vic
>  Ar.out.vic/main.c
>  Ar.out.vic/description.html
>  Ar.out.vic/veg_lib.c
>  Ar.out.vic/Makefile
>  Checked out revision 30991.
>  [EMAIL PROTECTED] ls
>  r.out.vic
>  [EMAIL PROTECTED] cd r.out.vic/
>  [EMAIL PROTECTED] ls
>  description.html  main.c  Makefile  veg_lib.c
>  [EMAIL PROTECTED] svn status
>  [EMAIL PROTECTED] vi Makefile
>  [EMAIL PROTECTED] svn status
>  M  Makefile
>  [EMAIL PROTECTED] svn commit -m "test commit" Makefile
>  Authentication realm: <https://svn.osgeo.org:443> GRASS Subversion
> Repository
>  Password for 'warmerda':
>  Authentication realm: <https://svn.osgeo.org:443> GRASS Subversion
> Repository
>  Username: warmerdam
>  Password for 'warmerdam':
>  SendingMakefile
>  Transmitting file data .
>  Committed revision 30992.
>
>  Forgive me for the rather pointless commit.
>
>
>  Best regards,
>  --
> ---+--
>  I set the clouds in motion - turn up   | Frank Warmerdam,
> [EMAIL PROTECTED]
>  light and sound - activate the windows | http://pobox.com/~warmerdam
>  and watch the world go round - Rush| President OSGeo, http://osgeo.org
>
>


-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] SVN error in Add-Ons

[Yann Chemin]

OK,

that must be something in this line that happened,
I do not record all the time if such software gets upgraded.

I'll check that up after work today,
Thanks for the help !
Yann

On 15/04/2008, Glynn Clements <[EMAIL PROTECTED]> wrote:
>
>  Yann Chemin wrote:
>
>  > I tried a fresh check out and it seems that it runs into the same 
> problem...
>  >
>  > # svn co https://svn.osgeo.org/grass/grass-addons/
>  > svn: Unrecognized URL scheme for 'https://svn.osgeo.org/grass/grass-addons'
>  > #
>  >
>  > I suppose that svn got allergic to https as you suggested, but I did
>  > not see that subversion got upgraded recently in my box... Definitely
>  > not while I was working.
>
>
> Note that the svn libraries rely upon the Neon library for HTTP/WebDAV
>  access, which in turn relies upon OpenSSL for SSL.
>
>  It's possible that the problem could be caused by an update to either
>  of those libraries, or a configuration change for OpenSSL (Neon
>  doesn't appear to have any configuration).
>
>
>  --
>  Glynn Clements <[EMAIL PROTECTED]>
>


-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] grass 7 and pixel random access

[Yann Chemin]

Hello list,

I would like to know the planned changes for the raster library,
especially the random access of pixels in the raster.

I wanted to work on it some months back, but my daily job got more intense.
In the coming future, we will need to access easily any row for
parallel processing.

Thanks,
Yann

-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] r.terraflow flow direction rules

[Yann Chemin]

Hello,

I need to route VIC hydrological model, and the routing program read
AGNPS style flow direction.
I tried to run r.watershed on my srtm watershed, and after a week, I
just stopped it,
because I needed the PC for other processing.
(it was doing it, but slower and slower as it passed 60% in 3 days,
65% in 4 days etc...)

Now I am getting onto r.terraflow for flow direction,
but what i need is AGNPS output,
what is the flow direction type in r.terraflow format please.

Thank you
Yann

-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Fwd: [GRASS-dev] grass 7 and pixel random access

[Yann Chemin]

2008/4/28 Yann Chemin <[EMAIL PROTECTED]>:
> We have experimented a bit with parallel processing, and for a given
>  processor power, there is a minimum amount of operations on a pixel
>  that needs to be done before there is any time benefit of using
>  parallelization. I would also believe that multi-core parallelization
>  (OpenMP: easy to code in most of the case) would benefit earlier that
>  multi-cpus (MPICH: requires some stronger preparation about coding),
>  for the physical reason of transport distance of bits.
>
>  I honestly would not know at which "level" we should integrate
>  parallelization capacities, it would be great indeed to have the
>  library understand a direct row loop and choose to split the loop by
>  the number of core/cpus available, if we speak about direct raster
>  processing. This would mean, potentially every direct raster
>  processing module could benefit, if they actually need it (which is
>  the main question, actually).
>
>  Now many processing in raster (and vector) may now be parallelized
>  straight-forwardly. And this is the main thing, we often face complex
>  algorithms, those ones are connecting pixels together from places to
>  places in the map (i.e. interpolation), those required taylor-made
>  parallelization. Here we should need tools to ease the task of
>  parallelization of those complex systems.
>
>  Finally, the codes I am working on are mostly pixel-based, either
>  temporal signal processing, energy-balance, adata assimilation of 1-D
>  vertical models, some take minutes, some hours/days, and some may go
>  up to a month (i dont run those last ones, I am waiting for CPU
>  improvement). So I would benefit directly by anything even just
>  running half of the raster on each core of my dual-core laptop/desktop.
>
>  Well, I am sure there are more experienced people on this list about
>  parallelization, so I am waiting for comments.
>
>  Yann
>
>  2008/4/28 Hamish <[EMAIL PROTECTED]>:
>
>
> > > Yann Chemin wrote:
>  >  > >  I would like to know the planned changes for the raster library,
>  >  > >  especially the random access of pixels in the raster.
>  >  Markus:
>  >
>  > > Not sure if all of those are actually planned, but here is a list:
>  >  > http://grass.osgeo.org/wiki/GRASS_7_ideas_collection#Raster
>  >  >
>  >  > >  I wanted to work on it some months back, but my daily job got more
>  >  > >  intense.
>  >  > >  In the coming future, we will need to access easily any row for
>  >  > >  parallel processing.
>  >
>  >
>  >  One thing I wonder about for parallel processing of (serial) raster
>  >  modules- do we really need random read access to send each individual row
>  >  into a separate thread? The overhead with that seems counter-productive.
>  >  Couldn't we read some GRASS_NPROC envrio variable and then split the
>  >  overall number of rows by that number and create a small number of
>  >  threads, ie matching the system.
>  >
>  >
>  >  like: ceil(rows/nproc)
>  >  nproc=4
>  >  rows=1035
>  >  chunk size=259
>  >
>  >
>  >  the last thread reads/processes/writes fewer rows than the others as it
>  >  finds the EOF.
>  >
>  >
>  >
>  >  another thing I still wonder about (see thread from a month or so back)
>  >  is  where to start? Modify the libs to support the concept, then tackle
>  >  each module on their own? ie concentrate on the non-I/O limited and
>  >  can't-do- much-about-it but throw more processor at the problem modules,
>  >  and leave non-number crunching modules alone? -- concentrate on areas
>  >  where we'll get the most bang for the buck / pick off low hanging fruit /
>  >  etc?
>  >
>  >
>  >  Hamish
>  >  (showing off his multi-proc naivet'e)
>  >
>  >
>  >
>  >
>  >   
> 
>  >  Be a better friend, newshound, and
>  >  know-it-all with Yahoo! Mobile.  Try it now.  
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>  >
>  >
>  >
>  >  ___
>  >  grass-dev mailing list
>  >  grass-dev@lists.osgeo.org
>  >  http://lists.osgeo.org/mailman/listinfo/grass-dev
>  >
>
>
>
>
>
> --
>  Yann Chemin
>  International Rice Research Institute
>  Office: http://www.irri.org/gis
>  Perso: http://www.freewebs.com/ychemin
>



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] c code: access region/window yllcorner and xllcorner values

[Yann Chemin]

Hello,

I am trying make a module to (among other things) export a flow
direction map in a specific ascii format.

I need to access the region or window xllcorner and yllcorner, right now,
the only code I found was to access cellhd.xxx variables:

 xmin=cellhd.west;
 xmax=cellhd.east;
 ymin=cellhd.south;
 ymax=cellhd.north;

which is not exactly my need since the xllcorner and yllcorner are
going to be part of the header of the new ascii file, where pixels
will be extracted from within the region limits.

I looked at G_window_* but no luck...
Any suggestions would be much appreciated,

Yann

-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS 7 raster coding best practices

[Yann Chemin]

Hi list,

I would like to open a discussion, hopefully quite short about
clean/short raster programming.

There are few things appearing that are nice coding practices, of
course I believe r.example exists, but it is not exhaustive, well it
is not intended to be anyway.

  /* Define the different options */
  input1  = G_define_standard_option(G_OPT_R_INPUT) ;
  input1->key   = _("albedo");
  input1->description  =_("Name of the Albedo map [0.0-1.0]");
  input1->answer =_("albedo");
  input1->guisection   = _("Required");

In here you can find G_define_standard_option(G_OPT_R_INPUT) assuming
already those:
input1->type   = TYPE_STRING;
input1->required   = YES;
input1->gisprompt  =_("old,cell,raster") ;

If your input is not required to run the module, you just create the
following line:
   input1->required   = NO;


Same goes for G_OPT_R_OUTPUT, but I could not find it for parameters
in float format (G_OPT_F_INPUT?) for example...


In another module (r.slope.aspect), I found an interesting code opennew():
#include 
#include 
#include 
int opennew (char *name, RASTER_MAP_TYPE wr_type){
int fd;
if (G_legal_filename (name) < 0)
G_fatal_error (_("<%s> is an illegal file name"), name);
if(wr_type < 0) /* default fp type */
   fd = G_open_fp_cell_new (name);
else
   fd = G_open_raster_new (name, wr_type);
if (fd < 0)
G_fatal_error (_("Failed in attempt to open %s"), name);
return fd;
}

Sorry, i squashed it a bit for the email.
Well, this could be interesting to also include a similar code in main GRASS,
so we could reduce some coding length and ultimately clarify it.

In a similar way, metadata/history storage:


G_short_history(result1, "raster", &history);
G_command_history(&history);
G_write_history(result1,&history);

This is the standard incantation, but I have to find timestamp(), and
more details metadata maybe like sensor type for a start, or
source/origin of data... Can we make metadata having elements
(history->processing, history->timestamp, history->source(or
history->origin), etc?) then it could be filled up specifically.

Or color palettes application, discovered this recently, it is nice:

  /* Color table for biomass */
G_init_colors(&colors);
G_add_color_rule(0,0,0,0,1,255,255,255,&colors);

I don't deny it, it must be there, I just would like to get things
together and identify what best (i.e. clean/complete/nice) coding I
can implement as a standard on the modules I work on...

Are there other gems hidden that we could simply list or make a more
exhaustive r.example2?

Thanks for your comments and suggestions,
Yann

-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7 raster coding best practices

[Yann Chemin]

2008/5/4 Glynn Clements <[EMAIL PROTECTED]>:
>
>  Yann Chemin wrote:
>
>  > Same goes for G_OPT_R_OUTPUT, but I could not find it for parameters
>  > in float format (G_OPT_F_INPUT?) for example...
>
>  Huh? What would be the settings for such an option?
>
   input = G_define_option(G_OPT_F(D?)_INPUT) ;
   input->key=_("parameter");
   input->type   = TYPE_DOUBLE;
   input->required   = YES;
   input->gisprompt  =_("value, parameter");
   input->description=_("Value of the parameter");
   /*input->answer =_("0.000");*/
   input->guisection = _("Required");

I could also think similarly for non-GRASS files actually
(configuration files sometimes need to be loaded separately, i.e.
i.atcorr, btw I cant find it anymore in grass70).

>
>  > In another module (r.slope.aspect), I found an interesting code opennew():
>  > #include 
>  > #include 
>  > #include 
>  > int opennew (char *name, RASTER_MAP_TYPE wr_type){
>  > int fd;
>  > if (G_legal_filename (name) < 0)
>  > G_fatal_error (_("<%s> is an illegal file name"), name);
>  > if(wr_type < 0) /* default fp type */
>  >fd = G_open_fp_cell_new (name);
>  > else
>  >fd = G_open_raster_new (name, wr_type);
>  > if (fd < 0)
>  > G_fatal_error (_("Failed in attempt to open %s"), name);
>  > return fd;
>  > }
>  >
>  > Sorry, i squashed it a bit for the email.
>  > Well, this could be interesting to also include a similar code in main 
> GRASS,
>  > so we could reduce some coding length and ultimately clarify it.
>
>  I'm not sure that the above warrants a separate function.
>
>  First, the G_legal_filename() call is redundant; G_open_*_new()
>  already contain that check.
>
>  Second, I would prefer it if G_open_*_new() simply called
>  G_fatal_error() themselves if an error occured. It's not as if there's
>  any reasonable alternative way to handle the error.
>

Yes, +1 for this.

>  --
>  Glynn Clements <[EMAIL PROTECTED]>
>



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7 raster coding best practices

[Yann Chemin]

2008/5/4 Hamish <[EMAIL PROTECTED]>:
> Yann Chemin wrote:
>  > > I could not find it for parameters in float format (G_OPT_F_INPUT?)
>
>  lib/gis/parser.c already defines G_OPT_F_* for input and output files,
>  and field separators for those files. Don't use that for floating point
>  input values.

  OK, good, so not G_OPT_F_*.
>
>  > > for example...
>  ...
>
> >input = G_define_option(G_OPT_F(D?)_INPUT) ;
>  >input->key=_("parameter");
>  >input->type   = TYPE_DOUBLE;
>  >input->required   = YES;
>  >input->gisprompt  =_("value, parameter");
>  >input->description=_("Value of the parameter");
>  >/*input->answer =_("0.000");*/
>
>
>  the only thing I see there that is a candidate for reuse as part of a
>  default macro is input->type=TYPE_DOUBLE. The others are all module
>  option dependent, e.g. "input->key =_("parameter");" is vague enough to
>  be useless in practice.
>
>  input->gisprompt is wrong, have a look at the GRASS 5 programmers manual
>  for a nice write up about what that is for (maybe in the GRASS 6 one too,
>  I'm not sure)

   Do you have a link to this one please?

>
>
>  >input->guisection = _("Required");
>
>  FWIW I consider this to be redundant noise. If it is wished that the
>  module GUI(s) group required options in the first tab then they should
>  extract that from the input->required field.
>
>

  Can you provide an example of filling in input->required, that would
be nice to add.

>
>  Hamish
>
>
>
>
>
>
>   
> 
>  Be a better friend, newshound, and
>  know-it-all with Yahoo! Mobile.  Try it now.  
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
>



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7 raster coding best practices

[Yann Chemin]

>  > > >input->guisection = _("Required");
>  > >
>  > >  FWIW I consider this to be redundant noise. If it is wished that the
>  > >  module GUI(s) group required options in the first tab then they
>  > >  should extract that from the input->required field.
>  >
>  > Can you provide an example of filling in input->required, that would
>  > be nice to add.
>
>  ?
>  you already have it above; =YES or =NO.
>
>

OK, a small misunderstanding here, some small examples.

input->guisection will create a Tab in the GUI with the name given to it.

input->guisection = _("Required");
input->guisection = _("Optional");
input->guisection = _("Set of functions 1");
input->guisection = _("Parameters for output2");

on the other hand,
input->required=YES
forbids the code to run on empty "input"


-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7 raster coding best practices

[Yann Chemin]

OK, if I get it right,

input->required=YES
is the same as:
input->guisection=_("Required")

therefore the second line is useless.
In the same way, is the following identical too?

input->required=NO
is it the same as below?
input->guisection=_("Optional")

Thanks for the links on the other topics,
I will start reading them.

Yann

2008/5/4 Hamish <[EMAIL PROTECTED]>:
> Yann Chemin:
>
> > OK, a small misunderstanding here, some small examples.
>  >
>  > input->guisection will create a Tab in the GUI with the name given to
>  > it.
>  >
>  > input->guisection = _("Required");
>  > input->guisection = _("Optional");
>  > input->guisection = _("Set of functions 1");
>  > input->guisection = _("Parameters for output2");
>  >
>  > on the other hand,
>  > input->required=YES
>  > forbids the code to run on empty "input"
>
>
>  yes, the above is correct, just note that this is meaningless, other than
>  to group that option in a tab by that name:
>   input->guisection = _("Required");
>
>  (and thus that is confusing+redundant and shouldn't be used IMHO)
>
>
>
>
>  Hamish
>
>
>
>
>   
> 
>  Be a better friend, newshound, and
>  know-it-all with Yahoo! Mobile.  Try it now.  
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
>



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] call for sample dataset: r.hydro.CASC2D

[Yann Chemin]

Hi,

I would like to test a bit more r.hydro.CASC2D with GRASS-7.0-SVN code,
does anybody have a sample dataset sleeping somewhere that is known to
work well with that module?

Thanks,
Yann

-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] dealing with nan

[Yann Chemin]

Hello,

I have some data that reads as "nan", while rare, it may happen when
compressing/uncompressing GRASS Locations to ship them across
Internet.

I would like to know how to deal with them in GRASS raster
programming, so that they are:
1 - detected
2 - set to null

thank you,
Yann

-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] dealing with nan

[Yann Chemin]

2008/5/19 Glynn Clements <[EMAIL PROTECTED]>:

>
> Yann Chemin wrote:
>
> > I have some data that reads as "nan", while rare, it may happen when
> > compressing/uncompressing GRASS Locations to ship them across
> > Internet.
> >
> > I would like to know how to deal with them in GRASS raster
> > programming, so that they are:
> > 1 - detected
> > 2 - set to null
>
> if (x != x)
>G_set_d_null_value(&x, 1);
>

Sounds simple enough.


>
> There is also isnan(), which is in C99, and also specified by POSIX:
>
>http://www.opengroup.org/onlinepubs/009695399/functions/isnan.html
>
> However, I don't know if it exists on all platforms which we care
> about. MSDN says that MSVCRT has _isnan() (with a leading underscore),
> but it's defined in  rather than .
>

hmm... ok



>
> The (x != x) test should be portable; OTOH, it's the kind of thing
> that compilers often get wrong, particularly when optimising (if you
> ignore NaN, x!=x is always false).
>

OK, this is a pickle... I'll give it a try and see what it does here.


>
> For 7.0, I intend to change G_is_[fd]_null_value() to treat all NaN
> values as null, not just the specific bit patterns which it currently
> uses.
>

This would be good indeed.


>
> --
> Glynn Clements <[EMAIL PROTECTED]>
>



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] dealing with nan

[Yann Chemin]

2008/5/19 Hamish <[EMAIL PROTECTED]>:

> > Yann Chemin wrote:
> > > I have some data that reads as "nan", while
> > > rare, it may happen when compressing/uncompressing
> > > GRASS Locations to ship them across Internet.
>
> what method are you using to compress/decompress?
> ..zip? .tar.gz? r.pack/r.unpack?
>

Windows zip, ftp download across the World, then Linux unzip.



>
> if r.pack I think it is safer to use the script in the trac wish patches
> which converts GRASS <=6 raster dir layout to proposed GRASS 7
> $MAPSET/raster/$NAME/element) then tarball up the map's dir, and vice versa.
> I should probably update r.pack not to use r.{in|out}.mat as that will lose
> some metadata for sure.
>

We will use r.[,un]pack that from now on.


>
>
> places in the code to look for accidental creation of nan:
> - (x/y) where both the x and y variables could sometimes be 0.
> - tan(pi/2)
> - r.in.mat/r.out.mat use Matlab's NaN to store grass NULLs
> - GRASS nulls + non-core libgis functions meet mixed endian (?)
> - ?
>

hmm, tan() is a suspect here. x==y==0 may also be, shall put tests but more
complex.


>
>
> > > I would like to know how to deal with them in GRASS
> > > raster programming, so that they are:
> > > 1 - detected
> > > 2 - set to null
>
> Glynn:
> >   if (x != x)
> >   G_set_d_null_value(&x, 1);
> >
> > There is also isnan(), which is in C99, and also specified
> > by POSIX:
> >
> >   http://www.opengroup.org/onlinepubs/009695399/functions/isnan.html
> >
> > However, I don't know if it exists on all platforms
> > which we care about. MSDN says that MSVCRT has _isnan() (with a
> > leading underscore), but it's defined in  rather than
> > .
> >
> > The (x != x) test should be portable; OTOH, it's the
> > kind of thing that compilers often get wrong, particularly when
> > optimising (if you ignore NaN, x!=x is always false).
>
>
> there is a longstanding wish that 'r.null setnull=' could understand nan,
> so that you could get rid of them. e.g. very rarely r.in.xyz will create
> them, I am not sure why/how.
>

would be useful to make coloring of output maps appear... right now nan
intefers in the standard colors setup, it seems.


>
>
> > For 7.0, I intend to change G_is_[fd]_null_value() to treat
> > all NaN values as null, not just the specific bit patterns which
> > it currently uses.
>
> the only reason I could see to keep them as nan not grass-NULL would be for
> debugging (there is obviously a bug if you get them..).
>
>
> Hamish
>
>
>
>
>
>


-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] dealing with nan

[Yann Chemin]

2008/5/19 Hamish <[EMAIL PROTECTED]>:

> Hamish:
> > > what method are you using to compress/decompress?
> > > ..zip? .tar.gz? r.pack/r.unpack?
>
> Yann Chemin wrote:
> > Windows zip, ftp download across the World, then Linux
> > unzip.
> ...
> > > if r.pack I think it is safer to use the script in the
> > > trac wish patches which converts GRASS <=6 raster dir layout to
> > > proposed GRASS 7 $MAPSET/raster/$NAME/element) then tarball up
> > > the map's dir, and vice versa.
> > > I should probably update r.pack not to use r.{in|out}.mat as that
> > > will lose some metadata for sure.
> >
> > We will use r.[,un]pack that from now on.
>
> I meant that r.pack as it is now may be lossy, and "r.convert" + "tar czf"
> may be a safer way:
>  http://trac.osgeo.org/grass/ticket/84
>
> (feel free to try, but be warned)
>
>
Oh! Excuse my Frenglish, ok got the point.


>
> Hamish
>
>
>
>
>
>


-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS-user] Is it i.albedo or r.albedo?

[Yann Chemin]

Hi again Hamish,

Thanks for the Makefile suggestions, I will try Makefile.gipe, it is
closer to actual method.

I have updated the wiki, but it is still not reflecting all new things in GIPE.

I have been checking up gem a year or so ago,
but I found out more useful to concentrate on making GIPE modules more robust.
Still I am full in making it all work.

Any suggestions from people about how to manage such thing is more than welcome.
Yann



2008/6/2 Hamish <[EMAIL PROTECTED]>:
> We should cc/move this thread to grass-dev for other eyes...
>
>
> Hamish:
>> > Better just to have a gipe Makefile which includes all
>> > gipe modules and nothing else.
>
> Yann Chemin wrote:
>> I am OK to do so, but how can it be run in imagery/ or in
>> raster/, since there is already a Makefile in those places?
>
> I can think of two ways:
> 1) keep gipe i.* and r.* modules in their own gipe/ dir in the grass source 
> tree, then run "make" in the gipe/ dir to make them all.
>
> 2) If you feel you must mix the gipe modules into grass raster/ and imagery/ 
> source code dirs, add a new file called Makefile.gipe with just gipe modules, 
> then "make -f Makefile.gipe" to use the alternate Makefile name.
>
>
> Did you get anywhere with using GEM? I am not sure how that has it organized 
> but I assume it has worked out some way. As Gipe grows it becomes more and 
> more a addon enhancement package rather than just some nice collection of 
> modules.
>
>
> regards,
> Hamish
>
>
>
>
>
>
>



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] G_OPT_R_INPUT broken in svn

[Yann Chemin]

Hi,

in the latest svn, G_OPT_R_INPUT does not provide with a raster
listing of available raster layers in the current mapset,
in tcltk gui, it does not have the raster icon, but instead, it has
the sign > on the button


-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] svn: undefined symbol G_gisinit

[Yann Chemin]

Hello,

some modules are complaining about this since this morning SVN:

i.eb.rohair: symbol lookup error: i.eb.rohair: undefined symbol: G_gisinit

I have made a clean install and still same.
(make distclean; ./conf.; make -j4 ; make install)



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] svn: undefined symbol G_gisinit

[Yann Chemin]

Thanks,
I'll do that now.
Yann

2008/6/6 Markus Neteler <[EMAIL PROTECTED]>:
> On Fri, Jun 6, 2008 at 11:28 AM, Yann Chemin <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> some modules are complaining about this since this morning SVN:
>>
>> i.eb.rohair: symbol lookup error: i.eb.rohair: undefined symbol: G_gisinit
>>
>> I have made a clean install and still same.
>> (make distclean; ./conf.; make -j4 ; make install)
>
> I have tried to compile with
> make MODULE_TOPDIR=$HOME/grass64/
>
> and it worked. Maybe you have some leftover old lib in
> your LD_LIBRARY_PATH? Maybe "ldd" can tell you
> where it is...
>
> Markus
>



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] storing full script as metadata

[Yann Chemin]

Hello,

Just wanted to keep exact track of the processing leading to a new layer.

1 - would it be feasible to store the whole processing line with
parameters (i.e. r.something -a input=file_in output-file_out etc...)
as metadata in the output file of a module ?

2 - would it be interesting to make a scripts/ place inside a mapset
where scripts would get automatically saved with something like:
MMMDDH_MODULE_NAME.sh or the like?

just an idea.
Yann

-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] storing full script as metadata

[Yann Chemin]

2008/6/9 Glynn Clements <[EMAIL PROTECTED]>:
>
> Yann Chemin wrote:
>
>> Just wanted to keep exact track of the processing leading to a new layer.
>>
>> 1 - would it be feasible to store the whole processing line with
>> parameters (i.e. r.something -a input=file_in output-file_out etc...)
>> as metadata in the output file of a module ?
>
> G_command_history() already does this, i.e. it appends the result of
> G_recreate_command() to the history.
>

G_recreate_command()
OK I'll look into it.

>> 2 - would it be interesting to make a scripts/ place inside a mapset
>> where scripts would get automatically saved with something like:
>> MMMDDH_MODULE_NAME.sh or the like?
>
> I'm not sure what you're suggesting here.
>
> GRASS (the libraries and modules) only knows which commands are run;
> it doesn't know *how* they are run, e.g. if they are part a script, if
> they were typed into the shell, executed by the GUI, etc.
>

well, since G_recreate_command passed it into the metadata,
I guess already that is good.
I was thinking more of a kind of "command log", but with time-based
separation of commands used in txt files.
Whether they are stored inside a mapset would just be convenient.

thanks
Yann

> --
> Glynn Clements <[EMAIL PROTECTED]>
>



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS FFMPEG support

[Yann Chemin]

Hi Marco,

I have also recently tried to include ffmpeg in my compilations (Linux
Debian - Sid) and you have to configure with --with-ffmpeg, this will
tell GRASS to count on ffmpeg libs (indeed they seems to be libavcodec
and libavutil as part of ffmpeg and they seem to be checked by
configure).

However I was unsuccessful so far to have configure accept it.
I even tried --with-ffmpeg-includes=/usr/include/ffmpeg

I hope some other people are having enlightenment.
Yann

2008/6/11  <[EMAIL PROTECTED]>:
> Hi all,
>
> I'm building ffmpeg on windows through MinGW; standard build went
> succesfully, but I have some doubts: what does GRASS need to enable ffmpeg
> support in it?
>
> I built ffmpeg enabling shared and disabling static libraries, but enabling
> shared produces only libavutil, libavcodec and libavformat as DLLs, and not
> a ffmpeg DLL, as I roughly expected (I checked on the official ffmpeg web
> site, that's normal, there is any ffmpeg.dll mentioned)
>
> Any suggestions?
>
> Thanks,
>
> Marco
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] cell_misc

[Yann Chemin]

Hello,

I am generating 60,000 maps from 60,000 original ones
 (shell script looping r.mapcalc),

it says unable to create mapset element cell_misc $filename

Since it is a (very) long process, I would like to know if I should stop it now,
or if it is not impacting of maps and data?

Thanks,
Yann

-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] cell_misc

[Yann Chemin]

2008/6/13 Hamish <[EMAIL PROTECTED]>:
> Yann Chemin wrote:
>> I am generating 60,000 maps from 60,000 original ones
>>  (shell script looping r.mapcalc),
>>
>> it says unable to create mapset element cell_misc $filename
>
> cell_misc/ saves each map's data in a subdirectory, not a file like the other 
> raster element directories.  is this in a ext3 partition?

yes it is ext3

>
> can you break it up into mapsets of ~ 10k maps each, linked by g.mapsets 
> search path? (thus < 32768 subdirectories/cell_misc)

I would want to avoid doing that since I need to use the data (it is
TRMM) in r.hydro.CASC2D, and it reads straight a filename to which it
adds .

Of course I could do it yearly and save parameters (eventually I may
have to do that...)

>
>> Since it is a (very) long process, I would like to know if
>> I should stop it now, or if it is not impacting of maps and
>> data?
>
> I think NULL data will be missing, if that is important to you.

Not important at all

> is it possible to stop where you are now and modify the script to restart it 
> where it left off? or are later steps dependent on earlier?
>

yes it is possible to stop and restart (chronological datasets) even
at a different YYYMMDDHH

> it is sometimes nice to write variables to a small text file or so as it runs 
> so you can "reseed" the second half of the calculation from an arbitrary 
> point without having to rerun the first.
>
>

Yeah, I may have to do a yearly mapset structure, which would be ~5000
images (1/2 original, 1/2 processed)

> ?
> Hamish
>

Thanks Hamish



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass6_devel, problems to find gdal library

[Yann Chemin]

same error on Debian/Sid for a couple of days now.

2008/7/4 Massimo Di Stefano <[EMAIL PROTECTED]>:
> Hi
>
> i'm tring to update grass from svn, on osx .
>
> the configure find gdal-config
> but fail to find gdal libraries
> 
> .
> ..
> checking for location of JPEG includes...
> /Library/Frameworks/UnixImageIO.framework/unix/include
> checking for jpeglib.h... yes
> checking for location of JPEG library...
> /Library/Frameworks/UnixImageIO.framework/unix/lib
> checking for jpeg_start_compress in -ljpeg... yes
> checking whether to use GDAL... yes
> checking for gdal-config...
> /Library/Frameworks/GDAL.framework/Programs/gdal-config
> configure: error: *** Unable to locate GDAL library.
>
> using the same configure (and the same gdal libraries)
> on the svn code downloaded 2 weeks ago
> (i don't know how to check  the exact release it is),
>
> it works as aspected
> thanks for any suggestion,
> regards
>
> Massimo Di Stefano.
> Chiacchiera con i tuoi amici in tempo
> reale!http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass6_devel, problems to find gdal library

[Yann Chemin]

config.log
-
configure:7599: checking whether to use GDAL
configure:7612: checking for gdal-config
configure:7677: gcc -o conftest -g -O2-Wl,--export-dynamic
conftest.c  -L/usr/lib -lgdal1.5.0 1>&5
configure:7671:18: error: gdal.h: No such file or directory
configure: In function 'main':
configure:7673: error: 'GA_ReadOnly' undeclared (first use in this function)
configure:7673: error: (Each undeclared identifier is reported only once
configure:7673: error: for each function it appears in.)
configure: failed program was:
#line 7670 "configure"
#include "confdefs.h"
#include 
int main() {
GDALOpen("foo", GA_ReadOnly);
; return 0; }
configure:7693: gcc -o conftest -g -O2-Wl,--export-dynamic
conftest.c  -L/usr/lib -lgdal1.5.0 -L/usr/lib -lgeos_c -I/usr/include
-lsqlite3 -lodbc -lodbcinst -L/usr/lib -lexpat -L/usr/lib -lxerces-c
-lpthread -ljasper -lhdf5 -lmfhdf -ldf -logdi -lgif -ljpeg -ltiff
-lpng -lnetcdf -lpq -L/usr/lib -lpq -lz -lpthread -lm -lrt -ldl -lcurl
-L/usr/lib/mysql -lmysqlclient 1>&5
configure:7687:18: error: gdal.h: No such file or directory
configure: In function 'main':
configure:7689: error: 'GA_ReadOnly' undeclared (first use in this function)
configure:7689: error: (Each undeclared identifier is reported only once
configure:7689: error: for each function it appears in.)
configure: failed program was:
#line 7686 "configure"
#include "confdefs.h"
#include 
int main() {
GDALOpen("foo", GA_ReadOnly);
; return 0; }


locate gdal.h returns: /usr/include/gdal/gdal.h

Added in configure options:
--with-includes=/usr/include/gdal

and it compiled properly
Thanks Glynn
Yann


2008/7/5 Glynn Clements <[EMAIL PROTECTED]>:
>
> Massimo Di Stefano wrote:
>
>> i'm tring to update grass from svn, on osx .
>>
>> the configure find gdal-config
>> but fail to find gdal libraries
>> 
>> .
>> ..
>> checking for location of JPEG includes... /Library/Frameworks/
>> UnixImageIO.framework/unix/include
>> checking for jpeglib.h... yes
>> checking for location of JPEG library... /Library/Frameworks/
>> UnixImageIO.framework/unix/lib
>> checking for jpeg_start_compress in -ljpeg... yes
>> checking whether to use GDAL... yes
>> checking for gdal-config... /Library/Frameworks/GDAL.framework/
>> Programs/gdal-config
>> configure: error: *** Unable to locate GDAL library.
>
> Look in config.log for the command which fails and any error messages
> which it generates.
>
> --
> Glynn Clements <[EMAIL PROTECTED]>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] grass behavior: pixel value from a different resolution

[Yann Chemin]

Hello,

could somebody tell me how GRASS chooses a value when your g.region
settings make you operate at a pixel size larger than the original
data.

i.e. I am working in 250m res but my SRTM original data is 90m.

How GRASS will choose/calculate the value to use?

corollary:
how to export with r.out.gdal an identical map as the one GRASS would
use at 250m.

thank you,
Yann

-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
---
Opportunities are usually disguised as hard work,
so most people don't recognize them.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] g.region -g crashes in a latlon location

[Yann Chemin]

I also have g.region -p crashing for about 2 weeks, cannot run tcltk
GUI and wxpython GUI because of that.

it does not say anything, on the segfault sentence...


2008/7/21 Maciej Sieczka <[EMAIL PROTECTED]>:
> Glynn Clements pisze:
>>
>> Maciej Sieczka wrote:
>
>>> I have just noticed that g.region -g or -p crashes in a latlon
>>> location. Example:
>
>>> 0x7f33d130f69e in sincos (val=0.90594848802138783,
>>> sin_val=0x7fffda923030, cos_val=0x7fffda923028) at GDapi.c:6265 6265
>>>  *sin_val = sin(val); (gdb) bt #0  0x7f33d130f69e in
>>> sincos (val=0.90594848802138783, sin_val=0x7fffda923030,
>>> cos_val=0x7fffda923028) at GDapi.c:6265 #1  0x7f33d130f6a3 in
>>> sincos (val=0.90594848802138783, sin_val=0x7fffda923060,
>>> cos_val=0x7fffda923058) at GDapi.c:6265 #2  0x7f33d130f6a3 in
>>> sincos (val=0.90594848802138783, sin_val=0x7fffda923090,
>>> cos_val=0x7fffda923088) at GDapi.c:6265
>
>>> (The whole backtrace is all very long.)
>
>> When you say "very long", is it actually finite? Or did you give up before
>> reaching the end?
>
> The latter. After reaching line #5473 in gdb I gave up.
>
>> Because the line which the debugger shows:
>
>>> 6265*sin_val = sin(val);
>
>> doesn't appear to be a recursive call, but the backtrace indicates an
>>  infinite "direct" recursion (i.e. the function calls itself with exactly
>> the same arguments).
>>
>> My guess is that the saved frame pointer is actually pointing to the
>> current frame, i.e. a linked list where "p->next == p".
>>
>> In any case, this doesn't help identify the real problem. Can you
>> step through the g.region code from the beginning and find where in
>> g.region (or the GRASS libraries) that it's going out of control?
>
> If you can tell how to do it I'd try.
>
> Can you reproduce the crash? Anybody else?
>
> Maciek
>
> P.S.
>
> Here's GRASS debug output. Maybe it helps some:
>
> D2/10: G__read_Cell_head
> D2/10: G__read_Cell_head_array
> D3/10: region item: proj:   3
> D3/10: region item: zone:   0
> D3/10: region item: north:  51N
> D3/10: region item: south:  50N
> D3/10: region item: east:   16E
> D3/10: region item: west:   15E
> D3/10: region item: cols:   1
> D3/10: region item: rows:   1
> D3/10: region item: e-w resol:  1
> D3/10: region item: n-s resol:  1
> D3/10: region item: top:1
> D3/10: region item: bottom: 0
> D3/10: region item: cols3:  1
> D3/10: region item: rows3:  1
> D3/10: region item: depths: 1
> D3/10: region item: e-w resol3: 1
> D3/10: region item: n-s resol3: 1
> D3/10: region item: t-b resol:  1
> D3/10: G_adjust_Cell_head: epsilon_ns: 0.001, epsilon_ew: 1e-06
> D2/10: G__read_Cell_head
> D2/10: G__read_Cell_head_array
> D3/10: region item: proj:   3
> D3/10: region item: zone:   0
> D3/10: region item: north:  52:00:01.5N
> D3/10: region item: south:  50:59:58.5N
> D3/10: region item: east:   17:00:01.5E
> D3/10: region item: west:   14:59:58.5E
> D3/10: region item: cols:   2401
> D3/10: region item: rows:   1201
> D3/10: region item: e-w resol:  0:00:03
> D3/10: region item: n-s resol:  0:00:03
> D3/10: region item: top:1
> D3/10: region item: bottom: 0
> D3/10: region item: cols3:  2401
> D3/10: region item: rows3:  1201
> D3/10: region item: depths: 1
> D3/10: region item: e-w resol3: 0:00:03
> D3/10: region item: n-s resol3: 0:00:03
> D3/10: region item: t-b resol:  1
> D3/10: G_adjust_Cell_head: epsilon_ns: 8.32639e-07, epsilon_ew: 1e-06
> D3/10: G_adjust_Cell_head: epsilon_ns: 8.32639e-07, epsilon_ew: 1e-06
> Segmentation fault
>
> --
> Maciej Sieczka
> www.sieczka.org
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] g.region -g crashes in a latlon location

[Yann Chemin]

This is on my system:
857 print_window (&window, print_flag);
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0x7f13a64e5a7e in sincos () from /usr/lib/libgdal1.5.0.so.1

break print_window gives:

(gdb)
37  ew_dist1 =
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0x7fda5b45ca7e in sincos () from /usr/lib/libgdal1.5.0.so.1

break G_distance gives:

Breakpoint 3, G_distance (e1=25.07581429527, n1=41.64570967638889,
e2=21.94686178889,
n2=41.64570967638889) at distance.c:84
84  {
(gdb)
85  if (projection == PROJECTION_LL)
(gdb)
G_distance (e1=25.07581429527, n1=41.64570967638889, e2=21.94686178889,
n2=41.64570967638889) at distance.c:86
86  return G_geodesic_distance (e1, n1, e2, n2);
(gdb)
0x7f4f967239d8 in [EMAIL PROTECTED] () from
/usr/local/grass-7.0.svn/lib/libgrass_gis.so
Current language:  auto; currently asm
(gdb)
Single stepping until exit from function [EMAIL PROTECTED],
which has no line number information.
0x7f4f96722ba8 in ?? () from /usr/local/grass-7.0.svn/lib/libgrass_gis.so
(gdb)
Cannot find bounds of current function
(gdb)

hope this helps
yann

2008/7/22 Maciej Sieczka <[EMAIL PROTECTED]>:
> Glynn Clements pisze:
>
>> Below that, there isn't actually anything which can cause a segfault.
>>  So, it's very much looking like a broken system.
>
> Gotcha! I'm using GCC 4.3.1 on amd64 Debian testing. Apparently it
> doesn't like GRASS default optimisation flags "-g -O2". When I override
> them it with e.g. "-pipe" alone, the segfault is gone.
>
> On another machine (Ubuntu Gutsy amd64) where GCC is 4.1.3, "-g -O2" has
> no side effects.
>
> Should GRASS enforce any optimisation flags by default?
>
> Maciek
>
> --
> Maciej Sieczka
> www.sieczka.org
>



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] g.region -g crashes in a latlon location

[Yann Chemin]

wow...
ok then we have to get to GDAL dev list about that...?
Yann

2008/7/22 Glynn Clements <[EMAIL PROTECTED]>:
>
> Yann Chemin wrote:
>
>> This is on my system:
>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x7fda5b45ca7e in sincos () from /usr/lib/libgdal1.5.0.so.1
>
> Whoah; GDAL?
>
> sincos() is defined in libm:
>
>   void sincos(double x, double *sin, double *cos);
>
> But gdal has its own version in frmts/hdf4/hdf-eos/GDapi.c (GDapi.c?
> That was in Maciej's report):
>
> #if !defined(HP9000) && !defined(DEC_ALPHA)
> void
> sincos(double val, double *sin_val, double *cos_val)
> {
>*sin_val = sin(val);
>*cos_val = cos(val);
>return;
> }
> #endif
>
> On my system, nearly all of the symbols in libm are weak, so
> definitions in other libraries can override them, even for use within
> libm.
>
> I note that G_set_geodesic_distance_lat2() computes both sin() and
> cos() for two angles:
>
>stm = sin(tm);
>ctm = cos(tm);
>sdtm = sin(dtm);
>cdtm = cos(dtm);
>
> That could explain why it only happens with optimisation enabled: the
> compiler notices that it needs both sin() and cos() of the same angle,
> and uses sincos() instead.
>
> Similarly, if GDAL was compiled with optimisation, GDAL's sincos()
> calculates both sin() and cos() of its argument (well that's the whole
> point of the function), so the compiler optimises GDAL's sincos() to
> sincos(), resulting in infinite reecursion.
>
> I'm fairly sure that's what is going on here.
>
> I think that the ultimate solution would be for GDAL to be a bit more
> careful about defining sincos, i.e. have configure actually check
> whether libm defines sincos() rather than assuming that it only exists
> on specific platforms.
>
> --
> Glynn Clements <[EMAIL PROTECTED]>
>



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] matplotlib again

[Yann Chemin]

+1 for d.histogram replacement

another +1 for svg output

2008/7/23 Michael Barton <[EMAIL PROTECTED]>:
> While waiting for an answer from the developer of one of the wxPython mixins
> on why it doesn't work, I spent a little time looking at MatPlotLib again.
> Sometime back, I'd mentioned this as a potentially useful library to include
> with a Python-enabled GRASS because it can create a rich array of
> high-quality graphs and charts (and even maps). One of the issues raised was
> that it needs to be used within a GUI environment meaning that the GUI can
> do things that the command line can't. Not long ago, while talking with a
> Python-using colleague, I mentioned MatPlotLib and he said, 'of course it
> can be used from the command line to create a graphic file; I do it all the
> time'. So I looked into to it today while recovering from a wisdom tooth
> extraction. Indeed, it can be put into a script to be run from the command
> line and output a normal graphic file, like a *.png. Here is a link on how
> to do it.
> <http://www.dalkescientific.com/writings/diary/archive/2005/04/23/matplotlib_without_gui.html>.
> This cookbook entry is 3 years old. Along with the Agg backend mentioned in
> the cookbook (for png), new backends for MatPlotLib include Cairo (for pdf,
> png, ps, svg, and svgz), dedicated pdf and ps, and dedicated svg--in
> addition to GUI backends for wx, TclTk, and Qt.
> We could use it to replace dedicated GRASS code for creating graphs like
> d.histogram and build it into scripts that now call gnuplot. It's worth
> checking out at <http://matplotlib.sourceforge.net/>. It could be used
> within the GUI of course, but also within scripts to output to graphic
> files.
> Michael
> 
> C. Michael Barton, Professor of Anthropology
> Director of Graduate Studies
> School of Human Evolution & Social Change
> Center for Social Dynamics & Complexity
> Arizona State University
> Phone: 480-965-6262
> Fax: 480-965-7671
> www: 
>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] matplotlib example script

[Yann Chemin]

Hi Michael,

I tried it in Debian/Sid and here is what I got, a strange permission error

Any idea/suggestion?

--

GRASS 7.0.svn (spearfish60):~ > python histogram_mpldemo.py
input=elevation.10m bins=25 output="~/myhistogram" fillcolor=20:20:200
start
execl() failed: Permission denied
GRASS 7.0.svn (spearfish60):~ >

--

thanks
Yann

2008/7/25 Yann Chemin <[EMAIL PROTECTED]>:
> Hi Michael,
>
> Nice histogram!
> I am going to get python compiled and try it here...
> Yann
>



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] matplotlib example script

[Yann Chemin]

Hi,

after chmod +x, it created a nice histogram of elevation.10m.
So I tried on floating point image created by some process.

here is the problem:
Traceback (most recent call last):
  File "/home/yann/histogram_mpldemo.py", line 173, in 
main()
  File "/home/yann/histogram_mpldemo.py", line 159, in main
alpha=0.75)
  File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 6035, in hist
normed=bool(normed), new=True)
  File "/usr/lib/python2.5/site-packages/numpy/lib/function_base.py",
line 236, in histogram
range = (a.min(), a.max())
ValueError: zero-size array to ufunc.reduce without identity


this happens because the data has NAN (see r.info output):
 Range of data:min = nan  max = nan

Is there a way to discard NAN in a.min() and a.max() calculations?
Or is there a NAN-resistant mode in matplotlib?

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

Re: [GRASS-dev] matplotlib example script

[Yann Chemin]

Hi Michael,

I got a nice CASC2D water depth histogram, in a different color...
It nicely work for other datasets... without NAN, which are different
from NULL values, I wish we had a G_set_nan_null_value() function
too...

Yann


2008/7/26 Michael Barton <[EMAIL PROTECTED]>:
> Yann,
>
> Have you tried this on a dataset without NAN values?
>
> Michael
> __
> C. Michael Barton, Professor of Anthropology
> Director of Graduate Studies
> School of Human Evolution & Social Change
> Center for Social Dynamics & Complexity
> Arizona State University
> Tempe, AZ  85287-2402
> USA
>
> voice: 480-965-6262; fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton
>
> On Jul 25, 2008, at 4:09 PM, Yann Chemin wrote:
>
>> Hi,
>>
>> after chmod +x, it created a nice histogram of elevation.10m.
>> So I tried on floating point image created by some process.
>>
>> here is the problem:
>> Traceback (most recent call last):
>>  File "/home/yann/histogram_mpldemo.py", line 173, in 
>>   main()
>>  File "/home/yann/histogram_mpldemo.py", line 159, in main
>>   alpha=0.75)
>>  File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 6035, in
>> hist
>>   normed=bool(normed), new=True)
>>  File "/usr/lib/python2.5/site-packages/numpy/lib/function_base.py",
>> line 236, in histogram
>>   range = (a.min(), a.max())
>> ValueError: zero-size array to ufunc.reduce without identity
>>
>>
>> this happens because the data has NAN (see r.info output):
>> Range of data:min = nan  max = nan
>>
>> Is there a way to discard NAN in a.min() and a.max() calculations?
>> Or is there a NAN-resistant mode in matplotlib?
>>
>> Yann
>
>



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
<>___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC idea: Testing framework

[Yann Chemin]

Hi Vaclav,

I would be interested to help for the imagery modules,

Good luck !
Yann


On 31 January 2014 09:23, Vaclav Petras  wrote:

> Hi all,
>
> I would like to apply to GSoC this year with the idea of testing framework
> for GRASS. I probably don't have to explain the need for it.
>
> Sören suggested that he would be my mentor in case my application is
> successful. I hope also that I will get the feedback from all developers,
> now or in the future, because it is crucial that GRASS developers will
> actually use this framework.
>
> I described the idea shortly on Trac GSoC 2014 wiki page. I plan to
> include more notes on separate page in next weeks but the basic idea should
> be clear. Some discussion is also in #2105. Perhaps, the most innovative
> idea is that different types of tests should be supported (e.g. Python
> doctest and shell scripts), although it would be always driven form Python.
> For example, it seems that doctest is very convenient for modules which has
> standard input and output (see recent doctest for r.category module).
>
> Best regards,
> Vaclav
>
>
> http://trac.osgeo.org/grass/wiki/GSoC/2014#TestingframeworkforGRASSGIS
> http://trac.osgeo.org/grass/ticket/2105
>
> http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.category/test_rcategory_doctest.txt
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 

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

[GRASS-dev] Temporal: t.register: problem parsing when time zone present

[Yann Chemin]

Hi,

input line is:
t.register input=ta maps=ta_2004131 start="2004-05-10 00:00:00 +0530"
end="2004
-05-10 23:59:59 +0530"

temporal says:
  File "/usr/lib/python2.7/sqlite3/dbapi2.py", line 69, in convert_timestamp
hours, minutes, seconds = map(int, timepart_full[0].split(":"))
ValueError: invalid literal for int() with base 10: '00+05'

Manual says following format accepted:
start=string
Valid start date and time of the first map. Format absolute time:
"-mm-dd HH:MM:SS +HHMM", relative time is of type integer).
end=string
Valid end date and time of all map. Format absolute time: "-mm-dd
HH:MM:SS +HHMM", relative time is of type integer).

yann
-- 

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

Re: [GRASS-dev] Temporal: t.register: problem parsing when time zone present

[Yann Chemin]

Thank you Soeren,

If I want to register an irregular set of daily maps (missing days), will
the end date need to be the next day (say 5 days after this image, 2 days
after in the next image)?

Cheers,
Yann


On 5 March 2014 12:14, Sören Gebbert  wrote:

> Hi Yann,
> if you need support for time zones you have to use postgresql as
> backend. Unfortunately sqlite does not support time zones. A work
> around would be to ignore the time zone and use t.shift to temporally
> shift the created STRDS by 5h and 30 min to UTC time after registering
> the maps. I should notice this in the help page, i don't know why i
> missed that ..???!!!
>
> The next thing is that TGRASS uses time intervals in which the end
> time is not part of the time interval, but the start time of a
> successor. That means that you do not need to know how many days in a
> month are;  Interval of one day: start="2004-05-10" end="2004-05-11"
>
> Best regards
> Soeren
>
> 2014-03-05 6:36 GMT+01:00 Yann Chemin :
> > Hi,
> >
> > input line is:
> > t.register input=ta maps=ta_2004131 start="2004-05-10 00:00:00 +0530"
> > end="2004
> > -05-10 23:59:59 +0530"
> >
> > temporal says:
> >   File "/usr/lib/python2.7/sqlite3/dbapi2.py", line 69, in
> convert_timestamp
> > hours, minutes, seconds = map(int, timepart_full[0].split(":"))
> > ValueError: invalid literal for int() with base 10: '00+05'
> >
> > Manual says following format accepted:
> > start=string
> > Valid start date and time of the first map. Format absolute time:
> > "-mm-dd HH:MM:SS +HHMM", relative time is of type integer).
> > end=string
> > Valid end date and time of all map. Format absolute time: "-mm-dd
> > HH:MM:SS +HHMM", relative time is of type integer).
> >
> > yann
> > --
> > 
>



-- 

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

Re: [GRASS-dev] Temporal: t.register: problem parsing when time zone present

[Yann Chemin]

Yes Soeren, such a pity, I missed all your temporal fun!
As usual, have to do it the hard way...

Thanks,
I will set up the input file, inefficient, but my data is not regular in
time...



On 5 March 2014 14:15, Sören Gebbert  wrote:

> Hi,
> such a pity you were not in the TGIS workshop.
> However, there can be gaps between time intervals.
> Hence the end time of a time interval can be start time of a potential
> successor or the start time of a gap.
> But gaps are not stored explicitly, they are computed by topological
> analysis
>
> I would suggest that you create an input text file that lists all maps
> with time stamps that should be registered
> If you call t.register for each single map the registration will be
> very inefficient and slow
> Example of an input file with gaps between map intervals:
> mapA|2001-05-10|2001-05-11
> mapB|2001-05-15|2001-05-16
>
> Best regards
> Soeren
>
> 2014-03-05 9:29 GMT+01:00 Yann Chemin :
> > Thank you Soeren,
> >
> > If I want to register an irregular set of daily maps (missing days), will
> > the end date need to be the next day (say 5 days after this image, 2 days
> > after in the next image)?
> >
> > Cheers,
> > Yann
> >
> >
> > On 5 March 2014 12:14, Sören Gebbert 
> wrote:
> >>
> >> Hi Yann,
> >> if you need support for time zones you have to use postgresql as
> >> backend. Unfortunately sqlite does not support time zones. A work
> >> around would be to ignore the time zone and use t.shift to temporally
> >> shift the created STRDS by 5h and 30 min to UTC time after registering
> >> the maps. I should notice this in the help page, i don't know why i
> >> missed that ..???!!!
> >>
> >> The next thing is that TGRASS uses time intervals in which the end
> >> time is not part of the time interval, but the start time of a
> >> successor. That means that you do not need to know how many days in a
> >> month are;  Interval of one day: start="2004-05-10" end="2004-05-11"
> >>
> >> Best regards
> >> Soeren
> >>
> >> 2014-03-05 6:36 GMT+01:00 Yann Chemin :
> >> > Hi,
> >> >
> >> > input line is:
> >> > t.register input=ta maps=ta_2004131 start="2004-05-10 00:00:00 +0530"
> >> > end="2004
> >> > -05-10 23:59:59 +0530"
> >> >
> >> > temporal says:
> >> >   File "/usr/lib/python2.7/sqlite3/dbapi2.py", line 69, in
> >> > convert_timestamp
> >> > hours, minutes, seconds = map(int, timepart_full[0].split(":"))
> >> > ValueError: invalid literal for int() with base 10: '00+05'
> >> >
> >> > Manual says following format accepted:
> >> > start=string
> >> > Valid start date and time of the first map. Format absolute time:
> >> > "-mm-dd HH:MM:SS +HHMM", relative time is of type integer).
> >> > end=string
> >> > Valid end date and time of all map. Format absolute time: "-mm-dd
> >> > HH:MM:SS +HHMM", relative time is of type integer).
> >> >
> >> > yann
> >> > --
> >> > 
> >
> >
> >
> >
> > --
> > 
>



-- 

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

Re: [GRASS-dev] Temporal: t.register: problem parsing when time zone present

[Yann Chemin]

I will contact Aruna to check about the videos...

I just repeated inefficient from:



On 5 March 2014 14:30, Sören Gebbert  wrote:

> Hi Yann,
>
> 2014-03-05 9:48 GMT+01:00 Yann Chemin :
> > Yes Soeren, such a pity, I missed all your temporal fun!
> > As usual, have to do it the hard way...
>
> I am sorry for that. Are the videos of the workshop ready yet?
>
> >
> > Thanks,
> > I will set up the input file, inefficient, but my data is not regular in
> > time...
>
> Well, TGRASS was designed to support irregular time, hence using an
> input file with thousands of maps with irregular time stamps is the
> most efficient way to register IMHO.
>
> Why is it in your case inefficient?
>
> Cheers
> Soeren
>
> >
> >
> >
> > On 5 March 2014 14:15, Sören Gebbert 
> wrote:
> >>
> >> Hi,
> >> such a pity you were not in the TGIS workshop.
> >> However, there can be gaps between time intervals.
> >> Hence the end time of a time interval can be start time of a potential
> >> successor or the start time of a gap.
> >> But gaps are not stored explicitly, they are computed by topological
> >> analysis
> >>
> >> I would suggest that you create an input text file that lists all maps
> >> with time stamps that should be registered
> >> If you call t.register for each single map the registration will be
> >> very inefficient and slow
> >> Example of an input file with gaps between map intervals:
> >> mapA|2001-05-10|2001-05-11
> >> mapB|2001-05-15|2001-05-16
> >>
> >> Best regards
> >> Soeren
> >>
> >> 2014-03-05 9:29 GMT+01:00 Yann Chemin :
> >> > Thank you Soeren,
> >> >
> >> > If I want to register an irregular set of daily maps (missing days),
> >> > will
> >> > the end date need to be the next day (say 5 days after this image, 2
> >> > days
> >> > after in the next image)?
> >> >
> >> > Cheers,
> >> > Yann
> >> >
> >> >
> >> > On 5 March 2014 12:14, Sören Gebbert 
> >> > wrote:
> >> >>
> >> >> Hi Yann,
> >> >> if you need support for time zones you have to use postgresql as
> >> >> backend. Unfortunately sqlite does not support time zones. A work
> >> >> around would be to ignore the time zone and use t.shift to temporally
> >> >> shift the created STRDS by 5h and 30 min to UTC time after
> registering
> >> >> the maps. I should notice this in the help page, i don't know why i
> >> >> missed that ..???!!!
> >> >>
> >> >> The next thing is that TGRASS uses time intervals in which the end
> >> >> time is not part of the time interval, but the start time of a
> >> >> successor. That means that you do not need to know how many days in a
> >> >> month are;  Interval of one day: start="2004-05-10" end="2004-05-11"
> >> >>
> >> >> Best regards
> >> >> Soeren
> >> >>
> >> >> 2014-03-05 6:36 GMT+01:00 Yann Chemin :
> >> >> > Hi,
> >> >> >
> >> >> > input line is:
> >> >> > t.register input=ta maps=ta_2004131 start="2004-05-10 00:00:00
> +0530"
> >> >> > end="2004
> >> >> > -05-10 23:59:59 +0530"
> >> >> >
> >> >> > temporal says:
> >> >> >   File "/usr/lib/python2.7/sqlite3/dbapi2.py", line 69, in
> >> >> > convert_timestamp
> >> >> > hours, minutes, seconds = map(int, timepart_full[0].split(":"))
> >> >> > ValueError: invalid literal for int() with base 10: '00+05'
> >> >> >
> >> >> > Manual says following format accepted:
> >> >> > start=string
> >> >> > Valid start date and time of the first map. Format absolute time:
> >> >> > "-mm-dd HH:MM:SS +HHMM", relative time is of type integer).
> >> >> > end=string
> >> >> > Valid end date and time of all map. Format absolute time:
> "-mm-dd
> >> >> > HH:MM:SS +HHMM", relative time is of type integer).
> >> >> >
> >> >> > yann
> >> >> > --
> >> >> > 
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > 
> >
> >
> >
> >
> > --
> > 
>



-- 

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

[GRASS-dev] wxgui: enabling "page down" key in map selection boxes

[Yann Chemin]

Hi,

in wxgui when looking to display a raster layer, "down arrow" works, but it
is too slow to go through 1000s of maps.

Maybe "Page down" could be set up to scroll faster.

Yann

-- 

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

[GRASS-dev] Fwd: Android Compilation

[Yann Chemin]

I had a go at Android cross-compilation again, this time with new libraries
(most svn versions) and SVN trunk of GRASS, on an Ubuntu 64bit machine.

Errors compiling only in
/home/yann/dev/grass/gui/wxpython/animation
/home/yann/dev/grass/gui/wxpython/mapswipe
/home/yann/dev/grass/gui/wxpython/gmodeler
/home/yann/dev/grass/gui/wxpython/rlisetup
/home/yann/dev/grass/gui/wxpython/psmap
/home/yann/dev/grass/gui/wxpython/dbmgr
/home/yann/dev/grass/gui/wxpython/vdigit
/home/yann/dev/grass/gui/wxpython/iclass
/home/yann/dev/grass/gui/wxpython/gcp
/home/yann/dev/grass/gui/wxpython/timeline

I am attaching the changed setup scripts (~/dev/grass/android/scripts/) as
it was in an initial tarball that MarkusN  gave me last year. if you
replace them, then run "Yann_try.sh" for Ubuntu (64-bit) install and
building the android version.

It did create in ~/dev/grass/:
grass-7.0.svn-arm-unknown-linux-androideabi-05_03_2014-install.sh
grass-7.0.svn-arm-unknown-linux-androideabi-05_03_2014.tar.gz

I am now looking for information on creating a .apk file most probably
involving something with files like Android.mk and Application.mk


build-grass.sh
Description: Bourne shell script


build-libs.sh
Description: Bourne shell script


config.conf
Description: Binary data


setup-env.sh
Description: Bourne shell script


Yann_try.sh
Description: Bourne shell script
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: Android Compilation

[Yann Chemin]

I can find the 2 toolbox files in the
/home/yann/dev/grass/dist.arm-unknown-linux-androideabi/etc/gui/wxpython/xml
but they have 0 bytes...




On 6 March 2014 10:08, Vaclav Petras  wrote:

>
> On Wed, Mar 5, 2014 at 11:23 PM, Yann Chemin  wrote:
>
>> Errors compiling only in
>> /home/yann/dev/grass/gui/wxpython/animation
>> /home/yann/dev/grass/gui/wxpython/mapswipe
>> /home/yann/dev/grass/gui/wxpython/gmodeler
>> /home/yann/dev/grass/gui/wxpython/rlisetup
>> /home/yann/dev/grass/gui/wxpython/psmap
>> /home/yann/dev/grass/gui/wxpython/dbmgr
>> /home/yann/dev/grass/gui/wxpython/vdigit
>> /home/yann/dev/grass/gui/wxpython/iclass
>> /home/yann/dev/grass/gui/wxpython/gcp
>> /home/yann/dev/grass/gui/wxpython/timeline
>>
>
> These (g.gui.* modules) are also problematic on Mac OS X. For me there is
> no difference between these and standard scripts but there probably is
> some. It seems that the build system is a bit fragile when it compiles
> wxGUI things.
>
> I'm wondering if toolboxes were generated
> (etc/gui/wxpython/xml/menudata.xml and module_tree_menudata.xml).
>



-- 

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

[GRASS-dev] Planetary Datums help to add in GRASS

[Yann Chemin]

Hi,

I would like to add planetary Datums in GRASS as from this:
http://help.arcgis.com/en/arcims/10.0/mainhelp/mergedprojects/ArcXMLGuide/elements/gcs.htm#104900and
after

Right now GRASS issues a benign warning on importing LOLA DEM:

WARNING: Datum  not recognised by GRASS and no parameters found

This kind of information is in the URL:
104900 GCS_Mercury_2000
GEOGCS["GCS_Mercury_2000",DATUM["D_Mercury_2000",SPHEROID["Mercury_2000_IAU_IAG",2439700.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]

104901 GCS_Venus_1985
GEOGCS["GCS_Venus_1985",DATUM["D_Venus_1985",SPHEROID["Venus_1985_IAU_IAG_COSPAR",6051000.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]

104902 GCS_Venus_2000
GEOGCS["GCS_Venus_2000",DATUM["D_Venus_2000",SPHEROID["Venus_2000_IAU_IAG",6051800.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]

104903 GCS_Moon_2000
GEOGCS["GCS_Moon_2000",DATUM["D_Moon_2000",SPHEROID["Moon_2000_IAU_IAG",1737400.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]

104904 GCS_Mars_1979
GEOGCS["GCS_Mars_1979",DATUM["D_Mars_1979",SPHEROID["Mars_1979_IAU_IAG",3393400.0,192.0430107526882]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]

104905 GCS_Mars_2000
GEOGCS["GCS_Mars_2000",DATUM["D_Mars_2000",SPHEROID["Mars_2000_IAU_IAG",3396190.0,169.8944472236118]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]


Any hint would be great thanks,
Yann
-- 

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

Re: [GRASS-dev] Planetary Datums help to add in GRASS

[Yann Chemin]

Hi Alessandro,

I updated the planetary Ellipsoid table (r59566) with the definitions from
the website.

Cheers,
Yann


On 2 April 2014 23:27, Alessandro Frigeri
wrote:

> Hi Yann,
>
> maybe the name of the ellipse/datum fund in LOLA metadata does not match
> the name found in the ellipse.table
> http://svn.osgeo.org/grass/grass/trunk/lib/gis/ellipse.table.solar.system?
>
>
> I'm out of office now, I will check tomorrow
>
> Best,
>
> Alessandro
>
>
>
>
>
> 2014-04-02 17:23 GMT+02:00 Yann Chemin :
>
> Hi,
>>
>> I would like to add planetary Datums in GRASS as from this:
>>
>> http://help.arcgis.com/en/arcims/10.0/mainhelp/mergedprojects/ArcXMLGuide/elements/gcs.htm#104900and
>>  after
>>
>> Right now GRASS issues a benign warning on importing LOLA DEM:
>>
>> WARNING: Datum  not recognised by GRASS and no parameters found
>>
>> This kind of information is in the URL:
>> 104900 GCS_Mercury_2000
>>
>> GEOGCS["GCS_Mercury_2000",DATUM["D_Mercury_2000",SPHEROID["Mercury_2000_IAU_IAG",2439700.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]
>>
>> 104901 GCS_Venus_1985
>>
>> GEOGCS["GCS_Venus_1985",DATUM["D_Venus_1985",SPHEROID["Venus_1985_IAU_IAG_COSPAR",6051000.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]
>>
>> 104902 GCS_Venus_2000
>>
>> GEOGCS["GCS_Venus_2000",DATUM["D_Venus_2000",SPHEROID["Venus_2000_IAU_IAG",6051800.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]
>>
>> 104903 GCS_Moon_2000
>>
>> GEOGCS["GCS_Moon_2000",DATUM["D_Moon_2000",SPHEROID["Moon_2000_IAU_IAG",1737400.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]
>>
>> 104904 GCS_Mars_1979
>>
>> GEOGCS["GCS_Mars_1979",DATUM["D_Mars_1979",SPHEROID["Mars_1979_IAU_IAG",3393400.0,192.0430107526882]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]
>>
>> 104905 GCS_Mars_2000
>> GEOGCS["GCS_Mars_2000",DATUM["D_Mars_2000",SPHEROID["Mars_2000_IAU_IAG",3396190.0,169.8944472236118]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]
>>
>>
>> Any hint would be great thanks,
>> Yann
>> --
>> 
>>
>
>
>
> --
> Alessandro Frigeri
> Istituto di Astrofisica e Planetologia Spaziali - Istituto Nazionale di
> Astrofisica, Roma, Italy
>



-- 

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

[GRASS-dev] wxGUI having a hard time overlaying data with 0-360 and -180+180 proj

[Yann Chemin]

Hi,

Using the Moon nomenclature data set with the geological maps of the Moon
gives strange results:

http://www.tiikoni.com/tis/view/?id=b7713fd

The Moon Nomenclature (text) is going 0-360 and the Moon geology is
-180+180.

The Moon Nomenclature does not wrap around, but does map full in 0-360

http://www.tiikoni.com/tis/view/?id=b936970

Any help please

-- 

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

Re: [GRASS-dev] [GRASS-PSC] too many branches => retirement GRASS6.5.svn (=develbranch6)

[Yann Chemin]

+1
I also think we should stop GRASS 6 development


On 6 April 2014 19:01, Martin Landa  wrote:

> 2014-04-06 15:16 GMT+02:00 Moritz Lennert :
>
> > Hamish, maybe you could be the official grass6 maintainer, managing the
> > whole grass6 development in the way you propose, i.e. any new development
> > and bugfixes first go into grass6dev for a period of testing, before
> _you_
> > make the decision that something can be backported to grass6release. I do
> > think however, that for this to work, we would need to regularly publish
> > snapshots of grass6dev for easy testing.
>
> I think we should really stop thinking about GRASS 6 "development",
> ideally we should fully focus our energy on GRASS 7. We do not have
> enough man-power for keeping development in GRASS 6, simply saying. So
> please bug fix only should go there (relbr64). No new functionality.
>
> Martin
>
> --
> Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 

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

Re: [GRASS-dev] wxGUI having a hard time overlaying data with 0-360 and -180+180 proj

[Yann Chemin]

Found this worked (with limitations and only for point data):

from http://lists.osgeo.org/pipermail/gdal-dev/2006-June/009293.html

ogr2ogr Moon_N.shp MOON_nomenclature.shp --config CENTER_LONG 0 -t_srs
'+proj=longlat +a=1737400 +b=1737400 +no_defs'
Warning 1: Field name of width 255 truncated to 254.
Warning 1: Field clean_name of width 255 truncated to 254.
Warning 1: Field origin of width 255 truncated to 254.
Warning 1: Field type of width 255 truncated to 254.
Warning 1: Field code of width 255 truncated to 254.
Warning 1: Field approval of width 255 truncated to 254.
Warning 1: Field ethnicity of width 255 truncated to 254.
Warning 1: Field continent of width 255 truncated to 254.
Warning 1: Field quad_name of width 255 truncated to 254.
Warning 1: One or several characters couldn't be converted correctly from
UTF-8 to ISO-8859-1.
This warning will not be emitted anymore.

but also this is documented with a python code (not tried though):
https://isis.astrogeology.usgs.gov/IsisSupport/index.php?topic=3722.0



On 3 April 2014 12:12, Yann Chemin  wrote:

> Hi,
>
> Using the Moon nomenclature data set with the geological maps of the Moon
> gives strange results:
>
> http://www.tiikoni.com/tis/view/?id=b7713fd
>
> The Moon Nomenclature (text) is going 0-360 and the Moon geology is
> -180+180.
>
> The Moon Nomenclature does not wrap around, but does map full in 0-360
>
> http://www.tiikoni.com/tis/view/?id=b936970
>
> Any help please
>
> --
> 
>



-- 

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

Re: [GRASS-dev] [GRASS-PSC] too many branches => retirement GRASS6.5.svn (=develbranch6)

[Yann Chemin]

 Agreeing with Moritz,

"In other words, there are some types of users (those that don't read
anything provided by the developers) for whom I am sometimes tempted to
just say "RTFM" instead of trying to find ways to make it possible for them
to still use GRASS"

I used to start my GRASS GIS courses by saying to students that this is not
going to work if you do not read the instructions. Invariably, those who
did not listen to that would come back frustrated 30 minutes later...

Cheers
Yann


On 9 April 2014 12:51, Moritz Lennert  wrote:

> On 09/04/14 03:17, Vaclav Petras wrote:
>
>>
>> On Tue, Apr 8, 2014 at 9:09 PM, Glynn Clements > > wrote:
>>
>> If there's no Python installed, the installer can install it. If
>> Python is installed and the version is compatible, the installer can
>> install any required packages. Otherwise, it can at least inform the
>> user of the situation and enumerate the options.
>>
>>
>> This is a good point, the documentation must be in the installer, not a
>> separate file. For example Git installer for MS Windows list three
>> options how to install git and other command line tools with an
>> explanation. The problem is that only part of the users will read it and
>> only part of them will understand all the consequences (I mean, I was
>> not sure when I saw installing Git installation for the first time).
>>
>
> I think part of this discussion boils down to the very old debate about
> how far we should go in taking the user's hand. Do we really want to
> compete with programs that "just do the work for you", thus having to think
> of every possible problem they might face, or do we decide that even though
> we can lower the entrance hurdle a bit, GRASS does demand some more
> involvement from the user than other software.
>
> Personally, I am a bit afraid that by going down the first route we
> concentrate much developer time that could be spent on other (IMHO more
> useful) things and we also risk to make GRASS less efficient for those that
> have taken the time to pass the hurdle.
>
> In other words, there are some types of users (those that don't read
> anything provided by the developers) for whom I am sometimes tempted to
> just say "RTFM" instead of trying to find ways to make it possible for them
> to still use GRASS.
>
> Moritz
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 

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

Re: [GRASS-dev] Structure of links for addons, manual pages etc.

[Yann Chemin]

About the manual urls, I have an opinion:

Main manual for G7 to be linked to the SVN version (always updated).
Old manuals fixed to released versions (not maintained).

I understand how extreme it may be, but it may be very easy to maintain
(only one version)

0.02c


On 10 April 2014 07:21, Vaclav Petras  wrote:

> Hi,
>
> I think we need to rethink the structure of addresses/links to various
> things which we are putting online.
>
> The motivation are discussions "Linking Addons manual pages to core
> modules", "addons for windows", and "Addon manual pages not linked".
>
> For example, so far we were linking the trunk documentation using
> grass70/manuals but since we forked the 70 branch these links now points to
> it and not to trunk. Also all general links to GRASS documentation leads to
> grass64/manuals but this will be soon very obsolete.
>
> A lot of projects uses links such as latest, release or current (e.g.
> latest/manuals or release/manuals) which leads to the current (latest)
> release. And also links such as master, latest, trunk, nightly which leads
> to the one builds from the source code of the main branch. Alternatively,
> there is no special link for the current release which shortens URLs. I
> think something like this might be beneficial for us.
>
> So far I identified this set of things:
>
> * GRASS binaries
> * addons for MS Windows
> * addons SVN
> * manual pages
> * programming manual (or manuals)
>
> I don't have any concrete suggestion now. What are your experiences with
> this?
>
> Thanks,
> Vaclav
>
>
> http://lists.osgeo.org/pipermail/grass-dev/2014-April/068192.html
> http://lists.osgeo.org/pipermail/grass-dev/2014-April/068193.html
> http://lists.osgeo.org/pipermail/grass-web/2013-December/004587.html
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 

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

Re: [GRASS-dev] TOC in the manual

[Yann Chemin]

Did not have an opinion fixed, so went back to work, opened a module,
pressed on the manual tab and did have to wait a bit because of
rendering... If it was to open in a default web browser, I could have
continued looking around the module.

+1 for button to external browser


On 11 April 2014 14:33, Martin Landa  wrote:

> Hi,
>
> 2014-04-11 10:38 GMT+02:00 Martin Landa :
>
> > body part is 80%, see eg. [1]. Since wxPython widget doesn't support
> > most of css, it's shown before DESCRIPTION and not as fixed.
>
> the question is whether to hide manual tab and just to provide button
> which opens manual in the web browser. Martin
>
> --
> Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 

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

Re: [GRASS-dev] TOC in the manual

[Yann Chemin]

+1


On 12 April 2014 03:57, Anna Petrášová  wrote:

> Note, that on Windows and on Ubuntu with wxPython 3, the manual page in
> the tab is loaded immediately. I believe we should keep the manual in the
> tab, I think people are more likely to look at the manual there than
> pressing Help button. Personally I try to avoid pressing Help button in any
> application, it usually takes a lot of time to start browser and load it.
> WxPython 3 has some new widget for websites so eventually, it could replace
> the widget we use now.
>
> Anna
>
>
>
>
>
> On Fri, Apr 11, 2014 at 6:49 AM, Yann Chemin  wrote:
>
>> Did not have an opinion fixed, so went back to work, opened a module,
>> pressed on the manual tab and did have to wait a bit because of
>> rendering... If it was to open in a default web browser, I could have
>> continued looking around the module.
>>
>> +1 for button to external browser
>>
>>
>> On 11 April 2014 14:33, Martin Landa  wrote:
>>
>>> Hi,
>>>
>>> 2014-04-11 10:38 GMT+02:00 Martin Landa :
>>>
>>> > body part is 80%, see eg. [1]. Since wxPython widget doesn't support
>>> > most of css, it's shown before DESCRIPTION and not as fixed.
>>>
>>> the question is whether to hide manual tab and just to provide button
>>> which opens manual in the web browser. Martin
>>>
>>> --
>>> Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
>>> ___
>>> grass-dev mailing list
>>> grass-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>>
>>
>>
>>
>> --
>> 
>>
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>
>


-- 

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

Re: [GRASS-dev] Who wants GUI and who does not and why

[Yann Chemin]

Maybe some of the earlier involved developers can share their thoughts on
the Tcl/Tk GUI and its integration, its rise and fall, why and where this
experience can lead the wxPython GUI now...


On 16 April 2014 08:00, Vaclav Petras  wrote:

> Hi all,
>
> I believe, I was calling for this discussion recently, and I'm calling for
> it again. It seems that there are quite different opinions on GRASS GIS GUI
> ranging from "GUI is the only thing which brings us new users" to "no GUI
> needed".
>
> There is no better time to discuss this: we are discussing issues with MS
> Windows support, planing to release 7, working towards compatibility of 7
> with QGIS and gvSIG, and we also discussed WebGRASS topic recently.
>
> Here are recent quotations from "Handling of Python scripts on MS Windows"
> discussion (
> http://lists.osgeo.org/pipermail/grass-dev/2014-April/068269.html) with
> few notes and questions but feel free to start wherever you want.
>
>
> On Sun, Apr 13, 2014 at 12:52 PM, Benjamin Ducke wrote:
> > On Sun, Apr 13, 2014 at 11:03 AM, Moritz Lennert <
> mlenn...@club.worldonline.be> wrote:
>
>> > [Side note: The same discussion should also constantly be held about
>> > functionality which is specific to the GUI, because specifically
>> > developed for it), i.e. not just a GUI layer above command line
>> > functionality, something I'm afraid to see creep in more and more...]
>> >
>>
>> Does this mean that you want remove everything from `gui/*` besides
> `gui/wxpython/forms/*`?
>
>
>>  Agreed. Once more, I plead for a clean separation between GUI
>> and CLI developments, and a disconnection of their release cycles.
>>
>
> I see some advantages, for example just using same bug tracker makes
> difficult to say what is critical issue; but there are some GUI errors are
> tightly coupled to core module issues.
>
> On the other hand, I don't see how these disconnected release cycles would
> work. Also it seems that it is impossible or very hard to create good GUI
> without the support of the processing and management tools.
>
>
>> The wxPython GUI can be considered a monolithic application,
>> and FWIW it can pull every trick in the book to integrate a
>> Python interpreter, and to make it all easier for Windows users.
>>
>> ...
>>
>> I would say: Consider the wxGUI, the QGIS and gvSIG plug-ins etc.
>> monolithic applications and let their maintainers figure out how
>> to deal with this. In the gvSIG CE project, we do a lot of hair-
>> raising stuff to hide the complexity of GRASS and its dependencies
>> from the end user, and I suspect so does QGIS. But I would not
>> advocate the same approach to the core GRASS architecture.
>
>
> Than perhaps, no wxGUI is needed because we have QGIS and gvSIG plugins.
> Managing one GUI less in OSGeo could save some work. For example, QGIS
> GRASS plugin is developed separately, so there is no need to have another
> graphical user interface for GRASS with disconnect development.
>
> > I also think that some of the debate comes from the question of whether
> > the wxGUI should have a special status or whether it should just
> > be treated as one of the hundreds of modules that GRASS offers.
>
> This is more or less the current state, there is g.gui, you can start
> without it, there are g.gui.* modules. On the other hand, there is always
> something spatial with GUI, e.g. if you want GUI to start when module is
> started without parameters/with --ui.
>
>
>
> Or, are you satisfied with the situation as it is now?
>
> Thanks for sharing your thoughts,
> Vaclav
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 

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

[GRASS-dev] i.spectral limited to 400 files

[Yann Chemin]

Hi,

is there a way to modify i.spectral to remove the limit of 400 files:

i.spectral -c 
group=ta_group@PERMANENTcoordinates=104.118832166,14.7585647484,103.525338069,13.0911289527,103.304897404,12.9328638602
output=/home/yann/dev/grass-promo/grassposter/2014_EGU_WD_Landscape/images/ta_spectral
ERROR: Can only do up to 400 raster maps (400 given)
ERROR: No data returned from query

I have about 1500 files in the group.

-- 

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

Re: [GRASS-dev] Who wants GUI and who does not and why

[Yann Chemin]

1. Allow for the release stable versions of core GRASS without
having to wait for GUI fixes on different OS.

+1 for that !
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] i.spectral limited to 400 files

[Yann Chemin]

In Ubuntu, I could expand the number of opened files by:

#PCA will require the extension of ulimit for open files in Ubuntu
sudo vi /etc/security/limits.conf

#There you should enter:
#usernamehardnofile  65000
#usernamesoftnofile  1
#before # End of file

and reboot

On 18/04/2014, Nikos Alexandris  wrote:
> Yann Chemin wrote:
>
>> >> is there a way to modify i.spectral to remove the limit of 400 files:
>
> Glynn:
>
>> > The limit is from r.what. It probably wouldn't be that hard to fix.
>
> Markus N:
>
>> ... "nice to have" for sure.
>>
>> BTW:
>> The next limit would be the operating system. Default Linux allows
>> 1024 files to be opened, which can be increased in
>> /etc/security/limits.conf
>
> Aren't there, however, any important side-effects in altering this limit?
> There must be a (security?) reason for the number 2^10.
>
> Nikos
>


-- 

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

[GRASS-dev] discussion: spectral libraries and GRASS

[Yann Chemin]

Hi, I would like to start a discussion about supporting spectral
libraries in GRASS.

known formats:

ASTER speclibv2.0 has each signature in a plain text file with 27
lines of headers and the rest in 2 columns Tab-separated
(1=wavelength, 2=reflectance)

Speclab.lib06 (http://speclab.cr.usgs.gov/spectral.lib06/) is in text
format, seems a bit more complex than speclibv2.0 and I have not been
able to compile their reading code yet, I might just skip it and make
directly a reader.

ENVI .sli seems to be a hyperspectral image cube with an augmented
header file to fit the attributes handling.

Questions:

1 - anybody worked with spectral libraries in GRASS before? If yes,
which approach you used?
2 - any (un/less)known modules waiting to be resurrected about that?
3 - If nothing is there, anybody has a strong feeling about the way to
go for GRASS to: a) import b) store such libraries?
4 - A last note: each signature has significant amount of metadata,
this might be a challenge.

(I am willing to code the necessary to import and store)

Yann
-- 

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

Re: [GRASS-dev] vector line coordinates

[Yann Chemin]

I somehow missed the v.to.db option:
start: line/boundary starting point coordinates, X,Y or X,Y,Z
end: line/boundary end point coordinates, X,Y or X,Y,Z




On 14/05/2014, Yann Chemin  wrote:
> Hi,
>
> I have a set of faults (lines made from 2 points only)
> and my target is to calculate the distance from a city to all of the
> faults in the region.
>
> Ideally I would need the location (X,Y) of the mid-point of the line,
> but if I can extract the two tipline nodes coordinates, then it is
> half-way to it.
>
> v.to.db has option=coor but it does not take type=line
>
> Also, v.type does not convert line to point
> v.type input=analysis output=analysis_pts from_type=line to_type=point
>
> Yann
>
> --
> 
>


-- 

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

[GRASS-dev] vector line coordinates

[Yann Chemin]

Hi,

I have a set of faults (lines made from 2 points only)
and my target is to calculate the distance from a city to all of the
faults in the region.

Ideally I would need the location (X,Y) of the mid-point of the line,
but if I can extract the two tipline nodes coordinates, then it is
half-way to it.

v.to.db has option=coor but it does not take type=line

Also, v.type does not convert line to point
v.type input=analysis output=analysis_pts from_type=line to_type=point

Yann

-- 

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

[GRASS-dev] wxGUI customized toolboxes: handler for non-GRASS commands

[Yann Chemin]

Hi,

I would like to make a customized toolbox to call some non-GRASS CLI programs.

Handlers OnMenuCmd and RunMenuCmd seem not to work. The menu items are
grey/shadowed so that no mouse click is allowed on them.

thanks
Yann
-- 

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

Re: [GRASS-dev] wxGUI customized toolboxes: handler for non-GRASS commands

[Yann Chemin]

To be precise, the non-GRASS programs have their own GUI already, and
the calls need only one word.

On 16/05/2014, Yann Chemin  wrote:
> Hi,
>
> I would like to make a customized toolbox to call some non-GRASS CLI
> programs.
>
> Handlers OnMenuCmd and RunMenuCmd seem not to work. The menu items are
> grey/shadowed so that no mouse click is allowed on them.
>
> thanks
> Yann
> --
> 
>


-- 

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

Re: [GRASS-dev] wxGUI customized toolboxes: handler for non-GRASS commands

[Yann Chemin]

in svn/gui/wxpython/lmgr/frame.py
line 758
by adding:

def RunCmd(self, event = None, cmd = []):
"""!Run command to system from menu"""
if event:
cmd = self.GetMenuCmd(event)
os.system(cmd)

it should handle it, however, it seems that a flag is needed to enable
the possibility to click the command from the created menu. It is
still grey/shadowed.



On 16/05/2014, Yann Chemin  wrote:
> To be precise, the non-GRASS programs have their own GUI already, and
> the calls need only one word.
>
> On 16/05/2014, Yann Chemin  wrote:
>> Hi,
>>
>> I would like to make a customized toolbox to call some non-GRASS CLI
>> programs.
>>
>> Handlers OnMenuCmd and RunMenuCmd seem not to work. The menu items are
>> grey/shadowed so that no mouse click is allowed on them.
>>
>> thanks
>> Yann
>> --
>> 
>>
>
>
> --
> 
>


-- 

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

Re: [GRASS-dev] wxGUI customized toolboxes: handler for non-GRASS commands

[Yann Chemin]

Hi Anna,

Patch works great ! Needs RunMenuCmd and all goes to perfection. Any
chance to have it included in the SVN tree?

Thank you
Yann

On 18/05/2014, Anna Petrášová  wrote:
> Hi Yann,
>
> it's grayed out because it tests if it's a working grass command (for
> example r.in.lidar is grayed when you don't compile grass with liblas). You
> can try to apply this patch which tests if the command looks like grass
> command (regular expression) and if it is not, it doesn't disable it in
> menu.
>
> Index: gui_core/menu.py
> ===
> --- gui_core/menu.py (revision 60284)
> +++ gui_core/menu.py (working copy)
> @@ -18,7 +18,7 @@
>  @author Robert Szczepanek (menu customization)
>  @author Vaclav Petras  (menu customization)
>  """
> -
> +import re
>  import wx
>
>  from core  import globalvar
> @@ -91,7 +91,8 @@
>  cmd = utils.split(str(command))
>  except UnicodeError:
>  cmd = utils.split(EncodeString((command)))
> -if cmd and cmd[0] not in globalvar.grassCmd:
> +if cmd and cmd[0] not in globalvar.grassCmd and \
> +   re.match('[rvdipmgt][3bs]?\.([a-z0-9\.])+', cmd[0]):
>      menuItem.Enable(False)
>
>  rhandler = eval('self.parent.' + handler)
>
>
>
> On Fri, May 16, 2014 at 12:30 AM, Yann Chemin  wrote:
>
>> in svn/gui/wxpython/lmgr/frame.py
>> line 758
>> by adding:
>>
>> def RunCmd(self, event = None, cmd = []):
>> """!Run command to system from menu"""
>> if event:
>> cmd = self.GetMenuCmd(event)
>> os.system(cmd)
>>
>>
> I am not sure if this is needed. I would say it might work without this
> change but you have to try it out.
>
>
> Best,
>
> Anna
>
>
>> it should handle it, however, it seems that a flag is needed to enable
>> the possibility to click the command from the created menu. It is
>> still grey/shadowed.
>>
>>
>>
>> On 16/05/2014, Yann Chemin  wrote:
>> > To be precise, the non-GRASS programs have their own GUI already, and
>> > the calls need only one word.
>> >
>> > On 16/05/2014, Yann Chemin  wrote:
>> >> Hi,
>> >>
>> >> I would like to make a customized toolbox to call some non-GRASS CLI
>> >> programs.
>> >>
>> >> Handlers OnMenuCmd and RunMenuCmd seem not to work. The menu items are
>> >> grey/shadowed so that no mouse click is allowed on them.
>> >>
>> >> thanks
>> >> Yann
>> >> --
>> >> 
>> >>
>> >
>> >
>> > --
>> > 
>> >
>>
>>
>> --
>> 
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>


-- 

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

Re: [GRASS-dev] wxGUI customized toolboxes: handler for non-GRASS commands

[Yann Chemin]

Hi Anna,

Thank you, updating trunk now !

About RunMenuCmd, it is just a note to remember that it is the call to
use for external program. All good there.

Yann

On 18/05/2014, Anna Petrášová  wrote:
> Hi Yann,
>
>
> On Sat, May 17, 2014 at 11:46 PM, Yann Chemin  wrote:
>
>> Hi Anna,
>>
>> Patch works great ! Needs RunMenuCmd and all goes to perfection. Any
>> chance to have it included in the SVN tree?
>>
>>
> I committed the patch in trunk, if you agree, I won't backport it now. I
> don't understand what do you mean with RunMenuCmd, is there still some
> problem and what is it exactly?
>
> Anna
>
>
> Thank you
>> Yann
>>
>> On 18/05/2014, Anna Petrášová  wrote:
>> > Hi Yann,
>> >
>> > it's grayed out because it tests if it's a working grass command (for
>> > example r.in.lidar is grayed when you don't compile grass with liblas).
>> You
>> > can try to apply this patch which tests if the command looks like grass
>> > command (regular expression) and if it is not, it doesn't disable it in
>> > menu.
>> >
>> > Index: gui_core/menu.py
>> > ===
>> > --- gui_core/menu.py (revision 60284)
>> > +++ gui_core/menu.py (working copy)
>> > @@ -18,7 +18,7 @@
>> >  @author Robert Szczepanek (menu customization)
>> >  @author Vaclav Petras  (menu customization)
>> >  """
>> > -
>> > +import re
>> >  import wx
>> >
>> >  from core  import globalvar
>> > @@ -91,7 +91,8 @@
>> >  cmd = utils.split(str(command))
>> >  except UnicodeError:
>> >  cmd = utils.split(EncodeString((command)))
>> > -if cmd and cmd[0] not in globalvar.grassCmd:
>> > +if cmd and cmd[0] not in globalvar.grassCmd and \
>> > +   re.match('[rvdipmgt][3bs]?\.([a-z0-9\.])+', cmd[0]):
>> >  menuItem.Enable(False)
>> >
>> >  rhandler = eval('self.parent.' + handler)
>> >
>> >
>> >
>> > On Fri, May 16, 2014 at 12:30 AM, Yann Chemin 
>> > wrote:
>> >
>> >> in svn/gui/wxpython/lmgr/frame.py
>> >> line 758
>> >> by adding:
>> >>
>> >> def RunCmd(self, event = None, cmd = []):
>> >> """!Run command to system from menu"""
>> >> if event:
>> >> cmd = self.GetMenuCmd(event)
>> >> os.system(cmd)
>> >>
>> >>
>> > I am not sure if this is needed. I would say it might work without this
>> > change but you have to try it out.
>> >
>> >
>> > Best,
>> >
>> > Anna
>> >
>> >
>> >> it should handle it, however, it seems that a flag is needed to enable
>> >> the possibility to click the command from the created menu. It is
>> >> still grey/shadowed.
>> >>
>> >>
>> >>
>> >> On 16/05/2014, Yann Chemin  wrote:
>> >> > To be precise, the non-GRASS programs have their own GUI already,
>> >> > and
>> >> > the calls need only one word.
>> >> >
>> >> > On 16/05/2014, Yann Chemin  wrote:
>> >> >> Hi,
>> >> >>
>> >> >> I would like to make a customized toolbox to call some non-GRASS
>> >> >> CLI
>> >> >> programs.
>> >> >>
>> >> >> Handlers OnMenuCmd and RunMenuCmd seem not to work. The menu items
>> are
>> >> >> grey/shadowed so that no mouse click is allowed on them.
>> >> >>
>> >> >> thanks
>> >> >> Yann
>> >> >> --
>> >> >> 
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > 
>> >> >
>> >>
>> >>
>> >> --
>> >> 
>> >> ___
>> >> grass-dev mailing list
>> >> grass-dev@lists.osgeo.org
>> >> http://lists.osgeo.org/mailman/listinfo/grass-dev
>> >>
>> >
>>
>>
>> --
>> 
>>
>


-- 

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

Re: [GRASS-dev] libLAS on Ubuntu 14.04

[Yann Chemin]

I can confirm the issue,

also by trying these configure options it is not helping:
--with-liblas --with-liblas-config
--with-liblas --with-liblas-config=/usr/bin/liblas-config
--with-liblas=yes --with-liblas-config
--with-liblas=yes --with-liblas-config=/usr/bin/liblas-config

Also two targets are found, both valid (v1.7.0) and identical:
whereis liblas-config
liblas-config: /usr/bin/liblas-config /usr/bin/X11/liblas-config
/usr/share/man/man1/liblas-config.1.gz

$ ls -aslh /usr/bin/X11/liblas-config
4.0K -rwxr-xr-x 1 root root 2.5K Feb 26 14:43 /usr/bin/X11/liblas-config
$ ls -aslh /usr/bin/liblas-config
4.0K -rwxr-xr-x 1 root root 2.5K Feb 26 14:43 /usr/bin/liblas-config




On 23/05/2014, Vaclav Petras  wrote:
> Hi,
>
> I was trying to compile GRASS with libLAS but ./configure says no.
>
> I used:
>
> --with-liblas-config=/usr/bin/liblas-config
>
> and I have all liblas packages from standard Ubuntu 14.04 repository
> (libLAS version is 1.7.0 which is the current stable release).
>
> Since configure went OK but the result for libLAS was "no", I tried to
> compile and run the ./configure's testing code myself.
>
>
> Code:
>
> #include 
> int main() {
> LASReader_Create("foo");
> ; return 0; }
>
> Compilation:
>
> gcc liblastest.c -o liblastest -ggdb -L/usr/lib -llas -llas_c
> -L/usr/lib/x86_64-linux-gnu
> /usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.54.0
> /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0 /usr/lib/libgdal.so
> /usr/lib/libgeotiff.so /usr/lib/x86_64-linux-gnu/libtiff.so $(liblas-config
> --includes)
>
> Debugging test:
>
> gdb liblastest
>
> Starting program: /home/vasek/dev/grass/test/liblastest
>
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x77285471 in std::istream::seekg(std::fpos<__mbstate_t>) () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (gdb) bt
> #0 0x77285471 in std::istream::seekg(std::fpos<__mbstate_t>) ()
> from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #1 0x7759597b in liblas::detail::reader::Header::ReadHeader() ()
> from /usr/lib/liblas.so.2
> #2 0x7754713b in
> liblas::ReaderFactory::CreateWithStream(std::istream&) () from
> /usr/lib/liblas.so.2
> #3 0x77bb1a80 in LASReader_Create () from /usr/lib/liblas_c.so.2
> #4 0x004006ab in main () at liblastest.c:4
>
> So the test failed with segmentation fault but it would actually fail
> during compilation if I would use `liblas-config --libs` because the boost
> libraries are `libboost_program_options.so.1.54.0` on my computer while
> `liblas-config --libs` says just `libboost_program_options.so` (same for
> thread library).
>
> It seems that the thing with boost libraries is a packaging issue but I'm
> not sure about the other ones. I can repeat it outside GRASS I don't know
> if this is actually what GRASS is doing and if it makes sense.
>
> Was somebody successful with libLAS on Ubuntu 14.04 and what is the general
> procedure for Linux anyway?
>
> Thanks,
> Vaclav
>


-- 

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

Re: [GRASS-dev] libLAS on Ubuntu 14.04

[Yann Chemin]

Hi,

I have libboost-thread-dev, libboost-program-options-dev, and
libboost-all-dev installed
in configure options:  --with-liblas-config=/usr/bin/liblas-config
--with-liblas=yes

still:
checking whether to use libLAS... yes
checking for liblas-config... /usr/bin/liblas-config
configure: error: *** Unable to locate libLAS library.

Full config script:
CFLAGS="-g -Wall"
./configure --with-cxx --with-wxwidgets --with-freetype=yes
--with-postgres=no --with-sqlite=yes --without-tcltk
--enable-largefile=yes --with-freetype-includes=/usr/include/freetype2
--with-opengl-libs=/usr/include/GL --with-readline --with-python=yes
--with-lapack --with-gdal=/usr/bin/gdal-config
--with-proj-share=/usr/share/proj --with-pthread
--with-liblas-config=/usr/bin/liblas-config --with-liblas=yes
--with-blas


On 30/05/2014, Vaclav Petras  wrote:
> On Thu, May 29, 2014 at 1:09 PM, Javier Martínez-López <
> javi.martinez.lo...@gmail.com> wrote:
>
>> Hi,
>>
>> I had the same problem with the latest grass 71 svn version (from
>> today) under ubuntu 14.04 and I certainly solved it installing
>> libboost-all-dev and the config option: --with-liblas=yes
>> --with-liblas-config=/usr/bin/liblas-config
>>
>>
> Thank you. This was very helpful. The problem was that I included only
>
> --with-liblas-config=/usr/bin/liblas-config
>
> in my ./configure call. I thought that this is enough. When I added
>
> --with-liblas=yes
>
> it started to work. After ./configure ... && make, I have r.in.lidar and
> v.in.lidar.
>
> I still have just libboost-thread-dev and libboost-program-options-dev, the
> libboost-all-dev package is not necessary, although it is the simplest
> option.
>
> I don't understand the think with --with-liblas=yes, I really though I read
> here that it is not necessary (once you have --with-liblas-config) and Yann
> was saying that different combinations of --with-liblas* does not work for
> him.
>
> There is still the problem with different content of CFLAGS and CPPFLAGS
> variables (r57541 and the patch from #2065) in ./configure and also I'm not
> able to run the test program from ./configure myself. I don't know how this
> is important.
>
> Thanks all for help. I'll try this also on other computers with Ubuntu
> 14.04 and I'll let you know if it will not work.
>
> Vaclav
>
>
> On Thu, May 22, 2014 at 3:25 PM, Vaclav Petras 
> wrote:
>> I was trying to compile GRASS with libLAS but ./configure says no.
>>
>> I used:
>>
>> --with-liblas-config=/usr/bin/liblas-config
>>
>> and I have all liblas packages from standard Ubuntu 14.04 repository
> (libLAS version is 1.7.0 which is the current stable release).
>
> On Thu, May 22, 2014 at 8:47 PM, Yann Chemin  wrote:
>>
>> I can confirm the issue,
>>
>> also by trying these configure options it is not helping:
>> --with-liblas --with-liblas-config
>> --with-liblas --with-liblas-config=/usr/bin/liblas-config
>> --with-liblas=yes --with-liblas-config
>> --with-liblas=yes --with-liblas-config=/usr/bin/liblas-config
>>
>> Also two targets are found, both valid (v1.7.0) and identical:
>> whereis liblas-config
>> liblas-config: /usr/bin/liblas-config /usr/bin/X11/liblas-config
>> /usr/share/man/man1/liblas-config.1.gz
>>
>> $ ls -aslh /usr/bin/X11/liblas-config
>> 4.0K -rwxr-xr-x 1 root root 2.5K Feb 26 14:43 /usr/bin/X11/liblas-config
>> $ ls -aslh /usr/bin/liblas-config
>> 4.0K -rwxr-xr-x 1 root root 2.5K Feb 26 14:43 /usr/bin/liblas-config
>>
>


-- 

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

Re: [GRASS-dev] libLAS on Ubuntu 14.04

[Yann Chemin]

More from config.log (thx MarkusM)

configure:6198: checking whether to use libLAS
configure:6215: checking for liblas-config
configure:6272: gcc -o conftest -g -O2  -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2  -I/usr/include -I/usr/include/gdal
-I/usr/include/geotiff -I/usr/include/x86_64-linux-gnu
-Wl,--export-dynamic conftest.c  -L/usr/lib -llas -llas_c
-L/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libboost_program_options.so
/usr/lib/x86_64-linux-gnu/libboost_thread.so /usr/lib/libgdal.so
/usr/lib/libgeotiff.so /usr/lib/x86_64-linux-gnu/libtiff.so 1>&5
configure:6266:32: fatal error: liblas/capi/liblas.h: No such file or directory
 #include 
^
compilation terminated.
configure: failed program was:
#line 6265 "configure"
#include "confdefs.h"
#include 
int main() {
LASReader_Create("foo");
; return 0; }
configure:6287: gcc -o conftest -g -O2  -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2  -I/usr/include -I/usr/include/gdal
-I/usr/include/geotiff -I/usr/include/x86_64-linux-gnu
-Wl,--export-dynamic conftest.c  -L/usr/lib -llas -llas_c
-L/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libboost_program_options.so
/usr/lib/x86_64-linux-gnu/libboost_thread.so /usr/lib/libgdal.so
/usr/lib/libgeotiff.so /usr/lib/x86_64-linux-gnu/libtiff.so 1>&5
configure:6281:32: fatal error: liblas/capi/liblas.h: No such file or directory
 #include 
^
compilation terminated.
configure: failed program was:
#line 6280 "configure"
#include "confdefs.h"
#include 
int main() {
LASReader_Create("foo");
; return 0; }


On 31/05/2014, Yann Chemin  wrote:
> Hi,
>
> I have libboost-thread-dev, libboost-program-options-dev, and
> libboost-all-dev installed
> in configure options:  --with-liblas-config=/usr/bin/liblas-config
> --with-liblas=yes
>
> still:
> checking whether to use libLAS... yes
> checking for liblas-config... /usr/bin/liblas-config
> configure: error: *** Unable to locate libLAS library.
>
> Full config script:
> CFLAGS="-g -Wall"
> ./configure --with-cxx --with-wxwidgets --with-freetype=yes
> --with-postgres=no --with-sqlite=yes --without-tcltk
> --enable-largefile=yes --with-freetype-includes=/usr/include/freetype2
> --with-opengl-libs=/usr/include/GL --with-readline --with-python=yes
> --with-lapack --with-gdal=/usr/bin/gdal-config
> --with-proj-share=/usr/share/proj --with-pthread
> --with-liblas-config=/usr/bin/liblas-config --with-liblas=yes
> --with-blas
>
>
> On 30/05/2014, Vaclav Petras  wrote:
>> On Thu, May 29, 2014 at 1:09 PM, Javier Martínez-López <
>> javi.martinez.lo...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I had the same problem with the latest grass 71 svn version (from
>>> today) under ubuntu 14.04 and I certainly solved it installing
>>> libboost-all-dev and the config option: --with-liblas=yes
>>> --with-liblas-config=/usr/bin/liblas-config
>>>
>>>
>> Thank you. This was very helpful. The problem was that I included only
>>
>> --with-liblas-config=/usr/bin/liblas-config
>>
>> in my ./configure call. I thought that this is enough. When I added
>>
>> --with-liblas=yes
>>
>> it started to work. After ./configure ... && make, I have r.in.lidar and
>> v.in.lidar.
>>
>> I still have just libboost-thread-dev and libboost-program-options-dev,
>> the
>> libboost-all-dev package is not necessary, although it is the simplest
>> option.
>>
>> I don't understand the think with --with-liblas=yes, I really though I
>> read
>> here that it is not necessary (once you have --with-liblas-config) and
>> Yann
>> was saying that different combinations of --with-liblas* does not work
>> for
>> him.
>>
>> There is still the problem with different content of CFLAGS and CPPFLAGS
>> variables (r57541 and the patch from #2065) in ./configure and also I'm
>> not
>> able to run the test program from ./configure myself. I don't know how
>> this
>> is important.
>>
>> Thanks all for help. I'll try this also on other computers with Ubuntu
>> 14.04 and I'll let you know if it will not work.
>>
>> Vaclav
>>
>>
>> On Thu, May 22, 2014 at 3:25 PM, Vaclav Petras 
>> wrote:
>>> I was trying to compile GRASS with libLAS but ./configure says no.
>>>
>>> I used:
>>>
>>> --with-liblas-config=/usr/bin/liblas-config
>>>
>>> and I have all liblas packages from standard Ubuntu 14.0

Re: [GRASS-dev] libLAS on Ubuntu 14.04

[Yann Chemin]

OK it was that thanks Vaclav

Summary:
sudo apt-get install libboost-thread-dev,libboost-program-options-dev
liblas-c-dev

in configure options:
--with-liblas-config=/usr/bin/liblas-config
--with-liblas=yes

On 31/05/2014, Vaclav Petras  wrote:
> On Sat, May 31, 2014 at 9:23 AM, Yann Chemin  wrote:
>
>> configure:6266:32: fatal error: liblas/capi/liblas.h: No such file or
>> directory
>>  #include 
>>
>
> Hm, are you sure you have the liblas-c-dev package? And are you sure the
> file liblas/capi/liblas.h is there (on include path, in case of the
> liblas-c-dev package it should be /usr/include/liblas/capi/liblas.h)?
>


-- 

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

Re: [GRASS-dev] libLAS on Ubuntu 14.04

[Yann Chemin]

Looking into the Wiki page I got FFMPEG configured by this:

sudo apt-get install libffms2-dev

and from wiki page:

--with-ffmpeg=yes \
--with-ffmpeg-includes="/usr/include/libavcodec
/usr/include/libavformat /usr/include/libswscale
/usr/include/libavutil"



On 31/05/2014, Vaclav Petras  wrote:
> On Sat, May 31, 2014 at 9:32 AM, Yann Chemin  wrote:
>
>> OK it was that thanks Vaclav
>>
>> Summary:
>> sudo apt-get install libboost-thread-dev,libboost-program-options-dev
>> liblas-c-dev
>>
>> in configure options:
>> --with-liblas-config=/usr/bin/liblas-config
>> --with-liblas=yes
>>
>> I updated the wiki for 14.04 and added libLAS packages and added libLAS
>> to
> configure for GRASS 7. I think the page needs some refactoring. I have hard
> time to navigate it when I understand most of the terms but the problem is
> the high number of possibilities.
>
> http://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu
>
>
>
>>  On 31/05/2014, Vaclav Petras  wrote:
>> > On Sat, May 31, 2014 at 9:23 AM, Yann Chemin  wrote:
>> >
>> >> configure:6266:32: fatal error: liblas/capi/liblas.h: No such file or
>> >> directory
>> >>  #include 
>> >>
>> >
>> > Hm, are you sure you have the liblas-c-dev package? And are you sure
>> > the
>> > file liblas/capi/liblas.h is there (on include path, in case of the
>> > liblas-c-dev package it should be /usr/include/liblas/capi/liblas.h)?
>> >
>>
>>
>> --
>> 
>>
>


-- 

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

[GRASS-dev] adding Isis menu to GRASS

[Yann Chemin]

Hi,

I made a bash script to create an Isis menu in GRASS [1].

It scans Isis/bin for applications, makes a list of them according to
keywords and builds the toolbox menu in
"$HOME/.grass7/toolboxes/toolboxes.xml" and a main_menu with Isis
entry in "$HOME/.grass7/toolboxes/main_menu.xml" both also attached.

https://www.youtube.com/watch?v=4O-MY4dBZx4

There are two issues now:
1 - if a toolboxes.xml already exists, it will overwrite it (not wanted?)
2 - if it is in gis_set.py it will regenerate the files each time the
GUI is starting (not wanted)

Yann


[1] 
https://sites.google.com/site/geosnipets/Downhome/Topic2/creatinganisismenuentryingrass

-- 

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

[GRASS-dev] i.atcorr Landsat 8: Unsupported iwave value 116, 117, etc

[Yann Chemin]

hi, I am trying to run atcorr on a Landsat 8 image, and it says

LC81270512014115LGN00.toar.1 LC81270512014115LGN00.surf.1
iwave no:   115
Atmospheric correction...
 100% <== NOTE: this one is OK ==><
Atmospheric correction complete.
LC81270512014115LGN00.toar.2 LC81270512014115LGN00.surf.2
iwave no:   116
WARNING: Unsupported iwave value: 116
 wavelength  less  than  0.25  micron:
 let's take s(l)=s(0.25)
Atmospheric correction...
LC81270512014115LGN00.toar.3 LC81270512014115LGN00.surf.3
iwave no:   117
WARNING: Unsupported iwave value: 117
 wavelength  less  than  0.25  micron:
 let's take s(l)=s(0.25)
Atmospheric correction...
LC81270512014115LGN00.toar.4 LC81270512014115LGN00.surf.4
iwave no:   118
WARNING: Unsupported iwave value: 118
Atmospheric correction...
 100%
Atmospheric correction complete.
LC81270512014115LGN00.toar.5 LC81270512014115LGN00.surf.5
iwave no:   120
WARNING: Unsupported iwave value: 120
Atmospheric correction...

...etc.


-- 

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

Re: [GRASS-dev] i.atcorr Landsat 8: Unsupported iwave value 116, 117, etc

[Yann Chemin]

Yes SVN,

let me rebuild GRASS manually to be sure it all goes above the rev number.

will comment as needed.
Yann

On 08/06/2014, Markus Neteler  wrote:
> On Sun, Jun 8, 2014 at 2:07 PM, Yann Chemin  wrote:
>> hi, I am trying to run atcorr on a Landsat 8 image, and it says
>
> Is it the current trunk from SVN version?
>
>> LC81270512014115LGN00.toar.1 LC81270512014115LGN00.surf.1
>> iwave no:   115
>> Atmospheric correction...
>>  100% <== NOTE: this one is OK ==><
>> Atmospheric correction complete.
>> LC81270512014115LGN00.toar.2 LC81270512014115LGN00.surf.2
>> iwave no:   116
>> WARNING: Unsupported iwave value: 116
>>  wavelength  less  than  0.25  micron:
>>  let's take s(l)=s(0.25)
>> Atmospheric correction...
>> LC81270512014115LGN00.toar.3 LC81270512014115LGN00.surf.3
>> iwave no:   117
>> WARNING: Unsupported iwave value: 117
>>  wavelength  less  than  0.25  micron:
>>  let's take s(l)=s(0.25)
>> Atmospheric correction...
>> LC81270512014115LGN00.toar.4 LC81270512014115LGN00.surf.4
>> iwave no:   118
>> WARNING: Unsupported iwave value: 118
>> Atmospheric correction...
>>  100%
>> Atmospheric correction complete.
>> LC81270512014115LGN00.toar.5 LC81270512014115LGN00.surf.5
>> iwave no:   120
>> WARNING: Unsupported iwave value: 120
>> Atmospheric correction...
>
> See
> http://trac.osgeo.org/grass/ticket/2305
>
> Comments therein are desired,
>
> Markus
>


-- 

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

[GRASS-dev] i.topo.corr does not appear in the wxGUI menu

[Yann Chemin]

Hi,

For some reason i.topo.corr is not mapped to the menu or tree.


It should appear in:
Imagery=>Satellite images tools=> below i.atcorr entry

Yann
-- 

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

[GRASS-dev] pyGRASS not finding addons?

[Yann Chemin]

Hi,

Running GRASS through pyGRASS with an addon (i.eb.z0m) made this:

Traceback (most recent call last):
  File "L8.py", line 312, in 
i.eb_z0m( input = b_ndvi, output = b_z0m, quiet = QIET, overwrite = OVR )
  File "/usr/local/grass-7.1.svn/etc/python/grass/pygrass/modules/shortcuts.py",
line 50, in __getattr__
return self.cls('%s.%s' % (self.prefix, name.replace('_', '.')))
  File 
"/usr/local/grass-7.1.svn/etc/python/grass/pygrass/modules/interface/module.py",
line 272, in __init__
self.params_list = [Parameter(p) for p in tree.findall("parameter")]
  File 
"/usr/local/grass-7.1.svn/etc/python/grass/pygrass/modules/interface/parameter.py",
line 86, in __init__
self.typedesc = diz['gisprompt']['prompt']
KeyError: u'prompt'



-- 

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

Re: [GRASS-dev] [GRASS-SVN] r60879 - grass/trunk/lib/gis/colors

[Yann Chemin]

Thank you Markus,

updated in r60889

Yann

On 20/06/2014, Markus Neteler  wrote:
> On Fri, Jun 20, 2014 at 8:33 AM,   wrote:
>> Author: ychemin
>> Date: 2014-06-19 23:33:17 -0700 (Thu, 19 Jun 2014)
>> New Revision: 60879
>>
>> Added:
>>grass/trunk/lib/gis/colors/kelvin
>> Log:
>> Added Kelvin palette
>
> ... this is incomplete, it lacks the description in
> lib/gis/colors.desc
>
> Markus
>


-- 

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

Re: [GRASS-dev] GRASS 7 release planning

[Yann Chemin]

+1

On 21/06/2014, Markus Neteler  wrote:
> Hi devs,
>
> ... so, getting out 7.0 seems to be endless...
>
> A radical solution might be to change trunk into GRASS GIS 8. Then we
> do not need to wait in 7 for API stabilization and can release it "as
> is" and go ahead with the planned massive improvements.
>
> Best
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>


-- 

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

Re: [GRASS-dev] Significant r.in.gdal speed-up: predefined 300 MiB as default cache size

[Yann Chemin]

WoW ! Thanks Markus !

On 30 July 2014 21:42, Markus Neteler  wrote:
> Hi,
>
> I have made a modification to r.in.gdal for a (significant) speedup
> (both in trunk and relbranch70).
>
> A nice test case is the European 25m elevation model which is a 23GB
> GeoTIFF file of 4.8 billion raster cells:
>
> gdalinfo /geodata/eudem_dem_3035_europe.tif
> Driver: GTiff/GeoTIFF
> Files: /geodata/eudem_dem_3035_europe.tif
> Size is 24, 20
> Coordinate System is:
> PROJCS["ETRS89 / LAEA Europe",
> ...
> UNIT["metre",1,
> AUTHORITY["EPSG","9001"]],
> AUTHORITY["EPSG","3035"]]
> ...
> Pixel Size = (25.000,-25.000)
> ...
>
> Previously:
> # using default GDAL cache (~40MB, which is tiny also for gdalwarp etc!)
> GRASS 7.0.0svn (eu_laea):~ > time -p r.in.gdal
> /geodata/eudem_dem_3035_europe.tif \
>   output=eudem_dem_3035_europe
>  100%
> Raster map  created.
> r.in.gdal complete.
> real 279901.23
> user 267876.52
> sys 1456.18
> --> 77h
>
> New:
> # I have now defined 300MB as default cache size (i.e. memory=300)
> GRASS 7.0.0svn (eu_laea):~ > time -p r.in.gdal
> /geodata/eudem_dem_3035_europe.tif \
>   output=eu_dem_25m
>  100%
> Raster map  created.
> r.in.gdal complete.
> real 5381.95
> user 5091.27
> sys 31.03
> --> 1:30h
>
> The user can set different cache sizes via the memory option as
> before. Most probably didn't know about this huge difference, that's
> why I added 300MB as default cache size (rather than keeping the
> original tiny GDAL setting [1]).
>
> If I am not wrong, it took only 2% of the previous time for importing
> this big file.
> Perhaps the GDAL project should reconsider their default cache size as well 
> :-)
>
> enjoy,
> Markus
>
> [1] http://trac.osgeo.org/gdal/wiki/ConfigOptions#GDAL_CACHEMAX
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev



-- 

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

Re: [GRASS-dev] [GRASS GIS] #2456: read CSV from GDAL data directory (was: read cvs from GDAL data directory)

[Yann Chemin]

+1
On Oct 20, 2014 10:18 PM, "GRASS GIS"  wrote:

> #2456: read CSV from GDAL data directory
>
> -+--
>  Reporter:  martinl  |   Owner:  grass-dev@…
>  Type:  task |  Status:  new
>  Priority:  normal   |   Milestone:  7.1.0
> Component:  Default  | Version:  unspecified
>  Keywords:  gdal |Platform:  Unspecified
>   Cpu:  Unspecified  |
>
> -+--
> Description changed by martinl:
>
> Old description:
>
> > Currently GRASS contains copy of several CVS files from GDAL
> > source:grass/trunk/lib/proj. It would make sense to modify GRASS
> > libraries to read these files dynamically.
> >
> > Any comments?
>
> New description:
>
>  Currently GRASS contains copy of several CSV files from GDAL
>  source:grass/trunk/lib/proj. It would make sense to modify GRASS libraries
>  to read these files dynamically.
>
>  Any comments?
>
> --
>
> --
> Ticket URL: 
> GRASS GIS 
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] temporal framework used as spectral framework?

[Yann Chemin]

Hi,

just wondering if there is room to use the temporal framework as a basis
for hyperspectral work?

Cheers,
Yann

-- 

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