What is the current status of v.in.ascii? There had been email exchanges about a bug and need for a fix. If there is a fix what do I need to do to implement it?
Regards,
Tom
--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177
EMAIL: thomas.adams@noaa.gov
VOICE: 937-383-0528
FAX: 937-383-0033
Thomas Adams wrote:
What is the current status of v.in.ascii? There had been email exchanges about a bug and need for a fix. If there is a fix what do I need to do to implement it?
v.in.ascii should work without problems for smaller data sets (by that I mean around 500000 points) and in fact with the latest release it should
work up to about 3 million points. We are now testing how far we can get if we skip the topology building - it seems to be working for larger data sets but becuase every v* command expects the topology to be built (although it may not always be needed for point data) more changes need to be done (or V_build needs to be changed to free the memory as Radim and Hamish indicated - that has not been implemented).
Let me know if you need to work with millions of points, otherwise v.in.ascii should be fine in the new release,
Helena
Regards,
Tom
On 8/10/05, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:
Thomas Adams wrote:
> What is the current status of v.in.ascii? There had been email exchanges
> about a bug and need for a fix. If there is a fix what do I need to do
> to implement it?v.in.ascii should work without problems for smaller data sets (by that I
mean around 500000 points) and in fact with the latest release it should
work up to about 3 million points. We are now testing how far we can get
if we skip the topology building - it seems to be working for larger
data sets but becuase every v* command expects the topology to be built
(although it may not always be needed for point data) more changes need
to be done (or V_build needs to be changed to free the memory as Radim
and Hamish indicated - that has not been implemented).
Please read my previous mails about that, IT IS implemented,
and IT DOES NOT call free() by default because it is faster
and IT CAN free the memory if it is necessary. I wrote that 2-3
times already.
Radim
Let me know if you need to work with millions of points, otherwise
v.in.ascii should be fine in the new release,Helena
>
> Regards,
> Tom
>_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
Radim Blazek wrote:
On 8/10/05, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:
Thomas Adams wrote:
What is the current status of v.in.ascii? There had been email exchanges
about a bug and need for a fix. If there is a fix what do I need to do
to implement it?v.in.ascii should work without problems for smaller data sets (by that I
mean around 500000 points) and in fact with the latest release it should
work up to about 3 million points. We are now testing how far we can get
if we skip the topology building - it seems to be working for larger
data sets but becuase every v* command expects the topology to be built
(although it may not always be needed for point data) more changes need
to be done (or V_build needs to be changed to free the memory as Radim
and Hamish indicated - that has not been implemented).Please read my previous mails about that, IT IS implemented, and IT DOES NOT call free() by default because it is faster
and IT CAN free the memory if it is necessary. I wrote that 2-3
times already.
I meant at the module level, as a user how can I tell v.in.ascii or v.build or any other module that builds topology to free the memory
when needed? From your emails it seemed to me
that this option needs to be added to the relevant modules, but I might have misunderstood it,
Helena
Radim
Let me know if you need to work with millions of points, otherwise
v.in.ascii should be fine in the new release,Helena
Regards,
Tom_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
On 8/16/05, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:
Radim Blazek wrote:
> Please read my previous mails about that, IT IS implemented,
> and IT DOES NOT call free() by default because it is faster
> and IT CAN free the memory if it is necessary. I wrote that 2-3
> times already.I meant at the module level, as a user how can I tell v.in.ascii or
v.build or any other module that builds topology to free the memory
when needed? From your emails it seemed to me
that this option needs to be added to the relevant modules, but I might
have misunderstood it,Helena
Spatial index occupies a lot of memory but it is necessary for
topology building. Also, it takes long time to release the memory
occupied by spatial index (dig_spidx_free) .
The function building topology (Vect_build) is usually called
at the end of module (before Vect_close) so it is faster to call
exit() and operating system releases all the memory much faster.
By default the memory is not released.
It is possible to call Vect_set_release_support() before Vect_close()
to force to release the memory, but it takes long time on large files.
Currently most of the modules do not release spatial index and work
like this:
main
{
Vect_open_new()
//writing new vector
Vect_build()
Vect_close() // memory is not released
}
you can add Vect_set_release_support():
main
{
Vect_open_new()
// writing new vector
Vect_build()
Vect_set_release_support()
Vect_close() // memory is released
}
but it only takes longer time.
It make sense to release spatial index if it is used only at the beginning
of a module or in permanently running programs like QGIS.
For example:
main
{
Vect_open_old()
// select features using spatial index, e.g. Vect_select_lines_by_box()
Vect_set_release_support()
Vect_close() // memory is released
// do some processing which needs memory
}
Radim