Hello,
I'm using these commands:
v.clean input=test_ln output=testclean_ln tool=snap,bpol thresh=0.2,0
v.type input=testclean_ln output=testclean_bnd type=line,boundary
v.centroids input=testclean_bnd output=testclean_py
trying to convert a bunch of lines to 5 polygons. I've tried lots of
variations of v.clean including many snap thresholds, but I can only get 3
polygons. Is there something I'm doing wrong?
Check out the line and polygons here:
http://www.ideotrope.org/~bryan/lines.png
http://www.ideotrope.org/~bryan/polygons.png
Bryan
On 09/22/2010 12:45 AM, Bryan Keith wrote:
Hello,
I'm using these commands:
v.clean input=test_ln output=testclean_ln tool=snap,bpol thresh=0.2,0
v.type input=testclean_ln output=testclean_bnd type=line,boundary
v.centroids input=testclean_bnd output=testclean_py
trying to convert a bunch of lines to 5 polygons. I've tried lots of
variations of v.clean including many snap thresholds, but I can only get 3
polygons. Is there something I'm doing wrong?
If it's only two missing, then just manually add centroids to those two areas that are not yet polygons. (using v.digit)
Check out the line and polygons here:
http://www.ideotrope.org/~bryan/lines.png
http://www.ideotrope.org/~bryan/polygons.png
Bryan
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
This mail was received via Mail-SeCure System.
--
Micha Silver
Arava Development Co. +972-52-3665918
http://surfaces.co.il
On 09/22/2010 12:45 AM, Bryan Keith wrote:
Hello,
I'm using these commands:
v.clean input=test_ln output=testclean_ln tool=snap,bpol thresh=0.2,0
v.type input=testclean_ln output=testclean_bnd type=line,boundary
v.centroids input=testclean_bnd output=testclean_py
trying to convert a bunch of lines to 5 polygons. I've tried lots of
variations of v.clean including many snap thresholds, but I can only get
3
polygons. Is there something I'm doing wrong?
If it's only two missing, then just manually add centroids to those two
areas that are not yet polygons. (using v.digit)
Well, it's two in this simple little example clipped from a larger file,
and I have lots of files to process so I'm looking for an automated
process.
Bryan
Check out the line and polygons here:
http://www.ideotrope.org/~bryan/lines.png
http://www.ideotrope.org/~bryan/polygons.png
Bryan
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
This mail was received via Mail-SeCure System.
--
Micha Silver
Arava Development Co. +972-52-3665918
http://surfaces.co.il
On 09/22/2010 02:40 PM, Bryan Keith wrote:
On 09/22/2010 12:45 AM, Bryan Keith wrote:
Hello,
I'm using these commands:
v.clean input=test_ln output=testclean_ln tool=snap,bpol thresh=0.2,0
v.type input=testclean_ln output=testclean_bnd type=line,boundary
v.centroids input=testclean_bnd output=testclean_py
trying to convert a bunch of lines to 5 polygons. I've tried lots of
variations of v.clean including many snap thresholds, but I can only get
3
polygons. Is there something I'm doing wrong?
If it's only two missing, then just manually add centroids to those two
areas that are not yet polygons. (using v.digit)
Well, it's two in this simple little example clipped from a larger file,
and I have lots of files to process so I'm looking for an automated
process.
Can you figure out why other areas were not closed? Maybe you need a larger threshold value?
By opening the vector with v.digit you'll see by the color coding of the nodes which are part of closed boundaries (dark green) and which are on a "broken" boundary (red).
You'll also see quickly where you have centroids inside correct boundaries, and where you're missing them.
Bryan
Check out the line and polygons here:
http://www.ideotrope.org/~bryan/lines.png
http://www.ideotrope.org/~bryan/polygons.png
Bryan
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
This mail was received via Mail-SeCure System.
--
Micha Silver
Arava Development Co. +972-52-3665918
http://surfaces.co.il
This mail was received via Mail-SeCure System.
--
Micha Silver
Arava Development Co. +972-52-3665918
http://surfaces.co.il
Micha Silver wrote:
Bryan Keith wrote:
Bryan Keith wrote:
Hello,
I'm using these commands:
v.clean input=test_ln output=testclean_ln tool=snap,bpol thresh=0.2,0
v.type input=testclean_ln output=testclean_bnd type=line,boundary
v.centroids input=testclean_bnd output=testclean_py
trying to convert a bunch of lines to 5 polygons. I've tried lots of
variations of v.clean including many snap thresholds, but I can only get
3
polygons. Is there something I'm doing wrong?
If it's only two missing, then just manually add centroids to those two
areas that are not yet polygons. (using v.digit)
Well, it's two in this simple little example clipped from a larger file,
and I have lots of files to process so I'm looking for an automated
process.
Can you figure out why other areas were not closed? Maybe you need a larger
threshold value?
By opening the vector with v.digit you'll see by the color coding of the
nodes which are part of closed boundaries (dark green) and which are on a
"broken" boundary (red).
You'll also see quickly where you have centroids inside correct boundaries,
and where you're missing them.
All this information (incorrect boundaries, centroids outside areas)
is printed by default as output of v.clean, when topology for the
cleaned vector is built. As long as any incorrect boundaries,
centroids outside areas or duplicate centroids are reported, the
vector is not clean and v.centroids will not be able to put a centroid
into every area that is supposed to be there (v.centroids does put a
centroid into each area that actually is there).
Markus M
Bryan
Check out the line and polygons here:
http://www.ideotrope.org/~bryan/lines.png
http://www.ideotrope.org/~bryan/polygons.png
Bryan
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
This mail was received via Mail-SeCure System.
--
Micha Silver
Arava Development Co. +972-52-3665918
http://surfaces.co.il
This mail was received via Mail-SeCure System.
--
Micha Silver
Arava Development Co. +972-52-3665918
http://surfaces.co.il
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
On 09/22/2010 02:40 PM, Bryan Keith wrote:
On 09/22/2010 12:45 AM, Bryan Keith wrote:
Hello,
I'm using these commands:
v.clean input=test_ln output=testclean_ln tool=snap,bpol thresh=0.2,0
v.type input=testclean_ln output=testclean_bnd type=line,boundary
v.centroids input=testclean_bnd output=testclean_py
trying to convert a bunch of lines to 5 polygons. I've tried lots of
variations of v.clean including many snap thresholds, but I can only
get
3
polygons. Is there something I'm doing wrong?
If it's only two missing, then just manually add centroids to those two
areas that are not yet polygons. (using v.digit)
Well, it's two in this simple little example clipped from a larger file,
and I have lots of files to process so I'm looking for an automated
process.
Can you figure out why other areas were not closed? Maybe you need a
larger threshold value?
By opening the vector with v.digit you'll see by the color coding of the
nodes which are part of closed boundaries (dark green) and which are on
a "broken" boundary (red).
You'll also see quickly where you have centroids inside correct
boundaries, and where you're missing them.
No, I can't figure out why the other areas were not closed. A larger
threshold value does not help. I have never used v.digit, and I actually
can't get anything to display with v.digit Hmmm, I'm not sure what I'm
doing wrong with v.digit
I would be nice to be able to see where nodes aren't connected (I'm
guessing that's the problem) and be able to measure how far apart they are
from each other. I'm surprised how increasing the threshold makes some
boundaries that were correct incorrect.
Bryan
Check out the line and polygons here:
http://www.ideotrope.org/~bryan/lines.png
http://www.ideotrope.org/~bryan/polygons.png
Bryan
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
This mail was received via Mail-SeCure System.
--
Micha Silver
Arava Development Co. +972-52-3665918
http://surfaces.co.il
This mail was received via Mail-SeCure System.
--
Micha Silver
Arava Development Co. +972-52-3665918
http://surfaces.co.il
On 09/23/2010 05:42 PM, Bryan Keith wrote:
On 09/22/2010 02:40 PM, Bryan Keith wrote:
On 09/22/2010 12:45 AM, Bryan Keith wrote:
Hello,
I'm using these commands:
v.clean input=test_ln output=testclean_ln tool=snap,bpol thresh=0.2,0
v.type input=testclean_ln output=testclean_bnd type=line,boundary
v.centroids input=testclean_bnd output=testclean_py
trying to convert a bunch of lines to 5 polygons. I've tried lots of
variations of v.clean including many snap thresholds, but I can only
get
3
polygons. Is there something I'm doing wrong?
If it's only two missing, then just manually add centroids to those two
areas that are not yet polygons. (using v.digit)
Well, it's two in this simple little example clipped from a larger file,
and I have lots of files to process so I'm looking for an automated
process.
Can you figure out why other areas were not closed? Maybe you need a
larger threshold value?
By opening the vector with v.digit you'll see by the color coding of the
nodes which are part of closed boundaries (dark green) and which are on
a "broken" boundary (red).
You'll also see quickly where you have centroids inside correct
boundaries, and where you're missing them.
No, I can't figure out why the other areas were not closed. A larger
threshold value does not help. I have never used v.digit, and I actually
can't get anything to display with v.digit Hmmm, I'm not sure what I'm
doing wrong with v.digit
What OS are you on? what version of GRASS, and what GUI?
I would be nice to be able to see where nodes aren't connected (I'm
guessing that's the problem) and be able to measure how far apart they are
from each other. I'm surprised how increasing the threshold makes some
boundaries that were correct incorrect.
Yes, Surprising. Can we see, as Markus M suggested, the output of v.info -t or v.clean? Also what units is your data in? i.e the output of v.info -g and g.region -p ?
Regards,
--
Micha
Bryan
Check out the line and polygons here:
http://www.ideotrope.org/~bryan/lines.png
http://www.ideotrope.org/~bryan/polygons.png
Bryan
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
This mail was received via Mail-SeCure System.
--
Micha Silver
Arava Development Co. +972-52-3665918
http://surfaces.co.il
This mail was received via Mail-SeCure System.
--
Micha Silver
Arava Development Co. +972-52-3665918
http://surfaces.co.il
This mail was received via Mail-SeCure System.
--
Micha Silver
Arava Development Co. +972-52-3665918
http://surfaces.co.il
On 09/22/2010 12:45 AM, Bryan Keith wrote:
Hello,
I'm using these commands:
v.clean input=test_ln output=testclean_ln tool=snap,bpol
thresh=0.2,0
v.type input=testclean_ln output=testclean_bnd type=line,boundary
v.centroids input=testclean_bnd output=testclean_py
and I have lots of files to process so I'm looking for an automated
process.
Can you figure out why other areas were not closed? Maybe you need a
larger threshold value?
By opening the vector with v.digit you'll see by the color coding of
the
nodes which are part of closed boundaries (dark green) and which are on
a "broken" boundary (red).
You'll also see quickly where you have centroids inside correct
boundaries, and where you're missing them.
No, I can't figure out why the other areas were not closed. A larger
threshold value does not help. I have never used v.digit, and I
actually
can't get anything to display with v.digit Hmmm, I'm not sure what I'm
doing wrong with v.digit
What OS are you on? what version of GRASS, and what GUI?
I'll answer these questions anyway, but I figured out the v.digit problem
(see below).
Windows XP
GRASS 6.4.0
wxGUI
I would be nice to be able to see where nodes aren't connected (I'm
guessing that's the problem) and be able to measure how far apart they
are
from each other. I'm surprised how increasing the threshold makes some
boundaries that were correct incorrect.
Yes, Surprising. Can we see, as Markus M suggested, the output of v.info
-t or v.clean? Also what units is your data in? i.e the output of v.info
-g and g.region -p ?
OK, getting closer, I think. The reason v.digit wasn't working was
because g.region was set incorrectly. Now I can look at the various maps
with v.digit and see the different colors of the lines and nodes. In the
meantime I created a very simple example and processed that map and was
able to get results that I expected. So then I looked at the one that
worked and the one that didn't using v.digit to see what the differences
were.
The files that doesn't have all the areas that I expect has lines that are
displayed orange (Boundary (1 area)) while the correct version has lines
that are display green (Boundary (2 areas)). Could that be why I'm not
getting all the areas that I expect? All the nodes look correct (no red
ones). How do I fix this? An option in v.clean?
Bryan
Check out the line and polygons here:
http://www.ideotrope.org/~bryan/lines.png
http://www.ideotrope.org/~bryan/polygons.png
Bryan
On 09/23/2010 07:36 PM, Bryan Keith wrote:
What OS are you on? what version of GRASS, and what GUI?
I'll answer these questions anyway, but I figured out the v.digit problem
(see below).
Windows XP
GRASS 6.4.0
wxGUI
So you'll be using the tcltk digitizer. (wxGui doesn't work yet in Windows)
OK, getting closer, I think. The reason v.digit wasn't working was
because g.region was set incorrectly. Now I can look at the various maps
with v.digit and see the different colors of the lines and nodes. In the
meantime I created a very simple example and processed that map and was
able to get results that I expected. So then I looked at the one that
worked and the one that didn't using v.digit to see what the differences
were.
The files that doesn't have all the areas that I expect has lines that are
displayed orange (Boundary (1 area)) while the correct version has lines
that are display green (Boundary (2 areas)). Could that be why I'm not
getting all the areas that I expect? All the nodes look correct (no red
ones). How do I fix this? An option in v.clean?
Orange boundaries are duplicates - overlapping lines - that GRASS topology doesn't allow.
You should be able to get rid of these with:
"v.clean in=... out=... tool=break,bpol,rmdupl"
But I've never had good luck with this.
The alternative that might work better for you:
Re-import the layer from the original shapefiles (or where ever they came from) but use the "type=line" option to v.in.ogr. (No centroids will be created)
Now do v.clean on this new GRASS vector, using tool=snap,break,rmdupl. Next use
"v.type ... type=line,boundary"
to convert the (cleaned) lines to boundaries, and then
"v.centroids ... opt=add"
to create area centroids inside each closed boundary.
--
Micha
Bryan
--
Micha Silver
Arava Development Co. +972-52-3665918
http://surfaces.co.il
On 09/23/2010 07:36 PM, Bryan Keith wrote:
What OS are you on? what version of GRASS, and what GUI?
I'll answer these questions anyway, but I figured out the v.digit
problem
(see below).
Windows XP
GRASS 6.4.0
wxGUI
So you'll be using the tcltk digitizer. (wxGui doesn't work yet in
Windows)
OK, getting closer, I think. The reason v.digit wasn't working was
because g.region was set incorrectly. Now I can look at the various
maps
with v.digit and see the different colors of the lines and nodes. In
the
meantime I created a very simple example and processed that map and was
able to get results that I expected. So then I looked at the one that
worked and the one that didn't using v.digit to see what the differences
were.
The files that doesn't have all the areas that I expect has lines that
are
displayed orange (Boundary (1 area)) while the correct version has lines
that are display green (Boundary (2 areas)). Could that be why I'm not
getting all the areas that I expect? All the nodes look correct (no red
ones). How do I fix this? An option in v.clean?
Orange boundaries are duplicates - overlapping lines - that GRASS
topology doesn't allow.
You should be able to get rid of these with:
"v.clean in=... out=... tool=break,bpol,rmdupl"
But I've never had good luck with this.
The alternative that might work better for you:
Re-import the layer from the original shapefiles (or where ever they
came from) but use the "type=line" option to v.in.ogr. (No centroids
will be created)
Now do v.clean on this new GRASS vector, using tool=snap,break,rmdupl.
Next use
"v.type ... type=line,boundary"
to convert the (cleaned) lines to boundaries, and then
"v.centroids ... opt=add"
to create area centroids inside each closed boundary.
Micha,
Yes, thank you, that worked! Here's what I did:
v.in.ogr -o dsn=C:\path\to\shapefile\test_ln.shp output=testm_ln type=line
v.clean input=testm_ln output=testmclean_ln tool=snap,break,rmdupl
thresh=0.2,0,0
v.type input=testmclean_ln output=testmclean_bnd type=line,boundary
v.centroids input=testmclean_bnd output=testmclean_py option=add
Thanks for all the help.
Bryan
--
Micha Silver
Arava Development Co. +972-52-3665918
http://surfaces.co.il
On 09/24/2010 12:45 AM, Bryan Keith wrote:
Orange boundaries are duplicates - overlapping lines - that GRASS
topology doesn't allow.
You should be able to get rid of these with:
"v.clean in=... out=... tool=break,bpol,rmdupl"
But I've never had good luck with this.
The alternative that might work better for you:
Re-import the layer from the original shapefiles (or where ever they
came from) but use the "type=line" option to v.in.ogr. (No centroids
will be created)
Now do v.clean on this new GRASS vector, using tool=snap,break,rmdupl.
Next use
"v.type ... type=line,boundary"
to convert the (cleaned) lines to boundaries, and then
"v.centroids ... opt=add"
to create area centroids inside each closed boundary.
Micha,
Yes, thank you, that worked! Here's what I did:
Cheers.
Although I think I misled you a bit. I was mistaken about the orange line color in the digitizer. It simply indicates a boundary that is wholly shared by two adjacent areas. *Not* a topological error.
In any case, importing polygon shapefiles first as lines (not boundaries), doing the topology cleanup, and then convert to boundaries and add centroids seems to be the smoother way to go.
--
Micha
v.in.ogr -o dsn=C:\path\to\shapefile\test_ln.shp output=testm_ln type=line
v.clean input=testm_ln output=testmclean_ln tool=snap,break,rmdupl
thresh=0.2,0,0
v.type input=testmclean_ln output=testmclean_bnd type=line,boundary
v.centroids input=testmclean_bnd output=testmclean_py option=add
Thanks for all the help.
Bryan
--
Micha Silver
Arava Development Co. +972-52-3665918
http://surfaces.co.il
Micha Silver wrote:
Bryan Keith wrote:
Orange boundaries are duplicates \- overlapping lines \- that GRASS
topology doesn't allow.
You should be able to get rid of these with:
"v.clean in=... out=... tool=break,bpol,rmdupl"
But I've never had good luck with this.
The alternative that might work better for you:
Re-import the layer from the original shapefiles (or where ever they
came from) but use the "type=line" option to v.in.ogr. (No centroids
will be created)
Now do v.clean on this new GRASS vector, using tool=snap,break,rmdupl.
Next use
"v.type ... type=line,boundary"
to convert the (cleaned) lines to boundaries, and then
"v.centroids ... opt=add"
to create area centroids inside each closed boundary.
Micha,
Yes, thank you, that worked! Here's what I did:
Cheers.
Although I think I misled you a bit. I was mistaken about the orange line
color in the digitizer. It simply indicates a boundary that is wholly shared
by two adjacent areas. *Not* a topological error.
In any case, importing polygon shapefiles first as lines (not boundaries),
doing the topology cleanup, and then convert to boundaries and add centroids
seems to be the smoother way to go.
I object because
1. you would need to replicate the cleaning steps done by v.in.ogr
which has, amongst others, a snapping option
2. adding centroids will add centroids to all areas, also those that
where holes in polygons provided by OGR, e.g. a waterbodies shapefile
with lakes and islands in lakes: the islands are not waterbodies and
should not get a centroid
3. you will loose attributes because there is no (easy) way to link
any attributes coming with the shapefile to newly generated centroids,
e.g. land cover/land use shapefiles
Markus M
v.in.ogr -o dsn=C:\path\to\shapefile\test_ln.shp output=testm_ln type=line
v.clean input=testm_ln output=testmclean_ln tool=snap,break,rmdupl
thresh=0.2,0,0
v.type input=testmclean_ln output=testmclean_bnd type=line,boundary
v.centroids input=testmclean_bnd output=testmclean_py option=add
Thanks for all the help.
Bryan
--
Micha Silver
Arava Development Co. +972-52-3665918
http://surfaces.co.il
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Micha Silver wrote:
Bryan Keith wrote:
Orange boundaries are duplicates \- overlapping lines \- that GRASS
topology doesn't allow.
You should be able to get rid of these with:
"v.clean in=... out=... tool=break,bpol,rmdupl"
But I've never had good luck with this.
The alternative that might work better for you:
Re-import the layer from the original shapefiles (or where ever they
came from) but use the "type=line" option to v.in.ogr. (No centroids
will be created)
Now do v.clean on this new GRASS vector, using tool=snap,break,rmdupl.
Next use
"v.type ... type=line,boundary"
to convert the (cleaned) lines to boundaries, and then
"v.centroids ... opt=add"
to create area centroids inside each closed boundary.
Micha,
Yes, thank you, that worked! Here's what I did:
Cheers.
Although I think I misled you a bit. I was mistaken about the orange
line
color in the digitizer. It simply indicates a boundary that is wholly
shared
by two adjacent areas. *Not* a topological error.
In any case, importing polygon shapefiles first as lines (not
boundaries),
doing the topology cleanup, and then convert to boundaries and add
centroids
seems to be the smoother way to go.
I object because
1. you would need to replicate the cleaning steps done by v.in.ogr
which has, amongst others, a snapping option
2. adding centroids will add centroids to all areas, also those that
where holes in polygons provided by OGR, e.g. a waterbodies shapefile
with lakes and islands in lakes: the islands are not waterbodies and
should not get a centroid
3. you will loose attributes because there is no (easy) way to link
any attributes coming with the shapefile to newly generated centroids,
e.g. land cover/land use shapefiles
Markus,
I agree with you regarding #1.
However, in my case I had a line shapefile, not polygons, so #2 and #3 did
not apply. I haven't tried to import a polygon shapefile as areas into
GRASS. Importing as lines and fixing attributes does not seem like the
desired approach.
Bryan
Markus M
v.in.ogr -o dsn=C:\path\to\shapefile\test_ln.shp output=testm_ln
type=line
v.clean input=testm_ln output=testmclean_ln tool=snap,break,rmdupl
thresh=0.2,0,0
v.type input=testmclean_ln output=testmclean_bnd type=line,boundary
v.centroids input=testmclean_bnd output=testmclean_py option=add
Thanks for all the help.
Bryan
--
Micha Silver
Arava Development Co. +972-52-3665918
http://surfaces.co.il
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
On 27/09/2010 20:29, Markus Metz wrote:
Micha Silver wrote:
Cheers.
Although I think I misled you a bit. I was mistaken about the orange line
color in the digitizer. It simply indicates a boundary that is wholly shared
by two adjacent areas. *Not* a topological error.
In any case, importing polygon shapefiles first as lines (not boundaries),
doing the topology cleanup, and then convert to boundaries and add centroids
seems to be the smoother way to go.
I object because
1. you would need to replicate the cleaning steps done by v.in.ogr
which has, amongst others, a snapping option
I never noticed that option.
2. adding centroids will add centroids to all areas, also those that
where holes in polygons provided by OGR, e.g. a waterbodies shapefile
with lakes and islands in lakes: the islands are not waterbodies and
should not get a centroid
I think Bryan's original problem was areas being imported without centroids. But in the general case, I see that importing lines, then converting to boundaries and adding centroids would be wrong.
3. you will loose attributes because there is no (easy) way to link
any attributes coming with the shapefile to newly generated centroids,
e.g. land cover/land use shapefiles
Yes, this was clear.
Markus M
Still, importing unclean shapefile polygons, and correcting the topology is often accompanied by much hair pulling...
Thanks for the clarifications!
--
Micha
Micha Silver:
Markus Metz wrote:
Micha Silver wrote:
In any case, importing polygon shapefiles first as lines (not
boundaries),
doing the topology cleanup, and then convert to boundaries and add
centroids
seems to be the smoother way to go.
I object because
1. you would need to replicate the cleaning steps done by v.in.ogr
which has, amongst others, a snapping option
I never noticed that option.
http://grass.osgeo.org/grass64/manuals/html64_user/v.in.ogr.html
Still, importing unclean shapefile polygons, and correcting the topology is
often accompanied by much hair pulling...
Unfortunately yes. If data providers would only provide clean data...
I have partially good news: v.in.ogr in 6.4.1 and above is faster and
produces cleaner and smaller output. Further on, it shows progress
when cleaning polygons, indicating that something is happening.
Previously (up to 6.4.0), it went silent for quite some time on larger
polygon imports which annoyed me considerably, I want to see that
something is happening.
Markus M
On 28/09/2010 10:00, Markus Metz wrote:
Micha Silver:
Markus Metz wrote:
Micha Silver wrote:
In any case, importing polygon shapefiles first as lines (not
boundaries),
doing the topology cleanup, and then convert to boundaries and add
centroids
seems to be the smoother way to go.
I object because
1. you would need to replicate the cleaning steps done by v.in.ogr
which has, amongst others, a snapping option
I never noticed that option.
http://grass.osgeo.org/grass64/manuals/html64_user/v.in.ogr.html
Still, importing unclean shapefile polygons, and correcting the topology is
often accompanied by much hair pulling...
Unfortunately yes. If data providers would only provide clean data...
I have partially good news: v.in.ogr in 6.4.1 and above is faster and
produces cleaner and smaller output. Further on, it shows progress
when cleaning polygons, indicating that something is happening.
Previously (up to 6.4.0), it went silent for quite some time on larger
polygon imports which annoyed me considerably, I want to see that
something is happening.
Great, I'm looking forward to seeing the improvements.
Markus M
This mail was received via Mail-SeCure System.
--
Micha Silver
http://www.surfaces.co.il/
Arava Development Co. +972-52-3665918
