[GRASS-user] Re: Exporting attributes to GMT ASCII format using v.out.ogr

GRASS GRASS user
1

IMHO choosing line/boundary as a default for ANY map
(i.e. even one that has no such geometries) is a bug,
not useful default behaviour.

So I would expect any scripts that use v.out.ogr in earnest
to be setting the type= option explicitly, anyhow.

The problem reported earlier with exporting areas
to GMT format seems to me to illustrate this.
The relationship between lines, boundaries and areas
can be very confusing, especially when data export/import
is concerned.

Actually, I would like to improve the area export logics
so that problems like Eric experienced will get more rare
in the future.

Anyhow, if there is a consensus that the old default
behaviour needs to stay, I will change the automatic
export type determination to only run on user demand,
via a flag.

Cheers,

Ben

----- Original Message -----
From: "Hamish" <hamish_b@yahoo.com>
To: "Eric Patton" <epatton@nrcan.gc.ca>
Cc: "grass-user" <grass-user@lists.osgeo.org>, "Hermann Peifer" <peifer@gmx.eu>
Sent: Monday, September 21, 2009 9:35:49 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: [GRASS-user] Re: Exporting attributes to GMT ASCII format using v.out.ogr

Hamish:

> I would ask if it acts any differently in latest grass
> 6.5 or 7 svn builds? (6.5 change may be reverted as it may
> break backwards compatibility / expected behaviour)

Eric:

Which change are you referring to? I'm using the latest
6.5.svn, and all seems to run smoothly.

make that "in new cases make things better, but subtly break backwards compatibility / expected behaviour in existing scripts."
ie an old script for 6.x should produce the same output as a new script at the cost of the default action not being as nice.
I don't really know if this is just hypothetical or if it could really screw somebody up. (ie if it matters or not)

r39128
https://trac.osgeo.org/grass/log/grass/branches/develbranch_6/vector/v.out.ogr

Hamish

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

------
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.

2

Benjamin Ducke wrote:

IMHO choosing line/boundary as a default for ANY map (i.e. even one that has no such geometries) is a bug,
not useful default behaviour.

So I would expect any scripts that use v.out.ogr in earnest
to be setting the type= option explicitly, anyhow.
  

IMHO, that applies to many vector modules. Having as default answer for the type option all types can produce unexpected and undesired results. The user would want a module to act only on certain types, but it is easy to forget setting the type option accordingly and then all vector object types are processed. Rather have the type option not set at all by default and exit with an error if no type is selected?

Markus M

The problem reported earlier with exporting areas
to GMT format seems to me to illustrate this.
The relationship between lines, boundaries and areas
can be very confusing, especially when data export/import
is concerned.

Actually, I would like to improve the area export logics
so that problems like Eric experienced will get more rare
in the future.

Anyhow, if there is a consensus that the old default
behaviour needs to stay, I will change the automatic
export type determination to only run on user demand,
via a flag.

Cheers,

Ben

----- Original Message -----
From: "Hamish" <hamish_b@yahoo.com>
To: "Eric Patton" <epatton@nrcan.gc.ca>
Cc: "grass-user" <grass-user@lists.osgeo.org>, "Hermann Peifer" <peifer@gmx.eu>
Sent: Monday, September 21, 2009 9:35:49 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: [GRASS-user] Re: Exporting attributes to GMT ASCII format using v.out.ogr

Hamish:
  

I would ask if it acts any differently in latest grass
6.5 or 7 svn builds? (6.5 change may be reverted as it may
break backwards compatibility / expected behaviour)
      
Eric:
  
Which change are you referring to? I'm using the latest
6.5.svn, and all seems to run smoothly.
    
make that "in new cases make things better, but subtly break backwards compatibility / expected behaviour in existing scripts."
ie an old script for 6.x should produce the same output as a new script at the cost of the default action not being as nice.
I don't really know if this is just hypothetical or if it could really screw somebody up. (ie if it matters or not)

