From geos-trac at osgeo.org Fri Aug 8 06:03:07 2014 From: geos-trac at osgeo.org (GEOS) Date: Fri, 08 Aug 2014 13:03:07 -0000 Subject: [geos-devel] [GEOS] #698: Support Visual Studio 2013 (Windows) Message-ID: <044.28443e384fb5d17e15e09b87aa6d061d@osgeo.org> #698: Support Visual Studio 2013 (Windows) ------------------------+--------------------------------------------------- Reporter: akks | Owner: geos-devel@? Type: defect | Status: new Priority: minor | Milestone: 3.4.3 Component: Default | Version: 3.4.2 Severity: Unassigned | Keywords: windows ------------------------+--------------------------------------------------- To build on Visual Studio 2013 Express I had to change CMakeLists.txt (add MSVC12 case). Better to add MSVC13 too to support future VS2014 (previews are released). The proposed patch follows. -- Ticket URL: GEOS GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS). From josh at snorfalorpagus.net Fri Aug 22 02:30:41 2014 From: josh at snorfalorpagus.net (Joshua Arnott) Date: Fri, 22 Aug 2014 10:30:41 +0100 Subject: [geos-devel] Errors building libgeos with mingw32 Message-ID: I'm having some trouble building libgeos on Windows 7 using mingw32. I'm building with: ./configure --disable-static --enable-shared --prefix=/usr/local make The shared library builds, but some of the tests fail (long output - see link below): http://pastebin.com/hr8GbBPs The library seems to function correctly from the most part, except for functions relating to WKB. I first noticed this using it via the Shapely Python module which uses GEOS with ctypes. https://github.com/Toblerity/Shapely/issues/151 Can anyone help me? Kind regards, Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From geos-trac at osgeo.org Fri Aug 22 10:46:19 2014 From: geos-trac at osgeo.org (GEOS) Date: Fri, 22 Aug 2014 17:46:19 -0000 Subject: [geos-devel] [GEOS] #699: Optimize Geometry->Intersection with rectangular argument Message-ID: <044.882b181b337f713b29f94d288e899da6@osgeo.org> #699: Optimize Geometry->Intersection with rectangular argument -------------------------+-------------------------------------------------- Reporter: strk | Owner: geos-devel@? Type: enhancement | Status: new Priority: major | Milestone: 3.4.3 Component: Default | Version: 3.4.2 Severity: Unassigned | Keywords: -------------------------+-------------------------------------------------- Intersection involving a rectangle could be optimized using rectangle predicates. I've tested it for queries against large (~1.5 million vertices in ~200k component polygons) and it takes the timing down from ~2000 seconds to less than 3 seconds... -- Ticket URL: GEOS GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS). From strk at keybit.net Fri Aug 22 10:49:44 2014 From: strk at keybit.net (Sandro Santilli) Date: Fri, 22 Aug 2014 19:49:44 +0200 Subject: [geos-devel] Errors building libgeos with mingw32 In-Reply-To: References: Message-ID: <20140822174944.GB25278@localhost> On Fri, Aug 22, 2014 at 10:30:41AM +0100, Joshua Arnott wrote: > I'm having some trouble building libgeos on Windows 7 using mingw32. I'm > building with: > > ./configure --disable-static --enable-shared --prefix=/usr/local > make > > The shared library builds, but some of the tests fail (long output - see > link below): > > http://pastebin.com/hr8GbBPs Sounds like all the coordinate values in your WKB gets interpreted as valued 0. You may simplify testing by running: tests/unit/geos_unit geos::io::WKBReader The code, for debugging, is here: src/io/WKBReader.cpp --strk; () ASCII ribbon campaign -- Keep it simple ! /\ http://strk.keybit.net/rants/ascii_mails.txt From geos-trac at osgeo.org Sun Aug 24 13:10:07 2014 From: geos-trac at osgeo.org (GEOS) Date: Sun, 24 Aug 2014 20:10:07 -0000 Subject: [geos-devel] [GEOS] #700: OpenBSD needs the same treatment as netbsd and dragonfly in geos/platform.h.in Message-ID: <046.f1cc0bdd8e04d7ec82efecc4a3e93ab0@osgeo.org> #700: OpenBSD needs the same treatment as netbsd and dragonfly in geos/platform.h.in ------------------------+--------------------------------------------------- Reporter: landry | Owner: geos-devel@? Type: defect | Status: new Priority: major | Milestone: 3.4.3 Component: Default | Version: 3.4.2 Severity: Unassigned | Keywords: ------------------------+--------------------------------------------------- I'm maintaining the geo/geos port in OpenBSD's ports-tree, and i need the attached patch to make it compile fine. -- Ticket URL: GEOS GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS). From geos-trac at osgeo.org Mon Aug 25 00:43:40 2014 From: geos-trac at osgeo.org (GEOS) Date: Mon, 25 Aug 2014 07:43:40 -0000 Subject: [geos-devel] [GEOS] #700: OpenBSD needs the same treatment as netbsd and dragonfly in geos/platform.h.in In-Reply-To: <046.f1cc0bdd8e04d7ec82efecc4a3e93ab0@osgeo.org> References: <046.f1cc0bdd8e04d7ec82efecc4a3e93ab0@osgeo.org> Message-ID: <055.391f250530417e4f32cf9ad4c5624349@osgeo.org> #700: OpenBSD needs the same treatment as netbsd and dragonfly in geos/platform.h.in ------------------------+--------------------------------------------------- Reporter: landry | Owner: geos-devel@? Type: defect | Status: closed Priority: major | Milestone: 3.4.3 Component: Default | Version: 3.4.2 Severity: Unassigned | Resolution: fixed Keywords: | ------------------------+--------------------------------------------------- Changes (by strk): * status: new => closed * resolution: => fixed Comment: r3995 in trunk (3.5.0), r3997 in 3.4 branch (3.4.3) -- Thanks! -- Ticket URL: GEOS GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS). From strk at keybit.net Mon Aug 25 01:44:56 2014 From: strk at keybit.net (Sandro Santilli) Date: Mon, 25 Aug 2014 10:44:56 +0200 Subject: [geos-devel] JTS GeometryCollection#apply(GeometryComponentFilter) Message-ID: <20140825084456.GB4108@localhost> Martin, I noticed that GeometryCollection#apply(GeometryComponentFilter) passes itself to the GeometryComponentFilter#filter function before passing it each and every component, is that a bug or intended behavior ? I was trying to use a GeometryComponentFilter to iterate over each of the simple-typed components of a Geometry, but due to the above I'm getting the collection itself as one of the components. --strk; () ASCII ribbon campaign -- Keep it simple ! /\ http://strk.keybit.net/rants/ascii_mails.txt From strk at keybit.net Mon Aug 25 01:46:25 2014 From: strk at keybit.net (Sandro Santilli) Date: Mon, 25 Aug 2014 10:46:25 +0200 Subject: [geos-devel] JTS GeometryCollection#apply(GeometryComponentFilter) In-Reply-To: <20140825084456.GB4108@localhost> References: <20140825084456.GB4108@localhost> Message-ID: <20140825084625.GC4108@localhost> On Mon, Aug 25, 2014 at 10:44:56AM +0200, Sandro Santilli wrote: > Martin, I noticed that GeometryCollection#apply(GeometryComponentFilter) > passes itself to the GeometryComponentFilter#filter function before > passing it each and every component, is that a bug or intended behavior ? > > I was trying to use a GeometryComponentFilter to iterate over each of > the simple-typed components of a Geometry, but due to the above I'm getting > the collection itself as one of the components. I shall note that GeometryCollection#apply(GeometryFilter) has the same implementation of the one taking GeometryCompomentFilter... --strk; From mika.heiskanen at fmi.fi Tue Aug 26 11:22:20 2014 From: mika.heiskanen at fmi.fi (Mika Heiskanen) Date: Tue, 26 Aug 2014 21:22:20 +0300 Subject: [geos-devel] [GEOS] #699: Optimize Geometry->Intersection with rectangular argument In-Reply-To: <044.882b181b337f713b29f94d288e899da6@osgeo.org> References: <044.882b181b337f713b29f94d288e899da6@osgeo.org> Message-ID: <53FCD05C.4070603@fmi.fi> Hello, On 08/22/2014 08:46 PM, GEOS wrote: > #699: Optimize Geometry->Intersection with rectangular argument > -------------------------+-------------------------------------------------- > Reporter: strk | Owner: geos-devel@? > Type: enhancement | Status: new > Priority: major | Milestone: 3.4.3 > Component: Default | Version: 3.4.2 > Severity: Unassigned | Keywords: > -------------------------+-------------------------------------------------- > Intersection involving a rectangle could be optimized using rectangle > predicates. I've tested it for queries against large (~1.5 million > vertices in ~200k component polygons) and it takes the timing down from > ~2000 seconds to less than 3 seconds... This spring we needed GEOS clipping functionality for rendering maps. Unfortunately GEOS failed to clip the ~3 million vertex ESRI Europe map data, which was key for us, it gave up after about 6 seconds. A quick look at the GEOS code revealed there was no special code for rectangular clipping. Since we were in a hurry, we wrote the needed code ourselves. The resulting code could clip the ESRI data in 0.05 seconds. The code o was written to use OGR/GDAL objects directly. OGR converts its geometries to GEOS geometries for more complex tasks, we thought this was an unnecessary step for us. However, there should be no reason why converting to code to use GEOS objects would not be fairly easy. o allows for two kinds of clipping: - a polygon remains a polygon if any part of it is inside the clipping rectangle. The resulting polygon will follow the edges of the clipping rectangle to maintain the geometry. - a polygon may become a linestring if any part of it is outside the clipping rectangle. o handles all special cases we could imagine on paper such as edges entering the rectangle from a corner. There are about 150 tests for such special cases. o should be very robust, but we're not experts on that. The code is fast for clipping geometries typical in mapping, we did not consider vastly complex cases which might be mostly of academic interest. For example, if a geometry component begins with a coordinate to the left of the clipping rectangle, only one coordinate comparison is used to decide whether the next vertex is still to the left. We do not have any benchmarks on how our code compares with other resources, apart for the GEOS failure we encountered. If there is interest in our code, we can contribute some time to integrate it with GEOS, but would mostly likely need co-operation from someone already working with GEOS. Mika Heiskanen / Finnish Meteorological Institute From strk at keybit.net Wed Aug 27 01:09:57 2014 From: strk at keybit.net (Sandro Santilli) Date: Wed, 27 Aug 2014 10:09:57 +0200 Subject: [geos-devel] [GEOS] #699: Optimize Geometry->Intersection with rectangular argument In-Reply-To: <53FCD05C.4070603@fmi.fi> References: <044.882b181b337f713b29f94d288e899da6@osgeo.org> <53FCD05C.4070603@fmi.fi> Message-ID: <20140827080957.GA4175@localhost> On Tue, Aug 26, 2014 at 09:22:20PM +0300, Mika Heiskanen wrote: > >#699: Optimize Geometry->Intersection with rectangular argument > This spring we needed GEOS clipping functionality for rendering maps. > Unfortunately GEOS failed to clip the ~3 million vertex ESRI Europe map > data, which was key for us, it gave up after about 6 seconds. A quick > look at the GEOS code revealed there was no special code for rectangular > clipping. Since we were in a hurry, we wrote the needed code ourselves. > The resulting code could clip the ESRI data in 0.05 seconds. > > The code > > o was written to use OGR/GDAL objects directly. OGR converts its > geometries to GEOS geometries for more complex tasks, we thought > this was an unnecessary step for us. However, there should be > no reason why converting to code to use GEOS objects would not > be fairly easy. > > o allows for two kinds of clipping: > > - a polygon remains a polygon if any part of it is inside > the clipping rectangle. The resulting polygon will follow the > edges of the clipping rectangle to maintain the geometry. > > - a polygon may become a linestring if any part of it is > outside the clipping rectangle. If I understood it correctly the second kind would be equivalent to the first kind applied to the boundary of the polygon (clipping lines instead of polygons). > o handles all special cases we could imagine on paper such as > edges entering the rectangle from a corner. There are about > 150 tests for such special cases. That's great ! > o should be very robust, but we're not experts on that. > > The code is fast for clipping geometries typical in mapping, we > did not consider vastly complex cases which might be mostly of > academic interest. For example, if a geometry component begins with a > coordinate to the left of the clipping rectangle, only one coordinate > comparison is used to decide whether the next vertex is still to the > left. Neat > We do not have any benchmarks on how our code compares with other > resources, apart for the GEOS failure we encountered. > > If there is interest in our code, we can contribute some time to > integrate it with GEOS, but would mostly likely need co-operation from > someone already working with GEOS. > > Mika Heiskanen / Finnish Meteorological Institute I'm very interested in your code and willing to help with integration. I guess this could be a RectangleIntersection class under a new geos::operation::intersection namespace, eventually further wrapped by a generic IntersectionOp using RectangleIntersection when an input is a rectangle or the generic OverlayOp in other cases. Then Geometry::intersection would be using that specialized class. Please let me know how I can help with this. PS: I added Dr.JTS in CC, as he might be interested about this for JTS too --strk; () ASCII ribbon campaign -- Keep it simple ! /\ http://strk.keybit.net/rants/ascii_mails.txt From remi.cura at gmail.com Wed Aug 27 01:46:18 2014 From: remi.cura at gmail.com (=?UTF-8?Q?R=C3=A9mi_Cura?=) Date: Wed, 27 Aug 2014 10:46:18 +0200 Subject: [geos-devel] [GEOS] #699: Optimize Geometry->Intersection with rectangular argument In-Reply-To: <20140827080957.GA4175@localhost> References: <044.882b181b337f713b29f94d288e899da6@osgeo.org> <53FCD05C.4070603@fmi.fi> <20140827080957.GA4175@localhost> Message-ID: 2014-08-27 10:09 GMT+02:00 Sandro Santilli : > On Tue, Aug 26, 2014 at 09:22:20PM +0300, Mika Heiskanen wrote: > > > >#699: Optimize Geometry->Intersection with rectangular argument > > > This spring we needed GEOS clipping functionality for rendering maps. > > Unfortunately GEOS failed to clip the ~3 million vertex ESRI Europe map > > data, which was key for us, it gave up after about 6 seconds. A quick > > look at the GEOS code revealed there was no special code for rectangular > > clipping. Since we were in a hurry, we wrote the needed code ourselves. > > The resulting code could clip the ESRI data in 0.05 seconds. > > > > The code > > > > o was written to use OGR/GDAL objects directly. OGR converts its > > geometries to GEOS geometries for more complex tasks, we thought > > this was an unnecessary step for us. However, there should be > > no reason why converting to code to use GEOS objects would not > > be fairly easy. > > > > o allows for two kinds of clipping: > > > > - a polygon remains a polygon if any part of it is inside > > the clipping rectangle. The resulting polygon will follow the > > edges of the clipping rectangle to maintain the geometry. > > > > - a polygon may become a linestring if any part of it is > > outside the clipping rectangle. > > If I understood it correctly the second kind would be equivalent > to the first kind applied to the boundary of the polygon (clipping > lines instead of polygons). > > > o handles all special cases we could imagine on paper such as > > edges entering the rectangle from a corner. There are about > > 150 tests for such special cases. > > That's great ! > > > o should be very robust, but we're not experts on that. > > > > The code is fast for clipping geometries typical in mapping, we > > did not consider vastly complex cases which might be mostly of > > academic interest. For example, if a geometry component begins with a > > coordinate to the left of the clipping rectangle, only one coordinate > > comparison is used to decide whether the next vertex is still to the > > left. > > Neat > > > We do not have any benchmarks on how our code compares with other > > resources, apart for the GEOS failure we encountered. > > > > If there is interest in our code, we can contribute some time to > > integrate it with GEOS, but would mostly likely need co-operation from > > someone already working with GEOS. > > > > Mika Heiskanen / Finnish Meteorological Institute > > I'm very interested in your code and willing to help with integration. > > I guess this could be a RectangleIntersection class under a new > geos::operation::intersection namespace, eventually further wrapped > by a generic IntersectionOp using RectangleIntersection when an input > is a rectangle or the generic OverlayOp in other cases. > Then Geometry::intersection would be using that specialized class. > > Please let me know how I can help with this. > > PS: I added Dr.JTS in CC, as he might be interested about this for JTS too > > --strk; > > This upgrade would be _much_ appreciated here. Very good news, thanks ! Cheers, R?mi-C -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika.heiskanen at fmi.fi Wed Aug 27 13:48:56 2014 From: mika.heiskanen at fmi.fi (Mika Heiskanen) Date: Wed, 27 Aug 2014 23:48:56 +0300 Subject: [geos-devel] [GEOS] #699: Optimize Geometry->Intersection with rectangular argument In-Reply-To: <20140827080957.GA4175@localhost> References: <044.882b181b337f713b29f94d288e899da6@osgeo.org> <53FCD05C.4070603@fmi.fi> <20140827080957.GA4175@localhost> Message-ID: <53FE4438.70502@fmi.fi> On 08/27/2014 11:09 AM, Sandro Santilli wrote: >> o handles all special cases we could imagine on paper such as >> edges entering the rectangle from a corner. There are about >> 150 tests for such special cases. > > That's great ! As luck would have it, we just encountered a case which was not handled correctly. We have all the input data to recreate the problem, and we hope to be able to debug it this week. We shall reassess the scope of our tests and hence the validity of our code depending on the outcome. Hopefully we can proceed once the problem has been resolved. Regards, Mika Heiskanen / FMI From strk at keybit.net Wed Aug 27 23:23:12 2014 From: strk at keybit.net (Sandro Santilli) Date: Thu, 28 Aug 2014 08:23:12 +0200 Subject: [geos-devel] [GEOS] #699: Optimize Geometry->Intersection with rectangular argument In-Reply-To: <53FE4438.70502@fmi.fi> References: <044.882b181b337f713b29f94d288e899da6@osgeo.org> <53FCD05C.4070603@fmi.fi> <20140827080957.GA4175@localhost> <53FE4438.70502@fmi.fi> Message-ID: <20140828062312.GA4522@localhost> On Wed, Aug 27, 2014 at 11:48:56PM +0300, Mika Heiskanen wrote: > On 08/27/2014 11:09 AM, Sandro Santilli wrote: > > >> o handles all special cases we could imagine on paper such as > >> edges entering the rectangle from a corner. There are about > >> 150 tests for such special cases. > > > >That's great ! > > As luck would have it, we just encountered a case which was not handled > correctly. We have all the input data to recreate the problem, and we > hope to be able to debug it this week. We shall reassess the scope of > our tests and hence the validity of our code depending on the outcome. > > Hopefully we can proceed once the problem has been resolved. Good luck ! --strk; () ASCII ribbon campaign -- Keep it simple ! /\ http://strk.keybit.net/rants/ascii_mails.txt From mika.heiskanen at fmi.fi Thu Aug 28 05:33:10 2014 From: mika.heiskanen at fmi.fi (Mika Heiskanen) Date: Thu, 28 Aug 2014 15:33:10 +0300 Subject: [geos-devel] [GEOS] #699: Optimize Geometry->Intersection with rectangular argument In-Reply-To: <20140828062312.GA4522@localhost> References: <044.882b181b337f713b29f94d288e899da6@osgeo.org> <53FCD05C.4070603@fmi.fi> <20140827080957.GA4175@localhost> <53FE4438.70502@fmi.fi> <20140828062312.GA4522@localhost> Message-ID: <53FF2186.6080303@fmi.fi> On 08/28/2014 09:23 AM, Sandro Santilli wrote: > On Wed, Aug 27, 2014 at 11:48:56PM +0300, Mika Heiskanen wrote: >> On 08/27/2014 11:09 AM, Sandro Santilli wrote: >> >>>> o handles all special cases we could imagine on paper such as >>>> edges entering the rectangle from a corner. There are about >>>> 150 tests for such special cases. >>> >>> That's great ! >> >> As luck would have it, we just encountered a case which was not handled >> correctly. We have all the input data to recreate the problem, and we >> hope to be able to debug it this week. We shall reassess the scope of >> our tests and hence the validity of our code depending on the outcome. >> >> Hopefully we can proceed once the problem has been resolved. The problem was resolved, and we added a few more regression tests. I have booked Monday for porting the code to GEOS. Mika Heiskanen / FMI From geos-trac at osgeo.org Fri Aug 29 01:20:20 2014 From: geos-trac at osgeo.org (GEOS) Date: Fri, 29 Aug 2014 08:20:20 -0000 Subject: [geos-devel] [GEOS] #380: Buffer(Geometry, 0) deletes part of the polygon [JTS affected too] In-Reply-To: <050.a1157464fd11f98c44597e33386f6f10@osgeo.org> References: <050.a1157464fd11f98c44597e33386f6f10@osgeo.org> Message-ID: <059.416d23e7e5624fc9d2f1be5c4f6c4b6b@osgeo.org> #380: Buffer(Geometry,0) deletes part of the polygon [JTS affected too] -------------------------+-------------------------------------------------- Reporter: jaapdekker | Owner: geos-devel@? Type: enhancement | Status: new Priority: minor | Milestone: GEOS Future Component: Default | Version: 3.2.0 Severity: Unassigned | Keywords: -------------------------+-------------------------------------------------- Comment(by corrado9999): Please, notice that the input geometry jaapdekker is using is: {{{ Select AsText(Buffer(MPolyFromText('MULTIPOLYGON(((-66 58,-66 59,-64 58,-65 58,-66 58),(-70 57,-66 57,-66 58,-68 58,-68 57,-70 57)),((-70 58,-70 57,-72 57,-72 59,-71 59,-71 58,-70 58)))'),0)); ^^^ }}} and not what I think he meant: {{{ Select AsText(Buffer(MPolyFromText('MULTIPOLYGON(((-66 58,-66 59,-64 58,-65 58,-66 58)),((-70 57,-66 57,-66 58,-68 58,-68 57,-70 57)),((-70 58,-70 57,-72 57,-72 59,-71 59,-71 58,-70 58)))'),0)); ^^^^^ }}} I could only test it using the Python bindings of OGR, but with them I experienced the same issue reported. If I use instead the new polygon, the output is the following: {{{ 'MULTIPOLYGON (((-70 57,-72 57,-72 59,-71 59,-71 58,-70 58,-70 57)),((-68 57,-68 58,-66 58,-66 57,-68 57)),((-66 58,-66 59,-64 58,-65 58,-66 58)))' }}} -- Ticket URL: GEOS GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS). From josh at snorfalorpagus.net Fri Aug 29 06:53:42 2014 From: josh at snorfalorpagus.net (Joshua Arnott) Date: Fri, 29 Aug 2014 14:53:42 +0100 Subject: [geos-devel] GEOSVoronoiDiagram missing symbol Message-ID: <5D039C35-253F-4A6C-A984-90A8452712E3@snorfalorpagus.net> Hello, I want to use the voronoi diagram functionality from the C API. The linker is complaining about the GEOSVoronoiDiagram not being found. I?ve written the following simple program: #include #include #include "geos_c.h" int main(int argc, char **argv) { initGEOS(NULL, NULL); GEOSGeometry* g1; GEOSGeometry* g2; char* wkt = "MULTIPOINT ((10 40), (40 30), (20 20), (30 10))"; g1 = GEOSGeomFromWKT(wkt); g2 = GEOSVoronoiDiagram(g1, NULL, 0.0, 0); printf("%s\n", GEOSGeomToWKT(g1)); finishGEOS(); return 0; } The compiler raises the following error: $ cc -o voronoi voronoi.c -lgeos_c voronoi.c:13:10: warning: implicit declaration of function 'GEOSVoronoiDiagram' is invalid in C99 [-Wimplicit-function-declaration] g2 = GEOSVoronoiDiagram(g1, NULL, 0.0, 0); ^ voronoi.c:13:8: warning: incompatible integer to pointer conversion assigning to 'GEOSGeometry *' (aka 'struct GEOSGeom_t *') from 'int' [-Wint-conversion] g2 = GEOSVoronoiDiagram(g1, NULL, 0.0, 0); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2 warnings generated. Undefined symbols for architecture x86_64: "_GEOSVoronoiDiagram", referenced from: _main in voronoi-41964a.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Removing the call to GEOSVoronoiDiagram allows the program to compile and run without error. Using `nm` I?ve checked, and the function appears to be missing from the shared library. The related GEOSDelaunayTriangulation is present. The version of GEOS I?ve compiled does appear to include the function so I?m not sure what?s going wrong. Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From strk at keybit.net Fri Aug 29 06:56:47 2014 From: strk at keybit.net (Sandro Santilli) Date: Fri, 29 Aug 2014 15:56:47 +0200 Subject: [geos-devel] GEOSVoronoiDiagram missing symbol In-Reply-To: <5D039C35-253F-4A6C-A984-90A8452712E3@snorfalorpagus.net> References: <5D039C35-253F-4A6C-A984-90A8452712E3@snorfalorpagus.net> Message-ID: <20140829135647.GA32764@localhost> On Fri, Aug 29, 2014 at 02:53:42PM +0100, Joshua Arnott wrote: > I want to use the voronoi diagram functionality from the C API. > The linker is complaining about the GEOSVoronoiDiagram not being found. How did you build GEOS, which version of it ? Did "make check" run correctly ? --strk; From mika.heiskanen at fmi.fi Fri Aug 29 07:17:57 2014 From: mika.heiskanen at fmi.fi (Mika Heiskanen) Date: Fri, 29 Aug 2014 17:17:57 +0300 Subject: [geos-devel] [GEOS] #699: Optimize Geometry->Intersection with rectangular argument In-Reply-To: <20140827080957.GA4175@localhost> References: <044.882b181b337f713b29f94d288e899da6@osgeo.org> <53FCD05C.4070603@fmi.fi> <20140827080957.GA4175@localhost> Message-ID: <54008B95.3090700@fmi.fi> On 08/27/2014 11:09 AM, Sandro Santilli wrote: > I'm very interested in your code and willing to help with integration. > > I guess this could be a RectangleIntersection class under a new > geos::operation::intersection namespace, eventually further wrapped > by a generic IntersectionOp using RectangleIntersection when an input > is a rectangle or the generic OverlayOp in other cases. > Then Geometry::intersection would be using that specialized class. > > Please let me know how I can help with this. I will try to port the code to the class and namespace you mentioned. There will be some helper classes too. I will also see if I can integrate the tests we have with your existing system. Integration with IntersectionOp etc is not what I am comfortable with, as I know too little of existing GEOS code. Regards, Mika From strk at keybit.net Fri Aug 29 07:20:11 2014 From: strk at keybit.net (Sandro Santilli) Date: Fri, 29 Aug 2014 16:20:11 +0200 Subject: [geos-devel] [GEOS] #699: Optimize Geometry->Intersection with rectangular argument In-Reply-To: <54008B95.3090700@fmi.fi> References: <044.882b181b337f713b29f94d288e899da6@osgeo.org> <53FCD05C.4070603@fmi.fi> <20140827080957.GA4175@localhost> <54008B95.3090700@fmi.fi> Message-ID: <20140829142011.GB32764@localhost> On Fri, Aug 29, 2014 at 05:17:57PM +0300, Mika Heiskanen wrote: > On 08/27/2014 11:09 AM, Sandro Santilli wrote: > >I'm very interested in your code and willing to help with integration. > > > >I guess this could be a RectangleIntersection class under a new > >geos::operation::intersection namespace, eventually further wrapped > >by a generic IntersectionOp using RectangleIntersection when an input > >is a rectangle or the generic OverlayOp in other cases. > >Then Geometry::intersection would be using that specialized class. > > > >Please let me know how I can help with this. > > I will try to port the code to the class and namespace you mentioned. > There will be some helper classes too. I will also see if I can > integrate the tests we have with your existing system. Integration with > IntersectionOp etc is not what I am comfortable with, as I know too > little of existing GEOS code. Don't worry about intergration with IntersectionOp, I can do that part. Testcases would be very important to get in. --strk; () ASCII ribbon campaign -- Keep it simple ! /\ http://strk.keybit.net/rants/ascii_mails.txt From josh at snorfalorpagus.net Fri Aug 29 07:27:03 2014 From: josh at snorfalorpagus.net (Joshua Arnott) Date: Fri, 29 Aug 2014 15:27:03 +0100 Subject: [geos-devel] GEOSVoronoiDiagram missing symbol Message-ID: I?m using GEOS 3.4.2, built from source on OS X 10.9.4. I had this issue using the library built using Homebrew, but have since compiled manually with the same issue. Compiled with "./configure --disable-dependency-tracking --prefix=/usr/local?. Results of ?make check? below: =============================== GEOS Test Suite Application =============================== capi::GEOSBuffer: .................... capi::GEOSContains: ... capi::GEOSConvexHull: . capi::GEOSCoordSeq: ...... capi::GEOSDelaunayTriangulation: ...... capi::GEOSDistance: . capi::GEOSGeomFromWKB: ..... capi::GEOSGeomToWKT: ............. capi::GEOSGeom_create: ....... capi::GEOSGeom_extractUniquePoints: ... capi::GEOSGetCentroid: ..... capi::GEOSInterrupt: ..NOTICE: InterruptedException: Interrupted! .NOTICE: InterruptedException: Interrupted! . capi::GEOSIntersects: ...NOTICE: IllegalArgumentException: RobustDeterminant encountered non-finite numbers .NOTICE: IllegalArgumentException: RobustDeterminant encountered non-finite numbers . capi::GEOSLineStringPoint: ... capi::GEOSNearestPoints: .. capi::GEOSNode: ... capi::GEOSOffsetCurve: .........NOTICE: IllegalArgumentException: Cannot get offset of single-vertex line . capi::GEOSOrientationIndex: ........... capi::GEOSPointOnSurface: ...... capi::GEOSPolygonizeGetCutEdges: .. capi::GEOSPreparedGeometry: ...... capi::GEOSRelateBoundaryNodeRule: .......NOTICE: Invalid boundary node rule 5 . capi::GEOSRelatePatternMatch: .....NOTICE: IllegalArgumentException: Geometry is not lineal capi::GEOSSharedPaths: ..NOTICE: IllegalArgumentException: Geometry is not lineal . capi::GEOSSimplify: . capi::GEOSSnap: .......... capi::GEOSUnaryUnion: ........NOTICE: IllegalArgumentException: EdgeEnd with coordinate nan nan invalid for node nan nan . capi::GEOSWithin: ... capi::GEOSisValidDetail: ...... geos::algorithm::Angle: .... geos::algorithm::CGAlgorithms::computeOrientation: .. geos::algorithm::CGAlgorithms::isCCW: ..... geos::algorithm::CGAlgorithms::isPointInRing: .. geos::algorithm::CGAlgorithms::signedArea: ... geos::algorithm::ConvexHull: ....... geos::algorithm::InteriorPointArea: . geos::algorithm::PointLocator: .... geos::algorithm::RobustLineIntersection: ...... geos::algorithm::RobustLineIntersector: ............. geos::algorithm::distace::DiscreteHausdorffDistance: .... geos::geom::Coordinate: ......... geos::geom::CoordinateArraySequence: ................. geos::geom::CoordinateArraySequenceFactory: [1=F]... geos::geom::CoordinateList: ... geos::geom::Dimension: ..... geos::geom::Envelope: ......... geos::geom::Geometry::clone: ....... geos::geom::Geometry::covers: .... geos::geom::Geometry::isRectangle: ....... geos::geom::GeometryFactory: .................................... geos::geom::IntersectionMatrix: ............................. geos::geom::LineSegment: ...... geos::geom::LineString: ......................... geos::geom::LinearRing: .............................. geos::geom::Location: ... geos::geom::MultiLineString: . geos::geom::MultiPoint: ............................ geos::geom::MultiPolygon: . geos::geom::Point: ........................................ geos::geom::Polygon: ..................................... geos::geom::PrecisionModel: ......... geos::geom::Triangle: ..... geos::geom::prep::PreparedGeometryFactory: ............................. geos::geom::util::GeometryExtracter: .. geos::index::quadtree::DoubleBits: . geos::io::ByteOrderValues: ... geos::io::WKBReader: ....... geos::io::WKBWriter: .... geos::io::WKTReader: ....... geos::io::WKTWriter: ..... geos::io::Writer: .... geos::linearref::LocationIndexedLine: ........................... geos::noding::BasicSegmentString: .... geos::noding::NodedSegmentString: ..... geos::noding::OrientedCoordinateArray: ..... geos::noding::SegmentNode: .... geos::noding::SegmentPointComparator: ..... geos::noding::snapround::HotPixel: ... geos::noding::snapround::MCIndexSnapRounder: . geos::operation::IsSimpleOp: ... geos::operation::buffer::BufferBuilder: . geos::operation::buffer::BufferOp: ........... geos::operation::buffer::BufferParameters: .......... geos::operation::distance::DistanceOp: ................... geos::operation::geounion::CascadedPolygonUnion: . geos::operation::geounion::UnaryUnionOp: ...... geos::operation::linemerge::LineMerger: ...... geos::operation::linemerge::LineSequencer: ............ geos::operation::overlay::snap::GeometrySnapper: .. geos::operation::overlay::snap::LineStringSnapper: ....... geos::operation::overlay::validate::FuzzyPointLocator: ....... geos::operation::overlay::validate::OffsetPointGenerator: ..... geos::operation::overlay::validate::OverlayResultValidator: ...... geos::operation::polygonize::Polygonizer: .. geos::operation::sharedpaths::SharedPathsOp: ..................... geos::operation::valid::IsValidOp: . geos::operation::valid::ValidClosedRing: ..... geos::operation::valid::ValidSelfTouchingRingFormingHole: ....... geos::precision::GeometryPrecisionReducer: ......... geos::precision::SimpleGeometryPrecisionReducer: ....... geos::simplify::DouglasPeuckerSimplifier: ........... geos::simplify::TopologyPreservingSimplifier: ............... geos::triangulate::Delaunay: ......... geos::triangulate::quadedge::QuadEdge: ... geos::triangulate::quadedge::QuadEdgeSubdivision: . geos::util::UniqueCoordinateArrayFilter: . ---> group: geos::geom::CoordinateArraySequenceFactory, test: test<1> problem: assertion failed tests summary: failures:1 ok:836 FAIL: geos_unit ================== 1 of 1 test failed ================== make[4]: *** [check-TESTS] Error 1 make[3]: *** [check-am] Error 2 make[2]: *** [check-recursive] Error 1 make[1]: *** [check-recursive] Error 1 make: *** [check] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: