Re: sqlite and grass65: was Re: [GRASS-dev] sqlite and grass64
Re. the missing functionality of DBF, would it be feasible for v.db.join to import the DBF table to a temp SQLite file, do the join and export it back to a DBF? Would the same thing be possible for other SQL ops that DBF does not support? For where=SQL module options? It should be possible to ship SQLite with GRASS, shouldn't it -- given it's highly portable and consumes 250K? Plus can be fully embedded w/o conflicting with system-wide installs? I suppose SpatiaLite would be an ideal exchange format for vector maps. Just some thoughts... Cheers, Ben Moritz Lennert wrote: On 06/03/09 01:24, Moskovitz, Bob wrote: Concerning the need to be able to easily backup/share, I think we definitely need some module which isolates and exports a series of chosen maps in a new temporary mapset with a local sqlite db file, copies the chosen maps into this temp mapset and then creates a tarball (or zip or whatever) with the basic LOCATION info (i.e. a PERMANENT mapset with PROJ and WIND files) and the temp mapset. Shouldn't be too hard to wip up, or ? Essentially a v.pack/v.unpack, right? Markus What would be really neat is if there was a way to delete, as well as archive a location from the startup screen. That should actually be much easier. Deleting just implies removing the directory from the file system, archiving just needs a call to create a tar ball or equivalent. So, essentially a small GUI to call one single command. v.pack/v.unpack would be different in that it should deal with individual maps. even though I suggest to include the location info as sort of meta-data, but also to give the possibility to v.unpack into a new, stand-alone location. Don't know if the last is really necessary, though. Just including necessary meta-data concerning the projection system should be enough. Moritz Bob ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Benjamin Ducke Senior Applications Support and Development Officer Oxford Archaeology Janus House Osney Mead OX2 0ES Oxford, U.K. Tel.: ++44 (0)1865 263 800 benjamin.du...@oxfordarch.co.uk -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #430: i.pca's output and history logged Comments disagree
Markus: Patch attached (maybe there is a better way to write it): Eigen values, (vectors), and [percent importance]: PC1 4712.17 (-0.2798,-0.3332,-0.5054,-0.0015,-0.5341,-0.5196) [ 84.0537% ] just cosmetics, but please could it look like: (G_message version) PC1 4712.17 ( -0.2798, -0.3332, -0.5054, -0.0015, -0.5341, -0.5196 ) [ 84.05% ] ie keep percentage as %.2; keep a space between vector components; and (less importantly) keep the space before and after the whole vector component set. the idea is that the increased component prec is needed so you can reconstruct the PCs, but percentage is only informational so it needs less ( you can recalc it from the eigenvalues if you want more). The r.info -h version should have it all align in a nice table so that you can column-wise import it as fixed-width into a speadsheet or box-select the values in a nice text editor that allows that (nedit, wordstar, etc). without the extra whitespace it is a bit too cluttered for my liking. G_message() compacts whitespace so you don't see the nice formatting in the normal output, and is a byproduct so shouldn't be sent to stdout by default. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #532: Vector editing not possible with wx tools
#532: Vector editing not possible with wx tools ---+ Reporter: geognu1| Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: major | Milestone: 6.4.0 Component: wxGUI | Version: 6.4.0 RCs Keywords: vector, digit |Platform: Linux Cpu: x86-32 | ---+ When you start editing a vector with wx interface you get in the command output: Traceback (most recent call last): File /home/user/releasebranch_6_4/dist.i686-pc-linux- gnu/etc/wxpython/gui_modules/wxgui_utils.py, line 512, in OnStartEditing self.mapdisplay.toolbars['vdigit'].StartEditing (maplayer) File /home/user/releasebranch_6_4/dist.i686-pc-linux- gnu/etc/wxpython/gui_modules/toolbars.py, line 1099, in StartEditing self.parent.digit = Digit(mapwindow=self.parent.MapWindow) File /home/user/releasebranch_6_4/dist.i686-pc-linux- gnu/etc/wxpython/gui_modules/vdigit.py, line 685, in __init__ VDigit.__init__(self, mapwindow) File /home/user/releasebranch_6_4/dist.i686-pc-linux- gnu/etc/wxpython/gui_modules/vdigit.py, line 223, in __init__ mapwindow) File /home/user/releasebranch_6_4/dist.i686-pc-linux- gnu/etc/wxpython/vdigit/grass6_wxvdigit.py, line 327, in __init__ this = _grass6_wxvdigit.new_Digit(*args) TypeError : in method 'new_Digit', argument 2 of type 'wxWindow *' The monitor gets erased and editing it is not possible -- Ticket URL: http://trac.osgeo.org/grass/ticket/532 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #532: Vector editing not possible with wx tools
#532: Vector editing not possible with wx tools --+- Reporter: geognu1 | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: major| Milestone: 6.4.0 Component: wxGUI| Version: 6.4.0 RCs Resolution: |Keywords: vector, digit Platform: Linux| Cpu: x86-32 --+- Comment (by martinl): Which version of swig do you use? -- Ticket URL: http://trac.osgeo.org/grass/ticket/532#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: v.in.gshhs - bogus horizontal lines
Markus Metz pisze: Maciej Sieczka wrote: Thanks for your v.in.gshhs GRASS 6 port. I have a problem: when importing full GSHHS extent, strange horizontal lines through the whole longitudal extent are present in the output GRASS vector map, which are *visible only in v.digit or QGIS*, but never on the regular wxGUI map display or X monitors. To reproduce please import e.g. gshhs_c.b, zoom to it in wxGUI, then open in digitizer and compare. Also please notice that *in QGIS those bogus lines are always visible*. I suppose this is related to the GSSHS data extent 0 - 360 vs. GRASS -180 - 180. Strange. v.in.gshhs converts all lon coordinates to the range of -180 - 180. The only possible problem is Eurasiafrica (also converted to -180 - 180), crossing the datum border, all other shorelines are not crossing the datum border. I wrote the new v.in.gshhs port so that it displays properly, but GRASS latlon handling is not fully consistent, e.g. bounding boxes in vector topology ignore the datum border problems whereas (most?) lib/gis functions take care of that. My guess is that neither the wxGUI vdigit nor QGIS do this on-the-fly wraparound like the GRASS display. No idea how to solve this. Glynn once remarked that he tried to support -360 - 360 in latlon, and said that this opens a problem box of Pandora. I tried myself, and found the same problem box :-( I personally like the way QGIS or MapServer handles it - they just don't care and don't try to treat lat-long data as connected at the datum border. This has the major plus that in those applications there is no problem with manual browsing/editing world-wide lat-long data. One can pan and zoom just like in any other coordinate system and the display coordinate extent is not restricted. GRASS automatic wrapparound is a feature that brings more troubles than benefits to developers and users IMHO. Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
