Re: [GRASS-dev] compilation of grass on AIX 7.1

[Hamish]

http://bugs.debian.org/672719:

> > LD_LIBRARY_PATH=":/build/buildd-grass_6.4.1-2.1-s390x-GTALEw/grass-6.4.1/dist.s390x-ibm-linux-gnu/lib"
> >  
> > ./test; diff ./test.tmp ../
  test.ok
  Killed
  make[6]: *** [OBJ.s390x-ibm-linux-gnu/test] Error 2

Markus M:
> That seems to me a problem on big endian systems, not related to LFS,
> fixed after 6.4.1. I would recommend to upgrade GRASS to either the
> latest 6.4.3 snapshot or to 7.0.

that's copied from an old bug report; Debian builds of modern versions
are ok for all of alpha, amd64, armel, armhf, i386, ia64, kfreebsd-amd64,
kfreebsd-i386, mips, mipsel, powerpc, powerpcspe, s390, sh4, and sparc.


regards,
Hamish

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

Re: [GRASS-dev] compilation of grass on AIX 7.1

[Markus Metz]

On Wed, Jun 19, 2013 at 6:10 AM, Hamish  wrote:
> Markus N wrote:
>
>> - diglib test updated in lib/vector/diglib/
>> --> still failing there, we try to understand

That has been fixed in 56699, it was related to LFS.

>
> hmm, this is quite similar, I wonder if it is related:
>
>   "grass: FTBFS on ppc64 and s390x"
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672719#17
>
>>> Errors in:
>>> /build/buildd-grass_6.4.1-2.1-s390x-GTALEw/grass-6.4.1/lib/vector/diglib
> ...
>>> cd OBJ.s390x-ibm-linux-gnu; \
>>> LD_LIBRARY_PATH=":/build/buildd-grass_6.4.1-2.1-s390x-GTALEw/grass-6.4.1/dist.s390x-ibm-linux-gnu/lib"
>>>  ./test; diff ./test.tmp ../
>>> test.ok
>>> Killed
>>> make[6]: *** [OBJ.s390x-ibm-linux-gnu/test] Error 2

That seems to me a problem on big endian systems, not related to LFS,
fixed after 6.4.1. I would recommend to upgrade GRASS to either the
latest 6.4.3 snapshot or to 7.0.

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

Re: [GRASS-dev] Proj4 string not shown in loc wiz when creating new location from file

[Markus Neteler]

On Wed, Jun 19, 2013 at 6:42 AM, Hamish  wrote:
> MarkusN wrote:
>> greetings from the amazing FOSS4G-CEE here in Bucharest
>> http://2013.foss4g-cee.org/program/schedule
>
> and greetings back to all you meet there, :)
> will your history of geoFOSS slides go online?

Sure:

http://www.slideshare.net/markusN/scaling-up-globally-30-years-of-foss4g-development-keynote-at-foss4gcee-2013-romania

...
> Is the first term of the above GEOGCS string legit or is it a r.out.gdal 
> string error?

Which string exactly? The file I generated like this:

- new GRASS location with EPSG:3035 from cmd line
- get into it, hence you are in a 1x2 current region
- r.mapcalc "eu_elevation = 1"
- r,out.gdal

Using Proj 4.8.0, 6 March 2012

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

Re: [GRASS-dev] Proj4 string not shown in loc wiz when creating new location from file

[Hamish]

Hamish:
> hmmm, I tested that a couple weeks ago and it was working, but now it 

> doesn't work for me

nope, there is only code for generating the +proj4 terms in the Summary page
for epsg and custom +proj terms (incl. defined from the table).
 (location_wizard.py line ~ 1659)

from geofile, wkt, and xy you get nothing for the summary.

I'm adding that now, but since it's just cosmetic and needs weeks of testing
I would not delay 6.4.3 for it. The more important side of that (which is
the main bit that needs testing) is detecting if it should ask you to set
datum transform terms.


Hamish

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

