Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
Hamish wrote: [snip] to the end-user will the upgrade be invisible except that it runs a lot faster now? As I said, v.rast.stats2 is meant to be a replacement for v.rast.stats: yes. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7 scripts overhaul
Glynn Clements wrote: Hamish wrote: It tries to run grass.raster_history() without first testing if the map is in the current mapset. Given that those maps are listed as inputs, it's debatable whether it should be modifying the history even if those maps are in the current mapset. All that i.landsat.rgb does is creating color rules. They are stored in /colr2 if the input maps are not in the current mapset. As r.colors does not modify the raster history, and i.landsat.rgb is just a front-end for r.colors, one could argue that i.landsta.rgb should not touch raster history as well. my2c Markus M In any case, the corresponding fix is: --- scripts/i.landsat.rgb/i.landsat.rgb.py (revision 48120) +++ scripts/i.landsat.rgb/i.landsat.rgb.py (working copy) @@ -124,8 +124,10 @@ set_colors(i, v0, v1) # write cmd history: + mapset = grass.gisenv()['MAPSET'] for i in [red, green, blue]: - grass.raster_history(i) + if grass.find_file(i)['mapset'] == mapset: + grass.raster_history(i) if __name__ == __main__: options, flags = grass.parser() -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7 scripts overhaul
Markus Neteler wrote: Hi, I have tested almost all GRASS 7 scripts and fixed a lot of them (mostly broken in the parser part). To all relevant (most) I have added North Carolina examples for easier testing. This set of modules I did not manage to fix: * db.in.ogr - it does not, as programmed, delete the empty geometry and the cat column fixed * d.rast.leg - messy output, at least in wx0 fixed by Michael Barton * i.in.spotvgt - NameError: global name 'string' is not defined fixed * i.spectral - no more errors but also no output worksforme * r.out.xyz (trying to export to elev_lid792_1m.csv) - File /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/scripts/r.out.xyz, line 42, in main outf = file(output) IOError: [Errno 2] No such file or directory: 'elev_lid792_1m.csv' fixed. BTW, r.out.xyz is nothing more than r.stats -1gn Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #1441: Hard Copy Map Utility (wxPython wrapper for ps.map) text overlay is broken
#1441: Hard Copy Map Utility (wxPython wrapper for ps.map) text overlay is broken ---+ Reporter: cmbarton | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.2 Component: wxGUI | Version: svn-trunk Keywords: hard copy map utility, ps.map |Platform: Unspecified Cpu: Unspecified| ---+ Trying to add text to an output cartography window in the hard copy map utility raises the following error: Traceback (most recent call last): File /Users/Shared/grass_dev/grass70_dev/dist.i386-apple- darwin10.8.0/etc/gui/wxpython/gui_modules/psmap_dialogs.py, line 1677, in OnOK ok = self.OnApply(event) File /Users/Shared/grass_dev/grass70_dev/dist.i386-apple- darwin10.8.0/etc/gui/wxpython/gui_modules/psmap_dialogs.py, line 1670, in OnApply self.parent.DialogDataChanged(id = self.id) File /Users/Shared/grass_dev/grass70_dev/dist.i386-apple- darwin10.8.0/etc/gui/wxpython/gui_modules/psmap.py, line 763, in DialogDataChanged extent = self.getTextExtent(textDict = self.instruction[id].GetInstruction()) File /Users/Shared/grass_dev/grass70_dev/dist.i386-apple- darwin10.8.0/etc/gui/wxpython/gui_modules/psmap.py, line 681, in getTextExtent dc.SetFont(wx.FontFromNativeInfoString(textDict['font'] + + fontsize)) File /Users/Shared/grass_dev/grass70_dev/macosx/dist/GRAS S-7.0.app/Contents/MacOS/etc/python/wx/_gdi.py, line 2309, in FontFromNativeInfoString val = _gdi_.new_FontFromNativeInfoString(*args, **kwargs) wx._core -- Ticket URL: http://trac.osgeo.org/grass/ticket/1441 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] winGRASS: problem with msvcr90.dll
Martin Landa wrote: Hi all, for some days I have problem with building winGRASS. after the last update of my OSGeo4W environment I have problem with compiling GRASS. First it complained about missing mscvr90.dll, then about mscvp90.dll. I have downloaded both files from http://dll-files.com and put them to osgeo4w\bin. Unfortunately it didn't helped a lot, see error message [1]. [1] http://josef.fsv.cvut.cz/~landa/python-error.png More info at [1]. Anyone here with similar experience, some tips? Same problem here, solved by downgrading libtiff through the osgeo4w installer to 4.0.0dev-90 and removing again patched-in msvcr90.dll and msvcp90.dll from osgeo4w\bin. libtiff-bin and libtiff-devel seem to be ok. Looks like a osgeo4w packaging bug... Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #548: grass7 - v.reclass with sqlite driver: Cannot step: SQL logic error or missing database
#548: grass7 - v.reclass with sqlite driver: Cannot step: SQL logic error or missing database --+- Reporter: mlennert | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: Database | Version: svn-trunk Keywords: v.reclass sqlite |Platform: Unspecified Cpu: Unspecified | --+- Comment(by mmetz): Replying to [comment:9 neteler]: Still failing in current GRASS 7 SVN: and the two other branches. It likely affects #1418 (v.dissolve failure) which suppresses error messages from v.reclass. Debugging a bit, the problem of v.reclass with the sqlite driver seems to be that the same database is opened twice (once by each driver instance), which causes database locking, therefore it is not possible to use one driver instance to fetch records from one table and use another driver instance to insert records into another table, all in the same sqlite database. BTW, there is a test in lib/db if a database is already opened when opening a database, this test is called quite often but it never complains. Markus M -- Ticket URL: http://trac.osgeo.org/grass/ticket/548#comment:10 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-user] How to remove nonexistent vector map
Hi, 2011/9/5 Aren Cambre a...@arencambre.com: I am trying to run v.in.ogr against a PostGIS database. The command's output is: ERROR: Vector map pointdata already exists Yet when I run g.remove pointdata, I get: Removing raster pointdata Raster map pointdata not found pointdata nothing removed yes, this can be confusing for the user. I would vote to change this behaviour (also for g.copy, g.rename). GRASS is for many years hybrid GIS with strong vector-based tools. Noted modules in GRASS7 should require option for defining element type, e.g. g.remove pointdata - ERROR: You need define one of options rast, rast3d... What do you think? Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #1158: Removing vector map in Windows fails with Unable to delete vector map
#1158: Removing vector map in Windows fails with Unable to delete vector map --+- Reporter: lponti| Owner: grass-dev@… Type: defect| Status: new Priority: blocker | Milestone: 6.4.2 Component: Vector| Version: 6.4.0 Keywords: wingrass, g.mremove, wildcards, v.in.ogr, v.select, g.remove | Platform: MSWindows 7 Cpu: Unspecified | --+- Comment(by arencambre): #1438 duplicates this. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1158#comment:47 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] #1438: g.remove cannot remove vector map
#1438: g.remove cannot remove vector map --+- Reporter: arencambre | Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: Component: Vector | Version: unspecified Resolution: duplicate|Keywords: Platform: MSWindows 7 | Cpu: Unspecified --+- Changes (by arencambre): * status: new = closed * resolution: = duplicate Comment: Duplicates #1158. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1438#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
Re: [GRASS-dev] GRASS 7 scripts overhaul
Markus Neteler wrote: Hi, I have tested almost all GRASS 7 scripts and fixed a lot of them (mostly broken in the parser part). To all relevant (most) I have added North Carolina examples for easier testing. This set of modules I did not manage to fix: [snip] * v.out.gps -t input=railroads output=trail.gpx [nothing happens...] ^CTraceback (most recent call last): File /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/scripts/m.proj, line 278, in module main() Traceback (most recent call last): File /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/scripts/v.out.gps, line 316, in module main() File /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/scripts/v.out.gps, line 207, in main p2.stdin.write(line) KeyboardInterrupt I think the piping from p1 to p2 is broken because the scripts tries to sneak in between p1.stdout and p2.stdin and p2 is maybe getting confused. Considering that OGR supports writing out gpx or anything gpsbabel supports, v.out.gps tries to do what v.out.ogr can already do? So why not getting rid of v.out.gps? Removing a module for a change would be nice;-) Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] winGRASS: problem with msvcr90.dll
Hi, 2011/9/5 Markus Metz markus.metz.gisw...@googlemail.com: Same problem here, solved by downgrading libtiff through the osgeo4w installer to 4.0.0dev-90 and removing again patched-in msvcr90.dll and msvcp90.dll from osgeo4w\bin. libtiff-bin and libtiff-devel seem to be ok. Looks like a osgeo4w packaging bug... thanks, it helped! Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #1442: GRASS 7: d.grid layout suboptimal
#1442: GRASS 7: d.grid layout suboptimal -+-- Reporter: neteler | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Display | Version: svn-trunk Keywords: |Platform: Linux Cpu: x86-64 | -+-- d.grid latitudes are poorly drawn, seen screenshot. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1442 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] #1442: GRASS 7: d.grid layout suboptimal
#1442: GRASS 7: d.grid layout suboptimal
-+--
Reporter: neteler | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Display | Version: svn-trunk
Keywords: |Platform: Linux
Cpu: x86-64 |
-+--
Description changed by neteler:
Old description:
d.grid latitudes are poorly drawn, seen screenshot.
New description:
d.grid latitudes are poorly drawn, seen screenshot.
{{{
# in latlong
g.region n=90 s=-90 w=-180 e=180
d.mon wx0
d.grid 10
}}}
--
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1442#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] [GRASS GIS] #1443: GRASS 7: d.vect grid drawing problem
#1443: GRASS 7: d.vect grid drawing problem
-+--
Reporter: neteler | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI| Version: svn-trunk
Keywords: |Platform: Linux
Cpu: x86-64 |
-+--
When importing attached SHAPE file of a 10 degree lines grid, the
horizontal lines are not draw. See attachments.
{{{
v.in.ogr worldgrid_10deg.shp out=worldgrid_10deg
g.region n=90 s=-90 w=-180 e=180
d.mon wx0
d.vect myworld_political type=area
d.vect worldgrid_10deg
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1443
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: d.rast.leg formatting improved
On Mon, Sep 5, 2011 at 8:47 AM, Michael Barton michael.bar...@asu.edu wrote: I've done some more work on formatting. It looks better now with a wide range of maps. Let me know what you think. Wow, Michael, great job! Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7 scripts overhaul
On Mon, Sep 5, 2011 at 4:11 PM, Markus Metz markus.metz.gisw...@googlemail.com wrote: * v.out.gps -t input=railroads output=trail.gpx ... Considering that OGR supports writing out gpx or anything gpsbabel supports, v.out.gps tries to do what v.out.ogr can already do? So why not getting rid of v.out.gps? Removing a module for a change would be nice;-) Sounds very good to me. There also also some other leftover (?) shell scripts there. Still open: On Sun, Sep 4, 2011 at 12:20 PM, Markus Neteler nete...@osgeo.org wrote: * r.mask - should show '[Raster MASK present]' as in GRASS 6 in the user prompt In GRASS 6, there was lib/init/prompt.sh for this job. Currently one cannot know from the command line if a MASK is there or not. * GRASS 7.0.svn (latlong_wgs84@neteler):~ v.in.wfs url=http://mapserver.gdf-hannover.de/cgi-bin/grassuserwfs?REQUEST=GetFeatureamp;SERVICE=WFSamp;VERSION=1.0.0; out=grass_users Retrieving data... Importing data... ERROR: Unable to open data source /home/neteler/grassdata/latlong_wgs84/neteler/.tmp/north/18964.0.xml WFS import failed One more: * when leaving GRASS 7 with d.mon wx0 still open, the polling never finishes. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #1439: v.in.ogr error message not useful
#1439: v.in.ogr error message not useful +--- Reporter: arencambre | Owner: grass-dev@… Type: defect | Status: new Priority: major | Milestone: 6.4.2 Component: Vector | Version: 6.4.1 Keywords: |Platform: MSWindows 7 Cpu: x86-64 | +--- Changes (by neteler): * version: unspecified = 6.4.1 * milestone: = 6.4.2 -- Ticket URL: http://trac.osgeo.org/grass/ticket/1439#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: [GRASS GIS] #1437: Recalled command has quotes stripped
#1437: Recalled command has quotes stripped +--- Reporter: arencambre | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.2 Component: wxGUI | Version: 6.4.1 Keywords: |Platform: MSWindows 7 Cpu: x86-64 | +--- Changes (by neteler): * version: unspecified = 6.4.1 * milestone: = 6.4.2 -- Ticket URL: http://trac.osgeo.org/grass/ticket/1437#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: [GRASS GIS] #1435: Quotes are stripped from command display
#1435: Quotes are stripped from command display +--- Reporter: arencambre | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.2 Component: wxGUI | Version: 6.4.1 Keywords: |Platform: MSWindows 7 Cpu: x86-64 | +--- Changes (by neteler): * version: unspecified = 6.4.1 * milestone: = 6.4.2 -- Ticket URL: http://trac.osgeo.org/grass/ticket/1435#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
Re: [GRASS-dev] GRASS 7: d.vect: layer=-1 default conflicts with where option
On Mon, Sep 5, 2011 at 4:04 AM, Glynn Clements gl...@gclements.plus.com wrote:
Markus Neteler wrote:
I found that d.vect fails on commandline
d.vect mylakes where=FTYPE IS NULL type=area col=red
ERROR: Option layer must be 0
d.vect mylakes where=FTYPE IS NULL type=area col=red layer=1
d.vect complete.
The reason is
layer Layer number or name ('-1' for all layers)
I suppose that the logic in the WHERE part needs to be updated.
The error message should be more straightforward, e.g.
Option where requires a layer
Making it support where= with all layers would require a substantial
re-write (and requires that you can come up with a single query which
works for all layers).
Sure but what I meant to say:
d.vect mylakes where=FTYPE IS NULL type=area col=red
... this works in GRASS 6 and fails in GRASS 7 since the default
layer value is unsuitable. IMHO default values should work (as before).
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7 scripts overhaul
Markus Metz wrote: Considering that OGR supports writing out gpx or anything gpsbabel supports, v.out.gps tries to do what v.out.ogr can already do? So why not getting rid of v.out.gps? v.out.ogr can certainly _not_ export to anything that gpsbabel supports. That's the entire point of v.out.gps. GPX is the main overlap and thus why it's used as the in-between format in the script: the script exports as GPX with v.out.ogr internally and then gpsbabel converts from GPX to whatever. http://www.gpsbabel.org/capabilities.html http://gdal.org/ogr/ogr_formats.html In fact v.out.gps roughly doubles the number of vector formats GRASS can export to. Being able to load up your handheld GPSs with wpts/trks/rtes directly from the GIS is a great and useful feature to have. keep it. n.b. If Glynn's python port is working well, there's no reason to keep the old shell script version of it in trunk any more. thanks, Hamish ps- note I still need to port (aka rewrite) the v.in.gpsbabel shell script to v.in.gps (python) in trunk. v.in.garmin can be dropped (it has richer support for older Garmin hardware). https://trac.osgeo.org/grass/changeset/45975 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7: d.vect: layer=-1 default conflicts with where option
Markus Neteler wrote: Making it support where= with all layers would require a substantial re-write (and requires that you can come up with a single query which works for all layers). Sure but what I meant to say: d.vect mylakes where=FTYPE IS NULL type=area col=red ... this works in GRASS 6 ... even if the map has multiple layers. This should be considered a bug in 6.x, IMHO. and fails in GRASS 7 since the default layer value is unsuitable. IMHO default values should work (as before). Is layer 1 *genuinely* special? I.e. is there some reason why it *should* be the default layer? As it stands, the default behaviour of d.vect in 6.x is to display *some* data without any indication that it isn't displaying all of it. I can see an argument for silently selecting layer 1 *if* a map only has one layer, although this is practically asking for people to write scripts which can't be used on maps with more than one layer. If a map has multiple layers, where= is given, and layer= is not given, then an error seem preferable to silently producing incomplete output. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7 scripts overhaul
Markus Metz wrote: I have tested almost all GRASS 7 scripts and fixed a lot of them (mostly broken in the parser part). To all relevant (most) I have added North Carolina examples for easier testing. This set of modules I did not manage to fix: [snip] * v.out.gps -t input=railroads output=trail.gpx [nothing happens...] ^CTraceback (most recent call last): File /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/scripts/m.proj, line 278, in module main() Traceback (most recent call last): File /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/scripts/v.out.gps, line 316, in module main() File /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/scripts/v.out.gps, line 207, in main p2.stdin.write(line) KeyboardInterrupt I think the piping from p1 to p2 is broken because the scripts tries to sneak in between p1.stdout and p2.stdin and p2 is maybe getting confused. It's m.proj which is broken: p = grass.Popen(cmd, stdin = grass.PIPE, stdout = grass.PIPE) cs2cs' stdout is redirected to a pipe, but the script never reads it. It needs: --- scripts/m.proj/m.proj.py(revision 48154) +++ scripts/m.proj/m.proj.py(working copy) @@ -235,7 +235,7 @@ # cs2cs | sed -e 's/d/:/g' -e s/'/:/g -e 's///g' cmd = ['cs2cs'] + copyinp + outfmt + in_proj.split() + ['+to'] + out_proj.split() -p = grass.Popen(cmd, stdin = grass.PIPE, stdout = grass.PIPE) +p = grass.Popen(cmd, stdin = grass.PIPE) while True: line = inf.readline() -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
