Re: [GRASS-user] log function for SQLite

NikosAlexandris wrote > Dear list, > > where is the extension for SQLite that contains the (mathematical) log > function available to download? As referenced in > https://grass.osgeo.org/grass73/manuals/v.db.update.html. > > I think the reference in the manual requires a source or a link to it.

Re: [GRASS-user] .bat modules in bin folder do not work in GRASS 7.2.0 Bourne Shell

Maurício Vancine wrote > I am using the Bourne Shell from GRASS 7.2.0 on Windows, installed by the > OSGeo4W package, and the .bat modules in the bin folder are not recognized > as commands. > > For example, v.db.addcolums only works on the console. > > Is there a way for these commands to work

[GRASS-user] [SoC] OSGeo - GSoC 2017: proactive students wanted!

[ https://lists.osgeo.org/pipermail/soc/2017-March/003561.html] Dear OSGeo community, students, OSGeo has been selected as a mentor organization for the 2017 edition of GSoC! [1] *According to the Google Summer of Code 2017 Timeline [2]: February 27 - March 20 Potential student participants

Re: [GRASS-user] Change value of a specific raster cell

>> east, north: 638546.314602, 222715.12161 >> myelev@user1: >> color: 255:255:255 >> value: 160 thats the result of my pixel change in the mapdisplay query. > In the digitizer? I saw no widgets for coordinates there. there is no such widget. my workflow mentioned above: >> -> cell

Re: [GRASS-user] Change value of a specific raster cell

Rich Shepard wrote >I tried this and must have missed a step. I selected 'raster > digitizer', > changed the status bar selector to 'Go to', entered the cell coordinates, > and the value of 160.0 in the digitizer value combo box, and saved the > map. > r.what shows the original value, not the

Re: [GRASS-user] Change value of a specific raster cell

- best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Change-value-of-a-specific-raster-cell-tp5308909p5308919.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list

Re: [GRASS-user] Change value of a specific raster cell

>What is the appropriate r.mapcalc command to change the value of the >raster cell at a specified coordinate? beside r.mapcalc, in the mapdisply there is the dropdown menue (2D view, 3D view, vector digitizer, raster digitizer). with the raster digitizer you can change the value of a single

Re: [GRASS-user] r.mapcalculator and r.mapcalc

>1 - Why wasn’t r.mapcalculator ported to grass7? It is great to use it from within QGIS. can't answer this one >My r.mapcalc outputs int32 rasters (I want float32). Is there a way to choose the output type? from the manual [1] [...] Functions The functions currently

Re: [GRASS-user] Problem installing grass7 AddOn

Hi Anna, Anna Muñoz wrote > Hi all, > > I have just installed r.sun.daily grass addon following the instructions > described in https://grasswiki.osgeo.org/wiki/AddOns. > As you can see in the console message the installation was successful: > > (Thu Feb 09 12:56:20 2017) > > g.extension

Re: [GRASS-user] GRASS7.2: v.in.osm add-on / Windows 8

Helmut Kudrnovsky wrote > > Helmut Kudrnovsky wrote >> anyone any idea why v.in.osm doesn't work? > by debug=3 on, it seems to stop around > > https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.in.osm/v.in.osm.py#L140 no, it's around here 70

Re: [GRASS-user] GRASS7.2: v.in.osm add-on / Windows 8

Helmut Kudrnovsky wrote > anyone any idea why v.in.osm doesn't work? by debug=3 on, it seems to stop around https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.in.osm/v.in.osm.py#L140 140 try: 141 grass.debug('Step 3/3: v.build.polylines...', 2)

Re: [GRASS-user] GRASS7.2: v.in.osm add-on / Windows 8

Helmut Kudrnovsky wrote > just imported all lines where there is an entry in the "highway" column > for me. > > it's what in > https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.in.osm/v.in.osm.py#L117 > > 117 gras

Re: [GRASS-user] GRASS7.2: v.in.osm add-on / Windows 8

Peter Löwe wrote > Hi GRASS-User list, > > I'm currently using GRASS7.2 on Windows 8. > > The v.in.osm add-on > (https://grass.osgeo.org/grass72/manuals/addons/v.in.osm.html) refuses to > work in this setting. I would be grateful for any ideas how to overcome > this. > > Reference example from

Re: [GRASS-user] GRASS7.2: v.in.osm add-on / Windows 8

Peter Löwe wrote > Hi GRASS-User list, > > I'm currently using GRASS7.2 on Windows 8. > > The v.in.osm add-on > (https://grass.osgeo.org/grass72/manuals/addons/v.in.osm.html) refuses to > work in this setting. I would be grateful for any ideas how to overcome > this. > > Reference example from

[GRASS-user] Google Summer of Code ideas page: action required latest by February 5th!

Dear All, It’s that time of the year again! Applications for Google Summer of Code 2017 are now open for would-be mentor organizations, and we are in the process of applying on behalf of OSGeo. At this stage, it is extremely important that we put up a nice and informative ideas page, that

Re: [GRASS-user] GRASS 7.2 v.in.ascii error

>SQL parser error (syntax error, unexpected TIME, expecting >NAME processing 'time') in statement: Could it be that time is a SQL reserved word/key? Try another word instead of 'time'. HTH Helmut - best regards Helmut -- View this message in context:

Re: [GRASS-user] update column w/ output from bash function

> You mean here: https://grasswiki.osgeo.org/wiki/SQL ? yes, thanks. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/update-column-w-output-from-bash-function-tp5303075p5303365.html Sent from the Grass - Users mailing list archive at Nabble.com.

Re: [GRASS-user] update column w/ output from bash function

Ken Mankoff wrote > Hi Stefan, > > Your code didn't seem to work for me, but allowed me to figure out how to > make it work. This does: > > db.execute sql="UPDATE CTD_2015 SET YMD=date('2015-01-01', +CAST(DOY AS > text) || ' days');" > > > I'm not sure why I can't simplify this to: > >

Re: [GRASS-user] update column w/ output from bash function

Ken Mankoff wrote > Hi Helmut, > > I misspoke and the data column I'm working with is not Julian Day (JD) but > Day of Year (DOY). I looked at the SQL datetime functions and can't find a > way to convert DOY to YYY-MM-DD. Can you help with this? > > Also, you are correct, these modules do not

Re: [GRASS-user] update column w/ output from bash function

Helmut Kudrnovsky wrote >>Neither db.execute nor db.select appear to work with arbitrary bash commands. > > AFAIK these modules need a SQL statement, not a bash command; e.g. [1]: > db.execute - Executes any SQL statement. > > > [1] https://grass.osgeo.org/grass73

Re: [GRASS-user] update column w/ output from bash function

>Neither db.execute nor db.select appear to work with arbitrary bash commands. AFAIK these modules need a SQL statement, not a bash command; e.g. [1]: db.execute - Executes any SQL statement. [1] https://grass.osgeo.org/grass73/manuals/db.execute.html - best regards Helmut -- View this

Re: [GRASS-user] WinGRASS not recognizing accented utf-8 (nor cp1252) attribute values

Martin Landa wrote > Hi, > > 2016-12-05 22:12 GMT+01:00 Salim Al Razzaz > salim.razzaz@ > : >> dbf file into utf-8 and sat it as the value of the variable, to no avail. >> I also >> tried using the 'encoding' parameter in v.in.ogr in both cases, didn't >> work. > > strange, it should help.

Re: [GRASS-user] WinGRASS not recognizing accented utf-8 (nor cp1252) attribute values

Salim Razzaz wrote > Hi, > > I've got shape files with Swedish accented letters (ÄÖÅ) in the some of > the attribute > values. The Attributes are shwon as they should in the GUI. SQL > statements, however, > are not recognizing them. They're also messed up in the command output if > another >

Re: [GRASS-user] WinGRASS not recognizing accented utf-8 (nor cp1252) attribute values

Salim Razzaz wrote > Hi, > > I've got shape files with Swedish accented letters (ÄÖÅ) in the some of > the attribute > values. The Attributes are shwon as they should in the GUI. SQL > statements, however, > are not recognizing them. They're also messed up in the command output if > another >

Re: [GRASS-user] areas with no centroid

> Thanks for the suggestion, but the area with no centroid doesn't >have a cat. that's exactly what I've meant. then do v.extract cats="cats of the polygones with cat" to extract only these polygones you need. from the v.extract manual : cats=range Category values Example: 1,3,7-9,13

Re: [GRASS-user] areas with no centroid

Dave Roberts wrote > After editing a map with wxgui I ended up with 39 areas and 38 > centroids. How do I find and delete the area with no centroid? > > I have tried many combinations of v.info, v.category, v.to.db, and > visualizing with d.vect. If I use v.clean tool=rmarea with slowly >

Re: [GRASS-user] importing Mars DEM takes too long

Even Rouault-2 wrote > On dimanche 20 novembre 2016 17:38:19 CET Anna Petrášová wrote: >> On Sun, Nov 20, 2016 at 5:02 PM, Helmut Kudrnovsky > hellik@ > wrote: >> >>11 seconds can be pretty long depending on the size of the file. Try >> >

Re: [GRASS-user] importing Mars DEM takes too long

Anna Petrášová wrote > On Sun, Nov 20, 2016 at 5:02 PM, Helmut Kudrnovsky > hellik@ > wrote: >>>11 seconds can be pretty long depending on the size of the file. Try >>>to convert it to tif and load again, it will be probably much faster. >> >> the gdal_t

Re: [GRASS-user] importing Mars DEM takes too long

>11 seconds can be pretty long depending on the size of the file. Try >to convert it to tif and load again, it will be probably much faster. the gdal_translated uncompressed geotif has about ~150MB (jp2 ~48 MB). the import takes about 7 seconds. there is some difference in importing time ;

Re: [GRASS-user] importing Mars DEM takes too long

Markus Neteler wrote > On Sun, Nov 20, 2016 at 9:17 PM, Anna Petrášová > kratochanna@ > wrote: >> On Sun, Nov 20, 2016 at 3:02 AM, Markus Neteler > neteler@ > wrote: >>> On Nov 19, 2016 11:55 PM, "Anna Petrášová" > kratochanna@ > wrote: On Sat, Nov 19, 2016 at 2:20 PM, Markus

Re: [GRASS-user] profil surface map fails

Rengifoo wrote > Dear community,profil surface map fails to  start and produce the > following output in the command console: > Traceback (most recent call last): >   File "C:\OSGeo4W\apps\grass\grass-7.0.5\gui\wxpython\mapdi > sp\frame.py", line 1044, in OnProfile > >

Re: [GRASS-user] How to get the mean of overlaping areas between rasters.

M. wrote > Dear all, > > I want to sum 13 raster maps, and calculate the mean of areas which > overlap > among them. I mean, sum all the maps, but in those areas which they > overlap > calculate the mean of the values. > > Does anybody know a method to do it? > > Thanks for the attention, hope

Re: [GRASS-user] v.edit: unexpected behavior

Rich Shepard wrote > On Fri, 28 Oct 2016, Helmut Kudrnovsky wrote: > >> in your cmd you're using 'id'? > > Helmut, > >Yes, because when I use the GUI to identify polygons the pop-up table > shows the numbers as IDs, not c

Re: [GRASS-user] v.edit: unexpected behavior

Rich Shepard wrote > The attached PNG image shows catchment boundaries and data collection > points. I'm trying to delete those catchments with no contained points, > but > v.edit is not working as expected. > >The topmost (northern) catchment with a data collection point has ID=4; > the

Re: [GRASS-user] Vector map attribute data: coordinates

Rich Shepard wrote > I've a map of points, one for each monitoring location. When I view the > attribute table the only empty columns are the geographic coordinates > (easting and northing). I want to run spatial statistical models on these > data, applying the RGrass interface. > >Are the

Re: [GRASS-user] Vector file import formats

Rich Shepard wrote > On Thu, 27 Oct 2016, Randal Hale wrote: > >> The MXD files are just ArcGIS Map documents. They will hold no data - >> only >> symbology. > > Randy, > >Therefore, useless to me. > >> You'll need to get your data out of the personal geodatabase files (the >> .mdb

Re: [GRASS-user] Non-Topological Vector Polygon Layer From r.water.outlet

>3. Cut the basin polygons using a geological polygon map and and calculate km2 or percentage of km2 for each lithological >unit found within each basin. After denormalizing these areas & lithologies (rows as samples and the columns km2 of each >lithology) one can then perform linear regression

Re: [GRASS-user] DBMI-SQLite drive error when running i.segment.stats (with vector map creation)

uld be worked around by the person using the > tools? > > I guess I could do this with a g.rename. > > Thanks > > James > > On 18 October 2016 at 17:51, Helmut Kudrnovsky > hellik@ > wrote: > >> >angle_ortho.1_min double precision >> >>

Re: [GRASS-user] DBMI-SQLite drive error when running i.segment.stats (with vector map creation)

>angle_ortho.1_min double precision I suspect that it is the point in the column name. to verify, try to add such a column name in one of your vectors. - best regards Helmut -- View this message in context:

Re: [GRASS-user] Interpreting r.watershed accumulation map

Rich Shepard wrote > On Sun, 16 Oct 2016, Sören Gebbert wrote: > >> I don't know why this happens. > >I sent Laurant the DEM and the Itzi simulation run worked for him using > grass-7.0.5, but it fails here with grass-7.0.6, 7.2.svn, and 7.3.svn. > There > must be something different here on

Re: [GRASS-user] grass-user Digest, Vol 126, Issue 37

Is there anything which could be improved in the manual to avoid this leading number issue? - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-grass-user-Digest-Vol-126-Issue-37-tp5290781p5290787.html Sent from the Grass - Users mailing list

Re: [GRASS-user] v.rast.stats ERROR

>ERROR: Unable to add column <1_average DOUBLE PRECISION>. >ERROR: Adding columns failed. Exiting. AFAIR in SQL column names starting with a number isn't allowed. So try to switch from 1_average to average_1 and so on. - best regards Helmut -- View this message in context:

Re: [GRASS-user] boundary vs area in wx0

Dave Roberts wrote > I'm having difficulty getting the wx devices to show vector features. > For example, I have a map called newveg. v.info clearly shows that > newveg has areas, e.g. > > Number of points: 0 Number of centroids: 38183 > Number of lines: 0 Number of

Re: [GRASS-user] DEM re-projection: change elevation units

Rich Shepard wrote > The source DEM has projection units in feet and both geographic > coordinates and elevations are in those units. Re-projecting these data to > the metric equivalent transforms the x, y coordinates from feet to meters > but leaves the elevations in feet. > >Is there a

Re: [GRASS-user] v.in.ascii: 6 points imported, 4 displayed [RESOLVED]

>I also tried 'zoom to selected maps' and nothing happened. > > Wonder what changed. 'zoom to selected maps' with this 6 points means : Point 4 and 6 are exactly on the left and right border of the map canvas, therefore you can see the points hardly. if you change the point symbol and

Re: [GRASS-user] v.in.ascii: 6 points imported, 4 displayed

Rich Shepard wrote > Using v.in.ascii 6 points were imported but only 4 display on the map > window. All 6 appear in the attribute table; when I right click on the > each > of the two invisible ones and select 'highlight selected feature and zoon' > the symbol displays in a light yellow rather

Re: [GRASS-user] map display query and layers

put=ascii.txt output=ascii format=standard > g.region vect=ascii > v.category --overwrite option=add input=ascii output=new_ascii > layer=2 type=centroid > > # check results > > v.category ascii op=report > # 1 layer, 4 centroids with cats 1 & 2 > v.category

Re: [GRASS-user] map display query and layers

>At any rate, since I did not edit what.c to apply Moritz's patch >none of this affects my issues with map display query or >d.what.vect. >I'll get back to that in a subsequent post. Fyi http://lists.osgeo.org/pipermail/grass-commit/2016- October/040536.html Anna committed the patch to

Re: [GRASS-user] r.water.outlet: no map displayed

Rich Shepard wrote > On Mon, 3 Oct 2016, Markus Neteler wrote: > >>> nsres: 1.00019858 >>> ewres: 1.00059954 >> >> ^-- you have no-square pixels, is that on purpose? Of course that's >> supported but just to reduce the amount of error if undesired. > > Markus, > >Nope. That's the

Re: [GRASS-user] r.water.outlet: no map displayed

>rows: 1004 >cols: 577 as the DEM raster you're using isn't that large, may you share the data (offline)? e.g. by a compressed geotiff, by e.g. using r.out.gdal -f input=yourelevation output=outraster.tif format=GTiff createopt=COMPRESS=LZW,PREDICTOR=2 - best regards Helmut

Re: [GRASS-user] r.water.outlet: no map displayed

Rich Shepard wrote > For some reason r.water.outlet now produces an empty map. It did before I > re-projected source maps to ensure they all have the proper values in the > target location. > >Attached is an image of the input drainage map and the coordinate > feature > (the lower dot). > >

Re: [GRASS-user] map display query and layers

Moritz Lennert wrote > On 02/10/16 10:53, Helmut Kudrnovsky wrote: >> it seems that d.what.vect [1] reports always all data of all layers. >> >> the same with v.what although the queried layer is specified. >> >> so maybe a bug/enhancement ticket is needed. >

Re: [GRASS-user] map display query and layers

Dave Roberts wrote > Thanks Helmut, > > On 10/02/16 02:53, Helmut Kudrnovsky wrote: > > {material deleted for space ...} > >> >> it seems that d.what.vect [1] reports always all data of all layers. >> >> the same with v.what although the querie

Re: [GRASS-user] map display query and layers

Dave Roberts wrote > Hi Vincent, > > I have studied the GRASS_GIS_vector_management_model page (and all > the discussion leading up to that), and I think I understand the data > model. What I don't understand is how the map display interacts with > the data tables. So in my example case,

Re: [GRASS-user] A question about raster map resolutions

Rich Shepard wrote > On Tue, 20 Sep 2016, Helmut Kudrnovsky wrote: > >> If it is about raster reprojection, there are hints in the r.proj manual >> about region settings before applying r.proj. >> >> A simple way to do this is to check the projected bounds of t

Re: [GRASS-user] A question about raster map resolutions

Rich Shepard wrote > The LiDAR source location has x- and y-resolution of 3 feet > (international) and several thousand cells east-west and north-south. > g.region -p for this location displays: > > projection: 99 (unnamed) > zone: 0 > datum: ** unknown (default: WGS84) ** > ellipsoid:

Re: [GRASS-user] A question about raster map resolutions

Rich Shepard wrote > The LiDAR source location has x- and y-resolution of 3 feet > (international) and several thousand cells east-west and north-south. > g.region -p for this location displays: > > projection: 99 (unnamed) > zone: 0 > datum: ** unknown (default: WGS84) ** > ellipsoid:

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED ... REALLY!]

> In the ODOT2014 location I created an empty mapset called 'hwy_2015.gdb'. >Exited grass. Moved the contents of the downloaded source file (also called >'hwy_2015.gdb') into the new mapset. Then restarted grass. AFAIK it's not recommended to move/copy any foreign stuff not created by GRASS

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED ... REALLY!]

>The location is the same as the previous map so I let grass >create a new mapset, moved the source files there, restarted grass, and was >told there was no layers selected. what do you mean by "let grass create a new mapset, moved the source files there"? moving the filegdb directory to a

Re: [GRASS-user] Importing data in .atx/.gdb format

>PROJCS["NAD83 / Oregon Lambert (ft)", >GEOGCS["NAD83", >DATUM["North_American_Datum_1983", > SPHEROID["GRS 1980", > you have to find the correct EPSG code related to this infomations. the simpliest task is to ask your data provider for the correct EPSG code of their

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED]

>$ ogrinfo -al . >FAILURE: >Unable to open datasource .' with the following drivers. "." is this really your directory which holds the filegdb data? - best regards Helmut -- View this message in context:

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED]

Rich Shepard wrote > On Wed, 14 Sep 2016, Helmut Kudrnovsky wrote: > >> IMHO it is a data provider issue. >> Data without any information about srs (epsg code, projection, latlon or >> whatever) should go back to the data Providers. > > Helmut, > >

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED]

Rich Shepard wrote > On Wed, 14 Sep 2016, Even Rouault wrote: > >> Cool I've just updated the doc of the FileGDB and OpenFileGDB driver to >> be >> very clear on that : >> >> """The OpenFileGDB driver provides read access to File Geodatabases >> (.gdb directories) created by ArcGIS 9 and above.

Re: [GRASS-user] Importing data in .atx/.gdb format

>Please have a look at www.gdal.org, there is a very nice description >of this data type and how it works with ogr which is used by GRASS >import modules. http://www.gdal.org/drv_openfilegdb.html - best regards Helmut -- View this message in context:

Re: [GRASS-user] Importing data in .atx/.gdb format

>However, as I wrote earlier, no file has a simple .gdb extention. As Markus M. and Stefan B. and me mentioned before; don't look for a file. It is the folder /directory where all the atx etc live, you have to specify for ogrinfo or v.in.ogr! this folder/directory can have any name:

Re: [GRASS-user] Importing data in .atx/.gdb format

Rich Shepard wrote > On Tue, 13 Sep 2016, Blumentrath, Stefan wrote: > >> Thus, you should be able to import your transport data (assuming it is >> vector) with v.in.ogr. A FGDB is as you say also a folder, but if I am >> not >> mistaken you do not have to provide special files to OGR: >>

Re: [GRASS-user] r.mapcalc error

Helmut Kudrnovsky wrote >>r.mapcalc "image 1 = if( NDVI@220215 >= 0.25 ,1 ,0)" >> syntax error, unexpected INTEGER, expecting '(' > > > is there a whitespace between "image" and "1"? > > try image1 instead of image 1. just tried

Re: [GRASS-user] r.mapcalc error

>r.mapcalc "image 1 = if( NDVI@220215 >= 0.25 ,1 ,0)" > syntax error, unexpected INTEGER, expecting '(' is there a whitespace between "image" and "1"? try image1 instead of image 1. - best regards Helmut -- View this message in context:

Re: [GRASS-user] r.mapcalc error

andry rustanto-2 wrote > dear all, > I got an error message when i try to mosaic images : > Mosaicing 2 images... > syntax error, unexpected INTEGER, expecting VARNAME or NAME > Parse error > ERROR: parse error > ERROR: An error occurred while running r.mapcalc > > the syntax error is also

Re: [GRASS-user] Working with multiple mapsets in one location

Rich Shepard wrote > While working in one mapset (version 7.3svn) I recognized that I had two > different data types in it (topography and features) and the features maps > needed their own mapset. Now that I've created the new mapset I want to > move > the features (vector) maps to it but cannot

Re: [GRASS-user] Importing data in .atx/.gdb format

Rich Shepard wrote > Reading the wiki pages on importing ESRI data I did not see anything > relating to .gdb files. The state's geospatial data center assumes the > entire world runs Microsoft and ESRI products and their data for state > transportaion (highways, roads, streets) comes with these

Re: [GRASS-user] GRASS raster curvature analysis type

georges wrote > Hello, > > I would like to know whether raster curvature analysis in GRASS > is Gaussianor Mean curvature analysis? > https://en.wikipedia.org/wiki/Gaussian_curvature > https://en.wikipedia.org/wiki/Mean_curvature > > This GRASS 7.2 manuals page mentions that raster curvature

Re: [GRASS-user] r. mapcalc error in grass gis 7

rustanto wrote > Dear All, > > please help me to solve r.mapcalc problem. After upgrading to 7.0.4, I > could not execute r.mapcalc perfectly, there is a problem : > > syntax error, unexpected INTEGER, expecting VARNAME or NAME Parse error > ERROR: parse error ERROR: An error occurred while

Re: [GRASS-user] Importing ESRI Grid file ... or Shapefile?

Rich Shepard wrote > The LiDAR data files do not have the same extent as the vector files, and > they should. I think I incorrectly imported them. > >There are two flavors of the files: ESRI Grid and Shapefiles. > >I used the Grid files, specifying hdr.adf as the file to use. But, >

Re: [GRASS-user] Import ASCII point file, project to current location

>> (wxgui.py:18569): GLib-GObject-WARNING **: invalid cast from >xPizza' to > >`GtkWindow' >(wxgui.py:18569): Gtk-CRITICAL **: >IA__gtk_window_set_transient_for: >assertion arent == NULL || GTK_IS_WINDOW (parent)' failed just screen the GRASS mailing lists;, there is some recent discussion on

Re: [GRASS-user] Import ASCII point file, project to current location

Rich Shepard wrote > On Fri, 9 Sep 2016, Helmut Kudrnovsky wrote: > >> AFAIK v.in.ascii doesn't do reprojection on the fly. > > Helmut, > >No, it does not. > >> first import your ascii vector by v.in.ascii into the location with the >> appropri

Re: [GRASS-user] Raster renamed but d.rast does not find it

> 'g.rename rast=hdr,bare_earth_2010' vs. >Failed to run command 'd.rast map=hdr@topography'. Details: > >GRASS_INFO_ERROR(4555,1): Raster map not found there is a mismatch in the raster name. - best regards Helmut -- View this message in context:

Re: [GRASS-user] Import ASCII point file, project to current location

Rich Shepard wrote > I'm missing something simple here and have not found a man page or other > explanation about the missing step. > >The source file is in standard format with long/lat points. The target > location is the Oregon state standard projection and coordinate system: > NAD > 1983

Re: [GRASS-user] grass73: python module name issue

Rich Shepard wrote > On Wed, 7 Sep 2016, Helmut Kudrnovsky wrote: > >> Yes, reported on windows, but the same issue. > > Helmut, > >Can we who are affected expect a fix soon? I've a client who needs the > results of topographic and hydrologic modeling, and so

Re: [GRASS-user] grass73: python module name issue

Rich Shepard wrote > On Wed, 7 Sep 2016, Helmut Kudrnovsky wrote: > >> there is already a ticket for this in OSGEO4W-winGRASS; the interesting >> thing is that this issue isn't in >standalone winGRASS of the same >> version. >> >> https://trac.

Re: [GRASS-user] grass73: python module name issue

>there is already a ticket for this in OSGEO4W-winGRASS; the interesting thing is that this issue isn't in >standalone winGRASS of the same version. https://trac.osgeo.org/grass/ticket/3057 - best regards Helmut -- View this message in context:

Re: [GRASS-user] grass73: python module name issue

Anna Petrášová wrote > On Tue, Sep 6, 2016 at 7:31 PM, Rich Shepard > rshepard@ > wrote: >> On Tue, 6 Sep 2016, Anna Petrášová wrote: >> >>> Can you run 'import numpy' for example from GUI Python shell? >>> The imports in GUI look correct to me. >> >> >> Anna, >> >> Yes: >> >> GRASS 7.3.svn

Re: [GRASS-user] create location from CLI

>ERROR: Could not read georeferenced file teste.prj using either OGR >nor > GDAL AFAIK the prj file holds the projection information, but the georeferenced file would be e.g. the related *.shp file. - best regards Helmut -- View this message in context:

Re: [GRASS-user] CHELSA climate data set

> According to gdalinfo, the pixel sizes are > Pixel Size = (0.0083330,-0.0083330) > should be > Pixel Size = (0.008,-0.008) > i.e. fp precision is too low which explains why west is not exactly on > -180 but -180.0001389, just as south is not exactly -90

Re: [GRASS-user] CHELSA climate data set

/addons/r.bioclim.html) that works > pretty nice. > > Cheers, > Vero > > > 2016-09-05 20:34 GMT+02:00 Helmut Kudrnovsky > hellik@ > : > >> hi community, >> >> there is an interesting new climate data set called >> >> CHELSA – Climatologies a

