Re: [GRASS-dev] Re: [GRASS-SVN] r51583 - grass/trunk/vector/v.buffer

2012-05-01 Thread Markus Metz 
On Tue, May 1, 2012 at 5:01 PM, Glynn Clements  wrote:
>
> Markus Neteler wrote:
>
>> > Author: mmetz
>> > Date: 2012-05-01 01:37:26 -0700 (Tue, 01 May 2012)
>> > New Revision: 51583
>> >
>> > Modified:
>> >   grass/trunk/vector/v.buffer/Makefile
>> > Log:
>> > add again GEOSLIBS ??? should be included by VECTORLIB
>>
>> I have this:
>>
>> [neteler@north grass70]$ grep geos include/Make/*
>> include/Make/Platform.make:GEOSLIBS            = -L/usr/lib64 -lgeos -lgeos_c
>
> If you add the -i flag (ignore case), you would get many more matches,
> including:
>
> include/Make/Grass.make:VECT_CFLAGS =  $(GDALCFLAGS) $(GEOSCFLAGS)
> include/Make/Grass.make:VECTORDEPS       = $(DBMILIB) $(GRAPHLIB) $(DIG2LIB) 
> $(LINKMLIB) $(RTREELIB) $(GISLIB) $(GEOSLIBS) $(GDALLIBS) $(MATHLIB) 
> $(BTREE2LIB) $(GPROJLIB) $(RASTERLIB) $(PQLIBPATH) $(PQLIB)
>
>> but without GEOSLIBS in the Makefile of v.buffer I get this error:
>
>> /usr/bin/ld: OBJ.x86_64-unknown-linux-gnu/main.o: undefined reference
>> to symbol 'GEOSBufferParams_create'

make distclean
svn up
./configure
make

...should help

> OTOH, as v.buffer is now using GEOS directly, $(GEOSLIBS) and
> $(GEOSCFLAGS) should be used in v.buffer/Makefile. While this
> shouldn't be necessary on Linux, I suspect that it is necessary on
> Windows.

Added to Makefile, just to be safe.
>
> For me, the current v.buffer doesn't even compile, due to
> GEOSBufferParams not being defined in any GEOS header (presumably it
> needs a more recent version of GEOS).

GEOSBufferParams has been introduced with GEOS version 3.3.0 which has
been released in 2008, not exactly brand new... Anyway, I have removed
GEOSBufferParams from v.buffer and made v.buffer use another buffer
function that is also present in older versions of GEOS.

Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS-SVN] r51583 - grass/trunk/vector/v.buffer

2012-05-01 Thread Glynn Clements 

Markus Neteler wrote:

> > Author: mmetz
> > Date: 2012-05-01 01:37:26 -0700 (Tue, 01 May 2012)
> > New Revision: 51583
> >
> > Modified:
> >   grass/trunk/vector/v.buffer/Makefile
> > Log:
> > add again GEOSLIBS ??? should be included by VECTORLIB
> 
> I have this:
> 
> [neteler@north grass70]$ grep geos include/Make/*
> include/Make/Platform.make:GEOSLIBS= -L/usr/lib64 -lgeos -lgeos_c

If you add the -i flag (ignore case), you would get many more matches,
including:

include/Make/Grass.make:VECT_CFLAGS =  $(GDALCFLAGS) $(GEOSCFLAGS)
include/Make/Grass.make:VECTORDEPS   = $(DBMILIB) $(GRAPHLIB) $(DIG2LIB) 
$(LINKMLIB) $(RTREELIB) $(GISLIB) $(GEOSLIBS) $(GDALLIBS) $(MATHLIB) 
$(BTREE2LIB) $(GPROJLIB) $(RASTERLIB) $(PQLIBPATH) $(PQLIB)

> but without GEOSLIBS in the Makefile of v.buffer I get this error:

> /usr/bin/ld: OBJ.x86_64-unknown-linux-gnu/main.o: undefined reference
> to symbol 'GEOSBufferParams_create'

If GRASS was configured --with-geos, GEOS should be pulled in by
libgrass_vector.so. It's possible that you're linking against a
version of libgrass_vector which was built without GEOS support, or
which was linked against a different major version of the GEOS
library.

OTOH, as v.buffer is now using GEOS directly, $(GEOSLIBS) and
$(GEOSCFLAGS) should be used in v.buffer/Makefile. While this
shouldn't be necessary on Linux, I suspect that it is necessary on
Windows.

For me, the current v.buffer doesn't even compile, due to
GEOSBufferParams not being defined in any GEOS header (presumably it
needs a more recent version of GEOS).

> Since you also have Fedora16, I wonder why it compiles for you and not for me
> without GEOSLIBS in the Makefile of v.buffer.

Probably because either:

1. If shared libraries are used, GEOS should get pulled in
automatically as a dependency of libgrass_vector.so.

2. If static libraries are used, $(VECTORDEPS) (which includes
$(GEOSLIBS)) will be added to the definition of VECTORLIB.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #1650: v.net.salesman - add sequence output

2012-05-01 Thread GRASS GIS 
#1650: v.net.salesman - add sequence output
-+--
 Reporter:  gfleming |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.3
Component:  Default  | Version:  unspecified  
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by mmetz):

 There is a new option to v.net.salesman in trunk to specify an output file
 where the sequence is written in tabular format with two columns, sequence
 and category number. Adding a new column to the attribute table is
 difficult because 1) several nodes could have the same category value, 2)
 a single internal node could be visited twice if it is not a user-selected
 node.

 The current output in verbose or debug mode in 6.x is correct only in
 special cases, for somewhat more complex routes, some nodes will be
 skipped by that output, or not all nodes will be printed.

 BTW, v.net.salesman in trunk is magnitudes faster than in 6.x,
 particularly for many (100+) nodes, and solves symmetric and asymmetric
 TSPs.

 Markus M

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #1464: Bug on v.buffer

2012-05-01 Thread GRASS GIS 
#1464: Bug on v.buffer
--+-
 Reporter:  leonidas  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Vector| Version:  svn-trunk
 Keywords:  v.buffer  |Platform:  All  
  Cpu:  All   |  
--+-

Comment(by neteler):

 Replying to [comment:4 mmetz]:
 > Fixed in trunk in r51580, as long as GRASS is compiled with GEOS.
 Neither one of the two GRASS-internal buffering methods is working
 correctly. Moreover, the GEOS method is the only one allowing for internal
 buffers with negative distances. Should we disable v.buffer if GEOS is not
 available (rather have no result than a wrong result)?

 I suppose that GEOS is available for all relevant platforms nowadays (and
 it became
 official OSGeo project yesterday). So I support this suggestion.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS-SVN] r51583 - grass/trunk/vector/v.buffer

2012-05-01 Thread Markus Neteler 
Hi,

On Tue, May 1, 2012 at 10:37 AM,   wrote:
> Author: mmetz
> Date: 2012-05-01 01:37:26 -0700 (Tue, 01 May 2012)
> New Revision: 51583
>
> Modified:
>   grass/trunk/vector/v.buffer/Makefile
> Log:
> add again GEOSLIBS ??? should be included by VECTORLIB

I have this:

[neteler@north grass70]$ grep geos include/Make/*
include/Make/Platform.make:GEOSLIBS= -L/usr/lib64 -lgeos -lgeos_c

but without GEOSLIBS in the Makefile of v.buffer I get this error:

gcc  -g -Wall  -fno-common -fexceptions -mtune=nocona -m64
-minline-all-stringops
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdal -I/usr/include
-DPACKAGE=\""grassmods"\"
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -o
OBJ.x86_64-unknown-linux-gnu/geos.o -c geos.c
: && gcc -L/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/lib
-L/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/lib
-Wl,--no-undefined -Wl,--export-dynamic  -L/usr/lib64
-Wl,-rpath-link,/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/lib
 -o /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin/v.buffer
OBJ.x86_64-unknown-linux-gnu/main.o
OBJ.x86_64-unknown-linux-gnu/geos.o-lgrass_vector.7.0.svn
-lgrass_dbmiclient.7.0.svn -lgrass_dbmibase.7.0.svn
-lgrass_gis.7.0.svn -lm   -lm
/usr/bin/ld: OBJ.x86_64-unknown-linux-gnu/main.o: undefined reference
to symbol 'GEOSBufferParams_create'
/usr/bin/ld: note: 'GEOSBufferParams_create' is defined in DSO
/usr/lib64/libgeos_c.so.1 so try adding it to the linker command line
/usr/lib64/libgeos_c.so.1: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make: *** [/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin/v.buffer]
Error 1

Using Fedora 16, 64bit with geos from their RPM.

A related page:
http://fedoraproject.org/wiki/UnderstandingDSOLinkChange

Since you also have Fedora16, I wonder why it compiles for you and not for me
without GEOSLIBS in the Makefile of v.buffer.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev