Re: [geos-devel] GEOS 3.1
On Thu, Dec 20, 2007 at 05:47:37PM -0700, Charlie Savage wrote: > > >>Are we going to keep fixing bugs in branches/3.0.0, following similar > >>procedure as GDAL does? > > > >Mateusz, > > > >Charlie seems to doubt the need for this, but I think it is good for us to > >treat 3.0 as a stable branch so we can put out a 3.0.1 if we fine some > >significant errors in the next few months before Ben's (3.1) work is > >complete. > > Its not that I doubt its a good idea. Its that I doubt there are the > people to actually maintain the branch. If there are, then by all means > there should be a branch. For what is worth, +1 for 3.0.0 stable and branch. --strk; ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Unclear objects lifetime and ownership issues in Monotone Chain components
On Wed, Sep 24, 2008 at 02:10:51PM +0200, Mateusz Loskot wrote: > Here is longer story [2] with suggested solution, however I'm not enough > knowledgeable about all internals especially about possible relations > between various collections allocated internally as well as flows and > ownership transfers. > > I'd be thankful if original authors of these components (Ben?, Sandro?) > could share their minds. Truth is (and you know): GEOS needs a GC ! Can't keep being considered 1:1 mapping with JTS if doesn't have one... --strk; ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Unclear objects lifetime and ownership issues in Monotone Chain components
On Wed, Sep 24, 2008 at 04:56:29PM +0200, Mateusz Loskot wrote: > strk wrote: > > Truth is (and you know): GEOS needs a GC ! > > Can't keep being considered 1:1 mapping with JTS if doesn't have one... > > Any particular GC technique you have in mind? > > IMHO, one of possible and clean solution for this kind of issues in GEOS > is to apply GC in form of shared_ptr - smart pointer that controls > lifetime of objects and frees developers from knowing *when* an object > is/should be deallocated. As long as you're sure no circular references exist, shared_ptr wuold be fine. But the point is if we GEOS needs to directly map JTS algorithms, they are based on a conservativ garbage collector. GCJ uses the bohem one, and is very nice. Ever tried to build JTS natively ? --strk; ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Unclear objects lifetime and ownership issues in Monotone Chain components
On Wed, Sep 24, 2008 at 08:30:13PM +0200, Mateusz Loskot wrote: > strk wrote: > > As long as you're sure no circular references exist, shared_ptr > > wuold be fine. > > I should precise I mean shared_ptr + weak_ptr. These two together solve > circular references issue. > > > But the point is if we GEOS needs to directly > > map JTS algorithms, they are based on a conservativ > > garbage collector. > > I can't answer this. However, I suppose it would be better if GEOS > implements the same algorithms as JTS does but not follows JTS > implementation line-by-line. Memory management is part of the algorithm, not an implementation detail. For strong/weak pointers to work it takes a design decision. If Martin never had to take it you'll be in trouble... > > GCJ uses the bohem one, and is very nice. > > Bohem can solve some/many problems, but it's not native C++ and > portable option, it's yet another dependencies (a big one), etc. > I don't think it would meet users' needs and expectations ;-) 'yet another' ? Isn't GEOS depencencies-free anymore ? Where I left it it had no dependencies except a C++ compiler and the standard template library. > Smart pointers would do solve this problem easier with > less complex solution. Although, I'm afraid it would require a lot of work. Bohem will likely require lot of work too... It's fun for me to talk about these issues *now* :) You can tell why I tried manual management always so far. The most effective way was usually kind of "pools". Basically, you use containers of things to delete at the end of the operations (every operation is a class anyway). It usually did fine. --strk; ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Unclear objects lifetime and ownership issues in Monotone Chain components
On Wed, Sep 24, 2008 at 10:50:59PM +0200, Mateusz Loskot wrote: > strk wrote: > > The most effective way was usually kind of "pools". > > Basically, you use containers of things to delete at the > > end of the operations (every operation is a class anyway). > > It usually did fine. > > Generally, true but number of issues come to my mind: > Those pools are not documented. Right. But you'll find a few around... > There is no way to learn where are start and end points of operations and > algorithms, unless you read the code from start to the end. There kind of is, if you assume operations are driven by operation classes... > Memory and time boundaries of operations are not documented. True, you may very well end out of memory before getting a chance to dispose all. > So, tracking objects ownership and flows is very hard. > How do we know all users of given pool in given time (without reading the > whole codebase). Which is another well known problem: there are too many interfaces exposed. My solution was: warranty void if you don't use the C-API. So you'd basically follow the flow from C-API on. The wider your pools, the more issues with memory and time boundaries. The closer-to-low-level-op you pool the better. --strk; ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Thread Safe CAPI RFC acceptance...
On Mon, Nov 03, 2008 at 01:15:15PM -0800, Paul Ramsey wrote: > Reference is here: > http://trac.osgeo.org/geos/wiki/RFC3 > > Looks good to me. > > Martin, Matz, Howard, Gary, Dale, votez! For what is worth, I think Chuck has a point in not willing to advertise reentrancy if not verified. The definition for "Reentrant" given in RFC3 requires checking under the CAPI layer to see if the core lib isn't using statics itself. I don't think it does, but I'm a bit outdated on latest developments... --strk; ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Thread Safe CAPI RFC acceptance...
On Mon, Nov 03, 2008 at 08:37:40PM -0600, Howard Butler wrote: > Now, if you were an an Real American (TM) like me, you would have no > problem voting unknowledgeably. Vetos have the consequences in GEOS' > governance, not +1's :) > I wonder if maybe we shouldn't put the threadsafe API in its own > entire header, but maybe it's too late to muck up the RFC with that > discussion. Being a Real Outsider (TM), I'll give my +1 here (separate header), with no shame of having no voting rights ;) --strk; ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] GEOS on wikipedia
I've stubbed an article on wikipedia about GEOS. http://en.wikipedia.org/wiki/Geomety_Engine,_Open_Source It's been proposed for deletion for being: "Non-notable software" Would you mind showing it's notable to you ? --strk; () ASCII Ribbon Campaign /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS on wikipedia
On Wed, Nov 12, 2008 at 11:25:01AM -0500, Stephen Woodbridge wrote: http://en.wikipedia.org/wiki/Geometry_Engine,_Open_Source > It has no pages linking to it and it references only one other page. I > think you should link it to PostGIS, OSGeo, Mapserver and maybe make a Linked to PostGIS and OSGeo. Does Mapserver make direct use ? > list of projects that are using it. > Also I would add links to OSGeo page > point to the wiki page, and maybe some of the other projects that use > GEOS and are also in wikipedia. Help welcome... --strk; ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Motion: Add Sandro Santilli to GEOS PSC
On Mon, Nov 10, 2008 at 09:30:00AM -0800, Paul Ramsey wrote: > Nevermind, I see the answer in Frank's followup. And your vote is ? :> --strk; > On Mon, Nov 10, 2008 at 9:29 AM, Paul Ramsey <[EMAIL PROTECTED]> wrote: > > Has Sandro indicated his interest in returning to more full involvement? > > > > On Mon, Nov 10, 2008 at 7:43 AM, Howard Butler <[EMAIL PROTECTED]> wrote: > >> PSC Members, > >> > >> I would like to motion to add Sandro Santilli to the PSC. Sandro wrote a > >> lot of GEOS, and his input, direction, and historical perspective is > >> beneficial to the project. ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Motion: Add Sandro Santilli to GEOS PSC
On Thu, Nov 13, 2008 at 10:42:30AM -0800, Paul Ramsey wrote: > Actually, I don't have a vote :) Ouch, it was a trap then ! ':-O --strk; ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Motion: Add Sandro Santilli to GEOS PSC
On Thu, Nov 27, 2008 at 09:10:18AM -0800, Dale Lutz wrote: > +1 With Dale vote we're up to 4. I get Matz and Gary otes are still missing ? /me wonders how useful PSCs are to free software advancement, surely sounds like they slow things down pretty much :) --strk; ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: 3D operations (Re: [geos-devel] C API coordinate sequence dimensions)
On Wed, Jan 14, 2009 at 07:54:21AM +, Mark Cave-Ayland wrote: > Can anyone with more experience with BuildArea (like Martin!) comment on > whether this is a GEOS bug or simply a problem with behaviour > 2 > dimensions being undefined? JTS didn't support 3d when I added it to GEOS, so can't really serve as a source of information. The 3d task was added driven by customer needs, so the only working and tested functions was the one the customer needed. If I recall correctly it was mainly Intersection and probably Union. Since other functions are based on the former, there may be side-effects you wouldn't care about if you aren't using 3d features. Paul draw the specs about expected behaviour. Dunno if there's a doc around and I likely lost mine (Oops). --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.1.0 Last Chance
On Tue, Mar 10, 2009 at 10:39:30AM -0700, Paul Ramsey wrote: > I have placed a tarball here: > http://download.osgeo.org/geos/geos-3.1.0.tar.bz2 > > PSC, please download, compile and check on your platforms/clients of > choice and report back in a day before I make a public announcement. Downloaded built and 'make check'ed successfully on: Debian 4.0 x86_32 Debian 5.0 x86_32 Ubuntu 8.10 x86_64 --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Question
On Tue, Mar 31, 2009 at 11:24:50PM +0800, LiN YongHeng wrote:
> hello everyone, Please look these code:
> GEOSGeom g1, g2;
> g1 = GEOSGeomFromWKT("SRID=5001;POINT(44 31)");
> g1srid = GEOSGetSRID(g1);
> g2 = GEOSGeomFromWKT(GEOSGeomToWKT(g1));
> g2srid= GEOSGetSRID(g2);
> g2srid not have the same value with g1srid, which g1srid value is 5001 and
> g2srid is -1. My GEOS version is "3.1.0". I don't know why? Can anyone give
> me answer
The WKT standard doesn't include a SRID specification,
so GEOSGeomToWKT won't get it. Still GEOSGeomFromWKT
accepts that.
--strk;
Free GIS & Flash consultant/developer () ASCII Ribbon Campaign
http://foo.keybit.net/~strk/services.html /\ Keep it simple!
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] JTS-1.9 Buffer enhancement to be ported
FYI, Safe Software funded me for porting enhancement in Buffer and Valid operation from JTS-1.9 to GEOS. I'm at work already. Thanks Safe. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] geos_ts_c.cpp warning
FYI: this is the only warning I get building GEOS trunk: geos_ts_c.cpp:2132: warning: comparison between signed and unsigned integer expressions --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] SegmentString to become an abstract class
One of the changes introduced in JTS-1.9 is that SegmentString became an abstract class (from a concrete one). I feel comfortable changing that as the C-API won't notice, but I'd like to signal that this would be of course a change in the known-to-be-fragile C++ API and ABI, thus calling for a lib version bump. If anyone has problems with it please scream loud. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Prepared geometry API
While working on a testcase for prepared geometries in GEOS
I've found that the documentation for the "GEOSPrepare" function
doesn't match with actual behaviour:
/*
* Argument ownership is taken by prepared geometry
*/
extern const GEOSPreparedGeometry GEOS_DLL *GEOSPrepare(const GEOSGeometry* g);
Testcase is along these lines:
GEOSGeometry* g = GEOSGeomFromWKT("POLYGON EMPTY");
const GEOSPreparedGeometry* pg = GEOSPrepare(g);
GEOSPreparedGeom_destroy(pg);
// 'g' leaks w/out the call below
//GEOSGeom_destroy(g);
So, is it documentation wrong or implementation ?
--strk;
Free GIS & Flash consultant/developer () ASCII Ribbon Campaign
http://foo.keybit.net/~strk/services.html /\ Keep it simple!
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Memory bug in Prepared geometry
I've just committed a fix for a bad memory bug in PreparedPolygonContainsProperly.cpp into trunk. I suspect it was in latest release too (I haven't checked). If so, I think this would be worth pushing out with a new patch-level release. ref: http://code.google.com/p/postgis/issues/detail?id=147 --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Buffer gets 20 times faster
Good news: bringing the Buffer package in sync with JTS-1.9+ results in some buffer operations completing in 1/20 of the time they used to. In particular, the fme.xml testcase under tests/xmltester runs now in 1.04 seconds while it took ~ 21.89 in geos-3.1.0. This is due to both robustness and performance improvements. Robustness results in the operation being performed only once rather than 3 times each at reduced precision. Performance still beats this much lower the nominal 7 seconds you get by dividing the original time. Time for testing some known dataset here. Paul, where can I find the dataset you used at the Toronto Sprint for such tests ? --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Numerical stability and -ffloat-store flag
Some of you may remember the numerical stability issue I've been struggling with 3 years ago: http://lists.osgeo.org/pipermail/geos-devel/2006-April/002202.html That problem shows up again now that I added a testcase for buffering operation taken from JTS repository: TestBufferExternal2.xml. The test succeeds on a 64bit system, fails on a 32bit one, adding this other variable to the already complex situation. Both me and Mateusz confirmed adding -ffloat-store to CFLAGS fixed the run on 32bit system too, so I suggest we add that flag by default, for improved numerical stability, when available in the compiler. Ok for everyone ? --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] build error on trunk
On Mon, Apr 20, 2009 at 11:33:53AM -0400, Kralidis,Tom [Ontario] wrote: > DiscreteHausdorffDistance.cpp:108: fatal error: opening dependency file > .deps/DiscreteHausdorffDistance.Tpo: Permission denied > compilation terminated. Try a make distclean, also check permissions of the new directories. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Re: GEOS, Shapely, DLLs, and memory (Mateusz Loskot)
On Thu, Apr 30, 2009 at 11:02:51AM -0700, Ragi Y. Burhum wrote: > This shows my ignorance of the C-API :) I have been working exclusively with > the C++ ABI Don't!! :) I'm changing more of the ABI, everytime something improves it's an ABI (and sometimes API) change for C++. C api is rock-solid ! --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS cross-heap problems
On Wed, May 13, 2009 at 12:19:23AM -0400, Frank Warmerdam wrote: > Paul Ramsey wrote: > >I'd like to hear from others on this. > > OK - though I don't see the downside. Downstream packages only need > to check for, and use GEOSFree() if they want. We are just adding a > new option, not altering an existing one or removing anything. Agreed, no compatibility problem adding a GEOSFree. Only, it'll have to stay (I've read Mateusz suggesting using type-specific destroyers). Worth going throught the CAPI header files and properly document when to use GEOSFree on the return right above the function. PS: I've noticed Frank added a ChangeLog entry manually. Was that the way ? As I haven't touched it :( --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Release 3.2.0 plans ?
Hello all, I might have the chance to help with closing up release 3.2.0 so would like to ask you: is there a plan for that already ? --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.2.0 Preparations
On Wed, May 27, 2009 at 12:27:14PM -0700, Paul Ramsey wrote: > I have triaged most of the bugs in the tracker now, and I think we > have a reasonable working set to examine and either fix or defer now > under the 3.2 milestone. Once that list has been worked, we can move > to an RC1 release. > > http://trac.osgeo.org/geos/report/3 Thank you. I got my involvement in the process approved, so I'm with you. I'd give end of June as a release date target, so Safe (who is sponsoring my recent developments) has time to properly test the new code. Ok with all ? If I have enough time I'll also give another pass at packages port syncs so we can call 3.2.0 a JTS-1.10 port w/out being embarassed :) --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] DLL for MSVC
On Fri, Jun 05, 2009 at 09:34:09PM -0700, Ragi Y. Burhum wrote: > Paul, > > Since I don't have TICKET_APPEND privileges, I am attaching the patch file > with my changes for the Windows C++ exports against TRUNK. Patch committed to trunk (revno 2556). Please give it a try, also for your IsValidOp failure (http://trac.osgeo.org/geos/ticket/259) Thanks. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel]
As per http://trac.osgeo.org/geos/ticket/259 GEOS finally uses proper NaN values rather than hand-crafted ones. The downside of this is that we lost compatibility with gcc 2.95.2 which didn't have the header in the companion stdlibc++. The good aspect is closer track of JTS. Tests with current trunk are highly welcome to early catch introduced problems. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] installed C++ headers
It was my idea long time ago to reduce the set of installed C++ headers. Now I've changed my mind. It's too much of a maintainance cost having to be selective on what to install and what not, particularly when the MSVC build scripts don't care and not only install headers but even export symbols which were previously selected as NOT public. Also sometimes headers we'd like not to install are required by others which we want in resulting in a partial hiding. Nowadays, since we're explicitly marking the C++ ABI as incompatible at every release, I wouldn't care about headers that much. Users are warned they shouldn't be using the C++ api, after that if they do they'll deal with API changes somehow. I plan to update the Makefile.ams next week if nobody objects. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] installed C++ headers
FYI: by installing *all* headers the include/geos installed dir gets up to 1928Kb from 1128Kb for 335 header files from 172. I still think it makes sense to do that, at least for consistency (what win users get is what unix users get). --strk; On Sun, Jun 07, 2009 at 12:45:52AM +0200, strk wrote: > It was my idea long time ago to reduce the set > of installed C++ headers. Now I've changed my mind. > > It's too much of a maintainance cost having to be selective > on what to install and what not, particularly when the MSVC > build scripts don't care and not only install headers but > even export symbols which were previously selected as NOT > public. > > Also sometimes headers we'd like not to install are required > by others which we want in resulting in a partial hiding. > > Nowadays, since we're explicitly marking the C++ ABI as > incompatible at every release, I wouldn't care about headers > that much. Users are warned they shouldn't be using the C++ > api, after that if they do they'll deal with API changes > somehow. > > I plan to update the Makefile.ams next week if nobody objects. > > --strk; > > Free GIS & Flash consultant/developer () ASCII Ribbon Campaign > http://foo.keybit.net/~strk/services.html /\ Keep it simple! > ___ > geos-devel mailing list > geos-devel@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/geos-devel -- Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] installed C++ headers
"Let users free to hurt themselves" patch was committed in revision 2557 ... Welcome to the jungle. --strk; On Mon, Jun 08, 2009 at 11:26:59AM +0200, strk wrote: > FYI: by installing *all* headers the include/geos > installed dir gets up to 1928Kb from 1128Kb for 335 > header files from 172. > > I still think it makes sense to do that, at least > for consistency (what win users get is what unix users get). > > --strk; > > On Sun, Jun 07, 2009 at 12:45:52AM +0200, strk wrote: > > It was my idea long time ago to reduce the set > > of installed C++ headers. Now I've changed my mind. > > > > It's too much of a maintainance cost having to be selective > > on what to install and what not, particularly when the MSVC > > build scripts don't care and not only install headers but > > even export symbols which were previously selected as NOT > > public. > > > > Also sometimes headers we'd like not to install are required > > by others which we want in resulting in a partial hiding. > > > > Nowadays, since we're explicitly marking the C++ ABI as > > incompatible at every release, I wouldn't care about headers > > that much. Users are warned they shouldn't be using the C++ > > api, after that if they do they'll deal with API changes > > somehow. > > > > I plan to update the Makefile.ams next week if nobody objects. > > > > --strk; > > > > Free GIS & Flash consultant/developer () ASCII Ribbon Campaign > > http://foo.keybit.net/~strk/services.html /\ Keep it simple! > > ___ > > geos-devel mailing list > > geos-devel@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/geos-devel > > -- > > Free GIS & Flash consultant/developer () ASCII Ribbon Campaign > http://foo.keybit.net/~strk/services.html /\ Keep it simple! > ___ > geos-devel mailing list > geos-devel@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/geos-devel -- Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Question: Cannot access geos::algorithm
On Wed, Jun 24, 2009 at 03:22:31PM -0700, Grace LIN wrote: > Hello, > > I have downloaded and built geos-3.1.1 according to instructions and > everything works perfectly. However it seems like I can only use member > functions from geos::geom, geos::io, and geos::util classes. When I tried > to use call functions from the geos::algorithm::CGAlgorithms, the compiler > gives "'algorithm': the symbol to the left of a '::' must be a type" > error. Access restriction was by design, due to high instability of the C++ API/ABI. You're highly reccommended to use the C-API instead. That said, in current GEOS trunk (upcoming 3.2 release) all headers are installed so that users are free to hurt themselves. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] [GEOS] #275: Topology Exception on valid geometries
On Mon, Jul 06, 2009 at 09:44:40AM -0700, Martin Davis wrote:
> This works in JTS.
It works in trunk too when converted to an XML testcase.
I'll update the trac issue ASAP. Martin: I'd appreciate if
you could follow up there. TIA.
--strk;
> >#275: Topology Exception on valid geometries
> >+---
> > Reporter: yabo| Owner: geos-devel@lists.osgeo.org
> > Type: defect | Status: new
> > Priority: major | Milestone: 3.1.1
> >Component: Default | Version: svn-trunk
> > Severity: Unassigned |Keywords:
> >+---
> > Hi,
> >
> > I've encoutered a situation where two valid geometries (as stated by
> > IsValidOp) throw a Topology Exception when being unioned. The first
> > geometry is a MultiPolygon and the second a Polygon. Unfortunately I
> > couldn't shrink the geometries down to a human-parsable size.
> >
> > I have this problem with both geos-3.1.0 and geos-svn-trunk.
> >
> > The reported error is :
> > {{{
> > TopologyException: found non-noded intersection between -3138.99 39.9929,
> > -3195.93 131.777 and -3145.05 62.5969, -3138.99 39.9929 -3138.99 39.9929
> > }}}
> >
> > I've attached the test program source to the ticket.
> >
> > Thanks,
> >
> >
> >
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] mapserver crash on exit, with svn head geos
On Fri, Jul 17, 2009 at 04:57:01PM -0400, David Fuhry wrote: > With GEOS from svn, mapserver crashes on calling exit(), as GEOS > destroys the static string defined in GEOS' WKBReader.cpp: > > string WKBReader::BAD_GEOM_TYPE_MSG = "bad geometry type encountered in "; Please check that mapserver is not linked to 2 different versions of the geos lib. I have had a similar problem with qgis/gdal due to this problem. A rebuild of both packages fixed it for me. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Porting LengthIndexedLine.project?
On Thu, Jul 23, 2009 at 11:13:34AM -0400, David Turner wrote: > JTS has a class called LengthIndexedLine with a method "project", which > lets you figure out the nearest point on a line to a given point. This > is useful, for instance, if you are trying to figure out what street a > person is on from (possibly slightly inaccurate) GPS observations. > > http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/linearref/LengthIndexedLine.html#project(com.vividsolutions.jts.geom.Coordinate) > > PostGIS calls this function st_line_locate_point. > > GEOS doesn't seem to have it, even though I was under the impression > that GEOS was merely a port of JTS. If I port JTS's project function > and related functions such as extractPoint to GEOS, would that patch be > likely to be accepted? Or am I missing something about the relationship > between JTS and GEOS? Your patch would be welcome. Make sure to include unit testing please. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Porting LengthIndexedLine.project?
Let's ask Martin... Are unit tests for LengthIndexedLine available or to be made ? --strk; On Sat, Aug 01, 2009 at 12:02:07AM -0400, David Turner wrote: > On Mon, 2009-07-27 at 17:42 -0400, David Turner wrote: > > On Thu, 2009-07-23 at 21:53 +0200, strk wrote: > > > On Thu, Jul 23, 2009 at 11:13:34AM -0400, David Turner wrote: > > > > JTS has a class called LengthIndexedLine with a method "project", which > > > > lets you figure out the nearest point on a line to a given point. This > > > > is useful, for instance, if you are trying to figure out what street a > > > > person is on from (possibly slightly inaccurate) GPS observations. > > > > > > > > http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/linearref/LengthIndexedLine.html#project(com.vividsolutions.jts.geom.Coordinate) > > > > > > > > PostGIS calls this function st_line_locate_point. > > > > > > > > GEOS doesn't seem to have it, even though I was under the impression > > > > that GEOS was merely a port of JTS. If I port JTS's project function > > > > and related functions such as extractPoint to GEOS, would that patch be > > > > likely to be accepted? Or am I missing something about the relationship > > > > between JTS and GEOS? > > > > > > Your patch would be welcome. Make sure to include unit testing please. > > > > I have a patch. Unfortunately, I do not yet have unit tests, because I > > cannot find the relevant Java unit tests to port. I could write my own, > > but it seems like some of the other code uses ported Java unit tests, > > and I want to follow the common practice. > > > > Can you point me to the Java unit tests? > > Just wanted to follow up to be sure this wasn't lost. The example I'm > looking at, in case I'm missing something, is: > > tests/unit/algorithm/RobustLineIntersectionTest.cpp > > which claims to be: > > Ported from JTS junit/algorithm/RobustLineIntersectionTest.java > > I assume there are probably similar tests for the linearref stuff, but > the JTS CVS appears to be empty or down or something, and Googling turns > up nothing. > > ___ > geos-devel mailing list > geos-devel@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/geos-devel -- Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Porting LengthIndexedLine.project?
Martin forgot to answer publically, anyway, he mentioned tests are here: test.jts.junit.linearref NOTE: they are only in CVS: :pserver:c...@cvs.jump-project.org:/home/cvs/jts --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! On Sun, Aug 02, 2009 at 03:23:18PM +0200, strk wrote: > Let's ask Martin... > Are unit tests for LengthIndexedLine available or to be made ? > > --strk; > > On Sat, Aug 01, 2009 at 12:02:07AM -0400, David Turner wrote: > > On Mon, 2009-07-27 at 17:42 -0400, David Turner wrote: > > > On Thu, 2009-07-23 at 21:53 +0200, strk wrote: > > > > On Thu, Jul 23, 2009 at 11:13:34AM -0400, David Turner wrote: > > > > > JTS has a class called LengthIndexedLine with a method "project", > > > > > which > > > > > lets you figure out the nearest point on a line to a given point. > > > > > This > > > > > is useful, for instance, if you are trying to figure out what street a > > > > > person is on from (possibly slightly inaccurate) GPS observations. > > > > > > > > > > http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/linearref/LengthIndexedLine.html#project(com.vividsolutions.jts.geom.Coordinate) > > > > > > > > > > PostGIS calls this function st_line_locate_point. > > > > > > > > > > GEOS doesn't seem to have it, even though I was under the impression > > > > > that GEOS was merely a port of JTS. If I port JTS's project function > > > > > and related functions such as extractPoint to GEOS, would that patch > > > > > be > > > > > likely to be accepted? Or am I missing something about the > > > > > relationship > > > > > between JTS and GEOS? > > > > > > > > Your patch would be welcome. Make sure to include unit testing please. > > > > > > I have a patch. Unfortunately, I do not yet have unit tests, because I > > > cannot find the relevant Java unit tests to port. I could write my own, > > > but it seems like some of the other code uses ported Java unit tests, > > > and I want to follow the common practice. > > > > > > Can you point me to the Java unit tests? > > > > Just wanted to follow up to be sure this wasn't lost. The example I'm > > looking at, in case I'm missing something, is: > > > > tests/unit/algorithm/RobustLineIntersectionTest.cpp > > > > which claims to be: > > > > Ported from JTS junit/algorithm/RobustLineIntersectionTest.java > > > > I assume there are probably similar tests for the linearref stuff, but > > the JTS CVS appears to be empty or down or something, and Googling turns > > up nothing. > > > > ___ > > geos-devel mailing list > > geos-devel@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/geos-devel > > -- > > Free GIS & Flash consultant/developer () ASCII Ribbon Campaign > http://foo.keybit.net/~strk/services.html /\ Keep it simple! > ___ > geos-devel mailing list > geos-devel@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/geos-devel ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] [Fwd: [Boost-users] [boost] Formal Review: Boost.Polygon starts today August 24, 2009]
On Wed, Sep 02, 2009 at 11:39:32AM +0200, Barend Gehrels wrote: > I just debugged the Geos area routine, what could then be the reason > that it is relatively slow? It might be that it is accessed as a vector, > indeed, but not as an iterator, so getting points using "return > (*vect)[pos]" is not efficient as it could be using iterators. Besides > that it is probably no problem to make the getAt function inline. getAt is a virtual function, can't be inlined. Templates would make it a lot better, but far away from 1:1 mapping with Java. Beside, how do you handle memory management in GGL ? --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] IMPORTANT: Losing Regression Tests
On Sat, Sep 12, 2009 at 02:43:25PM +0100, Mateusz Loskot wrote: > Paul Ramsey wrote: > > Due to http://trac.osgeo.org/geos/ticket/281 we are about to lose our > > regression test harness. > > > > Consider this an impassioned plea for someone w/ enough C++ chops to > > I've made a quick scan through the test source code and I think it > should be possible to replace CMarkupSTL [1] class with TinyXML. > It is used by XMLTester class [1] only. Committed in r2634. Thanks for the tip. God save the testsuite! --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] missing header
On Tue, Sep 29, 2009 at 03:33:06PM +0200, Christoph Dohmen wrote: > Hi all, > > I'm quite new to geos, but I found a header missing in my installation :-( > The DouglasPeuckerLineSimplifier is described in the online doc but the > DouglasPeuckerLineSimplifier.h include file is listed under noinst_HEADERS > in the Makefile.in. > Is this an error? Or, if not, why is this header not installed? It's a long story. In short the dev team was trying hard to keep users away of the C++ interface. You should really use the C one... Anyway in 3.2.0 (and current trunk) we won't care anymore and let users free to hurt themselves. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] 3.2.0 closeup
Guys, what about cutting up a 3.2.0 release ? Significative changes since 3.1: - Add Single-sided buffer operation - JTS-1.10 sync ... - Drastically improved Buffer speed - Improved EdgeList duplicate edge finding - Added algorithm::distance package - Added algorithm::Angle class - Added algorithm::BoundaryNodeRule class - IsSimpleOp can now return non-simple location coordinate - DistanceOp can now check for 'within distance' predicate (earlier exit) - MultiPolygon::getBoundary always return MultiLineString, also when the result is the EMPTY geometry. May I ask anyone with pending tasks on trac to take a look at them ? http://trac.osgeo.org/geos/report/3 I'd like to close up a 3.2.0 before the end of the year (but sooner is better) Thanks --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] How to build a multipolygon from a list of rings?
Consider looking at shp2pgsql.c from PostGIS project. It does contain code to build SFS geometries out of a set of rings. --strk; On Fri, Oct 09, 2009 at 02:51:55PM +0800, zhuliangxi...@hotmail.com wrote: > Hi there, > > I have a list of rings which are read from shapefile. all out rings are > clockwise and all hole rings are counterclockwise. After reading the OGC > spec, it seems that i have to decide for each hole ring that to which out > ring it belongs. Which means i have to build a list of Polygon first and then > build a MultiPolygon. > > how could i build a MultiPolygon from a list of rings directly? It is hard > for me to find out the relationship of holes and out rings. > > Regards, > Abe Zhu > ___ > geos-devel mailing list > geos-devel@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/geos-devel -- Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] blowing up on negative value buffer() call
On Fri, Oct 30, 2009 at 02:23:17PM -0700, Leo Shklovskii wrote: > Unfortunately, I've found several polygons that are valid but cause the > first call to buffer() to blow up (memory leak + spiked cpu + doesn't > return). > > Should I file this as a GEOS bug? or am I not using buffer() correctly? Negative buffer is supported, so looks like a bug. The best report would be in the form of an XML test. See tests/xmltester/tests/TestBufferExternal2.xml for examples on how to format a testcase for negative buffers. Or feel free to just report your input polygon WKT. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] 3.2.0rc1 tagged
Cheers all. GEOS 3.2.0 is ready for test. I've tagged a 3.2.0rc1. Please take your time to try upgrades against your existing clients. C-API clients should get the new functionalities for free (much faster buffer operation for example). C++ clients would need a rebuild as usual. Get with: svn co http://trac.osgeo.org/geos/browser/tags/3.2.0rc1 I'd tag final after a week of no issues reported. Thank you. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.2.0rc1 tagged
For the record, it's here: http://download.osgeo.org/geos/geos-3.2.0rc1.tar.bz2 Thanks Paul. --strk; On Thu, Nov 12, 2009 at 12:20:01PM -0800, Paul Ramsey wrote: > FYI, URL is wrong: > > svn co http://svn.osgeo.org/geos/tags/3.2.0-rc1 > > I'll build a tarball for posting. > > P > > On Wed, Nov 11, 2009 at 11:32 PM, strk wrote: > > Cheers all. > > GEOS 3.2.0 is ready for test. > > I've tagged a 3.2.0rc1. > > Please take your time to try upgrades against > > your existing clients. > > > > C-API clients should get the new functionalities > > for free (much faster buffer operation for example). > > > > C++ clients would need a rebuild as usual. > > > > Get with: > > svn co http://trac.osgeo.org/geos/browser/tags/3.2.0rc1 > > > > I'd tag final after a week of no issues reported. > > Thank you. > > > > --strk; > > > > Free GIS & Flash consultant/developer () ASCII Ribbon Campaign > > http://foo.keybit.net/~strk/services.html /\ Keep it simple! > > ___ > > geos-devel mailing list > > geos-devel@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/geos-devel > > > ___ > geos-devel mailing list > geos-devel@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/geos-devel -- Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.2.0rc1 tagged
On Fri, Nov 13, 2009 at 04:13:14PM -0500, Obe, Regina wrote: > > Now for VC++ 2009 express, I tried compiling and it seems I need inttypes.h? > I don't recall that being a dependency before (GEOS 3.1) or maybe I always > had it before on my prior boxes and didn't know it. Was in 3.1 too, and only in platform.h. Maybe you need to copy platform.h.vc to platform.h ? --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.2.0rc1 tagged
On Tue, Nov 17, 2009 at 01:36:40PM -0500, Obe, Regina wrote: > Also just curious - what is the reason why autogen.bat is not packaged in the > tar ball? Seems a bit of a pain to have to > go to svn for that file. Users of proprietary systems must suffer ;) > This file is missing in the package > > ..\..\..\tests\unit\capi\GEOSGeomFromWKBTest.cpp Good catch, it's missing from Makefile.am as well. I'll take a look (and ok, I'll add the autogen.bat too) --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] autogen.bat
On Tue, Nov 17, 2009 at 09:24:08PM +0100, strk wrote: > On Tue, Nov 17, 2009 at 01:36:40PM -0500, Obe, Regina wrote: > > > Also just curious - what is the reason why autogen.bat is not packaged in > > the tar ball? Seems a bit of a pain to have to > > go to svn for that file. > > Users of proprietary systems must suffer ;) I've found this in autogen.bat: REM NOTE: DO NOT include this script in GEOS sources distribution Author seems to be Mateusz. Mat, reason ? --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] GEOSGeomFromWKBTest.cpp
On Tue, Nov 17, 2009 at 09:24:08PM +0100, strk wrote: > On Tue, Nov 17, 2009 at 01:36:40PM -0500, Obe, Regina wrote: > > This file is missing in the package > > > > ..\..\..\tests\unit\capi\GEOSGeomFromWKBTest.cpp > > Good catch, it's missing from Makefile.am as well. > I'll take a look (and ok, I'll add the autogen.bat too) It's in as of r2716. Please go on testing before an rc2. Thanks. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Benchmark between various geometry libraries
On Wed, Nov 18, 2009 at 11:02:13AM -0800, Martin Davis wrote: > Thanks for clarifying this, Hartmut. This makes good sense to me. In > my (admittedly limited and dated) experience, the C/C++ heap allocator > (good ol' malloc still, right?) is pretty slow. From what you're saying > stack allocation is substantially faster. > > The kind of change you indicated should be fairly simple to make in the > GEOS codebase. I occasionally did rounds of such cleanups, but I think more time is spent in copying read-only coordinates for the sake of memory management while the JTS counterpart passes pointers around and delegates memory management to the garbage collector. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Benchmark between various geometry libraries
On Thu, Nov 19, 2009 at 05:16:53PM +0100, Maxime van Noppen wrote: > > ~/dev/geos/trunk $ grep 'new std' `find . -iname '*.cpp'` Thanks for another couple of eyes (see below for comment/fixes). > > ./capi/geos_ts_c.cpp:std::vector* vgeoms = new > > std::vector(geoms, geoms + ngeoms); [...] > > ./capi/geos_ts_c.cpp:std::vector *vholes = new > > std::vector(holes, holes + nholes); The above are heap-allocated to transfer their ownership to the collection constructed with them. Should be auto_ptr for clarity and exception safety (GeometryFactory interface needs to be extended to allow that). > > ./tests/unit/geom/CoordinateListTest.cpp: std::auto_ptr< > > std::vector > col( new std::vector() ); [...] > > ./tests/xmltester/XMLTester.cpp: > > std::vector*newgeoms = new std::vector > *>(lines->begin(), Tests, not much important. > > ./source/index/strtree/AbstractNode.cpp:childBoundables=new > > std::vector(); Fixed by http://trac.osgeo.org/geos/changeset/2724 > > ./source/operation/polygonize/PolygonizeGraph.cpp: > > intNodes=new std::vector(); Fixed by http://trac.osgeo.org/geos/changeset/2725 > > ./source/operation/polygonize/PolygonizeGraph.cpp: > > std::vector *edgeRingList=new std::vector(); Fixed by http://trac.osgeo.org/geos/changeset/2726 (this is a C++ API change but of an "internal" class) > > ./source/operation/polygonize/PolygonizeGraph.cpp: > > std::vector *edgeRingStarts=new > > std::vector(); Fixed by http://trac.osgeo.org/geos/changeset/2727 > > ./source/operation/polygonize/PolygonizeGraph.cpp: std::vector > LineString*> *cutLines=new std::vector(); Fixed by http://trac.osgeo.org/geos/changeset/2728 ... just moving the heap allocation closer to the surface, will need a second pass ... > > ./source/operation/polygonize/PolygonizeGraph.cpp: > > std::vector *edges=new std::vector(); Fixed by http://trac.osgeo.org/geos/changeset/2729 > > ./source/operation/polygonize/PolygonizeGraph.cpp: std::vector > LineString*> *dangleLines=new std::vector(); Fixed by http://trac.osgeo.org/geos/changeset/2730 ... just moving the heap allocation closer to the surface, will need a second pass ... > > ./source/operation/buffer/BufferBuilder.cpp: new std::vector< Geometry > > * >(); > > ./source/operation/buffer/BufferBuilder.cpp: std::vector< Geometry* >* > > mergedLinesGeom = new std::vector< Geometry* >(); Constructive again, should be auto_ptr when GeometryFactory is ready > > ./source/operation/valid/ConnectedInteriorTester.cpp: > > std::vector *edgeRings=new std::vector(); Fixed by http://trac.osgeo.org/geos/changeset/2731 > > ./source/geomgraph/DirectedEdgeStar.cpp:resultAreaEdgeList=new > > std::vector(); This is for lazy creation, will only be called once per instance, could be changed by adding a flag to remember whether processing happened already, but I don't think it will change things much. > > ./source/noding/MCIndexSegmentSetMutualIntersector.cpp::monoChains( > > new std::vector()), Fixed by http://trac.osgeo.org/geos/changeset/2732 > > ./source/planargraph/Node.cpp: std::vector* commonEdges = new > > std::vector(); This is in a method marked as UNUSED --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Benchmark between various geometry libraries
On Thu, Nov 19, 2009 at 10:14:17AM -0700, Martin Chapman wrote: > Also, I noticed a long time ago that GEOS passes these vectors around to > functions by value versus by reference. That means the vector is getting > copied a lot. I don't know if this has changed since then but that would be > a performance killer as well. Vectors are no more passed by value. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Re: autogen.bat
On Tue, Nov 17, 2009 at 11:16:28PM +, Mateusz Loskot wrote: > I assumed that GEOS distribution is supposed to already > provide generated and valid version.h and platform.h and geos_c.h Uhm, those are distributed indeed. Regina, do you still need autogen.bat to complete a build out-of-the-box ? --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Benchmark between various geometry libraries
On Thu, Nov 19, 2009 at 02:36:30PM -0700, Martin Chapman wrote: > For my own knowledge, did you see a decent performance gain when you made > the change or was it only a small increase in speed? Generally speaking, the biggest performance gains I've ever seen in GEOS had origin in algorithmical changes. Always driven by JTS code. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Benchmark between various geometry libraries
On Fri, Nov 20, 2009 at 06:42:53PM +0100, Maxime van Noppen wrote: > I looked for any 'new std::something' but I just found there are 'using > namespace std;' in the code, and therefore we should also look for 'new > something'. I found 120 'new vector' out of 656 'new something' : Yeah, I knew it :) > > ./doc/example.cpp:297: vector *holes = new vector; > > ./tests/bigtest/bug234.cpp:17: vector< Geometry * > *polys1 = new > > vector(); Examples and tests we don't care... > > ./source/planargraph/NodeMap.cpp:70:vector *values=new > > vector(); Fixed by http://trac.osgeo.org/geos/changeset/2724 > > ./source/geom/GeometryFactory.cpp:238: CoordinateSequence > > *cl=coordinateListFactory->create(new vector(1, coordinate)); This is a factory, it's meant to allocate things. In the specific cases it create these vectors to transfer their ownership to the Geometry objects it constructs. > > ./source/geom/Geometry.cpp:567: vector *v = new > > vector(); Same as above, allocated for ownership transfer. Optimized allocations for elements by http://trac.osgeo.org/geos/changeset/2734 Beside, this is not even used by the C-API ... Well, a lot of these are likely unused places after all so I stop here :) I think the correct way to proceed if we want to make GEOS any faster would be understanding what's making it slow in the first place. The Area() timing is interesting because it's obvious where the difference between GEOS and GGL is : coordinates access. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] 3.2.0-rc2 tagged
For the sake of heap allocation reductions... svn co http://svn.osgeo.org/geos/tags/3.2.0-rc1 --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.2.0-rc2 ready for download/test
And here's the tarball: http://download.osgeo.org/geos/geos-3.2.0rc2.tar.bz2 --strk; On Tue, Nov 24, 2009 at 07:16:20PM +0100, strk wrote: > For the sake of heap allocation reductions... > svn co http://svn.osgeo.org/geos/tags/3.2.0-rc1 > > --strk; > > Free GIS & Flash consultant/developer () ASCII Ribbon Campaign > http://foo.keybit.net/~strk/services.html /\ Keep it simple! > ___ > geos-devel mailing list > geos-devel@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/geos-devel -- Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] platform.h and config.h
I've added ISNAN detection result in platform.h instead. config.h seems to be unused except from a profiler.h file which probably doesn't need it in turn.. I'd drop config.h (after release though). Please test r2748. (./configure sould do, no need to autogen.sh again) --strk; On Thu, Nov 26, 2009 at 12:40:29PM -0800, Paul Ramsey wrote: > I'm tracking down a build failure in Solaris, which is happening because the > code is trying to use an std::isnan() that is not there. It is odd, because > ./configure is correctly detecting the presence of a cmath isnan(), but the > code isn't using it. > > What I am seeing is that platform.h has the proper switches in place to > handle the problem, but nowhere is config.h, which contains the results of > the configure run included, so the switches never actually move. > > Can someone confirm my diagnosis and solution (add config.h into platform.h > at the top) before I make this core change to the build? > > Paul___ > geos-devel mailing list > geos-devel@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/geos-devel -- Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Holes in holes
On Fri, Nov 27, 2009 at 02:47:17AM +0100, Frederik Ramm wrote: > I have another remotely related question, that concerns the direction of > a polygon ring (CW or CCW). When I create a polygon with the > createPolygon factory method and pass it a number of rings, do I have to > take care that they spin in the right direction, or will GEOS make sure > that a correct polygon is created? The createPolygon method takes an explicit shell and a list of holes. You don't need to care about direction. GEOS won't check validity automatic. Use Geometry::isValid() if you want to check that. Any ring direction is OGC valid. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Find self-intersections
What do you really need to do at the end of the day ?
Want a simple ring ? A polygon ?
--strk;
On Fri, Nov 27, 2009 at 05:22:22PM +0100, Frederik Ramm wrote:
> Hi,
>
>today I came across the following problem that I tried to solve with
> GEOS.
>
> I had 3.000 linestrings which together formed one large ring. However,
> this ring was not simple; it was 8-shaped. I wanted to find out where
> the intersection point - or perhaps the intersection line! - was.
>
> The best I could come up with was:
>
> for (i=0; i {
>for (j=i+1; j{
> Geometry *p = linestring[i]->intersection(linestring[j])
> if (p)
> {
> // found something
> }
>}
> }
>
> This is of course rather inefficient! I'd better build a LinearRing from
> the lot of them and then query for self-intersection. I did find some
> code that does this when looking at how isSimple() is implemented;
> however, that code would only find self intersection points, not lines.
>
> I wonder if there is some generic way to determine a geometry's "self
> intersection"?
>
> Bye
> Frederik
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Free GIS & Flash consultant/developer () ASCII Ribbon Campaign
http://foo.keybit.net/~strk/services.html /\ Keep it simple!
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] 3.2.0-rc3 tagged
Packaging and platform support tweaks mostly. Please take another loop, this could be final. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Another cleanup pass on 3.2.0 ongoing
FYI, Mateusz is doing a cleanup pass on trunk. He mentioned it should be done in a week. I think it's worth waiting till then and ship an rc4. If anyone is concerned with that please let me know. TIA --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.2 RC4?
On Tue, Dec 08, 2009 at 08:01:25AM -0800, Paul Ramsey wrote: > Thanks to Mats for taking the cleanup run through the code! I would > like to cut one more RC, anyone have objections, fixes-in-progress? Just closed a couple ([1], [2]) of fresh tickets and am now ready for rc4. [1] http://trac.osgeo.org/geos/ticket/305 [2] http://trac.osgeo.org/geos/ticket/307 --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.2 RC4?
On Tue, Dec 08, 2009 at 07:04:26PM +0100, strk wrote: > On Tue, Dec 08, 2009 at 08:01:25AM -0800, Paul Ramsey wrote: > > Thanks to Mats for taking the cleanup run through the code! I would > > like to cut one more RC, anyone have objections, fixes-in-progress? > > Just closed a couple ([1], [2]) of fresh tickets and am > now ready for rc4. Actually, distcheck is failing: make[2]: *** No rule to make target `geos.vsprops', needed by `distdir'. Stop. Mat ? --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.1 vs 3.2
On Tue, Dec 08, 2009 at 02:12:38PM -0800, Paul Ramsey wrote: > Not sure what this means, but: > 3.1 > 3.2 > > > Files: 20 > Files: 58 > Tests: 2216 > Tests: 3582 > Failed: 0 > Failed: 0 > Succeeded: 2216 > Succeeded: 3582 > PASS: testrunner> PASS: testrunner > > > real 0m29.194s > real 0m11.558s > user 0m24.750s > user 0m10.630s > sys 0m1.489s > sys 0m0.230s Much more tests in less of half the time ! It seems to mean 3.2.0 rocks :) --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Benchmark between various geometry libraries
On Wed, Dec 09, 2009 at 05:13:15PM +0100, Maxime van Noppen wrote: > Maxime van Noppen wrote: > > I will post any numbers I get. > > I'm still far from having a solid and complete report but just to give > you a taste : on 100 intersections dynamic allocations represent 25.01% > of the time cost (17.14% spent allocating, 7.87% deallocating). > > I've also found several small optimizations that can lead to significant > performance boosts. For example, on the 100 intersection benchmark I > found that 10% of the time was spent in CoordinateArraySequence::getAt. > The fact is that as the code is in the .cpp file it cannot be inlined by > the compiler. So I juste moved the one-line code of the .cpp file to the > .h file and the runtime cost dropped drastically (to ~ 2%). CoordinateArraySequence::getAt is a virtual function, which is probably the reason why the fully templated solution is much faster instead. How can a virtual method be inlined by the compiler ? --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.2.0 Final
On Thu, Dec 10, 2009 at 12:30:43PM -0800, Paul Ramsey wrote: > Shall we release 3.2.0 final? Things seem quiet... I've fixed a reported leak in r2822. r2823 also contains an updated ChangeLog. Ready for final myself. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.2.0 Final
On Fri, Dec 11, 2009 at 11:49:54AM +0100, Barend Gehrels wrote: > Hi, > > Maybe you can consider removing (or altering) this statement from the > documentation main page: "If you prefer troubles you can use the C++ > interface. " (in geom.h). It's still troubles ! how would you reword it ? Leaks, API/ABI instabilities... --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Re: Return value of GEOSGeom_getDimensions_r
On Fri, Dec 11, 2009 at 07:51:37AM -0500, Alex Trofast wrote: > If this is the case am I misunderstanding what GEOSGeom_getDimensions_r > is actually supposed to do: return 0 for point, 1 for curve, 2 for surface? > Any help is greatly appreciated, It's the number of ordinates used in the geometry (2 or 3, but will always be 3 atm). Pretty useless method indeed. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.2.0 Final
On Fri, Dec 11, 2009 at 08:22:31PM +0100, Barend Gehrels wrote: > Leaks? The C Api just wraps it... The C Api wraps a small portion of the C++ API. The thing is that in C++ there are *a lot* of interfaces exposed which should not be. You might have noticed that many of the headers were not installed up to 3.1.x. This was an attempt to reduce the set of exposed interface. Remember that GEOS is a direct port of JTS, where (in Java) there are visibility levels that are not supported in C++ (default visibility == only classes in same package can use those interfaces). In GEOS those all became public instead. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.2.0 Final
On Fri, Dec 11, 2009 at 03:55:54PM -0500, Frank Warmerdam wrote: > I am not aware of memory leaks related to the C++ API, and if there are some > there is no reason not to fix them. I'm not aware either, but it may happen because the clients we test GEOS again all use the C Api, which doesn't expose the leaks itself. I just fixed a couple of leaks reported by a C++ API user in methods that would never be called by the C-Api, that's why I mentioned them. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.2.0 Final
On Sat, Dec 12, 2009 at 10:04:26AM +0100, Maxime van Noppen wrote: > strk wrote: > > Remember that GEOS is a direct port of JTS, where (in Java) > > there are visibility levels that are not supported in C++ > > (default visibility == only classes in same package can use > > those interfaces). In GEOS those all became public instead. > > I believe it's a design issue. It could be possible to put those methods > as protected and to define friend classes that have access to those methods. Yes but then we'll have to add new friends everytime a new class is added and it's something increasing the maintainance cost. If we could mark a whole namespace as a friend that'd be 1:1 mapping with JTS I guess, and no additional maintainance cost. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.2.0 Final
On Fri, Dec 11, 2009 at 03:55:54PM -0500, Frank Warmerdam wrote: > I would suggest "If you prefer troubles you can use the C++ interface" > to "Applications requiring API/ABI stability are encouraged to use the > C interface instead of the C++ interface." I changed: << If you prefer troubles you can use the C++ interface. >> with: << If you don't care about adapting/rebuilding your client code you can still use the C++ interface. >> Your statement was already in previous statement: << The recommended low-level interface to the GEOS library is the simplified C wrapper interface. This will ensure stability of the API and the ABI of the library during performance improvements that will likely change classes definitions. >> --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.2.0 release ready for download
On Mon, Dec 14, 2009 at 06:39:21PM -0500, Greg Troxel wrote: > The shlib major version changed; probably NEWS should mention that. GEOS has 2 shared libraries. The one implementing the C++ API and the one implementing the C API. While we maintain proper library versioning for the C API, we don't for the C++ one, due to the way too wide set of exposed interfaces we should look at to figure when ABI was or wasn't broken (and in C++ land ABI breaks SO easily). > Are > there incompatible ABI changes? For the C++ shlib, most likely. > (From a packaging point of view, shlib > version changes when there aren't actually ABI changes generates work > that could be avoided; all depending packages need a version change > because they only interoperate with one or the other geos version.) This is exactly the reason why we incourage use of the C library (libgeos_c.so). The C library hard continues to expose a compatible ABI to the ABI-incompatible C++ library. So, while GEOS 3.2.0 *c++* lib is a few steps away from GEOS 3.0.0 *c++* lib, any code which linked against the *c* lib in GEOS 3.0.0 will still work with the *c* lib of GEOS 3.2.0. >From a packaging point of view you should likely properly encode if a client is dependent on *libgeos* or *libgeos_c* as that makes a big difference. Is this too much confusing ? --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.2.0 release ready for download
On Tue, Dec 15, 2009 at 10:59:01AM -0500, Greg Troxel wrote: > > strk writes (reordered) > > > Is this too much confusing ? > > Yes :-) So here are the results of the build on NetBSD with pkgsrc. The > build is very default, with the only change being putting @LDFLAGS@ into > geos-config so that rpath works right. So here are the results: > > For 3.1: > > -rwxr-xr-x 1 root wheel 1703998 Dec 15 10:27 libgeos-3.1.0.so > lrwxr-xr-x 1 root wheel 16 Dec 15 10:27 libgeos.so -> libgeos-3.1.0.so > lrwxr-xr-x 1 root wheel 18 Dec 15 10:27 libgeos_c.so -> > libgeos_c.so.1.5.0 > lrwxr-xr-x 1 root wheel 18 Dec 15 10:27 libgeos_c.so.1 -> > libgeos_c.so.1.5.0 > -rwxr-xr-x 1 root wheel 103071 Dec 15 10:27 libgeos_c.so.1.5.0 > > For 3.2: > > -rwxr-xr-x 1 root wheel 1894950 Dec 14 18:29 libgeos-3.2.0.so > lrwxr-xr-x 1 root wheel 16 Dec 14 18:29 libgeos.so -> libgeos-3.2.0.so > lrwxr-xr-x 1 root wheel 18 Dec 14 18:29 libgeos_c.so -> > libgeos_c.so.1.6.0 > lrwxr-xr-x 1 root wheel 18 Dec 14 18:29 libgeos_c.so.1 -> > libgeos_c.so.1.6.0 > -rwxr-xr-x 1 root wheel 133825 Dec 14 18:29 libgeos_c.so.1.6.0 Sounds good to me. As you can see the SONAME for libgeos_c.o hasn't changed (libgeos_c.so.1) while the one for libgeos is (libgeos-3.1.0.so vs libgeos-3.2.0.so). What I expect is that if you compile a couple simple test program one with -lgeos and the other with -lgeos_c while only 3.1 is installed, then when you install 3.2 the one compiled with -lgeos_c will automatically use functionalities of libgeos-3.2.0.so while the other will be strictly bound to libgeos-3.1.0.so. Can you confirm ? --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Installation of Postgis/postgresql
On Mon, Dec 28, 2009 at 07:43:08PM -0800, Nick Uebelhor wrote: > during ./configure of geos errors out looking for g++ > > to the best of my knowledge g++ is part of gcc and we have a current > version of the gcc compiler on the computer GCC is big so distributors usually split the binary packages by different runtimes and dev environment. Make sure to install the GNU C++ compiler. --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Missing file in Makefile.vc
On Tue, Dec 15, 2009 at 01:04:11PM -0500, Glenn Waldron wrote: > I wish I'd caught this before the 3.2 release, but > geom/CoordinateSequenceFactory is missing from source/Makefile.vc. The fixed > makefile.vc is attached. Glen, was this applied ? If not, could you put it on trac ? --strk; Free GIS & Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk/services.html /\ Keep it simple! ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] [#317] Build configuration for CMake build system
On Mon, Jan 18, 2010 at 09:31:26PM +, Mateusz Loskot wrote: > I have added GEOS build configuration for CMake (http://www.cmake.org/) > build system. Great! I've tried the "cmake ../trunk && make" run and got linking error: Linking CXX executable geos_unit CMakeFiles/geos_unit.dir/geostest2.cpp.o: In function `main': geostest2.cpp:(.text+0x588): multiple definition of `main' CMakeFiles/geos_unit.dir/geos_unit.cpp.o:geos_unit.cpp:(.text+0x6f2): first defined here CMakeFiles/geos_unit.dir/bug176.cpp.o: In function `do_sir()': bug176.cpp:(.text+0x0): multiple definition of `do_sir()' CMakeFiles/geos_unit.dir/geostest2.cpp.o:geostest2.cpp:(.text+0x0): first defined here CMakeFiles/geos_unit.dir/bug176.cpp.o: In function `do_buffer()': bug176.cpp:(.text+0x16a): multiple definition of `do_buffer()' CMakeFiles/geos_unit.dir/geostest2.cpp.o:geostest2.cpp:(.text+0x16a): first defined here CMakeFiles/geos_unit.dir/bug176.cpp.o: In function `main': bug176.cpp:(.text+0x588): multiple definition of `main' CMakeFiles/geos_unit.dir/geos_unit.cpp.o:geos_unit.cpp:(.text+0x6f2): first defined here collect2: ld returned 1 exit status Is the above expected ? SVN At revision 2876. Funny enough, on second 'make' run, after those error, I get an error earlier: [ 0%] Building CXX object src/CMakeFiles/geos.dir/algorithm/distance/DiscreteHausdorffDistance.cpp.o In file included from /usr/src/geos/trunk/include/geos/algorithm/distance/PointPairDistance.h:24, from /usr/src/geos/trunk/include/geos/algorithm/distance/DiscreteHausdorffDistance.h:23, from /usr/src/geos/trunk/src/algorithm/distance/DiscreteHausdorffDistance.cpp:20: /usr/src/geos/cmake_build/include/geos/platform.h:147:3: error: #error "Could not find finite or isfinite function or macro!" make[2]: *** [src/CMakeFiles/geos.dir/algorithm/distance/DiscreteHausdorffDistance.cpp.o] Error 1 make[1]: *** [src/CMakeFiles/geos.dir/all] Error 2 --strk; () Free GIS & Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] [#317] Build configuration for CMake build system
On Wed, Jan 20, 2010 at 11:05:40PM +, Mateusz Loskot wrote: > strk wrote: > > /usr/src/geos/cmake_build/include/geos/platform.h:147:3: error: #error > > "Could not find finite or isfinite function or macro!" > > make[2]: *** > > [src/CMakeFiles/geos.dir/algorithm/distance/DiscreteHausdorffDistance.cpp.o] > > Error 1 > > make[1]: *** [src/CMakeFiles/geos.dir/all] Error 2 > > Yes, I was playing with the platform.h a bit and then I was gradually > fixing this kind of issues about missing isnan or isfinite on various > systems. So, something may be still not working well on some environments. > > However, remember to remove old versions of platform.h > if you have any, for instance generated by autoconf > build in trunk/include/geos. It may cause problems. No platform.h in source tree. The platform.h in build tree is created by cmake from platform.h.cmake (I double-checked by removing and running cmake again) --strk; () Free GIS & Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Build and install instructions
On Wed, Jan 27, 2010 at 11:52:47PM +, Mateusz Loskot wrote: > Hi, > > I reorganised the Build and Install instructions a bit: > > http://trac.osgeo.org/geos/wiki#BuildandInstall > > Please, update if anything is missing or buggy. May I ask for 'make check' rather than 'make test' for the Test TODO item ? 'check' is a GNU standard rule. --strk; () Free GIS & Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Quick cmake/autotools comparison on OpenSUSE
FYI. Only 'make' was timed, no ./configure nor cmake runs. > cat cmake/TIMING real7m18.909s user6m11.319s sys 0m42.419s > cat autotools/TIMING time make - real7m58.631s user7m1.418s sys 0m43.067s --strk; () Free GIS & Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] cmake does not recognize sub-command RENAME
GEOS revision 2893. CMake Error at CMakeLists.txt:204 (file): file does not recognize sub-command RENAME cmake version 2.6-patch 0 --strk; () Free GIS & Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] [#317] Build configuration for CMake build system
On Sat, Jan 30, 2010 at 04:05:50AM +, Mateusz Loskot wrote: > The geostest no longer exists in tests/unit > I presume you are have old source tree nodes still in your copy. I tried with r2901 on a debian 5.0.3 (sorry if I'm following up with different systems, just I can't find the time to be single threaded). Here the cmake build succeeds, but make check fails (fails tests, not build): Scanning dependencies of target check Start processing tests Test project /usr/src/geos/cmake 1/ 2 Testing geos_unitPassed 2/ 2 Testing xmltester ***Failed 50% tests passed, 1 tests failed out of 2 The following tests FAILED: 2 - xmltester (Failed) Errors while running CTest make[3]: *** [CMakeFiles/check] Error 8 make[2]: *** [CMakeFiles/check.dir/all] Error 2 make[1]: *** [CMakeFiles/check.dir/rule] Error 2 make: *** [check] Error 2 --strk; () Free GIS & Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] cmake build on ubuntu-8.04
Ubuntu 8.04 cmake build attempt:
$ cmake ../trunk
CMake Error at CMakeLists.txt:220 (if):
if had incorrect arguments: ${CMAKE_VERSION} VERSION_LESS "2.8.0" (Unknown
arguments specified).
...
$ cmake --version
cmake version 2.6-patch 0
What's the min version supported ?
--strk;
() Free GIS & Flash consultant/developer
/\ http://foo.keybit.net/~strk/services.html
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] cmake: geos-config
cmake based installation results in a broken geos-config script. geos-config --ldflags, which is used by postgis, returns '-L'. --strk; () Free GIS & Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Unary Union (was: rgeos interface to R classes)
On Mon, Feb 01, 2010 at 09:48:57AM -0800, Martin Davis wrote: > The technique of using buffer(0) to union polygons is now deprecated in > favour of using Unary Union (Geometry.union() - not sure what the exact > GEOS signature is). Unary Union is usually faster and more robust than > the previous technique. You might want to check this out. Uhm, I might have missed this in my last port (either completely or just the outer interface). Is the JTS repository finally landed so to take a look ? I'm interested in evaluating its use for "geometry cleanup" purposes (http://trac.osgeo.org/postgis/ticket/399) --strk; () Free GIS & Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Re: cmake: geos-config
On Thu, Feb 04, 2010 at 11:38:15PM +, Mateusz Loskot wrote:
> strk wrote:
> > cmake based installation results in a broken geos-config
> > script. geos-config --ldflags, which is used by postgis,
> > returns '-L'.
>
> Sandro,
>
> Thanks for catching it. Fixed in trunk.
Excellent.
Did you reintroduce or still haven't fixed this ?
CMake Error at CMakeLists.txt:220 (if):
if had incorrect arguments: ${CMAKE_VERSION} VERSION_LESS "2.8.0" (Unknown
arguments specified).
--strk;
() Free GIS & Flash consultant/developer
/\ http://foo.keybit.net/~strk/services.html
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Re: cmake: geos-config
On Fri, Feb 05, 2010 at 09:33:45PM +, Mateusz Loskot wrote:
> strk wrote:
> > On Thu, Feb 04, 2010 at 11:38:15PM +, Mateusz Loskot wrote:
> >> strk wrote:
> >>> cmake based installation results in a broken geos-config
> >>> script. geos-config --ldflags, which is used by postgis,
> >>> returns '-L'.
> >> Sandro,
> >>
> >> Thanks for catching it. Fixed in trunk.
> >
> > Excellent.
> > Did you reintroduce or still haven't fixed this ?
> >
> > CMake Error at CMakeLists.txt:220 (if):
> > if had incorrect arguments: ${CMAKE_VERSION} VERSION_LESS "2.8.0" (Unknown
> > arguments specified).
>
> OK, should be fixed now:
>
> http://trac.osgeo.org/geos/ticket/317#comment:29
Nice. Works here. Thanks.
Time to move on improving 'make check' now :)
--strk;
() Free GIS & Flash consultant/developer
/\ http://foo.keybit.net/~strk/services.html
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] cmake: distclean-like ? out of source tree build ?
Mat, is there a 'cleanup' command for cmake-prepared build trees ? I start to suspect my source tree was 'infected' by cmake things :) Like: build$ cmake ../trunk # does things but *build* dir is empty build$ cd ../trunk trunk$ cmake . && make ... CMakeFiles/geos_unit.dir/geostest2.cpp.o: In function `main': /usr/src/geos/trunk/tests/unit/geostest2.cpp:56: multiple definition of `main' CMakeFiles/geos_unit.dir/geos_unit.cpp.o:/usr/src/geos/trunk/tests/unit/geos_unit.cpp:56: first defined here Didn't you fix the last error ? (which is what makes me think there might be something old around). --strk; () Free GIS & Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] What do GEOSSymDifference and GEOSIntersection (CAPI) do?
On Wed, Feb 10, 2010 at 10:46:33AM +0100, Roger Bivand wrote: > Continuing to try to interface R and GEOS (CAPI), I am puzzled that > GEOSSymDifference() and GEOSIntersection() seem to require input objects > to be "Geometry must be a Point or LineString". Sounds like an horrible bug, if confirmed. Could you file a ticket with accompaining smallest C testcase showing it ? --strk; () Free GIS & Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] What do GEOSSymDifference and GEOSIntersection (CAPI) do?
On Wed, Feb 10, 2010 at 12:00:31PM +0100, Roger Bivand wrote: > On Wed, 10 Feb 2010, strk wrote: > > >On Wed, Feb 10, 2010 at 10:46:33AM +0100, Roger Bivand wrote: > >>Continuing to try to interface R and GEOS (CAPI), I am puzzled that > >>GEOSSymDifference() and GEOSIntersection() seem to require input objects > >>to be "Geometry must be a Point or LineString". > > > >Sounds like an horrible bug, if confirmed. > >Could you file a ticket with accompaining smallest C testcase showing it ? > > Sorry, as before, I'm working on interfacing to R, so GEOM objects are > created and validated from there. If there is a workhorse main() providing > a way of reading input or taking input from hardcoded WKT strings, I'll > use it, but I'd prefer not to write it - last time the testcase I wrote > was worse than and did not cover the problem. Just a simple boilerplate so > that my coding of it isn't the problem, if you see what I mean. Sure, we have an XML format for testcases targetting the C++ interface (xmltester), and a framework for C-API too (see tests/unit/capi/*). --strk; () Free GIS & Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] What do GEOSSymDifference and GEOSIntersection (CAPI) do?
On Wed, Feb 10, 2010 at 12:00:31PM +0100, Roger Bivand wrote: > I've tried to go through GEOSPolygonize() to put the MULTILINESTRING > together again, and am analysing what has happened, but think that the > output has lost hole attributions, so needs running through GEOSContains > or similar. Oh, if your goal is building an area you may consider moving the algorithm implemented by PostGIS's ST_BuildArea code down into the C-API (from the postgis geos wrapper). I belive it would be useful in general... --strk; () Free GIS & Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] What do GEOSSymDifference and GEOSIntersection (CAPI) do?
On Wed, Feb 10, 2010 at 12:35:46PM +0100, Roger Bivand wrote: > Are GEOSSymDifference() and GEOSIntersection() intended to take at least > POLYGON inputs, and then return POLYGON output, or not? No. They are supposed to work also on linear and puntual geometries. > As far as I can see, all the files there are C++, not C. I need C, not > C++, please. Just the #include, main(), and a place in the main to put the > data (say as WKT strings) and the function call, and a place to put the > output to screen. I did meet Bjarne Stroustrup in 1987, but that was > enough! Just setting up initGEOS(), etc., portably is hard. I completely understand your point of view. That's why I push hard for the C-API in the first place :) Just, as a matter of fact, the actual workhorse is written in C++, so *if* a bug is found, the usual place to start for figuring out the culprint it is in object-oriented-land. In any case, the xmltester script takes XML files as input so you need no C++ nor C to prepare a testcase for your situation. Doing so would tell you if Difference and Intersection functions are broken at the low level. --strk; () Free GIS & Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] What do GEOSSymDifference and GEOSIntersection (CAPI) do?
On Wed, Feb 10, 2010 at 02:44:44PM +0100, Roger Bivand wrote: > On Wed, 10 Feb 2010, strk wrote: > > >On Wed, Feb 10, 2010 at 12:35:46PM +0100, Roger Bivand wrote: > > > >>Are GEOSSymDifference() and GEOSIntersection() intended to take at least > >>POLYGON inputs, and then return POLYGON output, or not? > > > >No. They are supposed to work also on linear and puntual geometries. > > Clearer please, your "also" confuses me. Do they work on POLYGON or > MULTIPOLYGON at all? They do work on LINESTRING and LINEARRING, I've > tried. Yes, if given POLYGONS or MULTIPOLYGONS they *may* return POLYGONS or MULTIPOLYGONS or LINESTRINGS or MULTILINESTRINGS or POINTS or MULTIPOINGS (depending on the way the POLYGONs you passed in relate to each other) > The ST_BuildArea code looks useful, although I'm afraid that my > PARANOIA_LEVEL is >> 1! Debugging C is simply so much easier under layers > of other software (for me). > > I'm trying a work-around using GEOSSymDifference() for setdiff and > intersection operations, That's exactly what BuildArea does in postgis (after Polygonize): * Iteratively invoke symdifference on outer rings * as suggested by Carl Anderson: * postgis-devel/2005-December/001805.html > and would value advice on what "pat" in > GEOSRelatePattern(GCA, GCC2, pat); should be declared as (neither const > char pat[9] nor char pat[9] work). Takes a 'const char *' and doesn't refuse a 'char *'. Use the source, Luke: (GEOS C-API header): http://trac.osgeo.org/geos/browser/trunk/capi/geos_c.h.in (Postgis [C code] use of GEOS C-API): http://trac.osgeo.org/postgis/browser/trunk/postgis/lwgeom_geos.c --strk; () Free GIS & Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Re: cmake: distclean-like ? out of source tree build ?
On Sat, Feb 06, 2010 at 09:13:46PM +, Mateusz Loskot wrote: > Mateusz Loskot wrote: > > mlos...@dog:~/dev/geos/_svn/trunk$ svn-clean > > By the way, if you are suspicious about some remaining garbage in the > source tree, just run svn-clean and confirm you have trunk up-to-date > with nothing reported by svn status. svn-clean doesn't seem to be part of 'svn' package, do you confirm ? On an OpenSUSE I'm prompted to install kde-related things ?! The program 'svn-clean' can be found in following packages: * kdesdk3 [ path: /opt/kde3/bin/svn-clean, repository: zypp (ARKANIS_openSUSE_11.1_1) ] * kdesdk4-scripts [ path: /usr/bin/svn-clean, repository: zypp (ARKANIS_openSUSE_11.1_1) ] Try installing with: sudo zypper install kdesdk3 --strk; () Free GIS & Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] deprecate non-thread-safe CAPI interfaces
I'd like to deprecate non-thread-safe version of CAPI interface in next release, and stop providing them for new methods. If anyone sees a reason not to do that please scream before it's too late (you've plenty of time). --strk; () Free GIS & Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] deprecate non-thread-safe CAPI interfaces
On Wed, Feb 10, 2010 at 09:42:56PM -0600, Howard Butler wrote: > > On Feb 10, 2010, at 5:26 PM, strk wrote: > > > I'd like to deprecate non-thread-safe version > > of CAPI interface in next release, and stop providing > > them for new methods. > > > > If anyone sees a reason not to do that please scream > > before it's too late (you've plenty of time). > > The proposal would be to stop providing new methods and method updates for > the non-thread-safe API, correct? What I mean is that when *new* interfaces are added, only the version taking GEOSContextHandler would be provided. And (I meant) all other ones not taking that handler would be marked with "deprecated" attribute so warnings come out at build time (only for GCC I know how..). Can still wait for the second part (deprecation), but I think it makes sense for the first part (stop *adding* the bare ones). --strk; () Free GIS & Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Problems compiling nightly snapshot
On Wed, Mar 03, 2010 at 11:20:34AM +0100, Paul Meems wrote: > What is the best approach the get the latest version? svn checkout http://svn.osgeo.org/geos/trunk --strk; Share. It's fair. http://iwouldntsteal.net ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Problems compiling nightly snapshot
On Wed, Mar 03, 2010 at 01:23:58PM +, Mateusz Loskot wrote: > Paul Meems wrote: > >But this doesn't work with geos_c.h because it refers to two files in > >sub folders. We can do two things: either create the sub folder and copy > >the two files in to it or copy geos_c.h and open it and change > >geos/version.h to geos_version.h and geos/export,h to geos_export,h.. > >Currently we do the latter workaround. [...] > So, I'm not really the right person to decide if/how to fix this problem. Sorry if I ask, but wasn't geos/version.h and geos/export.h being installed already by the 'make install' rule ? @Mat: could it be a temporary problem created when you changed install rule to put all geos headers *under* the geos/ folder ? (which you should have fixed, but maybe he got outdated version) --strk; Share. It's fair. http://iwouldntsteal.net ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