Re: [GRASS-dev] Proj4 string not shown in loc wiz when creating new location from file

[Hamish]

MarkusN wrote:
> greetings from the amazing FOSS4G-CEE here in Bucharest
> http://2013.foss4g-cee.org/program/schedule

and greetings back to all you meet there, :)
will your history of geoFOSS slides go online?


> Preparing my slides I remembered an issue that the proj4 string is not
> shown in case of generating a new location from a GeoTIFF (attached)
> or SHP.

hmmm, I tested that a couple weeks ago and it was working, but now it doesn't
work for me using either your sample tiff or some I have locally. WKT & .prj
creation method similarly has no output in the summary page, same with .shp.
The locations are created ok though except I don't get prompted for datum
transform terms.


> When using EPSG code as base for the new location this works fine.
>
> I can of course open a ticket but perhaps it is just an "easy"
> omission in the code.

Some tests:

gdalinfo shows:
{{{
PROJCS["Lambert Azimuthal Equal Area",
    GEOGCS["GCS Name = grs80|Ellipsoid = Geodetic_Reference_System_1980|Primem 
= Greenwich|",
    DATUM["European_Terrestrial_Reference_System_1989",
    SPHEROID["GRS 1980",6378137,298.2572221010002,
    AUTHORITY["EPSG","7019"]],
    AUTHORITY["EPSG","6258"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433]],
    PROJECTION["Lambert_Azimuthal_Equal_Area"],
    PARAMETER["latitude_of_center",52],
    PARAMETER["longitude_of_center",10],
    PARAMETER["false_easting",4321000],
    PARAMETER["false_northing",321],
    UNIT["metre",1,
    AUTHORITY["EPSG","9001"]]]
}}}

here is a little shell script to create a .prj file from that:
{{{
GEOTIFF=eu_elevation.tif
TOP=`gdalinfo "$GEOTIFF" | grep -n -m 1 '^Coordinate System is:$' | cut -f1 -d:`
BOT=`gdalinfo "$GEOTIFF" | grep -n -m 1 '^Origin = ' | cut -f1 -d:`
BOT=`expr "$BOT" - 1`
LINES=`expr "$BOT" - "$TOP"`

gdalinfo "$GEOTIFF" | head -n "$BOT" | tail -n "$LINES" > `basename "$GEOTIFF" 
.tif`.prj
}}}


Is the first term of the above GEOGCS string legit or is it a r.out.gdal string 
error?
(it doesn't seem to be the problem though, with  the other GeoTiff I had 
locally with
just "international" datum there, it still gave no +proj terms in the summary)


Using 'create new location from georef'd file' (latest 6.4.3svn) I end up with a
new location showing:

{{{
-PROJ_INFO-
name   : Lambert Azimuthal Equal Area
proj   : laea
datum  : etrs89
ellps  : grs80
lat_0  : 52
lon_0  : 10
x_0    : 4321000
y_0    : 321
no_defs    : defined
-PROJ_UNITS
unit   : metre
units  : metres
meters : 1
}}}

which looks ok. I think the only data loss there is the Primem = Greenwich,
but that may just be left off as matching the default.


I'll have a look at the code... perhaps due to a glitch in the last commit 
there.


Hamish

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

Re: [GRASS-dev] compilation of grass on AIX 7.1

[Hamish]

Markus N wrote:

> - diglib test updated in lib/vector/diglib/
>     --> still failing there, we try to understand

hmm, this is quite similar, I wonder if it is related:

  "grass: FTBFS on ppc64 and s390x"
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672719#17

>> Errors in:
>> /build/buildd-grass_6.4.1-2.1-s390x-GTALEw/grass-6.4.1/lib/vector/diglib
...
>> cd OBJ.s390x-ibm-linux-gnu; \
>> LD_LIBRARY_PATH=":/build/buildd-grass_6.4.1-2.1-s390x-GTALEw/grass-6.4.1/dist.s390x-ibm-linux-gnu/lib"
>>  ./test; diff ./test.tmp ../ 
>> test.ok 
>> Killed 
>> make[6]: *** [OBJ.s390x-ibm-linux-gnu/test] Error 2


Hamish

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

Re: [GRASS-dev] [GRASS GIS] #2009: thumbnails.py failure

[GRASS GIS]

#2009: thumbnails.py failure
+---
 Reporter:  neteler |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  7.0.0
Component:  Compiling   | Version:  svn-trunk
 Keywords:  r.colors, v.colors  |Platform:  All  
  Cpu:  Unspecified |  
+---
Changes (by hamish):

  * keywords:  r.colors v.colors => r.colors, v.colors


Comment:

 Anna - the new r.colors module GUI dropdown list looks brilliant. thanks!
 The information is right where/when you need it.

 Thumbnails in the help page fixed in trunk with r56787.

 some observations of further buglettes:

 I note in trunk there is some rendering error in the top-left corners of
 all the image boxes, manifested as a missing pixel. (in GRASS 6 there
 was/is a similar bug in d.barscale + Xdriver)

 Another rendering issue to be fixed: the absolute-value limited/libgis
 color tables (grey.eq, grey.log, and random) are too big by a few pixels
 on the right and bottom sides.

 We should do something better with the population palettes, maybe put them
 on a log-scale. Maybe the same with the precipitation palette. See the
 special rule for population in the old shell script version of the
 thumbnail generation script:
   http://grasswiki.osgeo.org/wiki/Talk:Color_tables

 Finally, this is a clear case where the Xdriver does a better job than the
 Cairo driver, compare the thumbnails in trunk with the crispness of the
 devbr6 versions:
   source:grass/branches/develbranch_6/raster/r.colors/thumbnails
 ... sometimes you want 1px lines to be exactly 1px wide, and no anti-
 aliasing.


 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] G7 compile error:

