Re: [GRASS-user] V.generalize

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 (SIRS

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 >

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

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

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:

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

On Mon, Feb 9, 2015 at 4:52 PM, Fábio Dias fabio.d...@gmail.com 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

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,

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

On Mon, Jan 26, 2015 at 3:54 PM, Fábio Dias fabio.d...@gmail.com 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

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

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

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

On Sun, Jan 25, 2015 at 6:11 PM, Fábio Dias fabio.d...@gmail.com 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

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

On Mon, Jan 26, 2015 at 9:30 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sun, Jan 25, 2015 at 6:11 PM, Fábio Dias fabio.d...@gmail.com 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

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 markus.metz.gisw...@gmail.com wrote: On Sat, Jan 10, 2015 at 7:23 PM, Fábio Dias fabio.d...@gmail.com 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

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

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

On Wed, Jan 14, 2015 at 3:54 PM, Fábio Dias fabio.d...@gmail.com 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

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

On Sat, Jan 10, 2015 at 7:23 PM, Fábio Dias fabio.d...@gmail.com 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

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 are,

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

On Sun, Jan 4, 2015 at 10:45 PM, Fábio Dias fabio.d...@gmail.com 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,

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

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

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

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

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?

On Wed, Dec 31, 2014 at 5:20 PM, Fábio Dias fabio.d...@gmail.com 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

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 markus.metz.gisw...@gmail.com wrote: On Wed, Dec 31, 2014 at 5:20 PM,

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,

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

On Wed, Dec 31, 2014 at 5:20 PM, Fábio Dias fabio.d...@gmail.com wrote: On Wed, Dec 31, 2014 at 12:23 PM, Markus Neteler nete...@osgeo.org wrote: On Sun, Dec 28, 2014 at 8:04 PM, Fábio Dias fabio.d...@gmail.com wrote: Hello all, Context: I've loaded some shp files into postgis, containing

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

On Wed, Dec 31, 2014 at 12:23 PM, Markus Neteler nete...@osgeo.org wrote: On Sun, Dec 28, 2014 at 8:04 PM, Fábio Dias fabio.d...@gmail.com wrote: Hello all, Context: I've loaded some shp files into postgis, containing information over the amazon forest. For reference, the sql script has

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 nete...@osgeo.org

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

On Mon, Nov 17, 2014 at 3:37 PM, Jed O. Kaplan jed.kap...@unil.ch 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

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 markus.metz.gisw...@googlemail.com An: Johannes Radinger jradin...@gmx.at CC: grASS user list grass-user@lists.osgeo.org Betreff: Re: [GRASS-user] v.generalize threshold and boyle\'s

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,                      

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

On Sun, Jan 29, 2012 at 1:12 PM, Paolo Cavallini cavall...@faunalia.it 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

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 Full

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

On Mon, Jan 30, 2012 at 4:56 PM, Paolo Cavallini cavall...@faunalia.it 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

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

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

On Sat, Jan 28, 2012 at 9:12 AM, Paolo Cavallini cavall...@faunalia.it 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

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

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

On Fri, Jan 27, 2012 at 1:32 PM, Paolo Cavallini cavall...@faunalia.it 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

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

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

On Fri, Jan 27, 2012 at 7:01 PM, Paolo Cavallini cavall...@faunalia.it 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

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

On Wed, Jan 25, 2012 at 11:03 AM, Paolo Cavallini cavall...@faunalia.it 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

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é ran...@gmail.com wrote: Hello

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

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

Re: [GRASS-user] v.generalize issues

On Thu, Jun 30, 2011 at 7:49 PM, Christian Guirreri guirr...@gmail.com 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

Re: [GRASS-user] v.generalize issues

On Thu, Jun 30, 2011 at 4:01 PM, Christian Guirreri christ...@guirreri.com 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

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 christ...@guirreri.com wrote: I'm a brand new user to GIS - my goal right now is to heavily simplify Tiger 2010

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

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

Re: [GRASS-user] v.generalize issues

On Thu, Jun 30, 2011 at 4:47 PM, Christian Guirreri christ...@guirreri.com 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/

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 christ...@guirreri.com wrote: I'm on GRASS 6.4.1. QGIS 1.7.0 In this version,

Re: [GRASS-user] v.generalize crash

On Tue, May 4, 2010 at 6:52 PM, Paolo Cavallini cavall...@faunalia.it 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

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

Re: [GRASS-user] v.generalize crash

On Wed, May 5, 2010 at 10:49 AM, Paolo Cavallini cavall...@faunalia.it 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:

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

Re: [GRASS-user] v.generalize for area boundaries?

On Tue, Feb 17, 2009 at 7:35 AM, Hamish hamis...@yahoo.com wrote: Hi, I am following the v.generalize tutorial at http://users.ox.ac.uk/~orie1848/tutorial.html (we should move that to the wiki before it disappears) Here are converters to Mediawiki syntax: http://www.jtidy.de/

Re: [GRASS-user] v.generalize for area boundaries?

On 17.02.2009 08:35, Hamish wrote: Hi, I am following the v.generalize tutorial at http://users.ox.ac.uk/~orie1848/tutorial.html (we should move that to the wiki before it disappears) but it doesn't say much about working with areas beyond removing small ones. That page and the

Re: [GRASS-user] v.generalize for area boundaries?

Hi, Is it possible with grass to replace missing values in a map by surrounding values by a sort of interpolation, knowing that sometimes many missing values are numerous one near another? If yes, how? Thank you very much Stéphanie ___ grass-user

Re: [GRASS-user] v.generalize for area boundaries?

Hi.. please try r.neighbors cheers.. Ivan Il giorno mar, 17/02/2009 alle 18.00 +0100, FAROUX STEPHANIE ha scritto: Hi, Is it possible with grass to replace missing values in a map by surrounding values by a sort of interpolation, knowing that sometimes many missing values are numerous one

Re: [GRASS-user] v.generalize for area boundaries?

On Tue, Feb 17, 2009 at 7:03 PM, ivan marchesini marches...@unipg.it wrote: Hi.. please try r.neighbors r.fillnulls is another option: http://grass.osgeo.org/grass64/manuals/html64_user/r.fillnulls.html Markus cheers.. Ivan Il giorno mar, 17/02/2009 alle 18.00 +0100, FAROUX STEPHANIE ha

Re: [GRASS-user] v.generalize / reanimation of dead lines ?

PROTECTED] Betreff: Re: [GRASS-user] v.generalize / reanimation of dead lines ? On 29.08.2008 18:54, Dylan Beaudette wrote: I have noticed this behavior as well when using v.generalize. I will try and dig up the exact situation that caused it-- but I am pretty sure

Re: [GRASS-user] v.generalize / reanimation of dead lines ?

@lists.osgeo.org, [EMAIL PROTECTED], [EMAIL PROTECTED], Daniel Bundala [EMAIL PROTECTED] Betreff: Re: [GRASS-user] v.generalize / reanimation of dead lines ? On 29.08.2008 18:54, Dylan Beaudette wrote: I have noticed this behavior as well when using v.generalize. I will try and dig up

Re: [GRASS-user] v.generalize / reanimation of dead lines ?

: grass-user@lists.osgeo.org, [EMAIL PROTECTED], [EMAIL PROTECTED], Daniel Bundala [EMAIL PROTECTED] Betreff: Re: [GRASS-user] v.generalize / reanimation of dead lines ? On 29.08.2008 18:54, Dylan Beaudette wrote: I have noticed this behavior as well when using v.generalize. I

Re: [GRASS-user] v.generalize / reanimation of dead lines ?

On Mon, Sep 1, 2008 at 3:55 PM, Markus Metz [EMAIL PROTECTED] wrote: As far as I understand the source code v.generalize discards all centroids and builds them anew at the end, area topology is not maintained during simplification. Dear all, That is correct. The intention was that the

Re: [GRASS-user] v.generalize / reanimation of dead lines ?

On Thursday 28 August 2008, Hamish wrote: Peter: when trying to derive a continous coast_line_ from the GSHHS data set. For this, the data was reduced using v.generalize (douglas, threshold=0.001). Since the reduced coastline consists of several lines (with individual

Re: [GRASS-user] v.generalize / reanimation of dead lines ?

On 29.08.2008 18:54, Dylan Beaudette wrote: I have noticed this behavior as well when using v.generalize. I will try and dig up the exact situation that caused it-- but I am pretty sure that the initial linework was correct = unclean deletion. That is very much possible. This module is

Re: [GRASS-user] v.generalize / reanimation of dead lines ?

Peter, Have you tried to v.build snap the lined before you generalize them? --Wolf On 28.08.2008 19:04, [EMAIL PROTECTED] wrote: Hi, when trying to derive a continous coast_line_ from the GSHHS data set. For this, the data was reduced using v.generalize (douglas, threshold=0.001).

Re: [GRASS-user] v.generalize for polygons?

Hamish, I played around with the map you gave me, and I think I found a way around the problem (though I'm still not very sure about what the real problem is, perhaps too many small areas or too many shorter segments (the boundary seems to be built of a number of smaller lines). I'll try to

Re: [GRASS-user] v.generalize for polygons?

Hi, I am not sure that I understand correcly what you are trying to do, but as far as I remember, the boundaries are generalized as polylines. That is, if the boundary contains some corners, they might be removed which might create the holes. Also, ovesimplified lines are removed by default.

Re: [GRASS-user] v.generalize for polygons?

Hamish: I have a high-res vector area map of regional districts which I wish to generalize. I am having trouble with finding the correct method in v.generalize to use. Currently every thing I try tends to break the area topology and leave only a portion of the now- open boundary. I have