[GRASS-user] v.generalize threshold change in Python does not affect output

Dear GRASS users, I'm trying to simplify a watercourse polygon with v.generalize in a Python script running on a x64 Windows 10 machine. The script points to the GRASS 7.8.3 distribution shipped with QGIS 3.14. Previously in QGIS, the v.generalize tool on the watercourse polygon with 'threshol

Re: [GRASS-user] V.generalize

Best regards Fabrice Dazin [cid:8590fe01-f45d-4f0d-8c6a-8ce2a9867149] De : Markus Neteler Envoyé : mercredi 26 août 2020 16:27 À : DAZIN Fabrice (SIRS) Cc : GRASS user list Objet : Re: [GRASS-user] V.generalize Hi, On Mon, Aug 24, 2020 at 4:35 PM DAZIN Fabrice

Re: [GRASS-user] V.generalize

Hi, On Mon, Aug 24, 2020 at 4:35 PM DAZIN Fabrice (SIRS) wrote: > > > Dear all, > > In the process of transforming a raster classification into a vector layer, I > use among others the command V.GENERALIZE. > > v.generalize input=v_classif_ext@PERMANENT layer=1 type=area type=boundary > method

Re: [GRASS-user] v.generalize and where clause

On 22/04/2019 01:35, Markus Metz wrote: On Sun, Apr 21, 2019 at 11:16 AM Micha Silver wrote: > > > > On 21/04/2019 0:42, Markus Metz wrote: > > > "If

Re: [GRASS-user] v.generalize and where clause

On Sun, Apr 21, 2019 at 11:16 AM Micha Silver wrote: > > > > On 21/04/2019 0:42, Markus Metz wrote: > > > > > Am I missing something? > > Yes, the option layer defaults to -1 = all layers. If you use the cats or where option, you need to specify a layer, otherwise the warning > WARNING: No layer s

Re: [GRASS-user] v.generalize and where clause

On 21/04/2019 0:42, Markus Metz wrote: > > Am I missing something? Yes, the option layer defaults to -1 = all layers. If you use the cats or where option, you need to specify a layer, otherwise the warning WARNING: N

Re: [GRASS-user] v.generalize and where clause

On Sat, Apr 20, 2019 at 8:27 PM Micha Silver wrote: > > Trying to address this SE question: > > > https://gis.stackexchange.com/questions/319319/how-to-apply-smoothing-filter-only-to-way-bigger-than-specified-number-of-nodes > > > I tried to apply v.generalize to a subset of area features, using a

[GRASS-user] v.generalize and where clause

Trying to address this SE question: https://gis.stackexchange.com/questions/319319/how-to-apply-smoothing-filter-only-to-way-bigger-than-specified-number-of-nodes I tried to apply v.generalize to a subset of area features, using a where clause, but it do

Re: [GRASS-user] v.generalize and external boundaries

Hi Markus, Micha, Many thanks for your emails, the combined solution that you suggested worked perfectly. best regards, Daniel. On 25/08/18 11:03, Markus Metz wrote: > > > On Sat, Aug 25, 2018 at 10:56 AM Micha Silver > wrote: > > > > I think I have a series of steps

Re: [GRASS-user] v.generalize and external boundaries

On Sat, Aug 25, 2018 at 10:56 AM Micha Silver wrote: > > I think I have a series of steps that will allow you to separate the "inner" boundaries and generalize only those. The idea is based on using the v.to.db module, with the "sides" option to add the cat number of each area to the left and righ

Re: [GRASS-user] v.generalize and external boundaries

I think I have a series of steps that will allow you to separate the "inner" boundaries and generalize only those. The idea is based on using the v.to.db module, with the "sides" option to add the cat number of each area to the left and right of each boundary. Outer bound

[GRASS-user] v.generalize and external boundaries

Hi List, I'm using v.generalize in a script (excerpt included below) to smooth the boundaries of a polygon vector dataset. In the attached example (input_vector.png), I would like to *only* generalize the internal lines (blue), and leave the external boundary (green line) unchanged. I thought that

Re: [GRASS-user] v.generalize failing on some geoms

On Tue, Feb 13, 2018 at 9:02 AM, Paolo Cavallini wrote: > > Hi Markus, > > Il 12/02/2018 21:46, Markus Metz ha scritto: > > > The original data in EPSG:3003 and EPSG:3857 are not identical. The > > original data in EPSG:3003 are topologically correct, while the original > > data in EPSG:3857 are n

Re: [GRASS-user] v.generalize failing on some geoms

Hi Markus, Il 12/02/2018 21:46, Markus Metz ha scritto: > The original data in EPSG:3003 and EPSG:3857 are not identical. The > original data in EPSG:3003 are topologically correct, while the original > data in EPSG:3857 are not. interesting. so reprojecting creates errors (tiny gaps, in fact).

Re: [GRASS-user] v.generalize failing on some geoms

On Mon, Feb 12, 2018 at 6:22 PM, Paolo Cavallini wrote: > > Il 11/02/2018 18:34, Markus Metz ha scritto: > > > This implies that the data have been reprojected at some stage somewhere > > from one SRS to the other. The most likely explanation for the different > > results, particularly the topolog

Re: [GRASS-user] v.generalize failing on some geoms

Il 11/02/2018 18:34, Markus Metz ha scritto: > This implies that the data have been reprojected at some stage somewhere > from one SRS to the other. The most likely explanation for the different > results, particularly the topological errors reported by v.in.ogr, is > that non-topological polygons

Re: [GRASS-user] v.generalize failing on some geoms

On Sun, Feb 11, 2018 at 11:06 AM, Helmut Kudrnovsky wrote: > > >v.generalize is failing to simplify some of my geometries when in > >EPSG:3857. Same geoms in EPSG:3003 were simplified correctly. > >Incorrect borders were reported, unclear to me why. > > In your first report you're talking about th

Re: [GRASS-user] v.generalize failing on some geoms

>v.generalize is failing to simplify some of my geometries when in >EPSG:3857. Same geoms in EPSG:3003 were simplified correctly. >Incorrect borders were reported, unclear to me why. In your first report you're talking about the same data set in different EPSG defined projections. >I'm not explic

Re: [GRASS-user] v.generalize failing on some geoms

Thanks Markus for the hint. Replies below. Il 10/02/2018 22:53, Markus Metz ha scritto: > This seems to be a reprojection problem. > > If you reprojected the vector data in GRASS with v.in.ogr + v.proj, this > is a problem of GRASS, granted that v.in.ogr did not complain about > vector topology.

Re: [GRASS-user] v.generalize failing on some geoms

Il 09/02/2018 19:25, Markus Neteler ha scritto: > On Fri, Feb 9, 2018 at 6:19 PM, Paolo Cavallini wrote: >> Hi all, >> v.generalize is failing to simplify some of my geometries when in >> EPSG:3857. Same geoms in EPSG:3003 were simplified correctly. >> Incorrect borders were reported, unclear to m

Re: [GRASS-user] v.generalize failing on some geoms

On Fri, Feb 9, 2018 at 6:19 PM, Paolo Cavallini wrote: > > Hi all, > v.generalize is failing to simplify some of my geometries when in > EPSG:3857. Same geoms in EPSG:3003 were simplified correctly. > Incorrect borders were reported, unclear to me why. > All the best, and thanks for any hint. Thi

Re: [GRASS-user] v.generalize failing on some geoms

On Fri, Feb 9, 2018 at 6:19 PM, Paolo Cavallini wrote: > Hi all, > v.generalize is failing to simplify some of my geometries when in > EPSG:3857. Same geoms in EPSG:3003 were simplified correctly. > Incorrect borders were reported, unclear to me why. Please let us know which GRASS GIS version you

[GRASS-user] v.generalize failing on some geoms

Hi all, v.generalize is failing to simplify some of my geometries when in EPSG:3857. Same geoms in EPSG:3003 were simplified correctly. Incorrect borders were reported, unclear to me why. All the best, and thanks for any hint. === Avvio dell'algoritmo v.generalize.simplify - Vector based simplifica

Re: [GRASS-user] v.generalize crash

Il 22/02/2016 21:33, Markus Neteler ha scritto: > Sure - here is our release schedule: > https://trac.osgeo.org/grass/milestone/7.0.4 > > In some weeks we'll have the first RC. Some more known bugs to be > eliminated since then! ok, thanks. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS co

Re: [GRASS-user] v.generalize crash

On Mon, Feb 22, 2016 at 8:23 AM, Paolo Cavallini wrote: > Il 21/02/2016 21:10, Markus Neteler ha scritto: >> On Sat, Feb 20, 2016 at 8:50 AM, Paolo Cavallini >> wrote: >> ... I have opened a ticket: https://trac.osgeo.org/grass/ticket/2929 >> >> It got fixed in 7.0.svn - please try (wi

Re: [GRASS-user] v.generalize crash

Il 21/02/2016 21:10, Markus Neteler ha scritto: > On Sat, Feb 20, 2016 at 8:50 AM, Paolo Cavallini > wrote: > ... >>> I have opened a ticket: >>> https://trac.osgeo.org/grass/ticket/2929 > > It got fixed in 7.0.svn - please try (will go into 7.0.4). Hi Markus, that was fast, thanks. When is 7.0

Re: [GRASS-user] v.generalize crash

On Sat, Feb 20, 2016 at 8:50 AM, Paolo Cavallini wrote: ... >> I have opened a ticket: >> https://trac.osgeo.org/grass/ticket/2929 It got fixed in 7.0.svn - please try (will go into 7.0.4). Markus ___ grass-user mailing list grass-user@lists.osgeo.org

Re: [GRASS-user] v.generalize crash

Thanks Markus. All the best. Il 20 febbraio 2016 08:19:14 CET, Markus Neteler ha scritto: >Hi Paolo, > >On Mon, Feb 15, 2016 at 4:38 PM, Paolo Cavallini > wrote: >> Hi all, >> I get consistent crashes of v.generalize on Debian sid, official deb, >e.g.: >> >> GRASS 7.0.3 (world):~ > v.generalize i

Re: [GRASS-user] v.generalize crash

Hi Paolo, On Mon, Feb 15, 2016 at 4:38 PM, Paolo Cavallini wrote: > Hi all, > I get consistent crashes of v.generalize on Debian sid, official deb, e.g.: > > GRASS 7.0.3 (world):~ > v.generalize input=corine@PERMANENT layer=1 > type=area type=line,boundary,area method=douglas threshold=5.0 > look

[GRASS-user] v.generalize crash

Hi all, I get consistent crashes of v.generalize on Debian sid, official deb, e.g.: GRASS 7.0.3 (world):~ > v.generalize input=corine@PERMANENT layer=1 type=area type=line,boundary,area method=douglas threshold=5.0 look_ahead=7 reduction=50 slide=0.5 angle_thresh=3 degree_thresh=0 closeness_thresh

Re: [GRASS-user] v.generalize: does it take forever?

On Sun, Feb 15, 2015 at 12:45 PM, Fábio Dias wrote: > And most of it was due to changes in code, > that will affect everyone automagically. > If nothing else, this is something people would like to know! (Not everybody is reading grass-user.) Best, Vaclav ___

Re: [GRASS-user] v.generalize: does it take forever?

The numbers I mention in the messages aren't really benchmark material. I didn't do a proper comparison in the end, when things started to really work. And most of it was due to changes in code, that will affect everyone automagically. Most of what was discussed found its way into the docs, with t

Re: [GRASS-user] v.generalize: does it take forever?

On Mon, Feb 9, 2015 at 4:52 PM, Fábio Dias wrote: > I switched to postgis for data storage and the v.generalize time went > down to 130ish minutes, all processes working in parallel. > > I'm happy now :) thanks you guys very much. > Thanks for reporting this back. What about a blog post, or some

Re: [GRASS-user] v.generalize: does it take forever?

I switched to postgis for data storage and the v.generalize time went down to 130ish minutes, all processes working in parallel. I'm happy now :) thanks you guys very much. -=--=-=- Fábio Augusto Salve Dias ICMC - USP http://sites.google.com/site/fabiodias/ On Tue, Jan 27, 2015 at 8:50 PM, Fábio

Re: [GRASS-user] v.generalize: does it take forever?

Hi, I've kept an iotop, cumulative, running while the generalization run. No disk IO involved, just a couple of postgre stats. I believe the OS is keeping everything in RAM cache. I don't believe the disk is a bottleneck either, it is a 10 disk raid of 15k rpm disks, it's really fast. I interrupt

Re: [GRASS-user] v.generalize: does it take forever?

On Mon, Jan 26, 2015 at 3:54 PM, Fábio Dias wrote: > Hi, > > The machine has 128Gb of ram. Doesn't matter what I do, I can't make a > dent on it. Even with everything cached in ram (shp files, database, > the whole lot), there is still free memory. OK, it's not RAM. > > I'm asking about the data

Re: [GRASS-user] v.generalize: does it take forever?

Hi, Running trunk. I was loading the shps into postgis then importing them to grass. Now I'm importing the shps directly. The machine has 128Gb of ram. Doesn't matter what I do, I can't make a dent on it. Even with everything cached in ram (shp files, database, the whole lot), there is still free

Re: [GRASS-user] v.generalize: does it take forever?

On Mon, Jan 26, 2015 at 9:30 AM, Markus Metz wrote: > On Sun, Jan 25, 2015 at 6:11 PM, Fábio Dias wrote: >> Hi, >> >> Running r64249, with a couple of stuff in parallel using &. It seems >> to be considerably slower. > > Very strange. Are you using trunk or GRASS 7.0? Here, v.generalize on a Ter

Re: [GRASS-user] v.generalize: does it take forever?

On Sun, Jan 25, 2015 at 6:11 PM, Fábio Dias wrote: > Hi, > > Running r64249, with a couple of stuff in parallel using &. It seems > to be considerably slower. Very strange. Are you using trunk or GRASS 7.0? > More than 100h, no 1% printed. To be fair, > I'm not entirely sure I'll see it when it

Re: [GRASS-user] v.generalize: does it take forever?

Hi, Running r64249, with a couple of stuff in parallel using &. It seems to be considerably slower. More than 100h, no 1% printed. To be fair, I'm not entirely sure I'll see it when it prints, 10 v.generalize running (5 for each year) + 1 v.in.ogr for 2012. That v.in.ogr is running for almost 100h

Re: [GRASS-user] v.generalize: does it take forever?

On Sun, Jan 11, 2015 at 11:32 PM, Markus Metz wrote: > On Sat, Jan 10, 2015 at 7:23 PM, Fábio Dias wrote: >>> I have optimized the GRASS vector library in trunk r64032 and added >>> another topology check to v.generalize in trunk r64033. The profile of >>> v.generalize now shows that it is limite

Re: [GRASS-user] v.generalize: does it take forever?

On Wed, Jan 14, 2015 at 3:54 PM, Fábio Dias wrote: ... > What would be the best way to do that in parallel? One mapset for each > year? Can I run multiple v.generalizes on the same input with > different outputs? Yes sure. > My first thought was to run completely separated grass processes for >

Re: [GRASS-user] v.generalize: does it take forever?

Hello, Hopefully my last question regarding v.generalize and speeding up the process. Context: I have multiple years of data that need to be generalized. For each year, I need a number of different generalizations (specific number TBD). Question: What would be the best way to do that in parall

Re: [GRASS-user] v.generalize: does it take forever?

On Sat, Jan 10, 2015 at 7:23 PM, Fábio Dias wrote: >> I have optimized the GRASS vector library in trunk r64032 and added >> another topology check to v.generalize in trunk r64033. The profile of >> v.generalize now shows that it is limited by disk I/O speed (on my >> laptop with a standard laptop

Re: [GRASS-user] v.generalize: does it take forever?

> I have optimized the GRASS vector library in trunk r64032 and added > another topology check to v.generalize in trunk r64033. The profile of > v.generalize now shows that it is limited by disk I/O speed (on my > laptop with a standard laptop-like spinning HDD), which means that the > algorithms a

Re: [GRASS-user] v.generalize: does it take forever?

On Sun, Jan 4, 2015 at 10:45 PM, Fábio Dias wrote: > As promised, profile of v.generalize, as of r63952. > (The data might not be exactly the same, I might have run v.clean somewhere). Thanks for your thorough code analysis! My initial guess was wrong, Vect_line_intersection2() is not the limiti

Re: [GRASS-user] v.generalize: does it take forever?

Another info update (and shameless bump) Around 18M primitives and 130M vertices. And I'm left wondering... Has nobody tried to generalize this amount of data yet? Or I'm going about this on the wrong way? I even mounted the grassdata dir as a ramdisk to try to speed up the process, but it is sti

Re: [GRASS-user] v.generalize: does it take forever?

Another interesting update I believed that doing a dissolve before generalizing would speed up the process, because it would remove a lot of edges. The data is very segmented, stitching would be the right term, I suppose. Turns out, that belief is really wrong. The really expensive part of the

Re: [GRASS-user] v.generalize: does it take forever?

Original: GRASS 7.1.svn (brasil):~ > v.info map=tc10 ++ | Name:tc10 | | Mapset: terraclass| | Loc

Re: [GRASS-user] v.generalize: does it take forever?

Just for further reference, the v.dissolve takes around 24h in this dataset. I'll post the v.info of both as soon as it is finished. Any other ideas? I have a fairly powerful server at my disposal, but I'm out of ideas... -=--=-=- Fábio Augusto Salve Dias http://sites.google.com/site/fabiodias/

Re: [GRASS-user] v.generalize: does it take forever?

As promised, profile of v.generalize, as of r63952. (The data might not be exactly the same, I might have run v.clean somewhere). I still have the raw profiles, if anyone wants them. F -=--=-=- Fábio Augusto Salve Dias http://sites.google.com/site/fabiodias/ On Sun, Jan 4, 2015 at 6:01 PM, Fábi

Re: [GRASS-user] v.generalize: does it take forever?

Attached is pdf generated with google-perf of v.generalize, using g7b4. I'm running it again for trunk. -=--=-=- Fábio Augusto Salve Dias http://sites.google.com/site/fabiodias/ On Sun, Jan 4, 2015 at 5:54 PM, Markus Metz wrote: > On Wed, Dec 31, 2014 at 5:20 PM, Fábio Dias wrote: >> >> I fusse

Re: [GRASS-user] v.generalize: does it take forever?

On Wed, Dec 31, 2014 at 5:20 PM, Fábio Dias wrote: > > I fussed about the v.generalize code, thinking about pthread > parallelization. The geometry part of the code is *really* fast and > can be easily parallelized so it can run even faster. But, according > to the profile google-perf gave me, the

Re: [GRASS-user] v.generalize: does it take forever?

On Wed, Dec 31, 2014 at 5:20 PM, Fábio Dias wrote: > On Wed, Dec 31, 2014 at 12:23 PM, Markus Neteler wrote: >> On Sun, Dec 28, 2014 at 8:04 PM, Fábio Dias wrote: >>> Hello all, >>> >>> Context: I've loaded some shp files into postgis, containing >>> information over the amazon forest. For refer

Re: [GRASS-user] v.generalize: does it take forever?

On Wed, Dec 31, 2014 at 12:23 PM, Markus Neteler wrote: > On Sun, Dec 28, 2014 at 8:04 PM, Fábio Dias wrote: >> Hello all, >> >> Context: I've loaded some shp files into postgis, containing >> information over the amazon forest. For reference, the sql script has >> around 6Gb. > > How many polygo

Re: [GRASS-user] v.generalize: does it take forever?

On Sun, Dec 28, 2014 at 8:04 PM, Fábio Dias wrote: > Hello all, > > Context: I've loaded some shp files into postgis, containing > information over the amazon forest. For reference, the sql script has > around 6Gb. How many polygons do you have there approximately? > Problem: I managed do import

[GRASS-user] v.generalize: does it take forever?

Hello all, Context: I've loaded some shp files into postgis, containing information over the amazon forest. For reference, the sql script has around 6Gb. Problem: I managed do import, clean and dissolve properly, but when I run the generalization, by my estimates, it would take almost an year to

Re: [GRASS-user] v.generalize dateline wrap problem

On Mon, Nov 17, 2014 at 3:37 PM, Jed O. Kaplan wrote: > Dear all, > > Further to my question, here is the output of g.version: > > GRASS 7.1.svn (global_lonlat):~ > g.version -g > version=7.1.svn > date=2014 > revision=62762 > build_date=2014-11-17 I can confirm the issue also in G7.0.svn on Linu

Re: [GRASS-user] v.generalize dateline wrap problem

Dear all, Further to my question, here is the output of g.version: GRASS 7.1.svn (global_lonlat):~ > g.version -g version=7.1.svn date=2014 revision=62762 build_date=2014-11-17 build_platform=x86_64-apple-darwin10.8.0 Thanks, Jed On 17 Nov 2014, at 15:34, Markus Neteler wrote: > Hi, > > can

Re: [GRASS-user] v.generalize threshold and boyle's algorithm

Hi Markus, Original-Nachricht > Datum: Tue, 7 Feb 2012 18:00:26 +0100 > Von: Markus Metz > An: Johannes Radinger > CC: grASS user list > Betreff: Re: [GRASS-user] v.generalize threshold and boyle\'s algorithm > Johannes Radinger wrote: > > Hell

Re: [GRASS-user] v.generalize threshold and boyle's algorithm

Johannes Radinger wrote: > Hello, > > after some month a tried an script again which > calls v.generalize. It seems that this module > has changed in version 6.4.2 and 6.5SVN. > > Before I could use following: > grass.run_command("v.generalize", >                      input = input, >              

[GRASS-user] v.generalize threshold and boyle's algorithm

Hello, after some month a tried an script again which calls v.generalize. It seems that this module has changed in version 6.4.2 and 6.5SVN. Before I could use following: grass.run_command("v.generalize", input = input, output = "vector_gen",

Re: [GRASS-user] v.generalize: strange behaviour on win?

On Mon, Jan 30, 2012 at 4:56 PM, Paolo Cavallini wrote: > Il 30/01/2012 16:35, Markus Metz ha scritto: > >> My previous description was obviously incomplete. Output topology is >> always correct, independent of the version. In 6.4.1, topologically > > Thanks Markus, this clarifies the issue a lot.

Re: [GRASS-user] v.generalize: strange behaviour on win?

Il 30/01/2012 16:35, Markus Metz ha scritto: > My previous description was obviously incomplete. Output topology is > always correct, independent of the version. In 6.4.1, topologically Thanks Markus, this clarifies the issue a lot. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Ful

Re: [GRASS-user] v.generalize: strange behaviour on win?

On Sun, Jan 29, 2012 at 1:12 PM, Paolo Cavallini wrote: > Il 28/01/2012 11:58, Markus Metz ha scritto: > >> are left have mixed up attributes. That was fixed such that boundaries >> are not generalized if the generalization would damage topology. For > > > OK, now I see. I think adding a warning i

Re: [GRASS-user] v.generalize: strange behaviour on win?

Il 28/01/2012 11:58, Markus Metz ha scritto: > are left have mixed up attributes. That was fixed such that boundaries > are not generalized if the generalization would damage topology. For OK, now I see. I think adding a warning in these case should be useful. Is this documented in the man? Howe

Re: [GRASS-user] v.generalize: strange behaviour on win?

Il 28/01/2012 11:36, Martin Landa ha scritto: >> type=area ... type=boundary >> >> ...no good! >> > > AFAIK the parser reads this combination as `type=area,boundary` in this case. the results are the same when using ara+boundary or boundary alone. thanks. -- Paolo Cavallini - Faunalia www.fauna

Re: [GRASS-user] v.generalize: strange behaviour on win?

On Sat, Jan 28, 2012 at 9:12 AM, Paolo Cavallini wrote: > Il 27/01/2012 19:24, Markus Metz ha scritto: > >> v.generalize is broken in 6.4.1 > > oh, so it's the different version - I didn't know v.generalize was changed > recently, > thanks for letting me know. strangely enough, in Linux (6.4.1) i

Re: [GRASS-user] v.generalize: strange behaviour on win?

Hi, 2012/1/28 Markus Neteler : >>> v.generalize input=province@Mapset_stefano type=area layer=1 -c >>> type=boundary method=douglas threshold=10 look_ahead=7 > > type=area ... type=boundary > > ...no good! > AFAIK the parser reads this combination as `type=area,boundary` in this case. Martin

Re: [GRASS-user] v.generalize: strange behaviour on win?

On Sat, Jan 28, 2012 at 10:51 AM, Markus Neteler wrote: > On Wed, Jan 25, 2012 at 11:03 AM, Paolo Cavallini > wrote: >> Hi all. >> Commands like: >> I guess I found your problem: >> v.generalize input=province@Mapset_stefano type=area layer=1 -c >> type=boundary method=douglas threshold=10

Re: [GRASS-user] v.generalize: strange behaviour on win?

On Wed, Jan 25, 2012 at 11:03 AM, Paolo Cavallini wrote: > Hi all. > Commands like: > > v.generalize input=province@Mapset_stefano type=area layer=1 -c > type=boundary method=douglas threshold=10 look_ahead=7 > reduction=50 slide=0.5 angle_thresh=3 degree_thresh=0 > closeness_thresh=0 betweene

Re: [GRASS-user] v.generalize: strange behaviour on win?

Il 28/01/2012 10:09, Markus Neteler ha scritto: >> Any explanation? > > Sure: > http://trac.osgeo.org/grass/changeset/46680 > > Maybe your analysis in 6.4.1 worked well but other generalization > methods failed. > Fixed in 6.4.2RC1. Here the "master" fixes: > http://trac.osgeo.org/grass/changese

Re: [GRASS-user] v.generalize: strange behaviour on win?

On Sat, Jan 28, 2012 at 9:12 AM, Paolo Cavallini wrote: > Il 27/01/2012 19:24, Markus Metz ha scritto: > >> v.generalize is broken in 6.4.1 > > oh, so it's the different version - I didn't know v.generalize was changed > recently, > thanks for letting me know. strangely enough, in Linux (6.4.1) i

Re: [GRASS-user] v.generalize: strange behaviour on win?

Il 27/01/2012 19:24, Markus Metz ha scritto: > v.generalize is broken in 6.4.1 oh, so it's the different version - I didn't know v.generalize was changed recently, thanks for letting me know. strangely enough, in Linux (6.4.1) it works well, whereas in Windows (AFAIK 6.4.2RC3) it does not. Any

Re: [GRASS-user] v.generalize: strange behaviour on win?

On Fri, Jan 27, 2012 at 7:01 PM, Paolo Cavallini wrote: > Il 27/01/2012 19:02, Markus Metz ha scritto: > >> same output. That is, if Province_general3 has been generated on >> windows, I do get the same result on Linux, no difference between the >> OS's. Are you using an older grass version on Lin

Re: [GRASS-user] v.generalize: strange behaviour on win?

Il 27/01/2012 19:02, Markus Metz ha scritto: > same output. That is, if Province_general3 has been generated on > windows, I do get the same result on Linux, no difference between the > OS's. Are you using an older grass version on Linux? aptitude show grass Versione: 6.4.1-1 Thanks. -- Paolo C

Re: [GRASS-user] v.generalize: strange behaviour on win?

On Fri, Jan 27, 2012 at 1:32 PM, Paolo Cavallini wrote: > Il 26/01/2012 20:53, Markus Metz ha scritto: > >> You would need to provide the input, not the output as an example. > > https://int.faunalia.it/~paolo/province.zip > >> Considering the detail of the output and the threshold used, it is no

Re: [GRASS-user] v.generalize: strange behaviour on win?

Il 26/01/2012 20:53, Markus Metz ha scritto: > You would need to provide the input, not the output as an example. https://int.faunalia.it/~paolo/province.zip > Considering the detail of the output and the threshold used, it is no > surprise that not all boundaries were generalized because that w

Re: [GRASS-user] v.generalize: strange behaviour on win?

On Wed, Jan 25, 2012 at 11:03 AM, Paolo Cavallini wrote: > Hi all. > Commands like: > > v.generalize input=province@Mapset_stefano type=area layer=1 -c > type=boundary method=douglas threshold=10 look_ahead=7 > reduction=50 slide=0.5 angle_thresh=3 degree_thresh=0 > closeness_thresh=0 betweene

[GRASS-user] v.generalize: strange behaviour on win?

Hi all. Commands like: v.generalize input=province@Mapset_stefano type=area layer=1 -c type=boundary method=douglas threshold=10 look_ahead=7 reduction=50 slide=0.5 angle_thresh=3 degree_thresh=0 closeness_thresh=0 betweeness_thresh=0 alpha=1.0 beta=1.0 iterations=1 output=Province_general3 o

[GRASS-user] v.generalize "snakes" method now uses threshold?

This seems new in 6.4.2, and the included documentation doesn't reflect the addition of this parameter. Is this intended functionality, or some sort of error? Roger ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/li

Re: [GRASS-user] v.generalize issue

Roger André wrote: > Ah, ok.  The causes, please. > It's a really powerful tool, and I would like to write some additional > documentation on how to use it for generalizing and smoothing large polygon > sets, but first I need to make sure that I can anticipate it's behavior a > little better.  The

Re: [GRASS-user] v.generalize issue

Ah, ok. The causes, please. It's a really powerful tool, and I would like to write some additional documentation on how to use it for generalizing and smoothing large polygon sets, but first I need to make sure that I can anticipate it's behavior a little better. The area attribute swapping was

Re: [GRASS-user] v.generalize issue

Roger André wrote: > Hi Markus, > That's good to know.  Can you tell me the bug number?  I'd like to review > the details of it. There is no bug number, at least I could not find a corresponding bug number. There were a few complaints about v.generalize in the mailing lists. In short, you are not

Re: [GRASS-user] v.generalize issue

Hi Markus, That's good to know. Can you tell me the bug number? I'd like to review the details of it. Thanks, Roger -- On Wed, Oct 26, 2011 at 12:23 AM, Markus Metz < markus.metz.gisw...@googlemail.com> wrote: > On Tue, Oct 25, 2011 at 11:07 PM, Roger André wrote: > > Hello GRASS Community,

Re: [GRASS-user] v.generalize issue

On Tue, Oct 25, 2011 at 11:07 PM, Roger André wrote: > Hello GRASS Community, > I'm having a problem that I'm hoping you can help me find the source of. > I think that either A) I am trying to use the v.generalize tool incorrectly, > B) that my data has some sort of topological problem which I'm u

[GRASS-user] v.generalize issue

Hello GRASS Community, I'm having a problem that I'm hoping you can help me find the source of. I think that either A) I am trying to use the v.generalize tool incorrectly, B) that my data has some sort of topological problem which I'm unaware of, or C) that there is a bug in v.generalize. The s

Re: [GRASS-user] v.generalize issues

On Thu, Jun 30, 2011 at 7:49 PM, Christian Guirreri wrote: > I suppose my other question is if anyone has any recommendations concerning > v.generalize as it applies specifically to tiger data - I'm doing all of US. > Lots of settings and tests and its a bit overwhelming for a newbie. > For simpli

Re: [GRASS-user] v.generalize issues

Success! Thanks for making this easy for the total noob that I am. On Thu, Jun 30, 2011 at 11:04 AM, Markus Metz < markus.metz.gisw...@googlemail.com> wrote: > On Thu, Jun 30, 2011 at 4:47 PM, Christian Guirreri > wrote: > > I'm on GRASS 6.4.1. QGIS 1.7.0 > > > In this version, v.generalize is s

Re: [GRASS-user] v.generalize issues

On Thu, Jun 30, 2011 at 4:47 PM, Christian Guirreri wrote: > I'm on GRASS 6.4.1. QGIS 1.7.0 > In this version, v.generalize is still broken. You would need a recent version of GRASS 6.4.2. For Windows, you can get a recent version here: http://wingrass.fsv.cvut.cz/grass64/ Markus M > On Thu, J

Re: [GRASS-user] v.generalize issues

Understood. I actually started to try using some of the GRASS interface via QGIS, but on some of the panels, such as v.generalize, I couldn't type in a tolerance value. I'm on Win7 x64. I'm going to try a fresh install of GRASS. On Thu, Jun 30, 2011 at 10:52 AM, Daniel Lee wrote: > I've exper

Re: [GRASS-user] v.generalize issues

I've experienced problems with calling up vectors stored in the GRASS database with QGIS, sometimes vectors simply are missing. Does the same problem occur in the GRASS environment? Maybe it would help to try showing the vectors in GRASS directly. If that work it means that QGIS is just having a pr

Re: [GRASS-user] v.generalize issues

I'm on GRASS 6.4.1. QGIS 1.7.0 On Thu, Jun 30, 2011 at 10:18 AM, Markus Metz < markus.metz.gisw...@googlemail.com> wrote: > On Thu, Jun 30, 2011 at 4:01 PM, Christian Guirreri > wrote: > > I'm a brand new user to GIS - my goal right now is to heavily simplify > Tiger > > 2010 county and distrct

Re: [GRASS-user] v.generalize issues

On Thu, Jun 30, 2011 at 4:01 PM, Christian Guirreri wrote: > I'm a brand new user to GIS - my goal right now is to heavily simplify Tiger > 2010 county and distrct data, without producing gaps between boundaries. > I've been testing this with v.generalize in grass via QuantumGIS - I've had > tons

[GRASS-user] v.generalize - Boyle's algorithm, literature source

Hello, I just wanted to know if anyone of you knows (original) literature of the Boyle's smoothing algorithm which can be used with v.generalize? /Johannes -- NEU: FreePhone - kostenlos mobil telefonieren! Jetzt informieren: http://www.gmx.net/de/go/freephone

[GRASS-user] v.generalize with where clause

Hi, I'm (slowly ;) getting to grips with GRASS, with the aim of turning the arctic ice maps from http://ice-glaces.ec.gc.ca/ (.e00) into KML. The maps contain vectors for the entire Canadian arctic coastline. Slarty Bartfast would've loved the fiddly bits, but I'd like to smooth out some of this

Re: [GRASS-user] v.generalize crash

Markus Metz ha scritto: > Right. I'll fix it, it should abort with fatal error: Out of memory. Thanks a lot for this. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/lis

Re: [GRASS-user] v.generalize crash

On Wed, May 5, 2010 at 10:49 AM, Paolo Cavallini wrote: > Markus Metz ha scritto: > >> Try another smoothing algorithm, e.g. chaiken. > > Thanks. Yes, Chaiken and Hermite work. However, IMHO it should not crash, > just stop. Right. I'll fix it, it should abort with fatal error: Out of memory. M

Re: [GRASS-user] v.generalize crash

Markus Metz ha scritto: > Try another smoothing algorithm, e.g. chaiken. Thanks. Yes, Chaiken and Hermite work. However, IMHO it should not crash, just stop. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-user mailing list grass

Re: [GRASS-user] v.generalize crash

On Tue, May 4, 2010 at 6:52 PM, Paolo Cavallini wrote: > Nikos Alexandris ha scritto: > >> Does it crash immediately or after a long time? It works for me in a small >> file (boundaries though, not lines) and takes forever (still running after >> 15min in a big file containing contours) but no cra

  1   2   >