Re: [GRASS-user] v.dissolve and r.cost problems
On Thu, Apr 2, 2009 at 6:37 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 02/04/09 18:12, Moritz Lennert wrote: On 02/04/09 16:58, Markus Neteler wrote: On Thu, Apr 2, 2009 at 4:51 PM, Moritz Lennert On 02/04/09 16:00, Markus Neteler wrote: On Thu, Apr 2, 2009 at 1:43 PM, Markus Neteler nete...@osgeo.org On Wed, Apr 1, 2009 at 6:05 PM, Paolo Cavallini v.dissolve input=reg...@nuovo layer=1 column=REGIAO output=reg_diss dbmi: Protocol error ... Offlist we figured it out: If the REGIAO column field value is empty, then it fails. ... BAD happens when Null is found here. And that's arguably a correct behaviour as how should NULL be handled in such a comparison ? Don't know how it is dealt with in other DBMS... Yes, I also don't know... So, before we fix this in any way, we should probably agree to how to handle it. One possible way would be to check for nulls and if there are any to assign a return value according to our choice as to where to sort nulls to. Don't know how to check for an uninitialised char variable in C, but I imagine that it should be possible. Actually, you should be able to check tbl-rows[*row1].values[cur_cmp_ocol].is_null and deal with the values accordingly, but from a casual glimpse I cannot find the possible values of is_null... I suppose 0 for false and 1 for true, but not sure...Use your example to check, with something like fprintf(stdout, row 1 null status = %i\n, tbl-rows[*row1].values[cur_cmp_ocol].is_null); echo SELECT cat, REGIAO FROM regiao ORDER BY REGIAO | db.select D0/0: case DBF_CHAR: c1 = ALTO PORTUGAL, c2 = ALTO PORTUGAL D0/0: case DBF_CHAR: row 1 null status = 0 D0/0: case DBF_CHAR: c1 = NOROESTE CISMONTANO, c2 = ALTO PORTUGAL D0/0: case DBF_CHAR: row 1 null status = 0 D0/0: case DBF_CHAR: c1 = NOROESTE CISMONTANO, c2 = ALTO PORTUGAL D0/0: case DBF_CHAR: row 1 null status = 0 D0/0: case DBF_CHAR: c1 = NOROESTE CISMONTANO, c2 = ALTO PORTUGAL D0/0: case DBF_CHAR: row 1 null status = 0 D0/0: case DBF_CHAR: c1 = (null), c2 = ALTO PORTUGAL D0/0: case DBF_CHAR: row 1 null status = 1 dbmi: Protocol error Seems to be found. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
On 03/04/09 08:43, Markus Neteler wrote:
On Thu, Apr 2, 2009 at 6:37 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 02/04/09 18:12, Moritz Lennert wrote:
On 02/04/09 16:58, Markus Neteler wrote:
On Thu, Apr 2, 2009 at 4:51 PM, Moritz Lennert
On 02/04/09 16:00, Markus Neteler wrote:
On Thu, Apr 2, 2009 at 1:43 PM, Markus Neteler nete...@osgeo.org
On Wed, Apr 1, 2009 at 6:05 PM, Paolo Cavallini
v.dissolve input=reg...@nuovo layer=1 column=REGIAO output=reg_diss
dbmi: Protocol error
...
Offlist we figured it out:
If the REGIAO column field value is empty, then it fails.
...
BAD happens when Null is found here.
And that's arguably a correct behaviour as how should NULL be handled in
such a comparison ? Don't know how it is dealt with in other DBMS...
Yes, I also don't know...
So, before we fix this in any way, we should probably agree to how to
handle it. One possible way would be to check for nulls and if there are any
to assign a return value according to our choice as to where to sort nulls
to. Don't know how to check for an uninitialised char variable in C, but I
imagine that it should be possible.
Actually, you should be able to check
tbl-rows[*row1].values[cur_cmp_ocol].is_null
and deal with the values accordingly, but from a casual glimpse I cannot
find the possible values of is_null... I suppose 0 for false and 1 for true,
but not sure...Use your example to check, with something like
fprintf(stdout, row 1 null status = %i\n,
tbl-rows[*row1].values[cur_cmp_ocol].is_null);
echo SELECT cat, REGIAO FROM regiao ORDER BY REGIAO | db.select
D0/0: case DBF_CHAR: c1 = ALTO PORTUGAL, c2 = ALTO PORTUGAL
D0/0: case DBF_CHAR: row 1 null status = 0
D0/0: case DBF_CHAR: c1 = NOROESTE CISMONTANO, c2 = ALTO PORTUGAL
D0/0: case DBF_CHAR: row 1 null status = 0
D0/0: case DBF_CHAR: c1 = NOROESTE CISMONTANO, c2 = ALTO PORTUGAL
D0/0: case DBF_CHAR: row 1 null status = 0
D0/0: case DBF_CHAR: c1 = NOROESTE CISMONTANO, c2 = ALTO PORTUGAL
D0/0: case DBF_CHAR: row 1 null status = 0
D0/0: case DBF_CHAR: c1 = (null), c2 = ALTO PORTUGAL
D0/0: case DBF_CHAR: row 1 null status = 1
dbmi: Protocol error
Seems to be found.
Ok, try the attached diff to grass6 head.
It implements the same behaviour for all data types: null values are
sorted to the end.
Moritz
Index: dbfexe.c
===
--- dbfexe.c (révision 36571)
+++ dbfexe.c (copie de travail)
@@ -499,32 +499,47 @@
tbl = (db.tables[cur_cmp_table]);
-switch (tbl-cols[cur_cmp_ocol].type) {
-case DBF_CHAR:
- c1 = tbl-rows[*row1].values[cur_cmp_ocol].c;
- c2 = tbl-rows[*row2].values[cur_cmp_ocol].c;
- return (strcmp(c1, c2));
- break;
-case DBF_INT:
- i1 = tbl-rows[*row1].values[cur_cmp_ocol].i;
- i2 = tbl-rows[*row2].values[cur_cmp_ocol].i;
- if (i1 i2)
- return -1;
- if (i1 i2)
+if (tbl-rows[*row1].values[cur_cmp_ocol].is_null) {
+ if (tbl-rows[*row2].values[cur_cmp_ocol].is_null) {
+ return 0;
+ }
+ else {
return 1;
- return 0;
- break;
-case DBF_DOUBLE:
- d1 = tbl-rows[*row1].values[cur_cmp_ocol].d;
- d2 = tbl-rows[*row2].values[cur_cmp_ocol].d;
- if (d1 d2)
+ }
+}
+else {
+ if (tbl-rows[*row2].values[cur_cmp_ocol].is_null) {
return -1;
- if (d1 d2)
- return 1;
- return 0;
- break;
+ }
+ else {
+ switch (tbl-cols[cur_cmp_ocol].type) {
+ case DBF_CHAR:
+ c1 = tbl-rows[*row1].values[cur_cmp_ocol].c;
+ c2 = tbl-rows[*row2].values[cur_cmp_ocol].c;
+ return (strcmp(c1, c2));
+ break;
+ case DBF_INT:
+ i1 = tbl-rows[*row1].values[cur_cmp_ocol].i;
+ i2 = tbl-rows[*row2].values[cur_cmp_ocol].i;
+ if (i1 i2)
+ return -1;
+ if (i1 i2)
+ return 1;
+ return 0;
+ break;
+ case DBF_DOUBLE:
+ d1 = tbl-rows[*row1].values[cur_cmp_ocol].d;
+ d2 = tbl-rows[*row2].values[cur_cmp_ocol].d;
+ if (d1 d2)
+ return -1;
+ if (d1 d2)
+ return 1;
+ return 0;
+ break;
+ }
+ return 0;
+ }
}
-return 0;
}
static int cmp_row_desc(const void *pa, const void *pb)
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
On Fri, Apr 3, 2009 at 9:20 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: ... Ok, try the attached diff to grass6 head. It implements the same behaviour for all data types: null values are sorted to the end. Perfect, this works. Please submit. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
On 03/04/09 09:31, Markus Neteler wrote: On Fri, Apr 3, 2009 at 9:20 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: ... Ok, try the attached diff to grass6 head. It implements the same behaviour for all data types: null values are sorted to the end. Perfect, this works. Please submit. Done, in trunk, devel6 and release64. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
Paolo, On Fri, Apr 3, 2009 at 10:04 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 03/04/09 09:31, Markus Neteler wrote: On Fri, Apr 3, 2009 at 9:20 AM, Moritz Lennert ... It implements the same behaviour for all data types: null values are sorted to the end. Perfect, this works. Please submit. Done, in trunk, devel6 and release64. I have retried your command: v.dissolve input=regiao layer=1 column=REGIAO output=reg_diss now it dissolves the map as expected. Also backported to 6.3 if that helps for you. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
Markus Neteler ha scritto: now it dissolves the map as expected. Also backported to 6.3 if that helps for you. Thanks a lot to all! -- Paolo Cavallini: http://faunalia.it/pc ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
Michael Barton ha scritto: Do you have a lot of null cells in your region? None. Tested also with a r.fractal surface, same results. All the best. -- Paolo Cavallini: http://faunalia.it/pc ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
Glynn Clements ha scritto: The entire notion of least cost is based upon the assumption that the cost must always be non-negative. Bingo, you got it! I had (by my mistake in mapcalc parameters) a few negative cells. Now r.cost runs, and I'doing further testing. I think your suggestions should be implemented: in the current situation the user doesn't have a clue of what is the problem. Thanks a lot! -- Paolo Cavallini: http://faunalia.it/pc ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
On Wed, Apr 1, 2009 at 6:05 PM, Paolo Cavallini cavall...@faunalia.it wrote:
Hi all.
I cannot get a result from v.dissolve:
v.dissolve input=reg...@nuovo layer=1 column=REGIAO output=reg_diss
dbmi: Protocol error
Cannot open select cursor: SELECT cat, REGIAO FROM regiao ORDER BY REGIAO
Unable to open vector map on topology level 2
Table linked to vector map does not exist
Vector map not found in current mapset
...
6.3.0.1-gfossit20090216-1
I got your data set and found:
GRASS 6.5.svn (portugal):~ echo SELECT cat, REGIAO FROM regiao
ORDER BY REGIAO | db.select
dbmi: Protocol error
GRASS 6.5.svn (portugal):~ echo SELECT cat, REGIAO FROM regiao | db.select
cat|REGIAO
1|NOROESTE CISMONTANO
2|ALTO PORTUGAL
3|ALTO PORTUGAL
but in db/driver/dbfexe.c I see
/* Order */
if (st-command == SQLP_SELECT st-orderCol) {
G_debug(3, Order selection by %s, st-orderCol);
/* Find order col */
cur_cmp_ocol = -1;
which suggests to me that ORDER BY should be supported.
Not sure why it fails.
Quick solution for you: use the SQLite driver.
Looking at
What's new in GRASS 6.3.0
* Source code quality/libraries:
...
o DBMI: SQL parser extended (support for DROP COLUMN,
ASC/DESC keyword in ORDER BY clause, etc.)
?
Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
On Thu, Apr 2, 2009 at 1:43 PM, Markus Neteler nete...@osgeo.org wrote:
On Wed, Apr 1, 2009 at 6:05 PM, Paolo Cavallini cavall...@faunalia.it wrote:
Hi all.
I cannot get a result from v.dissolve:
v.dissolve input=reg...@nuovo layer=1 column=REGIAO output=reg_diss
dbmi: Protocol error
Cannot open select cursor: SELECT cat, REGIAO FROM regiao ORDER BY REGIAO
Unable to open vector map on topology level 2
Table linked to vector map does not exist
Vector map not found in current mapset
...
6.3.0.1-gfossit20090216-1
I got your data set and found:
GRASS 6.5.svn (portugal):~ echo SELECT cat, REGIAO FROM regiao
ORDER BY REGIAO | db.select
dbmi: Protocol error
GRASS 6.5.svn (portugal):~ echo SELECT cat, REGIAO FROM regiao | db.select
cat|REGIAO
1|NOROESTE CISMONTANO
2|ALTO PORTUGAL
3|ALTO PORTUGAL
but in db/driver/dbfexe.c I see
/* Order */
if (st-command == SQLP_SELECT st-orderCol) {
G_debug(3, Order selection by %s, st-orderCol);
/* Find order col */
cur_cmp_ocol = -1;
which suggests to me that ORDER BY should be supported.
Not sure why it fails.
Offlist we figured it out:
If the REGIAO column field value is empty, then it fails. Perhaps
only happening with char columns. Somewhere here:
http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/db/drivers/dbf/dbfexe.c#L644
Any ideas why?
Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
On 02/04/09 16:00, Markus Neteler wrote:
On Thu, Apr 2, 2009 at 1:43 PM, Markus Neteler nete...@osgeo.org wrote:
On Wed, Apr 1, 2009 at 6:05 PM, Paolo Cavallini cavall...@faunalia.it wrote:
Hi all.
I cannot get a result from v.dissolve:
v.dissolve input=reg...@nuovo layer=1 column=REGIAO output=reg_diss
dbmi: Protocol error
Cannot open select cursor: SELECT cat, REGIAO FROM regiao ORDER BY REGIAO
Unable to open vector map on topology level 2
Table linked to vector map does not exist
Vector map not found in current mapset
...
6.3.0.1-gfossit20090216-1
I got your data set and found:
GRASS 6.5.svn (portugal):~ echo SELECT cat, REGIAO FROM regiao
ORDER BY REGIAO | db.select
dbmi: Protocol error
GRASS 6.5.svn (portugal):~ echo SELECT cat, REGIAO FROM regiao | db.select
cat|REGIAO
1|NOROESTE CISMONTANO
2|ALTO PORTUGAL
3|ALTO PORTUGAL
but in db/driver/dbfexe.c I see
/* Order */
if (st-command == SQLP_SELECT st-orderCol) {
G_debug(3, Order selection by %s, st-orderCol);
/* Find order col */
cur_cmp_ocol = -1;
which suggests to me that ORDER BY should be supported.
Not sure why it fails.
Offlist we figured it out:
If the REGIAO column field value is empty, then it fails. Perhaps
only happening with char columns. Somewhere here:
http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/db/drivers/dbf/dbfexe.c#L644
My wild guess would be that the problem is rather in the cmp_row_asc
function, where you have on line 481:
case DBF_CHAR:
c1 = tbl-rows[*row1].values[cur_cmp_ocol].c;
c2 = tbl-rows[*row2].values[cur_cmp_ocol].c;
return (strcmp(c1, c2));
break;
Don't know how strcmp handles empty values. Maybe you could add
something like
fprinf(stdout, c1 = %s, c2 = %s\n, a, b);
before the return statement to see the state of the respective character
variables ?
Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
On Thu, Apr 2, 2009 at 4:51 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 02/04/09 16:00, Markus Neteler wrote: On Thu, Apr 2, 2009 at 1:43 PM, Markus Neteler nete...@osgeo.org wrote: On Wed, Apr 1, 2009 at 6:05 PM, Paolo Cavallini cavall...@faunalia.it v.dissolve input=reg...@nuovo layer=1 column=REGIAO output=reg_diss dbmi: Protocol error ... Offlist we figured it out: If the REGIAO column field value is empty, then it fails. Perhaps only happening with char columns. Somewhere here: http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/db/drivers/dbf/dbfexe.c#L644 My wild guess would be that the problem is rather in the cmp_row_asc function, where you have on line 481: case DBF_CHAR: c1 = tbl-rows[*row1].values[cur_cmp_ocol].c; c2 = tbl-rows[*row2].values[cur_cmp_ocol].c; return (strcmp(c1, c2)); break; Don't know how strcmp handles empty values. Maybe you could add something like fprinf(stdout, c1 = %s, c2 = %s\n, a, b); before the return statement to see the state of the respective character variables ? Very good :) echo SELECT cat, REGIAO FROM regiao ORDER BY REGIAO | db.select D0/0: c1 = ALTO PORTUGAL, c2 = ALTO PORTUGAL D0/0: c1 = NOROESTE CISMONTANO, c2 = ALTO PORTUGAL D0/0: c1 = NOROESTE CISMONTANO, c2 = ALTO PORTUGAL D0/0: c1 = NOROESTE CISMONTANO, c2 = ALTO PORTUGAL D0/0: c1 = (null), c2 = ALTO PORTUGAL dbmi: Protocol error BAD happens when Null is found here. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
On 02/04/09 16:58, Markus Neteler wrote: On Thu, Apr 2, 2009 at 4:51 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 02/04/09 16:00, Markus Neteler wrote: On Thu, Apr 2, 2009 at 1:43 PM, Markus Neteler nete...@osgeo.org wrote: On Wed, Apr 1, 2009 at 6:05 PM, Paolo Cavallini cavall...@faunalia.it v.dissolve input=reg...@nuovo layer=1 column=REGIAO output=reg_diss dbmi: Protocol error ... Offlist we figured it out: If the REGIAO column field value is empty, then it fails. Perhaps only happening with char columns. Somewhere here: http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/db/drivers/dbf/dbfexe.c#L644 My wild guess would be that the problem is rather in the cmp_row_asc function, where you have on line 481: case DBF_CHAR: c1 = tbl-rows[*row1].values[cur_cmp_ocol].c; c2 = tbl-rows[*row2].values[cur_cmp_ocol].c; return (strcmp(c1, c2)); break; Don't know how strcmp handles empty values. Maybe you could add something like fprinf(stdout, c1 = %s, c2 = %s\n, a, b); before the return statement to see the state of the respective character variables ? Very good :) echo SELECT cat, REGIAO FROM regiao ORDER BY REGIAO | db.select D0/0: c1 = ALTO PORTUGAL, c2 = ALTO PORTUGAL D0/0: c1 = NOROESTE CISMONTANO, c2 = ALTO PORTUGAL D0/0: c1 = NOROESTE CISMONTANO, c2 = ALTO PORTUGAL D0/0: c1 = NOROESTE CISMONTANO, c2 = ALTO PORTUGAL D0/0: c1 = (null), c2 = ALTO PORTUGAL dbmi: Protocol error BAD happens when Null is found here. And that's arguably a correct behaviour as how should NULL be handled in such a comparison ? Don't know how it is dealt with in other DBMS... So, before we fix this in any way, we should probably agree to how to handle it. One possible way would be to check for nulls and if there are any to assign a return value according to our choice as to where to sort nulls to. Don't know how to check for an uninitialised char variable in C, but I imagine that it should be possible. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
On 02/04/09 18:12, Moritz Lennert wrote: On 02/04/09 16:58, Markus Neteler wrote: On Thu, Apr 2, 2009 at 4:51 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 02/04/09 16:00, Markus Neteler wrote: On Thu, Apr 2, 2009 at 1:43 PM, Markus Neteler nete...@osgeo.org wrote: On Wed, Apr 1, 2009 at 6:05 PM, Paolo Cavallini cavall...@faunalia.it v.dissolve input=reg...@nuovo layer=1 column=REGIAO output=reg_diss dbmi: Protocol error ... Offlist we figured it out: If the REGIAO column field value is empty, then it fails. Perhaps only happening with char columns. Somewhere here: http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/db/drivers/dbf/dbfexe.c#L644 My wild guess would be that the problem is rather in the cmp_row_asc function, where you have on line 481: case DBF_CHAR: c1 = tbl-rows[*row1].values[cur_cmp_ocol].c; c2 = tbl-rows[*row2].values[cur_cmp_ocol].c; return (strcmp(c1, c2)); break; Don't know how strcmp handles empty values. Maybe you could add something like fprinf(stdout, c1 = %s, c2 = %s\n, a, b); before the return statement to see the state of the respective character variables ? Very good :) echo SELECT cat, REGIAO FROM regiao ORDER BY REGIAO | db.select D0/0: c1 = ALTO PORTUGAL, c2 = ALTO PORTUGAL D0/0: c1 = NOROESTE CISMONTANO, c2 = ALTO PORTUGAL D0/0: c1 = NOROESTE CISMONTANO, c2 = ALTO PORTUGAL D0/0: c1 = NOROESTE CISMONTANO, c2 = ALTO PORTUGAL D0/0: c1 = (null), c2 = ALTO PORTUGAL dbmi: Protocol error BAD happens when Null is found here. And that's arguably a correct behaviour as how should NULL be handled in such a comparison ? Don't know how it is dealt with in other DBMS... So, before we fix this in any way, we should probably agree to how to handle it. One possible way would be to check for nulls and if there are any to assign a return value according to our choice as to where to sort nulls to. Don't know how to check for an uninitialised char variable in C, but I imagine that it should be possible. Actually, you should be able to check tbl-rows[*row1].values[cur_cmp_ocol].is_null and deal with the values accordingly, but from a casual glimpse I cannot find the possible values of is_null... I suppose 0 for false and 1 for true, but not sure...Use your example to check, with something like fprintf(stdout, row 1 null status = %i\n, tbl-rows[*row1].values[cur_cmp_ocol].is_null); Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
Furthermore, I launched r.cost on a 295 rows, 378 cols matrix, and it's taking 1h, whereas I did the same previously and it ran in tens of seconds. The speed of r.cost depends not just on the number of cells but also the complexity of the surface. Smoother surfaces seem to take longer than rough ones, I think because there are more possibilities for the algorithm to explore. However, if you're getting into the hours, I would think it's more likely that your region settings changed. Check g.region -p to be sure. Lastly, there seems to be a bug in r.cost that causes it to get confused on surfaces with lots of negative values (try running r.cost on a surface made by r.surf.fractal to see this). In these cases, I think it never finishes. -Colin ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
Colin Nielsen ha scritto: The speed of r.cost depends not just on the number of cells but also the complexity of the surface. Smoother surfaces seem to take longer than rough ones, I think because there are more possibilities for the algorithm to explore. Thanks for this Colin, I'm going to test. However, the matrix is very small (250x370), and I have the same results with or without the Knight's move. In the meantime, I solved the dissolve issue: it turned out that a few NULL fields triggered the event. I think this is a bug; I can share the file if someone wants to do further testing. All the best. -- Paolo Cavallini: http://faunalia.it/pc ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
Colin Nielsen ha scritto: However, if you're getting into the hours, I would think it's more likely that your region settings changed. Check g.region -p to be sure. Even if I bring resolution down to a ridiculous amount, it still takes forever: GRASS g.region -p projection: 99 (Transverse Mercator) zone: 0 datum: rome40 ellipsoid: international north: 4833555.85595178 south: 4804093.9108328 west: 1651001.9360271 east: 1688830.00910873 nsres: 1015.92914203 ewres: 995.47560741 rows: 29 cols: 38 cells: 1102 I tested it on a fractal surface, as you suggested. Is r.cost working for somebody? All the best, and thanks. -- Paolo Cavallini: http://faunalia.it/pc ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-dev] Re: [GRASS-user] v.dissolve and r.cost problems
Hi 2009/4/1 Paolo Cavallini cavall...@faunalia.it: But, is r.cost working for somebody else? r.cost is working for me (Ubuntu 8.10): GRASS 6.5.svn (nc_spm_08):~ r.cost -k streets_travtime output=streets_cost coor=634886,224328 --overwrite Reading raster map streets_travt...@user1... 100% Initializing output... 100% Finding cost path... 100% Writing raster map streets_cost... 100% 100% r.cost complete. Peak cost value: 15.509804. 450 rows x 500 cols ciao -- -- Paolo C. Lat. 44° 39' 11.08'' N Long. 7° 23' 25.26'' E ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
On Wed, Apr 1, 2009 at 6:05 PM, Paolo Cavallini cavall...@faunalia.it wrote: Hi all. I cannot get a result from v.dissolve: v.dissolve input=reg...@nuovo layer=1 column=REGIAO output=reg_diss dbmi: Protocol error Cannot open select cursor: SELECT cat, REGIAO FROM regiao ORDER BY REGIAO Unable to open vector map on topology level 2 Table linked to vector map does not exist Vector map not found in current mapset This happens on a specific column. The same shp dissolves well with fTools from QGIS. If you can send the data to me, I can investigate. Relevant post-6.3.0 fixes: 2008-12-20 17:07 martinl * v.dissolve: use instead of ' 2008-11-26 20:52 neteler * v.dissolve: added missing GIS_OPT_LAYER for layer 1 2008-10-24 21:39 neteler * v.dissolve: fix white space bugs (merge from trunk, r34004) 2008-01-17 01:24 hamish * : v.reclass does actually support strings as the key column 2008-01-17 01:17 hamish * : key type must be INTEGER 2007-06-01 13:03 markus * : fix for DBMI error if input map is specified with @mapset Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
On Apr 1, 2009, at 12:47 PM, grass-user-requ...@lists.osgeo.org wrote: From: Paolo Cavallini cavall...@faunalia.it Date: April 1, 2009 10:31:04 AM GMT-07:00 To: Colin Nielsen colin.niel...@gmail.com Cc: grass-user grass-user@lists.osgeo.org Subject: Re: [GRASS-user] v.dissolve and r.cost problems Reply-To: cavall...@faunalia.it Colin Nielsen ha scritto: However, if you're getting into the hours, I would think it's more likely that your region settings changed. Check g.region -p to be sure. Even if I bring resolution down to a ridiculous amount, it still takes forever: GRASS g.region -p projection: 99 (Transverse Mercator) zone: 0 datum: rome40 ellipsoid: international north: 4833555.85595178 south: 4804093.9108328 west: 1651001.9360271 east: 1688830.00910873 nsres: 1015.92914203 ewres: 995.47560741 rows: 29 cols: 38 cells: 1102 I tested it on a fractal surface, as you suggested. Is r.cost working for somebody? All the best, and thanks. -- Paolo Cavallini: http://faunalia.it/pc Do you have a lot of null cells in your region? Michael ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve and r.cost problems
Colin Nielsen wrote: Lastly, there seems to be a bug in r.cost that causes it to get confused on surfaces with lots of negative values (try running r.cost on a surface made by r.surf.fractal to see this). In these cases, I think it never finishes. That makes sense. If a group of adjacent cells have negative cost, the least-cost path will be the one which involves the most laps around the negative-cost area. In such a situation, the shortest path between two adjacent cells could be via a negative-cost area on the far side of the map. The entire notion of least cost is based upon the assumption that the cost must always be non-negative. If the cost map contains any negative values, it should either generate a fatal error, or treat such cells as nulls (exclude them or use the null_cost= value) and generate a warning. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
