[GRASS-dev] Re: [GRASS GIS] #198: v.in.ascii: column scanning is borked
#198: v.in.ascii: column scanning is borked ---+ Reporter: hamish| Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: critical | Milestone: 6.4.0 Component: Vector| Version: svn-develbranch6 Resolution:|Keywords: v.in.ascii Platform: All | Cpu: All ---+ Comment (by mmetz): Try attached patch for the missing values problem. NULL, nan or inf is still not recognized. There is however still a nonsense warning for completely empty columns declared double, but import is successful. Markus M -- Ticket URL: https://trac.osgeo.org/grass/ticket/198#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] Leftover GUI when leaving a GRASS session problem
Hi, we still have the problem of leftover GUI(s) when leaving a GRASS session. I wonder if we could get out more of the eval statement below to kill the GUI process when leaving? --- init.sh snippet --- tcltk | gis.m | oldtcltk | d.m | wxpython) if [ $GRASS_GUI = tcltk ] || \ [ $GRASS_GUI = gis.m ] || \ [ $GRASS_GUI = oldtcltk ] || \ [ $GRASS_GUI = d.m ] ; then # eval `foo` will return subshell return code and not app foo return code!!! eval '$GRASS_WISH -file $TCLTKGRASSBASE/gis_set.tcl' thetest=$? else eval '$GRASS_PYTHON $WXPYTHONGRASSBASE/gis_set.py' thetest=$? fi case $thetest in 1) --- init.sh snippet end --- ? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Leftover GUI when leaving a GRASS session problem
This issue isn't new one and it requires also changes in GUI part. See (uncommited) patches in old RT: http://wald.intevation.org/tracker/index.php?func=detailaid=515group_id=21atid=205 Should I look into those old patches and commit to 6.5? Maris. 2009/8/11, Markus Neteler nete...@osgeo.org: Hi, we still have the problem of leftover GUI(s) when leaving a GRASS session. I wonder if we could get out more of the eval statement below to kill the GUI process when leaving? --- init.sh snippet --- tcltk | gis.m | oldtcltk | d.m | wxpython) if [ $GRASS_GUI = tcltk ] || \ [ $GRASS_GUI = gis.m ] || \ [ $GRASS_GUI = oldtcltk ] || \ [ $GRASS_GUI = d.m ] ; then # eval `foo` will return subshell return code and not app foo return code!!! eval '$GRASS_WISH -file $TCLTKGRASSBASE/gis_set.tcl' thetest=$? else eval '$GRASS_PYTHON $WXPYTHONGRASSBASE/gis_set.py' thetest=$? fi case $thetest in 1) --- init.sh snippet end --- ? Markus ___ 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] Leftover GUI when leaving a GRASS session problem
On Tue, Aug 11, 2009 at 9:31 AM, Maris Nartissmaris@gmail.com wrote: This issue isn't new one and it requires also changes in GUI part. See (uncommited) patches in old RT: http://wald.intevation.org/tracker/index.php?func=detailaid=515group_id=21atid=205 Ah, forgot about that patch. Should I look into those old patches and commit to 6.5? This would be great. Perhaps it can be then recycled later for 7 as well. thanks. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #498: r.sun2 out of sync / broken svn history
#498: r.sun2 out of sync / broken svn history
-+--
Reporter: hamish | Owner: hamish
Type: defect | Status: assigned
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-develbranch6
Resolution: |Keywords: r.sun
Platform: Linux | Cpu: x86-32
-+--
Comment (by hamish):
Replying to [comment:7 hamish]:
Q2) am I using aspin= correctly? should that be a map
created by r.slope.aspect? Using it the processing speeds
up by 3x, but the results seem a bit weird -- to the south
of the mound is a depression in the light which while possible
for reflected light seems that it would be upstream
incorrect for beam_rad.
defining a slopein= map (from r.slope.aspect result) doesn't
change the processing time appreciably. I haven't tested for
its effect on the output map yet.
correction: using aspin=`r.slope.aspect` doesn't speed things up, but
slope+aspect does. Using slopein= causes differences (missing south west
butterfly wing), but slope+aspect makes it really bad.
test script:
{{{
time r.sun -s elevin=gauss day=$DAY beam_rad=rad_test.355.beam.try4
real3m1.750s
user3m1.327s
sys 0m0.400s
#
time r.sun -s elevin=gauss day=$DAY beam_rad=rad_test.355.beamA.try4 \
aspin=guass.aspect
real3m4.432s
user3m4.092s
sys 0m0.364s
#
time r.sun -s elevin=gauss day=$DAY beam_rad=rad_test.355.beamS.try4 \
slopein=guass.slope
real3m7.865s
user3m6.444s
sys 0m0.612s
#
time r.sun -s elevin=gauss day=$DAY beam_rad=rad_test.355.beamAS.try4 \
aspin=guass.aspect slopein=guass.slope
real1m32.279s
user1m31.686s
sys 0m0.240s
#
r.contour in=gauss out=gauss_200m_contours step=200
plot_stuff()
{
MAP=rad_test.355.beam${MAPEXT}.try4
d.rast $MAP
d.vect gauss_200m_contours color=180:180:180
echo $1 | d.text color=black
eval `r.univar -g $MAP`
echo sum: $sum | d.text color=black at=1,5
d.legend $MAP
}
###
d.mon x1
d.resize w=640 h=480
d.split.frame 4
#
d.frame uno
MAPEXT=
plot_stuff Std.
#
d.frame dos
MAPEXT=A
plot_stuff w/Aspect map
#
d.frame tres
MAPEXT=S
plot_stuff w/Slope map
#
d.frame cuatro
MAPEXT=AS
plot_stuff w/Aspect and Slope maps
###
d.frame full_screen
#d.out.file out=rsun_aspslp format=png
}}}
results in the attached image (rsun_aspslp.png).
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/498#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
[GRASS-dev] Re: [GRASS GIS] #498: r.sun2 out of sync / broken svn history
#498: r.sun2 out of sync / broken svn history
-+--
Reporter: hamish | Owner: hamish
Type: defect | Status: assigned
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-develbranch6
Resolution: |Keywords: r.sun
Platform: Linux | Cpu: x86-32
-+--
Comment (by hamish):
Q1) how small must the horizonstep be to recreate the beam_rad
output map effectively as good as e.g. seen in the r.sun wiki
page example?
trials showing differences between no horizon steps; trying to find the
ideal sweet spot compromise between time and quality.
note that none are perfect. Standard r.sun with no horizon inputs is
slightly clipped in lower east wing; the 360x 1 degree horizon map has
slightly uneven width between inner east west bands.
note2 color tables are not constant between maps.
see attached screenshot (rsun_horizons.png)
test script:
{{{
for DEG in 1 15 30 ; do
# can take a while to create all maps
r.horizon elev=gauss horizonstep=$DEG dist=0.7 horizon=horangle$DEG
time r.sun -s elevin=gauss day=$DAY horizon=horangle$DEG \
horizonstep=$DEG beam_rad=rad_test.355.beam.Hz${DEG}deg.try5
done
# r.sun with no horizon seeds
real3m7.571s
user3m7.444s
sys 0m0.060s
# r.sun with 360x 1 deg seeds
# sits quite a while at 0% due to loading sheer number of horizon maps!
real1m20.385s
user1m18.853s
sys 0m1.272s
# r.sun with 24x 15 deg seeds
real0m32.185s
user0m31.774s
sys 0m0.248s
# r.sun with 12x 30 deg seeds
real0m29.518s
user0m29.382s
sys 0m0.120s
#
}}}
{{{
plot_stuff()
{
r.colors $MAP -e color=bcyr
d.rast $MAP
d.vect gauss_200m_contours color=180:180:180
echo $1 | d.text color=black
eval `r.univar -g $MAP`
echo sum: $sum | d.text color=black at=1,5
d.legend $MAP range=1300,1500
}
###
d.mon x2
d.resize w=1024 h=768
d.split.frame 4
#
d.frame uno
MAP=rad_test.355.beam.try5
plot_stuff Std.
#
d.frame dos
MAP=rad_test.355.beam.Hz1deg.try5
plot_stuff w/ 1 degree horizon seeds
#
d.frame tres
MAP=rad_test.355.beam.Hz15deg.try5
plot_stuff w/ 15 degree horizon seeds
#
d.frame cuatro
MAP=rad_test.355.beam.Hz30deg.try5
plot_stuff w/ 30 degree horizon seeds
###
d.frame full_screen
#d.out.file out=rsun_horizons format=png
}}}
next I will try std and 1deg horizons with a r.sun time step of 3 min
instead of 30 minutes. (sun travels ~1deg of sky in 4min)
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/498#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
[GRASS-dev] Possible bug in r.out.gdal?
Dear Devs, i found a strange behavior in r.out.gdal while updating the GRASS test suite. Im using the grass6.4svn snapshot: grass-6.4.svn_src_snapshot_2009_08_01.tar.gz. on openSuse 10.3 Linux 2.6.22.19-0.2-bigsmp gdal version 1.6.1 The test i am implementing tries to export a DCELL raster map (named elevation ) to a DTED file with r.out.gdal. r.out.gdal reports plenty of errors (all of the same type) an exits with return code 0. A dted file is created, but im not sure if it is valid. Exporting the same file with r.out.gdal in ENVI and ELAS formats seems to work correctly. These steps are performed: GRASS 6.4.0svn g.region -p projection: 1 (UTM) zone: 32 datum: wgs84 ellipsoid: wgs84 north: 5582000 south: 558 west: 40 east: 402000 nsres: 20 ewres: 20 rows: 100 cols: 100 cells: 1 GRASS 6.4.0svn r.info elevation ++ | Layer:elevation Date: Sun Apr 30 12:48:58 2006| | Mapset: PERMANENT Login of Creator: soeren | | Location: TestLocation | | DataBase: /1/gebbert/src/GRASS_Testsuite | | Title: ( elevation ) | | Timestamp: none| || | | | Type of Map: raster Number of Categories: 255 | | Data Type: DCELL | | Rows: 100| | Columns: 100| | Total Cells: 1 | |Projection: UTM (zone 32) | |N:5582000S:558 Res: 20 | |E: 402000W: 40 Res: 20 | | Range of data:min = 68.246322 max = 363.529491 | | | | Data Description:| |generated by r.mapcalc | | | | Comments:| |sin(col() * 5) * col() + cos(row() * 5) * row() + 200 | | | ++ GRASS 6.4.0svn r.out.gdal --verbose format=DTED type=Float32 input=elevation output=/tmp/test.dted ERROR 5: Access window out of range in RasterIO(). Requested (0,994) of size 201x1 on raster of 100x100. ERROR 5: Access window out of range in RasterIO(). Requested (0,995) of size 201x1 on raster of 100x100. ERROR 5: Access window out of range in RasterIO(). Requested (0,996) of size 201x1 on raster of 100x100. More than 1000 errors or warnings have been reported. No more will be reported from now. r.out.gdal complete. GRASS 6.4.0svn gdalinfo -nomd -noct -stats /tmp/test.dted Driver: DTED/DTED Elevation Raster Files: /tmp/test.dted /tmp/test.dted.aux.xml Size is 201, 1201 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]] Origin = (399.9975002,559.0004138) Pixel Size = (0.005,-0.0008333) Corner Coordinates: Upper Left ( 399.998, 559.000) (399d59'51.00E,559d 0'1.50N) Lower Left ( 399.998, 558.000) (399d59'51.00E,557d59'58.50N) Upper Right ( 401.002, 559.000) (401d 0'9.00E,559d 0'1.50N) Lower Right ( 401.002, 558.000) (401d 0'9.00E,557d59'58.50N) Center ( 400.500, 558.500) (400d30'0.00E,558d30'0.00N) Band 1 Block=1x1201 Type=Int16, ColorInterp=Palette Min=0.000 Max=0.000 Minimum=0.000, Maximum=0.000, Mean=0.000, StdDev=0.000 NoData Value=-32767 Unit Type: m Color Table (RGB with 365 entries) Any suggestions what i did wrong? Maybe the region settings are incompatible with the dted output coordinate system? Or is this a correct behavior of r.out.gdal? Thanks in advance best regards Soeren ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] New: v.db.droprow
Hi, to be able to easily filter vector maps geometrically (i.e. remove vectors) I have written the v.db.droprow script (G6.5; needs a Python port for GRASS 7). It removes vector objects (point, line, area, face etc.) from a vector map through attribute selection in the table. Example: remove all vector with a certain attribute missing (nice when doing random sampling). cheers Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #498: r.sun2 out of sync / broken svn history
#498: r.sun2 out of sync / broken svn history
-+--
Reporter: hamish | Owner: hamish
Type: defect | Status: assigned
Priority: major | Milestone: 6.4.0
Component: Raster | Version: svn-develbranch6
Resolution: |Keywords: r.sun
Platform: Linux | Cpu: x86-32
-+--
Comment (by hamish):
first four more step sizes to add to previous 1,15,30 deg.
{{{
with 120x 3 deg horizon maps, 'r.sun -s' runs in:
real0m45.418s
user0m44.895s
sys 0m0.464s
with 72x 5 deg horizon maps, 'r.sun -s' runs in:
real0m38.214s
user0m37.822s
sys 0m0.368s
with 45x 8 deg horizon maps, 'r.sun -s' runs in:
real0m34.099s
user0m33.806s
sys 0m0.296s
with 36x 10 deg horizon maps, 'r.sun -s' runs in:
real0m34.072s
user0m33.666s
sys 0m0.244s
}}}
see attached rsun_horizons3_5_8_10.png
interestingly 36x 10 degree horizon maps is seemingly the most consistent.
I wonder if the trick is to match the horizon angle frequency with the
r.sun time step= option?
-
next I will try std and 1deg horizons with a r.sun time step of
3 min instead of 30 minutes. (sun travels ~1deg of sky in 4min)
3 minute setup:
{{{
time r.sun -s elevin=gauss day=$DAY \
beam_rad=rad_test.355.beam.3min_step.try6 step=0.05
real24m34.998s
user24m32.680s
sys 0m2.488s
time r.sun -s elevin=gauss day=$DAY \
beam_rad=rad_test.355.beam.3min_step.Hz1deg.try6 \
step=0.05 horizon=horangle horizonstep=1
real4m45.455s
user4m44.054s
sys 0m1.320s
}}}
plotting setup:
{{{
plot_stuff()
{
r.colors $MAP -e color=bcyr
d.rast $MAP
d.vect gauss_200m_contours color=180:180:180
echo $1 | d.text color=black
eval `r.univar -g $MAP`
echo sum: $sum | d.text color=black at=1,5
d.legend $MAP range=1300,1500
}
###
d.mon x2
d.resize w=1024 h=768
d.split.frame 4
#
d.frame uno
MAP=rad_test.355.beam
plot_stuff dt=30min; no horizon seeds
#
d.frame dos
MAP=rad_test.355.beam.Hz1deg.try5
plot_stuff dt=30min; 1 degree horizon seeds
#
d.frame tres
MAP=rad_test.355.beam.3min_step.try6
plot_stuff dt=3min; no horizon seeds
#
d.frame cuatro
MAP=rad_test.355.beam.3min_step.Hz1deg.try6
plot_stuff dt=3min; 1 degree horizon seeds
###
d.frame full_screen
#d.out.file out=rsun_horizon_dt format=png
}}}
see attached rsun_horizon_dt.png.
hmmm... are the lower lobes for 1 degree r.horizon seeds real?
maybe that 10 degree step size is actually the worst case. Again this is
for the winter solstice so the sun should never get into the NE,NW.
I suspect the standard r.sun @ 3min steps without horizon seeds is in fact
the most accurate result.
I suppose the way to test that is to run r.sun in Mode 1 for a loop
over the day and then run r.series to sum them and see if the pattern
matches. But that's a job for later or someone else, it's the end of the
day here. I'll set it up to run overnight with a 0.0025 timestep (9sec)
no horizon seeds.
hoping this is useful,
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/498#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
Re: [GRASS-dev] Possible bug in r.out.gdal?
Soeren Gebbert wrote: Dear Devs, i found a strange behavior in r.out.gdal while updating the GRASS test suite. Im using the grass6.4svn snapshot: grass-6.4.svn_src_snapshot_2009_08_01.tar.gz. on openSuse 10.3 Linux 2.6.22.19-0.2-bigsmp gdal version 1.6.1 Using grass6.4svn with gdal1.6.0 here Exporting elevation from nc_spm_08 with r.out.gdal input=elevat...@permanent format=DTED type=Float32 output=test.dted gives me Driver DTED does not support direct writing. Using MEM driver for intermediate dataset. Exporting to GDAL data type: Float32 100% Warning 1: The source does not appear to be a properly formatted cell. Warning 1: The source projection coordinate system is PROJCS[Lambert Conformal Conic,GEOGCS[grs80,DATUM[North_American_Datum_1983,SPHEROID[Geodetic_Reference_System_1980,6378137,298.257222101]],PRIMEM[Greenwich,0],UNIT[degree,0.0174532925199433]],PROJECTION[Lambert_Conformal_Conic_2SP],PARAMETER[standard_parallel_1,36.16],PARAMETER[standard_parallel_2,34.34],PARAMETER[latitude_of_origin,33.75],PARAMETER[central_meridian,-79],PARAMETER[false_easting,609601.22],PARAMETER[false_northing,0],UNIT[Meter,1]]. Only WGS 84 is supported. The DTED driver will generate a file as if the source was WGS 84 projection coordinate system. Warning 1: The corner coordinates of the source are not properly aligned on plain latitude/longitude boundaries. Warning 1: The horizontal source size is not conformant with the one expected by DTED Level 1 at this latitude (1500 pixels found instead of 225). r.out.gdal complete. These steps are performed: GRASS 6.4.0svn g.region -p projection: 1 (UTM) At least in gdal1.6.0, only WGS84 is supported for DTED, see warning above. WGS72 is also supported, but the gdal driver issues a warning. GRASS 6.4.0svn r.out.gdal --verbose format=DTED type=Float32 input=elevation output=/tmp/test.dted ERROR 5: Access window out of range in RasterIO(). Requested (0,994) of size 201x1 on raster of 100x100. ERROR 5: Access window out of range in RasterIO(). Requested (0,995) of size 201x1 on raster of 100x100. ERROR 5: Access window out of range in RasterIO(). Requested (0,996) of size 201x1 on raster of 100x100. These messages are generated by gdal, not r.out.gdal. See http://www.gdal.org/frmt_dted.html for more info on the DTED format, particularly the section Creation Issues and the link to the DTED specs: http://www.nga.mil/ast/fm/acq/89020B.pdf If you can confirm that the input data are exactly formatted as Level 0, 1 or 2 cell, it is a problem of r.out.gdal. Also note that for DTED, elevation data is returned as 16 bit signed integer (citation from gdal). hope that helps, Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Possible bug in r.out.gdal?
From the DTED specs: A data file of DTED Level 0, DTED Level 1 or DTED Level 2 is a 1° by 1° cell defined by whole degree latitude and longitude lines on WGS. A DTED file shall not cross whole degree latitude or longitude lines. Matrix intervals for DTED Level 0. ZONE LATITUDE latitude x longitude INTERVAL I 0° - 50° North-South 30 x 30 seconds II 50° - 70° North-South 30 x 60 seconds III 70° - 75° North-South 30 x 90 seconds IV 75° - 80° North-South 30 x 120 seconds V 80° - 90° North-South 30 x 180 seconds Matrix intervals for DTED Level 1. ZONE LATITUDE latitude x longitude INTERVAL I 0° - 50° North-South 3 x 3 seconds II 50° - 70° North-South 3 x 6 seconds III 70° - 75° North-South 3 x 9 seconds IV 75° - 80° North-South 3 x 12 seconds V 80° - 90° North-South 3 x 18 seconds Matrix intervals for DTED Level 2. ZONE LATITUDE latitude x longitude INTERVAL I 0° - 50° North-South 1 x 1 seconds II 50° - 70° North-South 1 x 2 seconds III 70° - 75° North-South 1 x 3 seconds IV 75° - 80° North-South 1 x 4 seconds V 80° - 90° North-South 1 x 6 seconds No idea how strict the gdal driver for DTED is, but it seems that it is very strict and won't work without reprojection, followed by setting region extends and resolution according to the desired DTED level. Markus M Soeren Gebbert wrote: Dear Devs, i found a strange behavior in r.out.gdal while updating the GRASS test suite. Im using the grass6.4svn snapshot: grass-6.4.svn_src_snapshot_2009_08_01.tar.gz. on openSuse 10.3 Linux 2.6.22.19-0.2-bigsmp gdal version 1.6.1 The test i am implementing tries to export a DCELL raster map (named elevation ) to a DTED file with r.out.gdal. r.out.gdal reports plenty of errors (all of the same type) an exits with return code 0. A dted file is created, but im not sure if it is valid. Exporting the same file with r.out.gdal in ENVI and ELAS formats seems to work correctly. These steps are performed: GRASS 6.4.0svn g.region -p projection: 1 (UTM) zone: 32 datum: wgs84 ellipsoid: wgs84 north: 5582000 south: 558 west: 40 east: 402000 nsres: 20 ewres: 20 rows: 100 cols: 100 cells: 1 GRASS 6.4.0svn r.info http://r.info elevation ++ | Layer:elevation Date: Sun Apr 30 12:48:58 2006| | Mapset: PERMANENT Login of Creator: soeren | | Location: TestLocation | | DataBase: /1/gebbert/src/GRASS_Testsuite | | Title: ( elevation ) | | Timestamp: none| || | | | Type of Map: raster Number of Categories: 255 | | Data Type: DCELL | | Rows: 100| | Columns: 100| | Total Cells: 1 | |Projection: UTM (zone 32) | |N:5582000S:558 Res: 20 | |E: 402000W: 40 Res: 20 | | Range of data:min = 68.246322 max = 363.529491 | | | | Data Description:| |generated by r.mapcalc | | | | Comments:| |sin(col() * 5) * col() + cos(row() * 5) * row() + 200 | | | ++ GRASS 6.4.0svn r.out.gdal --verbose format=DTED type=Float32 input=elevation output=/tmp/test.dted ERROR 5: Access window out of range in RasterIO(). Requested (0,994) of size 201x1 on raster of 100x100. ERROR 5: Access window out of range in RasterIO(). Requested (0,995) of size 201x1 on raster of 100x100. ERROR 5: Access window out of range in RasterIO(). Requested (0,996) of size 201x1 on raster of 100x100. More than 1000 errors or warnings have been reported. No more will be reported from now. r.out.gdal complete. GRASS 6.4.0svn gdalinfo -nomd -noct -stats /tmp/test.dted Driver: DTED/DTED Elevation Raster Files: /tmp/test.dted
Re: [GRASS-dev] New: v.db.droprow
On 11/08/09 14:49, Markus Neteler wrote: Hi, to be able to easily filter vector maps geometrically (i.e. remove vectors) I have written the v.db.droprow script (G6.5; needs a Python port for GRASS 7). It removes vector objects (point, line, area, face etc.) from a vector map through attribute selection in the table. Example: remove all vector with a certain attribute missing (nice when doing random sampling). Can't you do that with v.extract ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #718: r.li forgets mask/illegal filename
#718: r.li forgets mask/illegal filename
---+
Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Keywords: |Platform: MacOSX
Cpu: All|
---+
The r.li daemon seems to be forgetting the mask name used for a moving
window operation. In the terminal:
{{{
Illegal filename. Character not allowed.
Illegal filename. Character not allowed.
Illegal filename. Character not allowed.
Unable to open header file for raster map @(null)
CHILD[pid = 1486]: unable to open mask ... continue without!!!
Segmentation fault [64bit only]
... many more illegal filename errors
}}}
It segfaults on OSX 64bit, but not on 32bit OSX, where it still completes
but the output looks OK (but I don't know if it's right).
64bit crash log :
{{{
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x3036
Crashed Thread: 0
Thread 0 Crashed:
0 libSystem.B.dylib 0x7fff840d9d70 strcpy + 48
1 libgrass_rli.dylib 0x00010005d3ed next_Area + 111
2 libgrass_rli.dylib 0x00010005da8a calculateIndex
+ 859
3 r.li.patchdensity 0x0001175c start + 52
}}}
Tests OK on Linux (thanks Markus).
--
Ticket URL: http://trac.osgeo.org/grass/ticket/718
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] New: v.db.droprow
On Tue, Aug 11, 2009 at 5:53 PM, Moritz Lennertmlenn...@club.worldonline.be wrote: On 11/08/09 14:49, Markus Neteler wrote: ... Example: remove all vector with a certain attribute missing (nice when doing random sampling). Can't you do that with v.extract ? It is using v.extract. But IMHO most non-power users won't get the idea to use a reverse extraction to remove vectors via attribute selection... Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New: v.db.droprow
On 11/08/09 19:29, Markus Neteler wrote: On Tue, Aug 11, 2009 at 5:53 PM, Moritz Lennertmlenn...@club.worldonline.be wrote: On 11/08/09 14:49, Markus Neteler wrote: ... Example: remove all vector with a certain attribute missing (nice when doing random sampling). Can't you do that with v.extract ? It is using v.extract. But IMHO most non-power users won't get the idea to use a reverse extraction to remove vectors via attribute selection... Shouldn't this then be better documented ? Just wondering whether multiplying the number of small scripts is really the best way to go... Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New: v.db.droprow
On Tue, Aug 11, 2009 at 8:10 PM, Moritz Lennertmlenn...@club.worldonline.be wrote: On 11/08/09 19:29, Markus Neteler wrote: On Tue, Aug 11, 2009 at 5:53 PM, Moritz Lennert wrote: On 11/08/09 14:49, Markus Neteler wrote: ... Example: remove all vector with a certain attribute missing (nice when doing random sampling). Can't you do that with v.extract ? It is using v.extract. But IMHO most non-power users won't get the idea to use a reverse extraction to remove vectors via attribute selection... Shouldn't this then be better documented ? Please suggest where... (if I/user don't know that I have to use v.extract for this in the first place since I want to *delete*, it needs to be documented elsewhere). Just wondering whether multiplying the number of small scripts is really the best way to go... Well, since we have r.mfilter + r.mfilter.fp or r.colors + r.colors.stddev r.grow + r.grow.distance r.rescale + r.rescale.eq r.surf.idw + r.surf.idw2 r.what + r.what.color ... Luckily the v.* family looks better... With vector objects removal I don't see the problem (while I agree in general). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: About the vector changes
Glynn Clements wrote:
Markus Metz wrote:
[...] An integer literal without a
trailing suffix is an int. Using a larger type to hold the value
where necessary is a gcc extension. Other compilers may simply
truncate the value to an int, even if off_t is 64 bits.
The latest change:
#define OFF_T_TEST 0x0102030405060708LL
will fail to compile with a compiler which doesn't have long long int.
Both the definition and use of OFF_T_TEST need to be conditionalised
with #ifdef HAVE_LONG_LONG_INT.
OK. But on Linux 32 without LFS I get
port_init.c:217: warning: overflow in implicit constant conversion
at compile time because long long int is available but sizeof(off_t) =
4. Portability and its test is ok because OFF_T_TEST is not used in this
case.
Making the conversion explicit would eliminate the warning:
u_o = (off_t) OFF_T_TEST;
OK.
[...]
A 64-bit system might have a 64-bit off_t
but no long long type. We really need to have autoconf use define
SIZEOF_LONG etc in config.h (AC_CHECK_SIZEOF macro), so that we can
use e.g.:
#if SIZEOF_LONG == 8
#define LONG_LONG_TEST 0x0102030405060708L
#elif defined(HAVE_LONG_LONG_INT)
#define LONG_LONG_TEST 0x0102030405060708LL
#endif
You can take it from gdal.
I still see:
719:s[top].sn.branch[j].child.id =
720:(int)s[top].childpos[j];
754:s[top].sn.branch[j].child.id =
755:(int)s[top].childpos[j];
Also:
1011: if (!shcb((int)s[top].sn.branch[i].child, cbarg)) {
A narrowing cast always brings up the question of what if the value
won't fit in the destination type?
Am I missing something, or is childpos[j] *always* an int?
On level 0, it is always an int. It's the ID of the rectangle passed to
int RTreeInsertRect(struct Rect *r, int tid, struct RTree *t)
as tid. That applies to all three cases above.
I am writing out the rectangle ID as off_t although it is int and have
to read it as off_t then cast it to int again when loading the sidx file
to memory for updating. Of course I could also write the ID as int and
read it as int, then there would be no type casting, at the cost of one
more if ... else ... .
If so,
why is it stored in the file as an off_t?
On higher levels (RTree internal nodes), it is the position in file of
the child nodes of a node. For large sidx files, off_t is needed. The
corresponding line in spindex_rw.c is
668 s[top].pos[s[top].branch_id - 1] = nextfreepos;
where I set the node positions in file as off_t.
This is related to the use of union Child: on level 0, int id is used,
on higher levels, struct Node *ptr is used.
So it's a case of simplifying the sidx file I/O?
Yes, partly my laziness. Took me ages to get that particular post-order
traversal right.
That's reasonable enough. But, personally, I would:
1. Make the pos and childpos fields unions (int/off_t).
That's now easy, similar to the union in rtree.
2. Add an explicit range check before casting the off_t read from the
file to an int.
That should only be necessary if there is reason to suspect that the
sidx file is not read properly. Hmm, actually that would be a good check
for exactly that.
An assert() would suffice; the main purpose is to
answer the what if it doesn't fit in an int? question for the
benefit of anyone trying to read that code.
Only works if off_t_size = 8 is both available and used, otherwise it
will obviously always fit into an int.
The answer would be that the programmer wrote bad code with bugs because
it should never happen that it doesn't fit into an int.
Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: About the vector changes
Markus Metz wrote: 2. Add an explicit range check before casting the off_t read from the file to an int. That should only be necessary if there is reason to suspect that the sidx file is not read properly. Hmm, actually that would be a good check for exactly that. More important than validating the file is that, unless you have thoroughly analysed the code which generates the sidx file, it won't be obvious to someone reading the code that the off_t value read from the file will fit into an int. An explicit check would make it clear. Source code is meant to be read by humans as well as by compilers. -- 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] v.in.gshhs v2.0 error reading data
gshhs 2.0 is not yet supported, unfortunately. The latest supported version is 1.6, v.in.gshhs is awaiting updating. Markus M Jamie Adams wrote: I grabbed the 2.0 version of gshhs, released 2009-07-15, but can't import it into GRASS. The module doesn't return much in terms of error information. v.in.gshhs in=gshhs_f.b out=gshhs_f --o Using lat/lon bounds N=90.00 S=-90.00 E=180.00 W=-180.00 ERROR: Error reading data I've tried the various levels of detail (f, h, i, l) with the same result. Based on the readme file there may be some internal changes, but these are beyond me. Any thoughts? - Jamie GSHHS 2.0 - http://www.soest.hawaii.edu/pwessel/gshhs/index.html ___ 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
