Dear all,
I would like to move v.pack and v.unpack from the grass7 addons repo
into grass7 trunk. IMHO the functionality of these modules is really
important to transfer grass vectors from one grass location into an
other without conversion and information loss. The vector export
modules v.pack and v.unpack are quite stable thanks to the great work
of the grass developer Team around Markus Neteler, especially Luca
Delucchi. In addition i have modified the modules to switch the
compression on/off and added a test.
The modules r.pack/r.unpack and v.pack/v.unpack are a core requirement
of the space time raster and vector export/import modules in the
temporal framework.
I would like to move the modules next week if there are no objections
against it.
Dear all,
I would like to move v.pack and v.unpack from the grass7 addons repo
into grass7 trunk. IMHO the functionality of these modules is really
important to transfer grass vectors from one grass location into an
other without conversion and information loss. The vector export
modules v.pack and v.unpack are quite stable thanks to the great work
of the grass developer Team around Markus Neteler, especially Luca
Delucchi. In addition i have modified the modules to switch the
compression on/off and added a test.
The modules r.pack/r.unpack and v.pack/v.unpack are a core requirement
of the space time raster and vector export/import modules in the
temporal framework.
I would like to move the modules next week if there are no objections
against it.
+1, maybe someone could test v.pack v.unpack more? (also in different
OS, I can test only on linux)
The modules r.pack/r.unpack and v.pack/v.unpack are a core requirement
of the space time raster and vector export/import modules in the
temporal framework.
I would like to move the modules next week if there are no objections
against it.
The modules r.pack/r.unpack and v.pack/v.unpack are a core requirement
of the space time raster and vector export/import modules in the
temporal framework.
I would like to move the modules next week if there are no objections
against it.
The modules r.pack/r.unpack and v.pack/v.unpack are a core requirement
of the space time raster and vector export/import modules in the
temporal framework.
no objections, but I wonder if we can come up with a solution so that
moving files around like that is not a core requirement of the temporal
framework?
and as mentioned earlier, trying to compare two SRSs for equality is
really difficult to get right for all cases of expanded datum and
ellipsoid names, floating point precision and %f ascii text representation
issues, default vs specified grid transforms, etc. it's a mine field of
bugs. Not to discourage you from trying, only that a general purpose
open source python library which did that well would make many people
in the osgeo family very happy, and would probably need all of their eyes
and local corner cases to make it robust.
The modules r.pack/r.unpack and v.pack/v.unpack are a core requirement
of the space time raster and vector export/import modules in the
temporal framework.
no objections, but I wonder if we can come up with a solution so that
moving files around like that is not a core requirement of the temporal
framework?
Sorry, but i don't really understand this statement, i guess to my
limited knowledge of the English language.
and as mentioned earlier, trying to compare two SRSs for equality is
really difficult to get right for all cases of expanded datum and
ellipsoid names, floating point precision and %f ascii text representation
issues, default vs specified grid transforms, etc. it's a mine field of
bugs. Not to discourage you from trying, only that a general purpose
open source python library which did that well would make many people
in the osgeo family very happy, and would probably need all of their eyes
and local corner cases to make it robust.
To move the code of v.pack/unpack into trunk was for me a logical
step, since r.pack/unpack is already present and its functionality is
quite unique and IMHO important. So i took the freedom to implement
its use in the temporal import/export modules to allow transfer of
spatio-temporal vector data without information loss between grass
locations.
Dear all,
I would like to move v.pack and v.unpack from the grass7 addons repo
into grass7 trunk. IMHO the functionality of these modules is really
important to transfer grass vectors from one grass location into an
other without conversion and information loss. The vector export
modules v.pack and v.unpack are quite stable thanks to the great work
of the grass developer Team around Markus Neteler, especially Luca
Delucchi. In addition i have modified the modules to switch the
compression on/off and added a test.
The modules r.pack/r.unpack and v.pack/v.unpack are a core requirement
of the space time raster and vector export/import modules in the
temporal framework.
I would like to move the modules next week if there are no objections
against it.
