Exporting attributes to GMT ASCII format using v.out.ogr

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Exporting attributes to GMT ASCII format using v.out.ogr

Eric Patton
Hi,

I'm using v.out.ogr to export GRASS vectors to GMT format. The geometry
exports fine, but the attributes don't seem to be in the GMT file after
the export finishes. I can see the attribute column names in the GMT
header portion of the file, but all I get in the data columns are the x
and y, followed by a zero in the third column.

Any special CREATEOPT parameters that need to be passed? I checked on
the OGR website and there wasn't any hints about it; same with the
v.out.ogr manual (GMT format isn't even mentioned there).

Thanks,

--
Eric Patton
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: Exporting attributes to GMT ASCII format using v.out.ogr

hamish-2
Eric:

> I'm using v.out.ogr to export GRASS vectors to GMT format.
> The geometry exports fine, but the attributes don't seem
> to be in the GMT file after the export finishes. I can see
> the attribute column names in the GMT header portion of
> the file, but all I get in the data columns are the x
> and y, followed by a zero in the third column.
>
> Any special CREATEOPT parameters that need to be passed? I
> checked on the OGR website and there wasn't any hints about
> it; same with the v.out.ogr manual (GMT format isn't even
> mentioned there).


no new help to offer, but if you find something out it would be
good to add it to the wiki page:

   http://grass.osgeo.org/wiki/GMT#Vector


if nothing on the format page at the GDAL/OGR website, for CREATEOPT
you might have to go exploring in the OGR source code.



Hamish



     
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: Exporting attributes to GMT ASCII format using v.out.ogr

peifer
Hamish wrote:

> Eric:
>> I'm using v.out.ogr to export GRASS vectors to GMT format.
>> The geometry exports fine, but the attributes don't seem
>> to be in the GMT file after the export finishes. I can see
>> the attribute column names in the GMT header portion of
>> the file, but all I get in the data columns are the x
>> and y, followed by a zero in the third column.
>>
>> Any special CREATEOPT parameters that need to be passed? I
>> checked on the OGR website and there wasn't any hints about
>> it; same with the v.out.ogr manual (GMT format isn't even
>> mentioned there).
>
>
> no new help to offer, but if you find something out it would be
> good to add it to the wiki page:
>
>    http://grass.osgeo.org/wiki/GMT#Vector
>
>
> if nothing on the format page at the GDAL/OGR website, for CREATEOPT
> you might have to go exploring in the OGR source code.
>


A plain: v.out.ogr RBD_F1v3 format=GMT dsn=RBD_F1v3.gmt results into:

# FEATURE_DATA
>
# @D||||||||||||||||||||||||||


but  v.out.ogr RBD_F1v3 format=GMT type=area dsn=RBD_F1v3.gmt gives:

# FEATURE_DATA
>
# @D1|"Fleuves et cours d'eau cotiers de la Guyane"|fr|FR|"Guyana (French)"|83892.657134|W1001|FRW1001|FRK||"North Western Atlantic Ocean"|"Open Ocean"||W10000000|FRW10000000|W1|N|Y|2005-06-03|FR1||2008-02-26|ASB|136|FRK|1660787.48438|83892657133.7


Hope this helps, Hermann
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: Exporting attributes to GMT ASCII format using v.out.ogr

hamish-2
Hermann wrote:

> A plain: v.out.ogr RBD_F1v3 format=GMT dsn=RBD_F1v3.gmt
> results into:
>
> # FEATURE_DATA
> >
> # @D||||||||||||||||||||||||||
>
>
> but  v.out.ogr RBD_F1v3 format=GMT type=area dsn=RBD_F1v3.gmt gives:
>
> # FEATURE_DATA
> >
> # @D1|"Fleuves et cours d'eau cotiers de la Guyane"|fr|FR|"Guyana
> (French)"|83892.657134|W1001|FRW1001|FRK||"North Western Atlantic Ocean"|"Open Ocean"||W10000000|FRW10000000|W1|N|Y|2005-06-03|FR1||2008-02-26|ASB|136|FRK|1660787.48438|83892657133.7
>
>
> Hope this helps, Hermann

I think it does, the default for v.out.ogr is type=line,boundary

tip added in  http://grass.osgeo.org/wiki/GMT#Vector


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)


Hamish




_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: Exporting attributes to GMT ASCII format using v.out.ogr

Eric Patton
Hamish wrote:

> Hermann wrote:
> > A plain: v.out.ogr RBD_F1v3 format=GMT dsn=RBD_F1v3.gmt
> > results into:
> >
> > # FEATURE_DATA
> > >
> > # @D||||||||||||||||||||||||||
> >
> >
> > but  v.out.ogr RBD_F1v3 format=GMT type=area dsn=RBD_F1v3.gmt gives:
> >
> > # FEATURE_DATA
> > >
> > # @D1|"Fleuves et cours d'eau cotiers de la Guyane"|fr|FR|"Guyana
> > (French)"|83892.657134|W1001|FRW1001|FRK||"North Western Atlantic Ocean"|"Open Ocean"||W10000000|FRW10000000|W1|N|Y|2005-06-03|FR1||2008-02-26|ASB|136|FRK|1660787.48438|83892657133.7
> >
> >
> > Hope this helps, Hermann
>
> I think it does, the default for v.out.ogr is type=line,boundary
>
> tip added in  http://grass.osgeo.org/wiki/GMT#Vector

Yes, that was the problem I was having - wrong or missing type
parameter.

> 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)
>
> Hamish

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

--
Eric Patton
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: Exporting attributes to GMT ASCII format using v.out.ogr

hamish-2
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: Re: Exporting attributes to GMT ASCII format using v.out.ogr

Benjamin Ducke
In reply to this post by Eric Patton
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" <[hidden email]>
To: "Eric Patton" <[hidden email]>
Cc: "grass-user" <[hidden email]>, "Hermann Peifer" <[hidden email]>
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
[hidden email]
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: Re: Exporting attributes to GMT ASCII format using v.out.ogr

Markus Metz-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" <[hidden email]>
> To: "Eric Patton" <[hidden email]>
> Cc: "grass-user" <[hidden email]>, "Hermann Peifer" <[hidden email]>
> 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
> [hidden email]
> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>  
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: Re: Exporting attributes to GMT ASCII format using v.out.ogr

Benjamin Ducke
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" <[hidden email]>
To: "Benjamin Ducke" <[hidden email]>, "grass-user" <[hidden email]>
Cc: "Hermann Peifer" <[hidden email]>, "Eric Patton" <[hidden email]>
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" <[hidden email]>
> To: "Eric Patton" <[hidden email]>
> Cc: "grass-user" <[hidden email]>, "Hermann Peifer" <[hidden email]>
> 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
> [hidden email]
> 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
> [hidden email]
> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

thresh in v.select?

Achim Kisseler
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
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: Re: Exporting attributes to GMT ASCII format using v.out.ogr

Markus Metz-2
In reply to this post by Benjamin Ducke

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" <[hidden email]>
> To: "Benjamin Ducke" <[hidden email]>, "grass-user" <[hidden email]>
> Cc: "Hermann Peifer" <[hidden email]>, "Eric Patton" <[hidden email]>
> 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" <[hidden email]>
>> To: "Eric Patton" <[hidden email]>
>> Cc: "grass-user" <[hidden email]>, "Hermann Peifer" <[hidden email]>
>> 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
>> [hidden email]
>> 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
>> [hidden email]
>> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>  
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: Re: Exporting attributes to GMT ASCII format using v.out.ogr

hamish-2
In reply to this post by Benjamin Ducke
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




_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: thresh in v.select?

Markus Neteler
In reply to this post by Achim Kisseler
On Thu, Sep 24, 2009 at 2:07 PM, achim <[hidden email]> 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
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: thresh in v.select?

Achim Kisseler
!!! 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 <[hidden email]> 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

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

touching.png (23K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

serious problem with "ROUND-OFF"

Achim Kisseler
In reply to this post by Markus Neteler
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

break.png (79K) Download Attachment
v.to.rast.png (17K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: serious problem with "ROUND-OFF"

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

?
Hamish



--- On Tue, 29/9/09, achim <[hidden email]> wrote:

> From: achim <[hidden email]>
> Subject: [GRASS-user] serious problem with "ROUND-OFF"
> To: "grass-user" <[hidden email]>
> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-user
>



_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: serious problem with "ROUND-OFF"

Achim Kisseler
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 <[hidden email]> wrote:
>
>> From: achim <[hidden email]>
>> Subject: [GRASS-user] serious problem with "ROUND-OFF"
>> To: "grass-user" <[hidden email]>
>> 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
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>
>
>
>      

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

network_directions.png (141K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: serious problem with "ROUND-OFF"

Achim Kisseler
In reply to this post by Achim Kisseler
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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-user

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

break.png (79K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: serious problem with "ROUND-OFF"

Achim Kisseler
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
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> grass-user mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/grass-user
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: serious problem with "ROUND-OFF"

Achim Kisseler
In reply to this post by Achim Kisseler
Hi Hamish,

thanks for your suggestions. It is very useful to get ideas from a
different perspective!

I am sorry, that I have to write a 'but' again:

> > r.to.vect the area
..I have no areas to extract. I have a river network, for which I want
to subdivide some lines.
Because I have some thousands of lines, I always get some
start/end-nodes on these critical points on the border between two
raster-cells.

> > add cats to boundaries with v.category
> > v.type the boundary to line
> > v.extract the lines
> > v.buffer the lines to about the cell width
> > v.overlay op=not
Otherwise that would help!! (Even though v.buffer would take sooo... long)

Best regards,
Achim

> >
> > ?
> >
> >
> > Hamish
> >
> >
> >
> > --- On Wed, 30/9/09, achim <[hidden email]> wrote:
> >
>> >> From: achim <[hidden email]>
>> >> Subject: Re: [GRASS-user] serious problem with "ROUND-OFF"
>> >> To: "grass-user" <[hidden email]>
>> >> Received: Wednesday, 30 September, 2009, 4:37 AM
>> >> 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
>>> >>> [hidden email]
>>> >>> http://lists.osgeo.org/mailman/listinfo/grass-user
>> >> -----Inline Attachment Follows-----
>> >>
>> >> _______________________________________________
>> >> grass-user mailing list
>> >> [hidden email]
>> >> http://lists.osgeo.org/mailman/listinfo/grass-user
>> >>
> >
> >
> >
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
12