r39128
https://trac.osgeo.org/grass/log/grass/branches/develbranch_6/vector/v.out.ogr

Hamish

      _______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

------
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-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

3

Please note that I have reverted the default for v.out.ogr's "type="
in 6.5 SVN to "line,boundary". In 7 SVN it remains "auto" and that
seems to work well enough.

The added challenge re. v.out.ogr is that not all supported OGR
formats can handle mixed geometries. Unfortunately, the current
GDAL 1.6 API also does not seem to have a function to query this,
so we can't deal with it in a more automated way just yet.

I agree that type selection in general needs a clean-up and
be more consistent and easy on the poor users. Let's collect some
ideas on this.

Ben

----- Original Message -----
From: "Markus Metz" <markus.metz.giswork@googlemail.com>
To: "Benjamin Ducke" <benjamin.ducke@oxfordarch.co.uk>, "grass-user" <grass-user@lists.osgeo.org>
Cc: "Hermann Peifer" <peifer@gmx.eu>, "Eric Patton" <epatton@nrcan.gc.ca>
Sent: Thursday, September 24, 2009 9:42:57 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: [GRASS-user] Re: Exporting attributes to GMT ASCII format using v.out.ogr

Benjamin Ducke wrote:

IMHO choosing line/boundary as a default for ANY map
(i.e. even one that has no such geometries) is a bug,
not useful default behaviour.

So I would expect any scripts that use v.out.ogr in earnest
to be setting the type= option explicitly, anyhow.
  

IMHO, that applies to many vector modules. Having as default answer for
the type option all types can produce unexpected and undesired results.
The user would want a module to act only on certain types, but it is
easy to forget setting the type option accordingly and then all vector
object types are processed. Rather have the type option not set at all
by default and exit with an error if no type is selected?

Markus M

The problem reported earlier with exporting areas
to GMT format seems to me to illustrate this.
The relationship between lines, boundaries and areas
can be very confusing, especially when data export/import
is concerned.

Actually, I would like to improve the area export logics
so that problems like Eric experienced will get more rare
in the future.

Anyhow, if there is a consensus that the old default
behaviour needs to stay, I will change the automatic
export type determination to only run on user demand,
via a flag.

Cheers,

Ben

----- Original Message -----
From: "Hamish" <hamish_b@yahoo.com>
To: "Eric Patton" <epatton@nrcan.gc.ca>
Cc: "grass-user" <grass-user@lists.osgeo.org>, "Hermann Peifer" <peifer@gmx.eu>
Sent: Monday, September 21, 2009 9:35:49 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: [GRASS-user] Re: Exporting attributes to GMT ASCII format using v.out.ogr

Hamish:
  

I would ask if it acts any differently in latest grass
6.5 or 7 svn builds? (6.5 change may be reverted as it may
break backwards compatibility / expected behaviour)
      
Eric:
  
Which change are you referring to? I'm using the latest
6.5.svn, and all seems to run smoothly.
    
make that "in new cases make things better, but subtly break backwards compatibility / expected behaviour in existing scripts."
ie an old script for 6.x should produce the same output as a new script at the cost of the default action not being as nice.
I don't really know if this is just hypothetical or if it could really screw somebody up. (ie if it matters or not)

r39128
https://trac.osgeo.org/grass/log/grass/branches/develbranch_6/vector/v.out.ogr

Hamish

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

------
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-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

------
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.

4

Hi all,

I am using grass6.5, so I can use some v.select options.

Now I have a general problem with objects that are very,
very close to each other: only some digits far behind the
comma are different.

Is there a way to define the accuracy?

Thanks for hints,
Achim

5

Benjamin Ducke wrote:

Please note that I have reverted the default for v.out.ogr's "type=" in 6.5 SVN to "line,boundary".