[Hamish]

Johannes wrote:
> Interestingly the compilation was working some days (maybe already weeks) ago.

Right, the code had been changed by a few people to work
with their local version of libav at the expense of people
using other versions. So in the last week or so I put in a
bunch of conditionals to try and make it work for everyone
using versions from the last year or three. In some cases
that makes it stricter. The reason that distros are abandoning
ffmpeg is that the API changes all the time and it is hard
for the packagers to keep up, so they seem to be transitioning
to a more stable but-compatible fork, and hopefully these
troubles become less.

And yes, for the grass7 code just leave off --with-ffmpeg
since it isn't used in the wxNVIZ currently/yet.



regards,
Hamish

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

Re: [GRASS-dev] G7 compile error:

[Hamish]

Johannes wrote:

>>  I just tried to compile the recent G7 SVN but several error appeared:
..,
>>  --
>>  Errors in:
>>  /usr/local/src/grass7_trunk/lib/ogsf
...
>>  OBJ.i686-pc-linux-gnu/gsd_img_mpeg.o -c gsd_img_mpeg.c
>>  gsd_img_mpeg.c:33:25: fatal error: mathematics.h: No such file or directory
>>  compilation terminated.

MarkusN:
> I have that on Fedora 18 in
> rpm -qf /usr/include/ffmpeg/libavutil/mathematics.h
> ffmpeg-devel-1.0.7-1.fc18.x86_64
> 
> Perhaps you need to install a similar package for your distro?
> (just guessing)

Hi,

fwiw the reason ./configure doesn't catch this one is that avutil.h
should be including mathematics.h internally, but for newer versions
(libavutil 51.22.1) it seems to forget that. Since we need av_rescale_q()
from it we conditionally depend on mathematics.h depending on the
libavutil version. I'm hoping it's their bug and that the libavutil
people will fix it before too long.


Hamish

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

Re: [GRASS-dev] Fwd: [GRASS-SVN] r56709 - grass/branches/develbranch_6/raster/r.li/r.li.setup

[Hamish]

