Re: [geos-devel] 3.12.0beta2
Hi Paul, The GEOSMinimumRotatedEnvelope algorithm change affects some Shapely tests, but I don't see any other problems. We're likely to change the tests to match the new implementation. Beta2 looks good from here! On Wed, Jun 14, 2023 at 2:01 PM Paul Ramsey wrote: > Thank you everyone who tested and gave feedback on the first beta > release. Having incorporated all the feedback thus far, the next beta > is available: > > https://download.osgeo.org/geos/geos-3.12.0beta2.tar.bz2 > > Thanks again, > P > -- Sean Gillies ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS Maintenance Grant
Howard, I'm in favor, but first I'd like to see the GEOS project adopt a code of conduct. Sponsors look for one these days, right? It's probably a good move for GEOS in the long run. On Tue, Feb 15, 2022 at 8:37 AM Howard Butler wrote: > GDAL PSC, > > When we wrote the GDAL RFCs on sponsorship, we provided an escape clause > to allow us to direct resources to other projects upon which GDAL depends. > Our sponsorship numbers are still increasing, which provides us an > opportunity to directly support some of those projects, and one of them is > obviously GEOS. GEOS provides all of the geometry algebra support for > GDAL/OGR and many other open source geospatial softwares including Shapely, > PostGIS, GeoPandas, MapServer, and more. > > Dan Baston of the GEOS PSC has been identified as the developer with > capacity and interest in the next year to take on GEOS development on APIs > and performance, which he has a long history of doing for the project. This > support should allow him to work longer, multi-release upgrades that will > provide strong performance and convenience benefits for the project. > > I motion to provide the GEOS PSC with a $50,000 USD grant to address > performance, API, and other work that does not attract directed funding in > GEOS. The GEOS PSC will be responsible for coordinating work tasks, rates, > and development timelines. Howard Butler or Even Rouault of the GDAL > NumFocus liaison team will coordinate dispersement as directed by the GEOS > PSC and NumFocus rules. > > Thank you again to the GDAL Sponsors https://gdal.org/sponsors/index.html > who have made this kind of grant possible. A better GEOS makes for a better > GDAL. > > Howard > -- Sean Gillies ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] CAPI Performance Tool
Hi Paul, Thank you! On Tue, Mar 2, 2021 at 12:58 PM Paul Ramsey wrote: > Hey all, > > After much chattering over the years about the potential utility of a GEOS > C API performance suite independent of the GEOS code base, I have written > such a thing up. At a minimum, we can now generate that multi-year > performance improvement chart we've all been wanting. But hopefully it'll > also prove useful during development to make sure that changes are a net > positive over a range of "real world" use cases and data. I've started with > 6 tests, but hopefully will add some others that exercise other data and > use cases too. > > I've published in my own account, but if there's interest over the next > few months I'm happy to have the canonical repo live in libgeos org. > > https://github.com/pramsey/geos-performance/ > > P. > -- Sean Gillies ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] RFC7: Discontinue use of autotools
Hi Roger and all, On Fri, Jan 8, 2021 at 12:25 PM Roger Bivand wrote: > In so far as geos-config and geos.pc are generated in forms that autotools > can use (R packages use autotools to configure the use of external > libraries), the main problem is simply that I don't use Cmake, and have > never felt confident when obliged to use it. Unless forced, I really > prefer not to have to, and as I retire soon, I think I shouldn't begin > life as a pensioner by having to learn enough Cmake to be able to build > GEOS (nothing else I build regularly uses Cmake). > > Probably part of the problem is the ./autogen.sh step, which most other > libraries do not impose, however, the RFC does not mention this. > > My feeling is that my interest in tracking developments in GEOS (on behalf > of the R spatial cluster of packages, about 950 at last count) before a > release process is triggered will weaken sharply if I have to learn Cmake, > used for nothing else. > > The RFC mentions the preferences of commmitters; this is wrong-headed, > because the actually useful feedback comes from those in R/Python/etc. who > may be able to find regressions, but who will stop testing before release > if building from the repo or from source in general gets harder. Then you > risk making releases which cause havoc downstream, because you are making > it harder for people like me to build from source. What the committers > prefer will decide this, but it isn't wise. > > Roger > I can't speak for any other downstream projects or packagers, but the Shapely project won't be terribly inconvenienced by a complete switch to Cmake. -- Sean Gillies ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] dynamic_cast may yield null pointers in AbstractSTRtree::query and AbstractSTRtree::itemsTree on OS X
Hi Kurt, Thanks for the sympathy! It's the same library version. Same library build, even. I have a system that builds GEOS once, copies it into the two Python package trees, and uses install_name_tool to relink all the Python .so modules. https://github.com/matthew-brett/delocate (if you're curious) wraps both install_name_tool and otool and is what the SciPy team uses to make binary wheels (the Python distribution format) for numpy, scipy, pandas etc. $ delocate-listdeps --all ~/Downloads/scipy-1.0.0-cp27- cp27m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_ x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate /usr/lib/libSystem.B.dylib /usr/lib/libstdc++.6.0.9.dylib @loader_path/../../../../.dylibs/libgcc_s.1.dylib @loader_path/../../../../.dylibs/libgfortran.3.dylib @loader_path/../../../../.dylibs/libquadmath.0.dylib @loader_path/../../../.dylibs/libgcc_s.1.dylib @loader_path/../../../.dylibs/libgfortran.3.dylib @loader_path/../../../.dylibs/libquadmath.0.dylib @loader_path/../.dylibs/libgcc_s.1.dylib @loader_path/../.dylibs/libgfortran.3.dylib @loader_path/../.dylibs/libquadmath.0.dylib @loader_path/libgcc_s.1.dylib @loader_path/libquadmath.0.dylib This works like a charm for SciPy packages, which don't have overlapping dependencies like shapely and fiona do, and also works fine for shapely and fiona outside of the AbstractSTRTree module. On Thu, Jan 4, 2018 at 12:22 PM, Kurt Schwehr wrote: > Ouch :( > > Some thoughts... you might be getting different versions of the library > (e.g. different compiler versions or flags for the same version of > libgeos). otool -L and dtrace are places to start, but aren't fun. Is it > happening on multiple machines? Using macports, fink, homebrew, or for the > libs? > > On Wed, Jan 3, 2018 at 10:34 AM, Sean Gillies > wrote: > >> Hi and Happy New Year, all. >> >> I found time recently to make notes on a frustrating issue that I'm >> having with GEOS in the Shapely binary wheels for OS X that I'm publishing >> on PyPI. I'm not certain whether there's a GEOS bug, a dynamic loader bug, >> a ctypes bug, misuse of computers on my part, or all four. I'd really >> appreciate a bit of advice from anyone with more C++ and Mach-O wisdom that >> would rule out a few of these possibilities. >> >> Here's the gist of it: Shapely uses dlopen (via Python's ctypes) to load >> libgeos_c.dylib at run time. The GEOS C++ library (libgeos-3.6.2.dylib, for >> example) is a dependent library of libgeos_c.dylib. I have been >> distributing the GEOS libs with my Shapely binaries for convenience of >> users, but Shapely also works with GEOS installed to the standard places on >> your system. I've never experienced or seen report of a problem with >> Shapely's loading of the GEOS libraries *in isolation* that hasn't been >> fixed. >> >> My Fiona package for Python also depends on libgeos_c.dylib, but in the >> more familiar way: it's a dependent library of GDAL, which is loaded when >> Fiona's C extension modules are loaded in Python. >> >> If we import fiona in a Python script and then import shapely from a >> binary wheel that includes GEOS libraries, the script will abort in either >> AbstractSTRtree::query or AbstractSTRtree::itemsTree because the dynamic >> casts yield null pointers. As far as I can tell, loading two copies of the >> C++ GEOS library is where the trouble starts. Is the trouble in the loader, >> the library code, or my builds? I do not know. >> >> There's no problem on Linux. The Linux library loader may be more >> foolproof or the library code might be compiled more correctly in a way >> that I don't yet see. I'm using the following flags in my builds – the dual >> architecture build is the only thing that seems unusual to me. >> >> environment = >> MACOSX_DEPLOYMENT_TARGET=10.9 >> configure-options = >> CFLAGS="-arch i386 -arch x86_64 -O2 -Wl,-S -Wall -Wstrict-prototypes" >> CXXFLAGS="-arch i386 -arch x86_64 -O2 -Wl,-S -Wall -Wstrict-prototypes" >> LDFLAGS="-arch i386 -arch x86_64" >> >> The thing that makes me suspect that there is a localized bug in GEOS is >> that loading the library twice doesn't lead to failures in computing areas, >> lengths, predicates, or WKT serializations. Only in the AbstractSTRtree >> module as far as I can tell. >> >> I've made a ticket at https://trac.osgeo.org/geos/ticket/848 and have >> attached a script that reproduces the problem as well as demonstrating that &g
[geos-devel] dynamic_cast may yield null pointers in AbstractSTRtree::query and AbstractSTRtree::itemsTree on OS X
Hi and Happy New Year, all. I found time recently to make notes on a frustrating issue that I'm having with GEOS in the Shapely binary wheels for OS X that I'm publishing on PyPI. I'm not certain whether there's a GEOS bug, a dynamic loader bug, a ctypes bug, misuse of computers on my part, or all four. I'd really appreciate a bit of advice from anyone with more C++ and Mach-O wisdom that would rule out a few of these possibilities. Here's the gist of it: Shapely uses dlopen (via Python's ctypes) to load libgeos_c.dylib at run time. The GEOS C++ library (libgeos-3.6.2.dylib, for example) is a dependent library of libgeos_c.dylib. I have been distributing the GEOS libs with my Shapely binaries for convenience of users, but Shapely also works with GEOS installed to the standard places on your system. I've never experienced or seen report of a problem with Shapely's loading of the GEOS libraries *in isolation* that hasn't been fixed. My Fiona package for Python also depends on libgeos_c.dylib, but in the more familiar way: it's a dependent library of GDAL, which is loaded when Fiona's C extension modules are loaded in Python. If we import fiona in a Python script and then import shapely from a binary wheel that includes GEOS libraries, the script will abort in either AbstractSTRtree::query or AbstractSTRtree::itemsTree because the dynamic casts yield null pointers. As far as I can tell, loading two copies of the C++ GEOS library is where the trouble starts. Is the trouble in the loader, the library code, or my builds? I do not know. There's no problem on Linux. The Linux library loader may be more foolproof or the library code might be compiled more correctly in a way that I don't yet see. I'm using the following flags in my builds – the dual architecture build is the only thing that seems unusual to me. environment = MACOSX_DEPLOYMENT_TARGET=10.9 configure-options = CFLAGS="-arch i386 -arch x86_64 -O2 -Wl,-S -Wall -Wstrict-prototypes" CXXFLAGS="-arch i386 -arch x86_64 -O2 -Wl,-S -Wall -Wstrict-prototypes" LDFLAGS="-arch i386 -arch x86_64" The thing that makes me suspect that there is a localized bug in GEOS is that loading the library twice doesn't lead to failures in computing areas, lengths, predicates, or WKT serializations. Only in the AbstractSTRtree module as far as I can tell. I've made a ticket at https://trac.osgeo.org/geos/ticket/848 and have attached a script that reproduces the problem as well as demonstrating that other GEOS modules are unaffected. It's interesting, but mostly baffling and humbling to go so deep into the weeds of dynamic library loading. I'm over my head here and super grateful for insights and discussion. -- Sean Gillies ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] What's the intent of 'assert(!"should never be reached")'?
On Wed, Sep 30, 2015 at 12:04 PM, Sandro Santilli wrote: > On Tue, Jul 07, 2015 at 12:12:54PM -0600, Sean Gillies wrote: >> There are three places in GEOS where this assertion appears >> >> >> https://github.com/libgeos/libgeos/blob/c9d94c2ebb68b6b679f03dc7eabebfcd39136def/src/index/strtree/AbstractSTRtree.cpp#L371 >> >> and two them have been tripping up Shapely users on OS X. I've found that >> rebuilding GEOS with --disable-cassert solves the user problems: no assert >> exceptions raised and no other program crashes. >> >> My question: what is the intent of these statements? If they can be safely >> ignored, as I'm doing, should they not be disabled by default? > > Unless you're extending GEOS by subclassing a Boundable, such an > assert would indicate a compile issue. > Thanks for the reply, Sandro. I've switched over to --disable-cassert (-DNDEBUG) in my library builds but am still falling through the tests above that assert at runtime in a particular case: - on OS X - calling unary union - loading libgeos_c.dylib via Shapely *after* loading libgeos_c.dylib (using a different path) via a different Python C extension module (Fiona). As reported at https://github.com/Toblerity/Fiona/issues/276, there's a unary union operation that returns a multipolygon when Shapely is imported first and an empty geometry collection when Shapely is imported second. Are there inherent pitfalls in loading libgeos twice on OS X? -- Sean Gillies ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] What's the intent of 'assert(!"should never be reached")'?
There are three places in GEOS where this assertion appears https://github.com/libgeos/libgeos/blob/c9d94c2ebb68b6b679f03dc7eabebfcd39136def/src/index/strtree/AbstractSTRtree.cpp#L371 and two them have been tripping up Shapely users on OS X. I've found that rebuilding GEOS with --disable-cassert solves the user problems: no assert exceptions raised and no other program crashes. My question: what is the intent of these statements? If they can be safely ignored, as I'm doing, should they not be disabled by default? -- Sean Gillies ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Exposing Precision model through C-API
On Mon, Mar 17, 2014 at 2:31 AM, Sandro Santilli wrote: > On Sun, Mar 16, 2014 at 12:24:19PM -0600, Sean Gillies wrote: > > On Mar 12, 2014 6:46 AM, "Sandro Santilli" wrote: > > > > > On Wed, Mar 12, 2014 at 06:16:00AM -0400, Paul Ramsey wrote: > > > > I would tend to expect choosing a single precision model and working > > > > with it for a long time to be a more common usage than swapping > > > > between lots of models. My bias. > > > > > > I also find this to be a more likely usecase. > > > > While agree that one model at a time (and two at the most) is the most > > likely use case, I'm concerned about designs that limit the number. I'm > > also reversing myself on whether there should be a precision model in the > > global context. I'd rather GEOS did not add more global state. > > > > Please see the wiki page > > http://trac.osgeo.org/geos/wiki/GSoC/CAPI_PrecisionModel for my > (Shapely) > > requirements. > > So what would you think about "parking" a pointer to the client-owned > GeometryFactory into the "context" right before calling the geometry > creation functions ? Such "parking" method would return the old > GeometryFactory, so that you can pass it back. You'd only own the > GeometryFactory objects you'd have explicitly created. > > I'm talking about GeometryFactory rather than PrecisionModel because > the object referenced by geometries is really a GeometryFactory, > not a PrecisionModel. A GeometryFactory also references a > CoordinateSequenceFactory. > Sounds practical. Geometry objects will have to park their factories before every operation, right? Offloading complexity to client code seems fair enough. I've updated my wiki notes to refer to geometry factories instead of models. -- Sean Gillies ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Exposing Precision model through C-API
On Mar 12, 2014 6:46 AM, "Sandro Santilli" wrote: > On Wed, Mar 12, 2014 at 06:16:00AM -0400, Paul Ramsey wrote: > > I would tend to expect choosing a single precision model and working > > with it for a long time to be a more common usage than swapping > > between lots of models. My bias. > > I also find this to be a more likely usecase. > > --strk; > While agree that one model at a time (and two at the most) is the most likely use case, I'm concerned about designs that limit the number. I'm also reversing myself on whether there should be a precision model in the global context. I'd rather GEOS did not add more global state. Please see the wiki page http://trac.osgeo.org/geos/wiki/GSoC/CAPI_PrecisionModel for my (Shapely) requirements. ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Exposing Precision model through C-API
Hi Sandro, My Shapely project would benefit from this feature and I've written up its requirements here: https://github.com/Toblerity/Shapely/issues/110. Briefly, I'd like to be able to pass a precision model reference into initGEOS and create an appropriate geometry factory in the GEOS context. And I'd like to be able to switch between precision models within a Python program, so not adding any new state outside of the context struct would be my preference. Once a wiki page is created, I'll be happy to copy my requirements there. On Thu, Feb 13, 2014 at 11:19 AM, Sandro Santilli wrote: > On Thu, Feb 13, 2014 at 05:25:17PM +0530, Anubhav Jaiswal wrote: > > Hi, > > > > Just wanted to know whether GEOS is applying for GSoC'14 under OSGeo. If > > yes, will this(exposing precision model) be a sufficient task or are > there > > any other project ideas for GSoC. > > I'm available for mentoring such a project, which I find sufficient. > > There might be some GSoC ideas wiki page but I don't know right away. > For sure I can tell you that this exposure would be enough to cut up > the next GEOS minor release (3.5.0), given current development speed... > > --strk; > > ___ > geos-devel mailing list > geos-devel@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/geos-devel > -- Sean Gillies ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] New overlay validation, call for tests
All the Shapely tests are passing, FWIW.
On Wed, Jul 31, 2013 at 3:51 AM, Sandro Santilli wrote:
> I've just committed in trunk a change in the overlay operation
> heuristic to reduce the possibility of getting invalidly noded
> output.
>
> We used to get unnoded output due to common-bits-reducer
> heuristic introducing invalidities when moving the output
> geometry back to its original position (the input geometries
> were translated near the origin to have more computation bits).
>
> The new code re-checks noding after shifting back and refuses
> to accept a result if it isn't properly noded. This is still not
> 100% accurate in that results with mixed-typed components are
> not really checked for self-intersection, so you can still get
> such cases.
>
> In addition, the code now checks if the input is valid before
> trying the various heuristics, so that you would get a message
> about that, which is usually easier to read. Example:
>
> => select st_union('POLYGON((0 0, 10 10, 10 0, 0 10, 0 0))'::geometry,
> 'POLYGON((0 0, 5 0, 5 5, 0 5, 0 0))'::geometry);
> ERROR: GEOSUnion: TopologyException: Input geom 0 is invalid:
> Self-intersection at or near point 5 5 at 5 5
>
> This will be in GEOS-3.4.0, which I'm trying to close ASAP, so please
> run your tests against the trunk version in order to catch any problem
> earlier.
>
> Thank you !
>
> --strk;
> _______
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>
--
Sean Gillies
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Question about std::cerr in EdgeRing::getRingInternal() and polygonizing
In polygonizing OSM data, I'm seeing a lot of this in my stderr: EdgeRing::getRingInternal: IllegalArgumentException: Invalid number of points in LinearRing found 3 - must be 0 or >= 4 It's coming from: http://trac.osgeo.org/geos/browser/trunk/src/operation/polygonize/EdgeRing.cpp#L228 Do these caught exceptions correspond to members of the invalid ring list of the Polygonizer? In my case, polygonize_full shows me 1395 invalid rings and there are 676 error messages, so it seems possible. Related: should the output be restricted to debugging mode? Thanks, -- Sean Gillies ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Question about GEOSPolygonize_full_r
Thanks a bunch, strk! I got it sorted out with your reminder: https://github.com/Toblerity/Shapely/issues/57. On Fri, Jul 19, 2013 at 1:34 AM, Sandro Santilli wrote: > On Thu, Jul 18, 2013 at 09:47:35PM -0600, Sean Gillies wrote: > > Hi all, > > > > Shapely users have been asking me about access to GEOSPolygonize_full_r > and > > I'm looking into it today. One thing I don't understand about the > function > > (not being much of a C++ programmer anymore) is why the cuts, dangles, > and > > invalid rings are only retrieved if the pointers passed in for them are > not > > NULL? > > > > http://trac.osgeo.org/geos/browser/tags/3.3.8/capi/geos_ts_c.cpp#L3077 > > > > Wouldn't it be better if the pointers *were* NULL since they are supposed > > to point to memory allocated by this function instead of bringing in data > > from the caller? > > The pointer value (*cuts) can be null, the code doesn't even check for > that. > But you pass a pointer to the pointer, so that the code can change the > pointer value. > > --strk; > _______ > geos-devel mailing list > geos-devel@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/geos-devel > -- Sean Gillies ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Question about GEOSPolygonize_full_r
Hi all, Shapely users have been asking me about access to GEOSPolygonize_full_r and I'm looking into it today. One thing I don't understand about the function (not being much of a C++ programmer anymore) is why the cuts, dangles, and invalid rings are only retrieved if the pointers passed in for them are not NULL? http://trac.osgeo.org/geos/browser/tags/3.3.8/capi/geos_ts_c.cpp#L3077 Wouldn't it be better if the pointers *were* NULL since they are supposed to point to memory allocated by this function instead of bringing in data from the caller? -- Sean Gillies ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Polygon simplicity and validity
Is simplicity meaningful for polygons or only for lines? Here's a single ring bowtie that GEOS 3.3.0 reports as invalid but simple: POLYGON ((39.145133029967 23.751008160014, 97.053722089937 40.545500879987, 105.265270139984 48.133022130005, 100.917526850016 58.433368149997, 71.560814480048 83.551148010057, 60.711891680008 86.253160989978, 62.004698079972 75.147817599962, 83.163100069987 42.820716730009, 92.823058619976 37.191755819974, 95.994011290031 26.470512459984, 106.220544820006 15.519751919991, 39.145133029967 23.751008160014)) https://github.com/Toblerity/Shapely/issues/16#issuecomment-8116396 -- Sean Gillies ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] M-coordinate support
Hi Mike, Would GEOS need to implement M coordinate basis algorithms to fully profit from this? Do those exist? (I have no idea) On Tue, Jul 10, 2012 at 5:41 AM, Mike Toews wrote: > Hi devs, > > I'd like to know if "measure" or M-coordinate support is somewhere on > the development horizon for GEOS. I could see the benefit of opening > client software to support ISO 19125 compliant geometries, such as in > OGR or Shapely. > > Possibly the first widespread use of M-coordinates started in the > 1990s with the Shapefile file format, as detailed in the 1998 ESRI > technical specs. With open source software, Shapelib and PostGIS has > supported M-coordinates for quite some time (possibly close to a > decade?). More recently, Simple Features Access Standards published by > OGC and later ISO 19125, detail the use and storage of of > M-coordinates in various geometry types. > > Are there any limitations to adopting M-coordinate support for GEOS? > Potential performance loss? Other limitations or incompatibilities? > I'm curious, as I often run into instances where this dimension is > useful, but am a bit stumped at it's lack of support in some software. > Thanks. > > -Mike > ___ > geos-devel mailing list > geos-devel@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/geos-devel -- Sean Gillies ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.3.3?
Such as minimum bounding circle for the C API? Though it looks like other C API changes are scheduled for 3.4. On Tue, Feb 21, 2012 at 11:52 PM, Sandro Santilli wrote: > On Tue, Feb 21, 2012 at 10:35:08AM -0800, Paul Ramsey wrote: >> Any objection to my pushing out a 3.3.3? I see there are some small >> win32 fixes that I'm sure folks would enjoy not having to handfix >> building the tarball (having just hand-fixed them myself). > > Let's at least take a look at the 6 open tickets in that milestone > for low hanging fruits ? After which, no problem with me with taking > 3.3.3 out and planning a 3.3.4 > > --strk; > ___ > geos-devel mailing list > geos-devel@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/geos-devel -- Sean Gillies ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] distance
On Fri, Aug 26, 2011 at 9:50 AM, Tomas Neme wrote: > I'm looking at the geos API and I don't undestand what units are the > distance parameters supposed to be.. > > I'm trying to use buffer, to create a 1km circle around a Point > defined in SRID=22186, and.. I have no clue how to do this. > > Thanks > > Tomas Hi Tomas, All the GEOS operations are done in a unitless Cartesian space. Distance is unitless. For example, the distance between a point at (0, 0) and (1, 1) is sqrt(2). 22186 has units of meters, right? As long as your distances are in meters (1000 in your case), you'll be fine. Regards, -- Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Second beta for ffi-geos extension now available
On Thu, May 12, 2011 at 9:28 AM, Sandro Santilli wrote: > On Thu, May 12, 2011 at 11:16:19AM -0400, J Smith wrote: >> On Thu, May 12, 2011 at 2:19 AM, Sandro Santilli wrote: >> > Right. In the PHP binding I've made a single function taking an associative >> > array for all the parameters (building a GEOSBufferParameter object). >> > >> >> Yeah, I noticed that and decided to follow suit. I'd like the two to >> be reasonably close together in terms of their APIs and conventions >> aside from the usual language quirks and conventions. > > Speaking of which... how did you deal with prepared geoms ? > I didnt' make any use of those from the PHP binding. Dunno if I want > them to be transparent or explicit. > FWIW, Shapely has a prep() function that prepares a geometry. The result has a subset of the normal geometric object methods. http://gispython.org/shapely/docs/1.2/manual.html#prepared-geometry-operations -- Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] SVN commits failing
I've got a fix for #436, my first commit in a while, and I'm getting the following error message on a commit to http://svn.osgeo.org/geos/trunk. Anybody know what's up? Svn update works fine. svn: Commit failed (details follow): svn: Server sent unexpected return value (500 Internal Server Error) in response to MKACTIVITY request for '/geos/!svn/act/5f521cdf-6dec-43b1-ab2c-ceba246a71d3' Additionally, there seems to be a header missing in the trunk: error: geos/operation/buffer/OffsetCurveVertexList.h: No such file or directory -- Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS-3.3.0 enters feature freeze
On Fri, Apr 22, 2011 at 9:36 AM, Sandro Santilli wrote: > On Wed, Apr 20, 2011 at 05:18:49PM +0200, Sandro Santilli wrote: >> On Wed, Apr 13, 2011 at 09:28:56AM +0200, Sandro Santilli wrote: >> >> > So, if you agree, I'd call feature-freeze in one week unless someone. >> > Please PSC cast your votes. >> >> As it didn't work, I'll rephrase: >> So, if nobody disagrees, I'll call feature-freeze in one day :) > > We're officially in feature freeze mode for GEOS-3.3.0. > Please everyone take a look at own bugs and act upon them. > > There are 8 tickets filed for the 3.3.0 milestone. > Three of them are task/enhancements, assigned to Mateusz and Paul. > I've added a "GEOS Future" milestone if you want to move them elsewhere. > Somebody pointed out to me yesterday that the GEOS C API is missing some prepared geometry functions (touches, etc). I think I might be getting a patch for this any day now and so if you don't mind, I'm going to travel back in time and slip those enhancements in before the freeze. -- Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Ruby, FFI and ERROR_/NOTICE_MESSAGE
On Wed, Dec 8, 2010 at 10:34 PM, J Smith wrote: > On Thu, Dec 9, 2010 at 12:09 AM, Charlie Savage wrote: >>> I believe that the crux of the problem may be due to GEOS's error >>> handlers using varargs, which libffi cannot handle in callbacks >>> according to its documentation. >> >> Just did a quick read of https://github.com/ffi/ffi/wiki/examples and the >> google group. Seems like in general FFI does support varargs. Are callbacks >> a special case that isn't handled? How hard do you suppose to get them to >> work? >> > > I think callbacks are a special case, although the documentation is > somewhat vague. In the Missing Features section of the info > documentation, it says: > > "There is no support for calling varargs functions. This may work on > some platforms, depending on how the ABI is defined, but it is not > reliable." > > I believe this is referring to callbacks. When setting up a callback > along these lines... > > attach_function(:initGEOS_r, callback([ :string, :varargs ], :void), :void) > ... > FFIGeos.initGEOS_r( > self.method(:error_handler), > self.method(:error_handler) > ) > ... > def error_handler(*args) > p(args) > end > > All you get for the varargs argument is nil and the segfaults and > weirdness occurs as before. It appears that this is a special case, I > guess. > > Another option beyond modifying GEOS directly might be to write a > small native C shim between the CAPI and Ruby and access the error > messages through that. It might not be ideal, as I think it would be > preferable to keep the library purely Ruby, but it would be an option > that wouldn't affect the CAPI or cause any binary compatibility breaks > should the context handler need to be changed. > > I'll ask around the FFI groups and see what turns up. > > Cheers! FWIW, here's the GeoDjango approach: http://code.djangoproject.com/browser/django/trunk/django/contrib/gis/geos/libgeos.py#L53 and the Shapely approach: https://github.com/sgillies/shapely/blob/master/shapely/geos.py#L148 Shapely by default takes the error messages and sends them to /dev/null because I didn't find them super useful. Each of the above use a callback factory from ctypes http://docs.python.org/library/ctypes.html#callback-functions ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS Ruby bindings gem and extensions
On Wed, Dec 1, 2010 at 11:55 AM, strk wrote: > On Wed, Dec 01, 2010 at 11:44:05AM -0700, Charlie Savage wrote: > >> The downside is that the different language bindings (ie python and >> ruby) go their separate ways. But that is already the case anyway... > > Yeah, also for PHP I didn't use swig... > I've nothing other than anecdotal evidence, but I'm convinced Shapely (https://github.com/sgillies/shapely) has picked up more patches than it would have if it were maintained within GEOS. I've also been able to push out 22 releases in the time that GEOS has had 11 (11 is not a bad number at all). Isn't Ruby-FFI (https://github.com/ffi/ffi/wiki/why-use-ffi) production ready? I'm having nothing but success with Python's ctypes (and libffi) on Linux, OS X, and Windows. -- Sean Gillies Programmer Institute for the Study of the Ancient World New York University ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] PHP bindings anyone ?
On Wed, Jun 16, 2010 at 12:57 AM, Robert Coup wrote: > On Tue, Jun 15, 2010 at 11:16 PM, strk wrote: >> >> I'm plaing with drupal recently and be wondering >> if the SWIG binding for GEOS are still in use by >> anyone or not. >> >> In particular, I think Shapely and GeoDjango >> are using a direct interface rather than swig, right ? > > > Yep, they both access the C library using the Python ctypes module. AFAIK > they just wanted to expose clean "pythonic" interfaces rather than the > hybrid stuff SWIG produces... >From time to time I hear from some one who is using the SWIG bindings for Ruby. Are there any libffi (used by ctypes) intefaces for PHP? If so, I'd recommend giving that a try. Cheers, -- Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] use of STRtree functions in C API
Hi everybody, On Tue, May 4, 2010 at 5:54 PM, Martin Davis wrote: > > > Howard Butler wrote: >> >> >>> >>> I need GEOS for Touches/Disjoint (topology operations) anyway, so extra >>> dependencies are not a help, rather the opposite. >>> >> >> Indexing is orthogonal to GEOS main geometry algebra operations, IMO. I >> don't like that we expose internal indexing stuff publicly because it will >> limit the library's options to do something different in the future. That >> it uses an index to do things internally for things like prepared geometry >> is an implementation detail. Small pieces, loosely joined, not giant >> monoliths (/me stares in GDAL's >> embedding-every-library-in-the-entire-osgis-ecosystem's direction). I >> understand the desire to not have extra dependencies, but if you want a >> general, programmable rtree, GEOS' isn't it at this time. >> >> To the GEOS devs, is GEOS to be an indexing library too? >> > > Sure, why not? At least for in-memory indexes - there are no plans to > extend this to disk-based indexes. > > Reasons are: > i) The code is there and well-tested > ii) The index is designed to work well with GEOS objects (although as you > point out, indexes are fairly independent) > iii) This reduces the need for dependencies on other librarries (as I think > you have just recommended) > > Of course as you say this exposes an interface which will need to be > maintained in the future. But there's a fairly low cost to maintaining the > simple indexes currently provided (and there are no current plans to stop > using them in GEOS itself). > >> >>> >>> All I need is to identify which bounding boxes (envelopes in GEOM-speak) >>> intersect for a fixed set of objects whose bounding boxes I can compute, and >>> where GEOS is already present and running. >>> >> >> Doesn't GEOS' prepared geometry stuff already do this, or is that not >> sufficient? Maybe I don't understand the problem well enough. >> > > PreparedGeometry optimizes the computation between two individual > geometries, but it doesn't optimize the situation of processing two sets of > geometries in pairwise fashion. For that you need a spatial index. > I've done a bit of benchmarking using Rtree (libspatialindex) and Shapely (GEOS) and am finding that using a spatial index to select candidates for intersects() and within() isn't as big a win as I had expected. The GEOS predicates short-circuit when the bounding boxes of the features don't intersect http://trac.osgeo.org/geos/browser/trunk/src/operation/relate/RelateComputer.cpp#L67 Testing the bounds is O(N) (N being number of vertexes) and so the cost of evaluating intersects() for unrelated features that would be excluded by an index search is dwarfed by the cost of evaluating intersects() for complicated related features (about O(N log N) yes?). I'm finding 2X faster queries when using a spatial index in combination with intersects() for small (radius 0.01, N=64) polygons related to a large (radius 1.0, N=64) polygon in a 10.0 x 10.0 space. Faster, yes, but not justifying the creation of a spatial index for one search. -- Sean Gillies Programmer Institute for the Study of the Ancient World New York University ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Questions about linear referencing
On Feb 1, 2010, at 4:31 PM, David Turner wrote: On Mon, 2010-02-01 at 11:04 +0100, Sean Gillies wrote: The GEOSProject function returns a numerical value when passed a line string and a point not on the line. If the point is beyond (in some sense) the line's starting point, you get 0.0 (normalized). If the point is past (in some sense) the line's end point, you get 1.0 (normalized to the line's length). If the point is otherwise off of the line but not past one of its ends in that sense, you get a value between 0 and 1. Is this intended? The behavior seems like it could get rather unpredictable for anything other than a perfectly straight line. This comes from the LengthIndexedLine::project method. That method finds the closest point along the geometry to the input point. That closest point could be one of the end points. Why is this unpredictable? That does seem predictable. I just couldn't tell from the code or docs what the intent of the function exactly was. If it's intent is the same as ST_line_locate_point from PostGIS, I'm clear. Thanks, -- Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Questions about linear referencing
The GEOSProject function returns a numerical value when passed a line string and a point not on the line. If the point is beyond (in some sense) the line's starting point, you get 0.0 (normalized). If the point is past (in some sense) the line's end point, you get 1.0 (normalized to the line's length). If the point is otherwise off of the line but not past one of its ends in that sense, you get a value between 0 and 1. Is this intended? The behavior seems like it could get rather unpredictable for anything other than a perfectly straight line. -- Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] python bindings in trunk
Hi Michael, please see http://trac.osgeo.org/geos/browser/trunk/swig/python/README.txt Cheers, Sean On May 28, 2009, at 7:14 PM, Michael Toews wrote: Hi, I've compiled geos from svn/trunk r2533 to (hopefully) use some new features ported from JTS 1.9 last month. I am using an Ubuntu 8.04 LTS server, which already has libgeos-c1 and libgeos2c2a from apt (I'm not sure if this matters or not). I compiled r2533 using "./configure --enable-python", and the report said that both swig and python is enabled. After "make"/"make install", I tried going into Python: Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. import geos Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.5/site-packages/geos/geos.py", line 6, in import _geos ImportError: /usr/local/lib/python2.5/site-packages/geos/_geos.so: undefined symbol: GEOSWKTReader_create Any idea why? Thanks in advance. -Mike ___ 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] GEOS cross-heap problems
On May 13, 2009, at 7:42 AM, Mateusz Loskot wrote: Frank Warmerdam wrote: strk wrote: On Wed, May 13, 2009 at 12:19:23AM -0400, Frank Warmerdam wrote: Only, it'll have to stay (I've read Mateusz suggesting using type-specific destroyers). I cannot imagine why a type specific destroyer would be needed for simple malloc()/free() buffer allocations. Frank, But GEOS user does not know what allocator is hidden behind GEOSGeomToWKT function and he does *not* need or want to know. GEOSFree exposes all the meat that is supposed be encapsulated and it makes GEOS C API not symmetric so confusing. Aren't we supposed to be using the reader/writer API now? Add GEOSWK*Writer_Free functions (if we must) to those interfaces and GEOSFree to address the problem with deprecated GeomToWKT? Cheers, Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.1 Tag?
Thanks, Paul. On Mar 24, 2009, at 9:19 PM, Paul Ramsey wrote: r2274 On Tue, Mar 24, 2009 at 8:17 PM, Paul Ramsey wrote: Sweet mary francis, I deserve a slap upside the head. P On Tue, Mar 24, 2009 at 8:02 PM, Sean Gillies wrote: What revision was released as 3.1? ___ 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 ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] 3.1 Tag?
What revision was released as 3.1? ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Bug in GEOSEquals predicate ?
The GEOS C API returns a integer value of 2 to indicate an error. It's good to learn that geometry collection predicates aren't supported. On Mar 16, 2009, at 9:46 AM, Martin Davis wrote: GEOS does not support evaluating predicates on GEOMETRYCOLLECTIONS (due to the potential complexity and lack of obvious semantics of heterogeneous collections). In JTS trying to do this throws an exception. I'm not sure how GEOS reacts - or possibly shapely is not handling this gracefully? Pascal Leroux wrote: Hi all while searching for intersections between polygons (buildings), I have found shapes that make "equals" predicate crash. With simpler shapes, it occurs too : >>> from shapely.geometry import Polygon >>> p1 = Polygon(((0,0),(0,10),(10,10),(10,0),(8,0),(8,8),(2,8), (2,0))) >>> p2 = Polygon(((2,0),(2,8),(8,8),(7,4),(8,0))) >>> inter = p1.intersection(p2) >>> inter.is_valid and p1.is_valid and p2.is_valid True >>> inter.wkt 'GEOMETRYCOLLECTION (POINT (8. 0.), LINESTRING (8. 8., 2. 8.), LINESTRING (2. 8., 2. 0.))' >>> inter.equals(p1) False >>> inter.equals(p2) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/site-packages/Shapely-1.0.11-py2.5.egg/ shapely/predicates.py", line 34, in __call__ return bool(self.fn(self.context._geom, other._geom)) File "/usr/lib/python2.5/site-packages/Shapely-1.0.11-py2.5.egg/ shapely/predicates.py", line 21, in errcheck raise PredicateError, "Failed to evaluate %s" % repr(self.fn) shapely.geos.PredicateError: Failed to evaluate <_FuncPtr object at 0x96a3bf4> I have got a Bus Error on MacOSX (libgeos version 3.0.0) and a Segmentation Fault on Ubuntu (libgeos version 3.0.3) with an equivalent code written in C (so I think Shapely is not involved). Any idea ? Did I miss something ? Pascal ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ___ 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] Bug in GEOSEquals predicate ?
On Mar 14, 2009, at 3:06 AM, Pascal Leroux wrote: Hi all while searching for intersections between polygons (buildings), I have found shapes that make "equals" predicate crash. With simpler shapes, it occurs too : >>> from shapely.geometry import Polygon >>> p1 = Polygon(((0,0),(0,10),(10,10),(10,0),(8,0),(8,8),(2,8), (2,0))) >>> p2 = Polygon(((2,0),(2,8),(8,8),(7,4),(8,0))) >>> inter = p1.intersection(p2) >>> inter.is_valid and p1.is_valid and p2.is_valid True >>> inter.wkt 'GEOMETRYCOLLECTION (POINT (8. 0.), LINESTRING (8. 8., 2. 8.), LINESTRING (2. 8., 2. 0.))' >>> inter.equals(p1) False >>> inter.equals(p2) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/site-packages/Shapely-1.0.11-py2.5.egg/ shapely/predicates.py", line 34, in __call__ return bool(self.fn(self.context._geom, other._geom)) File "/usr/lib/python2.5/site-packages/Shapely-1.0.11-py2.5.egg/ shapely/predicates.py", line 21, in errcheck raise PredicateError, "Failed to evaluate %s" % repr(self.fn) shapely.geos.PredicateError: Failed to evaluate <_FuncPtr object at 0x96a3bf4> I have got a Bus Error on MacOSX (libgeos version 3.0.0) and a Segmentation Fault on Ubuntu (libgeos version 3.0.3) with an equivalent code written in C (so I think Shapely is not involved). Any idea ? Did I miss something ? Pascal Hi Pascal, Get those test geometries into WKT form so others can more easily try them, and add a bug to the GEOS tracker. I'll look into it. Cheers, Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] [GEOS] #228: import python bindings fails
Paul,
I stopped work on the SWIG wrappers for GEOS for three reasons
1) Abominable Python API derived from GEOS C++ (personal taste,
admittedly)
2) Instability of C++ API between 2.2 and 3.0
3) Accessing libgeos_c via libffi and ctypes is more portable
As far as I know, Charlie is still supporting Ruby through SWIG, and I
think that means that Python support remains pretty close. I do think
that Python users should be using Shapely (outside of GeoDjango), but
realize that people may want other options. Shapely requires Python
2.4, and one could generate wrappers with SWIG that would work with
2.2 or 2.3.
Sean
On Feb 2, 2009, at 12:32 PM, Paul Ramsey wrote:
Sean,
I've never really grokked the pythonic state of affairs. Let me try
and relay my guess: the python code in GEOS svn is orphaned; all
pythonic work is largely flowing through shapely now, which doesn't
need any code in the GEOS svn. Is that right? If so, I'd like to
replace the python code in the release with a README that says "go use
shapely".
P
-- Forwarded message --
From: GEOS
Date: Mon, Feb 2, 2009 at 11:12 AM
Subject: [geos-devel] [GEOS] #228: import python bindings fails
To: undisclosed-recipients
#228: import python bindings fails
+---
Reporter: martinm | Owner: geos-devel@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 3.1.0
Component: Default | Version: 3.1.0rc1
Severity: Unassigned |Keywords:
+---
Importing python module fails:
{{{
import geos
Traceback (most recent call last):
File "", line 1, in
File "/Library/Python/2.5/site-packages/geos/geos.py", line 60, in
class PySwigIterator(object):
File "/Library/Python/2.5/site-packages/geos/geos.py", line 64, in
PySwigIterator
__swig_destroy__ = _geos.delete_PySwigIterator
AttributeError: 'module' object has no attribute
'delete_PySwigIterator'
}}}
--
Ticket URL:
GEOS
Re: [geos-devel] 3.1.0rc2
Fine here. That cascaded union problem remains. On Jan 30, 2009, at 1:18 PM, Paul Ramsey wrote: I've placed RC2 on the download site, with Matz changes and the removal of stoopid debugging noise in the last one. http://download.osgeo.org/geos/geos-3.1.0rc2.tar.bz2 PSC, if you don't howl about this one, I'm going to make the link public on Monday morning. -- Paul Ramsey OpenGeo - http://opengeo.org PostGIS is Love. ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel -- Sean Gillies sean.gill...@gmail.com http://sgillies.net ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.1.0rc1
Another data point: I found Dane's shapefile to contain 100 polygons and 145 multipolygons. I was able to cascade union a) the first collection of 100 polygons, and also b) the collection of 3238 polygons exploded from the 145 multis. An attempt to cascade union everything (a + b) failed, as you're finding. http://lists.gispython.org/pipermail/community/2009-January/001963.html Sean On Jan 29, 2009, at 1:39 PM, Martin Davis wrote: I would have expected so - so I'm puzzled. No further ideas at the moment, I'm afraid. Paul Ramsey wrote: I can do an individual union of Mozambique and Zimbabwe without problems. Should I be seeing a topology exception? P On Thu, Jan 29, 2009 at 12:09 PM, Martin Davis > wrote: When I look at the area of the reported TopologyException in OpenJUMP, I'm seeing the following kinds of vertex values: Feature ID: 122 [ 3:0:666] POINT (32.47623099984 -21.32185399973) Feature ID: 222 [ 0:144] POINT (32.476231 -21.321854) So the dataset is not actually 100% cleanly noded. These kinds of small discrepancies are exactly the kind of situation which used to cause robustness errors in JTS. This has pretty much been fixed by the addition of the Geometry Snapping concept. I think this made it into GEOS - but perhaps there's a bug in it? It should be possible to narrow down the problem by finding the two geometries which containing the problematic points and just working with them. (Mozambique and Zimbabwe) Paul Ramsey wrote: Incidentally, the problem is not the invalid geometries. I first tried the union after "fixing" them with buffer(0), but I just now tried the union after deleting them, with the same result. aggtest=# delete from tm_world_2 where not st_isvalid(the_geom); NOTICE: Ring Self-intersection at or near point -53.7564 48.5033 NOTICE: Ring Self-intersection at or near point -70.9172 -54.7086 NOTICE: Ring Self-intersection at or near point 5.33694 61.5928 NOTICE: Ring Self-intersection at or near point 143.662 49.3122 DELETE 4 aggtest=# select geometrytype(st_union(the_geom)) from tm_world_2; NOTICE: TopologyException: found non-noded intersection between 32.4122 -21.2178, 32.4762 -21.3219 and 32.4762 -21.3219, 32.4122 -21.2178 32.4756 -21.3208 ERROR: GEOS2POSTGIS returned an error aggtest=# P On Wed, Jan 28, 2009 at 1:49 PM, Paul Ramsey wrote: For anyone that needs a test geometry, here's Dane's input as a single multipolygon: http://cleverelephant.dyndns.org/~pramsey/bigmulti.txt.bz2 On Wed, Jan 28, 2009 at 7:44 AM, Hartmut Kaiser wrote: I just did a bit further testing of the new cascaded union goodness via Shapely. See the linked email below: http://lists.gispython.org/pipermail/community/2009-January/001960.html Seems that I reached where a point that 'should never be reached' ? http://trac.osgeo.org/geos/browser/trunk/source/index/strtree/AbstractS TRtree.cpp#L358 I am new to looking at the geos code, so any pointers to help me test more would be great. Could you provide a minimal test I could use to reproduce this problem? Regards Hartmut Thanks! Dane On Jan 27, 2009, at 9:02 PM, Dane Springmeyer wrote: Paul, I tested on mac 10.5 and ubuntu 8.10 and all configure;make and make installs went perfectly. Just a few compiler warnings that I've pasted here: http://dpaste.com/hold/113736/ Dane On Jan 27, 2009, at 10:35 AM, Paul Ramsey wrote: This is a pre-warning to PSC members to download and test the first 3.1 rc tarball: http://download.osgeo.org/geos/geos-3.1.0rc1.tar.bz2 If I don't hear any howls of dismay over the next 24 hours, I will make a wider announcement for testing. Paul ___ 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 ___ 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 ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ___ 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 -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ___
Re: [geos-devel] 3.1.0rc1
GEOS 3.1.0rc1 is dumping debugging noise from GEOSUnionCascaded,
something we should fix.
Dane's shapefile is a bit broken, being a mix of polygons and
multipolygons. Is that the problem?
Sean
On Jan 28, 2009, at 1:45 PM, Paul Ramsey wrote:
Well, I'm seeing the same thing, with a bit more information:
aggtest=# select geometrytype(st_union(the_geom)) from tm_world;
NOTICE: TopologyException: found non-noded intersection between
21.8917 -26.6689, 21.9536 -26.6644 and 21.9536 -26.6644, 21.8917
-26.6689 21.953 -26.6645
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!> \q
The crash is probably the result of bad null/exception handling on my
part, but the core problem is that one of the union pairs is failing.
Basically ST_Union(geom1, geom2) still isn't 100% robust, so if you
find (or create) a pairing that doesn't work, you're SOL.
There's a hack approach to this which would probably work "better",
but still not 100%, and that would be to catch the exception when it
occurs in GEOS, and put the bad pair off to the side everything else
is done. Then try to union(finalresult, bad1) and union(finalresult,
bad2) in the hopes that the specific problem of union(bad1, bad2)
doesn't come up in the union with the finalresult.
I'm going to wrap this data into a MULTIPOLYGON for Hartmut to run,
which should allow him to extract the bad pairing, which we can then
give to Martin and see if JTS also dislikes it.
P.
On Wed, Jan 28, 2009 at 11:54 AM, Dane Springmeyer
wrote:
Hi Paul and Hartmut,
Sean wisely mentioned I should be careful in testing shapefiles
with invalid
polygons, which I definitely forgot to think about since I was
reading in
the shapefile directly.
Nevertheless with both this original shapefile [1] (that does have
invalid
polygons) and a cleaned up version (with the buffer(0) trick) that
I have
posted here [2], the below script results in the "should never be
reached"
assertion.
Perhaps the cleaned up shapefile [2] is still invalid for passing
directly
to the cascaded_union, just let me know how to test further.
Cheers,
Dane
[1] http://thematicmapping.org/downloads/TM_WORLD_BORDERS-0.3.zip
[2] http://dbsgeo.com/tmp/test_world_shapefile.zip
### python ###
from shapely.ops import cascaded_union
from osgeo import ogr
from shapely.wkb import loads
ds = ogr.Open('tm_world_buffer_zero.shp')
state = ds.GetLayer(0)
states = []
while 1:
f = state.GetNextFeature()
if f is None: break
g = f.geometry()
states.append(loads(g.ExportToWkb()))
print len(states) # 246
u = cascaded_union(states)
[snip...]
cxx type MultiPolygon
cxx type Polygon
cxx type Polygon
cxx type Polygon
cxx type Polygon
cxx type MultiPolygon
cxx type MultiPolygon
cxx type MultiPolygon
cxx type MultiPolygon
Assertion failed: (!"should never be reached"), function itemsTree,
file
AbstractSTRtree.cpp, line 358.
Abort trap
On Jan 28, 2009, at 10:33 AM, Paul Ramsey wrote:
Dane, can you provide the shapefile? I will see if this reproduces
in
PostGIS and generate a test file for Hartmut if it does.
P.
On Tue, Jan 27, 2009 at 9:40 PM, Dane Springmeyer >
wrote:
Hi again,
I just did a bit further testing of the new cascaded union
goodness via
Shapely. See the linked email below:
http://lists.gispython.org/pipermail/community/2009-January/001960.html
Seems that I reached where a point that 'should never be reached' ?
http://trac.osgeo.org/geos/browser/trunk/source/index/strtree/AbstractSTRtree.cpp#L358
I am new to looking at the geos code, so any pointers to help me
test
more
would be great.
Thanks!
Dane
On Jan 27, 2009, at 9:02 PM, Dane Springmeyer wrote:
Paul,
I tested on mac 10.5 and ubuntu 8.10 and all configure;make and
make
installs went perfectly.
Just a few compiler warnings that I've pasted here:
http://dpaste.com/hold/113736/
Dane
On Jan 27, 2009, at 10:35 AM, Paul Ramsey wrote:
This is a pre-warning to PSC members to download and test the
first
3.1 rc tarball:
http://download.osgeo.org/geos/geos-3.1.0rc1.tar.bz2
If I don't hear any howls of dismay over the next 24 hours, I
will
make a wider announcement for testing.
Paul
___
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
___
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
___
geos-devel ma
Re: [geos-devel] 3.1.0rc1
RC 1 builds and seems to work fine here on OS X 10.5, gcc 4.0.1, at least with Shapely. Haven't tried the reentrant API yet, but intend to next week. Sean On Jan 27, 2009, at 10:02 PM, Dane Springmeyer wrote: Paul, I tested on mac 10.5 and ubuntu 8.10 and all configure;make and make installs went perfectly. Just a few compiler warnings that I've pasted here: http://dpaste.com/hold/113736/ Dane On Jan 27, 2009, at 10:35 AM, Paul Ramsey wrote: This is a pre-warning to PSC members to download and test the first 3.1 rc tarball: http://download.osgeo.org/geos/geos-3.1.0rc1.tar.bz2 If I don't hear any howls of dismay over the next 24 hours, I will make a wider announcement for testing. Paul ___ 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 ___ 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)
David, thank you. Cheers, Sean On Jan 14, 2009, at 9:07 AM, David William Bitner wrote: Here are the specs that were used, the only requirement was for intersection, but I'm not sure if anything else was affected. On Wed, Jan 14, 2009 at 3:04 AM, strk wrote: 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 -- David William Bitner ___ 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
3D operations (Re: [geos-devel] C API coordinate sequence dimensions)
"Smurf code"? Smurfs are good, if I remember my Saturday morning
cartoons :)
It would probably take me much longer to grep and read through the
code base to find which functions are 3D and document them in the wiki
than it would take the authors ... can I do anything to entice them to
document the 3D functions?
Sean
On Jan 12, 2009, at 12:49 PM, Obe, Regina wrote:
I looked at the GEOS code a while back and compared to JTS and
was shocked that I saw GEOS z (as I call it smurf code and did not see
this smurf code in JTS).
This was when I was testing the PostGIS functions for 3D support
assuming all GEOS functions should be 2D and to my shock they seemed
to do something with Z.
I'm pretty sure at the very least that ST_ConvexHull, ST_Union Z
support
is coming straight from GEOS. Haven't verified ST_Difference.
-Original Message-
From: geos-devel-boun...@lists.osgeo.org on behalf of Sean Gillies
Sent: Mon 1/12/2009 2:37 PM
To: GEOS Development List
Subject: Re: [geos-devel] C API coordinate sequence dimensions
Thanks, Regina, that hints that the supporting GEOS C API functions
might be considering z, but then again, the 3D might be implemented in
the PostGIS lib.
On Jan 12, 2009, at 12:18 PM, Obe, Regina wrote:
> A lot of these are catalogued here
>
> http://postgis.refractions.net/documentation/manual-svn/ch08.html#id2671967
>
> and
> ST_Union and I just discovered even ST_BuildArea.
>
> ST_ConvexHull (but that in my opinion gives goofy results).
>
>
> Though still debating how to describe that their results are
> debateable.
>
> Also ST_BuildArea seems to hmm do a 2D and then tack on the Z so I
> guess I should add that to the list. Simon tested this out when he
> was doing this write up and to my shock it sort of preserved 3D
> though I would say incorrectly. Any rate I don't think he has that
> here, but still an interesting read
>
> http://www.spatialdbadvisor.com/postgis_tips_tricks
>
>
>
>
>
>
>
>
> -Original Message-
> From: geos-devel-boun...@lists.osgeo.org on behalf of Sean Gillies
> Sent: Mon 1/12/2009 2:00 PM
> To: GEOS Development List
> Subject: Re: [geos-devel] C API coordinate sequence dimensions
>
> Ah, I didn't know this. Which ones?
>
> On Jan 12, 2009, at 11:40 AM, Paul Ramsey wrote:
>
> > Not all operations are 2D, just 99% of them. Some of the overlay
ops
> > try to compute "correct" derived Z-values.
> >
> > P
> >
> > On Jan 12, 2009, at 10:04 AM, Sean Gillies wrote:
> >
> >> So, the dimension argument in GEOSCoordSeq_create is ignored
unless
> >> the active sequence implementation takes dimensions other than 3?
> >>
> >> Why is GEOS's default sequence 3D when all operations are 2D?
> >>
> >> Sean
> >>
> >> On Jan 12, 2009, at 10:56 AM, Martin Davis wrote:
> >>
> >>> Actually JTS implements this correctly. The return value from
> >>> getDimension is computed by the implementation of
> >>> CoordinateSequence. In the case of DefaultCoordinateSequence
> >>> (which by the way is deprecated and replaced by
> >>> CoordinateArraySequence) the value is alway 3, since the
> >>> Coordinate representation used by these sequences always allows
> >>> for 3 ordinates.
> >>>
> >>> In the case of PackedCoordinateSequence the dimension can be
> >>> selected on creation, and this is the value that is returned by
> >>> getDimension.
> >>>
> >>> Sanak wrote:
> >>>> Hi list,
> >>>>
> >>>> I don't know that this is a known bug, but
> >>>> CoordinateArraySequence.getDimension() method always return 3.
> >>>>
> >>>> [trunk/source/headers/geos/geom/CoordinateArraySequence.h -
line
> >>>> 88]
> >>>> size_t getDimension() const { return 3; }
> >>>>
> >>>>
> >>>> JTS(JTS Topology Suite) seems to be also the same.
> >>>>
> >>>> [jts/src/com/vividsolutions/jts/geom/
> >>>> DefaultCoordinateSequence.java - line 95]
> >>>> public int getDimension() { return 3; }
> >>>>
> >>>> I don't know that this is a specification or not...
> >>>>
> >>>> Regards,
> >>>>
> >>>> Sanak.
> >>>>
> >>>> 2009/1/12 Sean Gillies >>>> <mailto:sgill...@frii.com>>
> >>>>
&
Re: [geos-devel] C API coordinate sequence dimensions
Thanks, Regina, that hints that the supporting GEOS C API functions
might be considering z, but then again, the 3D might be implemented in
the PostGIS lib.
On Jan 12, 2009, at 12:18 PM, Obe, Regina wrote:
A lot of these are catalogued here
http://postgis.refractions.net/documentation/manual-svn/ch08.html#id2671967
and
ST_Union and I just discovered even ST_BuildArea.
ST_ConvexHull (but that in my opinion gives goofy results).
Though still debating how to describe that their results are
debateable.
Also ST_BuildArea seems to hmm do a 2D and then tack on the Z so I
guess I should add that to the list. Simon tested this out when he
was doing this write up and to my shock it sort of preserved 3D
though I would say incorrectly. Any rate I don't think he has that
here, but still an interesting read
http://www.spatialdbadvisor.com/postgis_tips_tricks
-Original Message-
From: geos-devel-boun...@lists.osgeo.org on behalf of Sean Gillies
Sent: Mon 1/12/2009 2:00 PM
To: GEOS Development List
Subject: Re: [geos-devel] C API coordinate sequence dimensions
Ah, I didn't know this. Which ones?
On Jan 12, 2009, at 11:40 AM, Paul Ramsey wrote:
> Not all operations are 2D, just 99% of them. Some of the overlay ops
> try to compute "correct" derived Z-values.
>
> P
>
> On Jan 12, 2009, at 10:04 AM, Sean Gillies wrote:
>
>> So, the dimension argument in GEOSCoordSeq_create is ignored unless
>> the active sequence implementation takes dimensions other than 3?
>>
>> Why is GEOS's default sequence 3D when all operations are 2D?
>>
>> Sean
>>
>> On Jan 12, 2009, at 10:56 AM, Martin Davis wrote:
>>
>>> Actually JTS implements this correctly. The return value from
>>> getDimension is computed by the implementation of
>>> CoordinateSequence. In the case of DefaultCoordinateSequence
>>> (which by the way is deprecated and replaced by
>>> CoordinateArraySequence) the value is alway 3, since the
>>> Coordinate representation used by these sequences always allows
>>> for 3 ordinates.
>>>
>>> In the case of PackedCoordinateSequence the dimension can be
>>> selected on creation, and this is the value that is returned by
>>> getDimension.
>>>
>>> Sanak wrote:
>>>> Hi list,
>>>>
>>>> I don't know that this is a known bug, but
>>>> CoordinateArraySequence.getDimension() method always return 3.
>>>>
>>>> [trunk/source/headers/geos/geom/CoordinateArraySequence.h - line
>>>> 88]
>>>> size_t getDimension() const { return 3; }
>>>>
>>>>
>>>> JTS(JTS Topology Suite) seems to be also the same.
>>>>
>>>> [jts/src/com/vividsolutions/jts/geom/
>>>> DefaultCoordinateSequence.java - line 95]
>>>> public int getDimension() { return 3; }
>>>>
>>>> I don't know that this is a specification or not...
>>>>
>>>> Regards,
>>>>
>>>> Sanak.
>>>>
>>>> 2009/1/12 Sean Gillies >>> <mailto:sgill...@frii.com>>
>>>>
>>>> I'm finding that GEOSCoordSeq_getDimensions returns 3 no matter
>>>> what
>>>>
>>>> # Accessing libgeos_c via Python ctypes
>>>> >>> s = lgeos.GEOSCoordSeq_create(2, 2)
>>>> >>> ndim = c_int()
>>>> >>> lgeos.GEOSCoordSeq_getDimensions(s, byref(ndim))
>>>> 1
>>>> >>> ndim
>>>> c_long(3)
>>>>
>>>> Is this a known bug? Looks like we're only testing creation of
3D
>>>> coordinate sequences in
>>>>
>>>>
http://trac.osgeo.org/geos/browser/trunk/tests/unit/capi/GEOSCoordSeqTest.cpp
>>>>
>>>> --
>>>> Sean Gillies
>>>> http://sgillies.net
>>>>
>>>> ___
>>>> geos-devel mailing list
>>>> geos-devel@lists.osgeo.org <mailto: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
>>>
>>> --
>>> Martin Davis
>>> Senior Technical Architect
>>> Refractions Resea
Re: [geos-devel] C API coordinate sequence dimensions
Ah, I didn't know this. Which ones?
On Jan 12, 2009, at 11:40 AM, Paul Ramsey wrote:
Not all operations are 2D, just 99% of them. Some of the overlay ops
try to compute "correct" derived Z-values.
P
On Jan 12, 2009, at 10:04 AM, Sean Gillies wrote:
So, the dimension argument in GEOSCoordSeq_create is ignored unless
the active sequence implementation takes dimensions other than 3?
Why is GEOS's default sequence 3D when all operations are 2D?
Sean
On Jan 12, 2009, at 10:56 AM, Martin Davis wrote:
Actually JTS implements this correctly. The return value from
getDimension is computed by the implementation of
CoordinateSequence. In the case of DefaultCoordinateSequence
(which by the way is deprecated and replaced by
CoordinateArraySequence) the value is alway 3, since the
Coordinate representation used by these sequences always allows
for 3 ordinates.
In the case of PackedCoordinateSequence the dimension can be
selected on creation, and this is the value that is returned by
getDimension.
Sanak wrote:
Hi list,
I don't know that this is a known bug, but
CoordinateArraySequence.getDimension() method always return 3.
[trunk/source/headers/geos/geom/CoordinateArraySequence.h - line
88]
size_t getDimension() const { return 3; }
JTS(JTS Topology Suite) seems to be also the same.
[jts/src/com/vividsolutions/jts/geom/
DefaultCoordinateSequence.java - line 95]
public int getDimension() { return 3; }
I don't know that this is a specification or not...
Regards,
Sanak.
2009/1/12 Sean Gillies <mailto:sgill...@frii.com>>
I'm finding that GEOSCoordSeq_getDimensions returns 3 no matter
what
# Accessing libgeos_c via Python ctypes
>>> s = lgeos.GEOSCoordSeq_create(2, 2)
>>> ndim = c_int()
>>> lgeos.GEOSCoordSeq_getDimensions(s, byref(ndim))
1
>>> ndim
c_long(3)
Is this a known bug? Looks like we're only testing creation of 3D
coordinate sequences in
http://trac.osgeo.org/geos/browser/trunk/tests/unit/capi/GEOSCoordSeqTest.cpp
--
Sean Gillies
http://sgillies.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org <mailto: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
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Sean Gillies
sean.gill...@gmail.com
http://sgillies.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Paul Ramsey
pram...@cleverelephant.ca
+1 250 885 0632
___
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] C API coordinate sequence dimensions
So, the dimension argument in GEOSCoordSeq_create is ignored unless
the active sequence implementation takes dimensions other than 3?
Why is GEOS's default sequence 3D when all operations are 2D?
Sean
On Jan 12, 2009, at 10:56 AM, Martin Davis wrote:
Actually JTS implements this correctly. The return value from
getDimension is computed by the implementation of
CoordinateSequence. In the case of DefaultCoordinateSequence (which
by the way is deprecated and replaced by CoordinateArraySequence)
the value is alway 3, since the Coordinate representation used by
these sequences always allows for 3 ordinates.
In the case of PackedCoordinateSequence the dimension can be
selected on creation, and this is the value that is returned by
getDimension.
Sanak wrote:
Hi list,
I don't know that this is a known bug, but
CoordinateArraySequence.getDimension() method always return 3.
[trunk/source/headers/geos/geom/CoordinateArraySequence.h - line 88]
size_t getDimension() const { return 3; }
JTS(JTS Topology Suite) seems to be also the same.
[jts/src/com/vividsolutions/jts/geom/DefaultCoordinateSequence.java
- line 95]
public int getDimension() { return 3; }
I don't know that this is a specification or not...
Regards,
Sanak.
2009/1/12 Sean Gillies mailto:sgill...@frii.com>>
I'm finding that GEOSCoordSeq_getDimensions returns 3 no matter
what
# Accessing libgeos_c via Python ctypes
>>> s = lgeos.GEOSCoordSeq_create(2, 2)
>>> ndim = c_int()
>>> lgeos.GEOSCoordSeq_getDimensions(s, byref(ndim))
1
>>> ndim
c_long(3)
Is this a known bug? Looks like we're only testing creation of 3D
coordinate sequences in
http://trac.osgeo.org/geos/browser/trunk/tests/unit/capi/GEOSCoordSeqTest.cpp
--
Sean Gillies
http://sgillies.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org <mailto: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
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Sean Gillies
sean.gill...@gmail.com
http://sgillies.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] C API coordinate sequence dimensions
I'm finding that GEOSCoordSeq_getDimensions returns 3 no matter what # Accessing libgeos_c via Python ctypes >>> s = lgeos.GEOSCoordSeq_create(2, 2) >>> ndim = c_int() >>> lgeos.GEOSCoordSeq_getDimensions(s, byref(ndim)) 1 >>> ndim c_long(3) Is this a known bug? Looks like we're only testing creation of 3D coordinate sequences in http://trac.osgeo.org/geos/browser/trunk/tests/unit/capi/GEOSCoordSeqTest.cpp -- Sean Gillies http://sgillies.net ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Documenting prepared geometry
Hi all, There's insufficient information in our trac site (tickets or wiki pages) about prepared geometries. What's the scope of this work? Use cases? Tests? API? Can anyone point me to the essential reading? Thanks, Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.0.3 To Do
According to http://trac.osgeo.org/geos/log/branches/3.0/capi/geos_c.cpp The C API hasn't changed since the 3.0 branch was made, so a change of the API version number isn't warranted. Sean Paul Ramsey wrote: > I couldn't apply this patch cleanly, could someone else try? > > P. > > On Thu, Oct 23, 2008 at 10:52 AM, Sanak <[EMAIL PROTECTED]> wrote: >> Ok, I had added geostest project to msvc80 solution file. >> Please see the attach >> file(geos-branches-3.0-build-msvc80_add_geostest.patch). >> geostest.vcproj will generate capi/test.out. >> >> I think that the cause of difference between generated test.out and >> test.expected is precision of floating point, but I don't know details. >> >> And another Visual C++ specific problem may be capi >> version.(capi/geos_c.h.in) >> --- >> Index: geos_c.h.in >> === >> --- geos_c.h.in(revision 2208) >> +++ geos_c.h.in(working copy) >> @@ -51,9 +51,9 @@ >> #if defined(_MSC_VER) >> #include >> #define GEOS_CAPI_VERSION_MAJOR 1 >> -#define GEOS_CAPI_VERSION_MINOR 3 >> +#define GEOS_CAPI_VERSION_MINOR 4 >> #define GEOS_CAPI_VERSION_PATCH 3 >> -#define GEOS_CAPI_VERSION "3.0.0rc4-CAPI-1.3.3" >> +#define GEOS_CAPI_VERSION "3.0.3-CAPI-1.4.3" >> #else >> #define GEOS_VERSION_MAJOR @VERSION_MAJOR@ >> #define GEOS_VERSION_MINOR @VERSION_MINOR@ >> --- >> >> Regards, >> >> 2008/10/24 Frank Warmerdam <[EMAIL PROTECTED]> >>> Obe, Regina wrote: I know Frank already tested on Visual C++ Express (which is basically Visual 2008 Express) and got some test fail errors. Do we have a solution file for that (or would people just use the msvc80 solution file for that if they wanted to use a solution) . >>> ... Running regression tests using geos_unitd.exe... === GEOS Test Suite Application === capi::GEOSCoordSeq: . 5 capi::GEOSSimplify: . 1 >>> Folks, >>> >>> I would note that I wasn't running geos_unitd.exe, I ran geostest.exe >>> against capi/test.wkt and compared to capi/test.expected. If I get >>> back to my windows build I'll look into the geos_unitd.exe which I wasn't >>> aware of. >>> >>> Best regards, >>> -- >>> >>> ---+-- >>> I set the clouds in motion - turn up | Frank Warmerdam, >>> [EMAIL PROTECTED] >>> light and sound - activate the windows | http://pobox.com/~warmerdam >>> and watch the world go round - Rush| Geospatial Programmer for Rent >>> >>> ___ >>> 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 >> > ___ > 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] GEOS 3.0.2 fails to compile under MingW Win32
Paul Ramsey wrote: > On Mon, Oct 20, 2008 at 6:42 AM, Sean Gillies <[EMAIL PROTECTED]> wrote: >> Sorry about not seeing the problem on windows until now. I've backported >> and am testing locally (linux) and am game to commit the fix of #212 to >> the 3.0 branch. What do you think, Mateusz? > > Yeehaw, cowboy Paul says "commit that doggie", let's get a 3.0.2 out > the door to go with PostGIS 1.3.4 :) > > P Can anybody commit to testing the fix on windows? Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS 3.0.2 fails to compile under MingW Win32
Mark Cave-Ayland wrote: > On Sun, 2008-10-19 at 21:48 +0100, Mark Cave-Ayland wrote: > >> My current solution is the attached patch which works by replacing >> strdup() with a simple malloc() and strcpy() to preserve the old locale. >> Note that this will almost certainly need to be applied to the 3.1 >> branch too, although I haven't got as far as trying to compile it on >> Win32 - yet ;) > > And as if by magic: > http://trac.osgeo.org/geos/ticket/212 > > Cool. In that case, please can this be backported to the 3.0 branch? And > I think we also need to backport the gcc-4.3 fixes since Debian and SUSE > are now using gcc-4.3 by default (see > http://postgis.refractions.net/pipermail/postgis-devel/2008-October/003939.html > for the SUSE confirmation, and my local machine as of 2 hours ago is the > Debian Lenny confirmation). > > > ATB, > > Mark. Mark, Sorry about not seeing the problem on windows until now. I've backported and am testing locally (linux) and am game to commit the fix of #212 to the 3.0 branch. What do you think, Mateusz? Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Looking for a geometry engine
hunniger wrote: > Hello, > my name is Dirk, I studied physics, and work for a mechanical > engineering company. > In my free time I like to write software, and most of all I like Python. > We often model machines as two dimensional objects with nodes, some of > which are free, some of which are (partially) fixed that are connected > by lines. We model the movement of a machines by changing the length of > a line, cause some free nodes to move. Currently I am getting paid for > calculating these movements by hand. Since I don't like my work I would > like write a software to do it instead of me and publish it open source. > So is geos able to solve this kind of problems and would this be a good > point for me to start with? > Yours Dirk > > PS: I just want to give a short example of a problem I would like to solve. > > Let there be a point A at (0,0) , and let there be an other point B > (0,1) , there shall be a further point C, that has a distance of 1 from > A as well as from B. What are the coordinates of C. (Well Ok there are > two solutions). And what is the trajectory on which C moves if the > distance between A and C increases from 1 to 2. And all other distances > stay the same. > Sounds like what you need is matlab-ish software. GEOS is geared towards answering questions like "do landscape patches A and B intersect, and if so, what is their intersection patch(es)?" and isn't ideal for solving algebra problems. Cheers, Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Tabs versus spaces?
Howard Butler wrote: > > On Aug 29, 2008, at 10:42 AM, Mateusz Loskot wrote: > >> Sean Gillies wrote: >>> I'm finding a lot of tabs in the GEOS source -- is this our convention? >> >> Sean, >> >> AFAIR, Sandro preferred to use tabs. I've also found it inconvenient >> as I personally believe in spaces :-) >> >> Perhaps, if others will agree, we can migrate GEOS sources to spaces. >> Single big batch operation and commit should fix it. > > +10 :) > > Howard No, 10 is too much. 4 would be fine. Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Tabs versus spaces?
I'm finding a lot of tabs in the GEOS source -- is this our convention? Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Delocalizing the WKT writer?
Mateusz Loskot wrote:
> Sean Gillies wrote:
>> Mateusz Loskot wrote:
>>> Mateusz Loskot wrote:
>>>> I'm going to try to review and reafactor WKT classes to base on C++ I/O
>>> I've forgot to add, that I'd suggest to leave current solution, possibly
>>> fixed with CPLLocaleC class, until I bring better solution into
>>> WKTReader/WKTWriter.
>>>
>>> Best regards,
>>
>> Okay. I'll learn what I can from CPLLocaleC.
>
> Sean, thanks for fixing.
> It's simple to use CPLLocaleC class
>
> void foo() // function that is assumed to depend on C locale
> {
>CPLLocaleC loc; // set "C" locale
>
>// ... some operations that should be locale indenendent
>
>
> } // loc destructor resets locale back to original
>
Thanks, Mateusz. Here's my new and improved solution:
http://trac.osgeo.org/geos/changeset/2174
Sean
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Delocalizing the WKT writer?
Mateusz Loskot wrote: > Mateusz Loskot wrote: >> I'm going to try to review and reafactor WKT classes to base on C++ I/O > > I've forgot to add, that I'd suggest to leave current solution, possibly > fixed with CPLLocaleC class, until I bring better solution into > WKTReader/WKTWriter. > > Best regards, Okay. I'll learn what I can from CPLLocaleC. Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Delocalizing the WKT writer?
Yep, works. Any objections to the changes?
http://trac.osgeo.org/geos/changeset/2172
Would anyone like to see me use a macro instead?
Sean
Chris Hodgson wrote:
> Oh, now I understand - by "bracing the guts" you meant wrapping it with
> those calls - I thought you meant commenting out those calls. With
> Frank's suggested changes I expect your solution will do the job.
>
> Chris
>
> [EMAIL PROTECTED] wrote:
>> Chris,
>>
>> The calls below were added for illustration, they are not in the source
>> trunk. Sorry about the confusion. I haven't found any other calls to
>> setlocale.
>>
>> Sean
>>
>>
>>> I'm no locale expert, but it looks to me like that is the code that IS
>>> de-localizing, setting to using the C locale instead of whatever the
>>> locale is set to in the system? Are there other setlocale calls in the
>>> writer code itself that undermine this?
>>>
>>> Chris
>>>
>>> [EMAIL PROTECTED] wrote:
>>>
Can one of the C++ gurus explain why delocalizing the writer (to fix
bug
201) isn't as simple as bracing the guts of this function with calls to
setlocale()?
capi/geos_c.cpp:
char*
GEOSWKTWriter_write(WKTWriter *writer, const Geometry *geom)
{
try
{
// switch to C locale
std::setlocale(LC_ALL, "C");
std::string s = writer->write(geom);
char *result;
result = (char*) std::malloc( s.length() + 1);
std::strcpy(result, s.c_str() );
// switch back to native locale
std::setlocale(LC_ALL, "");
return result;
}
catch (const std::exception &e)
{
ERROR_MESSAGE("%s", e.what());
return NULL;
}
catch (...)
{
ERROR_MESSAGE("Unknown exception thrown");
return NULL;
}
}
Sure, it would be nice to work this down into the C++ code, but the
WKTWriter class is a nightmare.
Sean
___
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
>>>
>>>
>>
>>
>> ___
>> 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
>
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Re: GEOS Incubation
Frank Warmerdam wrote: > Paul Ramsey wrote: >> Frank, >> >> Could you review the status at >> >> http://wiki.osgeo.org/wiki/GEOS_Incubation_Status >> >> and let me know how you think we're doing? > > Paul, > > I have reviewed the documents and I think they look great. Did we > get all the existing authorized commiters to agree to the terms of > RFC 2? I don't recall. It might be worth noting in the last item of > the incubation status. > > I am happy with the Provenance Review, and don't see further action > needed in that regard. > > I have two outstanding issues with regard to GEOS before I'd be very > comfortable recommending it for graduation. > > 1) I'd like to see the PSC making some decisions (RFCs, approving releases, > etc) to demonstrate that the PSC is operating effectively. > > 2) I'd like to see some active contribution from several parties. I feel > like the activity level is quite low on GEOS. This might be partly that it > is satisfactory already, or that no one has a pressing need just now, but > it leaves me uncertain about the project. For instance I recall there were > issues in the past raised by Safe, and the MapGuide folks about GEOS. > I'd love > to see them re-raising those issues - hammer out a consensus via the > PSC/RFC > process, and then implementing changes that get out as a release. > +1. Let's see the stakeholders become more active -- "stake wielders", even. > It is my opinion that there is no harm in us sitting in incubation for a > while > till we can demonstrate more of the above. I hope you are ok with this > since > my concerns are rather subjective. > > Best regards, The question of whether GEOS remains slaved to JTS or not seems to be something that might be resolved before graduation? Cheers, Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] [Agreement] GEOS RFC 2: Committer Guidelines
I have read, understand, and agree to follow the terms of this document. Paul Ramsey wrote: > I also read, understand and will follow RFC2. > > The following people need to affirm the same: > >* pramsey - Paul Ramsey (124, 2007-12-21) > * mbdavis - Martin Davis (1, 2003-02-11) > * hobu - Howard Butler (17, 2006-11-10) > * mloskot - Mateusz Loskot (136, 2008-08-01) > * csavage - Charlie Savage (102, 2007-09-21) > * frank, warmerdam - Frank Warmerdam (27, 2008-07-19) > * sgillies - Sean Gillies (10, 2008-01-02) > * benjubb - Ben Jubb (38, 2008-01-30) > > On Sat, Aug 9, 2008 at 8:40 AM, Mateusz Loskot <[EMAIL PROTECTED]> wrote: >> Dear PSC and GEOS Community, >> >> I'd like to give my agreement on the Committer Guidelines described >> in the GEOS RFC 2 document available at >> >> http://trac.osgeo.org/geos/wiki/RFC2 >> >> I have read, understand, and agree to follow the terms of this document. >> >> >> Best regards >> -- >> Mateusz Loskot, http://mateusz.loskot.net >> Charter Member of OSGeo, http://osgeo.org >> ___ >> 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 > ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Binary predicate shortcuts
Thanks, Martin. I wanted to check that I wasn't duplicating. Martin Davis wrote: > Neither GEOS nor JTS checks for identical geometries as input to the > predicates. > > What's your use case for this? At first glance it doesn't seem like it > would be a major source of performance loss. > > You could always check for this in your wrapper.. 8^) > > Sean Gillies wrote: >> Could GEOS not return known results immediately when evaluating binary >> predicates where both geometries are the same (same address in memory)? >> If this is already done, it's buried deeper in the code than I've >> looked, or I've completely missed it. >> >> Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Binary predicate shortcuts
Could GEOS not return known results immediately when evaluating binary predicates where both geometries are the same (same address in memory)? If this is already done, it's buried deeper in the code than I've looked, or I've completely missed it. Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] RFC 2 for GEOS
Paul Ramsey wrote: > For your delectation, a draft of RFC2. We will hold off on voting on > it until we approve RFC1, for obvious reasons :) > > http://trac.osgeo.org/geos/wiki/RFC2 > > Please add any edits you wish or comment on the list. > > Paul Paul, "#1232" works better with Trac than "bug 1232". Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.0.1
Frank Warmerdam wrote: > Folks, > > I have taken the liberty of closing the 3.0.0 milestone and pushing the > open tickets to the 3.0.1 milestone: > > http://trac.osgeo.org/geos/query?status=new&status=assigned&status=reopened&milestone=3.0.1 > > > I have fixed up the nmake related packaging issues. I've also fixed up > trunk > so packaged distributions work (I hate having to list every file in the > Makefile.am's!). > > I have prepared a quickly 3.0.1 alpha for folks to test. I'll leave a more > official RC to Paul. > > http://home.gdal.org/tmp/geos-3.0.1a1.tar.gz > > Best regards, Works for me. Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] SVN Snapshots out of date
Frank Warmerdam wrote: > Folks, > > The SVN snaphots pointed to by the web site are not being updated. Last > one > was from December. > > I have filed a ticket at: > > http://trac.osgeo.org/geos/ticket/174 > > I would be prepared to setup snapshot generation on download.osgeo.org (as > we do for GDAL, MapServer, etc) using a cron job if Paul isn't too keen to > fix this up on his server. I'd also be interested in cloning the geos > releases on download.osgeo.org if no one has an objection. > > --- > > Are we thinking of a GEOS 3.0.1 release? If so, I'll fix up the win32 > makefile.vc builds in the 3.0 branch. I had to hack them together for > OSGeo4W and the updated tar file of source with modified makefiles is at: > > http://download.osgeo.org/osgeo4w/release/geos/geos-3.0.0-1.tar.bz2 > > Best regards, I'm +1 on 3.0.1. Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Odd problem on Vista
I'm using Python's ctypes and libffi to access functions in GEOS. GEOSGeomToWKT and GEOSGeomToWKB_buf each allocate memory that must be freed by the caller. This has been no problem for me on Linux or Windows 2000, I simply free the memory with libc.free or msvcrt.free. There seems to be an authorization problem on Vista with the result that msvcrt.free cannot access the memory allocated by geos.dll. This is the DLL I got from Artem the other day. I'm thinking that the solution is for GEOS to export its own free function ala msFree in MapServer, yes? Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Makefile.vc Updates
Frank Warmerdam wrote: > Folks, > > I have updated source/Makefile.vc to include a bunch of the new classes > so it seems to properly create the DLLs (r2107). > > I have also observed that the distinction between geos.dll and > geos_c.dll as built by the Makefile.vc is essentially a fraud. It > appears we make no effort to declare GEOS C++ classes in a way that allows > the C++ API to be exported from DLLs, so geos.dll is really just the same > as geos_c.dll (only C API exported) with the exception that a bunch of > extra C++ classes are included that have no access via the C API. > > I have not changed this yet, but I assuming we don't want to declare the > C++ classes in a way that they can be exported from DLLs, I'll just strip > down the Makefile.vc to only generate geos.dll. > > Best regards, Thanks for looking into it, Frank. I guess my Shapely installer no longer needs to be the Number of the Beast in kb. Eddie the Head will be disappointed. Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS 3 DLLs?
Artem, Thanks, man! My Vista user confirms that it works. Cheers, Sean Artem Pavlenko wrote: > > On 14 Jan 2008, at 17:02, Charlie Savage wrote: > >>> Could it be a missing manifest? >> >> That is almost always the issue I run into. VC 2005 will embed the >> manifest for you, but I'm not sure if the Express versions do and >> nmake definitely does not. >> >> To fix, use the mt command link tool to embed the manifest: >> >> http://msdn2.microsoft.com/en-us/library/ms235591.aspx > > I found this one, too: > http://msdn2.microsoft.com/en-us/library/ms235591(VS.80).aspx > > OK, I embedded manifests into geos.dll and geos_c.dll, could you try ? > > http://artem.dev.openstreetmap.org/files/geos_c.dll > http://artem.dev.openstreetmap.org/files/geos.dll > > Joy of windows dev :) > > Artem > >> >> Charlie >> ___ >> 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 > ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS 3 DLLs?
Artem, My user is unable to load these DLLs on a new Vista system. --- Microsoft Visual C++ Runtime Library --- Runtime Error! Program: C:\Python25\python.exe R6034 An application has made an attempt to load the C runtime library incorrectly. Please contact the application's support team for more information. --- OK --- Could it be a missing manifest? Sean Artem Pavlenko wrote: > Hi Sean, > > You can get geos 3 dlls (+libs) from : > http://artem.dev.openstreetmap.org/files/geos_3.zip > Or you can always build them yourself using VC++ express (free as in beer): > > nmake /f Makefile.vc > > HTH > Cheers > Artem > On 12 Jan 2008, at 21:07, Sean Gillies wrote: > >> Can anyone share GEOS 3 DLLs (including the C API) with me? I tried to >> get them out of the PostGIS 1.3.2 installer, but that appeared to >> require installing Postgres and I'm unwilling to do that. >> >> Thanks, >> Sean >> ___ >> 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 > ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Windows installer for the Shapely Python GEOS package
Hi all, I've included Artem's DLLs in an installer for Shapely: http://gispython.org/downloads/gispy/Shapely-1.0rc1.win32.exe Shapely, the project for which I abandoned the GEOS SWIG bindings, also has a new manual: http://gispython.org/shapely/manual.html Cheers, Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS 3 DLLs?
Thanks, Artem. Once I got the redistributable package with msvcp80.dll it worked fine. That is standard on XP, yes? Charlie, Mark: thanks too. Sean Artem Pavlenko wrote: > Hi Sean, > > You can get geos 3 dlls (+libs) from : > http://artem.dev.openstreetmap.org/files/geos_3.zip > Or you can always build them yourself using VC++ express (free as in beer): > > nmake /f Makefile.vc > > HTH > Cheers > Artem > On 12 Jan 2008, at 21:07, Sean Gillies wrote: > >> Can anyone share GEOS 3 DLLs (including the C API) with me? I tried to >> get them out of the PostGIS 1.3.2 installer, but that appeared to >> require installing Postgres and I'm unwilling to do that. >> >> Thanks, >> Sean >> ___ >> 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 > ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] GEOS 3 DLLs?
Can anyone share GEOS 3 DLLs (including the C API) with me? I tried to get them out of the PostGIS 1.3.2 installer, but that appeared to require installing Postgres and I'm unwilling to do that. Thanks, Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Problem with building 3.0.0rc
Sean Gillies wrote: > Mark Cave-Ayland wrote: >> On Fri, 2007-12-28 at 11:45 -0700, Sean Gillies wrote: >> >>>>> The mkinstalldirs script appears to be buggy on this particular >>>>> platform. One shift too many. Strangely, the 3.0rc builds fine on >>>>> another Ubuntu 6.10 i686 of mine. Same bash version even. >>>>> >>>>> I suppose I could try to fix mkinstalldirs, but it seems like it should >>>>> be simpler and more foolproof for the build to ignore swig/python >>>>> alltogether unless it is explicitly enabled. >>>> It would be good to know what is going wrong. Strk and I did (and Mark >>>> a bit) did spend some time trying to make sure this works, and it seems >>>> like you've found some bug in the code or our logic. >>>> >>>> Charlie >>> I'd like to implement the solution at >>> >>> http://www.gnu.org/software/automake/manual/html_node/Conditional-Subdirectories.html >>> >>> It appears trivial. Was there really a 3.0 final made on the 21st as >>> appears in the downloads directory? If not, I'd really like to make this >>> fix ASAP. >>> >>> Sean >> >> Hi Sean, >> >> Having looked at Makefile.am in the SWIG directory, the mkinstalldir >> target appears to be generated automatically by autotools. So while I >> don't object to applying a conditional subdirectory fix, the fact that >> it works on another box of yours with the same configuration means that >> there is something else somewhere on your box which is causing the build >> to fail. In other words, applying a patch for this is just masquerading >> another problem on the box in question. >> >> (FWIW it builds fine here on 32-bit Ubuntu 6.06) >> >> >> Kind regards, >> >> Mark. >> > > Maybe it does in this case, but making the builds conditional also heads > off any number of future problems of this sort. If you look in > swig/python/Makefile.am, you'll see that conditional building has > already been implemented, but in a less robust fashion. > > Cheers, > Sean It was trivial. See the patch on http://trac.osgeo.org/geos/ticket/168. Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Problem with building 3.0.0rc
Mark Cave-Ayland wrote: > On Fri, 2007-12-28 at 11:45 -0700, Sean Gillies wrote: > >>>> The mkinstalldirs script appears to be buggy on this particular >>>> platform. One shift too many. Strangely, the 3.0rc builds fine on >>>> another Ubuntu 6.10 i686 of mine. Same bash version even. >>>> >>>> I suppose I could try to fix mkinstalldirs, but it seems like it should >>>> be simpler and more foolproof for the build to ignore swig/python >>>> alltogether unless it is explicitly enabled. >>> It would be good to know what is going wrong. Strk and I did (and Mark >>> a bit) did spend some time trying to make sure this works, and it seems >>> like you've found some bug in the code or our logic. >>> >>> Charlie >> I'd like to implement the solution at >> >> http://www.gnu.org/software/automake/manual/html_node/Conditional-Subdirectories.html >> >> It appears trivial. Was there really a 3.0 final made on the 21st as >> appears in the downloads directory? If not, I'd really like to make this >> fix ASAP. >> >> Sean > > > Hi Sean, > > Having looked at Makefile.am in the SWIG directory, the mkinstalldir > target appears to be generated automatically by autotools. So while I > don't object to applying a conditional subdirectory fix, the fact that > it works on another box of yours with the same configuration means that > there is something else somewhere on your box which is causing the build > to fail. In other words, applying a patch for this is just masquerading > another problem on the box in question. > > (FWIW it builds fine here on 32-bit Ubuntu 6.06) > > > Kind regards, > > Mark. > Maybe it does in this case, but making the builds conditional also heads off any number of future problems of this sort. If you look in swig/python/Makefile.am, you'll see that conditional building has already been implemented, but in a less robust fashion. Cheers, Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Problem with building 3.0.0rc
Charlie Savage wrote: > > >> Same here. >> >> The mkinstalldirs script appears to be buggy on this particular >> platform. One shift too many. Strangely, the 3.0rc builds fine on >> another Ubuntu 6.10 i686 of mine. Same bash version even. >> >> I suppose I could try to fix mkinstalldirs, but it seems like it should >> be simpler and more foolproof for the build to ignore swig/python >> alltogether unless it is explicitly enabled. > > It would be good to know what is going wrong. Strk and I did (and Mark > a bit) did spend some time trying to make sure this works, and it seems > like you've found some bug in the code or our logic. > > Charlie I'd like to implement the solution at http://www.gnu.org/software/automake/manual/html_node/Conditional-Subdirectories.html It appears trivial. Was there really a 3.0 final made on the 21st as appears in the downloads directory? If not, I'd really like to make this fix ASAP. Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Problem with building 3.0.0rc
John Cartwright wrote: > The release version > (http://geos.refractions.net/downloads/geos-3.0.0.tar.bz2) seems to work > OK for me w/o the python SWIG bindings. My system is 64bit RHEL 5. > It was released? Did I miss something? > By the way what is the status of the python bindings at 3.0? I couldn't > get them to compile and recall that they were not actively maintained. > Can someone confirm? > > Thanks! > > --john > I don't know what the status is. Sean > > Sean Gillies wrote: >> I'm encountering a problem with the 3.0 release candidate that blocks a >> build on my Ubuntu 6.10 i686. >> >> "configure --prefix=/tmp; make; make install" bails out here: >> >> ... >> Making install in swig >> make[1]: Entering directory `/tmp/geos-3.0.0rc5/swig' >> Making install in python >> make[2]: Entering directory `/tmp/geos-3.0.0rc5/swig/python' >> Making install in tests >> make[3]: Entering directory `/tmp/geos-3.0.0rc5/swig/python/tests' >> make[4]: Entering directory `/tmp/geos-3.0.0rc5/swig/python/tests' >> make[4]: Nothing to be done for `install-exec-am'. >> make[4]: Nothing to be done for `install-data-am'. >> make[4]: Leaving directory `/tmp/geos-3.0.0rc5/swig/python/tests' >> make[3]: Leaving directory `/tmp/geos-3.0.0rc5/swig/python/tests' >> make[3]: Entering directory `/tmp/geos-3.0.0rc5/swig/python' >> make[4]: Entering directory `/tmp/geos-3.0.0rc5/swig/python' >> /bin/bash ../../mkinstalldirs >> /bin/bash ../../mkinstalldirs >> shift: 49: can't shift that many >> make[4]: *** [install-pkgpythonPYTHON] Error 2 >> make[4]: Leaving directory `/tmp/geos-3.0.0rc5/swig/python' >> make[3]: *** [install-am] Error 2 >> make[3]: Leaving directory `/tmp/geos-3.0.0rc5/swig/python' >> make[2]: *** [install-recursive] Error 1 >> make[2]: Leaving directory `/tmp/geos-3.0.0rc5/swig/python' >> make[1]: *** [install-recursive] Error 1 >> make[1]: Leaving directory `/tmp/geos-3.0.0rc5/swig' >> make: *** [install-recursive] Error 1 >> >> I don't understand why the install-pkgpythonPYTHON target is attempted >> when I haven't enabled the swig python bindings. Any idea what's up here? >> >> Sean >> ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Problem with building 3.0.0rc
Same here. The mkinstalldirs script appears to be buggy on this particular platform. One shift too many. Strangely, the 3.0rc builds fine on another Ubuntu 6.10 i686 of mine. Same bash version even. I suppose I could try to fix mkinstalldirs, but it seems like it should be simpler and more foolproof for the build to ignore swig/python alltogether unless it is explicitly enabled. Sean Paul Ramsey wrote: > The tail of my ./configure looks like this, what does yours look like? > > config.status: creating swig/geos.i > config.status: creating swig/Makefile > config.status: creating swig/python/Makefile > config.status: creating swig/python/tests/Makefile > config.status: creating swig/ruby/Makefile > config.status: creating swig/ruby/test/Makefile > config.status: creating tests/Makefile > config.status: creating tests/bigtest/Makefile > config.status: creating tests/unit/Makefile > config.status: creating tests/tut/Makefile > config.status: creating tests/xmltester/Makefile > config.status: creating tools/Makefile > config.status: creating tools/geos-config > config.status: creating source/headers/config.h > config.status: source/headers/config.h is unchanged > config.status: creating source/headers/geos/platform.h > config.status: source/headers/geos/platform.h is unchanged > config.status: executing depfiles commands > Swig: false > Python: false > Ruby: false > > > On Dec 28, 2007, at 7:44 AM, Sean Gillies wrote: > >> Charlie Savage wrote: >>> >>> >>> Sean Gillies wrote: >>>> I'm encountering a problem with the 3.0 release candidate that blocks a >>>> build on my Ubuntu 6.10 i686. >>>> >>>> "configure --prefix=/tmp; make; make install" bails out here: >>>> >>>> I don't understand why the install-pkgpythonPYTHON target is attempted >>>> when I haven't enabled the swig python bindings. Any idea what's up >>>> here? >>> >>> Thinking about this more, I think the way this was setup is to run SWIG >>> if the bindings file (*.cxx) is older than any changes to the SWIG >>> interface files (*.i). >>> >>> That should not be the case unless you've modified the interface files, >>> or they've somehow been modified in SVN since the generation of the >>> *.cxx files. >>> >>> Charlie >>> >> >> I wonder then if I'm experiencing an unintended side effect. I've not >> enabled swig python or ruby and swig is not run to produce wrappers >> (good), but the machine still steps into swig/python/Makefile and >> executes targets therein, even attempting to byte compile nonexistant >> modules. >> >> IMO, unless swig/python is explicitly enabled, make should skip that >> branch of the tree. Or am I overlooking something? >> >> Sean >> ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Problem with building 3.0.0rc
Charlie Savage wrote: > > > Sean Gillies wrote: >> I'm encountering a problem with the 3.0 release candidate that blocks a >> build on my Ubuntu 6.10 i686. >> >> "configure --prefix=/tmp; make; make install" bails out here: >> >> I don't understand why the install-pkgpythonPYTHON target is attempted >> when I haven't enabled the swig python bindings. Any idea what's up here? > > Thinking about this more, I think the way this was setup is to run SWIG > if the bindings file (*.cxx) is older than any changes to the SWIG > interface files (*.i). > > That should not be the case unless you've modified the interface files, > or they've somehow been modified in SVN since the generation of the > *.cxx files. > > Charlie > I wonder then if I'm experiencing an unintended side effect. I've not enabled swig python or ruby and swig is not run to produce wrappers (good), but the machine still steps into swig/python/Makefile and executes targets therein, even attempting to byte compile nonexistant modules. IMO, unless swig/python is explicitly enabled, make should skip that branch of the tree. Or am I overlooking something? Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Problem with building 3.0.0rc
I'm encountering a problem with the 3.0 release candidate that blocks a build on my Ubuntu 6.10 i686. "configure --prefix=/tmp; make; make install" bails out here: ... Making install in swig make[1]: Entering directory `/tmp/geos-3.0.0rc5/swig' Making install in python make[2]: Entering directory `/tmp/geos-3.0.0rc5/swig/python' Making install in tests make[3]: Entering directory `/tmp/geos-3.0.0rc5/swig/python/tests' make[4]: Entering directory `/tmp/geos-3.0.0rc5/swig/python/tests' make[4]: Nothing to be done for `install-exec-am'. make[4]: Nothing to be done for `install-data-am'. make[4]: Leaving directory `/tmp/geos-3.0.0rc5/swig/python/tests' make[3]: Leaving directory `/tmp/geos-3.0.0rc5/swig/python/tests' make[3]: Entering directory `/tmp/geos-3.0.0rc5/swig/python' make[4]: Entering directory `/tmp/geos-3.0.0rc5/swig/python' /bin/bash ../../mkinstalldirs /bin/bash ../../mkinstalldirs shift: 49: can't shift that many make[4]: *** [install-pkgpythonPYTHON] Error 2 make[4]: Leaving directory `/tmp/geos-3.0.0rc5/swig/python' make[3]: *** [install-am] Error 2 make[3]: Leaving directory `/tmp/geos-3.0.0rc5/swig/python' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/tmp/geos-3.0.0rc5/swig/python' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/tmp/geos-3.0.0rc5/swig' make: *** [install-recursive] Error 1 I don't understand why the install-pkgpythonPYTHON target is attempted when I haven't enabled the swig python bindings. Any idea what's up here? Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Nightly/Hourly distros
Thanks. Paul Ramsey wrote: > geos.refractions.net/downloads > > On 18-Dec-07, at 9:36 AM, Sean Gillies wrote: > >> Paul, could you put the snapshot in a directory that we could browse >> into? That way we could check the timestamp to be sure things are >> working. >> >> Sean >> >> Paul Ramsey wrote: >>> Should be better now Howard. >>> >>> On 18-Dec-07, at 8:39 AM, Howard Butler wrote: >>> >>>> It appears that the nightly distro isn't being built against the new >>>> subversion server. I attempted to fetch it this morning looking for >>>> Mateusz's updates for OS X, but they hadn't been applied in >>>> http://geos.refractions.net/geos-svn.tar.bz2 >>>> >>>> Can someone look into this? >>>> >>>> Thanks, >>>> >>>> Howard ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Nightly/Hourly distros
Paul, could you put the snapshot in a directory that we could browse into? That way we could check the timestamp to be sure things are working. Sean Paul Ramsey wrote: > Should be better now Howard. > > On 18-Dec-07, at 8:39 AM, Howard Butler wrote: > >> It appears that the nightly distro isn't being built against the new >> subversion server. I attempted to fetch it this morning looking for >> Mateusz's updates for OS X, but they hadn't been applied in >> http://geos.refractions.net/geos-svn.tar.bz2 >> >> Can someone look into this? >> >> Thanks, >> >> Howard >> ___ >> 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 > ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] geos.refractions.net down again?
Jean-Claude Repetto wrote: > Sean Gillies a écrit : >> Does anybody have an original 2.2.3 release tarball handy? > > http://distfiles.gentoo.org/distfiles/geos-2.2.3.tar.bz2 Merci, Jean-Claude. Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] geos.refractions.net down again?
Does anybody have an original 2.2.3 release tarball handy? Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] geos.refractions.net offline?
Thanks, Paul. Super script flies again. I hope it was just a small glitch. Sean Paul Ramsey wrote: > Not just you, and not a problem anymore. > P > > On 17-Dec-07, at 9:33 AM, Sean Gillies wrote: > >> Yes, but my super-duper application deployment script points at the >> release tarball on the geos.refractions.net site. >> >> Benjamin Chartier wrote: >>> http://trac.osgeo.org/geos/ >>> >>> Benjamin Chartier >>> >>> >>> Sean Gillies a écrit : >>>> Or is it just me? >>>> >>>> Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] geos.refractions.net offline?
Yes, but my super-duper application deployment script points at the release tarball on the geos.refractions.net site. Benjamin Chartier wrote: > http://trac.osgeo.org/geos/ > > Benjamin Chartier > > > Sean Gillies a écrit : >> Or is it just me? >> >> Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] geos.refractions.net offline?
Or is it just me? Sean ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
