Re: [GRASS-dev] G_distance( ) problem in r.slope.aspect?
Try r.in.gdal input=as_dem_30s.bil output=dem_asia_hydrosheds_30s # check extents and range r.info dem_asia_hydrosheds_30s # set the region g.region -p rast=dem_asia_hydrosheds_30s r.colors map=dem_asia_hydrosheds_30s rules=srtm r.slope.aspect elevation=dem_asia_hydrosheds_30s slope=dem_asia_hydrosheds_30s_slope format=percent r.colors map=dem_asia_hydrosheds_30s_slope color=slope # check result r.info dem_asia_hydrosheds_30s_slope Markus M On Sat, Jun 29, 2013 at 7:14 AM, Yann Chemin yche...@gmail.com wrote: Hi, data: --- http://hydrosheds.cr.usgs.gov/datadownload.php?reqdata=30demb script: r.in.bin --overwrite input=/home/yann/RSDATA/hydrosheds/as_dem_30s.bil output=dem_asia_hydrosheds_30s bytes=2 north=59.715 south=-10.0 east=179.5 west=55.0 rows=8400 cols=15000 anull=- r.null map=dem_asia_hydrosheds_30s setnull=55537 r.colors map=dem_asia_hydrosheds_30s rules=srtm r.slope.aspect --overwrite elevation=dem_asia_hydrosheds_30s@PERMANENT slope=dem_asia_hydrosheds_30s_slope format=percent r.colors map=dem_asia_hydrosheds_30s_slope@PERMANENT color=slope complaint: -- WARNING: Unable to read fp range file for dem_asia_hydrosheds_30s_slope@PERMANENT Color table for raster map dem_asia_hydrosheds_30s_slope@PERMANENT set to 'slope' r.info on map: -- . ... Range of data:min = -nan max = -nan ... . -- ___ 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 GIS] #1872: r.in.wms doesn't work on Windows
#1872: r.in.wms doesn't work on Windows -+-- Reporter: martinl | Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: r.in.wms |Platform: MSWindows 2K Cpu: Unspecified | -+-- Comment(by neteler): Is this still the case (I also wonder why a single WMS module can have a critical level)? -- Ticket URL: https://trac.osgeo.org/grass/ticket/1872#comment:2 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 GIS] #1859: d.mon is broken
#1859: d.mon is broken +--- Reporter: huhabla | Owner: grass-dev@… Type: defect | Status: new Priority: critical| Milestone: 7.0.0 Component: Display | Version: svn-trunk Keywords: d.mon, wx0 |Platform: Linux Cpu: x86-64 | +--- Comment(by neteler): For me (Fedora 18) it works. Has the code style in question been updated? -- Ticket URL: https://trac.osgeo.org/grass/ticket/1859#comment:4 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 GIS] #1844: wingrass: db_open_select_cursor fails for DBF driver.
#1844: wingrass: db_open_select_cursor fails for DBF driver. ---+ Reporter: martinl| Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: Database | Version: unspecified Keywords: wingrass, dbf |Platform: MSWindows 2K Cpu: Unspecified| ---+ Comment(by neteler): Still an issue? -- Ticket URL: https://trac.osgeo.org/grass/ticket/1844#comment:6 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 GIS] #1662: Caching bug in 3D raster library with large data
#1662: Caching bug in 3D raster library with large data -+-- Reporter: huhabla | Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: Raster3D | Version: svn-trunk Keywords: 3D raster, tiles, cache |Platform: Linux Cpu: x86-32 | -+-- Comment(by neteler): Could you please provide the etopo_epsg4326 location which includes the temptest map? -- Ticket URL: https://trac.osgeo.org/grass/ticket/1662#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 GIS] #1067: Creating a new Vector Layer for digitize crashes grass with sys.excepthook
#1067: Creating a new Vector Layer for digitize crashes grass with sys.excepthook ---+ Reporter: vesnikos | Owner: grass-dev@… Type: defect| Status: closed Priority: critical | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Resolution: fixed |Keywords: ditizing, vector, GUI Platform: Linux | Cpu: x86-32 ---+ Changes (by neteler): * status: new = closed * resolution: = fixed Comment: This bug is 3 years old, the problem has been fixed since then (tested recently). Closing, feel free to reopen if needed. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1067#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 GIS] #1260: Georectifier: RMS broken
#1260: Georectifier: RMS broken +--- Reporter: q076256 | Owner: grass-dev@… Type: defect | Status: new Priority: blocker | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: wingrass, gcp, georect |Platform: MSWindows 2K Cpu: x86-32 | +--- Comment(by neteler): q076256, could you please try again with a current winGRASS 7 binary package? Available from http://grass.osgeo.org/download/software/ms-windows/ -- Ticket URL: https://trac.osgeo.org/grass/ticket/1260#comment:4 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 GIS] #443: cairo driver: labels are not rendered
#443: cairo driver: labels are not rendered
--+-
Reporter: martinl | Owner: grass-dev@…
Type: defect| Status: new
Priority: critical | Milestone: 7.0.0
Component: Display | Version: 6.4.0 RCs
Keywords: cairo |Platform: All
Cpu: All |
--+-
Comment(by neteler):
Replying to [ticket:443 martinl]:
Cairo driver does not display any labels (PNG driver seems to work).
E.g.
{{{
d.vect map=geodetic_swwake_pts@PERMANENT display=shape,cat
}}}
Probably solved with r56886?
--
Ticket URL: https://trac.osgeo.org/grass/ticket/443#comment:5
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 GIS] #443: cairo driver: labels are not rendered
#443: cairo driver: labels are not rendered ---+ Reporter: martinl | Owner: grass-dev@… Type: defect| Status: closed Priority: critical | Milestone: 7.0.0 Component: Display | Version: 6.4.0 RCs Resolution: fixed |Keywords: cairo Platform: All | Cpu: All ---+ Changes (by hamish): * status: new = closed * resolution: = fixed Comment: if there ever was a bug here, it's fixed now. Hamish wrote: perhaps (attrcol-answer != NULL) should switch on disp=attr if it was not already given?? Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/443#comment:6 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 GIS] #1872: r.in.wms doesn't work on Windows
#1872: r.in.wms doesn't work on Windows -+-- Reporter: martinl | Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: r.in.wms |Platform: MSWindows 2K Cpu: Unspecified | -+-- Comment(by hamish): it is worth re-testing since the script called from within another script winggrass bug was recently fixed. that was for .bat wrappers in grass6 though, so may not apply to trunk. also for locations using a grid file for the datum transform note the bug that there is no way to pass the path to a NTv2 grid filename to cs2cs if the path has a space in it, which can cause m.proj to fail. we should probably submit a quoting patch to proj4 to get that eventually fixed. ... and a reminder that r.in.wms2.py does not run from grass6 addons, still needs more porting work done on it. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1872#comment:3 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 GIS] #1866: broken db driver communication in winGRASS 7
#1866: broken db driver communication in winGRASS 7
--+-
Reporter: martinl | Owner: grass-dev@…
Type: defect| Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass |Platform: MSWindows 2K
Cpu: Unspecified |
--+-
Comment(by neteler):
Replying to [ticket:1866 martinl]:
In winGRASS 7 also SQLite driver is not working (see #1844 from DBF
driver). NC (basic) dataset.
{{{
db.describe census
}}}
doesn't report any error, it just hangs.
I have tried with r56943 on Windows8, still failing:
{{{
GRASS 7.0.svn db.describe overpasses
FEHLER: Kann die Datenbank
$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db nicht öffnen.
GRASS 7.0.svn v.info -c overpasses
Displaying column types/names for database connection of layer 1:
INTEGER|cat
CHARACTER|BRIDGE_NUM
CHARACTER|BSIP_BNUM
CHARACTER|STRUCTYPE
CHARACTER|FTR_INTRSC
CHARACTER|F_CARRIED
CHARACTER|COUNTY
GRASS 7.0.svn
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1866#comment:33
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 GIS] #1844: wingrass: db_open_select_cursor fails for DBF driver.
#1844: wingrass: db_open_select_cursor fails for DBF driver.
---+
Reporter: martinl| Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: wingrass, dbf |Platform: MSWindows 2K
Cpu: Unspecified|
---+
Comment(by neteler):
Replying to [ticket:1844 martinl]:
There is problem with DBF driver on MS Windows. To reproduce this bug
run:
{{{
db.connect driver=dbf database='$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/'
For me (Windows8, version of today, it already hangs here.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1844#comment:7
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 GIS] #1684: configure GRASS 6 with X11 support
#1684: configure GRASS 6 with X11 support +--- Reporter: martinl | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.3 Component: Compiling | Version: svn-releasebranch64 Keywords: configure, X11 |Platform: Linux Cpu: x86-64 | +--- Comment(by hamish): I see the same on debian/wheezy and ubuntu 12.04, no Xmons built. worked around with: LDFLAGS=-L/usr/lib/i386-linux-gnu or --x-includes=/usr/include/X11 --x-libraries=/usr/lib/i386-linux-gnu Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1684#comment:8 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 GIS] #1684: configure GRASS 6 with X11 support
#1684: configure GRASS 6 with X11 support +--- Reporter: martinl | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.3 Component: Compiling | Version: svn-releasebranch64 Keywords: configure, X11 |Platform: Linux Cpu: x86-64 | +--- Comment(by hamish): --x-includes=/foobar --x-libraries=/usr/lib/i386-linux-gnu also works, but leaving off --x-includes= entirely does not. -- Ticket URL: https://trac.osgeo.org/grass/ticket/1684#comment:9 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 GIS] #1997: i.landsat.toar for grass-dev is missing the option for landsat8
#1997: i.landsat.toar for grass-dev is missing the option for landsat8 +--- Reporter: vesnikos| Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Imagery | Version: svn-trunk Keywords: i.landsat.toar |Platform: All Cpu: Unspecified | +--- Comment(by vesnikos): some minor bugs during my tests: 1) Cosmetic typo at the description of sensor parameter: It says Required only if 'metfile' not given (recommended by sanity) should be Required only if 'metfile' not given (recommended for sanity) 2) Band8 (panchomatic) has my nature 15m res. The algorithm uses the regions resolution , and you cannot do anything to override it. 3) timestamp in r.info reads none, the date of acquisition is in the metadata, so it should be properly implemented eg: r.timestamp map=LC81840322013143LGN03_B10.toarr.1 date=$(date -d'$DATE_ACQUIRED $SCENE_CENTER_TIME' -u +'%d %b %Y %H:%M:%S.%N %z') -- Ticket URL: http://trac.osgeo.org/grass/ticket/1997#comment:6 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] r.statistics in G7
Hi, sorry if my question might sound fairly naive, but I miss what's the rationale behind having in GRASS 7 the following modules: r.statistics r.statistics2 r.statistics3 Could't they be grouped into one at a certain stage? Thanks to anyone who'll take the time to answer. -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.statistics in G7
hi, r.statistics r.statistics2 r.statistics3 r.statistics2 is intended to be a partial replacement for r.statistics, with support for floating-point cover maps at the expense of not support quantiles. [1] r.statistics3 is intended to be a partial replacement for r.statistics, with support for floating-point cover maps. It provides quantile calculations, which are absent from r.statistics2. [2] make sense? [1] http://grass.osgeo.org/grass70/manuals/r.statistics2.html [2] http://grass.osgeo.org/grass70/manuals/r.statistics3.html - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/r-statistics-in-G7-tp5063033p5063034.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.volume gives different results from G6 to G7
Hi! simple test with r.volume. Small testing dataset here: http://ubuntuone.com/2Odq6BDeQDdQhIJX2D8sHn On Grass 6.4 r.volume --overwrite data=slope clump=basin centroids=centroid1 CatAverage Data # CellsCentroid Total Number in clump Total in clump Easting Northing Volume 1 2.92229610 78593 635195.00 220715.00 22961000.00 Total Volume =22961000.00 On Grass 7.0 r.volume --overwrite input=slope clump=basin centroids=centroid1 CatAverage Data # CellsCentroid Total Number in clump Total in clump Easting Northing Volume 1-57817810.36-4544075169558 78593 635195.00 220715.00 -454407516955800.00 -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.statistics in G7
Margherita Di Leo wrote: sorry if my question might sound fairly naive, but I miss what's the rationale behind having in GRASS 7 the following modules: r.statistics r.statistics2 r.statistics3 Could't they be grouped into one at a certain stage? r.statistics2 and r.statistics3 are intended to replace r.statistics. But those two modules have almost nothing in common. r.statistics2 calculates statistics which are based upon accumulators (i.e. count, sum of x^n, sum of (x-mean)^n), while r.statistics3 calculates quantiles. If you want a work-alike replacement for r.statistics, it would be simpler to create a script which just runs r.statistics2 and/or r.statistics3 to do the work. In the event that you want both types of statistics, there could be some efficiency gains to be had by merging the two, but only at the cost of creating a module which is noticeably more complex than the sum of its parts. -- 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] r.statistics in G7
Hi Glynn, On Sat, Jun 29, 2013 at 9:48 PM, Glynn Clements gl...@gclements.plus.comwrote: r.statistics2 and r.statistics3 are intended to replace r.statistics. But those two modules have almost nothing in common. r.statistics2 calculates statistics which are based upon accumulators (i.e. count, sum of x^n, sum of (x-mean)^n), while r.statistics3 calculates quantiles. If you want a work-alike replacement for r.statistics, it would be simpler to create a script which just runs r.statistics2 and/or r.statistics3 to do the work. In the event that you want both types of statistics, there could be some efficiency gains to be had by merging the two, but only at the cost of creating a module which is noticeably more complex than the sum of its parts. Thank you for the explanation! I perfectly agree that it's better to keep a couple of modules instead of a very complex one. But from the user's POV their names at the moment are not very informative. If you consider also r.stats... how could the user guess what's the purpose of them all at the first glance? Perhaps names like r.stats.*, where * is the particular function that they perform, would be a bit easier to understand (?) Just my 2 cents cheers madi -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.statistics in G7
Helmut wrote: r.statistics2 is intended to be a partial replacement for r.statistics, with support for floating-point cover maps at the expense of not support quantiles. [1] r.statistics3 is intended to be a partial replacement for r.statistics, with support for floating-point cover maps. It provides quantile calculations, which are absent from r.statistics2. [2] Glynn wrote: r.statistics2 and r.statistics3 are intended to replace r.statistics. But those two modules have almost nothing in common. r.statistics2 calculates statistics which are based upon accumulators (i.e. count, sum of x^n, sum of (x-mean)^n), while r.statistics3 calculates quantiles. If you want a work-alike replacement for r.statistics, it would be simpler to create a script which just runs r.statistics2 and/or r.statistics3 to do the work. In the event that you want both types of statistics, there could be some efficiency gains to be had by merging the two, but only at the cost of creating a module which is noticeably more complex than the sum of its parts. Madi: Thank you for the explanation! I perfectly agree that it's better to keep a couple of modules instead of a very complex one. But from the user's POV their names at the moment are not very informative. If you consider also r.stats... how could the user guess what's the purpose of them all at the first glance? Perhaps names like r.stats.*, where * is the particular function that they perform, would be a bit easier to understand (?) perhaps - r.stats.cover and r.stats.quantile? we should also add r.stats (and perhaps r.univar) into this discussion. r.stats - r.stats.summary ? Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1844: wingrass: db_open_select_cursor fails for DBF driver.
#1844: wingrass: db_open_select_cursor fails for DBF driver. ---+ Reporter: martinl| Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: Database | Version: unspecified Keywords: wingrass, dbf |Platform: MSWindows 2K Cpu: Unspecified| ---+ Comment(by hamish): One oddity, 'db.connect -p' in trunk expands the $GISDBASE/$L/$M to the full pathname, while the VAR file stores it as the variable. As it is possible to hard-code in the VAR file, by auto-expanding there's no way to tell the difference, and if your current mapset will be portable if you rename or copy the mapset, change the drive it's on, etc. -- Testing grass7 nightly snapshot from a few days ago on XP, db.connect works ok, but v.db.addtable, v.db.addcolumn, and other v.db.* from the C:\ grass prompt do nothing, just silently return, even with --help or --ui. echo %errorlevel% comes back as 9009, which translates to Program is not recognized as an internal or external command, operable program or batch file. http://www.febooti.com/products/automation-workshop/online-help/events /run-dos-cmd-command/exit-codes/ other times just an errorlevel of 0. strange. From the wxGUI menu v.db.addtable worked. maybe a sometimes bug - race condition? From the Msys prompt you can get the program to wake up, but only if you add the .py extension. It seemed to lock up on me for the first try, but then ok? (with dbf/ dir re-removed) when I go to exit I get a traceback from grass.py with _subprocess.INFINITE, Terminate batch job (Y/N)? Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1844#comment:8 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 GIS] #1866: broken db driver communication in winGRASS 7
#1866: broken db driver communication in winGRASS 7
--+-
Reporter: martinl | Owner: grass-dev@…
Type: defect| Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass |Platform: MSWindows 2K
Cpu: Unspecified |
--+-
Comment(by hamish):
Replying to [comment:33 neteler]:
I have tried with r56943 on Windows8, still failing:
{{{
GRASS 7.0.svn db.describe overpasses
FEHLER: Kann die Datenbank
$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db nicht
öffnen.
GRASS 7.0.svn v.info -c overpasses
Displaying column types/names for database connection of layer 1:
INTEGER|cat
CHARACTER|BRIDGE_NUM
CHARACTER|BSIP_BNUM
CHARACTER|STRUCTYPE
CHARACTER|FTR_INTRSC
CHARACTER|F_CARRIED
CHARACTER|COUNTY
GRASS 7.0.svn
}}}
is the overpass vector map in the current mapset? You may be seeing the
effect of the db.* modules only working for databases linked from maps in
the current mapset, unless you explicitly set database= to the real path,
not the default which may expand $MAPSET to the current mapset, not the
other mapset's dir name.
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/1866#comment:34
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