Hamish:
> > g.gui.rlisetup.py naming


Luca wrote:
> For the name I think it is more consistent with the other
> grass7 GUI modules

I was questioning that naming convention for all
the grass7 gui modules, not g.gui.rlisetup.py in
particular.

Since they launch and run fine from the command line without
the rest of the wxGUI being loaded I guess it makes sense
and is ok actually.


nevermind,
Hamish

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

Re: [GRASS-dev] Fwd: [GRASS-SVN] r56709 - grass/branches/develbranch_6/raster/r.li/r.li.setup

[Luca Delucchi]

On 15 June 2013 12:09, Hamish  wrote:

>
> Hi Markus,
>

Hi Hamish

>
> For grass7 there is Luca's g.gui.rlisetup.py (I am not totally
> convinced about the g.gui.* naming), I am just keeping the raster/r.li
> r.li.setup dir in sync to avoid older code being in the "newer"
> branches. Much of r.li.setup will be deleted in trunk eventually since
> it needs Xmons, tcl/tk, shell scripts, etc. and is replaced by the
> wxPy version.
>

Hi think that r.li.setup could be removed from grass7.
For the name I think it is more consistent with the other grass7 GUI modules

>
> regards,
> Hamish
>

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] G7 compile error:

[Glynn Clements]

Johannes Radinger wrote:

> BTW: Can GRASS be configured without ffmpeg support?

FFMPEG support should be disabled by default (i.e. only enabled if you
use --with-ffmpeg).

> What is it needed for?

AFAIK, its only use was to allow NVIZ to save fly-throughs as video
files. I don't think that this feature is available in the wxGUI's
NVIZ component, and the original Tcl/Tk NVIZ is no longer present in
7.0. In which case, there's not much point in enabling it.

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

Re: [GRASS-dev] G7 compile error:

[Nikos Alexandris]

Johannes Radinger wrote:

> I just tried to compile the recent G7 SVN but several error appeared:
> 
> GRASS GIS 7.0.svn 56779M compilation log
> --
> Started compilation: Tue Jun 18 16:23:06 CEST 2013
> --
> Errors in:
> /usr/local/src/grass7_trunk/lib/ogsf
> /usr/local/src/grass7_trunk/lib/nviz
> /usr/local/src/grass7_trunk/misc/m.nviz.image
..
> So how do I have to deal with that problems?

Same errors here *before* removing the "--with-ffmpeg" option for the 
configuration process.  No errors currently (==yesterday).  See also ticket 
#1423:




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

Re: [GRASS-dev] G7 compile error:

[Johannes Radinger]

Interestingly the compilation was working some days (maybe already weeks)
ago.
I checked ffmpeg and there is a package installed:

ffmpeg version 0.8.6-4:0.8.6-0ubuntu0.12.04.1, Copyright (c) 2000-2013 the
Libav developers
  built on Apr  2 2013 17:00:59 with gcc 4.6.3
*** THIS PROGRAM IS DEPRECATED ***
This program is only provided for compatibility and will be removed in a
future release. Please use avconv instead.

So probably I also need to get the ffmpeg-devel installed. Will check that
tomorrow.

BTW: Can GRASS be configured without ffmpeg support? What is it needed for?

/johannes




On Tue, Jun 18, 2013 at 5:07 PM, Markus Neteler  wrote:

