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

Fábio Dias fabio.dias at gmail.com
Mon Jan 5 11:49:45 PST 2015


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/


On Sun, Jan 4, 2015 at 7:45 PM, Fábio Dias <fabio.dias at 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).
>
> 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ábio Dias <fabio.dias at gmail.com> wrote:
>> 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.giswork at gmail.com> wrote:
>>> On Wed, Dec 31, 2014 at 5:20 PM, Fábio Dias <fabio.dias at 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 google-perf gave me, the real bottleneck is inside the
>>>> check_topo function (which uses static vars and inserts a new line
>>>> into the vector, not only checks if it breaks topo - got stuck a while
>>>> in there due to the misnomer). More specifically in the Rtree function
>>>> used to check if one line intersects other lines.
>>>>
>>>
>>> The function used in check_topo is Vect_line_intersection() which does
>>> much more than just testing for intersections. The process could be
>>> made much faster if Vect_line_check_intersection() would be modified
>>> such that connections by end points are ignored. But I don't know if
>>> this would break other modules or other functionality.
>>>
>>> Markus M


More information about the grass-user mailing list