Re: [GRASS-dev] color tables
Helena wrote: I often get a question why there aren't images of color tables in GRASS GUI along with their names. Is this technically feasible? Or it is already there and I just don't see it? I don't think it's there. I am thinking about adding them to the r.colors man page, but first I IMhO these sorts of things should go in the wiki, not the man page. Anything but simple PNG figures add a huge amount to the bulk of the SVN and .tar.gz release sizes. would like to ask whether somebody has done this already (or has a script to do it). I was thinking about running something like this through all color tables set GRASS_WIDTH=50 and GRASS_HEIGHT=100 r.colors elev co=ryg d.colortable elev d.out.file ryg_col d.erase convert -rotate 90 ryg_col I have made a little script which does the trick, I'll post it to the wiki shortly at http://grass.osgeo.org/wiki/Raster_color_tables Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.5 GEOS build fails
Hi, 2009/8/8 Markus Neteler nete...@osgeo.org: [...] but in conftest.c it is: char GEOSGeom_createLinearRing(); No idea how to fix the test in configure.in. hopefully fixed in r38867. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #736: r.proj fails in wingrass
#736: r.proj fails in wingrass
--+-
Reporter: cnielsen | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Raster | Version: unspecified
Resolution: |Keywords: r.proj, wingrass
Platform: MSWindows Vista | Cpu: x86-32
--+-
Comment (by hamish):
As is the case once again with these wingrass bugs, valgrind finds some
memory errors which are apparently benign on UNIX.
setup:
{{{
#getset region
spearfish g.region -dbg
#
#create and enter a LL/WGS84 location
ll_wgs84 g.region n=44.50173527 s=44.37032007 \
w=-103.87110972 e=-103.62942673 res=0:00:01 -ap
ll_wgs84 CMD=r.proj in=elevation.dem loc=spearfish60 mapset=PERMANENT
ll_wgs84 valgrind --tool=memcheck --leak-check=yes --show-reachable=yes
$CMD
}}}
result:
(GRASS 6.5svn on Debian/Etch 32bit i686 linux)
{{{
==5114== Memcheck, a memory error detector.
==5114== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==5114== Using LibVEX rev 1658, a library for dynamic binary translation.
==5114== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==5114== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation
framework.
==5114== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==5114== For more details, rerun with: -v
==5114==
Input Projection Parameters: +proj=utm +zone=13 +a=6378206.4
+rf=294.9786982 +no_defs +nadgrids=$GISBASE/etc/nad/conus
Input Unit Factor: 1
Output Projection Parameters: +proj=longlat +a=6378137 +rf=298.257223563
+no_defs +towgs84=0.000,0.000,0.000
Output Unit Factor: 1
Input:
Cols: 633 (633)
Rows: 466 (466)
North: 4928000.00 (4928000.00)
South: 4914020.00 (4914020.00)
West: 590010.00 (590010.00)
East: 609000.00 (609000.00)
EW-res: 30.00
NS-res: 30.00
Output:
Cols: 868 (871)
Rows: 462 (474)
North: 44.501667 (44.501944)
South: 44.37 (44.370278)
West: -103.870556 (-103.87)
East: -103.629444 (-103.629167)
EW-res: 0.000278
NS-res: 0.000278
Allocating memory and reading input map...
==5114== Syscall param write(buf) points to uninitialised byte(s)
==5114==at 0x4000792: (within /lib/ld-2.3.6.so)
==5114==by 0x804BF58: main (main.c:391)
==5114== Address 0x6366A0C is 2,532 bytes inside a block of size 163,840
alloc'd
==5114==at 0x401D38B: malloc (vg_replace_malloc.c:149)
==5114==by 0x4037B8D: G__malloc (alloc.c:41)
==5114==by 0x804C7D7: readcell (readcell.c:68)
==5114==by 0x804BF58: main (main.c:391)
100%
Projecting...
100%
==5114==
==5114== Invalid read of size 4
==5114==at 0x4010DE9: (within /lib/ld-2.3.6.so)
==5114==by 0x4004B78: (within /lib/ld-2.3.6.so)
==5114==by 0x4006792: (within /lib/ld-2.3.6.so)
==5114==by 0x479246F: (within /lib/tls/i686/cmov/libc-2.3.6.so)
==5114==by 0x400B44E: (within /lib/ld-2.3.6.so)
==5114==by 0x4791EDE: _dl_open (in /lib/tls/i686/cmov/libc-2.3.6.so)
==5114==by 0x47946FC: (within /lib/tls/i686/cmov/libc-2.3.6.so)
==5114==by 0x400B44E: (within /lib/ld-2.3.6.so)
==5114==by 0x479475D: __libc_dlopen_mode (in
/lib/tls/i686/cmov/libc-2.3.6.so)
==5114==by 0x476E7CF: __nss_lookup_function (in
/lib/tls/i686/cmov/libc-2.3.6.so)
==5114==by 0x476E8BF: (within /lib/tls/i686/cmov/libc-2.3.6.so)
==5114==by 0x47704E5: __nss_passwd_lookup (in
/lib/tls/i686/cmov/libc-2.3.6.so)
==5114== Address 0x6361B3C is 36 bytes inside a block of size 38 alloc'd
==5114==at 0x401D38B: malloc (vg_replace_malloc.c:149)
==5114==by 0x4006B83: (within /lib/ld-2.3.6.so)
==5114==by 0x479246F: (within /lib/tls/i686/cmov/libc-2.3.6.so)
==5114==by 0x400B44E: (within /lib/ld-2.3.6.so)
==5114==by 0x4791EDE: _dl_open (in /lib/tls/i686/cmov/libc-2.3.6.so)
==5114==by 0x47946FC: (within /lib/tls/i686/cmov/libc-2.3.6.so)
==5114==by 0x400B44E: (within /lib/ld-2.3.6.so)
==5114==by 0x479475D: __libc_dlopen_mode (in
/lib/tls/i686/cmov/libc-2.3.6.so)
==5114==by 0x476E7CF: __nss_lookup_function (in
/lib/tls/i686/cmov/libc-2.3.6.so)
==5114==by 0x476E8BF: (within /lib/tls/i686/cmov/libc-2.3.6.so)
==5114==by 0x47704E5: __nss_passwd_lookup (in
/lib/tls/i686/cmov/libc-2.3.6.so)
==5114==by 0x471EB6E: getpwuid_r (in /lib/tls/i686/cmov/libc-2.3.6.so)
==5114==
==5114== Conditional jump or move depends on uninitialised value(s)
==5114==at 0x4008ED5: (within /lib/ld-2.3.6.so)
==5114==by 0x47928C4: (within /lib/tls/i686/cmov/libc-2.3.6.so)
==5114==by 0x400B44E: (within /lib/ld-2.3.6.so)
==5114==by 0x4791EDE: _dl_open (in
[GRASS-dev] Re: [GRASS GIS] #736: r.proj fails in wingrass
#736: r.proj fails in wingrass
--+-
Reporter: cnielsen | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Raster | Version: unspecified
Resolution: |Keywords: r.proj, wingrass
Platform: MSWindows Vista | Cpu: x86-32
--+-
Comment (by jef):
Replying to [ticket:736 cnielsen]:
By adding a couple debug lines I found out it is crashing on
[http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/raster/r.proj.seg/main.c#L280
line 280]
{{{
pj_print_proj_params(iproj, oproj);
}}}
[http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/lib/proj/get_proj.c#L396
pj_print_proj_params()] uses G_free() to free a string returned from PROJ,
where it should use pj_free().
--
Ticket URL: http://trac.osgeo.org/grass/ticket/736#comment:3
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #707: wxGUI: v.digit broken for new maps: No vector map selected for editing. although selected
#707: wxGUI: v.digit broken for new maps: No vector map selected for editing. although selected --+- Reporter: neteler | Owner: martinl Type: defect | Status: assigned Priority: blocker | Milestone: 6.4.0 Component: wxGUI| Version: 6.4.0 RCs Resolution: |Keywords: vector digitizer, vdigit Platform: Linux| Cpu: All --+- Comment (by martinl): Replying to [comment:1 martinl]: Works for me. '...' in 'command output' tab indicates that some messages have been printed out. Or set GRASS_WX_DEBUG=1 to redirect error messages to the xterm. Can you send traceback message from the command output? Martin -- Ticket URL: http://trac.osgeo.org/grass/ticket/707#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-SVN] r38872 - grass/trunk
2009/8/26 svn_gr...@osgeo.org: Author: glynn Date: 2009-08-26 08:41:06 -0400 (Wed, 26 Aug 2009) New Revision: 38872 Modified: grass/trunk/configure grass/trunk/configure.in Log: Revert r38867 (bogus GEOM check) can you explain why it's bogus. Now configuration fails with checking for geos-config... /usr/local/bin/geos-config checking for geos_c.h... yes checking for GEOSGeom_createLinearRing in -lgeos... no configure: error: *** Unable to locate GEOS library. initGEOS or GEOSGeom_createLinearRing are defined in GEOS C API (geos_c)... Martin -- Martin Landa landa.martin gmail.com * 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] GRASS 6.5 GEOS build fails
Martin Landa wrote: but in conftest.c it is: char GEOSGeom_createLinearRing(); No idea how to fix the test in configure.in. hopefully fixed in r38867. No. Broken in r38867; fixed (i.e. reverted) in r38872. GRASS needs GEOS 3.x; the check is supposed to fail on older versions. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.5 GEOS build fails
Hi, 2009/8/26 Glynn Clements gl...@gclements.plus.com: No. Broken in r38867; fixed (i.e. reverted) in r38872. Sorry, on my computer is broken now... GRASS needs GEOS 3.x; the check is supposed to fail on older versions. geos-config --version 3.1.0 checking for geos-config... /usr/local/bin/geos-config checking for geos_c.h... yes checking for GEOSGeom_createLinearRing in -lgeos... no configure: error: *** Unable to locate GEOS library. Martin -- Martin Landa landa.martin gmail.com * 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] GRASS 6.5 GEOS build fails
2009/8/26 Martin Landa landa.mar...@gmail.com: checking for geos-config... /usr/local/bin/geos-config checking for geos_c.h... yes checking for GEOSGeom_createLinearRing in -lgeos... no configure: error: *** Unable to locate GEOS library. as I mentioned earlier it should check geos_c (i.e. GEOS C API) not geos. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #736: r.proj fails in wingrass
#736: r.proj fails in wingrass --+- Reporter: cnielsen | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: normal | Milestone: 6.4.0 Component: Raster | Version: unspecified Resolution: |Keywords: r.proj, wingrass Platform: MSWindows Vista | Cpu: x86-32 --+- Comment (by glynn): Replying to [comment:3 jef]: [http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/lib/proj/get_proj.c#L396 pj_print_proj_params()] uses G_free() to free a string returned from PROJ, where it should use pj_free(). Fixed in r38873 (7.0). -- Ticket URL: http://trac.osgeo.org/grass/ticket/736#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #736: r.proj fails in wingrass
#736: r.proj fails in wingrass --+- Reporter: cnielsen | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: normal | Milestone: 6.4.0 Component: Raster | Version: unspecified Resolution: |Keywords: r.proj, wingrass Platform: MSWindows Vista | Cpu: x86-32 --+- Comment (by martinl): Replying to [comment:4 glynn]: Replying to [comment:3 jef]: [http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/lib/proj/get_proj.c#L396 pj_print_proj_params()] uses G_free() to free a string returned from PROJ, where it should use pj_free(). Fixed in r38873 (7.0). Backported in r38874 (6.5) and r38875 (6.4). -- Ticket URL: http://trac.osgeo.org/grass/ticket/736#comment:5 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #736: r.proj fails in wingrass
#736: r.proj fails in wingrass --+- Reporter: cnielsen | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: normal | Milestone: 6.4.0 Component: Raster | Version: unspecified Resolution: |Keywords: r.proj, wingrass Platform: MSWindows Vista | Cpu: x86-32 --+- Comment (by cnielsen): Not fixed yet. Same error comes up after update. It prints the Input Projection Parameters which is the line above the now pj_free, but hangs at pj_free [http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/lib/proj/get_proj.c?rev=38875#L405 line 405 of get_proj.c] -- Ticket URL: http://trac.osgeo.org/grass/ticket/736#comment:6 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] SQLite 3 SQL logic error
Dear all, I have been trying in vain to store some very simple GRASS vector map in an SQLite3 DBMS using v.out.ogr. The data consists of only 93 3D points with attached integer and double attributes. No complex shapes, timestamps, text or blobs. Using v.out.ogr, I get: ERROR 1: sqlite3_step() failed: SQL logic error or missing database for all except the first record, which gets stored correctly in the (new) database. It is not possible to test this with an existing SQLite database file, because v.out.ogr in RC5 does not support the OGR update action. I have searched the Trac system for clues and found one ticket that may be related: http://trac.osgeo.org/grass/ticket/548 I have also tried this with different versions of SQLite and on different Linux systems, but always with the same result. My setup: 32Bit Gentoo Linux GRASS 6.4RC5 SQLite 3.6.16 GDAL 1.6.1 (SQLite driver using native code, not linked to spatialite) Is there anybody here experiencing the same problems? Any idea where to start looking? I am very interested in making external SQLite support via OGR work, but have no clue where to start looking to resolve the problem, so any ideas are more than welcome! Thanks, Ben -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #736: r.proj fails in wingrass
#736: r.proj fails in wingrass --+- Reporter: cnielsen | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: normal | Milestone: 6.4.0 Component: Raster | Version: unspecified Resolution: |Keywords: r.proj, wingrass Platform: MSWindows Vista | Cpu: x86-32 --+- Comment (by jef): Replying to [comment:6 cnielsen]: Not fixed yet. Same error comes up after update. It prints the Input Projection Parameters which is the line above the now pj_free, but hangs at pj_free [http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/lib/proj/get_proj.c?rev=38875#L405 line 405 of get_proj.c] Ouch. It's not pj_free(), it's pj_dalloc() (just like in #537). Sorry. -- Ticket URL: http://trac.osgeo.org/grass/ticket/736#comment:7 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #736: r.proj fails in wingrass
#736: r.proj fails in wingrass --+- Reporter: cnielsen | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: normal | Milestone: 6.4.0 Component: Raster | Version: unspecified Resolution: |Keywords: r.proj, wingrass Platform: MSWindows Vista | Cpu: x86-32 --+- Comment (by jef): Replying to [comment:7 jef]: Ouch. It's not pj_free(), it's pj_dalloc() (just like in #537). Sorry. And #468. How embarassing - sorry again. -- Ticket URL: http://trac.osgeo.org/grass/ticket/736#comment:8 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #477: d.vect: segfault if zcolor= does not exist
#477: d.vect: segfault if zcolor= does not exist --+- Reporter: hamish | Owner: martinl Type: defect | Status: closed Priority: major| Milestone: 6.4.0 Component: default | Version: svn-develbranch6 Resolution: fixed|Keywords: d.vect Platform: Linux| Cpu: x86-32 --+- Changes (by martinl): * status: assigned = closed * resolution: = fixed Comment: Replying to [comment:2 martinl]: Fixed in devbr6, r38367. Any objections to backport it to relbr64? Already done by Markus in r38570. Closing the ticket. Martin -- Ticket URL: http://trac.osgeo.org/grass/ticket/477#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #710: v.db.select: allow output to a file
#710: v.db.select: allow output to a file --+- Reporter: mlennert | Owner: martinl Type: enhancement | Status: assigned Priority: normal | Milestone: 6.5.0 Component: Vector | Version: svn-trunk Resolution: |Keywords: v.db.select file Platform: Unspecified | Cpu: Unspecified --+- Comment (by martinl): Replying to [comment:5 mlennert]: Replying to [comment:2 martinl]: Slightly changed patch applied in trunk, r38606. I have changed output to file. If reasonable I will backport it to devbr6. Thanks a lot. Should this also be implemented in db.select ? Done in r38876 (and backported to devbr6 in r38877). Can we close the ticket now? Martin -- Ticket URL: http://trac.osgeo.org/grass/ticket/710#comment:6 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #457: wxGui, layer manager: copy/paste/save layer; workspace load in Display n (not only in 1)
#457: wxGui, layer manager: copy/paste/save layer; workspace load in Display n (not only in 1) --+- Reporter: paoloC | Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: normal | Milestone: 6.5.0 Component: wxGUI| Version: unspecified Resolution: |Keywords: layer manager Platform: Unspecified | Cpu: Unspecified --+- Changes (by martinl): * cc: martinl (added) * keywords: = layer manager * priority: major = normal * milestone: 6.4.0 = 6.5.0 -- Ticket URL: http://trac.osgeo.org/grass/ticket/457#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-SVN] r38872 - grass/trunk
Martin Landa wrote: Author: glynn Date: 2009-08-26 08:41:06 -0400 (Wed, 26 Aug 2009) New Revision: 38872 Modified: grass/trunk/configure grass/trunk/configure.in Log: Revert r38867 (bogus GEOM check) can you explain why it's bogus. Now configuration fails with checking for geos-config... /usr/local/bin/geos-config checking for geos_c.h... yes checking for GEOSGeom_createLinearRing in -lgeos... no configure: error: *** Unable to locate GEOS library. It's bogus insofar as the check succeeds but GRASS fails to compile due to GEOS-related errors. Checks are, well, checks; they're supposed to fail if everything isn't in order. [However I have just discovered that the problems aren't related to the libraries, only the headers. IOW, the check wasn't specifically wrong, just insufficient; but it turns out to be easier to make GEOS 2.x work than to detect and avoid it.] Although, my errors weren't those in Markus' original post; instead: make[4]: Entering directory `/usr/local/src/grass/svn/lib/vector/diglib' test -d OBJ.i686-pc-linux-gnu || mkdir -p OBJ.i686-pc-linux-gnu gcc -I/usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include -I/usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include -g -Wall -Wno-parentheses -Wno-format-zero-length -fPIC -I/usr/local/include -I/usr/include -D_FILE_OFFSET_BITS=64 -DPACKAGE=\grasslibs\ -I/usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include -I/usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/allocation.o -c allocation.c In file included from allocation.c:21: /usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include/grass/vector.h:479: error: syntax error before '*' token /usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include/grass/vector.h:479: warning: type defaults to `int' in declaration of `Vect_read_line_geos' /usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include/grass/vector.h:479: warning: data definition has no type or storage class /usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include/grass/vector.h:483: error: syntax error before '*' token /usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include/grass/vector.h:483: warning: type defaults to `int' in declaration of `Vect_get_isle_points_geos' /usr/local/src/grass/svn/dist.i686-pc-linux-gnu/include/grass/vector.h:483: warning: data definition has no type or storage class Lines 479-483 of vector.h are: GEOSGeometry *Vect_read_line_geos(struct Map_info *, int, int*); GEOSGeometry *Vect_line_to_geos(struct Map_info *, const struct line_pnts*, int); GEOSGeometry *Vect_read_area_geos(struct Map_info *, int); GEOSCoordSequence *Vect_get_area_points_geos(struct Map_info *, int); GEOSCoordSequence *Vect_get_isle_points_geos(struct Map_info *, int); The error indicates that it doesn't understand the types. No surprise there, as neither GEOSGeometry nor GEOSCoordSequence appear in my version of geos_c.h (GEOS 2.2.3). However, it does have: typedef struct GEOSGeom_t *GEOSGeom; typedef struct GEOSCoordSeq_t *GEOSCoordSeq; If I add typedefs for GEOSGeometry and GEOSCoordSeq, everything compiles okay. [I have no idea whether it works, but it compiles, and doesn't appear to break anything.] I've committed r38878, which restores the configure checks, and adds adds workarounds for the issues with GEOS 2.x. Someone needs to check that these don't break 3.x. initGEOS or GEOSGeom_createLinearRing are defined in GEOS C API (geos_c)... Right; those are there. I had the impression[1] that this was a 3.x-specific symbol; and much confusion ensued. [1] Mainly from: http://lists.osgeo.org/pipermail/grass-dev/2009-August/045435.html -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] color tables
On Aug 26, 2009, at 2:22 AM, Hamish wrote: Helena wrote: I often get a question why there aren't images of color tables in GRASS GUI along with their names. Is this technically feasible? Or it is already there and I just don't see it? I don't think it's there. I am thinking about adding them to the r.colors man page, but first I IMhO these sorts of things should go in the wiki, not the man page. Anything but simple PNG figures add a huge amount to the bulk of the SVN and .tar.gz release sizes. I had in mind something that is on hand directly from the GUI - best would be in the drop-down menu which currently lists the color tables by name, but if that is not supported by the wxpython, man page would do as well because it is accessible from the command's gui. The images are tiny, they take very little space - I had in mind something like this (I should have put it into the Description section, but you get the idea) http://skagit.meas.ncsu.edu/~helena/grasswork/grasscontrib/r.colors.html this just uses your rescaled png images. Same would be handy for the point symbols - they are pretty difficult to find on wiki if you don't know where they are. If this cannot go into the man page, adding a link to the wiki page on man page would certainly help. would like to ask whether somebody has done this already (or has a script to do it). I was thinking about running something like this through all color tables set GRASS_WIDTH=50 and GRASS_HEIGHT=100 r.colors elev co=ryg d.colortable elev d.out.file ryg_col d.erase convert -rotate 90 ryg_col I have made a little script which does the trick, I'll post it to the wiki shortly at http://grass.osgeo.org/wiki/Raster_color_tables that was ultrafast! Thanks a lot - even that helps, Helena Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