> On Tue, Jun 18, 2013 at 4:40 PM, Johannes Radinger
>  wrote:
> > Hi,
> >
> > I just tried to compile the recent G7 SVN but several error appeared:
> >
> > GRASS GIS 7.0.svn 56779M compilation log
> > --
> > Started compilation: Tue Jun 18 16:23:06 CEST 2013
> > --
> > Errors in:
> > /usr/local/src/grass7_trunk/lib/ogsf
>
> ...
> > radinger@grassgis:/usr/local/src/grass7_trunk$ cd
> > /usr/local/src/grass7_trunk/lib/ogsf
> > radinger@grassgis:/usr/local/src/grass7_trunk/lib/ogsf$ make
> > gcc  -g  -fPIC
>  -I/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/include
> > -I/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/include
> > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdal
> > -I/usr/include  -DPACKAGE=\""grasslibs"\" -I/usr/include/libavcodec
> > -I/usr/include/libavformat -I/usr/include/libswscale
> > -I/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/include
> > -I/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/include -o
> > OBJ.i686-pc-linux-gnu/gsd_img_mpeg.o -c gsd_img_mpeg.c
> > gsd_img_mpeg.c:33:25: fatal error: mathematics.h: No such file or
> directory
> > compilation terminated.
>
> I have that on Fedora 18 in
> rpm -qf /usr/include/ffmpeg/libavutil/mathematics.h
> ffmpeg-devel-1.0.7-1.fc18.x86_64
>
> Perhaps you need to install a similar package for your distro?
> (just guessing)
>
> On F18 it compiles.
>
> Markus
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] G7 compile error:

[Markus Neteler]

On Tue, Jun 18, 2013 at 4:40 PM, Johannes Radinger
 wrote:
> Hi,
>
> I just tried to compile the recent G7 SVN but several error appeared:
>
> GRASS GIS 7.0.svn 56779M compilation log
> --
> Started compilation: Tue Jun 18 16:23:06 CEST 2013
> --
> Errors in:
> /usr/local/src/grass7_trunk/lib/ogsf

...
> radinger@grassgis:/usr/local/src/grass7_trunk$ cd
> /usr/local/src/grass7_trunk/lib/ogsf
> radinger@grassgis:/usr/local/src/grass7_trunk/lib/ogsf$ make
> gcc  -g  -fPIC  -I/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/include
> -I/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/include
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdal
> -I/usr/include  -DPACKAGE=\""grasslibs"\" -I/usr/include/libavcodec
> -I/usr/include/libavformat -I/usr/include/libswscale
> -I/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/include
> -I/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/include -o
> OBJ.i686-pc-linux-gnu/gsd_img_mpeg.o -c gsd_img_mpeg.c
> gsd_img_mpeg.c:33:25: fatal error: mathematics.h: No such file or directory
> compilation terminated.

I have that on Fedora 18 in
rpm -qf /usr/include/ffmpeg/libavutil/mathematics.h
ffmpeg-devel-1.0.7-1.fc18.x86_64

Perhaps you need to install a similar package for your distro?
(just guessing)

On F18 it compiles.

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

[GRASS-dev] G7 compile error:

[Johannes Radinger]

Hi,

I just tried to compile the recent G7 SVN but several error appeared:

GRASS GIS 7.0.svn 56779M compilation log
--
Started compilation: Tue Jun 18 16:23:06 CEST 2013
--
Errors in:
/usr/local/src/grass7_trunk/lib/ogsf
/usr/local/src/grass7_trunk/lib/nviz
/usr/local/src/grass7_trunk/misc/m.nviz.image
--
In case of errors please change into the directory with error and run
'make'.
If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you will
also get errors from anything which uses the library.
--
Finished compilation: Tue Jun 18 16:34:38 CEST 2013
make: *** [default] Error 1

radinger@grassgis:/usr/local/src/grass7_trunk$ cd
/usr/local/src/grass7_trunk/lib/ogsf
radinger@grassgis:/usr/local/src/grass7_trunk/lib/ogsf$ make
gcc  -g  -fPIC
-I/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/include
-I/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdal
-I/usr/include  -DPACKAGE=\""grasslibs"\" -I/usr/include/libavcodec
-I/usr/include/libavformat -I/usr/include/libswscale
-I/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/include
-I/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/include -o
OBJ.i686-pc-linux-gnu/gsd_img_mpeg.o -c gsd_img_mpeg.c
gsd_img_mpeg.c:33:25: fatal error: mathematics.h: No such file or directory
compilation terminated.
make: *** [OBJ.i686-pc-linux-gnu/gsd_img_mpeg.o] Error 1

