[GRASS-user] Problems with lidar tools
Hello, I'm having major problems with the Lidar tools. I've got a dataset with 5.5-7.0 points per m² and have run v.edgedetection on the original point cloud containing all points with a the spline step parameters set to 0.6 and the other parameters set as outlined in Inverse calibration of lidar filterimg parameters by Brovelli Lucca. Nonetheless, the edges detected don't seem to have a whole lot to do with actual edges in the scene, buildings look like they're completly ignored. Another fact is that I can't see the data in nviz, it claims that there are no points in the region, even though I've set the region settings to match the LiDAR data set. More confusing, I can tell GRASS to show the points with random colors according to their classes, but I can't see the classes themselves in the attribute table, so I can't extract them thematically or control how they're shown. If I build topology again for that classes, I can open the attribute table, but it only has two fields: ID and Interp. Can't figure out what they mean, and v.lidar.growing doesn't change the map at all. What's going on?? Thanks a bunch, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Problems-with-lidar-tools-tp6418988p6418988.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] Re: LiDAR LAS import
That's great, thanks, Markus! I don't know if I understood that 100% correctly - do I need to compile GRASS 7 from source in order to be able to use it? Is there a way to get it running on an already installed version of GRASS 7 from the repository? -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/LiDAR-LAS-import-tp6402014p6416885.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] Re: GRASS can't fetch interface description for Python script
Hi Hamisch, thanks for the reply, but the problem was even more basic than that - I'd simply forgotten to make the script executable. A simple mistake, but one that I needed hours to recognize, probably due to programming for too long without a break ;) Thanks, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/GRASS-can-t-fetch-interface-description-for-Python-script-tp6393688p6411247.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] Using v.lidar.* for object recognition
Hi all, As far as I understand, the v.lidar* modules help to separate surface objects out from the terrain. I've got a lidar point cloud that I would like to use to detect building footprints and can't seem to get them to work. I've followed the instructions on the wiki and cleaned the dataset (there were basically no outliers) and then used, in sequence, v.lidar.edgedetection, v.lidar.growing and v.lidar.correction to try to separate the buildings from the terrain. I was especially excited because I was hoping to simultaneously be able to differentiate between trees and buildings, something that II haven't been able to reliably do using only the DTM and DSM. However, the outputs aren't any different from the inputs, except that the attribute tables only contain two fields, which contradicts the help texts for the individual tools. As far as I can tell from the help texts, it seems that after running the three tools I should get classified points back that have four categories, terrain single pulse, terrain double pulse, and object single and double pulse. Every single point in my results has the category 1, which I don't understand because if I interpolate from the objects that were preclassified as non-terrain objects, I can see that there are differences to the interpolated results if I make an elevation raster from the preclassified terrain points. Also, I'm kind of unsure as to how GRASS should know what points were double and which ones were single pulse. Could anybody help me further, or does anyone have ideas as to how to to extract building footprints without extracting the tree footprints too? Thanks a bunch! Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Using-v-lidar-for-object-recognition-tp6411300p6411300.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] Extracting building footprints from DSM/DTM/LiDAR point cloud
Hi there, I'm working on a project to create a large amount of building footprints. We're planning on giving the building footprints to OSM in the end anyway, so we briefly considered using the Bing imagery in order to digitalize them manually, but to save labor and set up a process that will also work welwell in other areas it would be much better to minimize manual classification if at all possible. That's why we're trying to do the following: 1. Separate non-terrain objects from terrain 2. Separate buildings from other structures 3. Convert 2D building footprints to vectors anand smooth the boundaries Does anyone have any experience with this kind of operation? I've tried a few things and have a couple more ideas too: - Produce the footprints using a normalized digital surface model. I produced one by subtracting the digital surface model from the digital terrain model (from the data provider) and then classified for all objects over 2 m high. This kept most of the trees and part of our study area is suburban, meaning that there were lots of trees. Most of them coule be eliminated by converting the remaining pixels to areas and then deleting all areas that didn't contain address points, but the results were still at best disappointing. - Another idea I have is to take the LiDAR raw data and try to extract the trees from it, then producing a DSM from the remaining points and normalizing it like above, this time definitely without trees. Since I've never worked with raw data from LiDAR scans before, I imagine this task as being kind of daunting, but nonethless quite interesting. The omnipresent time constraints mak me want to find a way around it, though I don't see how. Anyway, I was just wondering if anyone has any experience here that could help me. If not I'll probably end up scripting an algorithm to separate the trees by the echo they return, if anyone's interested in having it I'd be happy to share. Thanks! Best, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Extracting-building-footprints-from-DSM-DTM-LiDAR-point-cloud-tp6402521p6402521.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] GRASS can't fetch interface description for Python script
Hi there, I'm having a lot of trouble starting this script in GRASS. As I'm more than a newbie in programming, this is probably some really basic mistake, but my other scripts all work consistently in GRASS and I've been working on this for quite a while with no success, so here goes :) I quickly put together a script, copied it into /opt/grass/scripts, and when I try to call it from within GRASS it returns the following error: Traceback (most recent call last): File /opt/grass/etc/wxpython/gui_modules/prompt.py, line 1067, in OnKeyPressed self.parent.RunCmd(cmd) File /opt/grass/etc/wxpython/gui_modules/goutput.py, line 516, in RunCmd task = menuform.GUI().ParseInterface(command) File /opt/grass/etc/wxpython/gui_modules/menuform.py, line 2020, in ParseInterface tree = etree.fromstring(getInterfaceDescription(cmd[0])) File /opt/grass/etc/wxpython/gui_modules/menuform.py, line 1970, in getInterfaceDescription Details: %s) % (cmd, e.value) AttributeError : 'exceptions.OSError' object has no attribute 'value' I'm not really able to find any differences between this script and another script that works just fine. However, several scripts that I'd used about a year ago don't work any more, even though the code's the same - very mysterious. I'm using the most recent GRASS 6.4.1 from the OpenSUSE geo-repository. Any clues or tips would be greatly appreciated! Would enclose more information, but I'm not sure what's exactly relevant and I don't want to spam ya'll with my entire code. Thanks! Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/GRASS-can-t-fetch-interface-description-for-Python-script-tp6393688p6393688.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] Re: GRASS can't fetch interface description for Python script
...Yes, you can laugh at me... I've been trying to solve this program for a week. The only problem was that I hadn't made the script executable. Sorry!!! It works now ;) Now I have to go dunk my head in icewater... -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/GRASS-can-t-fetch-interface-description-for-Python-script-tp6393688p6393725.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] Unable to start wxpython GUI in KDE
Hi there, I'm not sure if I should be asking here or in the development forum, but has anybody else had trouble starting the wxpython GUI in KDE? I'm running OpenSUSE 11.4 and when I select a location and mapset the splash screen shows up, but then before one of the windows opens I get the following message in the terminal: GRASS 6.4.1 (Hayward_LiDAR):~ (python:3394): GLib-GObject-WARNING **: invalid cast from `GtkCheckButton' to `GtkTreeView' I haven't been able to find anything in the Internet that helped further with this error, but it seems to be specific to KDE and perhaps also to OpenSUSE 11.4. I also use GNOME and in GNOME GRASS is able to run the wxpython GUI without any problems. Really would like be able to work in KDE though. Thanks a lot! Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Unable-to-start-wxpython-GUI-in-KDE-tp6336959p6336959.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] Re: DEM resolution from r.surf.contour
Interpolation's kind of a tough issue. The horizontal resolution shouldn't necessarily be dependent on the contour step intervals, because those are two unconnected parameters. In principle, interpolation will fill the gaps between given values. Since the gap filling values are always guesses - albeit educated guesses - the resolution is kind of a matter of taste, in my opinion. I'd say that the method chosen is much more important - e.g. r.surf.contour interpolates linearly, whereas v.surf.rst uses spline with tension. So... Lange Rede, kurzer Sinn, I'd have a hard time telling you what resolution to take for an interpolated DEM. Factors I'd consider would be: 1. How closely spaced are the contour lines? a.k.a. if you were to translate the surveying coverage of the vectors to horizontal resolution, what would you guess - how exact is the spatial data you're dealing with as inputs? 2. What scale do you need for your analysis? As far as the problem with limited memory goes, perhaps the thing to do would be to split the area up into smaller tiles and then perform the interpolation for them all recursively and stitching together again in the end? In that case I'd make the tiles a little bigger than necessary and let them overlap, and then throw away the edges when I stitched everything back together again. Interpolated values should be cropped at the edges, because on those sides there's no data available to interpolate into so you get unrealistic results. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/DEM-resolution-from-r-surf-contour-tp6330087p6337007.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] Re: Unable to start wxpython GUI in KDE
Thanks, the link had the trick on it - I changed the GTK style in the application settings under the personal settings area and GRASS opens like a charm. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Unable-to-start-wxpython-GUI-in-KDE-tp6336959p6337887.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] Re: Limit r.fillnulls to interpolate only small gaps
I would do it like this: - Make a mask of the gaps with r.mask (either by masking placeholder values that stand for gaps or, if the map really has no values where there are gaps, by making an inverse mask from the real values. - Create an arbitrary raster that overlays the gaps (with the mask applied just use e.g. r.mapcalc newmap=1 - Remove the mask - Conver the raster to vectors - Delete all vectors that are small enough to be interpolated over - Conver the vectors back into raster - Interpolate all the gaps in the old map - Make an inverse mask from the raster that holds the locations of the too large gaps - Use r.mapcalc to remove the interpolated areas where the gap was too big Another way, which is in my opinion better and faster, would be to use r.clump on the raster of the gaps to give the contigious areas an identical value, then run r.stats to spit out their areas, and then reclass the raster so that the cell values match the area covered by the gaps. Then you could remove the too big areas with r.reclass. Hope that helps! :) Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Limit-r-fillnulls-to-interpolate-only-small-gaps-tp6040101p6040155.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] Re: Limit r.fillnulls to interpolate only small gaps
I think William's right, the shape factor is important. A way to combine the two so that the shapes of the large null areas is the same as the gaps in the original raster would be to make polygons out of the original gap areas, then use William's method with r.grow, then making polygons that match the unfilled areas. The polygons that have the area of the original gaps that also overlap polygons generated using the r.grow method would then be the polygons to use as a mask. Thus the thin gaps would be filled in. The only problem there is that large gaps with a bottleneck somewhere would be shut out of the analysis, although the bottleneck could theoretically be interpolated quite well. But that would have happened with my original suggestion too. Or you could use r.grow and just accept the fact that even the large interpolated areas will be interpolated on the edges. Then the bottlenecking problem would be gone. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Limit-r-fillnulls-to-interpolate-only-small-gaps-tp6040101p6040361.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] Re: r.mapcalculator / r.mapcalc not producing raster
Wow, it looks like your output raster is really, really small - only 400 cells. Is that correct? It also has values (you can tell by the min/max values in the metadata). That means that GRASS is producing something. Have you tried setting the regional settings to match test_combo? If you're importing into a new location without having set the regional settings before, it could be that your regional settings don't allow GRASS to display the map. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/r-mapcalculator-r-mapcalc-not-producing-raster-tp6041018p6041044.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] Am I still on the list?
Hi there, Listen, I'm not meaning to bug anyone, but the last couple of questions I've posted on this list haven't been answered at all. I can see the posts online but I never get any answers back. Is this not getting sent out to the subscribed users or are my questions too stupid? I don't mean to sound annoyed or anything - I'm really truly just wondering. In case somebody does get this, it'd be nice if they could take a look at my (probably newbie) question about multithreading: http://osgeo-org.1803224.n2.nabble.com/Multithreading-in-GRASS-6-4-td5875866.html Thanks a lot and happy New Year! Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Am-I-still-on-the-list-tp5889353p5889353.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] Multithreading in GRASS 6.4
Hello, I'm trying to use multithreading in GRASS 6.4 in OpenSUSE 64-bit installed from the community repository and am wondering what the best way would be to set my script. What I'm wanting to do is several r.sun analyses parallel to one another using a Python script. I've read the wiki page about OpenMP at http://grass.osgeo.org/wiki/OpenMP#Multithreaded_jobs_in_GRASS but don't quite understand it - it seems that I can activate multithreading capabilities in GRASS by modifying /lib/gpde/Makefile but I don't have that file. I also wasn't able to find a whole lot of information about it that I could understand - I meet the requirement listed at http://grass.osgeo.org/programming6/gpdelib.html of having a compiler that supports OpenMP (I've got gcc 4.5), but am unsure of how I should proceed. Does anyone have any tips? Happy New Year's and thanks a bunch in advance! Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Multithreading-in-GRASS-6-4-tp5875866p5875866.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] Re: getting started (stuck) with GRASS 2.
Hi Ruvy, GRASS can definitely do all the stuff that you listed. I've never worked with the DWG format, but I believe there's a module that lets you import it called v.in.dwg. As far as importing the Arc data, it sounds like you're wanting v.in.ogr. That's the module used to import shapefiles, which are the formats you're talking about. Buying the book is definitely a good idea, because getting started with GRASS isn't necessarily as easy as with other GI-Systems. However, you'll find that you can do a whole lot more with GRASS than with many other systems. As it sounds like you've already set the location of your GRASS database, you need a location and a mapset to get started. For the location, you need a coordinate system - try using one of your georeferenced files to create that, like your .shp from the Arc user's data. As soon as that's done you can create mapsets that are geographically or thematically sorted - as a practice you might want to just open up your PERMANENT mapset and import some data into it, set the region settings to match your data and play around. Anyway, those are just some fast starter tips, but I would definitely suggest getting the book. All your data should be compatible, the functions you're looking for are there - I hope this helps you a bit further :) Best, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/getting-started-stuck-with-GRASS-2-tp5620514p5620584.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] Re: getting started (stuck) with GRASS 2.
Hi Ruvy, Don't worry, setting up the location is something that can even be difficult for geographers that aren't familiar with GRASS. The concept is: 1. Geodata (data connected with locational information) consists of descriptive information as well as data describing the object's position, normally on the Earth's surface. That means coordinates. But because there are multiple ways to describe positions on the Earth's surface, meaning various coordinate systems, GRASS has to know what coordinate system your data uses in order to be able to analyze your data in a spatial context. 2. In order to be more organized once a coordinate system has been defined GRASS analyzes the data you import into various sub-categories that you can organize as you like. Practically, that means that you need to first define the coordinate system you're working with. That's what you do in the Location GUI. In the first GUI that pops up when you start GRASS, you tell GRASS where it should put its database (the GIS Data Directory, field at the top) - that's a directory that GRASS works with, where it will put all its data - including any data you import and any data you produce. It sounds like you've already done this. After that you need to define a location that you'll be working in. Locations can hold your data. All the data in a single location needs to use the same coordinate system. If you have data with different coordinate systems and want to be able to analyze or view them together in GRASS, it's no problem, but you'll need to transform the data so that it all has a single coordinate system. We won't worry about that. Let's worry about getting you a working location first. So the first step is to open the location wizard to create a new location. If you click on that button it'll ask you what your new location should be called - you can name it as you like - and after clicking Next you'll be asked how you'd like to create your new location. As you're a landscape architect I'm assuming you don't have too much experience with coordinate systems and etc., which could make the next menu somewhat confusing. If you know more information about the coordinate system you're working with, you can enter that info. I'll assume you want to just take the coordinate system of the data you've been given. Your first post sounded like you might have already tried it, but I'll go through that quickly by describing two methods that both work just as well: - Select Read projection and datum terms from a georeferenced data file and click next. Then enter one of your shapefiles (that's an Arc file with the extension .shp). You could probably just as easily use the DWG file, but since I've never tried that before we'll stick with the shapefile. Alternatively, you can - Select Read projection and datum terms from a WKT or PRJ file and click next. Then take one of your *.prj files from the Arc data. Now you should see a summary of the info you've entered. Click Finish and you've got your location. In the interest of simplicity, don't set the default region extents and resolution yet. That's just step one, now you need a mapset to work in. Mapsets are inside locations and contain data. You can have several datasets inside one mapset. Mapsets can also interact with each other, as long as all the data's inside the same location. Most users find it helpful to put data in mapsets that either covers the same geographic area or is thematically related, but it's really a matter of taste and effectiveness and must be decided from project to project. Normally I would always suggest making a new mapset to hold your data, but since you don't have experience with GRASS and need your stuff quickly, we can skip that and you can start working more cleanly later, after you've gotten the GRASS book :) Once your location is made, you've got a mapset automatically. It's called PERMANENT. Every location has a permanent mapset; all other mapsets are added manually by the user. Let's use that one, so go ahead and open it by clicking Start GRASS. Now you're in GRASS, and this is where I was talking about as I mentioned v.in.ogr and v.in.dwg. You'll have two windows, one is your layer manager and the other is the map display, and if you type in v.in.ogr without quotation marks in the Cmd field at the bottom of the layer manager, you'll get the GUI for that module. It should let you import almost any vector data format you want. I mentioned v.in.dwg after seeing your data format and glancing over the results of a Google search, but I can't find it either and in the documentation it seems to perhaps not exist any more. I'm not sure what other options you have for that kind of data since I don't know that format - it's for CAD data, right? There's probably a way of importing it into GRASS, or of converting it into a format that can be imported to GRASS, but I unfortunately can't help you much further in that area. Entering the commands in the command field is a
[GRASS-user] Re: NetCDF Data in GRASS?
Great, thanks a bunch! Dumb mistake on my part that I missed that :P -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/NetCDF-Data-in-GRASS-tp5506213p5512700.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] NetCDF Data in GRASS?
Hello all, Does anybody have any experience with integrating NetCDF data into GRASS? That's a ton of great data and I'm wondering if there's a direct way of importing such files into a GRASS database. I've seen scripts that convert them to ArcGRID format, but that's not a very elegant solution, especially if you're dealing with long time series. Thanks a bunch! Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/NetCDF-Data-in-GRASS-tp5506213p5506213.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] Re: BAnk and ditch symbols in grass (or other Open Source GIS)
Hi Tim, Although it's definitely possible to make maps with GRASS, I personally prefer to use GRASS to produce my data and then make my maps with QGIS. Therefore I'm not too familiar with GRASS cartography (is definitely possible) but QGIS makes it quite easy. You could create custom vector symbology that does just what you describe and load your vectors into a database (see QGIS User Guide, especially chapter 3.4, Vector Properties Dialog - http://download.osgeo.org/qgis/doc/manual/qgis-1.5.0_user_guide_en.pdf). I'm not so sure about vectors with directions, though. You could categorize your lines as having their left side in a certain direction, for example... Or maybe somebody else has a better idea for that. Best, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/BAnk-and-ditch-symbols-in-grass-or-other-Open-Source-GIS-tp5451904p5451961.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] Re: Table is not created with vector map
Hey there, Thanks for the help. Also a good tip - for the record, the problem occured consistently with GRASS 6.4, always in Linux systems (Ubuntu 10.4 64-bit and OpenSUSE 11.3 32-bit). The vector map wasn't imported, but converted from a raster map, also created with GRASS. I think that using databases is generally a better idea. At the moment we're in the process in my company of moving everything to databases anyway, so as soon as a similar problem comes up again I'll try that. In the meantime I've found a more elegant solution - using r.clump and porting the results on the map with r.report to python, using that to make a reclass table, and reclassifying the remaining raster cells according to the criteria I need. It's basically a workaround because I never was able to get r.area running, despite the fact that many list members offered great tips. Best, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Table-is-not-created-with-vector-map-tp5432355p5449943.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] Re: Table is not created with vector map
Alright, I've run the same test again with the same raster after having deleted my mapset and importing it again into another location. I've read a lot in the forums about coor files being too large and it seems that my hypothesis of the vector being too large is completely invalid. Here some additional info: When I use v.build I get the same error: Coor files of vector map homogeneous_ar...@permanent is larger than it should be (94546466 bytes excess) Nonetheless, v.build runs to the end. Trying to add a column after running v.build gives me the same problem. I get the following message: Coor files of vector map homogeneous_ar...@permanent is larger than it should be (94546466 bytes excess) Coor files of vector map homogeneous_ar...@permanent is larger than it should be (94546466 bytes excess) Coor files of vector map homogeneous_ar...@permanent is larger than it should be (94546466 bytes excess) DBMI-DBF driver error: Table 'homogeneous_areas' doesn't exist. Error in db_execute_immediate() ERROR: Error while executing: 'ALTER TABLE homogeneous_areas ADD COLUMN area double precision ' ERROR: Cannot continue (problem adding column). Still no further. Running v.digit also doesn't help; I have the same problem. I also tried exporting the vector as a shapefile and that didn't work either; GRASS complained about not being able to access the level 2 topology data. Any help would be appreciated, or at least a nudge in the right direction. I've read a lot of stuff online but haven't found anything that helps me in this situation yet and am confident that GRASS can do this... The coor file is only 90 MiB large with a topo file of 231.8 MiB, therefore not huge files. Of course, I wouldn't mind doing it with r.area, but my thread there has also died off... People, I'm sorry if I'm asking stupid questions but at least I'm trying! :P Thanks a bunch, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Table-is-not-created-with-vector-map-tp5432355p5435807.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] Table is not created with vector map
Hello all, I'm converting a raster to a vector with r.to.vect. The geometries are converted successfully to vector shapes, but I noticed I was unable to work further on the vectors' attribute table. When trying to add a field, I received the following message: Coor files of vector map vector_...@test is larger than it should be (94546466 bytes excess) I then tried to open up the attribute table and was told that the attribute table vector_map could not be found. Interesting. A glance under the tab Manage Tables showed no tables at all; I moved on to Manage Layers and found only one layer, linked to my grass base and then /Test/test/dbf/vector_map with the key cat. However, in my file manager I don't see any such file, even when also viewing hidden files. I tried connecting a new table with v.db.addtable, but got: v.db.addtable map=vector_...@test table=test Using user specified table name: test ERROR: There is already a table linked to layer 1 I've been able to duplicate this problem multiple times with the same raster, but other vector maps I make from other rasters are created fine, also with tables. Could the problem be connected to the high number of features in the vector map? It's got almost a million. However, I've also worked with vectors with more, which makes me doubt that hypothesis. Thanks! Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Table-is-not-created-with-vector-map-tp5432355p5432355.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] GRASS compiled from source: child_exception
Hi all, I've got another problem again. Since I had so much trouble with getting g.extension to work and never managed to get the add-on I desperately need to compile (r.area), I'm trying it now with GRASS compiled from source. I tried GRASS 7 and now I've tried GRASS 6.5, both with the same results. I'm running OpenSUSE 11.3, 32 bit. Since the problem's been the same with 7 and 6.5, I'll show the more recent terminal outputs from 6.5. Installed the latest 6.5-svn code from http://grass.itc.it/grass65/binary/linux/snapshot/. Here's how I did it: - Downloaded grass-6.5.svn-x86_64-unknown-linux-gnu-07_08_2010-install.sh and grass-6.5.svn-x86_64-unknown-linux-gnu-07_08_2010.tar.gz into the same directory - Ran sudo sh grass-6.5.svn-x86_64-unknown-linux-gnu-07_08_2010-install.sh grass-6.5.svn-x86_64-unknown-linux-gnu-07_08_2010.tar.gz GRASS installed itself with the following output: GRASS GIS 6.5.svn-x86_64-unknown-linux-gnu-07_08_2010 binary package installation tool Using gunzip decompressor... The package grass-6.5.svn-x86_64-unknown-linux-gnu-07_08_2010.tar.gz seems to be o.k. Proceeding... Checking and creating installation directory... Installing GRASS binaries into /usr/local/grass6.5.svn-x86_64-unknown-linux-gnu-07_08_2010 Uncompressing the package and extracting to target directory... Creating start script: /usr/local/bin/grass65 - /usr/local/bin/grass-6.5.svn-x86_64-unknown-linux-gnu-07_08_2010 Creating the locks directory for monitors... Creating datum transformation gridshift files... Generating display font configuration file... grass-6.5.svn-x86_64-unknown-linux-gnu-07_08_2010-install.sh: line 344: /usr/local/grass6.5.svn-x86_64-unknown-linux-gnu-07_08_2010/bin/g.mkfontcap: cannot execute binary file Installation finished. Start GRASS 6.5.svn-x86_64-unknown-linux-gnu-07_08_2010 with /usr/local/bin/grass65 Welcome to GRASS GIS. Enjoy this open source GRASS GIS! So far so good, although the inability to execute g.mkfontcap did worry me. Then I started GRASS with the command grass65 and got the following output: l...@pc19392:~/Downloads grass65 WELCOME TO GRASS Version 6.5.svn 2010 1) Have at your side all available GRASS tutorials 2) When working on your location, the following materials are extremely useful: - A topo map of your area - Current catalog of available computer maps 3) Check the GRASS webpages for feedback mailinglists and more: http://www.grass-gis.org http://grass.osgeo.org Hit RETURN to continue Starting GRASS ... Traceback (most recent call last): File /usr/local/grass6.5.svn-x86_64-unknown-linux-gnu-07_08_2010/etc/wxpython/gis_set.py, line 37, in module import gui_modules.goutput
[GRASS-user] Re: GRASS compiled from source: child_exception
Hi there,
Alright, I think I figured out the problem: I've got a 32-bit system and not
a 64-bit one. My mistake.
Now I'm back to the old problem, though. I really need r.area because I'm
working with python and don't want to pipe awk commands through r.stats in
order to find out the area of my homogeneous areas and then have to
eliminate them with r.reclass. When I try to install r.area with g.extension
(put GRASS 6.4 back on my machine) I get the following problem in GRASS:
g.extension extension=r.area
svnurl=https://svn.osgeo.org/grass/grass-addons/ prefix=${GISBASE}
Fetching r.area from GRASS-Addons SVN (be patient)...
Ar.area/main.c
Ar.area/description.html
Ar.area/Makefile
Checked out revision 43042.
mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/bin.i686-pc-linux-gnu
mkdir -p
/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include/grass
mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/lib
mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/bin
mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/etc
mkdir -p
/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/driver
Compiling r.area...
main.c:19:23: fatal error: grass/gis.h: No such file or
directory
compilation terminated.
make: *** [OBJ.i686-pc-linux-gnu/main.o] Error 1
ERROR: Compilation failed, sorry. Please check above error messages.
mkdir -p
/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/driver/db
mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/fonts
test -d OBJ.i686-pc-linux-gnu || mkdir -p OBJ.i686-pc-linux-gnu
gcc -I/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include
-O2 -DPACKAGE=\grassmods\
-I/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include -o
OBJ.i686-pc-linux-gnu/main.o -c main.c
If I try to compile it in a folder after changing the makefile's
MODULE_TOPDIR to point to /opt/grass/ I get the following error:
test -d OBJ.i686-pc-linux-gnu || mkdir -p OBJ.i686-pc-linux-gnu
gcc -I/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include
-O2 -DPACKAGE=\grassmods\
-I/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include -o
OBJ.i686-pc-linux-gnu/main.o -c main.c
main.c:19:23: fatal error: grass/gis.h: No such file or directory
compilation terminated.
make: *** [OBJ.i686-pc-linux-gnu/main.o] Error 1
Does anybody know of a solution or any way to come further?
Thanks,
Daniel
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/GRASS-compiled-from-source-child-exception-tp5412414p5412721.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] Re: Installing r.area
Okay, I changed my Platform.make file from the original file # GRASS dirs GRASS_HOME = /usr/src/packages/BUILD/grass-6.4.0RC6 RUN_GISBASE = /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu to # GRASS dirs # GRASS_HOME = /usr/src/packages/BUILD/grass-6.4.0RC6 RUN_GISBASE = /opt/grass Then I navigated into the folder with r.area and did the following: l...@pc19384:~/r.area export LC_ALL=C l...@pc19384:~/r.area sudo make MODULE_TOPDIR=/opt/grass/ root's password: gcc -I/dist.i686-pc-linux-gnu/include -O2 -DPACKAGE=\grassmods\ -I/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/main.o -c main.c main.c:19:23: fatal error: grass/gis.h: No such file or directory compilation terminated. make: *** [OBJ.i686-pc-linux-gnu/main.o] Error 1 Still no better. I think it might be smarter just to uninstall GRASS completely and compile it from source, but I run into trouble when I do that too... Best, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Installing-r-area-tp5340139p5375851.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] Re: Installing r.area
This will never work unless the OpenSuse packager fixes the wrong path (.../BUILD/... is wrong and needs to be /opt/...). Or you do it yourself... AFAIK, it is in your case in /opt/grass/include/Make/Platform.make Alright, I think I understood what to do. I edited /opt/grass/include/Make/Platform.make (made a backup) and changed these two lines from: # GRASS dirs GRASS_HOME = /usr/src/packages/BUILD/grass-6.4.0RC6 RUN_GISBASE = /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu to: # GRASS dirs GRASS_HOME = /opt/grass RUN_GISBASE = /opt/grass/dist.i686-pc-linux-gnu But this still happens: l...@pc19384:~/r.area make Makefile:11: ../../include/Make/Module.make: Datei oder Verzeichnis nicht gefunden make: *** Keine Regel, um »../../include/Make/Module.make« zu erstellen. Schluss. l...@pc19384:~/r.area make MODULE_TOPDIR=/opt/grass/ gcc -I/opt/grass/dist.i686-pc-linux-gnu/include -O2 -DPACKAGE=\grassmods\ -I/opt/grass/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/main.o -c main.c main.c:19:23: schwerwiegender Fehler: grass/gis.h: Datei oder Verzeichnis nicht gefunden Kompilierung beendet. make: *** [OBJ.i686-pc-linux-gnu/main.o] Fehler 1 Did I do something wrong? Thanks a bunch! Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Installing-r-area-tp5340139p5372018.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] Re: Installing r.area
Alright, I gave it another shot...
GRASS_HOME is the location of the GRASS source tree. If you don't have
the GRASS source tree, it should be unset.
Okay, I turned it off by putting # in front of it. Now the line looks like
this:
# GRASS dirs
# GRASS_HOME = /usr/src/packages/BUILD/grass-6.4.0RC6
Its value is used to initialise a few other variables, which need to
be changed when building without the source tree:
ARCH_DISTDIR = $(GRASS_HOME)/dist.$(ARCH)
ARCH_BINDIR = $(GRASS_HOME)/bin.$(ARCH)
ERRORLOG= $(GRASS_HOME)/error.log
If you're building against an installed version, ARCH_DISTDIR should
be set to the installation directory (e.g. /usr/local/grass-6.4.0RC6),
ARCH_BINDIR shouldn't matter, and ERRORLOG can be set to any absolute
filename.
Alright. I took out the variable $ARCH_DISTDIR and replaced it with
/opt/grass/. So the three lines the GRASS dirs are now:
# GRASS dirs
# GRASS_HOME = /usr/src/packages/BUILD/grass-6.4.0RC6
RUN_GISBASE =
/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu
RUN_GISRC =
/opt/grass/demolocation/.grassrc${GRASS_VERSION_MAJOR}${GRASS_VERSION_MINOR}
Also, you need to override MODULE_TOPDIR on the command line, e.g.:
make MODULE_TOPDIR=/usr/local/grass-6.4.0RC6
This is used to locate the *.make files, so setting in those files
won't work.
Alright. Tried it out by navigating into the folder with r.area. Here are
the results:
l...@pc19384:~/r.area sudo make MODULE_TOPDIR=/opt/grass/
mkdir -p /bin.i686-pc-linux-gnu
mkdir -p /dist.i686-pc-linux-gnu/include/grass
mkdir -p /dist.i686-pc-linux-gnu/lib
mkdir -p /dist.i686-pc-linux-gnu/bin
mkdir -p /dist.i686-pc-linux-gnu/etc
mkdir -p /dist.i686-pc-linux-gnu/driver
mkdir -p /dist.i686-pc-linux-gnu/driver/db
mkdir -p /dist.i686-pc-linux-gnu/fonts
gcc -I/dist.i686-pc-linux-gnu/include -O2 -DPACKAGE=\grassmods\
-I/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/main.o -c main.c
main.c:19:23: schwerwiegender Fehler: grass/gis.h: Datei oder Verzeichnis
nicht gefunden
Kompilierung beendet.
make: *** [OBJ.i686-pc-linux-gnu/main.o] Fehler 1
Unfortunately no improvement. Oh man...
The depressed
Daniel
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/Installing-r-area-tp5340139p5372689.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] Re: Installing r.area
Alright... I tried the following: l...@pc19384:~ svn checkout https://svn.osgeo.org/grass/grass-addons/raster/r.area/ Ar.area/main.c Ar.area/description.html Ar.area/Makefile Ausgecheckt, Revision 42981. l...@pc19384:~ cd r.area/ l...@pc19384:~/r.area make MODULE_TOPDIR=/opt/grass/ test -d OBJ.i686-pc-linux-gnu || mkdir -p OBJ.i686-pc-linux-gnu gcc -I/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include -O2 -DPACKAGE=\grassmods\ -I/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/main.o -c main.c main.c:19:23: schwerwiegender Fehler: grass/gis.h: Datei oder Verzeichnis nicht gefunden Kompilierung beendet. make: *** [OBJ.i686-pc-linux-gnu/main.o] Fehler 1 Same error message, it doesn't find what it's looking for. I looked at the error report and was a bit confused. Does this mean that there's no way around this other than compiling GRASS from source? Or is it perhaps possible to download the GRASS source and keep my distributed GRASS version and just use the source to compile r.area? Thanks, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Installing-r-area-tp5340139p5367915.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] Re: Installing r.area
Alright, sorry, was gone over the weekend. Now I'm back. Here some additional information. Concerning installing the add-on r.area with g.extension: (you mean the installation via g.extension isn't functional on your machine) Right, my mistake. After using g.extension to get r.area I get the following error: GRASS 6.4.0RC6 (DornbirnTest):~ g.extension r.area Fetching r.area from GRASS-Addons SVN (be patient)... Ar.area/main.c Ar.area/description.html Ar.area/Makefile Checked out revision 42954. Compiling r.area... test -d OBJ.i686-pc-linux-gnu || mkdir -p OBJ.i686-pc-linux-gnu gcc -I/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include -O2 -DPACKAGE=\grassmods\ -I/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/main.o -c main.c main.c:19:23: fatal error: grass/gis.h: No such file or directory compilation terminated. make: *** [OBJ.i686-pc-linux-gnu/main.o] Error 1 ERROR: Compilation failed, sorry. Please check above error messages. You see that grass/gis.h is missing which should be there in your binary installation in include/. Ah I just realise that it looks in /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include which is unlikely to exist on your machine, right? The path /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include/grass/ is on my machine, but the directory is empty. It was made on the Thursday, leading me to believe that g.extension made it. Concerning the include/ directory in my grass install, that apparently should be installed with the grass-devel package that I installed with my package manager: ...does /opt/grass/include/ contain anything? Does it have a subdirectory grass/ with a series of .h files? This are needed and not found above since there is something wrong with your paths. The directory /opt/grass/include/grass/ does indeed exist and it's got 89 *.h files and four folders. Maybe it's just looking at the wrong path? What reports echo $GISBASE in a GRASS session? It returns /opt/grass So it looks like my GISBASE is where my package manager installed it. At least that's where the relevant files are. Is it possible that you have two GRASS version installed? Don't think so. I deinstalled GRASS with the package manager and then tried to compile it (see previous entries), but it didn't work. Then I installed GRASS again with my package manager. Since the compilation failed, I don't think I've got two version. Plus, the error messages have stayed the same, both before and after my attempts. My present course of action: - Copied the contents of /opt/grass/include/grass/ (all the *.h files) temporarily to /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include/grass/ to see if g.extension can use them now. Then I tried g.extension r.area in the shell in a GRASS session. Result: Fetching r.area from GRASS-Addons SVN (be patient)... Ar.area/main.c Ar.area/description.html Ar.area/Makefile Ausgecheckt, Revision 42961. Compiling r.area... test -d OBJ.i686-pc-linux-gnu || mkdir -p OBJ.i686-pc-linux-gnu gcc -I/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include -O2 -DPACKAGE=\grassmods\ -I/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/main.o -c main.c make: *** Keine Regel vorhanden, um das Target »/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/lib/libgrass_gis.so«, benötigt von »/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/bin/r.area«, zu erstellen. Schluss. FEHLER: Compilation failed, sorry. Please check above error messages. So that's a different error than before. Here's the old one: GRASS 6.4.0RC6 (DornbirnTest):~ g.extension r.area Fetching r.area from GRASS-Addons SVN (be patient)... Ar.area/main.c Ar.area/description.html Ar.area/Makefile Checked out revision 42954. Compiling r.area... test -d OBJ.i686-pc-linux-gnu || mkdir -p OBJ.i686-pc-linux-gnu gcc -I/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include -O2 -DPACKAGE=\grassmods\ -I/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/main.o -c main.c main.c:19:23: fatal error: grass/gis.h: No such file or directory compilation terminated. make: *** [OBJ.i686-pc-linux-gnu/main.o] Error 1 ERROR: Compilation failed, sorry. Please check above error messages. The new area says it can't find the rule to make the target »/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/lib/libgrass_gis.so«, which is needed by »/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/bin/r.area«. - I looked in those directories for a main.o and a libgrass_gis.so, but they weren't there. Now I've deleted the contents of the directory that I'd temporarily copied so that my folders are back to the state they were in before I copied them. Thanks a bunch, by the way, to Marcello for
[GRASS-user] Re: Installing r.area
Hi ya'll! Alright, r.area still isn't functional, but I think we might be a few steps closer to the goal... I got the new and improved g.extension script from http://svn.osgeo.org/grass/grass/branches/releasebranch_6_4/scripts/g.extension/ and popped it as an executable into $GISBASE/scripts/, then changed the rights so that I can use it. I tried it again. Bad news is, it still didn't work. The good news is, my new error message is different from my last one! GRASS 6.4.0RC6 (DornbirnTest):~ g.extension r.area Fetching r.area from GRASS-Addons SVN (be patient)... Ar.area/main.c Ar.area/description.html Ar.area/Makefile Checked out revision 42954. Compiling r.area... test -d OBJ.i686-pc-linux-gnu || mkdir -p OBJ.i686-pc-linux-gnu gcc -I/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include -O2 -DPACKAGE=\grassmods\ -I/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/main.o -c main.c main.c:19:23: fatal error: grass/gis.h: No such file or directory compilation terminated. make: *** [OBJ.i686-pc-linux-gnu/main.o] Error 1 ERROR: Compilation failed, sorry. Please check above error messages. It's a lot shorter than the old error message because it didn't make directories, apparently. However, maybe I'm just really missing the point here, because the directories are still there from the last time I tried to build it. So much to that. As far as the other stuff is concerned: Markus Neteler wrote: Again, this needs GRASS to be properly packaged. Perhaps the include/ stuff was separated out into an extra grass-devel package for your distro? Not sure. My distro is OpenSUSE 11.3 and I have the grass-devel package installed. I used the packet manager to get it. I have found a directory /opt/grass/include/ - could that be it? Markus Neteler wrote: Please check if grass-dev (or whatever it is called in Ubuntu) is installed. Then retry. Yep. Thanks so much for the help! Best, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Installing-r-area-tp5340139p5358726.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] Re: Installing r.area
Hi everyone, Thanks for the responses. I'm really sorry that I'm struggling so much here, but... It just isn't working for me. Hamish: I tried building GRASS from source and failed miserably. I know, it must sound pathetic. I went through all of the packages that are required for GRASS - really all of them - following the instructions on http://grass.osgeo.org/wiki/Compile_and_Install. This was my process: - Downloaded all of the packages listed on the requirements page (http://grass.osgeo.org/grass64/source/REQUIREMENTS.html) with the package manager. Yes, some of them weren't there and I had to compile and install them from source. I managed that. - Made /usr/local/src/grass and gave myself rights to it. - Downloaded GRASS with svn checkout https://svn.osgeo.org/grass/grass/branches/develbranch_6 grass6_devel Had to do it as super user because I didn't have rights to /usr/local/src/. No problem, did it as a super user and then gave myself rights to it. - Navigated into /usr/local/src/grass6_devel/ and tried ./configure Results: The terminal spit out a bunch of things that found and then was unable to find PROJ.4. Here's the message: checking for location of External PROJ.4 includes... checking for proj_api.h... no configure: error: *** Unable to locate External PROJ.4 includes. Now, I know I have PROJ.4 because I installed it with the package manager. And it's still there. So... I'm confused. But this seems like a whole lot of trouble for just one little extension - I think the problem is more that I can't get the extension to compile. I ended up reinstalling GRASS with my packet manager. It works now. But I still don't have the extension. Since I didn't compile GRASS myself, I'm not sure exactly where the module top directory is. I've got opt/grass/etc/python/grass, for example, and a bunch of other grass folders (12 of them) and am not exactly sure where that is. It seems like it might be in /opt/grass/ but I'm not sure. That's definitely where my script directory is. However, when I navigate into ~/grass-addons/raster/r.area/ and type ./configure MODULE_TOPDIR=/opt/grass/ it says it can't find the file or folder ./configure. Also very strange. And all I want to do is compile this stupid add on! If I search my computer for any files/folders with grass* -dev* I don't find a thing. Anyway... Sadly, I haven't managed to come any further. Leonardo: Thanks for the tip. As you'll see above, I can't seem to use ./configure on the GRASS source... It always fails to find PROJ.4, even though PROJ.4 is installed, and the command locate PROJ.4 doesn't help either. Therefore I don't come any further. I've searched for any grass raster directory to move r.area to and it's not anywhere on my computer. *sigh* So it looks like I'm still miles away from getting this addon. I also tried it with g.extension. Here's the error I get: Fetching r.area from GRASS-Addons SVN (be patient)... Ar.area/main.c Ar.area/description.html Ar.area/Makefile Ausgecheckt, Revision 42949. Compiling r.area... mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/bin.i686-pc-linux-gnu mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include/grass mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/lib mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/bin mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/etc mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/driver mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/driver/db mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/fonts test -d OBJ.i686-pc-linux-gnu || mkdir -p OBJ.i686-pc-linux-gnu gcc -I/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include -O2 -DPACKAGE=\grassmods\ -I/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/main.o -c main.c main.c:19:23: fatal error: grass/gis.h: Datei oder Verzeichnis nicht gefunden compilation terminated. make: *** [OBJ.i686-pc-linux-gnu/main.o] Fehler 1 FEHLER: Compilation failed, sorry. Please check above error messages. Datei oder Verzeichnis nicht gefunden = Didn't find file or folder. It doesn't find grass/gis.h. I definitely DO have gcc, I also installed that with the packet manager. Just to be sure, I installed the newest gcc for every language that I could see in YaST. I'm at my wit's end... -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Installing-r-area-tp5340139p5347803.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] Re: Installing r.area
Thanks for the replies! I've tried it out and here are my responses to the suggestions: @ Markus - Downloaded the script and put it in my scripts folder, made it executable and made it assigned rights to myself. Just as a test I tried opening it as a GUI and, lo and behold, it worked. However, it couldn't find my add-on path, of course, when I tried to add r.area. So I went to the terminal and entered: export GRASS_ADDON_PATH?$GISBASE g.extension r.area Now things looked good. It did the following: Fetching r.area from GRASS-Addons SVN (be patient)... Ar.area/main.c Ar.area/description.html Ar.area/Makefile Checked out revision 42910. - Great, got the files needed. Then it started compiling: Compiling r.area... mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/bin.i686-pc-linux-gnu mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include/grass mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/lib mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/bin mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/etc mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/driver mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/driver/db mkdir -p /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/fonts test -d OBJ.i686-pc-linux-gnu || mkdir -p OBJ.i686-pc-linux-gnu gcc -I/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include -O2 -DPACKAGE=\grassmods\ -I/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/main.o -c main.c main.c:19:23: fatal error: grass/gis.h: No such file or directory compilation terminated. make: *** [OBJ.i686-pc-linux-gnu/main.o] Error 1 ERROR: Compilation failed, sorry. Please check above error messages. - So it looks like it was able to make a bunch of directories. I checked, they're there, new as of today. The entire directory of /usr/src/packages/ is new. However, GRASS wasn't able to compile. I checked for /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include/grass/gis.h since it seemed that it was looking for it and couldn't find it, and discovered that the directory /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu/include/grass/ is completely empty. Could that be the problem? I also tried using sudo g.extension r.area And got the usual error that I have to be in GRASS GIS to run the program. I didn't try starting GRASS as a super user because I don't want to do anything wrong and I also don't want it to install r.area only for super users. But that would be a nice way of loading add-ons, because it looks like I wouldn't have to have the source code all on my hard drive. Any idea why it's not working? @ Micha - Tried running it with g.extension (see above); it didn't work, so I tried to do the thing manually again. Entered svn checkout https://svn.osgeo.org/grass/grass-addons/ grass-addons to get the source codes. It worked and all the source codes were downloaded to my home directory in the folder grass-addons. Then I navigated into the directory ~/grass-addons/raster/r.area/ and entered the command ./configure This is similar to last time; last time, I also had been inside the directory when I tried the commands. But I thought hey, maybe I'd copied the source codes wrong. Sadly, that doesn't seem to be the problem; just like last time, I got the message bash: ./configure: No such file or directory I then tried it as super user. Same problem. Any other ideas? Thanks a lot again for the help, everyone! Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Installing-r-area-tp5340139p5341684.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] Re: Installing r.area
Phew, I didn't think it'd be so complicated ;) Sorry! And the question mark that should be an equals sign was a typo as I was typing that line over (the other stuff I copy-pasted, but I'm a fast typer that's lazy with the mouse so I didn't do it for those two lines). As far as the binaries are concerned, in that case I got the files by running g.extension r.area in the terminal within a GRASS session. I'd downloaded GRASS from the OpenSUSE Geo-Repository (URL: http://download.opensuse.org/repositories/Application:/Geo/openSUSE_11.3/). The binaries had later on were obtained with the command svn checkout https://svn.osgeo.org/grass/grass-addons/ grass-addons performed in the terminal outside a GRASS session. Best, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Installing-r-area-tp5340139p5342221.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] Re: Online database with GRASS
Thanks! Believe it or not, that really does help me quite a bit. I also got some direct emails from some other forum users with tips on books and stuff. I think this'll at least help me to start finding out what I need to find out :) -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Online-database-with-GRASS-tp5324371p5339365.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] Re: Online database with GRASS
Sure thing... I'll wait till the thing runs and then post the summary. -Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Online-database-with-GRASS-tp5324371p5339425.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] Installing r.area
Hi all, I'm trying to use r.area. For that I need to, of course, install it. As I've never compiled and installed anything before, these questions might be kind of stupid... So I apologize. Yes, I've read http://grass.osgeo.org/wiki/Compile_and_Install#Compiled_C_modules but although I tried what it asked me to do I didn't get the results I expected. Here is what I tried on OpenSUSE 11.3, 32 bit: 1. Went to the GRASS AddOns Wiki-page (http://grass.osgeo.org/wiki/GRASS_AddOns) and tried to add the various the SVN repository to my repository directories in Yast (the OpenSUSE system tool). Didn't work, which I think is one of those things that everybody'll say duh about, but when I say duh in this case, it comes from my heart because I'm dumb :P 2. Found the source codes of r.area (consisting of description.html, main.c and Makefile), copied their content into files with matching names in my home directory 3. Followed the instructions on http://grass.osgeo.org/wiki/Compile_and_Install to compile and install C add-ons (under the assumption that that's correct for r.area - sure looks like it is). Got the following results: - Hoping that the add-on was a binary (I know, I know...), I tried compiling it with make MODULE_TOPDIR=/usr/bin/grass64/ Result: Makefile:11: /usr/bin/grass64//include/Make/Module.make: Not a directory make: *** No rule to make target `/usr/bin/grass64//include/Make/Module.make'. Stop. Okay. The computer spoke Latin to me. Noticing that it's got a path with two slashes right after another after my input, I thought that perhaps it wasn't finding the proper directory and tried it without the slash at the end: make MODULE_TOPDIR=/usr/bin/grass64 Result: Makefile:11: /usr/bin/grass64/include/Make/Module.make: Not a directory make: *** No rule to make target `/usr/bin/grass64/include/Make/Module.make'. Stop. Alright. No more double slash, but for all intents and purposes the same message. So I then tried setting up an alias, not because I understand what that means but because it was also suggested on the page: alias gmake64='make MODULE_TOPDIR=/usr/bin/grass64/' Computer seemed to like this and gave no reply. However, the next line was ready, so I guess the alias was set up. Then I tried installing it: make MODULE_TOPDIR=/usr/bin/grass64/ install Result: Makefile:11: /usr/bin/grass64//include/Make/Module.make: Not a directory make: *** No rule to make target `/usr/bin/grass64//include/Make/Module.make'. Stop. Obviously I'm doing something wrong. Thinking that I might be dealing with source code that still needed to be prepared, I entered: ./configure To which my computer replied: bash: ./configure: No such file or directory No luck. Can anybody help me? I know this is a relatively simple question, but I don't seem to be able to make anything of the online help texts. Thanks!! Best, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Installing-r-area-tp5340139p5340139.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] Re: Online database with GRASS
Hi... Just in case the question got lost, since it's been a few days since I asked, here's my old post. I haven't gotten any replies yet :( Hi all, My company's looking at making our geodata available online using an OpenStreetMaps map and some kind of geodatabase that the OSM interface accesses to display polygons with various attributes. The user should be able to click on the polygon and read the attributes. Now, I know the online interface is not the topic for this forum, but the whole thing is pretty challenging for me and the databank with GRASS is threatening enough. Does anybody have any experience with this type of project? I know e.g. that GRASS can work with DBF, SQLite, PostgreSQL, MySQL RDBMS, MySQL embedded databases, and UnixODBC. As a complete newbie to any kind of advanced database systems, I don't know the differences there. What would you all suggest? We're looking at a large amount of data, several ten thousand polygons with associated with about 10 attributes each. What would be the best option there and how would one set it up? Any help, suggestions or... Pretty much any communication regarding this matter would make me a very happy guy :) Thanks a lot in advance! Best, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Online-database-with-GRASS-tp5324371p5335006.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] Online database with GRASS
Hi all, My company's looking at making our geodata available online using an OpenStreetMaps map and some kind of geodatabase that the OSM interface accesses to display polygons with various attributes. The user should be able to click on the polygon and read the attributes. Now, I know the online interface is not the topic for this forum, but the whole thing is pretty challenging for me and the databank with GRASS is threatening enough. Does anybody have any experience with this type of project? I know e.g. that GRASS can work with DBF, SQLite, PostgreSQL, MySQL RDBMS, MySQL embedded databases, and UnixODBC. As a complete newbie to any kind of advanced database systems, I don't know the differences there. What would you all suggest? We're looking at a large amount of data, several ten thousand polygons with associated with about 10 attributes each. What would be the best option there and how would one set it up? Any help, suggestions or... Pretty much any communication regarding this matter would make me a very happy guy :) Thanks a lot in advance! Best, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Online-database-with-GRASS-tp5324371p5324371.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] Re: r.out.gdal output size vs input size
Hi Espen, r.out.gdal uses the current region settings. Is it possible that you've set a high region resolution? Then your GeoTIFF is probably being resampled to a higher resolution, causing the file to be a lot bigger. Best, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/r-out-gdal-output-size-vs-input-size-tp5291740p5291763.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] Re: r.out.gdal output size vs input size
In my opinion, the easiest way would be to set the region according to your GeoTIFF. You can do that with g.region using the parameter rast=your_raster More here: http://grass.itc.it/gdp/html_grass64/g.region.html If you set the region to your GeoTIFF, the extent and resolution of the region will match its original specifications so your output file should be ~ the same size as the original :) -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/r-out-gdal-output-size-vs-input-size-tp5291740p5291817.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] Script Directory in Ubuntu
Hi all, I know, this is an extremely rudimentary question, but please bear with me: I developed a bunch of scripts that I need on OpenSUSE. I was able to call them up in GRASS by typing in their name. They were stored in the directory: /opt/grass/scripts/ Recently I started working on a second computer using Ubuntu. I installed GRASS without any problems (although I can't get the wxpython GUI to start, but that's a problem to deal with later) and can't find where to put my scripts. I've found a number of scripts in the path: /usr/local/grass-6.4.0RC6/scripts/ I've copied my scripts into that directory and set ownership rights to myself, my group. The scripts are executable. Still, when I try to call e.g. a simple shell script from the tcl/tk GUI I get the following message: couldn't execute r.script: no such file or directory After that, a window pops up named dialog0. It's empty. The folder /opt/ is empty on the Ubuntu computer - dir as sudo also tells me it's empty, so it's got nothing to do with rights... Anybody have a tip? I'd be really grateful, the Ubuntu computer has a much better processor and my other computer would be a little challenged to keep up with it. Best, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Script-Directory-in-Ubuntu-tp5292424p5292424.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] Re: Script Directory in Ubuntu
Hi Stephen, Great! It worked. Thanks a bunch :) The script sounds good, thanks in advance for that. I'm so happy I can use this other computer, this'll reduce the computing time by a couple days... Best, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Script-Directory-in-Ubuntu-tp5292424p5292646.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] Re: Script Directory in Ubuntu
Thanks a bunch! -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Script-Directory-in-Ubuntu-tp5292424p5292826.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] Re: Define Global Variables and use them in a Python script
Hi Kim, I'm no expert, but I'd suggest not reading them into GRASS as global variables but defining them as global variables within the script in Python. You could then have Python read the variables from a file and set them within the environment of the script, like with a config file. Here's some interesting stuff about reading from files in Python: http://www.java2s.com/Code/Python/File/File-Read.htm http://docs.python.org/tutorial/inputoutput.html Hope that helps! Sorry that I couldn't find a better tutorial, but there's tons of stuff out there and the stuff I just posted is probably really basic for you anyway ;) Best, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Define-Global-Variables-and-use-them-in-a-Python-script-tp5256628p5256687.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] Cost Distance Analysis
Hi all, Does anybody know how to perform a cost-distance analysis? I'm planning a street and have assigned various costs to different surfaces in my planning area. As I understand it, I need to perform the following steps: 1. r.cost using the starting point to generate a cost map for each pixel 2. r.walk to generate a raster with cumulative movement costs for each pixel from the point of origin 3. r.drain to generate the road My problem is, I don't want to model drainage; I want to find the route with the lowest costs possible to connect two points. Is there a way to calculate the path of least resistance from my origin point to a goal point? I've thought of using r.cost with two different points and then performing r.drain to connect the two. But would that work? It seems like r.drain produces paths that end at the point with the lowest cost, but that's not my goal - it gives me no control over where the street ends. Thanks a bunch for the help! Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Cost-Distance-Analysis-tp5208474p5208474.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] Re: r.lake - starting from shell problem
Hey there, Sorry I don't have an answer, but maybe it contributes to the understanding of the problem: I've also had this exact same error message when trying to run my own python scripts from shell under Windows. The scripts seem to be fine, but GRASS was unable to use them. Somebody posted what I believe might be a solution, if the problem's python-based, but I haven't tried it because I rewrote it as a shell script using Linux. Here's the thread: http://osgeo-org.1803224.n2.nabble.com/Problem-with-running-Python-script-in-GRASS-td5007296.html#a5007296 -Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/r-lake-starting-from-shell-problem-tp5035268p5040119.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] Re: Problem with running Python script in GRASS
Hi everyone, Just a quick status update: Being so new to the whole GRASS scene (and the Open Source scene in the first place) but wanting very much to work with these systems, I installed Linux and had the difficulties I described above. As an answer to the question if anything else happened when I tried to run a Python script using GRASS 6.4: I listed everything that happened, sadly there was no further information that the system gave me. I've now learned a little bit about writing shell scripts and have successfully translated the Python script into the shell format. Now it seems to be running without problems. It's quite a large computation, but right now it's going great in Linux. My other question, though, is how to get newer versions of GRASS. I also considered going over to GRASS 7, it seems to be planned to deal a lot better with Python, but wasn't able to find it on the official GRASS page. Did I just overlook it, or is it available through some other source? I found some sources in the Internet but didn't quite trust them. Best, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Problem-with-running-Python-script-in-GRASS-tp5007296p5018865.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] Re: Problem with running Python script in GRASS
Hello, Thanks for the answer. Yeah, that's really strange. Now I've installed Linux on top of Windows and tried running it there. I seem to get a step further. Rather than spitting out that strange error message I get the following: child process exited abnormally And another window pops up, titled dialog0. Nothing more to report other than that... But now that I'm in Linux it should work better, right? Does anybody have a fix or an idea of what it could be? Thanks so much! The desperate Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Problem-with-running-Python-script-in-GRASS-tp5007296p5011558.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] Problem with running Python script in GRASS
Hello fellow GRASS users!
I'm sure this is a very simple problem but I'm having a really difficult
time with it... After searching for the solution for several days I'm on the
end of my whits and am really needing this script to get working. This is
the problem:
I've written a Python script, doing my best to use the Python I know and
reverse engineer the python scripts I found in the Internet. As far as I can
tell, the script should be fine, although I naturally can't execute it
independently. My goal is to run it as a command from inside GRASS so that
the user can input the parameters through the GUI. I think GRASS recognizes
that the script is there but isn't able to generate the GUI.
Here's the script:
__
#
# MODULE: r.solar
# AUTHOR(S):Daniel Lee
# PURPOSE: Runs r.sun for a year using different inputs for each month
# COPYRIGHT:(C) 2010 by Daniel Lee
#
# This program is free software under the GNU General Public
# License (=v2). Read the file COPYING that comes with GRASS
# for details.
#
#
#%Module
#% label: Solar modeling tool.
#% description: Conducts a solar analysis for a year using empirical inputs
for each month.
#% keywords: raster
#%End
#%Option
#% key: elevin
#% type: string
#% gisprompt: old,cell,raster
#% description: Name of input elevation map (unit = meters)
#% required : yes
#% guisection: Required inputs
#%End
#%Option
#% key: aspect
#% type: string
#% gisprompt: old,cell,raster
#% description: Name of input aspect map (decimal degrees)
#% required : yes
#% guisection: Required inputs
#%End
#%Option
#% key: slopein
#% type: string
#% gisprompt: old,cell,raster
#% description: Name of input slope map (decimal degrees)
#% required : yes
#% guisection: Required inputs
#%End
#%Option
#% key: linkein
#% type: string
#% gisprompt: old,cell,raster
#% description: Name of input Linke atmospheric turbidity coefficient map
#% required : no
#% guisection: Optional inputs
#%End
#%Option
#% key: albedo
#% type: string
#% gisprompt: old,cell,raster
#% description: Name of input albedo coefficient map
#% required : no
#% guisection: Optional inputs
#%End
#%Option
#% key: mapset
#% type: string
#% description: Name of the mapset containing solar data
#% required : yes
#% guisection: Required inputs
#%End
#%Flag
#% key: z
#% description: Generate map of sunlight insolation time (h)
#% guisection: Output options
#%End
#%Flag
#% key: y
#% description: Generate map of reflected radiation (Wh/m2)
#% guisection: Output options
#%End
import sys
import os
import string
import grass.script as grass
def main():
elevin = options['elevin']
aspect = options['aspect']
slopein = options['slopein']
linkein = options['linkein']
albedo = options['albedo']
mapset = @ + options['mapset']
reflected = flags['y']
duration = flags['z']
step = 0.16
for day in range(365):
day += 1
# Define month
if day == 1:
month = 01 + mapset
elif day == 32:
month = 02 + mapset
elif day == 60:
month = 03 + mapset
elif day == 91:
month = 04 + mapset
elif day == 121:
month = 05 + mapset
elif day == 152:
month = 06 + mapset
elif day == 182:
month = 07 + mapset
elif day == 213:
month = 08 + mapset
elif day == 244:
month = 09 + mapset
elif day == 274:
month = 10 + mapset
elif day == 305:
month = 11 + mapset
elif day == 335:
month = 12 + mapset
# Define coefficients!
coefbh = 'coefbh' + month
coefdh = 'coefdh' + month
if not grass.find_file(elevin)['file'] or not
grass.find_file(aspect)['file'] or not grass.find_file(slopein)['file'] or
not grass.find_file(coefbh)['file'] or not grass.find_file(coefdh)['file']:
grass.fatal(_(Raster map %a not found.) % input
# Define outputs!
beam_rad = 'beam' + str(day)
diff_rad = 'diffuse' + str(day)
glob_rad = 'global' + str(day)
if duration and reflected:
insol_time = 'insol_time' + str(day)
refl_rad = 'reflected' + str(day)
grass.run_command('r.sun', flags = 's', elevin = elevin, aspin =
aspin, slopein = slopein, linkein = linkein, albedo = albedo, coefbh =
coefbh, coefdh = coefdh, beam_rad = beam_rad, insol_time = insol_time,
diff_rad = diff_rad, refl_rad = refl_rad, glob_rad = glob_rad, day = day,
step = step)
elif duration and not reflected:
insol_time = 'insol_time' + str(day)
grass.run_command('r.sun', flags = 's', elevin = elevin, aspin =
aspin, slopein = slopein, linkein = linkein, albedo = albedo, coefbh =
coefbh, coefdh = coefdh, beam_rad = beam_rad, insol_time = insol_time,
diff_rad = diff_rad, glob_rad = glob_rad, day = day, step = step)
elif reflected and not duration:
refl_rad = 'reflected' + str(day)