That's not exactly a bug (maybe yes because default settings can produce wrong results?), but areas won't be exported correctly with these default settings. The resulting shapefile has lines not polygons, and attributes get lost because boundaries usually don't have categories, and if they do have, these categories do not represent the properties of the two areas to the left and right. What would probably work most of the time is "point,line,area" as default.

Markus M

In 7 SVN it remains "auto" and that
seems to work well enough.

The added challenge re. v.out.ogr is that not all supported OGR
formats can handle mixed geometries. Unfortunately, the current
GDAL 1.6 API also does not seem to have a function to query this, so we can't deal with it in a more automated way just yet.

I agree that type selection in general needs a clean-up and
be more consistent and easy on the poor users. Let's collect some
ideas on this.

Ben

----- Original Message -----
From: "Markus Metz" <markus.metz.giswork@googlemail.com>
To: "Benjamin Ducke" <benjamin.ducke@oxfordarch.co.uk>, "grass-user" <grass-user@lists.osgeo.org>
Cc: "Hermann Peifer" <peifer@gmx.eu>, "Eric Patton" <epatton@nrcan.gc.ca>
Sent: Thursday, September 24, 2009 9:42:57 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: [GRASS-user] Re: Exporting attributes to GMT ASCII format using v.out.ogr

Benjamin Ducke wrote:
  

IMHO choosing line/boundary as a default for ANY map (i.e. even one that has no such geometries) is a bug,
not useful default behaviour.

So I would expect any scripts that use v.out.ogr in earnest
to be setting the type= option explicitly, anyhow.
  

IMHO, that applies to many vector modules. Having as default answer for the type option all types can produce unexpected and undesired results. The user would want a module to act only on certain types, but it is easy to forget setting the type option accordingly and then all vector object types are processed. Rather have the type option not set at all by default and exit with an error if no type is selected?

Markus M

The problem reported earlier with exporting areas
to GMT format seems to me to illustrate this.
The relationship between lines, boundaries and areas
can be very confusing, especially when data export/import
is concerned.

Actually, I would like to improve the area export logics
so that problems like Eric experienced will get more rare
in the future.

Anyhow, if there is a consensus that the old default
behaviour needs to stay, I will change the automatic
export type determination to only run on user demand,
via a flag.

Cheers,

Ben

----- Original Message -----
From: "Hamish" <hamish_b@yahoo.com>
To: "Eric Patton" <epatton@nrcan.gc.ca>
Cc: "grass-user" <grass-user@lists.osgeo.org>, "Hermann Peifer" <peifer@gmx.eu>
Sent: Monday, September 21, 2009 9:35:49 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: [GRASS-user] Re: Exporting attributes to GMT ASCII format using v.out.ogr

Hamish:
  

I would ask if it acts any differently in latest grass
6.5 or 7 svn builds? (6.5 change may be reverted as it may
break backwards compatibility / expected behaviour)
      

Eric:
  

Which change are you referring to? I'm using the latest
6.5.svn, and all seems to run smoothly.
    

make that "in new cases make things better, but subtly break backwards compatibility / expected behaviour in existing scripts."
ie an old script for 6.x should produce the same output as a new script at the cost of the default action not being as nice.
I don't really know if this is just hypothetical or if it could really screw somebody up. (ie if it matters or not)

r39128
https://trac.osgeo.org/grass/log/grass/branches/develbranch_6/vector/v.out.ogr

Hamish

      _______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

------
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-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

------
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-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

6

Benjamin Ducke wrote:

Please note that I have reverted the default for v.out.ogr's "type="
in 6.5 SVN to "line,boundary". In 7 SVN it remains "auto" and that
seems to work well enough.

thanks. I am glad to have the type=auto option in 6.5, it is a useful
addition.

maybe it is being a bit too strict with the no-changes to the module
interface in a stable release rule, but then we can't guarantee that
someone isn't aware of + relying on the old default=lines in a script,
so the best we can do is avoid as many backwards-incompatibilities as we
can and make the trunk version contain the ideal way. Plus this way we
can claim the new release is backwards-compatible without fine print.

cheers,
Hamish

7

On Thu, Sep 24, 2009 at 2:07 PM, achim <ak7@jupiter.uni-freiburg.de> wrote:

Hi all,

I am using grass6.5, so I can use some v.select options.

Now I have a general problem with objects that are very,
very close to each other: only some digits far behind the
comma are different.

Is there a way to define the accuracy?

The code uses Vect_select_lines_by_box():
http://download.osgeo.org/grass/grass6_progman/vector_2Vlib_2select_8c.html#b1754f710ac2001a10af2ff724d92ff5

So it takes what it finds. What is the exact problem? That
it takes too many? A simple example would be useful.

Markus

8

!!! I solved the problem by a workaround:
-> I deleted all lines, whose connected nodes both touch the same area

But the problem itself still exists.

The Problem is:
-I used a line, which crosses an area, to make the area bigger
-Then I tried to delete those lines, crossing and touching the area

-> crossing is no problem, but touching is a problem, I guess because of
in-consistences of roundings

I add an picture, explaining this and I hereby hint at my following mail
concerning with serious problems with rounding-snapping I have.

Markus Neteler schrieb:

On Thu, Sep 24, 2009 at 2:07 PM, achim <ak7@jupiter.uni-freiburg.de> wrote:

Hi all,

I am using grass6.5, so I can use some v.select options.

Now I have a general problem with objects that are very,
very close to each other: only some digits far behind the
comma are different.

Is there a way to define the accuracy?

The code uses Vect_select_lines_by_box():
http://download.osgeo.org/grass/grass6_progman/vector_2Vlib_2select_8c.html#b1754f710ac2001a10af2ff724d92ff5

So it takes what it finds. What is the exact problem? That
it takes too many? A simple example would be useful.

Markus

(attachments)

touching.png

9

Hi all,

I have a problem, I really would like to solve, because many problems
occur in my theses in further steps.

What I do is:

1. I break lines at some lengths.
2. I use both vector- and raster-data for analysis, which is eg.
updating points with raster-values or converting lines and points to raster.