radinger@grassgis:/usr/local/src/grass7_trunk/lib/ogsf$ cd
/usr/local/src/grass7_trunk/lib/nviz/
radinger@grassgis:/usr/local/src/grass7_trunk/lib/nviz$ make
gcc -shared -o /usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/lib/
libgrass_nviz.7.0.svn.so-L/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/lib
-L/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/lib
-Wl,--export-dynamic  -L/usr/lib
-Wl,-rpath-link,/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/lib
OBJ.i686-pc-linux-gnu/change_view.o OBJ.i686-pc-linux-gnu/cplanes_obj.o
OBJ.i686-pc-linux-gnu/draw.o OBJ.i686-pc-linux-gnu/exag.o
OBJ.i686-pc-linux-gnu/lights.o OBJ.i686-pc-linux-gnu/map_obj.o
OBJ.i686-pc-linux-gnu/nviz.o OBJ.i686-pc-linux-gnu/position.o
OBJ.i686-pc-linux-gnu/render.o  -lgrass_ogsf.7.0.svn -lgrass_gis.7.0.svn
-L/usr/include/GL  -lGL   -lSM -lICE -lX11  -lm
/usr/bin/ld: cannot find -lgrass_ogsf.7.0.svn
collect2: ld returned 1 exit status
make: *** [/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/lib/
libgrass_nviz.7.0.svn.so] Error 1

radinger@grassgis:/usr/local/src/grass7_trunk/lib/nviz$ cd
/usr/local/src/grass7_trunk/misc/m.nviz.image/
radinger@grassgis:/usr/local/src/grass7_trunk/misc/m.nviz.image$ make
make: *** No rule to make target
`/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/lib/
libgrass_ogsf.7.0.svn.so', needed by
`/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/bin/m.nviz.image'.
Stop.


So how do I have to deal with that problems?

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

Re: [GRASS-dev] Unexpected EVI range from "i.vi"

[Markus Metz]

On Mon, Jun 17, 2013 at 10:58 PM, Nikos Alexandris
 wrote:
> Markus Metz wrote:
>
>> Feeding the test values and the evi(2) formula to r.mapcalc, the
>> results are more or less in the expected range, still beyond [-1, 1],
>> but not much.
>
> [cut]
>
> Yes, but feeding the "suspect" values in r.mapcalc, still gives, correctly,
> large/out of range (regarding EVI's expected range) result(s).

Just to confirm, the suspect values are

> blue <- 0.230260364323039
> red <- 0.110923862670943
> nir <- 0.0614305088322746
> evi <- ( 2.5 * ( nir - red) ) / (nir + 6 * red - 7 * blue + 1.0)
> evi
[1] -1.07453

and

> blue <- 0.228143006540123
> red <- 0.106632395012542
> nir <- 0.0712654621906476
> evi <- ( 2.5 * ( nir - red) ) / (nir + 6 * red - 7 * blue + 1.0)
> evi
[1] -0.7751909

?

Using r.mapcalc I get the same results like in R, not
-5905.44171917482 or 6952.80543731566, respectively. Why are the way
out of range values correct if R produces reasonable results?

Markus M


>
> Anyhow, just to have a quick-check on "r.what", should I upload the bands in
> question somewhere?  Would anyone have the time to explain/check why r.what
> gives different results depending on the extent/resolution for the same
> coordinates?  Which, might be expected, but why does "g.region rows=1 cols=1"
> set the resolution to... see below:

That explained Moritz. I would only add that you should align the
region to the raster (not the raster's resolution, these are two
different things), before using r.what, otherwise the raster lib will
do some internal nn resamplng (if the region's resoltion is larger
than the raster's resolution).

>
> Nikos
>
>
> Nikos Alexandris:
>
> [snip]
>
>> > Now, "pointing" to the suspect pixel:
>> >
>> > # both res=30  &  res=1 give the same result, of course
>> > g.region -pagc e=784935 n=2695215 rows=1 cols=1 res=30
> ---^--^-^^
>> >
>> > n=2695230
>> > s=2621340
>> > w=658560
>> > e=784950
>
> --vv
>> > nsres=73890
>> > ewres=126390
> --^^
>
>> > rows=1
>> > cols=1
>> > cells=1
>> > center_easting=721755.00
>> > center_northing=2658285.00
>> >
>> > # what is there?
>> > r.what coordinates=784935,2695215
>> > map=B.Trimmed.ToAR.1,B.Trimmed.ToAR.3,B.Trimmed.ToAR.4,evi_DN,evi_ToAR
>> >
>> > 784935|2695215||0.264138088849702|0.372703389833447|
>> > 0.438437054236573|-0.203045685279188|0.0970312073830427
>> >
>> > [..]
>> >
>> > I guess it has to do with the extent/res definitions...
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #86: d.rast.edit.tcl: doesn't start from wxPython without aspect map

[GRASS GIS]

#86: d.rast.edit.tcl: doesn't start from wxPython without aspect map
---+
 Reporter:  hamish |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  major  |   Milestone:  6.4.4
Component:  wxGUI  | Version:  6.4.0 RCs
 Keywords:  d.rast.edit, wingrass  |Platform:  MSWindows XP 
  Cpu:  Unspecified|  
---+

Comment(by hamish):

 for the record: aspect maps + d.rast.edit.tcl work on WinGrass now, so the
 aspect map workaround isn't just ignoring a bigger problem. (it may well
 be ignoring some other problem, but seeing that tcl from wx on wingrass is
 pretty rare, I'll worry about that problem when it arrives)

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #86: d.rast.edit.tcl: doesn't start from wxPython without aspect map

[GRASS GIS]

#86: d.rast.edit.tcl: doesn't start from wxPython without aspect map
---+
 Reporter:  hamish |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  major  |   Milestone:  6.4.4
Component:  wxGUI  | Version:  6.4.0 RCs
 Keywords:  d.rast.edit, wingrass  |Platform:  MSWindows XP 
  Cpu:  Unspecified|  
---+
Changes (by hamish):

  * milestone:  6.4.3 => 6.4.4


Comment:

 mandatory aspect map fix and wingrass PATH env work-around backported to
 6.4svn in r56784.

 the d.rast.edit.tcl module gui still never gets the message that the child
 process has returned (both Windows and Linux), stays with greyed out
 buttons until you "X" its window, and the no --overwrite error message
 still ends up in the cmd.exe terminal window, but neither is critical for
 6.4.3 so bumping down the road.


 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1163: wx wms import tool error

[GRASS GIS]

#1163: wx wms import tool error
---+
  Reporter:  hamish|   Owner:  grass-dev@…  
  Type:  defect|  Status:  closed   
  Priority:  major |   Milestone:  6.4.3
 Component:  wxGUI | Version:  svn-develbranch6 
Resolution:  fixed |Keywords:  wingrass, wms, r.in.wms  
  Platform:  MSWindows XP  | Cpu:  x86-64   
---+
Changes (by hamish):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 xml2 check for the wms tool tested ok and backported to 6.4svn with
 r56783.

 #820 remains open for r.in.wms[.sh] on MS Windows issues, continued
 there...


 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #820: r.in.wms doesn't work in WinGRASS installer distribution

[GRASS GIS]

#820: r.in.wms doesn't work in WinGRASS installer distribution
---+
 Reporter:  ddalimonte |   Owner:  hamish 
 Type:  defect |  Status:  new
 Priority:  major  |   Milestone:  6.4.4  
Component:  Projections/Datums | Version:  svn-releasebranch64
 Keywords:  r.in.wms, wingrass, cs2cs  |Platform:  MSWindows XP   
  Cpu:  All|  
---+
Changes (by hamish):

  * milestone:  6.4.3 => 6.4.4


Comment:

 Replying to [comment:49 hamish]:
 > It fails anytime when `xml2` is not available, so not a wingrass bug
 > per se, xml2.exe just happens to be missing there (see #1952).
 ...
 > attempt to catch that and abort with an informative error message added
 > to devbr6 in r56743 for testing.

 tested ok and backported to 6.4svn with r56783.

 cs2cs + grid paths is likely still a problem, more testing needed. On the
 other hand basic functionality is present so changing the milestone to
 6.4.4.

 TBC ...


 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #945: wxGUI: g.setproj fails

[GRASS GIS]

#945: wxGUI: g.setproj fails
---+
 Reporter:  hamish |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  major  |   Milestone:  6.4.4
Component:  wxGUI  | Version:  svn-releasebranch64  
 Keywords:  g.setproj  |Platform:  All  
  Cpu:  All|  
---+
Changes (by hamish):

  * priority:  critical => major
  * milestone:  6.4.3 => 6.4.4


Comment:

 re. the pager problem, actually it wasn't failing gracefully, it was
 #ifdef'd out for wingrass. #ifdef removed, tested the pager with g.list
 and g.setproj in devbr6 and it works now with the isatty()-able cmd.exe
 window. backported to 6.4svn in r56780.

 r.digit and g.setproj now start ok from the wxGUI menu, with and without
 Xmons.


 
 Final issue to resolve before closing this bug:
  * GRASS_MESSAGE_FORMAT ugliness remains, see comment:7 and comment:8 in
 this ticket for a possible solution.

 that's not critical, so bumping it down the road to 6.4.4 ...


 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Unexpected EVI range from "i.vi"

[Moritz Lennert]

On Mon, June 17, 2013 22:58, Nikos Alexandris wrote:
> Markus Metz wrote:
>
>> Feeding the test values and the evi(2) formula to r.mapcalc, the
>> results are more or less in the expected range, still beyond [-1, 1],
>> but not much.
>
> [cut]
>
> Yes, but feeding the "suspect" values in r.mapcalc, still gives,
> correctly,
> large/out of range (regarding EVI's expected range) result(s).
>
> Anyhow, just to have a quick-check on "r.what", should I upload the bands
> in
> question somewhere?  Would anyone have the time to explain/check why
> r.what
> gives different results depending on the extent/resolution for the same
> coordinates?  Which, might be expected, but why does "g.region rows=1
> cols=1"
> set the resolution to... see below:

[...]

>> > g.region -pagc e=784935 n=2695215 rows=1 cols=1 res=30
> ---^--^-^^
>> >
>> > n=2695230
>> > s=2621340
>> > w=658560
>> > e=784950
>
> --vv
>> > nsres=73890
>> > ewres=126390
> --^^

rows and cols has precedence over res, but res=30 plus -a still has an
effect, so you get an extension that is in multiples of 30, with a
resolution equal to the total extension, since you asked for one row and
one col.

Moritz

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

Re: [GRASS-dev] [GRASS GIS] #1144: m.cogo- add type options

[GRASS GIS]

#1144: m.cogo- add type options
+---
 Reporter:  needelsd|   Owner:  grass-dev@…  
 Type:  enhancement |  Status:  new  
 Priority:  minor   |   Milestone:  7.0.0
Component:  Vector  | Version:  svn-trunk
 Keywords:  import, m.cogo, v.type  |Platform:  All  
  Cpu:  All |  
+---
Changes (by hamish):

  * keywords:  import m.cogo v.type => import, m.cogo, v.type
  * priority:  normal => minor
  * version:  unspecified => svn-trunk
  * milestone:  6.5.0 => 7.0.0


Comment:

 example of how to do that with the new -c flag added in r56768,9 for
 devbr6 and trunk.

 for the record it does not import anything itself (yet), it just prints a
 string of coords to stdout.


 Hamish

-- 
Ticket URL: 
GRASS GIS 

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