Re: [GRASS-user] map display query and layers
W dniu 03.10.2016 o 23:18, Markus Neteler pisze: On Mon, Oct 3, 2016 at 7:12 PM, Dave Roberts <drobe...@montana.edu> wrote: Hi Markus, Given your kind offer I elected to try and compile GRASS again. This time I was successful (after a few false starts). The primary problem was python confusion, where arch linux assumes python3 as the default, and I had not done the symbolic links correctly to redicrect to python2. After that ./configure \ --without-freetype \ --with-postgress \ --with-readline worked successfully. I'm now testing GRASS-7.0.5. Hi Dave, My PKGBUILD may help: https://gitlab.com/tutturu/grass7_pkgbuild/blob/master/PKGBUILD. Advertised on https://grass.osgeo.org/download/software/linux/. Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Grass profile problem in Ubuntu 16.04 LTS 64 bit
https://trac.osgeo.org/grass/ticket/2558 discusses this issue in more detail. I have updated the ticket according to my knowledge. Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Grass profile problem in Ubuntu 16.04 LTS 64 bit
W dniu 05.07.2016 o 04:43, Do Thi Hang pisze:
> Please find below the error I get when I try to use profile
>
>
> Traceback (most recent call last):
> File "/usr/lib/grass70/gui/wxpython/mapdisp/frame.py",
> line 1043, in OnProfile
>
> self.Profile(rasters=rasters)
> File "/usr/lib/grass70/gui/wxpython/mapdisp/frame.py",
> line 1051, in Profile
>
> controller=self.profileController)
> File "/usr/lib/grass70/gui/wxpython/wxplot/profile.py",
> line 52, in __init__
>
> BasePlotFrame.__init__(self, parent=parent, size=size,
> **kwargs)
> File "/usr/lib/grass70/gui/wxpython/wxplot/base.py", line
> 88, in __init__
>
> self.client = plot.PlotCanvas(self)
> File "/usr/lib/python2.7/dist-
> packages/wx-3.0-gtk2/wx/lib/plot.py", line 598, in __init__
>
> self.HandCursor = wx.Cursor(Hand.GetImage())
> File "/usr/lib/python2.7/dist-
> packages/wx-3.0-gtk2/wx/_gdi.py", line 1510, in __init__
>
> _gdi_.Cursor_swiginit(self,_gdi_.new_Cursor(*args,
> **kwargs))
> TypeError
> :
> Required argument 'type' (pos 2) not found
Same problem on Arch Linux where wxPython 2.8 package requires wxPython
3 package. Thus one can't have wxPython 2.8 installed alone, while GRASS
wxgui defaults to wxPython 3 in case both 3 and 2.8 are installed.
Several months ago Glynn wrote
(https://lists.osgeo.org/pipermail/grass-dev/2014-October/071122.html):
> In theory, code which uses the wxPython library is supposed to use
> something like:
>
>import wxversion
>wxversion.select('2.8')
>import wx
Question to GRASS team: would there be any problem with adding the above
wxversion selector to all wxgui code that is not comaptible with
wxPython 3? Further in the thread Glynn suggested:
> One option would be to replace "import wx" with "import grass.wx",
> where the grass.wx module is just
>
>wxversion.select('2.8')
>from wx import *
>
> The other option is to only add wxversion.select() to top-level
> modules, i.e. those which are executed as scripts rather than imported
> as modules.
Maciek
--
Maciej Sieczka
http://www.sieczka.org
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.out.ntv2 published
Hi, I have just published r.out.ntv2 - a GRASS 7 addon, which wraps i.group and r.out.gdal for convenient NTv2 datum transformation grid export. I hope someone will find it usefull. Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Topo to Raster
W dniu 01.04.2014 12:37, Martin Landa pisze: found code in Addons [1], btw, link at [2] doesn't work Corrected that. [1] http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.surf.nnbathy/r.surf.nnbathy [2] http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#r.surf.nnbathy -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] surface interpolation with breaklines
W dniu 03.02.2014 18:55, Vincent Bain pisze: Would anyone help me figure out how I could perform this conversion, given that I would rely on a linear interpolation method within triangles faces (the result would be close to what r.surf.nnbathy does, except nor this addon does support breaklines). Can you rasterize the output triangle 3d sides, and use that as an input for r.surf.nnbathy? r.surf.nnbathy should create a structure similar to v.triangle product, since both use the same Shewchuk's triangle algorithm underneath. You may try if using only the triangle node vertices alone wouldn't suffice, and extracting those from a 3d vector map should be very easy (v.to.points -n ?). Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] surface interpolation with breaklines
W dniu 09.02.2014 13:17, Vincent Bain pisze: Perhaps a wiser solution would be to v.to.point (i) contour lines, (ii) breaklines, then merge them in a single raster an run r.surf.nnbathy. There is no need to v.to.points isolines before rasterizing them for nnbathy. Unless you want to generalize the contour lines on purpose, e.g. to minimize the staircase artifacts in the output raster map. As to breaklines, if these are linear features that indicate surface discontinuity and have no elevation attribute, nnbathy has no use of them (which you know already). If they are vector isolines, just rasterize them straight away. If these are vector 3d lines, you'd need to rasterize them interpolating their elevation at each cell of the output raster map, which v.to.rast can't do. At least it couldn't a few years ago when I tried it. This could probably be approximated with something like v.to.points -v -i dmax=raster DEM resolution + v.to.rast, but that's suboptimal. Finally I found on the web a custom solution based on a nice little python script named tin2raster, you can find it at the address bellow. I tried to contact Antonio, the guy who wrote it, but did not get a reply : http://digilander.libero.it/antonioall/python_tin2raster.html That tool utilizes Vect_tin_get_z (http://grass.osgeo.org/programming6/tin_8c.html), which claims to be able to perform such interpolation, not only along a linear 3d feature, but on faces as well. Nice. I haven't tried the tool, but it seems it does exactly what you are after here. In my case it was very efficient and fast. Do you think it could represent a potential new option that could be applied to v.to.rast in order to handle 3d vector areas ? I don't know, but I'd like v.to.rast to provide such feature too. Le dimanche 09 février 2014 à 12:53 +0100, Maciej Sieczka a écrit : W dniu 03.02.2014 18:55, Vincent Bain pisze: Would anyone help me figure out how I could perform this conversion, given that I would rely on a linear interpolation method within triangles faces (the result would be close to what r.surf.nnbathy does, except nor this addon does support breaklines). Can you rasterize the output triangle 3d sides, and use that as an input for r.surf.nnbathy? r.surf.nnbathy should create a structure similar to v.triangle product, since both use the same Shewchuk's triangle algorithm underneath. You may try if using only the triangle node vertices alone wouldn't suffice, and extracting those from a 3d vector map should be very easy (v.to.points -n ?). -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] [GRASS-dev] releasebranch_6_4 Arch PKGBUILD - review
I have uploaded PKGBUILDs for releasebranch_6_4, develbranch_6 and trunk to AUR [1]. Latest 6.4 RC comes soon. They can be co-installed. Any improvement suggestions are welcome. Can I maintain them in GRASS SVN (each in its branch) and advertise on http://grass.osgeo.org/download/software/linux/? Maciek [1] https://aur.archlinux.org/packages/?SeB=mK=czk W dniu 13.01.2013 01:03, Maciej Sieczka pisze: Hi, I'm attaching my Arch PKBUILD for GRASS releasebranch_6_4. Can you guys please have a good look if there is anything wrong, missing, could be done better/neater (including comments too)? I'm going to come up with similar PKBUILDs for develbranch_6, trunk and most recent 6.4 RC as well, and publish them all on AUR (https://aur.archlinux.org), so that it's easy to have multiple, uniform GRASS versions installed in parallel on Arch. There are a couple of GRASS PKBUILDs in AUR already, but some of them conflict each other, have different sets of build options enabled and they mess with the source more than really needed. BTW: Will the TK 8.6 fix http://trac.osgeo.org/grass/ticket/1843#comment:8 be applied to releasebranch_6_4 and releasebranch_6? Maciek ___ grass-dev mailing list grass-...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] releasebranch_6_4 Arch PKGBUILD - review
Hi, I'm attaching my Arch PKBUILD for GRASS releasebranch_6_4. Can you guys please have a good look if there is anything wrong, missing, could be done better/neater (including comments too)? I'm going to come up with similar PKBUILDs for develbranch_6, trunk and most recent 6.4 RC as well, and publish them all on AUR (https://aur.archlinux.org), so that it's easy to have multiple, uniform GRASS versions installed in parallel on Arch. There are a couple of GRASS PKBUILDs in AUR already, but some of them conflict each other, have different sets of build options enabled and they mess with the source more than really needed. BTW: Will the TK 8.6 fix http://trac.osgeo.org/grass/ticket/1843#comment:8 be applied to releasebranch_6_4 and releasebranch_6? Maciek -- Maciej Sieczka http://www.sieczka.org grass64.PKGBUILD.sh Description: Bourne shell script ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GRASS workshop during a conf. in Wroclaw, Poland, May
There will be a GRASS workshop (alongside with a QGIS and OpenLayers ones) and several presentations regarding FOSS4G, during a conference Wolne Oprogramowanie w Geoinformatyce in Wrocław, Poland, 12-13.05.2011. More information (going to appear) on http://www.gislab.up.wroc.pl/wogis2011. Cheers, Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Remove duplicate points
W dniu 02.02.2011 23:07, Zem LeRoi pisze: Hello, I have GPS data where multiple points have the same coordinates. I would like to simplify the file and erase any duplicates. I have tried using v.clean: v.clean input=kpr1 output=clean1 type=point tool=rmdupl The command completes ok, but when I look inside the resulting file, it has the same number of points. Could anyone suggest what the reason might be? Do the points have identical coordinates really? Check with v.out.ascii (maybe using dp greater then default 8). Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: r.mapcalc -- 3 maps
W dniu 16.01.2011 18:29, Gabriele N. pisze: A and B do not overlap, and I should take the values of A and B also (always). Then.in areas that are empty, I would then put the values of C. I tried withr.mapcalc output = if((isnull(a)),b,if(isnull(b),a),c) but I lose the values of C This should work: r.mapcalc 'd=if(isnull(a),if(isnull(b),c,b),a)' If map a is null check if b is null too. If so, use c; if not - use b. Otherwise use a. Or: r.mapcalc 'd=if(isnull(a|||b),c,if(isnull(a),b,a))' If both a and b are null, use c; if a is null use b, otherwise use a. Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] leftover node in v.digit
W dniu 08.01.2011 06:01, Shane Litherland pisze: Hi Maris, Have braved my first attempt at filing a bug report, and appear to have put enough together to generate a ticket Ticket #1256 leftover node when deleting boundaries vertex-by-vertex hope it's of help... :-) Shane, 6.4.0 RC6 is several months old. Please try installing and veryfing your issues against the newest stable release candidate - http://grass.osgeo.org/grass64/binary/linux/snapshot/. If impossible, please at least try the 6.4.0 final Ubuntu package from https://launchpad.net/~ubuntugis/+archive/ubuntugis-unstable/. Maciek -shane. On Fri, 2011-01-07 at 12:49 +0200, Maris Nartiss wrote: Open a bug report with exact step-by-step how to reproduce this issue. http://trac.osgeo.org/grass Maris. 2011/1/7, Shane Litherlandlitherland-f...@bigpond.com: Hi again, another little thing I found by accident, If digitising boundaries, then using 'remove vertex' to delete some of a boundary, vertex-by-vertex... If I kept going and removed all the vertexes (instead of the correct way of using 'delete point/line/boundary'), it was possible to end up with some leftovers.. I could see a lone red cross on the v.digit screen (meaning, node(1 line) ) that I could not select to move, add, delete, anything... no matter what my zoom. This errant node did not show in the GRASS map view of the vector in question, only in v.digit. Using v.clean 'found' and removed this errant node (using the rmline option) and I checked the vector info of the 'dirty' versus 'clean' vectors to see nothing else had been upset. It was an accident, I thought I'd selected the 'delete' tool... but interesting, nonetheless ;-) regards, shane. ___ 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 -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] leftover node in v.digit
W dniu 08.01.2011 06:01, Shane Litherland pisze: Hi Maris, Have braved my first attempt at filing a bug report, and appear to have put enough together to generate a ticket Ticket #1256 leftover node when deleting boundaries vertex-by-vertex hope it's of help... :-) 2011/1/9, Maciej Sieczka msiec...@sieczka.org: Shane, 6.4.0 RC6 is several months old. Please try installing and veryfing your issues against the newest stable release candidate - http://grass.osgeo.org/grass64/binary/linux/snapshot/. If impossible, please at least try the 6.4.0 final Ubuntu package from https://launchpad.net/~ubuntugis/+archive/ubuntugis-unstable/. W dniu 09.01.2011 19:00, Maris Nartiss pisze: Hello Maciek, it wouldn't change a lot, as this bug is also present in 6.5. It's just a corner case. Nobody has been doing such strange thing before and thus it has went unnoticed for years. Shane, thanks for report. I will fix it someday (hopefully for 6.4.2). Shane, FWIW - I was referring to reporting an testing habbits in general :). Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] leftover node in v.digit
W dniu 09.01.2011 21:22, Maris Nartiss pisze: Huh. Then You are right. (Too much of snow digging today to be able to park my car) Still, I had free 30min and I fixed issue in 6.5. :) Great! Thanks. Maciek Maris. 2011/1/9, Maciej Sieczkamsiec...@sieczka.org: W dniu 08.01.2011 06:01, Shane Litherland pisze: Hi Maris, Have braved my first attempt at filing a bug report, and appear to have put enough together to generate a ticket Ticket #1256 leftover node when deleting boundaries vertex-by-vertex hope it's of help... :-) 2011/1/9, Maciej Sieczkamsiec...@sieczka.org: Shane, 6.4.0 RC6 is several months old. Please try installing and veryfing your issues against the newest stable release candidate - http://grass.osgeo.org/grass64/binary/linux/snapshot/. If impossible, please at least try the 6.4.0 final Ubuntu package from https://launchpad.net/~ubuntugis/+archive/ubuntugis-unstable/. W dniu 09.01.2011 19:00, Maris Nartiss pisze: Hello Maciek, it wouldn't change a lot, as this bug is also present in 6.5. It's just a corner case. Nobody has been doing such strange thing before and thus it has went unnoticed for years. Shane, thanks for report. I will fix it someday (hopefully for 6.4.2). Shane, FWIW - I was referring to reporting an testing habbits in general :). Maciek -- Maciej Sieczka http://www.sieczka.org -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] lots of The application failed to initialize properly in 6.4.0 on Windows
W dniu 21.09.2010 10:36, Glynn Clements pisze: Maciej Sieczka wrote: Dependency Walker http://www.dependencywalker.com/ says: --- Error: The Side-by-Side configuration information for c:\program files\grass-64\extralib\LIBPQ.DLL contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001). Error: At least one required implicit or forwarded dependency was not found. [ ? ] MSVCR80.DLL Error opening file. The system cannot find the file specified (2). [D? ] IESHIMS.DLL Error opening file. The system cannot find the file specified (2). [D? ] WER.DLL Error opening file. The system cannot find the file specified (2). Apparently, IESHIMS.DLL and WER.DLL are specific to Vista and later. They shouldn't be required (and probably won't even work) on other platforms, but Dependency Walker complains about any DLLs which it can't find, regardless of whether they're actually required. All of my GRASS executables cause Dependency Walker to complain about a missing MSJAVA.DLL (required by MSHTML.DLL), but they still work. The missing MSVCR80.DLL would be a real problem. This file is part of the Visual Studio 2005 runtime. People often forget to bundle the MSVCRxx.DLL files because so many systems already have them (although they aren't part of the OS install), so the error is only discovered when installing on a relatively clean system. I have scratch-installed Windows XP SP3, fetched all updates, installed GRASS 6.4.0. As expected, many commands crashed with an The application failed to initialize properly error. According to Dependency Walker, missing were MSVCR80.DLL, MSVCR90.DLL, IESHIMS.DLL and WER.DLL. Installing MS Visual C++ 2008 SP1 Redistributable Package [1] and the 2005 one [2] fixed the issue. IESHIMS.DLL and WER.DLL are still missing but it doens't do any harm to my GRASS instalation, AFAICT. Can Win GRASS installer ship MSVCR80.DLL and MSVCR90.DLL? [1] http://www.microsoft.com/downloads/en/confirmation.aspx?FamilyID=a5c84275-3b97-4ab7-a40d-3802b2af5fc2 [2] http://www.microsoft.com/downloads/en/confirmation.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647 -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] lots of The application failed to initialize properly in 6.4.0 on Windows
W dniu 14.09.2010 15:46, Maciej Sieczka pisze: W dniu 14.09.2010 00:59, Glynn Clements pisze: Maciej Sieczka wrote: Ideas, anybody? Another possibility is an incompatible version of one of the (many) libraries which GDAL uses. Do the GDAL utilities (gdalinfo etc) work? They don't. Same error. Dependency Walker http://www.dependencywalker.com/ says: --- Error: The Side-by-Side configuration information for c:\program files\grass-64\extralib\LIBPQ.DLL contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001). Error: At least one required implicit or forwarded dependency was not found. [ ? ] MSVCR80.DLL Error opening file. The system cannot find the file specified (2). [D? ] IESHIMS.DLL Error opening file. The system cannot find the file specified (2). [D? ] WER.DLL Error opening file. The system cannot find the file specified (2). --- Full output attached (g.region.txt.bz2). I found a copy of MSVCR80.DLL in C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd and copied it to C:\WINDOWS\system. This got rid of that one missing dependency, still the other two remain. And there is no trace of them on my system. By google they seem to be related to some MS Movie Maker issue (I haven't tried searching hard I admit). Time to reinstall Windows :)? Maciek -- Maciej Sieczka http://www.sieczka.org g.region.txt.bz2 Description: application/bzip ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] lots of The application failed to initialize properly in 6.4.0 on Windows
W dniu 14.09.2010 00:59, Glynn Clements pisze: Maciej Sieczka wrote: Ideas, anybody? Another possibility is an incompatible version of one of the (many) libraries which GDAL uses. Do the GDAL utilities (gdalinfo etc) work? They don't. Same error. -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] lots of The application failed to initialize properly in 6.4.0 on Windows
W dniu 11.09.2010 21:38, Glynn Clements pisze: Maciej Sieczka wrote: Lots of commands (e.g. g.proj, g.region, g.remove) That list looks suspiciously like programs which use GDAL. You might want to check whether there are other versions of GDAL on your system, particularly if they are in %PATH%. Thanks for the hint. No trace of GDAL in system and user variables AFAICT. My PATH on cmd GRASS concole: GRASS 6.4.0 (demolocation) echo %PATH% C:\Program Files\GRASS-64\bin;C:\Program Files\GRASS-64\lib;C:\Program Files\GRASS-64\tcl-tk\bin;C:\Program Files\GRASS-64\sqlite\bin;C:\Program Files\GRASS-64\gpsbabel;C:\Program Files\GRASS-64\extrabin;C:\Program Files\GRASS-64\extralib;C:\Program Files\GRASS-64\msys\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem PATH on msys GRASS console: GRASS 6.4 echo $PATH /C/Program Files/GRASS-64/lib:/C/Program Files/GRASS-64/bin:/C/Program Files/GRASS-64/scripts:/C/Program Files/GRASS-64/tcl-tk/bin:/C/Program Files/GRASS-64/sqlite/bin:/C/Program Files/GRASS-64/gpsbabel:/C/Program Files/GRASS-64/extrabin:/C/Program Files/GRASS-64/extralib:.:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem I have these 2 GDAL libs installed there: GRASS 6.4 ls /c/Program\ Files/GRASS-64/extralib/*gdal* /c/Program Files/GRASS-64/extralib/gdal15.dll /c/Program Files/GRASS-64/extralib/gdal16.dll Ideas, anybody? Best, Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] lots of The application failed to initialize properly in 6.4.0 on Windows
Hi, Lots of commands (e.g. g.proj, g.region, g.remove) on my instalation of Windows GRASS 6.4.0 and the latest SVN snapshot (WinGRASS-6.4.SVN-r43430-1-Setup.exe) fail to run and an error window pops up (attached), saying: The application failed to initialize properly (0xc0150002). This a Virtulabox (3.2.8 non-free) running Windows Prof. SP3 32bit under Debian Squeeze amd64. I don't have a real Windows box at hand if the problem takes place on my system only. Does anybody experience similar errors on Windows? Maciek -- Maciej Sieczka http://www.sieczka.org attachment: win_err.png___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Some questions about DEMs
W dniu 10.07.2010 02:31, Hamish pisze: Maciek wrote: For heterogenous input data I'd try the nn algorithm in nnbathy, through r.surf.nnbathy (http://grass.osgeo.org/wiki/Addons#r.surf.nnbathy). It is great for sparse points, but for contour lines + hydrological modeling it is not the best. See nn valley staircase effect in http://grass.osgeo.org/wiki/Contour_lines_to_DEM Interpolating from contour lines has always been a nightmare for me :). What is the best approach in your opinion? Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Some questions about DEMs
W dniu 09.07.2010 12:29, David Townshend pisze: I have a couple of questions about DEMs, and how they work in GRASS. My application is hydrological and hydraulic analysis, and at the moment I'm investigating using r.sim.water to generate floodlines. Usually, for this sort of analysis, I would have 5m contours for the catchment and a detailed survey (i.e. spot heights, sometimes with triangles) for sections of river. So my first question is, what is the best way to generate a DEM from this information? I know that I can use r.surf.contour to create a DEM from the contours, and I'd assume that something like v.surf.rst would be best for the points, but I need a single DEM for the analysis. For heterogenous input data I'd try the nn algorithm in nnbathy, through r.surf.nnbathy (http://grass.osgeo.org/wiki/Addons#r.surf.nnbathy). The second problem is that I don't need a highly detailed DEM for the catchment, I only need detail along the watercourses - i.e. where I have the detailed survey. If I create two DEMs at different resolutions, can I patch them without losing detail? You can patch 2 rasters of different resolution, but not to loose information, the output raster map needs to be of the resolution of the more detailed input raster map. This will result in a flat squares + smooth valleys surface. My third question is about creating a mask. If I'm working along the coast, or if I'm creating a detailed DEM along the watercourse, I only want raster data where there is base data (i.e. contours or points). Is there a way to quickly generate a mask for this? v.hull + v.to.rast? Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Rectify an image
Nikos Dumakis pisze: Greetings I have an image without any GCP's but, teorethically it's in WGS84. I have all pixel positions outside that file. My question is, what should I do in GRASS to rectify/project this image? I thought in two solutions If the image doesn't require warping, but is just missing a georereference, use r.region to put in place. Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Atmospheric Correction in wxpython
Hamish pisze: Nikos wrote: I have just installed GRASS 6.4 in a Linux Machine and I realized that Atmospheric Correction menu item is disabled. Question: Is this module unavailable at Linux version? Because it is available in Windows. things get automatically greyed out if the binary for that module is missing. There is no particular reason I know of why that would fail to build on linux; check your installation or build log for errors. i.atcorr is written in C++. Maybe the build was done without --with-cxx? Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: v.breach addon
M S pisze: Kubuntu 9.10 64bit, using GRASS 6.5. I ran v.breach on a stream network extracted with r.stream.extract. It runs through the program, and puts up an error dialogue at v.parallel. Attached is the log file. It looks like a negative number is being passed to v.parallel. I saw in the documentation this might be a problematic module in the script for non-metric coordinate system. Below is the portion of the output box from the module. Note the error 11 lines down. --- Building topology for vector map breach_pt_segm_2l_r_tmp_5636_0_v_breach_sh... Registering primitives... 100 primitives registered 259 vertices registered Building areas... 0 areas built 0 isles built Attaching islands... Attaching centroids... Number of nodes: 100 ERROR: value -0.1 out of range for parameter distance Number of primitives: 100 Number of points: 0 Number of lines: 100 Number of boundaries: 0 Number of centroids: 0 Legal range: 0-1 Description: Creates parallel line to input vector lines. Keywords: vector, geometry --- Should I look in the script for this portion, and check if it is a metric issue? or does this seem like a different problem? A different one. v.parallel used to accept negative offsets to distinguish left/right. Now (after v.parallel2 replaced it) it doesn't accept negative offsets anymore. Maciek 2009/12/14 Maciej Sieczka msiec...@sieczka.org: Luís Ferreira pisze: I used v.breach with both SQLite and dbf, with ETRS89 metric negative coordinates, from 20m to 2m resolution and worked fine. System: Ubuntu 9.10 Karmic Koala, 64 bits, GRASS 6.4SVN. But I remember to see some warnings like yours. Are these warnings critical? Visually, the interpolated DEMs with v.surf.rst are coherent. I'll let you know next time I take a hobbyist look at v.breach. But I really don't know when it will be. Good luck. Maciek On Mon, 2009-12-14 at 04:57 +0100, Maciej Sieczka wrote: @Luís: I applied most your of patch. Thanks! Are you sure that's all errors? I keep on getting warnings like: WARNING: Unable to get point on line: cat = 1 offset = 2.831711 (line length = 0) at v.segment calls in the script, and a crash at v.in.ascii. -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: v.breach addon
Luís Ferreira pisze: I used v.breach with both SQLite and dbf, with ETRS89 metric negative coordinates, from 20m to 2m resolution and worked fine. System: Ubuntu 9.10 Karmic Koala, 64 bits, GRASS 6.4SVN. But I remember to see some warnings like yours. Are these warnings critical? Visually, the interpolated DEMs with v.surf.rst are coherent. I'll let you know next time I take a hobbyist look at v.breach. But I really don't know when it will be. Good luck. Maciek On Mon, 2009-12-14 at 04:57 +0100, Maciej Sieczka wrote: @Luís: I applied most your of patch. Thanks! Are you sure that's all errors? I keep on getting warnings like: WARNING: Unable to get point on line: cat = 1 offset = 2.831711 (line length = 0) at v.segment calls in the script, and a crash at v.in.ascii. -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: v.breach addon
Luís Ferreira pisze: On Mon, 2009-12-07 at 08:11 +0100, Maciej Sieczka wrote: Luís Ferreira pisze: I had to change some strings to make v.breach work on GRASS 6.4svn revision 39873, Ubuntu/Debian 9.10. Can you send a diff (diff original_file your_file), as attachment? Here is it :) The problem with v.breach is down to v.parallel interface change in v.parallel2 - option `distance' does not accept negative offsets anymore, and introduces a new `side' option to distinguish left/right, instead: $ v.parallel in=lines out=lines_par dist=-1 ERROR: value -1 out of range for parameter distance Legal range: 0-1 @Devs: It would be cool if v.parallel could be changed to accept negative offsets, for compatibility within 6.x line. @Luís: I applied most your of patch. Thanks! Are you sure that's all errors? I keep on getting warnings like: WARNING: Unable to get point on line: cat = 1 offset = 2.831711 (line length = 0) at v.segment calls in the script, and a crash at v.in.ascii. Best, Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.breach available?
M S pisze: I downloaded all the grass-addons, and didnt seen v.breach in the directory. I also tried to download it as a specific module and I get a message saying it doesnt exist. svn checkout https://svn.osgeo.org/grass/grass-addons/v.breach grass-addons/v.breach yields... svn: URL 'https://svn.osgeo.org/grass/grass-addons/v.breach' doesn't exist Any suggestions? It's here: http://www.sieczka.org/programy_en.html Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Define breaklines in DEM creation - r.surf.nnbathy
Luís Ferreira pisze: At page 235 from book OPEN SOURCE GIS - A GRASS GIS Approach 3rd edition: Natural neighbor interpolation is implemented in addon module r.surf.nnbathy. It uses “nn” – a natural neighbor interpolation library and allows the user to define breaklines such as stream lines or ridges as 2D lines without the need to define their elevation That's not possible. r.surf.nnbathy accepts only a single raster map as input. Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: v.breach addon
Luís Ferreira pisze: Aftermath... I had to change some strings to make v.breach work on GRASS 6.4svn revision 39873, Ubuntu/Debian 9.10. Can you send a diff (diff original_file your_file), as attachment? Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: v.breach addon
Luís Ferreira pisze: I want to make a hydrological corrected DEM, using v.surf.rst for interpolation/aproximation and v.breach to introduce aditional elevation points at streams. My spatial reference system is EPSG:3763 ETRS89 / Portugal TM06, (metrical). As required in v.breach document: - each input vect line have a unique category in layer 1; - input lines not cross themselves; - input lines not constitute loops; - the input vector lines not stand out of the input raster DEM; - the input lines direction is from upstream to downstream. After creating a DEM using v.surf.rst I want to correct the false sinks in narrow valleys and sparse points areas. Using v.breach I have as result two output vectors for streams lines and points but without entities or attributes. I tried with both PostgreSQL and Sqlite database connections. For PostgreSQL connection: DBMI-Postgres driver error: Cannot select: SELECT cat,lcat,z,z_breach FROM topografia.vbreachpoints_2 ERROR: column z does not exist LINE 1: SELECT cat,lcat,z,z_breach FROM topografia.vbreachpoints_2 ^ Unable to open select cursor: 'SELECT cat,lcat,z,z_breach FROM topografia.vbreachpoints_2' Copy table failed Table vbreach_2 does not exist in database host=localhost,dbname=grass_pp_muda_pttm06 The table vbreach_2 is now part of vector map vbreach and may be deleted or overwritten by GRASS modules DBMI-Postgres driver error: Cannot create index: create unique index vbreach_2_cat on vbreach_2 ( cat ) ERROR: relation vbreach_2 does not exist Cannot create index DBMI-Postgres driver error: Cannot grant on table: grant select on vbreach_2 to public ERROR: relation vbreach_2 does not exist Cannot grant privileges on table vbreach_2 Select privileges were granted on the table Any ideas? If wanted I'll send the files needed for replication. Luís, Glad to see someone trying to use my stuff :). What GRASS version do you use? What OS? What was your command line, exactly? Maybe the culprit is the DB backend. I have never used the script with anything else than DBF. Try to switch to DBF in GRASS (db.connect). Or a GRASS version too new. I think I used it only against 6.3. There *might* have been changes to underlying GRASS modules. I've written the script, and used it the last time, about 2 years ago. It did the job fine then. I don't have a personal interest in developing it at the moment. I could provide you a commercial support if you like. That would include testing the script against your data, in a GRASS setup similar to yours, and fixing the tool if necessary. Please contact me in priv if you are interested. I don't charge much :). Or, if there's a GRASS hacker willing to do it for free - please go ahead, anybody. Best, Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] copying mouse location to clipboard in gis.m
pete davidson pisze: Hi all In gis.m, as you mouse over a map, the current easting and northing is displayed in the lower right hand corner of the map window. This makes it easy to, for example, find the coordinates of an intersection on a street map by simply moving the cursor over the intersection and writing down the coordinates. My problem is, is there any way to copy those coordinates to the clipboard with a keystroke command so they can be pasted somewhere else, rather than having to write them down by hand? I've tried the usual ctrl-c / ctrl-x kind of things with the Pointer, Query, and Measure tools selected, but nothing I try seems to put anything on the clipboard. Does anyone know the answer to this one (or is there another way to do this using v.digit or something similar?) Here's a link to a screenshot with the coordinate box highlighted in case I haven't been clear: https://php10.ucsf.edu/ufostudy/transfer/screenshot.html Query the map - the coordinates of where you clicked are in the gis.m output window then, even if no object was found. Copy paste from there. Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] The upper limit for displaying large vector layers
Maybe related: http://trac.osgeo.org/grass/ticket/384 http://trac.osgeo.org/qgis/ticket/1430 Maciek ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] The upper limit for displaying large vector layers
Maciej Sieczka pisze: Maybe related: http://trac.osgeo.org/grass/ticket/384 http://trac.osgeo.org/qgis/ticket/1430 And another one - maybe: https://trac.osgeo.org/qgis/ticket/1427 Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] g.transform: forward and reverse rmse
Dear All, I have a problem understanding how to interprete the reverse and forward rmse returned by g.transform. I found Glynn's explanation [1], but, shame one me, I don't quite get it. Is there anybody willing to put the explanation some other words so maybe this gives enough clue? I noticed that e.g. i.points displays only one rmse value, which g.transform returns as the forward one. Looks like other GIS software don't bother with reverse rmse either. So what is the use of this reverse rmse information actually? [1]http://lists.osgeo.org/pipermail/grass-dev/2006-June/024208.html -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] weird dbf file in GRASS 6.4
QGIS and GRASS devs, Below I'm forwarding you a QGIS-GRASS issue. It seems to be somewhat related to https://trac.osgeo.org/qgis/ticket/554#comment:7. maning sambale pisze: I am editing a dbf file of a GRASS vector in QGIS. When I launch the open attribute table in QGIS it shows a long table of over a thousand records, but when I open the file in OpenOffice Calc 3.0 it only shows me 30 records which was the 30 classes I initially converted from raster to vector. Using: r.to.vect -v input=x output=x_vect feature=area --overwrite --verbose My plan is to edit the class categoris of each vector polygon in OOCalc. Any ideas why is it like this? I don't have problems with my previous vector files when I am using 6.3 You used the '-v' switch which means: Use raster values as categories instead of unique sequence. Thus, it is normal that the output table has only that many rows, as many unique cell values were there in the input raster map. Multiple polygons are linked to the same table row (by having the same category), so there are more polygons than rows in the table indeed. QGIS table editor does not present a GRASS vector map table as it really is, but treats each vector feature separately. This has the pro that you can access individual polygons from the table editor, no matter that multiple polygons have the same category. The con is that it's not the real table as it is, which confuses some users. Best if QGIS could provide both modes, with the current behaviour as an option and defaulting to real table layout. Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] WinGRASS issues poll
Marco Pasetti pisze: Together with a colleague we've been thinking about an enterprise related to WinGRASS - thus the reconnaissance. cool! may I have more info about it? Nothing really to talk about yet. First things first the reconnaissance. 1. I noticed that some replies have been sent to you as private mail, and not to the entire list; it would be great that all the replies to this topic will be sent directly to the list The were 2 of them only. Replying to each I forwarded the relevant part of the original message to the ML so you can have a look. 2. would be also good to move that topic to the grass-windows mailing list I wanted feedback from the users mainly. Looking at the WinGRASS ML traffic there are not many subscribers. But thanks for reminding me about that ML - I should follow it. Maybe if the poll stalls here I'll try there too. For now let's keep it here. 3. please, take as reference, about the WinGRASS project, the following documents: [1] http://grass.osgeo.org/grass63/binary/mswindows/native/README.html [2] http://grass.osgeo.org/wiki/WinGRASS_Current_Status#ToDo Been there. Thanks for maintaining them! Many changes and enhancements are on the way, but I need some more time to do them. Feel free to modify the wiki document [2] if needed Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] WinGRASS issues poll
Jonathan Greenberg pisze: Large file support for the imports (we discussed this a few weeks back) -- I can't use wingrass without it. I think you were trying to see if you could do a recompile of gdal to get it working... Hi Jonathan, Thanks for your feedback. What Windows version? What WinGRASS installer version? Can you reproduce the problems with latest [1] one? [1]http://grass.osgeo.org/grass63/binary/mswindows/native/WinGRASS-6.3.0-4-Setup.exe Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] WinGRASS issues poll
Firman Hadi pisze: 1. GDAL/OGR * When I use gdalwarp with EPSG code, there is error saying that it can't find epsg file * When I use gdalwarp with WKT, there is error saying that libproj.dll is missing 2. GRASS terminal * When I choose GRASS terminal, I can't use binary program besides unix program. I can't use gdalwarp, gdalinfo, ogr2ogr etc.\\ Hi Firman, Thanks for your feedback. What Windows version? What WinGRASS installer version? Can you reproduce the problems with latest [1] one? [1]http://grass.osgeo.org/grass63/binary/mswindows/native/WinGRASS-6.3.0-4-Setup.exe Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Trying to rename a column
Thomas Adams pisze: Ultimately what I am trying to do is to make a varchar(5) field be a varchar(8) field — but I don't see how to do this directly. So, I thought if I created a new varchar(8) column, copied the values of the varchar(5) column into it (This all worked fine); then, renamed the varchar(5) column to 'foo' (which also worked), then I could rename the varchar(8) column to what the column name was for the original varchar(5) column — this does NOT work. Paste the exact command with an error message, v.info -c of the vector map for which the command fails, your GRASS version and platform. Also, I would like to delete the 'foo' column, but I don't see how to do this. v.db.dropcol (it's been available since GRASS 6.3). If you don't have it you can just fetch it from GRASS SVN [1], put somewhere on your executable path and call it from GRASS, or use such a command: echo ALTER TABLE $table DROP COLUMN $col | db.execute [1]http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/scripts Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] problems with ps.map outputs
Glynn Clements pisze: The usual tool for interactively editing PostScript files is Illustrator. FTR, Corel Draw worked for me too when I used Windows. BTW - anybody knows of good Open Source alternatives for editing (*real* editing, alike Illustrator or Corel Draw) PS or PDF under GNU/Linux? Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] g.list rast not working on wingrass.
Milton Cezar Ribeiro pisze: I don´t know why now I can´t run g.list rast on my system. All comands works fine, but when I try to run g.list rast I get an error windows (from native windows, something like illegal call etc), and the GRASS return an empty list. But the GRASS don´t crach, and I can continue running other commands without problem. Only g.list that is not working. What GRASS version exactly (best give a link to where you dowloaded it from)? What Windows version? Does 'g.list rast' fail in GUI or command line? Does e.g. 'g.list vect' work? Please post the *exact* error message too. Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] problems with ps.map outputs
Tom Russo pisze: [EMAIL PROTECTED] wrote: How about Inkscape or Scribus? http://www.inkscape.org/ http://www.scribus.net/ Both of these are cool programs, and if one could get ps.map's output into them they'd be great choices for tweaking map presentation. But neither is actually able to import a PDF (or even PostScript) map for editing. Scribus can import a PDF of text and allow you to edit it. It can't do much with the graphics, though. Inkscape can do a great deal with the graphics if you can get the data imported. But it can't read PDFs or postscript directly. Inkscape has some script that tries to use ghostscript to convert the document to an Adobe Illustrator document and then import that, but every time I've tried it it fails. As far as I could tell, it was because the ghostscript ps-to-ai deal didn't work properly on ps.map's generated postscript. Have you actually had success with either of these programs? Tom, I also had problem with Inkscape in past, but I just checked 0.46 stock Debian testing package and it rocks now. See my previous message in the thread. Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS export GeoTiff adventure :-)
Markus Metz pisze: Nikos Alexandris wrote: Maciek suggested to compress the overviews to save disk space. Would this cause a viewing problem in Arc? (Have no access to any commercial package currently). Don't create overviews in this case. And yes, there can well be problems with ESRI products, Use external overviews. GDAL-based software will make use of them and they will just be ignored by other software. You umight consider external overviews in HFA format, which is supported also by some non-GDAL software. Check QGIS user ML archive for a recent thread regarding overviews for some more details. Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Concave hull of a set of points (alphashapes)
[EMAIL PROTECTED] pisze: Hello, I have a set of points and would like to compute the concave hull of it. Is it possible within grass and has anybody done it before. (Not tested idea:) Connect all points with v.distance. Get rid of doubled lines with v.clean tool=rmdupl. Turn lines into boundaries with v.type - this creates areas without centroids. Add a centroid to each area. Make sure each centroid has the same category (use v.category if needed). Dissolve areas (v.dissolve) - you should get a single area with nodes only at the most outer points you had in your input dataset. Let me know if this works. Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Segmentation fault with r.in.gdal
Vishal Mehta pisze: Hi all, I am attempting to import netcdf files into GRASS. I'm using GRASS 6.2.2 on Ubuntu 8.04LTS. I get a 'Segmentation fault' error. gdalinfo --formats includes netcdf support; however running gdal_translate or gdalinfo on the netcdf file returns the same error. Apparently it's a GDAL issue. Try to report upstream. Cheers, Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.carve stalling or not working properly...
G. Allegri pisze: I'm trying to use r.carve for the very first time, but I can't make it work as it stalls even with not so big region settings, and common stream network density. In case a restric the region to a narrower area, after a long time the work seems done, but the resulting DEM appears carved only at few sparse locations... Any hints? Slightly shameless, but have you tried my v.breach from GRASS AddOnns? Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Workflow of a classification project with orthophotos
Nikos Alexandris pisze: how do Open Source Professionals image normalisation for aerial photos... let's say 300 photos? I cannot imagine that people sit-down and extract psuedoinvariant targets for 300 photos (except they are payed a lot for that). Nikos, Have you looked at OSSIM? Not that I'm sure it provides the tool, but seems likely. -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] can't click a button in wxGUI = 7 years old GTK bug?
Hi, Some of you might have noticed a problem with wxPython GRASS GUI that sometimes you could not click some button again without moving out of it's area of control and back (e.g. you can't press Run button in a module's GUI the second time not having moved the cursor somewhere outside of it and back). It is highly likely that it's been the same bug that was reported 7 (seven) years ago for GTK and just recently fixed. Dig the whole story [1]. Is it really the same thing like I suppose? [1]http://research.operationaldynamics.com/blogs/andrew/software/gnome-desktop/gtk-bug-56070.html Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.info vs. r.info: different region output format
Sebastian Holler pisze: v.info -g precip_30ynormals north=36.49917 south=33.99472 east=-75.62194 west=-84.02389 top=1615.44 bottom=2.438400 r.info -g elev_ned_03arcsec north=35:54:40.66N south=35:35:17.334885N east=78:27:08.335106W west=78:49:17.33W Is there any reason for the different outputs or is this a bug? Not a bug but a bad feature. Although the curent behaviour is not good, I'm affraid it cannot be changed during GRASS 6 devel line not to brake software that might depend on it. Please fill a defect report in Trac and the issue maybe will be fixed in GRASS 7. Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ogr imports some areas of shapefile twice or more
Tim Michelsen pisze: I have a shapefile containing 150 polygons. After importing this shapefile with v.in.ogr and then adding it to a qgis prject I observe that it has more polygons than the original data source. I tested it by overlaying the original shapefile in QGIS as a normal (non-GRASS) vector. This is really strange. What could be the cause for this? Post 'ogrinfo -al -so' of the shapefile and of the GRASS vector (point ogrinfo at the 'head' file of the GRASS vector map, sth. like /home/grassdata/location/mapset/vector/vector map/head). Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: import a folder full of shapefiles and reproject on-the-fly?
Tim Michelsen pisze: Nevertheless, I cannot get around expressing my disappointment about GRASS in this area. * I cannot just point the program to a directory of shapefiles and tell it import all. QGIS, gvSIG and ArcGIS can do this. Well, true. I clearly remember how frustrating it was for me when I started using GRASS - how do I import those 20 shapefiles, process them all with the same command and then export them back, withot having to click those buttons a hundred times for an hour. Yet now I'm fine with this as that was the first moment when I had to learn some scripting. Maybe not really consoling for you at the moment... * I cannot reproject these on the fly be changing the projection of my location. On-the fly reprojection is not what a GIS *analysis* software should do, IMO. It's great in QGIS which is mainly a viewer/map composer (for me at least), but even in QGIS if you want to do anything with your shapefile in a different coordinate system, you still have to reproject it permanently, for the performance penalty when working with live-repojected data is not worth the comfort (e.g. try to edit a live-reprojected shapefile in QGIS - several times slower) and also opens a field for new issues (say area/distance/angle calculation will be different in different CRSs - now should the native or the temporary CRS be considered?). And it would make it necessary to adapt all GRASS modules to support on-the-fly reprojections, consistently. And the real fun begins in case of raster maps. = Whenever it comes to data format conversion and reprojection people on QGIS/GRASS Maillists tend to tell the user: get your keyboard and hack something with OGR/GDAL (Re: converting .asc to .xyz, http://permalink.gmane.org/gmane.comp.gis.qgis.user/2519). In this thread you asked about a particular conversion tool, and there was a reply. True, the tools mentioned don't support multiple input, but they do the work once you learn the magic: for i in *.xyz; do gdal2xyz.py $i $i.xyz; done (Few days ago I learned how to do it in Python and I'm an even hapier camper :). Nice thing is that now you can re-use the syntax in any later work that involves batch processing on Unix. And you'll be ways more time-efficient than having to click around, even if the GUI and multiple input support was there (am I getting old or what?). In clear words this means that the software is not ready, yet. This tells me that these GIS are not made for normal Desktop GIS task and mapping. Maybe GRASS is good for some very specialised and automatisable tasks. But to make a beautiful and printable map from a buch of data that can be interpreted? That's not what GRASS is for; a separate issue is that there doesn't actually exist a decent GUI-driven FOSS map composer AFAIK (however what Marco Hugentobler is doing now for QGIS 1.0 is extremely promissing). Yet the latter is not a GRASS fault. I don't think GRASS development should concetrate on a user-friendly map composer, when the dev resources are so scarce. I was trying my best to run my current project with GRASS and FOSS4G. But these have such severe usability issues that I cannot affort putting the time in. Yes, you need to invest some time first to start being productive ... Since geographical analysis also involves data aquisition and -- later -- a interpretation I want to minimise the processing time. ... but once you get it, you'll save a lot of time. I am not here to rant only. I will try to update the page on usabilty (http://grass.osgeo.org/wiki/Usability) after finishing my project. Thanks! That would be appreciated. But really, GIS is visual work with geoGRAPHICAL As for the word play, I'd put it all in capital letters :). data. Point for me. Why did I write disappointment? Because GRASS is advertised by OSGEO as THE most powerful free GIS that can perform any task. One must be honest and tell, that one needs to be a programmer (at least bash) and run linux and have a good visual imagination because of the non integrated GUI. The above mentioned tasks are really basic GIS tasks. Yes, some scripting is necessary to be any productive with massive data processing. Even on Windows with ArcGIS. Finally, the moment to grab the keyboard comes anyway :). Someone is devloping a GUI for OGR: * http://inventis.ca/ogr2gui/ * http://permalink.gmane.org/gmane.comp.gis.gdal.devel/16254 Hope that this will help for future tasks. I think it is better to reproject and merge shapefiles via ogr2ogr. The very trivial task (in my experience) was to clean vector after import in GRASS. v.clean tool=rmdupl,snap,bpol Actually, it is not really trivivial. GRASS freezes the computer when running the above mentioned command on a vector that consists of merged corine land cover tiles (number of tiles = 20). Some defect it seems. Please report to Trac (with details how to reproduce). Maciek -- Maciej Sieczka www.sieczka.org
Re: [GRASS-user] How to use SQLite command
[EMAIL PROTECTED] pisze: db.connect driver=sqlite database='gis/latlon_jpn/PERMANENT/sqlite.db' Error: value sqlite out of range for parameter driver Legal range: dbf,ogr,pg Why error massage ? Apparently your GRASS installation is not built with SQLite support. grass manual wrote follwing message: GRASS is automatically creating the SQLite database if it is not yet existing. http://grass.itc.it/grass62/manuals/html62_user/grass-sqlite.html But I find only dbf holde under PERMANENT directory... Why is not sqlite.db made ? Do I need to install sqlite for cygwin ? My grass environment: Cygwin grass62 You would need to rebuild GRASS against SQLite I guess. Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: import a folder full of shapefiles and reproject on-the-fly?
Tim Michelsen pisze: Maciej Sieczka wrote: Moritz Lennert wrote: So, normally, if you don't give a layer all the shapefiles in the directory (dsn=) will be imported. Note this loads the Shapefiles as *layers* (in the GRASS meaning of it) of a single output vector map. Not necessarily what one might want. That means that they would get imported as patched tiles? Not exactly - the geometry would be in a single vector map, but each ex-tile would have a separate attribute table and categories of features in each ex-tile would not be unique cross-layer. Read about the layer concept in the GRASS manual. Here is my workflow 1) import all landcovers in the UTM location= v.in.ogr 2) patch all landcover tiles = v.patch in=list_of_tiles out=tiles_all 3) import the tiles_all into the lat/lon location That's different than what you wrote initially - you wrote you need to reproject first, and then import all reprojected tiles into one location. Given the above workflow, mind that each UTM zone is a different CRS actually. Do all your shapefiles fit into a single UTM zone? Can this be done more efficiently? You can patch and reproject multiple shapefiles with ogr2ogr alone. See it's manual. Then import into GRASS location in a single v.in.ogr step. You will, however, need a loop for the v.proj step... ogr2ogr is more convenient than going through a temporary location creation, Shapefile import and reprojection with v.proj, IMHO. Much less work. If I want to change the projection of the lat/lon location with g.setproj do I also need to reporject all layers inside that location? I don't quite understand what you mean. Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Once more: raster projection transformation: LAEA - UTM
Maciej Sieczka wrote: Jana K. pisze: Looks like you do have correct settings in the PROJ_INFO in both PERMANENT mapsets. Can you post the header file of the raster map you want to reproject? Maybe it's malformed, for whatever reason. You'll find it in location/mapset/cellhd folder. Thanks all of you for quick help, I think Maciej hit the problem - here is the input file header: proj: 0 zone: 0 north: 650 south: 70 east: 750 west: 80 cols: 67000 rows: 58000 e-w resol: 100 n-s resol: 100 format: 0 compressed: 1 while the PROJ_INFO is: name: Lambert Azimuthal Equal Area datum: etrs89 towgs84: 0.000,0.000,0.000 proj: laea ellps: grs80 a: 6378137.00 es: 0.0066943800 f: 298.2572221010 lat_0: 52.00 lon_0: 10.00 x_0: 4321000.00 y_0: 321.00 Here is how I (most probably) created the input file location: GLC landuse data available on the web are in tiff format. The downloaded package contained .tif, .tfw, .aux, and .prj files. I created a new location called GLC_europe manually, using info from .prj file. I imported the .tif file into the GLC_europe location. Afterwards, I performed other operations - I reprojected another GLC file from lat/lon, I reclassed the categories in the two files and I patched the first file with the other (rougher). Now when I looked at the headers of all files that I manipulated in this location, all of them have the projection 0 in their headers. (By the way, what is format in the header? Some of them have 0 and others 1). Now, how can I solve this problem? Can I simply manually change the information in header files? Should be enough to just modigy the number in line proj:. See [1], Projection Information for details. Do you have some idea, why the headers are not correct? Maybe the way how I created the GLC_europe location was not correct? Please point me to these GLC landuse data available on the web are in tiff format so I can have a look. Also, please create a new raster in both locations (e.g. r.mapcalc 'test=1') and post the content of their headers. If it still does not reflect your settings in PERMANENT/PROJ_INFO, there's something wrong with GRASS I guess. What GRASS version and platform BTW? [1]http://download.osgeo.org/grass/grass6_progman/gislib.html -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] import a folder full of shapefiles and reproject on-the-fly?
Moritz Lennert pisze: On 23/07/08 22:36, Maciej Sieczka wrote: Use ogr2ogr to reproject Shapefiles outside GRASS (it accepts directory of shapefiles as input as well as single shapefiles) and then import them all with v.in.ogr. You can automate v.in.ogr in Shell using for in do syntax (plenty of examples in the archive or Google it). I don't think you actually need a for-loop. From the v.in.ogr man page: layer=string[,string,...] OGR layer name. If not given, all available layers are imported So, normally, if you don't give a layer all the shapefiles in the directory (dsn=) will be imported. Note this loads the Shapefiles as *layers* (in the GRASS meaning of it) of a single output vector map. Not necessarily what one might want. You will, however, need a loop for the v.proj step... ogr2ogr is more convenient than going through a temporary location creation, Shapefile import and reprojection with v.proj, IMHO. Much less work. Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Once more: raster projection transformation: LAEA - UTM
Jana K. pisze: I've already posted this a couple of days ago, but I am afraid somehow it got lost in other questions. I believe someone must know an answer, so please, HELP me :-(: I need to transform a map from LAEA coordinates into UTM. I created a new location with UTM projection. I used r.proj from within the new location, but running it, I received the following error message: Input Projection Parameters: +proj=laea +lat_0=52.00 +lon_0=10.00 +x_0=4321000.00 +y_0=321.00 +a=6378137 +rf=298.257222101 +no_defs +towgs84=0.000,0.000,0.000 Input Unit Factor: 1 Output Projection Parameters: +proj=utm +zone=34 +a=6378137 +rf=298.257223563 +no_defs +towgs84=0.000,0.000,0.000 Output Unit Factor: 1 Can't work with xy data I don't understand it as the data are clearly georeferenced. Looks like you do have correct settings in the PROJ_INFO in both PERMANENT mapsets. Can you post the header file of the raster map you want to reproject? Maybe it's malformed, for whatever reason. You'll find it in location/mapset/cellhd folder. Do I need to make a transformation to lat/lon beforehand? In general avoid reprojecting rasters more often than needed - each reprojection introduces some distortion to data. Now question 2: My raster data are categorical (landuse), and during the projection transformation I want to go from high resolution (100m) to rather crude resolution (2500m). How GRASS handles such operation? I would expect that It assigns the highest frequency value to the new cell (I mean if one new cell contains 625 old pixels, it will be assigned the value which occurs most frequently). Am I right? Look into section 'Design of r.proj' in the r.proj manual. In 'NOTES' you'll find instructions on how to maintain input and output region settings. Best, Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem displaying a vector map
Moritz Lennert pisze: On 17/07/08 17:38, ramaraju wrote: coor files of vector '[EMAIL PROTECTED]' is larger than it should be (14 bytes excess). Somehow your file got messed up (did you do any digitizing on it ?). Try running v.build. For me v.build alone does not help the coor files of vector is larger than it should be. However opening the vector map in v.digit and quitting does. Does anybody have an idea why this file size excess happens at all? It crops out from time to time when you run v.build on a vector map lacking topology (e.g. due to v.digit crash). -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Vector Topology: how to get a line from a boundary
[EMAIL PROTECTED] pisze: 1) How to get just the outline of the island ? Both v.type and v.extract with type=boundary,line produce an empty vector. The manual reads: --- NOTES Only features with a category number will be extracted. So if you want to extract boundaries (which are usually without category, as that information is normally held in the area's centroid) you must first use v.category to add them. --- 2) The main issue is to derive all counties of the island which lie on the shore (= ignore the counties which don't have a beach). How can a topological query be set up, saying derive all the county polygons which share a common boundary with the islands shoreline ? You might try v.to.db opt=sides col=left,right. After that select those areas, of which at least one boundary only has 'left' or 'right' populated. Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] random raster map
[EMAIL PROTECTED] pisze: Dear All, How can I create a raster map with random values between a minimum and a max value ? I tried r.random but I do not know how to specify these min anx max values. In case you are not sure what GRASS module to use, but have a general idea of what you are looking for, enter the directory where GRASS html manual is stored on your machine and search for the keyword inside the html files. A search for random in html files of raster modules (i.e. those matching r*html wildcard) returns for me: /usr/local/grass-6.4.svn/docs/html/r3.mapcalc.html /usr/local/grass-6.4.svn/docs/html/raster.html /usr/local/grass-6.4.svn/docs/html/r.clump.html /usr/local/grass-6.4.svn/docs/html/r.colors.html /usr/local/grass-6.4.svn/docs/html/r.cost.html /usr/local/grass-6.4.svn/docs/html/r.cross.html /usr/local/grass-6.4.svn/docs/html/r.le.setup.html /usr/local/grass-6.4.svn/docs/html/r.li.html /usr/local/grass-6.4.svn/docs/html/r.li.setup.html /usr/local/grass-6.4.svn/docs/html/r.mapcalc.html /usr/local/grass-6.4.svn/docs/html/r.random.cells.html /usr/local/grass-6.4.svn/docs/html/r.random.html /usr/local/grass-6.4.svn/docs/html/r.random.surface.html /usr/local/grass-6.4.svn/docs/html/r.surf.fractal.html /usr/local/grass-6.4.svn/docs/html/r.surf.gauss.html /usr/local/grass-6.4.svn/docs/html/r.surf.idw2.html /usr/local/grass-6.4.svn/docs/html/r.surf.idw.html /usr/local/grass-6.4.svn/docs/html/r.surf.random.html /usr/local/grass-6.4.svn/docs/html/r.texture.html Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] remove centroids from a patched vector
maning sambale pisze: V.clean options only removes duplicate centroids (rmdac) but not for all the centroids. any ideas? v.edit tool=delete Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Clip vector to current region
Dwight Needels pisze: I also seemed to have to add a centroid to the vector created by g.in.region (That's *v.in.region* you probably mean.) No need to add centroid manually - use option type=area. Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ogr weird import
Carlos Guâno Grohmann pisze: also, the dsn option must point to the _directory_ were your shps are. like: v.in.ogr dsn=/home/poseidon/Work/vector_data/ output=tracklines2 layer=Tracklines2.shp min_area=0.0001 snap=-1 That's just one option. You can point v.in.ogr at a specifi *.shp file as well. Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [POSIBLESPAM]: Re: [POSIBLESPAM]: [GRASS-user] v.in.shape
Jose A. Ruiz-Arias pisze: dsn is the directory whereas layer your .shp file Not necessarily. You can point at a specific shapefile too. Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Is mosaicing 24 bit images possible in Grass 6.2?
Hamish pisze: Nagesh wrote: Is there a way to mosaic 24 bit images and to output it as a single 24 bit image? To export a 24 bit image make a group of the 3 bands (i.group) and export the *group* using r.out.gdal (gdal_translate can do that also from outside GRASS, if you choose it's input as a path to your group file). This way you don't loose data as it would be the case for r.composite. Note that you can nicely visualise GRASS raster groups in QGIS, if at adding the GRASS raster layer you choose a group. Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.clean and database cleaning
Miha Staut pisze: Recently I ran v.clean tool=rmarea on a v.overlay result and surprised discovered that despite the command did get rid of small areas the corresponding database table was not updated accordingly. E.g. from 136 areas resulting from v.overlay after v.clean only 120 remained. The new table, however still had 136 rows. Since the purpose is to use the cleaned table in further, non-spatial analysis I am asking if there is a way to clean the table of all redundant rows not corresponding to any area. v.extract will pick only vector features which have a (specified) category and their corresponding table entries. Maciek -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Any freely available topographical maps for (South-) Germany ?
Nikos Alexandris pisze: I was asked about freely available geo-data concerning the South of Germany. AFAIK, best available elevation data are the SRTM3 data. About topographical data I am aware of some commercial data (1:25.000). The friend who asked me is satisfied with a 1:50.000 topo-map. Any secret sources? I don't know how secret these are, but: http://mapcenter.cgpsmapper.com/catalogue.php?country=55 http://mapcenter2.cgpsmapper.com/catalogue.php?country=130 *How* free these are varies from map to map. As well as the quality. These are in so called Polish format. Most complete description is available in cGPSmapper manual AFAIK [1]. There is a freeware (closed) program for converting them into Shapefiles [2]. Some other converter [3]. Mateusz Loskot has worked on an OGR driver, but I don't know details (CCing him). [1]http://www.cgpsmapper.com/manual.htm [2]http://www.msh-tools.com/Ptxt2shp.html [3]http://www.gpslib.net/services/Polish-to-Google.Earth/ Maciek P.S. Please better ask generic free GIS data questions on FreeGIS ML. -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] gps import: definition of WGS84
Hamish pisze: but they are incomplete! compare the entry for epsg:31370 in /usr/share/proj/epsg and in /usr/share/qgis/resources/srs.sb (using sqlitebrowser or such). you will see the srs.db version is missing the +towgs84= part. Definitely, it is a defect in QGIS srs.db. I have posted a script to regenerate a correct, updated srs.db to QGIS dev ML [1]. Among the other fixes, the database the script generates has the EPSG:31370 +towgs84 definition complete too. Once the remaining issues outlined in [1] are solved, there are chances that the fixed srs.db will be included in next QGIS release. [1]http://www.nabble.com/forum/ViewPost.jtp?post=17586603framed=y -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] using v.line.center
Markus Neteler pisze: On Thu, Jun 5, 2008 at 7:38 PM, Maciej Sieczka [EMAIL PROTECTED] wrote: Manuel Sangiao pisze: WARNING: Cannot get point on line: cat=927 offset=89379.795093 (line lenght=2.219076) P 927 927 89379.795093 I guess the reason for this error is the projection (mapset?) unit. The projection unit(s) in my mapset is degree(s). And the length units are meters. v.line.center as it is can't work in latlon Location. It uses v.to.db for length calculation, which cannot measure in degrees, I think it can... from the man page: When calculating perimeters in Latitude-Longitude locations, the geodesic distance between the vertices is used. Markus v.line.center uses v.to.db to calculate lengths of input vector lines, which then are fed into v.segment as offsets to create lines' center points. v.segment expects offsets in units of the Location. If these are degrees we have a problem because v.to.db can't calculate length in degrees. It supports the following units: mi,miles,f,feet,me,meters,k,kilometers,a,acres,h,hectares Therefore, v.line center can't work in latlon locations. -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] using v.line.center
Manuel Sangiao pisze: WARNING: Cannot get point on line: cat=927 offset=89379.795093 (line lenght=2.219076) P 927 927 89379.795093 I guess the reason for this error is the projection (mapset?) unit. The projection unit(s) in my mapset is degree(s). And the length units are meters. v.line.center as it is can't work in latlon Location. It uses v.to.db for length calculation, which cannot measure in degrees, and then pipes the result to v.segment, which assumes Location unit - if it's degree the script won't work. It would be cool if v.segment could accept offsets in various units. I should fix v.line.center to check location units, and update the manual. Someday. So, how can i change the mapset units. Should I create another mapset with the properly units? Reproject the data into a metric location. -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] mosaic with landsat geotiff
Juan Manuel Barreneche pisze: [These images come labeled by the orbit of the satellite and the point, which is the number of image of the sequence of said orbit, and are in UTM projection (resolution 30m x 30m)] Juan, Different UTM zones are different coordinate systems. If you want to uses data form two different UTM zones you need to reproject them into a common coordinate system first. Finding such a system is up to you. Reprojection can be accomplished with gdalwarp. If you need to do it in GRASS there is r.proj. Maciek ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Orthorectification of Historic Aerial Photographs
Shaun Melissa Busler pisze: Thank you so much for your response! The resources you linked to were very useful. The Erdas paper is especially good. I never heard of MapAnalyst. I will have to give it a try. Unfortunately, the focal length of the camera is not on the photo border. The photo must be too old. Do you have any recommendations on what focal length I should try? In one of the links already mentioned [1] there is a couple of hints. Maybe try asking on some RS-related ML? I was using photo2.image as part of the i.ortho.photo UI when I was having the problems. It may be because I am using GIS-Knoppix. If I use GIMP to measure the fiducial mark coordinates, do I still need to use photo2.image or do I just use photo.camera? In GIMP measure fiducial marks coordinates, assuming you have the resolution of the image set right. In GIMP you can check it in Image Print size - if the value there is wrong, set a correct one. Then, in i.ortho.photo go through steps 1-3. In step 4 enter a name your camera parameters will be stored under. A dialog pops up for camera parameters. Once you enter the number of fiducial marks and press Esc+Enter, you will be prompted with a dialog for their coordinates - that's where to put values measured in GIMP. Maciek [1]http://www.pcigeomatics.com/services/support_center/faqs/oe_general_v10.html#no_fiducial ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GForge tickets Trac
Markus Neteler pisze: Sascha fixed XML export of GForge today (thanks!): http://wald.intevation.org/export/tracker.php?group_id=21atid=204 Now we need to process this XML to generate something useful for trac. I'm sorry but I don't have much spare time until mid-summer or so (work work work). I won't be able to help much until then. Please anybody willing to port existing GForge tickets to Trac do it. Maciek ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Orthorectification of Historic Aerial Photographs
Shaun Melissa Busler pisze: 1) When is i.ortho.photo going to be available for the Windows binaries? Dunno. It currently depend on X displays, not easily portable to else than Unix. 2) The historic aerial photos do not have camera calibration files. I have searched all over and they do not seem to exist anymore. Is there a way to orthorectify the images without the camera calibration files? Can I make some assumptions? If so, what parameters should I enter? If the DPI at which photos have been scanned is known to you, you can measure the principal point and fiducial marks coordinates in any image editing software, like GIMP. Interior orientation results will depend on how close is the geometry of the image plane to the geometry of camera's optical system, and if/how the photo scan is distorted. Idea, not tested: you might try using software like MapAnalyst [1] to asses the distortion of the image, which can help you guessing genuine fiducial marks coordinates. Then you need the focal length. It often is present on the photo border. Or guess it :). 3) When I tried using photo.2image, I was not prompted with Look ok? (Y/N) so I was not able to mark the fiducials. photo.2image is not supposed to be used standalone. i.ortho.photo is the UI for photo.2image friends. There's plenty of info you might find usefull on the net. eg. [2] [3]. [1]http://mapanalyst.cartography.ch [2]http://support.erdas.com/focus3/files/Aerial_photo.pdf [3]http://www.pcigeomatics.com/services/support_center/faqs/oe_general_v10.html#no_fiducial ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] reading landsat 2 images
Michael Barton pisze: On Mar 7, 2008, at 10:00 AM, [EMAIL PROTECTED] wrote: I have to read old landsat-2 image files. They come as a 1 BIL file GRASS will read this. Use r.in.bin. Or r.in.gdal. GDAL supports BIL [1]. http://www.gdal.org/frmt_various.html#EHdr Maciek ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Just a successful report ; -) --- Compiling GRASS source code under Ubuntu 7.10 64-bit with...
Nikos Alexandris pisze: *** FFTW *** # ...installing FFTW cd fftw-2.1.5/ Not needed. On Gutsy the stock FFTW 3 suffices. Maciek ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] gdal-grass
gary wrote: I'm doing an install of grass62. I'm a bit confused about this new program gdal-grass. Yes, I know google is my friend, but I don't really follow this explanation: http://osdir.com/ml/gis.gdal.devel/2005-02/msg00049.html Incidentally, I've already compiled proj-4, geos, gdal, and grass62. I'm not sure how to set up the ./configure for gdal-grass. ./configure --with-grass=/path/to/grass/instalation It should pick up right --with-gdal and --with-autoload automatically. If it doesn't, refer to ./configure --help. Maciek ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Detect failure during batch job execution
Tim Michelsen wrote: A pointer here would be nice. http://lists.osgeo.org/pipermail/grass-user/2007-October/041465.html Maciek ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: [GRASS-dev] Some migration news
Markus Neteler wrote: # Tickets (have to be migrated from GForge and maybe also RT) http://trac.osgeo.org/grass/report Working on it [1]. Propably can do for GForge; propably won't-do for RT - too much mess there; I'd leave as it is. I'm still keeping an eye on RT, closing tickets for issues that get fixed in CVS, adding new commets from time to time etc. If anybody (*especially* original reporters) would like to skimm through their old RT reports to validate them or mark for closing, They are always more than welcome. That would certainly be much help. [1]http://wald.intevation.org/tracker/index.php?func=detailaid=560group_id=1atid=162 Maciek ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: [GRASS-dev] Some migration news
Martin Landa wrote: But the export from GForge failed How did you do this export? If all goes well we'll get an SQL dump of GRASS GForge trackers content from Sascha. Would it be easy to import this into Trac? Maciek ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.le.setup trouble and r.li not found
Patrick Giraudoux wrote: After having updated grass from 6.2.2 to 6.2.3 (Ubuntu gutsy), I am still messing with r.le.setup with the error: (...) Enter name of site map Enter 'list' for a list of existing vector files Hit RETURN to cancel request sites5 sites5 WARNING: Adapted sites library used for vector points (module should be updated to GRASS 6 vector library). ERROR: G_get_site() not yet updated. FWIW this stage works for me with current GRASS 6.2 CVS and GRASS 6.3 CVS. GRASS 6.2.3 (startt):~ r.li.setup bash: r.li.setup : commande introuvable r.li.* commands are not supposed to be present in 6.2 AFAIK. In 6.3 they are. Maciek ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] thematic vector map with non-numeric field values
Tim Michelsen wrote: Hello, how do I disply a thematic map in GRASS for vector attributes that don't have numeric values? I'd suggest QGIS. Load a GRASS vector, enter it's properties, in 'Symbology' tab use 'Legend Type: Unique Value'. Maciek ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
