Re: [GRASS-dev] Rast_set_window() changes in 7.0

[Seth Price]

I'm getting an error whenever I run r.sun under the latest weekly:
ERROR: Output window changed while maps are open for write

Here's the command I'm using:
r.sun numpartitions=2 elevin=gauss glob_rad=glob_rad_out day=180

Is this related to your work? Should I make a bug report?
~Seth


On Jul 22, 2010, at 12:57 AM, Glynn Clements wrote:



r42876 implements a fairly invasive change to the raster window
handling in 7.0. Specifically:

1. Modules which read and write maps at different resolutions now make
use of the ability to set separate input and output windows
(Rast_set_input_window() and Rast_set_output_window()).

2. Changing the input/output window while maps are open for read/write
(respectively) now generates a fatal error. There should be no need to
do so, and I want to get bug reports for any cases I've overlooked.
Rast_set_window() changes both the input and output windows.

I would appreciate it if people can test any affected modules.
Specifically, the following are the modules and libraries which called
Rast_set_window:

display/d.rast.arrow
display/d.rast.num
general/g.region
imagery/i.atcorr
imagery/i.ifft
imagery/i.rectify
lib/display
lib/gpde
lib/lidar
lib/rst/interp_float
ps/ps.map
raster/r.basins.fill
raster/r.category
raster/r.coin
raster/r.compress
raster/r.describe
raster/r.external
raster/r.flow
raster/r.horizon
raster/r.in.arc
raster/r.in.ascii
raster/r.in.bin
raster/r.in.gdal
raster/r.in.gridatb
raster/r.in.mat
raster/r.in.png
raster/r.in.poly
raster/r.neighbors
raster/r.null
raster/r.proj
raster/r.recode
raster/r.resamp.bspline
raster/r.resamp.filter
raster/r.resamp.interp
raster/r.resamp.rst
raster/r.resamp.stats
raster/r.rescale
raster/r.slope.aspect
raster/r.sun
raster/r.support.stats
raster/r.support
raster/r.surf.idw2
raster/r.to.rast3
raster/r.to.rast3elev
raster/simwe/simlib
raster3d/r3.cross.rast
raster3d/r3.out.vtk
raster3d/r3.to.rast

In particular, anything using the gpde, lidar or rst libraries should
be a priority.

FWIW, the rationale behind the "split window" functionality is to
avoid having r.resamp.* continually changing the window between the
input and output resolutions, as this causes the column mapping to be
regenerated for the input map each time.

--
Glynn Clements 
___
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] Re: [GRASS GIS] #957: v.voronoi has extra lines in output

[GRASS GIS]

#957: v.voronoi has extra lines in output
+---
 Reporter:  helena  |   Owner:  grass-...@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  6.4.1
Component:  Vector  | Version:  svn-develbranch6 
 Keywords:  |Platform:  All  
  Cpu:  All |  
+---

Comment(by deboyy):

 This new file (agaccpgr34.zip) v.voronoi couldn't produce any problem for
 me.
 Yalçın

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Re: [GRASS GIS] #957: v.voronoi has extra lines in output

[GRASS GIS]

#957: v.voronoi has extra lines in output
+---
 Reporter:  helena  |   Owner:  grass-...@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  6.4.1
Component:  Vector  | Version:  svn-develbranch6 
 Keywords:  |Platform:  All  
  Cpu:  All |  
+---

Comment(by deboyy):

 Replying to [comment:2 mlennert]:
 > ping
 >
 > I can reproduce this bug with 6.4. Any ideas ?
 >
 > Moritz
 Dear Moritz,
 I attach same areas new shp file with little changes (trees dbh>12 cm).
 May be it can help to solve problem. I suspect points z coordinate and
 minimum distance between points.

 Yalçın

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] About v.distance, v.what.vect (wrt "count points within...").

[Markus Metz]

Hamish wrote:
> Markus Metz wrote:
>> compiles now in 64, but no longer in 65 (stats library
>> in 65 is different from 64),
>
> til now we have only really worried about backward-
> compatibility at the data and command-line level.
> None the less, all attempts should be made to keep the C
> API function calls stable. I'm not talking about new
> functions here, I'm talking about modified ones.
>
> In the past we used new function calls like G_fn_name2()
> when there was a function change within the major version.
> (ie for fns already released in a stable branch)
>
> needing patches to build on diff't versions of 6.x is a
> clear sign on failure on our behalf.
>
FYI, the change in question happened 11 months ago, on Sep 4th 2009,
in lib/stats. IOW, this is not an internal module fn, it's a grass
library fn, a change that should have been backported months ago.
There have been a number of changes to existing fn calls within minor
versions in grass6 (grass 6.0.0 was released around March 2005 which
is some time ago...)

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

Re: [GRASS-dev] About v.distance, v.what.vect (wrt "count points within...").

[Hamish]

Markus Metz wrote:
> compiles now in 64, but no longer in 65 (stats library
> in 65 is different from 64),

til now we have only really worried about backward-
compatibility at the data and command-line level.
None the less, all attempts should be made to keep the C
API function calls stable. I'm not talking about new
functions here, I'm talking about modified ones.

In the past we used new function calls like G_fn_name2()
when there was a function change within the major version.
(ie for fns already released in a stable branch)

needing patches to build on diff't versions of 6.x is a
clear sign on failure on our behalf.

.. so is statsvalue() a module-private or libgis-public function?  
https://trac.osgeo.org/grass/changeset/43093
(no prob if it's an internal module fn)


thanks,
Hamish



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

[GRASS-dev] Re: [GRASS GIS] #1125: wingrass - ctypes - compiling error

[GRASS GIS]

#1125: wingrass - ctypes - compiling error
--+-
 Reporter:  hellik|   Owner:  grass-...@…  
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  6.5.0
Component:  Compiling | Version:  svn-trunk
 Keywords:  wingrass, ctypes  |Platform:  MSWindows Vista  
  Cpu:  x86-32|  
--+-

Comment(by martinl):

 Replying to [comment:12 hellik]:
 > there is no difference to my initial post.

 the same here, when I try to print lex data
 ([source:grass/trunk/lib/python/ctypes/ctypesgencore/parser/lex.py]) I am
 getting

 {{{
  /osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/etc/python/grass/lib
 make[1]: Entering directory
 `/osgeo4w/usr/src/grass_trunk/lib/python/ctypes'
 make[1]: `/osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib' is up to date.
 make[1]: Leaving directory
 `/osgeo4w/usr/src/grass_trunk/lib/python/ctypes'
 make date.py grass.py raster.py gmath.py proj.py imagery.py vector.py
 display.py stats.py dbmi.py g3d.py arraystats.py cluster.py trans.py
 vedit.py ogsf.py nviz.py /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/date.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/grass.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/raster.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/gmath.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/proj.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/imagery.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/vector.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/display.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/stats.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/dbmi.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/g3d.py /osgeo4w/usr/src/grass_trunk/dist.i686
 -pc-mingw32/etc/python/grass/lib/arraystats.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/cluster.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/trans.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/vedit.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/ogsf.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/nviz.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/__init__.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/ctypes_preamble.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/ctypes_loader.py
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/date.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/grass.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/raster.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/gmath.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/proj.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/imagery.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/vector.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/display.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/stats.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/dbmi.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/g3d.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/arraystats.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/cluster.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/trans.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/vedit.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/ogsf.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/nviz.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/__init__.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/ctypes_preamble.pyc
 /osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/etc/python/grass/lib/ctypes_loader.pyc
 make[1]: Entering directory
 `/osgeo4w/usr/src/grass_trunk/lib/python/ctypes'
 GISRC=/osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 mingw32/demolocation/.grassrc70
 GISBASE=c:/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32
 PATH="/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/

[GRASS-dev] Re: [GRASS GIS] #1125: wingrass - ctypes - compiling error (was: wingrass7 - ctypes - compiling error)

[GRASS GIS]

#1125: wingrass - ctypes - compiling error
--+-
 Reporter:  hellik|   Owner:  grass-...@…  
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  6.5.0
Component:  Compiling | Version:  svn-trunk
 Keywords:  wingrass, ctypes  |Platform:  MSWindows Vista  
  Cpu:  x86-32|  
--+-
Changes (by martinl):

 * cc: martinl (added)


-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Re: [GRASS GIS] #1131: Global LFS for wingrass

[GRASS GIS]

#1131: Global LFS for wingrass
--+-
 Reporter:  mmetz |   Owner:  grass-...@…  
 Type:  defect|  Status:  new  
 Priority:  critical  |   Milestone:  7.0.0
Component:  libgis| Version:  svn-trunk
 Keywords:  LFS,wingrass  |Platform:  MSWindows 7  
  Cpu:  All   |  
--+-

Comment(by glynn):

 Replying to [comment:1 mmetz]:

 > Following up previous discussions, I have removed struct stat where
 possible. The changes needed for LFS with wingrass are in config.h.in but
 still inactive.
 >
 > Glynn, could you please check if I messed up something somewhere (all
 the struct stat related changes and config.h.in)?

 The config.h.in changes seem okay. Although, I would omit the aliases for
 seek() and tell(), as we don't use those (does seek() even exist? I can't
 find any evidence for it).

 I don't see any "struct stat" changes. Currently, 7.0 has references to
 "struct stat" in:
 {{{
 display/d.font/main.c
 general/g.access/get_perms.c
 general/g.mkfontcap/freetype_fonts.c
 include/gisdefs.h
 include/iostream/ami_stream.h
 lib/db/dbmi_base/isdir.c
 lib/gis/copy_dir.c
 lib/gis/mapset_msc.c
 lib/gis/mapset_nme.c
 lib/gis/paths.c
 lib/gis/remove.c
 lib/gis/user_config.c
 lib/init/clean_temp.c
 lib/vector/Vlib/open.c
 lib/vector/dglib/examples/parse.c
 lib/vector/diglib/file.c
 raster/r.li/r.li.daemon/daemon.c
 vector/v.mapcalc/map.c
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] 6.4.0 blocker bugs

[Martin Landa]

Hi,

2010/8/12 Markus Neteler :
>> So, there's no need to delay 6.4.0 for ctypes. We can add it in 6.4.1,
>> or even make a separate package which works with 6.4.0 (so long as we
>> don't change the API, we would just need to ensure that grass.py
>> contains the correct definition for GIS_H_VERSION so that G_gisinit()
>> works).

on the other hand what can cost to add ctypes now. One RC? That's
acceptable. I would suggest to add ctypes now, publish RC7 and in
one/two weeks final (before FOSS4G 2010). Stable will be released with
ctypes and without swig.

>> But if we release 6.4.0 with the swig directory in place, we'll still
>> be getting questions about it (that we probably won't be able to
>> answer) in ten years time.
>
> Given Glynn's suggestion I redraw my suggestion to add ctypes now.
> We'll do that for 6.4.1.
>
> Can anyone remove swig/ in the 6.4-release branch? I am also on the
> road these days with sporadic internet access. Then we can release
> 6.4.0 next week.

Done in r43095.

Martin

-- 
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] About v.distance, v.what.vect (wrt "count points within...").

[Nikos Alexandris]

[...]

On Friday 13 of August 2010 12:42:57 Markus Metz wrote: 
> compiles now in 64, but no longer in 65 (stats library in 65 is
> different from 64), 65 is a development version and will probably
> never be an officially stable version
> 
> does not compile in trunk because it's written for 65, now 64

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

Re: [GRASS-dev] About v.distance, v.what.vect (wrt "count points within...").

[Markus Metz]

Nikos Alexandris wrote:
> Markus M:
>> I've put a new module in grass-addons, called v.vect.stats.
> ...
>
> ... The
> module fails to compile though under grass64, grass_trunk

compiles now in 64, but no longer in 65 (stats library in 65 is
different from 64), 65 is a development version and will probably
never be an officially stable version

does not compile in trunk because it's written for 65, now 64

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

Re: [GRASS-dev] About v.distance, v.what.vect (wrt "count points within...").

[Nikos Alexandris]

Markus M:
> I've put a new module in grass-addons, called v.vect.stats. 
...

I just want to confirm that this is _fast_. Tested under grass6_devel. The 
module fails to compile though under grass64, grass_trunk (see attached 
files).

Nikos
gcc -I/geo/osgeo/src/grass64_release/dist.x86_64-unknown-linux-gnu/include  -g  
  -I/usr/local/include-DPACKAGE=\""grassmods"\"  
-I/geo/osgeo/src/grass64_release/dist.x86_64-unknown-linux-gnu/include -o 
OBJ.x86_64-unknown-linux-gnu/main.o -c main.c
gcc  -g   -I/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-gnu/include 
-I/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-gnu/include  
-D_FILE_OFFSET_BITS=64 -I/usr/local/include -I/usr/local/include 
-DPACKAGE=\""grassmods"\"   
-I/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-gnu/include 
-I/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-gnu/include -o 
OBJ.x86_64-unknown-linux-gnu/main.o -c main.c
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] About v.distance, v.what.vect (wrt "count points within...").

[Markus Metz]

Moritz Lennert wrote:
> Markus Metz wrote:
>>
>> Start from scratch:
>>
>> I've put a new module in grass-addons, called v.vect.stats. It counts
>> points in polygons, fairly fast, but, as the name implies, can do a
>> bit more. Optionally, it calculates statistics for areas based on the
>> attributes of all points falling into an area. Currently supported
>> methods are sum, average, median, mode, min, min_cat, max, max_cat,
>> range, stddev, variance, diversity. The meaning of min_cat and max_cat
>> is the category value corresponding to the observed minimum/maximum
>> value, e.g. the hospital with the largest number of beds and not the
>> largest number of beds.
>>
>> The module is meant as the companion to v.rast.stats, update area
>> attributes from raster: v.vect.stats, update area attributes from
>> vector
>>
>> Have fun,
>>
>> Markus M
>>
>> PS: No entry on wiki because I am not sure what will happen with the
>> module. If it's regarded nonsense, it will be removed again. OTOH, it
>> might end up in trunk.
>
> No nonsense in my eyes. Very nice and useful little module.
>
> In terms of usage time, the parts that take most time with large files (the
> 600,000 points and 100x100 grid used before) are the creation of the spatial
> index

That's why it's faster in grass 7

> and (if a stats method is applied) the collecting of attributes from
> the points vector (at one point we will probably have to attack db driver
> efficiency issues in GRASS... example: do we really have to create a select
> cursor and loop through every line this returns ?). The actual
> point-in-areas is very fast !
>
> A few small questions/remarks:
>
> - Any special reason why you construct a whole SQL statement to add the
> columns, instead of using db_add_column() (defined in
> lib/db/dbmi_client/c_add_col.c) ?
>
No special reason, I simply forgot about db_add_column(), thanks for the tip!

> - Maybe add a key to point_column_opt to call it point_column (instead of
> the default "column")
>
Yes. I was also thinking about pcolumn, ccolumn, scolumn as keys,
these would allow shortcuts like pc, cc, sc. Other modules also use
e.g. qcolumn instead of query_column.

> - If one sets a method and a stats_column, but no point_column, the first
> two settings are simply ignored. Maybe a fatal error would be better (I took
> me a bit of time to understand that I had forgotten the point_column.

Ah, ok, will do.
>
> No time for more, but I really think this would be a useful addition to
> trunk...
>

Thanks for testing!

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

Re: [GRASS-dev] About v.distance, v.what.vect (wrt "count points within...").

[Moritz Lennert]

On 12/08/10 16:51, Markus Metz wrote:

Start from scratch:

I've put a new module in grass-addons, called v.vect.stats. It counts
points in polygons, fairly fast, but, as the name implies, can do a
bit more. Optionally, it calculates statistics for areas based on the
attributes of all points falling into an area. Currently supported
methods are sum, average, median, mode, min, min_cat, max, max_cat,
range, stddev, variance, diversity. The meaning of min_cat and max_cat
is the category value corresponding to the observed minimum/maximum
value, e.g. the hospital with the largest number of beds and not the
largest number of beds.

The module is meant as the companion to v.rast.stats, update area
attributes from raster: v.vect.stats, update area attributes from
vector

Have fun,

Markus M

PS: No entry on wiki because I am not sure what will happen with the
module. If it's regarded nonsense, it will be removed again. OTOH, it
might end up in trunk.


No nonsense in my eyes. Very nice and useful little module.

In terms of usage time, the parts that take most time with large files 
(the 600,000 points and 100x100 grid used before) are the creation of 
the spatial index and (if a stats method is applied) the collecting of 
attributes from the points vector (at one point we will probably have to 
attack db driver efficiency issues in GRASS... example: do we really 
have to create a select cursor and loop through every line this returns 
?). The actual point-in-areas is very fast !


A few small questions/remarks:

- Any special reason why you construct a whole SQL statement to add the 
columns, instead of using db_add_column() (defined in 
lib/db/dbmi_client/c_add_col.c) ?


- Maybe add a key to point_column_opt to call it point_column (instead 
of the default "column")


- If one sets a method and a stats_column, but no point_column, the 
first two settings are simply ignored. Maybe a fatal error would be 
better (I took me a bit of time to understand that I had forgotten the 
point_column.


No time for more, but I really think this would be a useful addition to 
trunk...


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

Re: [GRASS-dev] About v.distance, v.what.vect (wrt "count points within...").

[Moritz Lennert]

On 13/08/10 08:47, Nikos Alexandris wrote:

Moritz L:


--- v.db.dropcolumn.py  2010-08-12 18:48:03.0 +0200
+++ /home/mlennert/v.db.dropcolumn.py   2010-08-12 18:47:29.0
+0200 @@ -102,6 +102,7 @@
  "DROP TABLE ${table}",
  "CREATE TABLE ${table}(${coldef})",
  "INSERT INTO ${table} SELECT ${colnames} FROM
${table}_backup", +   "CREATE UNIQUE INDEX ${table}_cat ON
${table ( ${keycol} )"


Nikos A:


+  "CREATE UNIQUE INDEX ${table}_cat ON ${table ( ${keycol}
)" , #missing comma?


  "DROP TABLE ${table}_backup",
  "COMMIT"
  ]



sql = tmpl.substitute(table = table, coldef = coltypes, colnames =
colnames)


Martin L:

change to

sql = tmpl.substitute(table = table, coldef = coltypes, colnames =
colnames, keycol = keycol)


Everything works fine now in grass_trunk, that is:

a. "v.db.dropcolumn" on its own
b. "v.distance" is fast even after dropping a column (=index is there)

Nikos (happy user today) :D


Committed in trunk as 43083.

Moritz

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

Re: [GRASS-dev] About v.distance, v.what.vect (wrt "count points within...").

[Nikos Alexandris]

On Saturday 07 of August 2010 09:16:20 Nikos Alexandris wrote:
> Just something more,
> 
> my intention to ask an outsider is purely aiming to take-off some work-load
> of the grass-dev core team. Solely that. And of course, this in case it is
> really (a.) a problem and (b.) it is known and the question is just about
> who is going to spend time on it.

Not of interesed anymore!

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