[GRASS-user] CHELSA climate data set

hi community, there is an interesting new climate data set called CHELSA – Climatologies at high resolution for the earth’s land surface areas [1] CHELSA is a high resolution (30 arc sec) climate data set for the earth land surface areas has anyone already tried to use it within GRASS and

Re: [GRASS-user] Problems with r.viewshed.cva

>Module r.viewshed fails, ... ['r.viewshed', '--q', 'observer_elevation=1', 'input=elev_lid792_1m@PERMANENT', 'refraction_coeff=0.14286', 'coordinates=638736.69107769,220612.66221008', 'memory=500', 'max_distance=-1', 'output=vshed_1\r', 'target_elevation=1.75'] ended with error

Re: [GRASS-user] Problems with r.viewshed.cva

tested here with NC sample data set >Module r.viewshed fails, so I would suggest changing >observer_elevation to a number bigger than zero, although I am not >sure if that's the problem. WARNING: Illegal filename . Character < > not allowed. WARNING: Illegal filename . Character < > not

Re: [GRASS-user] Problems with r.viewshed.cva

>Downloading precompiled GRASS Addons ... > >ERROR: File is not a zip file: http://wingrass.fsv.cvut.cz/grass70/x86_64/addons/grass-7.0.3/r.viewshed.zip r.viewshed isn't an addon, it's a core module of GRASS GIS. so no g.extension download needed. tested here with System Info

