Re: [GRASS-user] self compile grass- msys
Yes, I installed it in c/osgeo4w But there is not any "error.log" file in /osgeo4w/usr/src/grass64/ I tried to run compile again and it appeared the error in msys: [... checking ... configure: error: *** Unable to locate curses library.] Thy ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Two questions re 6.4 and OSX 10.4
William, Make exits with an error in Nviz; /lib/nviz won't make. Here's the /lib/nviz error: (cd /usr/local/grass-6.4.0/dist./lib; ln -f -s libgrass_nviz.6.4.0.dylib /usr/local/grass-6.4.0/dist./lib/libgrass_nviz.dylib) ld: cycle in dylib re-exports with /usr/X11/lib/libGL.dylib collect2: ld returned 1 exit status make: *** [/usr/local/grass-6.4.0/dist./lib/libgrass_nviz.6.4.0.dylib] Error 1 Richard On 17/09/10 11:47 PM, William Kyngesburye wrote: --with-proj --with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include --with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib --with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj On Sep 17, 2010, at 3:48 AM, Richard Chirgwin wrote: William - I'm not getting as far as "make" yet. At configure, it fails: Unable to locate External PROJ.4 includes. This, even if I use: --with-proj=/Library/Frameworks/PROJ.framework/Versions/4/Headers/proj_api.h (I know that PROJ.4 is installed, I'm using 6.4.0-RC4 with no worries!) Richard On 14/09/10 9:06 AM, William Kyngesburye wrote: If you mean, install 6.4.0 without overwriting 6.4 RCs: After you "make", don't "make install". Instead "make bindist". After it creates the Mac installer package, it leaves a full copy in macosx/dist (the staging area for creating the installer package), which you can move to whereever you like (or rename it). If you mean, install GRASS 6.4.x without overwriting 6.3, then that's not a problem since the applications are named with the major.minor version. Note that existing builds of Qgis.app will still use the older GRASS install, because of library linking, and setting the GRASS_GIS_BASE in Qgis to try to make it use the newer GRASS will only cause trouble. Qgis must be rebuilt to use the newer GRASS. - William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.net.path extension
try wx.path python version. but it will not fulfil your needs but more interactive than v.net.path now it only support spearfish dataset will extend to use any data if anyone needs http://svn.osgeo.org/grass/grass-addons/gui/wxpython/wx.path/wx.path.py On Fri, Sep 17, 2010 at 7:01 PM, Robbie Heremans wrote: > Starting from a file with start and end positions (x_start, y_start, > x_stop, y_stop) and a vector map of roads, I have to find places on the > roads where most people pass, assuming they will use the shortest path or > path with the least cost. > > Is there a command in Grass that can do this (ic v.net.path for each record > and summary map of these shortest paths)? > > Any suggestions/examples? > > Robbie > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > > -- Rashad ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: which file do I use? .adf files
see also the wiki help: http://grass.osgeo.org/wiki/Tips_for_Arc_users#Raster_import.2Fexport_commands Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Estimating Albedo from Landsat
Nikos wrote: > Given that the NC lsat data set represents untouched DN's, does it? > perhaps it has to do with "old vs new" calibration parameters? at least for the lsat7_2000 NC maps, the cloud detection is also very bad, and there I confirmed the calibration numbers with the values listed in the r.info metadata. I think we'll have to redownload the three NC scenes from GloVis to know for sure. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Estimating Albedo from Landsat
Hamish: > > Probably we should concentrate on the North Carolina dataset for common > > tests... its landsat mapset has: ... > > Auto-cloud determination for the NC 1987 Landsat5 scene is no good. Right, it does not look good. # rename lsat5_1987_10 to lsat5_1987.1 (same for the rest of the bands of course) # DN to TOA (from metadata at Glovis: "sun elevation =39.71119266") i.landsat.toar band_prefix=lsat5_1987 method=uncorrected sensor=5 date=1987-10-14 solar_elevation=39.71119266 product_date=1987-10-14 # uncorrected, 2-pass i.landsat.acca -5 -2 band_prefix=lsat5_1987.toar output=lsat5_1987.toar.acca --o --v# cloud detection is really bad # single pass i.landsat.acca -5 band_prefix=lsat5_1987.toar output=lsat5_1987.toar.acca --o --v# as noted by Hamish I think, seems to partially follow the road network... !? Given that the NC lsat data set represents untouched DN's, perhaps it has to do with "old vs new" calibration parameters? Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] self compile grass- msys
Hi, >Hi Thy-san, > >I wonder if you know there is a precompiled >Windows binary for GRASS-6.5 and GRASS-7 at > >[http://josef.fsv.cvut.cz/wingrass/grass65/] >[http://josef.fsv.cvut.cz/wingrass/grass70/] > >Best > >Venka unfortunately the WinGrass7-installer seems to be broken at the moment. best regards Helmut ___ GRATIS: Spider-Man 1-3 sowie 300 weitere Videos! Jetzt kostenlose Movie-FLAT freischalten! http://movieflat.web.de smime.p7s Description: S/MIME Cryptographic Signature ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: self compile grass- msys
Hi Thy-san, I wonder if you know there is a precompiled Windows binary for GRASS-6.5 and GRASS-7 at http://josef.fsv.cvut.cz/wingrass/grass65/ http://josef.fsv.cvut.cz/wingrass/grass70/ Best Venka On 2010/09/17 16:52, Pham Thy wrote: Hi Helmut, Thank you. Msys worked. But when I compiled it seams there are mistakes showing in the package.log in the below: --- Fri Sep 17 14:02:05 2010: STARTING configure checking host system type... i686-pc-mingw32 checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for Cygwin environment... no checking for mingw32 environment... yes checking for executable suffix... .exe checking for full floating-point support... yes checking for pwd... /c/mingw/bin/pwd checking for source directory... /osgeo4w/usr/src/grass64 checking for build directory... /osgeo4w/usr/src/grass64 checking for MacOSX App... no checking for MacOSX architectures... no checking for MacOSX SDK... no checking how to build libraries... shared checking for ranlib... ranlib checking how to run the C preprocessor... gcc -E checking if 64bit support is requested... no checking if 64bit Sparc VIS support is requested... no checking system version (for dynamic loading)... MINGW32_NT-5.2-1.0.11(0.46/3/2) checking for dlopen in -ldl... no checking for ar... ar checking for additional include dirs... /c/OSGeo4W/apps/gdal-16/include /c/OSGeo4W/include checking for additional library dirs... /c/OSGeo4W/apps/gdal-16/lib /c/OSGeo4W/lib checking for a BSD compatible install... /c/mingw/bin/install -c checking for flex... flex checking for yywrap in -lfl... no checking for bison... bison -y checking for ranlib... ranlib checking for ar... ar checking for env... env checking for perl... no checking for ANSI C header files... no checking for limits.h... yes checking for termio.h... no checking for termios.h... no checking for unistd.h... yes checking for values.h... yes checking for f2c.h... no checking for g2c.h... no checking for sys/ioctl.h... no checking for sys/mtio.h... no checking for sys/resource.h... no checking for sys/time.h... yes checking for sys/timeb.h... yes checking for sys/types.h... yes checking for sys/utsname.h... no checking for libintl.h... yes checking for iconv.h... yes checking for langinfo.h... no checking whether time.h and sys/time.h may both be included... yes checking for off_t... yes checking for uid_t in sys/types.h... no checking return type of signal handlers... void checking for Cygwin environment... no checking for ftime... no checking for gethostname... no checking for gettimeofday... no checking for lseek... no checking for nice... no checking for time... no checking for uname... no checking for seteuid... no checking for setpriority... no checking for setreuid... no checking for setruid... no checking for drand48... no checking for putenv... no checking for setenv... no checking for nanosleep... no checking whether setpgrp takes no argument... yes checking for long long int... yes checking for W11... no checking for X... disabled checking whether to use Curses... yes checking for curses.h... yes checking curses.h WINDOW structure component... _maxy checking for initscr in -lncurses... no checking for initscr in -lcurses... no --- Therefore there is no "bin" folder in /osgeo4w/apps/grass/ when run grass Please show me my mistake. Thank in advance Thy in the OSGeo4W installer-setup choose "advanced installation". in the command-line utilities-section you have to choose explicitly "msys - a Minimal system" to install msys inside Osgeo4W-stack and a desktop-icon msys. if you have installed osgeo4w under c:\OSGeo4W, then the msys-folder should live in C:\OSGeo4W\apps\msys. best regards Helmut ___ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: which file do I use? .adf files
Hi everyone, I had a similar problem recently, and made a nasty mistake for not paying enough attention. I had to import one of these arc rasters to GRASS, and used r.in.gdal. I also knew that it had to be a .adf file, but there were quite a few of those in the folder. I tried the first one (dblbnd.adf ) and it worked -- a normal-looking and correctly placed map was imported, so I just stopped looking and went on with the analysis. Later on, I found out that the values on the map weren't right -- for my region of interest they were about 3 times higher than the original values in the arc raster... The "good" one turned out to be the largest file in the folder (w001001.adf) -- Daniel's suggestion was thus wise. I think the dblbnd.adf is the same map with some kind of colour stretch to make it look better... But it gets imported as a normal map, and the colours are turned into (false) values that can easily deceive us. I didn't find a way to import complete folders (for cases like this) with r.in.gdal; is there one? Cheers, Márcia ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Two questions re 6.4 and OSX 10.4
--with-proj --with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include --with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib --with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj On Sep 17, 2010, at 3:48 AM, Richard Chirgwin wrote: > William - I'm not getting as far as "make" yet. At configure, it fails: > > Unable to locate External PROJ.4 includes. > > This, even if I use: > --with-proj=/Library/Frameworks/PROJ.framework/Versions/4/Headers/proj_api.h > > (I know that PROJ.4 is installed, I'm using 6.4.0-RC4 with no worries!) > > Richard > > On 14/09/10 9:06 AM, William Kyngesburye wrote: >> If you mean, install 6.4.0 without overwriting 6.4 RCs: >> >> After you "make", don't "make install". Instead "make bindist". After it >> creates the Mac installer package, it leaves a full copy in macosx/dist (the >> staging area for creating the installer package), which you can move to >> whereever you like (or rename it). >> >> If you mean, install GRASS 6.4.x without overwriting 6.3, then that's not a >> problem since the applications are named with the major.minor version. >> >> >> Note that existing builds of Qgis.app will still use the older GRASS >> install, because of library linking, and setting the GRASS_GIS_BASE in Qgis >> to try to make it use the newer GRASS will only cause trouble. Qgis must be >> rebuilt to use the newer GRASS. - William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] WDPA vector files
Thanks for your advice! This is a dirty dataset. I was hoping I had taken care of most of the problems, by breaking apart the dataset into IUCN categories. It is common for one protected area to have several different designations. It could be a national park and a national forest, for example. However, apart from that, there are the unintended overlaps, which is something the makers of the shapefile could clean. We loaded GRASS70 yesterday. I tried to run this morning, and my Linux terminal is completely frozen. I can't even close the window. So I am waiting for my colleague, who is a Linux guru, to get to work and get me unfrozen so I can try again... Tim *** Timothy S. Thomas, Research Fellow, IFPRI t.s.tho...@cgiar.org +1-202-862-4605 skype: timothy.s.thomas Rm 5035 -Original Message- From: Markus Metz [mailto:markus.metz.gisw...@googlemail.com] Sent: Friday, September 17, 2010 3:56 AM To: Thomas, Timothy (IFPRI) Cc: grass-user@lists.osgeo.org; Hamish Subject: Re: [GRASS-user] WDPA vector files Hamish wrote: > Tim wrote: >> I need to make some graphics showing WDPA protected areas. >> I am trying to import each IUCN type as a separate layer, from shapefile >> format. >> have only done 3 of the 8, and each is taking between 24 and 48 hours. >> I am running out of time. Does anyone already have these in GRASS format >> and would be willing to share? Thanks! > > you are probably running into the old "Florida Coastline" problem. > M.Metz: did you do something to improve this in trunk? No, I tried to optimize the cleaning functions in general. > > > in a pinch you might try the v.in.ogr -c flag, > > -c Do not clean polygons (not recommended) > > but as it says, it's really not recommended to work with uncleaned data. In this particular case, it might be ok not to clean polygons because most protected areas are isolated, i.e. not bordering other protected areas. OTOH, this dataset is also not really clean, I found that protected areas that are supposed to be adjacent are overlapping each other. You can try importing with the -c flag (also try the -r flag or spatial=W,S,E,N), but you should validate the delineation of the protected areas of interest. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.net.path extension
Starting from a file with start and end positions (x_start, y_start, x_stop, y_stop) and a vector map of roads, I have to find places on the roads where most people pass, assuming they will use the shortest path or path with the least cost. Is there a command in Grass that can do this (ic v.net.path for each record and summary map of these shortest paths)? Any suggestions/examples? Robbie ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] self compile grass- msys
Hi, >Hi Helmut, >Thank you. Msys worked. But when I compiled it seams there are mistakes >showing in the package.log in the below: > >--- >Fri Sep 17 14:02:05 2010: STARTING configure >checking host system type... i686-pc-mingw32 >checking for gcc... gcc >checking whether the C compiler (gcc ) works... yes >checking whether the C compiler (gcc ) is a cross-compiler... no >checking whether we are using GNU C... yes >checking whether gcc accepts -g... yes >checking for Cygwin environment... no >checking for mingw32 environment... yes >checking for executable suffix... .exe >checking for full floating-point support... yes >checking for pwd... /c/mingw/bin/pwd >checking for source directory... /osgeo4w/usr/src/grass64 >checking for build directory... /osgeo4w/usr/src/grass64 >checking for MacOSX App... no >checking for MacOSX architectures... no >checking for MacOSX SDK... no >checking how to build libraries... shared >checking for ranlib... ranlib >checking how to run the C preprocessor... gcc -E >checking if 64bit support is requested... no >checking if 64bit Sparc VIS support is requested... no >checking system version (for dynamic loading)... >MINGW32_NT-5.2-1.0.11(0.46/3/2) >checking for dlopen in -ldl... no [...] there seems to be nothing obvious wrong, answers of checks can be "yes" and "no". you can find the relevant things - if compiling fails - in /osgeo4w/usr/src/grass64/error.log. - where did you install the osgeo4w-stack (i.e. c:\osgeo4w\ or in an another destination) - please post the content of error.log Helmut ___ GRATIS: Spider-Man 1-3 sowie 300 weitere Videos! Jetzt kostenlose Movie-FLAT freischalten! http://movieflat.web.de smime.p7s Description: S/MIME Cryptographic Signature ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: which file do I use? .adf files
Thanks for all of your help. The metadata is of no help, already been down that road. This is more of a arc file structure problem... On Fri, Sep 17, 2010 at 3:50 AM, Sylvain Maillard wrote: > have you take a look in the metadata.xml file? regarding the name i guess > you could find usefull information inside ... > > > Sylvain > > > 2010/9/17 Hermann Peifer >> >> I guess you want to run r.in.gdal, or something. So you could follow this >> advice: >> >> > To open the coverage select the coverage directory, >> > or an .adf file (such as hdr.adf) from within it. >> >> http://www.gdal.org/frmt_various.html#AIG >> >> Hermann >> >> >> On 17/09/2010 02:33, stephen sefick wrote: >>> >>> I know that I need to use a .adf file, but which one? Is there a way >>> to find out? These are all in a file folder that is supposed to >>> contain a 1_foot LIDAR dem. >>> >>> dblbnd.adf >>> sta.adf >>> w001001x.adf >>> z001003.adf >>> z001005x.adf >>> hdr.adf >>> vat.adf >>> z001001.adf >>> z001003x.adf >>> hillshd_10m >>> w001000.adf >>> z001001x.adf >>> z001004.adf >>> metadata.xml >>> w001000x.adf >>> z001002.adf >>> z001004x.adf >>> prj.adf >>> w001001.adf >>> z001002x.adf >>> z001005.adf >>> >>> >>> thanks for all of your help, >>> >> >> ___ >> grass-user mailing list >> grass-user@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user > > -- Stephen Sefick | Auburn University | | Department of Biological Sciences | | 331 Funchess Hall | | Auburn, Alabama | | 36849 | |___| | sas0...@auburn.edu | | http://www.auburn.edu/~sas0025 | |___| Let's not spend our time and resources thinking about things that are so little or so large that all they really do for us is puff us up and make us feel like gods. We are mammals, and have not exhausted the annoying little problems of being mammals. -K. Mullis "A big computer, a complex algorithm and a long time does not equal science." -Robert Gentleman ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Displaying layers - GRASS 6.4.0RC6 with MSYS
Thanks Micha for putting me on the right track. GRASS_PNGFILE=myimage.png GRASS_PNG_READ=TRUE export GRASS_PNGFILE GRASS_PNG_READ before the d.vect commands or before the for-done-loop does the job. Robbie 2010/9/16 Micha Silver > Robbie Heremans wrote: > > I use the Windows-version *GRASS* 6.4.0RC6 with *MSYS* and I want to >> display 2 *layers* using following commands for the Spearfish60 sample >> location. >> >> d.vect streams col=blue >> d.vect roads col=red >> >> The output file map.png only displays the last layer. >> > I think what you need is to set the environment variable GRASS_PNG_READ to > TRUE. Then each run of d.vect will start with the existing png file and add > to it. > > >> How can I display multiple layers with MSYS? >> >> Using the wxGUI interface is not an option, I think, since I want to >> remake the example on >> http://casoilresource.lawr.ucdavis.edu/drupal/node/340 which uses a loop >> (map.png only gives the points of the 5th cluster). >> >> # there are 5 clusters: show them all, and compute convex hulls >> for x in `seq 1 5` do v.extract --o in=bclust where="cluster=$x" >> out=bclust_$x v.hull --o in=bclust_$x out=bclust_hull_$x >> d.vect bclust_hull_$x type=boundary fcol=none width=2 col=white >> d.vect bclust icon=basic/box fcol=black col=black size=6 >> done >> Any solutions? >> >> Robbie >> >> This mail was received via Mail-SeCure System. >> >> >> ___ >> grass-user mailing list >> grass-user@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user >> >> This mail was received via Mail-SeCure System. >> >> >> >> > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: which file do I use? .adf files
have you take a look in the metadata.xml file? regarding the name i guess you could find usefull information inside ... Sylvain 2010/9/17 Hermann Peifer > I guess you want to run r.in.gdal, or something. So you could follow this > advice: > > > To open the coverage select the coverage directory, > > or an .adf file (such as hdr.adf) from within it. > > http://www.gdal.org/frmt_various.html#AIG > > Hermann > > > On 17/09/2010 02:33, stephen sefick wrote: > >> I know that I need to use a .adf file, but which one? Is there a way >> to find out? These are all in a file folder that is supposed to >> contain a 1_foot LIDAR dem. >> >> dblbnd.adf >> sta.adf >> w001001x.adf >> z001003.adf >> z001005x.adf >> hdr.adf >> vat.adf >> z001001.adf >> z001003x.adf >> hillshd_10m >> w001000.adf >> z001001x.adf >> z001004.adf >> metadata.xml >> w001000x.adf >> z001002.adf >> z001004x.adf >> prj.adf >> w001001.adf >> z001002x.adf >> z001005.adf >> >> >> thanks for all of your help, >> >> > ___ > 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
Re: [GRASS-user] Two questions re 6.4 and OSX 10.4
William - I'm not getting as far as "make" yet. At configure, it fails: Unable to locate External PROJ.4 includes. This, even if I use: --with-proj=/Library/Frameworks/PROJ.framework/Versions/4/Headers/proj_api.h (I know that PROJ.4 is installed, I'm using 6.4.0-RC4 with no worries!) Richard On 14/09/10 9:06 AM, William Kyngesburye wrote: If you mean, install 6.4.0 without overwriting 6.4 RCs: After you "make", don't "make install". Instead "make bindist". After it creates the Mac installer package, it leaves a full copy in macosx/dist (the staging area for creating the installer package), which you can move to whereever you like (or rename it). If you mean, install GRASS 6.4.x without overwriting 6.3, then that's not a problem since the applications are named with the major.minor version. Note that existing builds of Qgis.app will still use the older GRASS install, because of library linking, and setting the GRASS_GIS_BASE in Qgis to try to make it use the newer GRASS will only cause trouble. Qgis must be rebuilt to use the newer GRASS. On Sep 13, 2010, at 5:39 PM, Richard Chirgwin wrote: Hi, I'm running a MacBook Pro with 10.4.1 (burned too many times with upgrade instability; now that it's running nice, I don't feel any desire to upgrade the OS!). My main question is this: how can I install the new 6.4 without over-writing my existing install? (Just in case I have trouble with the new version). Noting, of course, that because I'm on an aged OS, I have to use the compile-from-source instructions for OSX. Richard ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user - William Kyngesburye http://www.kyngchaos.com/ "Those people who most want to rule people are, ipso-facto, those least suited to do it." - A rule of the universe, from the HitchHiker's Guide to the Galaxy ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: which file do I use? .adf files
I guess you want to run r.in.gdal, or something. So you could follow this advice: > To open the coverage select the coverage directory, > or an .adf file (such as hdr.adf) from within it. http://www.gdal.org/frmt_various.html#AIG Hermann On 17/09/2010 02:33, stephen sefick wrote: I know that I need to use a .adf file, but which one? Is there a way to find out? These are all in a file folder that is supposed to contain a 1_foot LIDAR dem. dblbnd.adf sta.adf w001001x.adf z001003.adf z001005x.adf hdr.adf vat.adf z001001.adf z001003x.adf hillshd_10m w001000.adf z001001x.adf z001004.adf metadata.xml w001000x.adf z001002.adf z001004x.adf prj.adf w001001.adf z001002x.adf z001005.adf thanks for all of your help, ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] WDPA vector files
Hamish wrote: > Tim wrote: >> I need to make some graphics showing WDPA protected areas. >> I am trying to import each IUCN type as a separate layer, from shapefile >> format. >> have only done 3 of the 8, and each is taking between 24 and 48 hours. >> I am running out of time. Does anyone already have these in GRASS format >> and would be willing to share? Thanks! > > you are probably running into the old "Florida Coastline" problem. > M.Metz: did you do something to improve this in trunk? No, I tried to optimize the cleaning functions in general. > > > in a pinch you might try the v.in.ogr -c flag, > > -c Do not clean polygons (not recommended) > > but as it says, it's really not recommended to work with uncleaned data. In this particular case, it might be ok not to clean polygons because most protected areas are isolated, i.e. not bordering other protected areas. OTOH, this dataset is also not really clean, I found that protected areas that are supposed to be adjacent are overlapping each other. You can try importing with the -c flag (also try the -r flag or spatial=W,S,E,N), but you should validate the delineation of the protected areas of interest. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: self compile grass- msys
Hi Helmut, Thank you. Msys worked. But when I compiled it seams there are mistakes showing in the package.log in the below: --- Fri Sep 17 14:02:05 2010: STARTING configure checking host system type... i686-pc-mingw32 checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for Cygwin environment... no checking for mingw32 environment... yes checking for executable suffix... .exe checking for full floating-point support... yes checking for pwd... /c/mingw/bin/pwd checking for source directory... /osgeo4w/usr/src/grass64 checking for build directory... /osgeo4w/usr/src/grass64 checking for MacOSX App... no checking for MacOSX architectures... no checking for MacOSX SDK... no checking how to build libraries... shared checking for ranlib... ranlib checking how to run the C preprocessor... gcc -E checking if 64bit support is requested... no checking if 64bit Sparc VIS support is requested... no checking system version (for dynamic loading)... MINGW32_NT-5.2-1.0.11(0.46/3/2) checking for dlopen in -ldl... no checking for ar... ar checking for additional include dirs... /c/OSGeo4W/apps/gdal-16/include /c/OSGeo4W/include checking for additional library dirs... /c/OSGeo4W/apps/gdal-16/lib /c/OSGeo4W/lib checking for a BSD compatible install... /c/mingw/bin/install -c checking for flex... flex checking for yywrap in -lfl... no checking for bison... bison -y checking for ranlib... ranlib checking for ar... ar checking for env... env checking for perl... no checking for ANSI C header files... no checking for limits.h... yes checking for termio.h... no checking for termios.h... no checking for unistd.h... yes checking for values.h... yes checking for f2c.h... no checking for g2c.h... no checking for sys/ioctl.h... no checking for sys/mtio.h... no checking for sys/resource.h... no checking for sys/time.h... yes checking for sys/timeb.h... yes checking for sys/types.h... yes checking for sys/utsname.h... no checking for libintl.h... yes checking for iconv.h... yes checking for langinfo.h... no checking whether time.h and sys/time.h may both be included... yes checking for off_t... yes checking for uid_t in sys/types.h... no checking return type of signal handlers... void checking for Cygwin environment... no checking for ftime... no checking for gethostname... no checking for gettimeofday... no checking for lseek... no checking for nice... no checking for time... no checking for uname... no checking for seteuid... no checking for setpriority... no checking for setreuid... no checking for setruid... no checking for drand48... no checking for putenv... no checking for setenv... no checking for nanosleep... no checking whether setpgrp takes no argument... yes checking for long long int... yes checking for W11... no checking for X... disabled checking whether to use Curses... yes checking for curses.h... yes checking curses.h WINDOW structure component... _maxy checking for initscr in -lncurses... no checking for initscr in -lcurses... no --- Therefore there is no "bin" folder in /osgeo4w/apps/grass/ when run grass Please show me my mistake. Thank in advance Thy in the OSGeo4W installer-setup choose "advanced installation". in the command-line utilities-section you have to choose explicitly "msys - a Minimal system" to install msys inside Osgeo4W-stack and a desktop-icon msys. if you have installed osgeo4w under c:\OSGeo4W, then the msys-folder should live in C:\OSGeo4W\apps\msys. best regards Helmut ___ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
