Re: Polygonizer bug ?

On Mon, Jun 21, 2010 at 09:13:16AM -0700, Martin Davis wrote:
> strk,
> 
> The JTS Developer's Guide is a bit confusing.  The geometry given in the 
> example is NOT the geometry depicted in the illustration. (This is  a 
> doc bug - but I"m not sure if and when I can fix it).
> 
> When I run the geometry below in JTS I get:
> 
> Polygons:
> GEOMETRYCOLLECTION (
>  POLYGON ((189 98, 83 187, 185 221, 325 168, 189 98)),
>  POLYGON ((185 221, 88 275, 180 316, 292 281, 185 221)))
> 
> Dangles:
> MULTILINESTRING ((185 221, 100 100),
>  (0 0, 10 10))
> 
> I believe this is the expected result.

Uhm, that's w/out self-noding, right ?

--strk;

> 
> Hope that helps
> 
> Martin
> 
> strk wrote:

Re: Re: Polygonizer bug ?

FYI, as of r3078 the mis-port is fixed in GEOS.
Still interested in the result after self-noding.
Thanks !

--strk;

On Thu, Jul 01, 2010 at 10:59:12PM +0200, strk wrote:
> On Mon, Jun 21, 2010 at 09:13:16AM -0700, Martin Davis wrote:
> > strk,
> > 
> > The JTS Developer's Guide is a bit confusing.  The geometry given in the 
> > example is NOT the geometry depicted in the illustration. (This is  a 
> > doc bug - but I"m not sure if and when I can fix it).
> > 
> > When I run the geometry below in JTS I get:
> > 
> > Polygons:
> > GEOMETRYCOLLECTION (
> >  POLYGON ((189 98, 83 187, 185 221, 325 168, 189 98)),
> >  POLYGON ((185 221, 88 275, 180 316, 292 281, 185 221)))
> > 
> > Dangles:
> > MULTILINESTRING ((185 221, 100 100),
> >  (0 0, 10 10))
> > 
> > I believe this is the expected result.
> 
> Uhm, that's w/out self-noding, right ?
> 
> --strk;

Re: gstrdup in CAPI implementation

On Wed, 2010-06-23 at 18:16 +0200, strk wrote:
> So, question is: are gstrdup and gstrdup_s
> functions in geos_ts.cpp intended to include
> or not a null termination ?
>
> Note that gstrdup_s takes a size but reads
> one more byte from input pointer:

Sandro,

Yes, these functions are dodgy, let's say, by design.
It is not really possible to make such interface consistent
and make one function working with both kinds of strings,
std::string and C-string.
The assumption is that user of gstrdup will learn
its implementation to understand how to use it.
Meaning, to keep value of size consistent with number of non-null
characters.

Best regards,
--

-- 
Mateusz Loskot, http://mateusz.loskot.net

debug version

_______________________________________________
geos-devel mailing list
geos-devel <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

[GEOS] #362: Build fails on libtool/capi

#362: Build fails on libtool/capi
------------------------+---------------------------------------------------
 Reporter:  chodgson    |       Owner:  geos-devel <at> …              
     Type:  defect      |      Status:  new                       
 Priority:  major       |   Milestone:                            
Component:  Default     |     Version:  3.2.0                     
 Severity:  Unassigned  |    Keywords:                            
------------------------+---------------------------------------------------
 Downloaded 3.2.2 source tarball. Running on Redhat linux el5,
 2.6.18-164.15.1.el5, x86_64

 Configured with:
 ./configure --prefix=/usr/local/ --libdir=/usr/local/lib64

 make command ends with:

 Making all in capi
 make[1]: Entering directory `/usr/local/src/geos-3.2.2/capi'
 /bin/sh ../libtool --tag=CXX   --mode=link g++  -DGEOS_INLINE  -pedantic
 -Wall -ansi -Wno-long-long  -ffloat-store -version-info 7:2:6 -no-
 undefined  -o libgeos_c.la -rpath /usr/local/lib64 libgeos_c_la-geos_c.lo
 libgeos_c_la-geos_ts_c.lo ../source/libgeos.la
 libtool: link: unsupported hardcode properties
 libtool: link: See the libtool documentation for more information.
 libtool: link: Fatal configuration error.
 make[1]: *** [libgeos_c.la] Error 1
 make[1]: Leaving directory `/usr/local/src/geos-3.2.2/capi'
 make: *** [all-recursive] Error 1

 The same configure options compiles successfully using the 3.2.1 source
 tarball. Am I doing something weird or is x86_64 not that well tested?

--

-- 
Ticket URL: <http://trac.osgeo.org/geos/ticket/362>
GEOS <http://geos.refractions.net/>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
geos-devel <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [GEOS] #362: Build fails on libtool/capi

#362: Build fails on libtool/capi
------------------------+---------------------------------------------------
 Reporter:  chodgson    |       Owner:  geos-devel <at> …              
     Type:  defect      |      Status:  new                       
 Priority:  major       |   Milestone:                            
Component:  Default     |     Version:  3.2.0                     
 Severity:  Unassigned  |    Keywords:                            
------------------------+---------------------------------------------------

Comment(by pramsey):

 I've compiled on a number of x64 platforms... the only thing I haven't
 done before is --libdir=/usr/local/lib64, so see if removing that makes
 any difference.

--

-- 
Ticket URL: <http://trac.osgeo.org/geos/ticket/362#comment:1>
GEOS <http://geos.refractions.net/>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
geos-devel <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [GEOS] #362: Build fails on libtool/capi

#362: Build fails on libtool/capi
------------------------+---------------------------------------------------
 Reporter:  chodgson    |       Owner:  geos-devel <at> …              
     Type:  defect      |      Status:  new                       
 Priority:  major       |   Milestone:                            
Component:  Default     |     Version:  3.2.0                     
 Severity:  Unassigned  |    Keywords:                            
------------------------+---------------------------------------------------

Comment(by chodgson):

 Hmm... without the libdir it seems to work fine.. however I had a
 situation before when building a full mapserver/gdal/geos/postgis/proj/etc
 stack that things didn't work right if I didn't put them in the lib64 dir.
 I think it may have been gdal that was picky about that and I'm not using
 gdal for this build so I think can leave it out... kinda weird that I get
 this error from a simple directory option though.

--

-- 
Ticket URL: <http://trac.osgeo.org/geos/ticket/362#comment:2>
GEOS <http://geos.refractions.net/>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
geos-devel <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Pending Commit: changes to single sided buffering & ogc validity checking

_______________________________________________
geos-devel mailing list
geos-devel <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: Pending Commit: changes to single sided buffering & ogc validity checking

_______________________________________________
geos-devel mailing list
geos-devel <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: Pending Commit: changes to single sided buffering & ogc validity checking

On Thu, Jul 15, 2010 at 07:53:33PM -0400, Andrew Ross wrote:
> Hi Tom, All
> 
> Saw the copyright notice in the change. Copyright for geos seems to be held
> by a number of people and organizations. That seems legally murky to me but
> I am not a lawyer. Has this been discussed previously?

Not that I know about. I'm personally happy with multi-people copyright.

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html