Re: [GRASS-user] Some thoughts on wxGUI (GRASS Community Sprint)
Hello, having console output in same window with layers is one of those small tibits that make new GUI unproductive for daily use. Yeah, it might hava bright future, but unless I can undock comand output to separate window, it will continue to suck. My proposal - do not try to copy ArcGIS/QGIS. With current manpower and legacy we will not be able to do on same level or better. If it's so - better don't. Keep GRASS different. Being able to drag separate windows to different monitors etc. is one of GRASS strenghts. Maris. 2011/3/9, Markus Neteler nete...@osgeo.org: On Tue, Mar 8, 2011 at 6:20 PM, stephen sefick sas0...@auburn.edu wrote: On Mar 8, 2011, at 8:46 AM, Martin Landa wrote: Less Windows. I suggest at most three and preferably two- The layer I agree with that (since I have already another tons of windows already open). which is essentially trapping the individual wxGUI windows in a single one. At least optionally... Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Some thoughts on wxGUI (GRASS Community Sprint)
Hi, 2011/3/10 Maris Nartiss maris@gmail.com: having console output in same window with layers is one of those small tibits that make new GUI unproductive for daily use. Yeah, it might hava bright future, but unless I can undock comand output to separate window, it will continue to suck. I don't see any fundamental troubles here, at least with working key shortcuts to switch between layer tree and output area. My proposal - do not try to copy ArcGIS/QGIS. With current manpower and legacy we will not be able to do on same level or better. If it's so - better don't. Keep GRASS different. Being able to drag separate windows to different monitors etc. is one of GRASS strenghts. Good point. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] winGrass daily builds - available?
Hi, 2011/3/10 Markus Neteler nete...@osgeo.org: On Thu, Mar 10, 2011 at 12:54 AM, Sharon M morrisx...@gmail.com wrote: Could someone advise if the winGrass daily binary snapshots (6.4, 6.5 and 7.0) are still available as the link to the snapshots on the Grass download page (Grass page: http://grass.osgeo.org/grass64/binary/mswindows/native/ to Binary Snapshot link e.g. http://josef.fsv.cvut.cz/wingrass/grass64/) gives a Network error and has done for a few weeks. If snapshots available, where/how do you access them? Server: The server was up a few days ago, we'll investigate what's going on. Snapshots: The snapshots weren't available for some time due to bugs in the winGRASS builder which have been fixed a week ago. yes, server is down since yesterday. Today I will check what's the problem. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Some thoughts on wxGUI (GRASS Community Sprint)
On Thu, Mar 10, 2011 at 9:31 AM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2011/3/10 Maris Nartiss maris@gmail.com: having console output in same window with layers is one of those small tibits that make new GUI unproductive for daily use. Yeah, it might hava bright future, but unless I can undock comand output to separate window, it will continue to suck. I don't see any fundamental troubles here, at least with working key shortcuts to switch between layer tree and output area. My proposal - do not try to copy ArcGIS/QGIS. With current manpower and legacy we will not be able to do on same level or better. If it's so - better don't. Keep GRASS different. Being able to drag separate windows to different monitors etc. is one of GRASS strenghts. Good point. Let the user decide... obviously there are two groups. So to make it optional would be the best solution. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS 6.4.1RC1 wxPython problems on Solaris
On Tue, Feb 22, 2011 at 3:30 PM, Ulli Wölfel uwoel...@gmx.de wrote: Hi, Today I compiled GRASS 6.4.1RC1 on Solaris 10 (SPARC) and encountered some problems with the wxPython-based GUI. When I try to open a preferences Dialog in Layer Manager, I get some error output (see further below) and nothing happens. This error also existed in version 6.4.0 and seems to be related to the following posts: http://trac.osgeo.org/grass/ticket/882 http://lists.osgeo.org/pipermail/grass-user/2011-February/059569.html My desktop is configured for a German locale and UTF-8. However, when entering r.cost --interface-description, I get ?xml version=1.0 encoding=646? - so this might be something specific to Solaris. I have searched and found http://gcc.gnu.org/ml/java/2001-05/msg00111.html It's the default encoding for the C locale. Found also something about charset.alias http://www.stata.com/support/faqs/unix/charset.html I wonder if you have any charset.alias file on your Solaris system which could be tuned. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] sqlite db locking blocking
On Wed, Feb 23, 2011 at 6:19 AM, Hamish hamis...@yahoo.com wrote: ... the error looks like: --- DBMI-SQLite driver error: Error in sqlite3_step(): database is locked For the record: we get such error here, too. It turned out to be a NFS problem: SQLite fails likely when the file is on a NFS mounted file system due to bugs in older NFS versions. Here with Mandriva 2011 it works, with an older Scientific Linux 5.5 it fails. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Running an external executable file from a Python Script
Greetings all, I have a python script from where I need to run an external binary (in Windows). This external binary (not developed by me) uses an input_parameter file to configure binary and get other parameters. The problem is that this binary requires that in my active folder I have my parameter file. Example: If I want to run this binary (outside GRASS Python Scripts) i open cmd, go to a folder where I have a parameter file (e.g. c:\delete (cd c:\delete)) Then I can run this binary as long as I have my parameter file in my active folder like this (c:\tool\training.exe). What I mean is that in my active folder I do not need to have my binary only my parameter file. My question is, when I'm running a GRASS python Script what is my active folder in order to place there my Parameter file? Or, is there any way to change my active folder while I'm running GRASS python Script? Hope I was clear enough in this email since this was unexpected for me. Thanks Antonio __ Information from ESET NOD32 Antivirus, version of virus signature database 5941 (20110310) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.in.ascii: DBMI-DBF driver error
Hi all, I'm trying to use v.in.ascii and I'm getting a DBMI-DBF driver error. --- GRASS 6.4.0RC5 (latlong_coral):~/grassdata/latlong_coral v.in.ascii input=kyy.csv out=kyy skip=1 fs=, columns='x, y, cat int' cat=3Scanning input for column types... Maximum input row length: 86 Maximum number of columns: 9 Minimum number of columns: 8 DBMI-DBF driver error: Cannot create dbf database: ~/grassdata/latlong_coral/PERMANENT/dbf/ WARNING: Unable to open database ~/grassdata/latlong_coral/PERMANENT/dbf/ by driver dbf ERROR: Unable to open database ~/grassdata/latlong_coral/PERMANENT/dbf/ by driver dbf I'm using GRASS6.4.0RC5 in Ubuntu 10.04. I ran db.connect successfully and got the following output. GRASS 6.4.0RC5 (latlong_coral):~/grassdata/latlong_coral db.connect -p driver:dbf database:~/grassdata/latlong_coral/PERMANENT/dbf/ schema: group: It seems a lot of people get this error (according to google...), but I haven't seen a solution. Does anyone have any idea how I can make this work? I've attached the csv file I'm trying to import. Any advice is greatly appreciated! Thanks, Nick longitude,latitude,gps,depth,secchi,salinity,ph,turbidity,phosphate 98.58923902,7.90619538,35,1.03,0.65,30.39,7.04,6.54,0.12 98.58783429,7.9058705,36,0.36,0.36,30.39,7.29,9.01,0.11 98.59471726,7.90156145,37,0.64,0.62,30.61,7.36,10.28,0.13 98.58250014,7.90999465,46,1.1,0.67,30.44,7.42,11.2,0.13 98.58307203,7.91001971,47,1.5,0.6,30.04,7.44,12,0.14 98.58355575,7.91108907,50,0.9,0.9,30.01,7.68,2.72,0.06 98.5838088,7.91114171,51,1.5,1.5,30.31,7.96,2.18,0.07 98.58412128,7.91193875,52,1.2,- 98.58406487,7.91276428,53,1.45,1.45,30.35,8.02,1.44,0.08 98.58434021,7.91298715,54,1.25,1.25,30.39,8,1.75,0.06 98.58451087,7.91313057,55,1.5,1.5,30.36,8.02,1.43,0.14 98.58461338,7.91292773,56,1.65,1.1,30.38,8.03,1.09,0.02 98.58479125,7.91294466,57,2.5,2.5,30.36,8.03,0.87,0.18 98.5847,7.9129698,58,5,-,30.44,8.1,0.58,0.07 98.58467616,7.91273075,59,6,3.5,30.42,8.09,0.78,0.08 98.58417341,7.91232482,60,5.6,2.75,30.42,8.05,0.75,0.15 98.58451255,7.91226287,61,6,2.6,30.4,8.03,0.64,0.1 98.58472846,7.91191628,62,-,2.7,30.36,8.05,0.72,0.09 98.58475822,7.9117375,63,2.7,2.2,30.36,8.04,0.78,0.13 98.58461355,7.91157799,64,2.3,2,30.35,8.06,0.96,0.11 98.58466585,7.91157749,65,1.4,1.4,30.4,8.04,1.19,0.17 98.58456368,7.91147129,66,1.4,1.4,30.37,8.06,1.29,0.17 98.58449645,7.9115453,67,0.57,0.57,30.4,8,1.28,0.21 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS 6.4.1RC1 wxPython problems on Solaris
Ulli Wölfel wrote: Today I compiled GRASS 6.4.1RC1 on Solaris 10 (SPARC) and encountered some problems with the wxPython-based GUI. When I try to open a preferences Dialog in Layer Manager, I get some error output (see further below) and nothing happens. This error also existed in version 6.4.0 and seems to be related to the following posts: http://trac.osgeo.org/grass/ticket/882 http://lists.osgeo.org/pipermail/grass-user/2011-February/059569.html My desktop is configured for a German locale and UTF-8. However, when entering r.cost --interface-description, I get ?xml version=1.0 encoding=646? - so this might be something specific to Solaris. The encoding is obtained from nl_langinfo(CODESET). In this case, 646 is probably used as a shorthand for ISO-646, which specifies ASCII as well as national variants. I suspect that Python doesn't accept 646 as a valid encoding. Was GRASS configured with the --with-nls switch? If not, it will operate in the C locale, which uses ASCII. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Running an external executable file from a Python Script
António Rocha wrote: My question is, when I'm running a GRASS python Script what is my active folder in order to place there my Parameter file? Or, is there any way to change my active folder while I'm running GRASS python Script? By active folder, I presume that you're referring to the current directory (aka working directory, current working directory or CWD). This is inherited from the calling process; e.g. if you run a script from a shell, the script's current directory will be the shell's current directory. When executing a command via subprocess.Popen(), you can specify its current directory via the cwd= parameter. The grass.Popen() and grass.call() functions accept this parameter, as do all of the grass.*_command() functions for running GRASS modules. You can change the current directory for the current process using os.chdir(), but that should normally be avoided, as any relative filenames will then be interpreted relative to the new current directory, whereas the user probably intended them to be relative to the initial current directory. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Running an external executable file from a Python Script
Hi (Olá) in order to figure out what is your current working folder (or active folder) you can do # python code import os os.getcwd() # end of code This will return a string with your current working folder. As Glyn is stating, if you are going to call this external binary from within a python script you can use a grass.Popen object (or just a normal subprocess.Popen). The grass.Popen object allows you to capture your external binary's output and (eventual) error messages. In the following example, I'm running the 'ls -l' external command, using the /home/Documents directory as a working directory for the external command. Please adapt to your problem / operating system: # python code import grass.script as grass externalCommand = [ls, -l] # note that it is a list externalProcess = grass.Popen(externalCommand, stdout=grass.PIPE, stderr=grass.PIPE, cwd=/home/ricardo/Documents) sdtout, stderr = externalProcess.communicate() # to show the output of your external program print(stdout) # end of code Hope it helps ;) 2011/3/10 Glynn Clements gl...@gclements.plus.com: António Rocha wrote: My question is, when I'm running a GRASS python Script what is my active folder in order to place there my Parameter file? Or, is there any way to change my active folder while I'm running GRASS python Script? By active folder, I presume that you're referring to the current directory (aka working directory, current working directory or CWD). This is inherited from the calling process; e.g. if you run a script from a shell, the script's current directory will be the shell's current directory. When executing a command via subprocess.Popen(), you can specify its current directory via the cwd= parameter. The grass.Popen() and grass.call() functions accept this parameter, as do all of the grass.*_command() functions for running GRASS modules. You can change the current directory for the current process using os.chdir(), but that should normally be avoided, as any relative filenames will then be interpreted relative to the new current directory, whereas the user probably intended them to be relative to the initial current directory. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- ___ ___ __ Ricardo Garcia Silva ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] winGrass daily builds - available?
Hi, 2011/3/10 Martin Landa landa.mar...@gmail.com: Server: The server was up a few days ago, we'll investigate what's going on. Snapshots: The snapshots weren't available for some time due to bugs in the winGRASS builder which have been fixed a week ago. yes, server is down since yesterday. Today I will check what's the problem. http://josef.fsv.cvut.cz/wingrass/ is back again. Anyway I am planning to move wingrass binaries to the new server, I will inform you later. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ascii: DBMI-DBF driver error
On Thu, Mar 10, 2011 at 3:45 PM, Nick Jachowski njachow...@gmail.com wrote: Hi all, I'm trying to use v.in.ascii and I'm getting a DBMI-DBF driver error. --- GRASS 6.4.0RC5 (latlong_coral):~/grassdata/latlong_coral v.in.ascii input=kyy.csv out=kyy skip=1 fs=, columns='x, y, cat int' cat=3 ^^^ ... this cannot work since you did not specify the types for x and y. Doing so, I get: v.in.ascii input=kyy.csv out=kyy skip=1 fs=, columns='x double precision, y double precision, cat int' cat=3 Scanning input for column types... Maximum input row length: 86 Maximum number of columns: 9 Minimum number of columns: 8 Column: 1 type: double Column: 2 type: double Column: 3 type: integer Column: 4 type: string length: 3 Column: 5 type: string length: 3 Column: 6 type: double Column: 7 type: double Column: 8 type: double Column: 9 type: double WARNING: Table kyy linked to vector map kyy does not exist ERROR: Number of columns defined (3) does not match number of columns (9) in input Of course all the other columns need to be defined as well. Or just use the auto-detector: v.in.ascii input=kyy.csv out=kyy skip=1 fs=, cat=3 Scanning input for column types... Maximum input row length: 86 Maximum number of columns: 9 Minimum number of columns: 8 Column: 1 type: double Column: 2 type: double Column: 3 type: integer Column: 4 type: string length: 3 Column: 5 type: string length: 3 Column: 6 type: double Column: 7 type: double Column: 8 type: double Column: 9 type: double Importing points... 100% Populating table... Building topology for vector map kyy... Registering primitives... 23 primitives registered 23 vertices registered Building areas... 100% 0 areas built 0 isles built Attaching islands... Attaching centroids... 100% Number of nodes: 23 Number of primitives: 23 Number of points: 23 Number of lines: 0 Number of boundaries: 0 Number of centroids: 0 Number of areas: 0 Number of isles: 0 v.in.ascii complete. ... It seems a lot of people get this error (according to google...), but I haven't seen a solution. I doubt this statement :) Hope this helps, Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS 6.4.1RC1 wxPython problems on Solaris
Am 10.03.2011 um 16:03 schrieb Glynn Clements: Ulli Wölfel wrote: Today I compiled GRASS 6.4.1RC1 on Solaris 10 (SPARC) and encountered some problems with the wxPython-based GUI. When I try to open a preferences Dialog in Layer Manager, I get some error output (see further below) and nothing happens. This error also existed in version 6.4.0 and seems to be related to the following posts: http://trac.osgeo.org/grass/ticket/882 http://lists.osgeo.org/pipermail/grass-user/2011-February/059569.html My desktop is configured for a German locale and UTF-8. However, when entering r.cost --interface-description, I get ?xml version=1.0 encoding=646? - so this might be something specific to Solaris. The encoding is obtained from nl_langinfo(CODESET). In this case, 646 is probably used as a shorthand for ISO-646, which specifies ASCII as well as national variants. I suspect that Python doesn't accept 646 as a valid encoding. Was GRASS configured with the --with-nls switch? If not, it will operate in the C locale, which uses ASCII. Thanks a lot! That was my mistake - I now recompiled it with --with- nls and it works fine. Btw. in order to get it to compile, I had to edit include/Make/ Platform.make and set INTLLIB = -lintl Maybe this should be fixed in the configure script. Ulli Wölfel___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.sun - ambiguities about coefbh/coefdh
Thanks Jaro, I have added your citation in the manual including a text reference: http://trac.osgeo.org/grass/changeset/45620 (while I was at it, I have also turned the table into a real HTML table). best Markus On Thu, Mar 10, 2011 at 1:54 PM, Jaro Hofierka jhofie...@gmail.com wrote: Hi Markus, The r.sun model is described in this paper: Šúri, M., Hofierka, J. (2004): A New GIS-based Solar Radiation Model and Its Application to Photovoltaic Assessments. Transactions in GIS 8, pp. 175-190. ... The coefficients coefbh, coefdh are defined in the section 3.2 Computing radiation under overcast conditions - eqs. (41), (42). These are beam and diffuse components of the clear sky index. That means the r.sun module can compute a clear-sky radiation right away, however if you want a real-sky radiation (with the effects of cloudiness) then you need some kind of coefficient saying how much the clear-sky radiation is attenuated by the cloudiness. Therefore you have to use raster maps with spatial distribution of these coefficients separatelly for beam and diffuse radiation. I hope this helps. Best wishes, Jaro Markus Neteler wrote: Hi Jaro, on the GRASS list the email below appeared which I cannot really answer. Do you have any hints for us? If ok, I would relay your answer to the list then. From the manual: coefbh=string Name of real-sky beam radiation coefficient input raster map [-] coefdh=string Name of real-sky diffuse radiation coefficient input raster map [-] Besides clear-sky radiations, the user can compute a real-sky radiation (beam, diffuse) using coefbh and coefdh input raster maps defining the fraction of the respective clear-sky radiations reduced by atmospheric factors (e.g. cloudiness). The value is between 0-1. Usually these coefficients can be obtained from a long-terms meteorological measurements. Thanks Markus On Sat, Mar 5, 2011 at 1:30 AM, TimNorweytimmy_wey...@live.at wrote: Hy I´m using GRASS GIS for the first time and I´m going to use the r.sun model for a project. When I was reading the explanation of the model, some questions appeared. One is left. I don´t understand the input parameter/raster coefbh/coefdh. Both of them can be values between 0-1 and they are described by atmospheric factors such as cloudiness. This is what is written in the explanation. But how do I determine coefbh/coefdh? What other factors are influencing them? How are the parameters combined, so that a value between 0-1 is given? Is it possible to determine them in a not too complicated way? I already read one post on coefbh/coefdh. Unfortunately, I didn´t understand it. I´m looking forward to get some answers. Thanks -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/r-sun-ambiguities-about-coefbh-coefdh-tp6090593p6090593.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Processing Atlas Lidar Data - Problem(s)
Hi all! I´m trying to generate a DEM/DSM out of LIDAR data that I have downloaded from the website http://atlas.lsu.edu/lidar/ . The data can be downloaded as .csv-file. Within this file no attribute names are given. For test purpose I manipulated the .csv, so that only 10,000 points were left and I added a row at the top x,y,z as attribute names. After doing that I imported the .csv into QGIS using the Plugin Add Delimited Text Layer, stored the points as .shp-file and imported them into GRASS GIS database using v.in.ogr (as 3D points). Then I tried to follow the workflow described on the website http://grass.osgeo.org/wiki/LIDAR#LIDAR_Tools (I started at DEM/DSM separation the more complex way). The first step should be the use of v.extract to separate first and last pulse laser points. Because of the reason that I have no information about first/last pulse laser points, I skipped this step and tried to follow the other steps. But I think this was for nothing, because v.lidar.edgedetection needs the last pulse laser points and v.lidar.growing needs the first pulse laser points. So I don´t write more about this... I really don´t know how to generate a DEM/DSM based on this data and it would be nice if anyone of you has an idea. Is there a possibility to do generate a DEM/DSM without using the steps that are described within the WIKI page above? What do you think about the import of the .csv into GRASS GIS via QGIS? Is there an easier way to import it? If you need any further information to understand my problem, just let me know. Tim -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Processing-Atlas-Lidar-Data-Problem-s-tp6158817p6158817.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Processing Atlas Lidar Data - Problem(s)
Hi Tim, When dealing with lidar data, I always import using r.in.xyz first. You can easily vary the resolution to generate a quick preview and it will give you a sense of the data source and what information it contains. If you then find you need to do more advanced processing, you can move over to the lidar tools. Cheers, Jamie On Thu, Mar 10, 2011 at 10:23 AM, TimNorwey timmy_wey...@live.at wrote: Hi all! I´m trying to generate a DEM/DSM out of LIDAR data that I have downloaded from the website http://atlas.lsu.edu/lidar/ . The data can be downloaded as .csv-file. Within this file no attribute names are given. For test purpose I manipulated the .csv, so that only 10,000 points were left and I added a row at the top x,y,z as attribute names. After doing that I imported the .csv into QGIS using the Plugin Add Delimited Text Layer, stored the points as .shp-file and imported them into GRASS GIS database using v.in.ogr (as 3D points). Then I tried to follow the workflow described on the website http://grass.osgeo.org/wiki/LIDAR#LIDAR_Tools (I started at DEM/DSM separation the more complex way). The first step should be the use of v.extract to separate first and last pulse laser points. Because of the reason that I have no information about first/last pulse laser points, I skipped this step and tried to follow the other steps. But I think this was for nothing, because v.lidar.edgedetection needs the last pulse laser points and v.lidar.growing needs the first pulse laser points. So I don´t write more about this... I really don´t know how to generate a DEM/DSM based on this data and it would be nice if anyone of you has an idea. Is there a possibility to do generate a DEM/DSM without using the steps that are described within the WIKI page above? What do you think about the import of the .csv into GRASS GIS via QGIS? Is there an easier way to import it? If you need any further information to understand my problem, just let me know. Tim -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Processing-Atlas-Lidar-Data-Problem-s-tp6158817p6158817.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] db.connect/db.in.ogr Questions
My postgres tables are in /usr/local/pgsql/data/. My GRASS database is in ~/grassdata/. Since the water well log table did not want to cleanly import with v.in.ascii using the default dbf driver/database, I'll use the postgres table. db.connect wants a driver name (pg), and the database name (Default: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/). The database name is 'nevada' and the table I want to use is 'water_well'. What syntax should I use for db.connect? db.in.ogr has an example for importing a postgres table. What I don't see is how I tell GRASS that it's the last two columns, utm_easting and utm_northing, that should be used as the geographic points? Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] winGrass daily builds - available?
Is there any plans to release nightly builds through Osgeo4W ? It would be great to get hands on grass7 (and wxNviz). Le 10/03/2011 17:11, Martin Landa a écrit : Hi, 2011/3/10 Martin Landalanda.mar...@gmail.com: Server: The server was up a few days ago, we'll investigate what's going on. Snapshots: The snapshots weren't available for some time due to bugs in the winGRASS builder which have been fixed a week ago. yes, server is down since yesterday. Today I will check what's the problem. http://josef.fsv.cvut.cz/wingrass/ is back again. Anyway I am planning to move wingrass binaries to the new server, I will inform you later. Martin ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] db.connect/db.in.ogr Questions
On Thu, 10 Mar 2011, Hamish wrote: set 'g.gisevn set=DEBUG=5' to find the data line it dies on, if you don't already know that. (empty records was it?) Hamish, Already did that and posted the results. The suggestion was to use the postgres table and ignore the dbf table. so maybe like database=host=localhost,dbname=nevada ? I was thinking of trying this. try v.in.db for that. Ah, so. I'll read the v.in.db manual page. Thanks, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Processing Atlas Lidar Data - Problem(s)
Thank you both for answering. I downloaded the recommended book Open Source GIS - A GRASS Approach (Neteler and Mitasova) and my first impressions of it are really good. Especially in Chapter 6 Working with vector data further information to my question can be found. So I hope that I can manage to do this, but before I`m going to start with the beginning ;-), as Stuart recommended. I will let you know when I fixed my problem or I´ll come back with some questions :-)! Cheers Tim -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Processing-Atlas-Lidar-Data-Problem-s-tp6158817p6160016.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ascii: DBMI-DBF driver error
Thanks for the help Markus, but when I try it on my computer I still get the same error message: - GRASS 6.4.0RC5 (latlong_coral):~/grassdata/latlong_coral v.in.ascii input=kyy.csv out=kyy skip=1 fs=, cat=3 Scanning input for column types... Maximum input row length: 86 Maximum number of columns: 9 Minimum number of columns: 8 DBMI-DBF driver error: Cannot create dbf database: ~/grassdata/latlong_coral/PERMANENT/dbf/ WARNING: Unable to open database ~/grassdata/latlong_coral/PERMANENT/dbf/ by driver dbf ERROR: Unable to open database ~/grassdata/latlong_coral/PERMANENT/dbf/ by driver dbf - I'm a complete newbie to the db part of GRASS; was I supposed to do anything special during the installation to allow the dbf driver to work? I've tried this on two separate machines and have the same error message in both, one is running GRASS 6.4.0RC5 on Ubuntu 9.10 the other is running GRASS 6.4.0 on Ubuntu 10.04 in a vm. Sorry to bother the list again! Nick On Fri, Mar 11, 2011 at 12:13 AM, Markus Neteler nete...@osgeo.org wrote: On Thu, Mar 10, 2011 at 3:45 PM, Nick Jachowski njachow...@gmail.com wrote: Hi all, I'm trying to use v.in.ascii and I'm getting a DBMI-DBF driver error. --- GRASS 6.4.0RC5 (latlong_coral):~/grassdata/latlong_coral v.in.ascii input=kyy.csv out=kyy skip=1 fs=, columns='x, y, cat int' cat=3 ^^^ ... this cannot work since you did not specify the types for x and y. Doing so, I get: v.in.ascii input=kyy.csv out=kyy skip=1 fs=, columns='x double precision, y double precision, cat int' cat=3 Scanning input for column types... Maximum input row length: 86 Maximum number of columns: 9 Minimum number of columns: 8 Column: 1 type: double Column: 2 type: double Column: 3 type: integer Column: 4 type: string length: 3 Column: 5 type: string length: 3 Column: 6 type: double Column: 7 type: double Column: 8 type: double Column: 9 type: double WARNING: Table kyy linked to vector map kyy does not exist ERROR: Number of columns defined (3) does not match number of columns (9) in input Of course all the other columns need to be defined as well. Or just use the auto-detector: v.in.ascii input=kyy.csv out=kyy skip=1 fs=, cat=3 Scanning input for column types... Maximum input row length: 86 Maximum number of columns: 9 Minimum number of columns: 8 Column: 1 type: double Column: 2 type: double Column: 3 type: integer Column: 4 type: string length: 3 Column: 5 type: string length: 3 Column: 6 type: double Column: 7 type: double Column: 8 type: double Column: 9 type: double Importing points... 100% Populating table... Building topology for vector map kyy... Registering primitives... 23 primitives registered 23 vertices registered Building areas... 100% 0 areas built 0 isles built Attaching islands... Attaching centroids... 100% Number of nodes: 23 Number of primitives: 23 Number of points: 23 Number of lines: 0 Number of boundaries: 0 Number of centroids: 0 Number of areas: 0 Number of isles: 0 v.in.ascii complete. ... It seems a lot of people get this error (according to google...), but I haven't seen a solution. I doubt this statement :) Hope this helps, Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ascii: DBMI-DBF driver error
Hi Nick Odd. Please check the permissions of the ../dbf/ directory. There is nothing special to install for DBF support. Markus On 3/11/11, Nick Jachowski njachow...@gmail.com wrote: Thanks for the help Markus, but when I try it on my computer I still get the same error message: - GRASS 6.4.0RC5 (latlong_coral):~/grassdata/latlong_coral v.in.ascii input=kyy.csv out=kyy skip=1 fs=, cat=3 Scanning input for column types... Maximum input row length: 86 Maximum number of columns: 9 Minimum number of columns: 8 DBMI-DBF driver error: Cannot create dbf database: ~/grassdata/latlong_coral/PERMANENT/dbf/ WARNING: Unable to open database ~/grassdata/latlong_coral/PERMANENT/dbf/ by driver dbf ERROR: Unable to open database ~/grassdata/latlong_coral/PERMANENT/dbf/ by driver dbf - I'm a complete newbie to the db part of GRASS; was I supposed to do anything special during the installation to allow the dbf driver to work? I've tried this on two separate machines and have the same error message in both, one is running GRASS 6.4.0RC5 on Ubuntu 9.10 the other is running GRASS 6.4.0 on Ubuntu 10.04 in a vm. Sorry to bother the list again! Nick On Fri, Mar 11, 2011 at 12:13 AM, Markus Neteler nete...@osgeo.org wrote: On Thu, Mar 10, 2011 at 3:45 PM, Nick Jachowski njachow...@gmail.com wrote: Hi all, I'm trying to use v.in.ascii and I'm getting a DBMI-DBF driver error. --- GRASS 6.4.0RC5 (latlong_coral):~/grassdata/latlong_coral v.in.ascii input=kyy.csv out=kyy skip=1 fs=, columns='x, y, cat int' cat=3 ^^^ ... this cannot work since you did not specify the types for x and y. Doing so, I get: v.in.ascii input=kyy.csv out=kyy skip=1 fs=, columns='x double precision, y double precision, cat int' cat=3 Scanning input for column types... Maximum input row length: 86 Maximum number of columns: 9 Minimum number of columns: 8 Column: 1 type: double Column: 2 type: double Column: 3 type: integer Column: 4 type: string length: 3 Column: 5 type: string length: 3 Column: 6 type: double Column: 7 type: double Column: 8 type: double Column: 9 type: double WARNING: Table kyy linked to vector map kyy does not exist ERROR: Number of columns defined (3) does not match number of columns (9) in input Of course all the other columns need to be defined as well. Or just use the auto-detector: v.in.ascii input=kyy.csv out=kyy skip=1 fs=, cat=3 Scanning input for column types... Maximum input row length: 86 Maximum number of columns: 9 Minimum number of columns: 8 Column: 1 type: double Column: 2 type: double Column: 3 type: integer Column: 4 type: string length: 3 Column: 5 type: string length: 3 Column: 6 type: double Column: 7 type: double Column: 8 type: double Column: 9 type: double Importing points... 100% Populating table... Building topology for vector map kyy... Registering primitives... 23 primitives registered 23 vertices registered Building areas... 100% 0 areas built 0 isles built Attaching islands... Attaching centroids... 100% Number of nodes: 23 Number of primitives: 23 Number of points: 23 Number of lines: 0 Number of boundaries: 0 Number of centroids: 0 Number of areas: 0 Number of isles: 0 v.in.ascii complete. ... It seems a lot of people get this error (according to google...), but I haven't seen a solution. I doubt this statement :) Hope this helps, Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ascii: DBMI-DBF driver error
Wow, thanks, problem solved! It seems the problem had to do with using single quotes when I declared the db path: db.connect driver=dbf database='~/grassdata/latlong_coral/PERMANENT/dbf/' Deleting the quotes, then running chmod 777 on the dbf folder made it work. -Nick On Fri, Mar 11, 2011 at 1:49 PM, Markus Neteler nete...@osgeo.org wrote: Hi Nick Odd. Please check the permissions of the ../dbf/ directory. There is nothing special to install for DBF support. Markus On 3/11/11, Nick Jachowski njachow...@gmail.com wrote: Thanks for the help Markus, but when I try it on my computer I still get the same error message: - GRASS 6.4.0RC5 (latlong_coral):~/grassdata/latlong_coral v.in.ascii input=kyy.csv out=kyy skip=1 fs=, cat=3 Scanning input for column types... Maximum input row length: 86 Maximum number of columns: 9 Minimum number of columns: 8 DBMI-DBF driver error: Cannot create dbf database: ~/grassdata/latlong_coral/PERMANENT/dbf/ WARNING: Unable to open database ~/grassdata/latlong_coral/PERMANENT/dbf/ by driver dbf ERROR: Unable to open database ~/grassdata/latlong_coral/PERMANENT/dbf/ by driver dbf - I'm a complete newbie to the db part of GRASS; was I supposed to do anything special during the installation to allow the dbf driver to work? I've tried this on two separate machines and have the same error message in both, one is running GRASS 6.4.0RC5 on Ubuntu 9.10 the other is running GRASS 6.4.0 on Ubuntu 10.04 in a vm. Sorry to bother the list again! Nick On Fri, Mar 11, 2011 at 12:13 AM, Markus Neteler nete...@osgeo.org wrote: On Thu, Mar 10, 2011 at 3:45 PM, Nick Jachowski njachow...@gmail.com wrote: Hi all, I'm trying to use v.in.ascii and I'm getting a DBMI-DBF driver error. --- GRASS 6.4.0RC5 (latlong_coral):~/grassdata/latlong_coral v.in.ascii input=kyy.csv out=kyy skip=1 fs=, columns='x, y, cat int' cat=3 ^^^ ... this cannot work since you did not specify the types for x and y. Doing so, I get: v.in.ascii input=kyy.csv out=kyy skip=1 fs=, columns='x double precision, y double precision, cat int' cat=3 Scanning input for column types... Maximum input row length: 86 Maximum number of columns: 9 Minimum number of columns: 8 Column: 1 type: double Column: 2 type: double Column: 3 type: integer Column: 4 type: string length: 3 Column: 5 type: string length: 3 Column: 6 type: double Column: 7 type: double Column: 8 type: double Column: 9 type: double WARNING: Table kyy linked to vector map kyy does not exist ERROR: Number of columns defined (3) does not match number of columns (9) in input Of course all the other columns need to be defined as well. Or just use the auto-detector: v.in.ascii input=kyy.csv out=kyy skip=1 fs=, cat=3 Scanning input for column types... Maximum input row length: 86 Maximum number of columns: 9 Minimum number of columns: 8 Column: 1 type: double Column: 2 type: double Column: 3 type: integer Column: 4 type: string length: 3 Column: 5 type: string length: 3 Column: 6 type: double Column: 7 type: double Column: 8 type: double Column: 9 type: double Importing points... 100% Populating table... Building topology for vector map kyy... Registering primitives... 23 primitives registered 23 vertices registered Building areas... 100% 0 areas built 0 isles built Attaching islands... Attaching centroids... 100% Number of nodes: 23 Number of primitives: 23 Number of points: 23 Number of lines: 0 Number of boundaries: 0 Number of centroids: 0 Number of areas: 0 Number of isles: 0 v.in.ascii complete. ... It seems a lot of people get this error (according to google...), but I haven't seen a solution. I doubt this statement :) Hope this helps, Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ascii: DBMI-DBF driver error
what does db.connect -p say? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