The Problems are (due to rounding or "non-snapping"?):
!Points from lines on the edge between two diagonal cells (see pictures)!
These points do:
1. not belong precisely to one cell (compared with the line they come
from (see picture v.to.rast.png)
2. These points sometimes don't lie on on the cells, the line is
referred to (see picture break.png)

Any hints are very welcomed!

Thanks in advance,
Achim

(attachments)

break.png
v.to.rast.png

10

try temporarily increasing the region resolution by 2x for
the r.to.vect step.

?
Hamish

--- On Tue, 29/9/09, achim <ak7@jupiter.uni-freiburg.de> wrote:

From: achim <ak7@jupiter.uni-freiburg.de>
Subject: [GRASS-user] serious problem with "ROUND-OFF"
To: "grass-user" <grass-user@lists.osgeo.org>
Received: Tuesday, 29 September, 2009, 11:01 PM
Hi all,

I have a problem, I really would like to solve, because
many problems
occur in my theses in further steps.

What I do is:

1. I break lines at some lengths.
2. I use both vector- and raster-data for analysis, which
is eg.
updating points with raster-values or converting lines and
points to raster.

The Problems are (due to rounding or "non-snapping"?):
!Points from lines on the edge between two diagonal cells
(see pictures)!
These points do:
1. not belong precisely to one cell (compared with the line
they come
from (see picture v.to.rast.png)
2. These points sometimes don't lie on on the cells, the
line is
referred to (see picture break.png)

Any hints are very welcomed!

Thanks in advance,
Achim

-----Inline Attachment Follows-----

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

11

Thanks, but r.to.vect is not a problem, since I increase the resolution
by 3 and using a script, that produce a correct conversion.

(see picture)
Re: [GRASS-user] Re: IN: raster-flow-direction OUT:vector-network?

Hamish schrieb:

try temporarily increasing the region resolution by 2x for
the r.to.vect step.

?
Hamish

--- On Tue, 29/9/09, achim <ak7@jupiter.uni-freiburg.de> wrote:

From: achim <ak7@jupiter.uni-freiburg.de>
Subject: [GRASS-user] serious problem with "ROUND-OFF"
To: "grass-user" <grass-user@lists.osgeo.org>
Received: Tuesday, 29 September, 2009, 11:01 PM
Hi all,

I have a problem, I really would like to solve, because
many problems
occur in my theses in further steps.

What I do is:

1. I break lines at some lengths.
2. I use both vector- and raster-data for analysis, which
is eg.
updating points with raster-values or converting lines and
points to raster.

The Problems are (due to rounding or "non-snapping"?):
!Points from lines on the edge between two diagonal cells
(see pictures)!
These points do:
1. not belong precisely to one cell (compared with the line
they come
from (see picture v.to.rast.png)
2. These points sometimes don't lie on on the cells, the
line is
referred to (see picture break.png)

Any hints are very welcomed!

Thanks in advance,
Achim

-----Inline Attachment Follows-----

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

(attachments)

network_directions.png

12

Dear grass users,

I think I know what is needed...

to solve the problem (see below, mainly coming from splitting lines on
edges between raster-cells), I will have to:
1) identify the verts
2) move these verts on the line (direction of the line) at certain
distance (about half grid-size)

That would solve the problem mainly, but I have no idea how to deal with it.
Any help, suggestions or opinions are very welcome!

Thanks in advance,
Achim

achim schrieb:

Hi all,

I have a problem, I really would like to solve, because many problems
occur in my theses in further steps.

What I do is:

1. I break lines at some lengths.
2. I use both vector- and raster-data for analysis, which is eg.
updating points with raster-values or converting lines and points to raster.

The Problems are (due to rounding or "non-snapping"?):
!Points from lines on the edge between two diagonal cells (see pictures)!
These points do:
1. not belong precisely to one cell (compared with the line they come
from (see picture v.to.rast.png)
2. These points sometimes don't lie on on the cells, the line is
referred to (see picture break.png)

Any hints are very welcomed!

Thanks in advance,
Achim

------------------------------------------------------------------------

------------------------------------------------------------------------

------------------------------------------------------------------------

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

(attachments)

break.png

13

update for 1)

due to my raster-resolution of 30 seconds, I could get these points by
end-/startpoints-coordinates for each line:

When this coord is very close to 30.00 sec, the geometry of this vert
should be moved...

2) ...could this be done with vertexmove in v.edit, having the
coordinates? ...how can I find out the direction of the line?

A

achim schrieb:

Dear grass users,

I think I know what is needed...

to solve the problem (see below, mainly coming from splitting lines on
edges between raster-cells), I will have to:
1) identify the verts
2) move these verts on the line (direction of the line) at certain
distance (about half grid-size)

That would solve the problem mainly, but I have no idea how to deal with it.
Any help, suggestions or opinions are very welcome!

Thanks in advance,
Achim

achim schrieb:

Hi all,

I have a problem, I really would like to solve, because many problems
occur in my theses in further steps.

What I do is:

1. I break lines at some lengths.
2. I use both vector- and raster-data for analysis, which is eg.
updating points with raster-values or converting lines and points to raster.

The Problems are (due to rounding or "non-snapping"?):
!Points from lines on the edge between two diagonal cells (see pictures)!
These points do:
1. not belong precisely to one cell (compared with the line they come
from (see picture v.to.rast.png)
2. These points sometimes don't lie on on the cells, the line is
referred to (see picture break.png)

Any hints are very welcomed!

Thanks in advance,
Achim

------------------------------------------------------------------------

------------------------------------------------------------------------

------------------------------------------------------------------------

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

------------------------------------------------------------------------

------------------------------------------------------------------------

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user