Re: [GRASS-user] Results of GRASS-GIS' PSC-2016 Election

NikosAlexandris wrote > Dear GRASS GIS community, > > the new Project Steering Committee is composed by the following nine > members: > > 1 Markus Neteler62 > 2 Helena Mitasova 53 > 3 Martin Landa 52 > 4 Anna Petrasova45 > 5 Moritz Lennert41 > 6 Margherita Di Leo 39 > 7

[GRASS-user] r.in.wms help needed

hi, there is a nice map compilation available via WMTS: http://www.basemap.at/ WMTS GetCapabilities : https://www.basemap.at/wmts/1.0.0/WMTSCapabilities.xml what I've done: - create a location with EPSG:3857 - set the region for a small area of interest g.region -p

Re: [GRASS-user] Error trying to run grass from python script/command line in Windows

'PATH': ''C:\\Windows\\SYSTEM32;C:\\Windows;C:\\Windows\\SYSTEM32\\WBEM;C:\\Program Files

Re: [GRASS-user] Error trying to run grass from python script/command line in Windows

>What i discover is that if I remove gdal from PATH environment, the error change to "iconv.dll missing" but >with a similar stacktrace the OSGeo4W iconv.dll lives in C:\OSGeo4W\bin. is it there in your OSGeo4W stack. have a look if there are maybe other iconv.dll in your %PATH%/system (e.g.

Re: [GRASS-user] Error trying to run grass from python script/command line in Windows

>I forgot to mention in the first mail that before getting the stack trace a popup appear saying this > >=== >Microsoft Visual C++ Runtime Library > >Program >C:\OSGeo4W\apps\grass\grass-7.0.4\bin\g.gisenv.EXE > >R6034 >An application has made an attempt to load the C runtime library incorrectly.

Re: [GRASS-user] Error trying to run grass from python script/command line in Windows

>(besides, instaling grass through the Osgeo4w doesn't create a grass70.bat in the >C:\OSGeo4W\apps\grass\grass-7.0.4 folder, the bat seems to be only created using the standalone grass >installers). it does, but it lives in C:\OSGeo4W\bin - best regards Helmut -- View this message in

Re: [GRASS-user] Perform resample a raster using another image as a reference for the process?

Eddison wrote > Hello thank you very much , you can put some screenshots of the process? > Greetings and thanks Eddison have a look at https://grass.osgeo.org/grass70/manuals/g.region.html -a Align region to resolution raster=name[,name,...] Set region

Re: [GRASS-user] v.import and v.proj errors

>would be anyway useful to clarify what this "datum_trans" option means. an example of the datum Hermannskogel [1] aka MGI [2]. this datum goes back to the Austrian-Hungary monarchy which covered the area of Austria, Hungary, Slovenia, etc. this datum was used in all these countries, but

Re: [GRASS-user] v.import and v.proj errors

>as they are in mercator projection (epsg:3857) and I'm working in eu_laea I assume eu_laea is epsg: 3035 (http://epsg.io/3035)? if yes, epsg3035 is dedicated to the area of Europe. is the generalized coastlines data for the whole world? maybe world wide data in epsg:3857

Re: [GRASS-user] [GRASS-PSC] [GRASS-dev] Comment regarding PSC election

Markus Neteler wrote > (sorry for cross-posting) > > On Tue, Jul 26, 2016 at 12:05 AM, Markus Neteler > neteler@ > wrote: >> On Mon, Jul 25, 2016 at 11:33 PM, Michael Barton > Michael.Barton@ > wrote: >>> My perspective is that active contributors to the project should vote. >>> How to

Re: [GRASS-user] [GRASS-PSC] [GRASS-dev] Comment regarding PSC election

Markus Neteler wrote > (sorry for cross-posting) > > On Tue, Jul 26, 2016 at 12:05 AM, Markus Neteler > neteler@ > wrote: >> On Mon, Jul 25, 2016 at 11:33 PM, Michael Barton > Michael.Barton@ > wrote: >>> My perspective is that active contributors to the project should vote. >>> How to

<    1   2   3   4   5   6   7   8   9   10   >