On Wed, Jun 20, 2001 at 10:39:55AM +0700, Artemis wrote:
Hi all,
I've recently had a problem with v.what when
querying vector layer from a script.When I give v.what the coordinates where no
lines and no areas are present it still outputs
something like 'Line - Category 432' or so
but in only particular parts of my region.Maybe this has something to topology support?
The routine that matches a coordinate to a line uses a heuristic whereby
it first checks if the point falls into the bounding box for a given
line. If the point falls into the bounding box for multiple lines, then
a routine makes sure the closest line is chosen. Unfortunately, this
probably isn't the best way to do this. A nearby line may never be
associated with a given point even if that line would be closest because
the point may lie outside the bounding box. On the contrary, a point
that may be far away from any line, may still be associated with a given
line, iff it lies within the bounding box for that line.
Clearly, it would be better for the routine to take some sort of maximum
distance fuzz factor (probably should be scale dependent) then grow each
bounding box by that distance (so that near-misses don't happen) and
then eliminate lines that are farther than that fuzz factor (so that
far-hits don't happen).
Sort of a bug in the implementation, I guess... I'll CC this to GRASS
developer's list...
--
Eric G. Miller <egm2@jps.net>
From neteler Wed Jun 20 12:56:35 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
id MAA04148; Wed, 20 Jun 2001 12:56:35 +0100
Date: Wed, 20 Jun 2001 12:56:35 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: Grass Developers <grass5@geog.uni-hannover.de>
Subject: Re: [GRASS5] Error to compile i.fft
Message-ID: <20010620125635.H27335@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: Grass Developers <grass5@geog.uni-hannover.de>
References: <3B2F1895.3F60653F@hpcc.nectec.or.th> <20010619132536.M19538@hgeo02.geog.uni-hannover.de> <20010619140224.A25873@hgeo02.geog.uni-hannover.de> <20010619232905.A29291@hgeo02.geog.uni-hannover.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010619232905.A29291@hgeo02.geog.uni-hannover.de>; from neteler@geog.uni-hannover.de on Tue, Jun 19, 2001 at 11:29:06PM +0100
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/>
Status: O
Content-Length: 2028
Lines: 62
On Tue, Jun 19, 2001 at 11:29:06PM +0100, Markus Neteler wrote:
On Tue, Jun 19, 2001 at 02:02:25PM +0100, Markus Neteler wrote:
> Hi,
>
> again on the "gmath"/numerical functions issue...
> I need a recommendation.
>
> Currently we face following situation:
>
> - src/libes/gmath/ has been written by David to support LAPACK/BLAS
> (it contains wrapper functions)
> - we have spreading around numerous files containing various numerical
> functions like fft, ifft, matrix operations etc.
>
> My intention is to assemble all functionality in one library. So
> I started to migrate all such functions into src/libes/gmath/
> (as I did for i.fft and accidentially already uploaded).
>
> A problem arises on those machines, which don't have LAPACK/BLAS and "g2c"
> (requirement, which is the former f2c.h) installed.
> For example you will get, when compiling "gmath":
> src/include/la.h:28: g2c.h: No such file or directory
> make: *** [OBJ.sparc-sun-solaris2.6/la.o] Error 1
>
> Two solutions may the at our choice:
>
> (1) split the library into two libraries
> a) LAPACK/BLAS routines
> b) others
> (2) add some clever mechanism to selectively compile with/without
> LAPACK/BLAS support. So far "configure" checks already the presence
> of LAPACK/BLAS.
>
> I would vote for (2), but don't know how to implement it. Must be some
> ifdef's around "la.h"?So far I have updated configure now to search for g2c.h and f2c.h.
The src/libes/gmath/la.c is compiled only, if g2c.h is present (shall we
allow f2c.h as well?). That should do the trick for (2) above.To test, please update
cvs up configure configure.in
cvs up src/include
cvs up src/libes/gmath
... not to forget:
cvs up src/CMD/lists
to have gmath compiled on default.
To test:
configure
gmake5 src/libes/gmathNo error should occur.
In case of problems, please let me know.
Markus
Markus