Re: [GRASS-user] Mixing zone analyses?
I would recommend Cormix (www.cormix.info or www.mixzon.com) but it is not GIS and quite expensive... Nicolas Le 28/01/2019 à 22:10, Rich Shepard a écrit : Has anyone used GRASS to model the mixing zone of an industrial point discharge into a receiving stream or river? If so, please point me to any relevant publications or work flows for doing such an analysis. The 'Application's pages of the web site do not have suggestions, although there is a reference to the Sandia Decision Support System, which might well be incorporated into a mixing zone analysis. Thanks in advance, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.gshhs
Le 20/05/2013 21:18, Nicolas Pérenne a écrit : Hi, Trying to import GSHHG V2.2.2 ( see http://www.soest.hawaii.edu/pwessel/gshhg/ ) through 'v.in.gshhs', I ran into this: GRASS 6.4.2 (wgs84):~/tmp/gshhs_bin v.in.gshhs gshhs_c.b out=gshhs_c Using lat/lon bounds N=90.00 S=-90.00 E=180.00 W=-180.00 ERREUR :Trying to import version 3, only GSHHS versions 4 to 8 (2.0) are supported. which looks strange to me. I am currently doing some 'v.in.ogr' on the Shapefile version of GSHHS, but the process appears to be quite long for the high and full resolution (assuming one wants to import the whole dataset without using '-c'), so I was hoping 'v.in.gshhs' would be quicker... please let me know if this is a known issue, or something I did wrong, etc. Nicolas ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user I assume GSHHG internal version numbers are just not ordered by increasing value... anyway using '-r' to restrict the import of a GSHHG __shapefile__ to the current Grass region works just fine (including the highest GSHHS resolution): sorry for the inconvenience! Nicolas ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.in.gshhs
Hi, Trying to import GSHHG V2.2.2 ( see http://www.soest.hawaii.edu/pwessel/gshhg/ ) through 'v.in.gshhs', I ran into this: GRASS 6.4.2 (wgs84):~/tmp/gshhs_bin v.in.gshhs gshhs_c.b out=gshhs_c Using lat/lon bounds N=90.00 S=-90.00 E=180.00 W=-180.00 ERREUR :Trying to import version 3, only GSHHS versions 4 to 8 (2.0) are supported. which looks strange to me. I am currently doing some 'v.in.ogr' on the Shapefile version of GSHHS, but the process appears to be quite long for the high and full resolution (assuming one wants to import the whole dataset without using '-c'), so I was hoping 'v.in.gshhs' would be quicker... please let me know if this is a known issue, or something I did wrong, etc. Nicolas ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] RE : GRASS 6.4 Windows - How to change current directory
Le 27/03/2013 15:47, BLANDENIER Lucien a écrit : Thank you Nicolas for your answer, I tried the chdir command but it doesn't work. As for the cd command, I dont' receive an error message but I stay in C:\. I use the distribution that is include in the QGis distribution. De : Nicolas Pérenne [nicolas.pere...@free.fr] Date d'envoi : mercredi 27 mars 2013 15:38 À : BLANDENIER Lucien Cc: grass-user [grass-user@lists.osgeo.org] Objet : Re: [GRASS-user] GRASS 6.4 Windows - How to change current directory Le 27/03/2013 15:04, BLANDENIER Lucien a écrit : Hi all, I have some problem to change the current directory on the windows terminal. I used cd : d:\directory but I stay in the same directory... Do someone knows how to do that on windows? Thanks for your help. Lucien ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user if you are using the OSGeo4W distribution, then you might try chdir instead of cd (DOS syntax)... which looks strange to me but it did happen in a test I recently performed Nicolas It won't help in the current case but for potential OSGeo4W users I need to correct myself: the shell in (my installation of) OSGeo4W is ms-dos, not 'bash' (or any other flavor of 'sh'). So it does understand 'cd' (contratry to what I wrote above) although the native command would be more like 'chdir'. Hoverer, to switch to another drive in ms-dos I first type the drive (by itself), e.g. C: D: enter and then I can proceed with 'cd': D: cd grassdata enter Nicolas ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS 6.4 Windows - How to change current directory
Le 27/03/2013 15:04, BLANDENIER Lucien a écrit : Hi all, I have some problem to change the current directory on the windows terminal. I used cd : d:\directory but I stay in the same directory... Do someone knows how to do that on windows? Thanks for your help. Lucien ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user if you are using the OSGeo4W distribution, then you might try chdir instead of cd (DOS syntax)... which looks strange to me but it did happen in a test I recently performed Nicolas ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] PNG output using Cairo: pb. with raster map
Dear GRASS users, This is about generating PNG files with the Cairo driver. I like very much the antialising provided with the Cairo driver but I have an issue here about raster maps rendering. No problem with the PNG driver: export GRASS_TRUECOLOR=true d.mon PNG #begin plot d.rast pfd4 d.vect tch d.vect c20 d.vect c21 d.vect pfd_ctr col=yellow d.vect emissaire cat=3 col=orange width=2 d.vect emissaire cat=1 col=blue width=3 d.vect emissaire cat=2 col=red width=3 #end plot d.mon stop=PNG = 'map.png' ok (with aliased vector maps, especially with default 640x480 resolution). However: d.mon cairo #begin plot (...) # same plot #end plot d.mon stop=cairo = 'map.png' is fine (anti-aliased) but... raster map 'pfd4' is not drawn! Please let me know if this is a known issue with the Cairo driver or if (much more probably) I missed something. My system: Ubuntu 12.04 (LTS) + PPA ubuntugis-unstable (GRASS 6.4.2). Nicolas ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] nviz problem
Hello, Here I have Grass 6.4.2 on Ubuntu 12.04 but fail to launch nviz, even on sample data from the website, e.g.: GRASS 6.4.2 (nc_spm_08):~ nviz elev_ned_30m All I get is the very small window attached to this mail: there is not even a 'visualize' menu... The command line doesn't look so bad though: Chargement de la carte raster elev_ned_30m@PERMANENT... 100% Chargement de la carte raster elev_ned_30m@PERMANENT... 100% Traduction des couleurs à partir de la carte raster elev_ned_30m@PERMANENT... 100% I searched the mail archive... perhaps an issue with my display driver... that's why I have attached also the output of my 'glxinfo' in case somebody can help me with this. Nicolas (*) nicolas@Herminet3:~$ uname -a Linux Herminet3 3.2.0-39-generic #62-Ubuntu SMP Thu Feb 28 00:28:53 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux attachment: pb_nviz.pngname of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: ATI server glx version string: 1.4 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group client glx vendor string: ATI client glx version string: 1.4 client glx extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_swap_control, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_NV_swap_group, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_swap_barrier, GLX_SGIX_swap_group, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, GLX_EXT_framebuffer_sRGB, GLX_ARB_fbconfig_float, GLX_AMD_gpu_association GLX version: 1.4 GLX extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_swap_control, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, GLX_NV_swap_group, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_swap_barrier, GLX_SGIX_swap_group, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap OpenGL vendor string: Advanced Micro Devices, Inc. OpenGL renderer string: ATI Radeon HD 4200 OpenGL version string: 3.3.11627 Compatibility Profile Context OpenGL shading language version string: 3.30 OpenGL extensions: GL_AMDX_debug_output, GL_AMD_conservative_depth, GL_AMD_debug_output, GL_AMD_depth_clamp_separate, GL_AMD_draw_buffers_blend, GL_AMD_name_gen_delete, GL_AMD_performance_monitor, GL_AMD_pinned_memory, GL_AMD_sample_positions, GL_AMD_shader_stencil_export, GL_ARB_ES2_compatibility, GL_ARB_base_instance, GL_ARB_blend_func_extended, GL_ARB_color_buffer_float, GL_ARB_compressed_texture_pixel_storage, GL_ARB_conservative_depth, GL_ARB_copy_buffer, GL_ARB_depth_buffer_float, GL_ARB_depth_clamp, GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_draw_buffers_blend, GL_ARB_draw_elements_base_vertex, GL_ARB_draw_instanced, GL_ARB_explicit_attrib_location, GL_ARB_fragment_coord_conventions, GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader, GL_ARB_framebuffer_object, GL_ARB_framebuffer_sRGB, GL_ARB_geometry_shader4, GL_ARB_get_program_binary, GL_ARB_half_float_pixel, GL_ARB_half_float_vertex, GL_ARB_imaging, GL_ARB_instanced_arrays, GL_ARB_internalformat_query, GL_ARB_map_buffer_alignment, GL_ARB_map_buffer_range, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_occlusion_query2, GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_provoking_vertex, GL_ARB_sampler_objects, GL_ARB_seamless_cube_map, GL_ARB_separate_shader_objects, GL_ARB_shader_bit_encoding, GL_ARB_shader_objects, GL_ARB_shader_precision, GL_ARB_shader_stencil_export, GL_ARB_shader_texture_lod, GL_ARB_shading_language_100, GL_ARB_shading_language_420pack, GL_ARB_shading_language_packing, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_sync, GL_ARB_texture_border_clamp, GL_ARB_texture_buffer_object, GL_ARB_texture_buffer_object_rgb32, GL_ARB_texture_compression, GL_ARB_texture_compression_rgtc, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_float, GL_ARB_texture_mirrored_repeat,
Re: [GRASS-user] nviz problem
Indeed! Many thanks Anna. Feeling rather stupid now to have asked such a question, but I prefer not to imagine how much time I would have spent before having the idea to pull down the corner... thanks again for your quick anwer! Le 19/03/2013 21:18, Anna Kratochvílová a écrit : Hi Nicolas, On Tue, Mar 19, 2013 at 8:50 PM, Nicolas Pérenne nicolas.pere...@free.fr wrote: Hello, Here I have Grass 6.4.2 on Ubuntu 12.04 but fail to launch nviz, even on sample data from the website, e.g.: GRASS 6.4.2 (nc_spm_08):~ nviz elev_ned_30m All I get is the very small window attached to this mail: there is not even a 'visualize' menu... just maximize the window or resize it with mouse like any other window. This works for me (I have also Ubuntu 12.04). Best regards, Anna ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] d.rast.arrows in high quality plot
Hi Niklas, Same for me: the PNG driver draws thinner and thinner arrows when you increase the resolution. If you lower the resolution it's okay though. If you do need such a high resolution (for a poster?), you might try the CAIRO driver (g.manual displaydrivers) which behaves quite differently when producing PNGs. Arrows are drawn with a thicker pen indeed (even at high pixel resolution) but you might be surprised by the raster rendering... and files get very large. Nicolas Le mardi 02 novembre 2010 à 16:12 +0100, Niklas Neckel a écrit : Dear all, I'm trying to plot arrows, representing length proportional to magnitude in a printable high resolution map (with d.rast.arrows). Here is what I tried: #!/bin/sh export GRASS_WIDTH=1 export GRASS_HEIGHT=1 export GRASS_PNGFILE=testpng.png export GRASS_PNG_COMPRESSION=0 #export GRASS_RENDER_IMMEDIATE=TRUE export GRASS_TRUECOLOR=TRUE g.region fig_arrows d.mon start=PNG d.rast map=backgro...@permanent d.rast map=magnitude_...@permanent d.rast.arrow map=direction_...@permanent type=compass arrow_color=black grid_color=none x_color=black unknown_color=red skip=12 scale=20 magnitude_map=magnitude_...@permanent d.mon stop=PNG eog $GRASS_PNGFILE Unfortunately the plotted arrows are quite slim now... is there another solution to achieve this goal? Many thanks, Niklas ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] pb. with netCDF row order
Le lundi 25 octobre 2010 à 19:57 +0200, Nicolas Pérenne a écrit : Thanks for the links. I'll try to provide some useful feekback on the GDAL Trac, issue #2654 looks pretty close to it indeed. Hi again, So I went on to have a look at the GDAL Trac, where I didn't understand everything but realized that the problem appeared to be fixed in version 1.7.2 of GDAL (I was using 1.6.3). The UbuntuGIS software deposit which was hinted at on the GDAL download area: https://launchpad.net/~ubuntugis/+archive/ppa/ proved to be a very convenient way to upgrade (among others) GDAL to version 1.7.2, released 2010/04/23 (many thanks to the UbuntuGIS project). And indeed the upside down effect disappeared, in the very same workflow that I was using before: thanks to the GDAL developpers! Eduardo: if you can manage to get GDAL 1.7.2 on your system, you can drop my script. Nicolas ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] pb. with netCDF row order
Hi Eduardo, I have downloaded your file and indeed as you guessed there is a way to select the time index, and possibly also a level (altitude or depth) index. It goes through optional positional arguments which are not documented (sorry), because one has to guess that 'l' stands for the time index and 'k' for the level one: bash nc2grass.sh -h Usage: nc2grass.sh [-h] nc2grass.sh [-x axis name] [-y axis name] [-z axis name] [-t axis name] [-m missing value] netCDF file variable imin imax jmin jmax [l [k]] -h: help -x: axis name in input file. Default: longitude -y: axis name in input file. Default: latitude -z: axis name in input file. Default: z -t: axis name in input file. Default: time -m: missing value code in output header. Default: -9.99e+02 Actually in your case 'ncdump -h' shows that the missing value flag is 1.e+30f and you can tell GRASS about it using the -m option; my experience is that you have to provide this flag with the very same formatting given to awk in the script, that is +1.00e+30 (check out the default value). To get the first time index in your file: nc2grass.sh -m +1.00e+30 t2m.mean.KNMI.HA2.nc t2m 1 100 1 80 1 \ t2m_l1.txt latN latS lonE lonW: 74.750 35.250 34.750 -14.750 Or you can automate the extraction like this: bash for l in 1 2 3 4; do nc2grass.sh -m +1.00e+30 t2m.mean.KNMI.HA2.nc t2m 1 100 1 80 $l \ t2m_l$l.txt done latN latS lonE lonW: 74.750 35.250 34.750 -14.750 latN latS lonE lonW: 74.750 35.250 34.750 -14.750 latN latS lonE lonW: 74.750 35.250 34.750 -14.750 latN latS lonE lonW: 74.750 35.250 34.750 -14.750 bash ls t2m_l1.txt t2m_l2.txt t2m_l3.txt t2m_l4.txt t2m.mean.KNMI.HA2.nc One potential shortcoming of the script though is that you may provide a time index, or a time index and a level index, but not a level index alone... a fix could be to provide 'k' and 'l' as options instead of positional arguments. Hope it helps. Le mardi 26 octobre 2010 à 12:48 +0200, Eduardo Corbelle Rico a écrit : Nicolas, I've been struggling with the issue of row order in netCDF files and your post came perfect for me. Thank you very much for it. I still have a problem that surely you or anyone in the list would find trivial: the file I'm trying to convert (downloadable in the Prudence project: http://prudence.dmi.dk/data/seasonal/KNMI/t2m.mean.KNMI.HA2.nc.gz ) has four time bands, which I can't write separately into different ascii files. I'm using the script as... ./nc2grass-0001.bin t2m.mean.KNMI.HA2.nc t2m 1 100 1 80 t2m.txt ...and the four time (seasonal) bands came together in the same ascii line. Should I use any additional argument with the script to be able to get four separate ascii files? Thanks a lot! ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] pb. with netCDF row order
Hi,
I am new to GRASS but bought the book (3rd edition) and searched the
mail archive before sending in this question. The issue is about reading
a netCDF file: I got a vertical mirror of upside down effect (when I
display the imported raster using d.rast) but when I use an
old-fashioned technique (translating to GRASS ASCII, see below) it looks
okay.
The netCDF file itself is fine when viewed using, e.g., Ferret
(http://ferret.pmel.noaa.gov/Ferret/). The outputs of ncdump and
gdalinfo are provided at the end of this mail.
The best procedure would be to follow
http://lists.osgeo.org/pipermail/grass-user/2010-September/057799.html
and thus either use r.in.gdal directly:
grassr.in.gdal -o NETCDF:r2.nc:xe out=xe2
(in a WGS84 LOCATION) or after a gdal_translate:
grassgdal_translate -a_srs EPSG:4326 NETCDF:r2.nc:h0 h02.tiff
grassr.in.gdal h02.tiff out=h02
But when I view the resulting raster, h02, it is flipped upside
down (as if the latitude was increasing downward).
Thus so far I need to rely on a script which is actually a follow-up of
this (old) thread:
http://lists.osgeo.org/pipermail/grass-user/2002-December/008022.html
I have attached the script I use to this mail, in case somebody finds it
useful (you also need awk and nco); it is only an ersatz though, and I
would like to know what I can do to import my netCDF file directly into
GRASS (without a temporary GRASS ASCII file).
Are there metadata I should add to the netCDF file to get r.in.gdal
happy? Does r.in.gdal need a particular row order in the netCDF file
(such as j index increasing southward)?
That was a long one!
Hope it was more or less clear.
Nicolas
PS the system I am working with:
bashuname -a
Linux Herminet1 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:48:22 UTC
2010 i686 GNU/Linux
bashgdalinfo --version
GDAL 1.6.3, released 2009/11/19
bashgrass -v
GRASS GIS 6.4.0RC5+39438
#
bash ncdump -h r2.nc
netcdf r2 {
dimensions:
longitude = 133 ;
latitude = 64 ;
time = UNLIMITED ; // (14 currently)
variables:
double longitude(longitude) ;
longitude:units = degrees_east ;
double latitude(latitude) ;
latitude:units = degrees_north ;
double time(time) ;
time:units = seconds since 1900-1-1 ;
float h0(latitude, longitude) ;
h0:units = m ;
h0:missing_value = -999.f ;
float xe(time, latitude, longitude) ;
xe:units = m ;
xe:missing_value = -999.f ;
float u(time, latitude, longitude) ;
u:units = m/s ;
u:missing_value = -999.f ;
float v(time, latitude, longitude) ;
v:units = m/s ;
v:missing_value = -999.f ;
// global attributes:
:Conventions = COARDS ;
}
bash gdalinfo r2.nc
Driver: netCDF/Network Common Data Format
Files: r2.nc
Size is 512, 512
Coordinate System is `'
Metadata:
NC_GLOBAL#Conventions=COARDS
Subdatasets:
SUBDATASET_1_NAME=NETCDF:r2.nc:h0
SUBDATASET_1_DESC=[64x133] h0 (32-bit floating-point)
SUBDATASET_2_NAME=NETCDF:r2.nc:xe
SUBDATASET_2_DESC=[14x64x133] xe (32-bit floating-point)
SUBDATASET_3_NAME=NETCDF:r2.nc:u
SUBDATASET_3_DESC=[14x64x133] u (32-bit floating-point)
SUBDATASET_4_NAME=NETCDF:r2.nc:v
SUBDATASET_4_DESC=[14x64x133] v (32-bit floating-point)
Corner Coordinates:
Upper Left (0.0,0.0)
Lower Left (0.0, 512.0)
Upper Right ( 512.0,0.0)
Lower Right ( 512.0, 512.0)
Center ( 256.0, 256.0)
nc2grass.sh
Description: application/shellscript
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
