[GRASS-dev] Moving v.pack and v.unpack from addons to trunk

[Sören Gebbert]

Hi Hamish,

2012/8/29 Hamish <hamish_b at yahoo.com>:
> Sören:
>> 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.

I have tried to address this issue by implementing this functions:
http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/core.py#L553
http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/core.py#L617
This functions are used in t.rast.import, t.vect.import, r.unpack and
v.unpack to compare projection parameter.

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.

Best regards
Soeren


> Hamish
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev