Re: [GRASS-dev] Re: [GRASS-SVN] r38872 - grass/trunk
Hi, 2009/8/26 Glynn Clements gl...@gclements.plus.com: [...] 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. thanks, backported to devbr6 in r38879. 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] color tables
On Wed, 26 Aug 2009 21:22:16 -0400, Helena Mitasova hmit...@unity.ncsu.edu wrote: http://skagit.meas.ncsu.edu/~helena/grasswork/grasscontrib/r.colors.html this just uses your rescaled png images. Quite useful - +1 for me. pc -- http://faunalia.it/pc ___ 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
Glynn: 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. great, I can report that 6.5svn now ./configures and builds --with-geos ver 2.2.3 successfully, and that 'v.select --help' shows new options. in related issues swig/python/ still fails to build due to too-old(?) swig ver 1.3.29, but the ./configure check just checks for the presence of /usr/bin/swig; it doesn't test if that contains what we need. It would be nice if it could be made to work with older versions of swig again, if not, at least the ./configure script should throw an error when --with-python is given instead of doing what it does now fail at compile-time. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] SQLite 3 SQL logic error
Dear all,
I have made some progress on this and think that I have actually
found the reason for this problem.
The error message is issued by this block of C++ code
in gdal-1.6.1/ogr/ogrsf_frmts/sqlite/ogrsqlitetablelayer.cpp
(ca. line 826):
/* */
/* Execute the insert. */
/* */
rc = sqlite3_step( hInsertStmt );
if( rc != SQLITE_OK rc != SQLITE_DONE )
{
CPLError( CE_Failure, CPLE_AppDefined,
sqlite3_step() failed:\n %s,
sqlite3_errmsg(hDB) );
return OGRERR_FAILURE;
}
I have added some debugging code to the OGR SQLite driver to see
what the SQL statement looks like that actually gets processed
by sqlite3_step().
The output of v.out.ogr then was:
Exporting 2898 points/lines...
SQL: 'INSERT INTO 'dem' (WKT_GEOMETRY,'cat','cat_','flt1') VALUES
(?,'1','1','75.5')'
SQL: 'INSERT INTO 'dem' (OGC_FID,WKT_GEOMETRY,'cat','cat_','flt1') VALUES
(1,?,'2','2','73.57')'
ERROR 1: sqlite3_step() failed:
SQL logic error or missing database
SQL: 'INSERT INTO 'dem' (OGC_FID,WKT_GEOMETRY,'cat','cat_','flt1') VALUES
(1,?,'3','3','75.41')'
ERROR 1: sqlite3_step() failed:
SQL logic error or missing database
[...]
Interestingly, the SQL code for the first feature (which gets stored
OK in the DB) differs from that of all the following in that it does
not insert a value into the OGC_FID column!
After that, the statements look OK but they are not: OGC_FID is
a primary key field, but the same value 1 is generated for all
rows.
Actually, the first statement is the right one! Since it does not
touch the OGC_FID field, but that field is properly declared
as an auto-incrementing primary key, the SQLite3 driver takes care
of inserting a proper value by itself.
So it seems to me the fix would be to stop v.out.ogr from creating
an OGC_FID value as part of the attribute record for the OGR
feature (after the first record, which is for some reason OK!).
Unfortunately, I know very little about the OGR C API and don't quite
understand how to change the code in v.out.ogr. Could someone more
familiar with that module help out, please?
Thanks,
Ben
P.S.: Why this all seems to be no problem for a PostGIS DBMS completely
eludes me -- perhaps it just ignores wrong values for a PK field and
silently replaces them with correct values...
Benjamin Ducke wrote:
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
--
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
Re: [GRASS-dev] Re: [GRASS-SVN] r38872 - grass/trunk
Hamish wrote: in related issues swig/python/ still fails to build due to too-old(?) swig ver 1.3.29, but the ./configure check just checks for the presence of /usr/bin/swig; it doesn't test if that contains what we need. It would be nice if it could be made to work with older versions of swig again, if not, at least the ./configure script should throw an error when --with-python is given instead of doing what it does now fail at compile-time. AFAIK, that version with SWIG will work with older versions of Python. The core problem is that your distro ships a version of of SWIG which isn't compatible with their version of Python (or have you upgraded Python manually?). A configure check would need to use SWIG to generate a Python wrapper, then try to compile it. -- 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] Re: [GRASS-SVN] r38872 - grass/trunk
Hamish wrote: in related issues swig/python/ still fails to build due to too-old(?) swig ver 1.3.29, [...] Glynn: AFAIK, that version with SWIG will work with older versions of Python. The core problem is that your distro ships a version of of SWIG which isn't compatible with their version of Python Debian/Etch, swig 1.3.29-2.1, 2.4.4-3+etch2. Swig+python used to work on this machine up until a couple of months ago, about the time of the automatic .h - .i changes. I don't really know but I figured the two were related somehow. I should check the archives, I've got a funny feeling this has been explained to me a number of times already. (hence my suspicion that my copy of swig was too old now) (or have you upgraded Python manually?). nope; but it is slighly possible a security update package gone wrong might have altered something. A configure check would need to use SWIG to generate a Python wrapper, then try to compile it. FWIW the error is as so: [...] gcc -I/usr/local/src/grass/svn/grass65/dist.i686-pc-linux-gnu/include -ggdb -march=pentium4 -Wall -Werror-implicit-function-declaration-fPIC -DPACKAGE=\grasslibs\ -fPIC -I/usr/include/python2.4 -I/usr/include/python2.4-DPACKAGE=\grasslibs\ -I/usr/include/gdal -I/usr/include/gdal -I/usr/local/src/grass/svn/grass65/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/utils_wrap.o -c utils_wrap.c utils_wrap.c: In function 'pyseq_to_ptr': utils_wrap.c:2495: error: 'Py_ssize_t' undeclared (first use in this function) utils_wrap.c:2495: error: (Each undeclared identifier is reported only once utils_wrap.c:2495: error: for each function it appears in.) utils_wrap.c:2495: error: expected ';' before 'len' utils_wrap.c:2522: error: 'len' undeclared (first use in this function) utils_wrap.c: In function 'pyobj_to_ptr': utils_wrap.c:2570: error: 'Py_ssize_t' undeclared (first use in this function) utils_wrap.c:2570: error: expected ';' before 'len' [...] thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] SQLite 3 SQL logic error
OK, I _may_ have fixed it.
The problem is/seems that v.out.ogr creates only one instance
of OGRFeatureH struct and then recycles that for every
vector object that needs to be exported, only clearing
the Geometry once for every run through the main export loop.
It also clears all user-defined attributes.
This is obviously not a problem for file-based geometries such
as Shapefiles, because they consist of nothing more than
geometry + user attributes. But it seems that the SQLite driver
creates an OGC_FID as part of the feature and this sticks around.
I have not tried very many other OGR drivers, but PostGIS handles
this differently and is OK.
So what needs to be done is to destroy the entire feature
struct after every pass through the main export loop.
Thus, the code for exporting points and lines would look as
follows (see //NEW tags):
---
/* Lines (run always to count features of different type) */
if ((otype GV_POINTS) || (otype GV_LINES)) {
G_message(_(Exporting %i points/lines...), Vect_get_num_lines(In));
for (i = 1; i = Vect_get_num_lines(In); i++) {
G_percent(i, Vect_get_num_lines(In), 1);
//NEW:
Ogr_feature = OGR_F_Create(Ogr_featuredefn);
type = Vect_read_line(In, Points, Cats, i);
G_debug(2, line = %d type = %d, i, type);
if (!(otype type)) {
G_debug(2, type %d not specified - skipping, type);
fskip++;
continue;
}
Vect_cat_get(Cats, field, cat);
if (cat 0 !donocat) { /* Do not export not labeled */
nocatskip++;
continue;
}
/* Geometry */
if (type == GV_LINE poly_flag-answer) {
OGRGeometryH ring;
ring = OGR_G_CreateGeometry(wkbLinearRing);
Ogr_geometry = OGR_G_CreateGeometry(wkbPolygon);
/* Area */
for (j = 0; j Points-n_points; j++) {
OGR_G_AddPoint(ring, Points-x[j], Points-y[j],
Points-z[j]);
}
if (Points-x[Points-n_points - 1] != Points-x[0] ||
Points-y[Points-n_points - 1] != Points-y[0] ||
Points-z[Points-n_points - 1] != Points-z[0]) {
OGR_G_AddPoint(ring, Points-x[0], Points-y[0],
Points-z[0]);
}
OGR_G_AddGeometryDirectly(Ogr_geometry, ring);
}
else if (type == GV_POINT) {
Ogr_geometry = OGR_G_CreateGeometry(wkbPoint);
OGR_G_AddPoint(Ogr_geometry, Points-x[0], Points-y[0],
Points-z[0]);
}
else { /* GV_LINE or GV_BOUNDARY */
Ogr_geometry = OGR_G_CreateGeometry(wkbLineString);
for (j = 0; j Points-n_points; j++) {
OGR_G_AddPoint(Ogr_geometry, Points-x[j], Points-y[j],
Points-z[j]);
}
}
OGR_F_SetGeometry(Ogr_feature, Ogr_geometry);
/* Output one feature for each category */
for (j = -1; j Cats-n_cats; j++) {
if (j == -1) {
if (cat = 0)
continue; /* cat(s) exists */
}
else {
if (Cats-field[j] == field)
cat = Cats-cat[j];
else
continue;
}
mk_att(cat, Fi, Driver, ncol, doatt, Ogr_feature);
OGR_L_CreateFeature(Ogr_layer, Ogr_feature);
}
OGR_G_DestroyGeometry(Ogr_geometry);
//NEW:
OGR_F_Destroy(Ogr_feature);
}
}
---
Clearly, this adds additional memory management overhead and will
slow down everything.
So my questions are:
1. Do you think this fix is plausible?
2. Should it be enabled ONLY for SQLite type datasources?
I would still feel better about this if someone more knowledgeable
about GDAL/OGR could comment on this...
Thanks,
Ben
Benjamin Ducke wrote:
Dear all,
I have made some progress on this and think that I have actually
found the reason for this problem.
The error message is issued by this block of C++ code
in gdal-1.6.1/ogr/ogrsf_frmts/sqlite/ogrsqlitetablelayer.cpp
(ca. line 826):
/* */
/* Execute the insert. */
/* */
rc = sqlite3_step( hInsertStmt );
if( rc != SQLITE_OK rc != SQLITE_DONE )
{
CPLError( CE_Failure, CPLE_AppDefined,
sqlite3_step() failed:\n %s,
[GRASS-dev] Re: [GRASS GIS] #735: r.in.wms causes g.parser buffer owerflow
#735: r.in.wms causes g.parser buffer owerflow
-+--
Reporter: marisn | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.5.0
Component: Raster | Version: svn-develbranch6
Resolution: |Keywords:
Platform: Linux | Cpu: Unspecified
-+--
Comment (by marisn):
Replying to [comment:2 hamish]:
from grass65/scripts/r.in.wms/wms.request:
{{{
g.message Requesting ${NUMBER_OF_TILES} tiles.
}}}
g.message is a bad choice, as on fast machine with fast WMS server it too
soon gets burried in 200 tile downloading messages.
Glynn: no idea. It's too hardcore for me. Still IMHO buffer owerflow isn't
the right way how to deal with error conditions.
It would be nice if r.in.wms could calculate resulting arg length and fail
if it exceeds systems capabilities (theoretical limits).
--
Ticket URL: https://trac.osgeo.org/grass/ticket/735#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
Re: [GRASS-dev] Re: [GRASS-SVN] r38872 - grass/trunk
Hamish wrote: FWIW the error is as so: [...] gcc -I/usr/local/src/grass/svn/grass65/dist.i686-pc-linux-gnu/include -ggdb -march=pentium4 -Wall -Werror-implicit-function-declaration-fPIC -DPACKAGE=\grasslibs\ -fPIC -I/usr/include/python2.4 -I/usr/include/python2.4-DPACKAGE=\grasslibs\ -I/usr/include/gdal -I/usr/include/gdal -I/usr/local/src/grass/svn/grass65/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/utils_wrap.o -c utils_wrap.c utils_wrap.c: In function 'pyseq_to_ptr': utils_wrap.c:2495: error: 'Py_ssize_t' undeclared (first use in this function) utils_wrap.c:2495: error: (Each undeclared identifier is reported only once utils_wrap.c:2495: error: for each function it appears in.) utils_wrap.c:2495: error: expected ';' before 'len' utils_wrap.c:2522: error: 'len' undeclared (first use in this function) utils_wrap.c: In function 'pyobj_to_ptr': utils_wrap.c:2570: error: 'Py_ssize_t' undeclared (first use in this function) utils_wrap.c:2570: error: expected ';' before 'len' Oops. It's not your distro; utils.i and my_typemaps.i are using Py_ssize_t although that type only exists in Python 2.5. Later versions of SWIG define it (as an alias for int) for earlier versions of Python. Try this: --- swig/include/python/common.i(revision 38884) +++ swig/include/python/common.i(working copy) @@ -2,6 +2,13 @@ #include stdio.h #include grass/gis.h #include grass/raster.h + +#if PY_VERSION_HEX 0x0205 !defined(PY_SSIZE_T_MIN) +typedef int Py_ssize_t; +# define PY_SSIZE_T_MAX INT_MAX +# define PY_SSIZE_T_MIN INT_MIN +#endif + %} %rename(my_def) def; -- 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 Thursday 27 August 2009, paolo wrote: On Wed, 26 Aug 2009 21:22:16 -0400, Helena Mitasova hmit...@unity.ncsu.edu wrote: http://skagit.meas.ncsu.edu/~helena/grasswork/grasscontrib/r.colors.html this just uses your rescaled png images. Quite useful - +1 for me. pc +1 from me as well. I really like the mini-images next to the color scheme name. Dylan -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] color tables
On Thu, Aug 27, 2009 at 6:19 PM, Dylan Beaudettedebeaude...@ucdavis.edu wrote: On Thursday 27 August 2009, paolo wrote: On Wed, 26 Aug 2009 21:22:16 -0400, Helena Mitasova hmit...@unity.ncsu.edu wrote: http://skagit.meas.ncsu.edu/~helena/grasswork/grasscontrib/r.colors.html this just uses your rescaled png images. Quite useful - +1 for me. pc +1 from me as well. I really like the mini-images next to the color scheme name. An option might be to make a local Makefile hack to substitute part of the generated HTML file with a replacement including these images. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #730: sqlite: troubles with datetime columns: unable to parse decltype: datetime
Hi,
On Sun, Aug 23, 2009 at 12:36 AM, GRASS GISt...@osgeo.org wrote:
#730: sqlite: troubles with datetime columns: unable to parse decltype:
datetime
--+-
Reporter: neteler | Owner: grass-...@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Database | Version: 6.4.0 RCs
Keywords: | Platform: All
Cpu: All |
--+-
There are some troubles with datetime columns in SQLite:
{{{
GRASS 6.4.0svn (patUTM32): db.select meteo_iasma_hourly_modis_overpass
WARNING: SQLite driver: unable to parse decltype: datetime
WARNING: SQLite driver: unable to parse decltype: datetime
WARNING: SQLite driver: column 'data', SQLite type 3 is not supported
cat|station|t_max|t_min|t_mean
1|st14|8.3|7.1|7.7
2|st14|9.5|7.7|9.4
3|st14|-1.8|-2.5|-2.2
4|st14|-2|-2.4|-2.2
...
}}}
The column is not shown at all above (but below). Indeed, for SQLite
itself the type exists and it doesn't have problems with the table:
{{{
sqlite3 $HOME/grassdata/patUTM32/meteo_iasma/sqlite.db
sqlite .schema meteo_iasma_hourly_modis_overpass
CREATE TABLE meteo_iasma_hourly_modis_overpass (cat integer, station
varchar ( 255 ), data datetime, t_max double precision, t_min double
precision, t_mean double precision);
CREATE UNIQUE INDEX meteo_iasma_hourly_modis_overpass_cat on
meteo_iasma_hourly_modis_overpass ( cat );
sqlite select * from meteo_iasma_hourly_modis_overpass;
1|st14|2001-11-01 10:00:00|8.3|7.1|7.7
2|st14|2001-11-01 11:00:00|9.5|7.7|9.4
3|st14|2003-04-11 1:00:00|-1.8|-2.5|-2.2
4|st14|2003-04-11 2:00:00|-2.0|-2.4|-2.2
...
}}}
I see that in db/drivers/sqlite/describe.c there is no datetime:
{{{
334 if (sscanf(buf, decimal ( %d , %d ), length, length) == 2)
335 return DB_SQL_TYPE_DECIMAL;
336 if (sscanf(buf, time ( %d ), length) == 1 ||
337 sscanf(buf, timetz ( %d ), length) == 1)
338 return DB_SQL_TYPE_TIME;
339 if (sscanf(buf, timestamp ( %d ), length) == 1 ||
340 sscanf(buf, timestamptz ( %d ), length) == 1)
341 return DB_SQL_TYPE_TIMESTAMP;
}}}
Not sure what to do: map to which DB_SQL_TYPE_xxx?
Sorry to insist... any pointers?
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] gmath/gpde Patch for grass6.5 and grass7
Hello Hamish, i am sorry for the delay, i was very busy in the last days ... 2009/8/21 Hamish hamis...@yahoo.com Hamish wrote: by the way, I notice that we already ship the bwidget LGPL library trunk/lib/external/bwidget/ That is for Tcl which is redundant for grass 7, actually that's used by tcl NVIZ so still in use. wx NVIZ is not yet to the point where it can replace the tcl version. (btw, we should rename visualization/nviz2/ to be wxNViz or something; the tcl version is already version 2.2) I added a new lib/external/README.license file to explain things. AFAICT the SUBMITTING file and RFCs do not require adjustment. Ok, i will put ccmath into lib/external together with the lgpl.license file and a README. Additionally i need to modify the lib/Makefile to put the directory external before the gmath library. But i think that is not a problem. Best regards Soeren Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] gmath/gpde Patch for grass6.5 and grass7
Hello Glynn, i am sorry for the delay, the last days were very stressing for me ... 2009/8/21 Glynn Clements gl...@gclements.plus.com Soeren Gebbert wrote: 3.) I can place an ATTENTION.txt file in the ccmath library folder, which explains the licensing issue. You can't assume that someone modifying the file will have viewed the contents of the folder. When I open a source file, it's often from grep or compilation output (C-x ` or selecting a specific line of output), or via M-. (find-tag, i.e. locate the point in the source where a given symbol is defined). If you want to ensure that the information is seen by anyone modifying the file, the information needs to go into the file itself. What would be better still would be if subversion could restrict the ability to modify those files, or at least send a reminder email if the files are modified. Can we modify the svn access to lib/external? As Hamish suggested i would like to place the ccmath library into this directory, because other LGPL libraries are located there. Best regards Soeren An alternative would be to put the library in e.g. lib/nonGPL/ccmath so that the pathname serves as a reminder. -- 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
Markus Neteler wrote: On Thu, Aug 27, 2009 at 6:19 PM, Dylan Beaudettedebeaude...@ucdavis.edu wrote: On Thursday 27 August 2009, paolo wrote: On Wed, 26 Aug 2009 21:22:16 -0400, Helena Mitasova hmit...@unity.ncsu.edu wrote: http://skagit.meas.ncsu.edu/~helena/grasswork/grasscontrib/r.colors.html this just uses your rescaled png images. Quite useful - +1 for me. pc +1 from me as well. I really like the mini-images next to the color scheme name. An option might be to make a local Makefile hack to substitute part of the generated HTML file with a replacement including these images. Try overriding the default rule with: r.colors.tmp.html: $(HTMLSRC) $(call htmldesc,$,$@) sed 's!^DDb\([a-z0-9.]*\)/b:!DDimg width=80 height=12 src=Colortable_\1_i.pngb\1/b:!' $@ $...@.tmp mv -f $...@.tmp $@ Or you could just put the images into the static part of the file. -- 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] gmath/gpde Patch for grass6.5 and grass7
Soeren Gebbert wrote: Additionally i need to modify the lib/Makefile to put the directory external before the gmath library. But i think that is not a problem. It should be okay to put the external subdirectory first, as it shouldn't depend upon anything in GRASS. -- 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
Helena wrote: http://skagit.meas.ncsu.edu/~helena/grasswork/grasscontrib/r.colors.html this just uses your rescaled png images. Markus: An option might be to make a local Makefile hack to substitute part of the generated HTML file with a replacement including these images. I don't think that's needed; just put the images in the main body of description.html, as the color options get repeated there. the script on the discussion side of the wiki page could be modified to use Helena's idea of d.colortable + rotate 90 for the mini images; no point including the d.legend frame around them. If you want a 1px frame use border=1 in the img src. ..png please. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] gmath/gpde Patch for grass6.5 and grass7
Hamish wrote: I added a new lib/external/README.license file to explain things. AFAICT the SUBMITTING file and RFCs do not require adjustment. Soeren: Ok, i will put ccmath into lib/external together with the lgpl.license file and a README. actually there is nothing about the GPL or the implications of it in the SUBMITTING file, probably it is a good idea to add something there after all, with a be aware that files in lib/external/ ... rider. I don't think technical SVN restrictions are workable, but I'm open to being proved wrong by a good idea. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] color tables
Markus: An option might be to make a local Makefile hack to substitute part of the generated HTML file with a replacement including these images. Hamish wrote: I don't think that's needed; just put the images in the main body of description.html, as the color options get repeated there. sorry, I just noticed that that is only true for 6.4, in 6.5/7 the duplicated list has been removed. I suggest to make the thumbnails the equivalent of 8-10pt tall and an inch wide, about what Helena already demonstrated, maybe a little bigger. Hamish ___ 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
Glynn wrote: Try this: --- swig/include/python/common.i(revision 38884) +++ swig/include/python/common.i(working copy) @@ -2,6 +2,13 @@ #include stdio.h #include grass/gis.h #include grass/raster.h + +#if PY_VERSION_HEX 0x0205 !defined(PY_SSIZE_T_MIN) +typedef int Py_ssize_t; +# define PY_SSIZE_T_MAX INT_MAX +# define PY_SSIZE_T_MIN INT_MIN +#endif + %} %rename(my_def) def; yes, with that patch a fresh build completes successfully. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] lots of link errors in trunk (OSX)
I'm getting a lot of link errors in trunk now. It looks like it might be related to r38871 and r38893 where all the *DEP and *LIB variables were changed. It's a very long list, but errors are all similar to: in cluster: cc ... -lgrass_imagery -lgrass_gis Undefined symbols: _Rast_is_d_null_value, referenced from: _I_cluster_point_part in c_point.o _I_cluster_point in c_point.o or in rowio: cc ... [no link libs at all] Undefined symbols: _G_warning, referenced from: _Rowio_setup in setup.o _G__malloc, referenced from: _Rowio_setup in setup.o _Rowio_setup in setup.o or in g.proj: gcc ... -lproj -lgrass_gproj -lgrass_gis Undefined symbols: _OGR_L_GetExtent, referenced from: _input_georef in input.o _OSRImportFromProj4, referenced from: _input_proj4 in input.o _GDALGetRasterXSize, referenced from: _input_georef in input.o ... and there are quite a few modules that are missing the PROJ lib in linking. Something's not working right in the new transformation magic in grass.make. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history. - Hitchhiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #629: WinGRASS: spaces in pathnames
#629: WinGRASS: spaces in pathnames ---+ Reporter: hamish| Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: normal| Milestone: 6.4.0 Component: Installation | Version: 6.4.0 RCs Resolution:|Keywords: wingrass, msys Platform: MSWindows XP | Cpu: x86-32 ---+ Comment (by cnielsen): Replying to [comment:14 hamish]: maybe Exec + some `FOR /F ... SET UNIXPATH=~dps0` style DOS magic? http://nsis.sourceforge.net/Docs/Chapter4.html#4.9.1.2 No luck so far, I managed to have the NSI script write a little batch file, which in turn writes the 8.3 shortname to a system variable with SETX. This value is then written to the fstab value, however it always writes the previous value of the variable instead... annoying. Also it is not really preferable to have a system environment variable permanently written for this purpose... GRASS-Installer.nsi has code for that already? True but msys still has problems with /c/Program\ Files/GRASS/bin/grass64 as it strips out the \. On another similar note, I had an error with v.digit failing to write to the dbf because the GIS Database path had a space in it (which is the default in the installer). -- Ticket URL: https://trac.osgeo.org/grass/ticket/629#comment:15 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
