Hi Hamish, 2012/8/29 Hamish <[email protected]>: > 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
