[GRASS-user] how to clean vector file after reprojection

mlennert · February 6, 2007, 2:14pm

Hello,

I am trying to (inverse) project a vector file from an laea location to a lat-long location.

Here is what (an excerpt of) my source file looks like in v.digit:

http://moritz.homelinux.org/grass/v_proj_source.png

However, after projection, some areas are not recognized as areas anymore:

http://moritz.homelinux.org/grass/v_proj_target.png

I don't really see why as I don't see one-line nodes which would indicate an open boundary:

So, two questions:

1) What might be the problem with these areas ?

2) Which tool (v.clean ?) could I use to solve this ?

Thanks,

Moritz

H_B · February 6, 2007, 11:31pm

Moritz Lennert wrote:

I am trying to (inverse) project a vector file from an laea location
to a lat-long location.

..

2) Which tool (v.clean ?) could I use to solve this ?

Yes, try "v.clean tool=snap". Or before reprojection "v.clean
tool=break".

My guess is lines are not broken at intersections and reprojected lines
no longer exactly touch? (only verticies are projected)

Hamish

Markus_Neteler1 · February 7, 2007, 10:18am

Hamish wrote on 02/07/2007 12:31 AM:

Moritz Lennert wrote:


I am trying to (inverse) project a vector file from an laea location
to a lat-long location.


..


2) Which tool (v.clean ?) could I use to solve this ?

Yes, try "v.clean tool=snap". Or before reprojection "v.clean
tool=break".

My guess is lines are not broken at intersections and reprojected lines
no longer exactly touch? (only verticies are projected)

Could this be a precision problem in v.proj?
Markus

PS: Please don't use the old Baylor address if you want to reach all folks here
(maybe update your address book?)

mlennert · February 7, 2007, 2:22pm

On 07/02/07 00:31, Hamish wrote:

Moritz Lennert wrote:

I am trying to (inverse) project a vector file from an laea location
to a lat-long location.

..

2) Which tool (v.clean ?) could I use to solve this ?

Yes, try "v.clean tool=snap". Or before reprojection "v.clean
tool=break".

'break' on the source map does not find any intersections to break.

'snap' on target map (v.clean in=nuts2 out=nuts2_snap_0_001 tool=snap thresh=0.001 - which if I calculated correctly should snap anything within a bit more than 100 meters) gives me an even worse result (even less areas are recognized):

http://moritz.homelinux.org/grass/v_proj_target_after_snap.png

My guess is lines are not broken at intersections and reprojected lines
no longer exactly touch? (only verticies are projected)

Yes, that is the problem. I had mistakenly assumed that an end of line automatically is a 'node' and that unclosed lines would show up as one-line nodes. But I see that unclosed ends of lines are not nodes and are, therefore not visible in v.digit...

But, really strange: looking at the same spot in the source map, the line also is not closed, but is still recognized as an area... ???

Will have to explore this some more.

Moritz

mlennert · February 7, 2007, 4:18pm

On 07/02/07 15:22, Moritz Lennert wrote:

On 07/02/07 00:31, Hamish wrote:

Moritz Lennert wrote:

I am trying to (inverse) project a vector file from an laea location
to a lat-long location.

..

2) Which tool (v.clean ?) could I use to solve this ?

Yes, try "v.clean tool=snap". Or before reprojection "v.clean
tool=break".

'break' on the source map does not find any intersections to break.

'snap' on target map (v.clean in=nuts2 out=nuts2_snap_0_001 tool=snap thresh=0.001 - which if I calculated correctly should snap anything within a bit more than 100 meters) gives me an even worse result (even less areas are recognized):

http://moritz.homelinux.org/grass/v_proj_target_after_snap.png

My guess is lines are not broken at intersections and reprojected lines
no longer exactly touch? (only verticies are projected)

Yes, that is the problem. I had mistakenly assumed that an end of line automatically is a 'node' and that unclosed lines would show up as one-line nodes. But I see that unclosed ends of lines are not nodes and are, therefore not visible in v.digit...

But, really strange: looking at the same spot in the source map, the line also is not closed, but is still recognized as an area... ???

Will have to explore this some more.

Ok, here is what I see in the source location:

http://moritz.homelinux.org/grass/source_display.jpg

And in v.digit:

http://moritz.homelinux.org/grass/source_v_digit1.jpg

Zooming in to the area marked by the red circle:

http://moritz.homelinux.org/grass/source_v_digit2.jpg

And zooming even further (I'm in the centimeter range there):

http://moritz.homelinux.org/grass/source_v_digit3.jpg

The lines are not closed, but they are still recognized as an area.

I assume I must be getting something wrong here, but I don't really understand what...

Any hint would be welcome.

Moritz

H_B · February 7, 2007, 11:19pm

Moritz Lennert wrote:

> Yes, try "v.clean tool=snap". Or before reprojection "v.clean
> tool=break".

'break' on the source map does not find any intersections to break.

'snap' on target map (v.clean in=nuts2 out=nuts2_snap_0_001 tool=snap
thresh=0.001 - which if I calculated correctly should snap anything
within a bit more than 100 meters) gives me an even worse result (even
less areas are recognized):

try making snap very small in the lat/lon location. The default is
intended to be 1mm, not 1degX10-3. so try 1e-8. Based on your other
screenshots what about enlarging the snap thresh to 0.1 or so (in the
source loc'n) to get those lines to connect before reprojection? I take
it the same lines do not connect with d.vect+d.zoom? It is very odd.

Note that if you zoom waaaaaay in on a corner with d.vect+d.zoom in an
xmon sometimes one of the lines going off screen will disappear but the
area remains filled. That's a rendering bug & I've never seen it miss a
line segment with both ends on screen.

Hamish

mlennert · February 8, 2007, 11:27am

On 08/02/07 00:19, Hamish wrote:

Moritz Lennert wrote:

Yes, try "v.clean tool=snap". Or before reprojection "v.clean
tool=break".

'break' on the source map does not find any intersections to break.

'snap' on target map (v.clean in=nuts2 out=nuts2_snap_0_001 tool=snap thresh=0.001 - which if I calculated correctly should snap anything within a bit more than 100 meters) gives me an even worse result (even
less areas are recognized):

try making snap very small in the lat/lon location. The default is
intended to be 1mm, not 1degX10-3. so try 1e-8.

tried this, but it makes it worse (thresh=0.000000001):

http://moritz.homelinux.org/grass/target_snap_0_000000001.jpg

Based on your other
screenshots what about enlarging the snap thresh to 0.1 or so (in the
source loc'n) to get those lines to connect before reprojection?

http://moritz.homelinux.org/grass/source_snap_0_1.jpg.jpg

I take
it the same lines do not connect with d.vect+d.zoom?

That is another issue I have: trying to zoom in either in the GIS Manager or with d.vect+d.zoom I get CPU overheating (never had that before) and memory errors when I get to around 1e-8.

It is very odd.

Yes. I don't understand the lose edges without nodes...

Actually the original files were shapefiles, and so I finally did the reprojection with the shpproj tool from shapelib. I can then import the resulting file into a lat-long GRASS location and there are no problems.

...

Exploring this a bit further: I just tried duplicating the cleaning done by v.in.ogr by launching:

v.clean in=inmap out=outmap_clean_vinogr tool=snap,bpol,rmdupl,break,rmdupl,rmsa,chdangle,rmdangle,chbridge,rmbridge thresh=0.000001

And, behold !, I get a perfect map. So, now I have to isolate which of the cleaning tools did the job.

Moritz