[EMAIL PROTECTED] wrote: > Message: 1 > Date: Wed, 29 Oct 2008 11:49:02 -0400 > From: Kevin Webb <[EMAIL PROTECTED]> > Subject: [GRASS-user] v.select output vector is empty > To: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii"; format=flowed > > Greetings! > > I am attempting to execute a "point-in-polygon" process on 2 vectors using > v.select and the output vector is empty, it contains no value/s. > > When I create a map display of the 2 vectors I can clearly see the point > intersecting a polygon on the area layer, so it isn't an issue of > no-intersecting > values between the two datasets. > > The point vector was created using: > cat /home/kfw4/dev/grass_db/one_point.txt | v.in.ascii out=single_point > fs=',' x=3 y=2 col='batch_id varchar(32),decimal_la double > precision,decimal_lo double precision' --o > > > v.info and db.select show the correct imported value: > > GRASS 6.4.svn (lat_lon):~ > v.info single_point > > +----------------------------------------------------------------------------+ > | Layer: single_point > | Mapset: PERMANENT > | Location: lat_lon > | Database: /home/kfw4/dev/grass_db > | Title: > | Map scale: 1:1 > | Map format: native > | Name of creator: kfw4 > | Organization: > > |---------------------------------------------------------------------------- > | Type of Map: vector (level: 2) > | > | Number of points: 1 Number of areas: 0 > | Number of lines: 0 Number of islands: 0 > | Number of boundaries: 0 Number of faces: 0 > | Number of centroids: 0 Number of kernels: 0 > | > | Map is 3D: No > | Number of dblinks: 1 > | > | Projection: Latitude-Longitude > | N: 34:06:59.1408N S: 34:06:59.1408N > | E: 116:04:04.116W W: 116:04:04.116W > | > | Digitization threshold: 0 > | Comments: > | > > +----------------------------------------------------------------------------+ > > GRASS 6.4.svn (lat_lon):~ > db.select single_point > cat|batch_id|decimal_la|decimal_lo > 1|BAT000000074|34.116428|-116.06781 > > > The area vector was re-projected using v.proj: > > v.proj PREC0101 location=PREC0101 mapset=PERMANENT > > > GRASS 6.4.svn (lat_lon):~ > v.info PREC0101 > > +----------------------------------------------------------------------------+ > | Layer: PREC0101 > | Mapset: PERMANENT > | Location: lat_lon > | Database: /home/kfw4/dev/grass_db > | Title: > | Map scale: 1:1 > | Map format: native > | Name of creator: kfw4 > | Organization: > | Source date: Wed Oct 29 09:15:47 2008 > > |---------------------------------------------------------------------------- > | Type of Map: vector (level: 2) > | > | Number of points: 0 Number of areas: 6720 > | Number of lines: 0 Number of islands: 1212 > | Number of boundaries: 13970 Number of faces: 0 > | Number of centroids: 0 Number of kernels: 0 > | > | Map is 3D: No > | Number of dblinks: 1 > | > | Projection: Latitude-Longitude > | N: 49:25:31.535591N S: 24:27:48.66742N > | E: 66:54:50.339466W W: 124:46:59.356755W > | > | Digitization threshold: 0 > | Comments: > | > > +----------------------------------------------------------------------------+ > > > > Clearly, the single_point projection is contained by the PREC0101 > projection. (Clearly?) > > Yet, v.select yields nothing. > > GRASS 6.4.svn (lat_lon):~ > v.select ainput=single_point binput=PREC0101 > output=single_select op=overlap --overwrite --v > WARNING: Vector map <single_select> already exists and will be overwritten > Processing ainput lines ... > 100% > Processing ainput areas ... > Writing attributes ... > Layer 1 > v.select complete. > Building topology for vector map <single_select>... > 0 primitives registered > 0 vertices registered > 0 areas built > 0 isles built > Attaching islands: > Attaching centroids: Topology was built > Number of nodes : 0 > Number of primitives: 0 > Number of points : 0 > Number of lines : 0 > Number of boundaries: 0 > Number of centroids : 0 > Number of areas : 0 > Number of isles : 0 > GRASS 6.4.svn (lat_lon):~ > v.db.select -c single_select > GRASS 6.4.svn (lat_lon):~ > v.db.select -c single_select > GRASS 6.4.svn (lat_lon):~ > > > > > Any suggestions? > > > Thank you. > > > KFW > Two thoughts. 1) Try telling Grass-GIS explicitly that ainput is a point and binput is an area. I know these are supposed to be optional... 2) Use v.distance to see if the point's distance to the area is calculated correctly (if the point is inside the area, distance should be zero)
Richard Chirgwin > > > ------------------------------ > > Message: 2 > Date: Wed, 29 Oct 2008 13:46:29 -0400 > From: "Patton, Eric" <[EMAIL PROTECTED]> > Subject: RE: [GRASS-user] Tips for setting up an new > FOSS-GEO-linux-box > To: "Nikos Alexandris" <[EMAIL PROTECTED]>, > "grass-user" <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > >> OS: >> OK, I think I shouldn't ask about which OS since foss runs on everything >> (right?). But are I am curious to know if there are any advantages using >> Debian instead of Ubuntu for example? >> > > Everyone has their own favorite; I've been using Ubuntu and Grass together > since 2004, with no difficulties on 32-bit and 64-bit machines. > > >> Filesystems: >> Which filesystem is better(=safer/faster) for data storage? Is there any >> important advantage to choose XFS for example rather than ext3? >> > > Not sure about the main differences/advantages of either; I've been using ext3 > since forever, with no regrets. > > >> Partitions: >> Do you keep your geo-data in a separate partition? I suppose yes. Have >> you split further your partition based on other criteria, always related >> with "working with geospatial data"? >> > > Pretty much the main 3-4 projects I'm working on are on /home, with anything I > haven't worked on in the last 2-weeks backed up and archived on an external > 2TB hardrive. (LaCie) > > >> Do you keep all of your source code in a separate partition maybe? >> > > Nope, just under good old /usr/local. I only compile from scratch those > applications where > I need all the bleeding edge goodies and bug fixes, which, for me, is only > Grass, > gdal, and lilypond. I try to use the distribution's packages for everything > else; > makes it a lot easier to maintain using the package manager than chasing > around > and recompiling source for a ton of apps. > > >> Organisation: >> GRASS takes care to organise the data inside the GIS data-base and its >> fantastic. But what about the "raw" data? How do you organise them? >> Manually everything? Any tool to be more productive? >> > > Once raw data is imported into Grass, I usually get it off my hard drive and > backed > up onto something external, in case my computer melts down; then I can always > rebuild from scratch. Of course the external drive could also melt down. I > guess > a RAID would be even better, but costs more. > > >> BackUp: >> How often do you backup your data? Do you just copy or do you compress >> as well? What is safer? >> > > I've been using 'tar cjvf' for each project, but that is becoming > unmanageable; I need > to migrate to a versioning system as Dylan has done with rsync. At least for > the > projects I work on all the time. The old stuff can probably stay on the > backup drive > in tar.bz2 format. > > > >> Other: >> Any other important issues when setting-up a new foss-geo-box? >> > > I just installed Ubuntu Intrepid 8.10 yesterday, and found it much easier > installing packages via Synaptic rather than downloading the bleeding edge > source packages and compiling. The only source package I had to compile was > Grass. > > > Thank you, Nikos > > P.S. Maybe we can add a new wiki-page if something useful comes out of > this thread. Or maybe not... :-) > > _______________________________________________ > grass-user mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-user > > > > ------------------------------ > > Message: 3 > Date: Wed, 29 Oct 2008 20:29:23 +0100 > From: "Markus Neteler" <[EMAIL PROTECTED]> > Subject: Re: [GRASS-user] Tips for setting up an new > FOSS-GEO-linux-box > To: "Nikos Alexandris" <[EMAIL PROTECTED]> > Cc: grass-user <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, Oct 29, 2008 at 6:46 PM, Patton, Eric <[EMAIL PROTECTED]> wrote: > >>> OS: >>> OK, I think I shouldn't ask about which OS since foss runs on everything >>> (right?). But are I am curious to know if there are any advantages using >>> Debian instead of Ubuntu for example? >>> >> Everyone has their own favorite; I've been using Ubuntu and Grass together >> since 2004, with no difficulties on 32-bit and 64-bit machines. >> > > Happy Mandriva user here :) > Also Scientific Linux user on our cluster. > > ... > >>> Do you keep all of your source code in a separate partition maybe? >>> >> Nope, just under good old /usr/local. I only compile from scratch those >> applications where >> I need all the bleeding edge goodies >> > > I don't even install but run it directly with a link from > grass64/dist.x86_64-unknown-linux-gnu/ > > Markus > > > ------------------------------ > > Message: 4 > Date: Wed, 29 Oct 2008 20:34:59 +0100 > From: Nikos Alexandris <[EMAIL PROTECTED]> > Subject: Re: [GRASS-user] Tips for setting up an new > FOSS-GEO-linux-box > To: grass-user <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain > > On Wed, 2008-10-29 at 15:08 +0100, Nikos Alexandris wrote: > >> I know, I know... it's off the lists topic! But I need some help. >> Probably I am going to "migrate" soon all of my stuff in a new >> linux-box. So I would like to collect best practice tips concerning the >> following: >> >> >> OS: >> OK, I think I shouldn't ask about which OS since foss runs on everything >> (right?). But are I am curious to know if there are any advantages using >> Debian instead of Ubuntu for example? >> >> >> Filesystems: >> Which filesystem is better(=safer/faster) for data storage? Is there any >> important advantage to choose XFS for example rather than ext3? >> >> >> Partitions: >> Do you keep your geo-data in a separate partition? I suppose yes. Have >> you split further your partition based on other criteria, always related >> with "working with geospatial data"? >> >> Do you keep all of your source code in a separate partition maybe? >> >> >> Organisation: >> GRASS takes care to organise the data inside the GIS data-base and its >> fantastic. But what about the "raw" data? How do you organise them? >> Manually everything? Any tool to be more productive? >> >> >> BackUp: >> How often do you backup your data? Do you just copy or do you compress >> as well? What is safer? >> >> >> Other: >> Any other important issues when setting-up a new foss-geo-box? >> >> >> Thank you, Nikos >> >> P.S. Maybe we can add a new wiki-page if something useful comes out of >> this thread. Or maybe not... :-) >> > > Dylan, Eric and Markus, > thank you for your precious time to respond. > > Since there are already 3 answers then maybe some wiki-page can be > set-up out-of it. I'll try to structure the information a bit and open a > page whenever I find some free-time (possibly this weekend). > > Please to all GRASS-users following the list, if you have some spare > time and consider these questions important, participate with your > ideas/tips/hints/tricks. > > Kind regards, Nikos > > > > ------------------------------ > > Message: 5 > Date: Wed, 29 Oct 2008 21:03:56 +0000 > From: Glynn Clements <[EMAIL PROTECTED]> > Subject: Re: [GRASS-user] d.out.file now does GeoTIFFs > To: [EMAIL PROTECTED] > Cc: grass list <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > > Hamish wrote: > > >>>> Unfortunately 'd.info -g' is buggy, it reports exactly the same as >>>> 'g.region -g'. But if that was fixed it would be an easy solution. >>>> >> fixed in devbr6 but not trunk; I'm unsure about the changes needed. >> > > 7.0 doesn't have D_get_screen_window(); D_setup() uses R_get_window() > instead (R_get_window() reports the raster clip region, which is > initially set from $GRASS_FRAME). > > Also, I would suggest reporting the values returned from D_get_u_* > rather than using the current region directly (which can always be > obtained from g.region). > > Although the two should match, it's the values reported by D_get_u_* > which are actually used, so using D_get_u_* would be more robust in > the face of any future extensions (e.g. allowing the region to be > enlarged to fit the window rather than shrinking the window to fit the > region). > > _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
