gt; PACKAGE = "rgeos")
> 2: gPolygonize(LS)
> Error in gPolygonize(LS) : caught access violation - continue with care
>
> I hope you can help me
> Kindest regards
>
> Paolo
>
> ___
> geos-devel mailing li
rgeos 0.2-13 is now submitted to CRAN, should be built as a Windows binary
shortly, probably also for your R 2.14.
Roger
-
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/troubles-with-gPolygonize
AN, should be built as a Windows binary
> shortly, probably also for your R 2.14.
>
> Roger
>
>
>
> -
> Roger Bivand
> NHH Norwegian School of Economics, Bergen, Norway
> --
> View this message in context:
> http://osgeo-org.1560.n
n the CAPI?
I'd like to add noding to rgeos, a user has occasional incoming polygon
geometries that are not valid, and whose creation he does not control, and
needs to node them after coercion to line strings, before going back out
through polygonize.
Grateful for any ideas,
Roger
--
Ro
d 100
random segments shows no issues, with the noded output feeding through to
polygonizing without obvious failures.
Roger
Roger Bivand wrote
> I'd like to ask for pointers to example code using GEOSNode/GEOSNode_r in
> CAPI. What should the geometry g be - GEOS_MULTILINESTRING,
>
"red",add=TRUE)
writeWKT(MyLay)
writeWKT(MyLayl)
There is a report on the thread of PostGIS not showing the issue, but we
are checking that the same input data are being used.
Grateful for any input correcting my misunderstanding ...
Roger
--
Roger Bivand
Department of Economics, No
of "philae" is unknown and untraceable - please contact me
directly including the test script, which wasn't attached to the ticket.
A minor leakage of 40 bytes isn't a big deal, and its origin isn't clear.
Roger
--
Roger Bivand
Department of Economics, Norwegian School
ce for all contributed R packages
(almost 8000) is to email the maintainer, whose email is in the package,
and on the archive network package page.
packageDescription("rgeos")$Maintainer
[1] "Roger Bivand "
This is typically what happens, but in the R-spatial community, it is
e
ality
doesn't mean that you can force everybody else's schedules, does it?
For sf and rgeos R package developers with very many users.
Roger Bivand
-----
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GEOS-Developer
e not yet found the custom error handler - we still need the message.
Roger
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no
http://orcid.org/-0003-2392-6140
https://scholar.goog
ature which will be normalised for 3.9.0?
So far I don't think that there are obvious failures in R packages related
to the new code (again assuming that a straight build of master of 8
November exercises Overlay_NG), but the unexpected output was surprising.
Best wishes,
Roger
--
Ro
On Tue, 13 Oct 2020, Paul Ramsey wrote:
On Oct 13, 2020, at 11:08 AM, Roger Bivand wrote:
I've been checking the possible fallout from Overlay_NG (assuming that
building from master on 8 October uses the new code) in some R
packages, in particular sf and rgeos. I see messages su
23 AM, Roger Bivand wrote:
On Tue, 13 Oct 2020, Paul Ramsey wrote:
On Oct 13, 2020, at 11:08 AM, Roger Bivand wrote:
I've been checking the possible fallout from Overlay_NG (assuming that building
from master on 8 October uses the new code) in some R packages, in particular
sf and rg
erlay-NG or not will relieve
the pressure.
Anyway, the failure count is very low, a half-dozen from hundreds is fine
(and if they didn't write tests, that isn't our problem...).
Roger
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045
suddenly have
everything break on ordinary testing).
Does that make sense?
P
On Oct 15, 2020, at 8:59 AM, Roger Bivand wrote:
Can I ask whether there is, or could be, a function exposed in the C_API, or
a header variable say in geoc_c.h, showing whether the running GEOS is
using Overlay-NG or no
t suddenly have everything break on ordinary
testing).
Does that make sense?
Yes, it does, thank you.
Best wishes,
Roger
P
On Oct 15, 2020, at 8:59 AM, Roger Bivand wrote:
Can I ask whether there is, or could be, a function exposed in the C_API, or a
header variable say in geoc_c.h,
On Thu, 15 Oct 2020, Sandro Santilli wrote:
On Thu, Oct 15, 2020 at 05:59:39PM +0200, Roger Bivand wrote:
Can I ask whether there is, or could be, a function exposed in the
C_API, or a header variable say in geoc_c.h, showing whether the
running GEOS is using Overlay-NG or not?
There are
I apologise for brevity, this blog shows some current thinking:
https://developer.r-project.org/Blog/public/2020/05/29/testing-r-on-emulated-platforms/index.html
Roger
---
Roger Bivand
Department of Economics
Norwegian School of Economics
Bergen, Norway
roger.biv...@nhh.no
be
used >= "3.9.0", we are choosing to advise package maintainers to add a
condition to their tests to add the new >= "3.9.0" WKT when GEOS >=
"3.9.0". Not ideal, but we can return to normalization later if this isn't
enough.
Best wishes,
Ro
On Thu, 15 Oct 2020, Martin Davis wrote:
On Thu, Oct 15, 2020 at 9:00 AM Roger Bivand wrote:
Anyway, the failure count is very low, a half-dozen from hundreds is fine
(and if they didn't write tests, that isn't our problem...).
What would be especially interesting is to s
On Fri, 16 Oct 2020, Martin Davis wrote:
On Fri, Oct 16, 2020 at 11:59 AM Roger Bivand wrote:
Cases 794 and 936 are all-by-all intersections, and as noted in the latter
issue, the problems occurring differ by input order.
Well, that's disappointing that 794 and 936 still have fai
clear way to interrogate the runtime to find out whether it supports
OverlayNG.
Next question - why no RC, is it fair to just go from beta to release?
Best wishes,
Roger
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95
Thu, 10 Dec 2020, Roger Bivand wrote:
Hi,
Please confirm that the 3.9.0 release will as advertised enable OverlayNG by
default. As lately as beta2 configure still seemed to need
--enable-overlayng. Ad-hoc tests from late October to detect ring order fail
without --enable-overlayng. I repeat that
ion is going to fail. I can ensure there is
configure-time output on the status, but that's really about as far as
I'm willing to go.
P
On Dec 10, 2020, at 12:56 AM, Roger Bivand wrote:
Even with --enable-overlayng, the ring orders are different from those
generated by
ch is much lower, and we can just leave the #define
in place and manually flip it if, for some reason, we want to test old
behaviour.
Thoughts?
P
On Dec 10, 2020, at 8:46 AM, Roger Bivand wrote:
Thanks for responding. The motivation is that users of R (and others)
packages, using R pack
o re-check
development versions if I can locate them.
Roger
P
On Dec 10, 2020, at 11:12 AM, Roger Bivand wrote:
Again, from the point of view of communities like R, this would simplify things a
lot. We could then say that unless the questioner (or the person the questioner is
asking for) has
Overnight checks on R packages show no new problems - package maintainers
were warned of failing tests as soon as OverlayNG was available for
testing.
Roger
On Thu, 10 Dec 2020, Roger Bivand wrote:
On Thu, 10 Dec 2020, Paul Ramsey wrote:
This is done. There will be an rc1 shortly.
Good
ases 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
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway
On Fri, 8 Jan 2021, Paul Ramsey wrote:
On Jan 8, 2021, at 11:25 AM, 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'
On Sun, 10 Jan 2021, Sean Gillies wrote:
Hi Roger and all,
On Fri, Jan 8, 2021 at 12:25 PM Roger Bivand wrote:
...
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
On Tue, 12 Jan 2021, Paul Ramsey wrote:
On Jan 11, 2021, at 1:09 AM, Roger Bivand wrote:
Cmake proponents: apart from the reservations raised by packagers, why for me
does rm -rf _build not lead to
mkdir _build && cd _build && cmake .. && make
taking the same ti
On Tue, 12 Jan 2021, Sandro Santilli wrote:
On Tue, Jan 12, 2021 at 11:26:42AM +0100, Roger Bivand wrote:
(log out and reboot system)
mkdir _build
cd _build
cmake ../geos-3.9.0
time make
# real 0m12.358s
# user 0m8.308s
# sys 0m3.393s
The ouput objects are being cached somewhere, and
Source - C API
Requires:
Version: 3.10.0dev
Cflags: -I${includedir}
Libs: -L${libdir} -lgeos_c
also pointing at /usr/local/lib, not /usr/local/lib64. Was the instalation
to lib64 a recent change and was it intended?
Best wishes,
Roger
--
Roger Bivand
Emeritus Professor
Department of Economics
, Roger Bivand wrote:
Following the decision to drop autotools, I see that cmake generates (in the
current state of the gitea repo) a geos-config that points to /usr/local/lib
for installed shared objects on Linux, but installs in /usr/local/lib64,
leading to other programs not finding them. I
.
Cheers,
Mike
--
Roger Bivand
Emeritus Professor
Department of Economics, Norwegian School of Economics,
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway.
e-mail: roger.biv...@nhh.no
https://orcid.org/-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0J&h
:
On Thu, 6 May 2021 at 18:59, Roger Bivand wrote:
Thanks - what would be the best way for me to patch my instance of the
gitea repo to check that this works? Can I get a regular diff from a git
PR?
Just add .diff to the address:
https://github.com/libgeos/geos/pull/447.diff
And yes, please
wrote:
On Fri, 7 May 2021 at 00:19, Roger Bivand wrote:
I ran:
$ cat 447.diff | patch -p1 -c -b
patching file tools/CMakeLists.txt
patching file tools/geos-config.cmake
patching file tools/geos-config.in
patching file tools/geos.pc.cmake
I get this too, but on inspection it didn't actu
lib64/pkgconfig
Even
--
Roger Bivand
Emeritus Professor
Department of Economics, Norwegian School of Economics,
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway.
e-mail: roger.biv...@nhh.no
https://orcid.org/-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0J&
ven't tested geos.pc in a dependency
configure.
Roger
--
Roger Bivand
Emeritus Professor
Department of Economics, Norwegian School of Economics,
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway.
e-mail: roger.biv...@nhh.no
https://orcid.org/-0003-2392-6140
https://scholar
On Fri, 7 May 2021, Roger Bivand wrote:
On Fri, 7 May 2021, Even Rouault wrote:
Yes, of course you are right, thanks! After removing it and with
/usr/local/lib64/pkgconfig on the path (it was there before, but after
/usr/local/lib/pkgconfig):
$ pkg-config geos --libs
-lgeos_c
of R packages across
multiple platforms, and is having to hot-patch this at the moment. I'll
check further with R packages, but already checked with 3.10.0dev during
the summer and have adapted as necessary (mostly 3.9 sorting after 3.10
problems).
Roger
--
Roger Bivand
Emeritus Professor
/github.com/rsbivand/foss4g21/blob/main/bivand_foss4g_210930.pdf
from the FOSS4G R-spatial panel two days ago, slides 2-3.
Roger
--
Roger Bivand
Emeritus Professor
Department of Economics, Norwegian School of Economics,
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway.
e-mail: roger.biv...@nhh.no
ht
On Sat, 2 Oct 2021, Roger Bivand wrote:
On Fri, 1 Oct 2021, Greg Troxel wrote:
Paul Ramsey writes:
That feels... off the reservation for a library and something for the
final build? Like, not every platform requires that link, I don't think.
My quick reaction is that -lstdc++
After fixing https://github.com/r-spatial/sf/issues/1809 in R package sf,
the reverse dependency checks overnight on 1050 R packages using R
packages linking to GEOS appear clean, with no new failing changes.
Roger
--
Roger Bivand
Emeritus Professor
Department of Economics, Norwegian School
n I can work out how to get a viable Cmake
workflow, I can try to transfer it to Windows cross-compilation under MXE
and native macOS.
Any help very welcome.
Roger
--
Roger Bivand
Emeritus Professor
Department of Economics, Norwegian School of Economics,
Postboks 3490 Ytre Sandviken, 5045 Berg
On Fri, 15 Oct 2021, Paul Ramsey wrote:
On Oct 15, 2021, at 2:00 AM, Roger Bivand wrote:
/usr/bin/ld: /home/rsb/static/lib64/libgeos.a(WKTWriter.cpp.o): in function
`geos::io::WKTWriter::writeNumber[abi:cxx11](double) const':
WKTWriter.cpp:(.text+0xe39): undefined referen
On Fri, 15 Oct 2021, Paul Ramsey wrote:
On Oct 15, 2021, at 8:05 AM, Roger Bivand wrote:
On Fri, 15 Oct 2021, Paul Ramsey wrote:
On Oct 15, 2021, at 2:00 AM, Roger Bivand wrote:
/usr/bin/ld: /home/rsb/static/lib64/libgeos.a(WKTWriter.cpp.o): in function
`geos::io::WKTWriter
On Fri, 15 Oct 2021, Paul Ramsey wrote:
On Oct 15, 2021, at 10:26 AM, Paul Ramsey wrote:
On Oct 15, 2021, at 8:20 AM, Roger Bivand wrote:
Good. I moved libryu.a to the installed lib64 directory and added
-lryu to the g++ command, and there immediate failure is gone. I added
Thanks very much; static and dynamic builds OK with R package rgeos.
Roger
--
Roger Bivand
Emeritus Professor
Department of Economics, Norwegian School of Economics,
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway.
e-mail: roger.biv...@nhh.no
https://orcid.org/-0003-2392-6140
https
The R archive network checks R packages and their upstream libraries on Intel
Solaris (details
https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86), so a build
of 3.10.0 has been tried. -DBUILD_GEOSOP=OFF was needed but is unimportant,
however, sqrt(2) in geos-3.10.0/tests/unit/ca
GEOS 3.10.1 now compiles and checks on Solaris (Oracle Developer Studio).
Thanks for the rapid fix.
Roger
--
Roger Bivand
Emeritus Professor
Department of Economics, Norwegian School of Economics,
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway.
e-mail: roger.biv...@nhh.no
https://orcid.org
wishes,
Roger
--
Roger Bivand
Emeritus Professor
Department of Economics, Norwegian School of Economics,
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway.
e-mail: roger.biv...@nhh.no
https://orcid.org/-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0J
oubt that GCC 13 fixes are a general
requirement?
Sorry for the distraction,
Roger
--
Roger Bivand
Emeritus Professor
Norwegian School of Economics
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
roger.biv...@nhh.no
___
geos-devel mailing list
geos-d
probably will
need someone who knows the code well to make progress. I wouldn't dare try to
add the now missing #include where it seems to be needed. I tried
-DCMAKE_CXX_STANDARD=98 and 11 without success. Sorry not to be more help.
Roger
--
Roger Bivand
Emeritus Professor
Norwegian Scho
tion: Overlay input is mixed-dimension
The input shapefile may be found at
https://github.com/rspatial/terra/tree/master/inst/ex/lux.*
I'm unsure whether this is change intentional, should I provide a WKT of the
shapefile geometries, possibly planar?
Best wishes,
Roger
--
Roger Bivand
Emeritus
Thanks, Paul, for responding so quickly.
Having built GEOS with
https://github.com/pramsey/geos/tree/main-collection-overlay, the issues in
released and development versions of R package terra appear resolved.
The sf package remains unaffected by 3.12.
Roger
--
Roger Bivand
Emeritus
Paul, will try tomorrow morning my time. Does this 3.11 contain the fix for gcc
13 - I had to switch to devel on upgrading to Fedora 38 so if that commit is
also present here, it should be feasible, if not rather harder.
Roger
--
Roger Bivand
Emeritus Professor
Norwegian School of Economics
d and development versions of terra pass with 3.12.0beta2.
I think that this means that the 3.11 branch does not have the mitigations for
the multiple dimension problem.
Roger
--
Roger Bivand
Emeritus Professor
Norwegian School of Economics
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
roge
Bas, thanks for watching my back!
rgeos current on CRAN is 0.6-3; development 0.6-4 on
https://r-forge.r-project.org/R/?group_id=602 has resolved the problem (an
extra parentheses in a WKT string in a test/example). I'll submit to CRAN
shortly, not a blocker.
Roger
--
Roger Bivand
Eme
alling rgeos_plspairUnion()
- desperate test framework, or rgeos_plsbufUnion() which I had thought
worked, but which clearly doesn't dissolve small squares.
Very grateful for any help, this is a show-stopper, and I had hoped to
release rgeos before February (small chance now!)
Roger
--
Roger Bivan
o the
coordinates.
Anyway, I'm sure that Unary Union is a better solution than buffer(0) in
general, so thanks for that!
Roger
Martin
Roger Bivand wrote:
Hi,
I've felt that I've been making reasonable progress with interfacing GEOS
geometries and methods for the R language (cran.
only
differing in scale (the coordinates of the second are 1000 times those of
the first). I see the same difference on GEOS 3.2.0/C API 1.6.0 on x86_64
RHEL5 and with an MSYS-built GEOS 3.2.0/C API 1.6.0 on Win 32 R.
Hope this is good enough, grateful for any ideas,
Roger
Roger Bivand w
;m amazed that someone actually
interfaced to JTS via files and presumably system calls - but I guess when
all you have is a hammer...)
Roger
Roger Bivand wrote:
On Mon, 1 Feb 2010, Martin Davis wrote:
Can you post the WKT/WKB of your test case?
If this is WKT, then:
SP2WKT(spol0
~strk/services.html
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, He
(multi)-polygons is crucial. GEOS ought to be able to deliver, but I need
to be shown how - example code, proper documentation of the C API (saying
what can be used as arguments to functions as a start without having to
delve through arcane C++ documentation which may or may not apply to the
On Wed, 10 Feb 2010, strk wrote:
On Wed, Feb 10, 2010 at 10:46:33AM +0100, Roger Bivand wrote:
Continuing to try to interface R and GEOS (CAPI), I am puzzled that
GEOSSymDifference() and GEOSIntersection() seem to require input objects
to be "Geometry must be a Point or LineString"
On Wed, 10 Feb 2010, strk wrote:
On Wed, Feb 10, 2010 at 12:00:31PM +0100, Roger Bivand wrote:
On Wed, 10 Feb 2010, strk wrote:
On Wed, Feb 10, 2010 at 10:46:33AM +0100, Roger Bivand wrote:
Continuing to try to interface R and GEOS (CAPI), I am puzzled that
GEOSSymDifference() and
On Wed, 10 Feb 2010, strk wrote:
On Wed, Feb 10, 2010 at 12:35:46PM +0100, Roger Bivand wrote:
Are GEOSSymDifference() and GEOSIntersection() intended to take at least
POLYGON inputs, and then return POLYGON output, or not?
No. They are supposed to work also on linear and puntual geometries
On Wed, 10 Feb 2010, strk wrote:
On Wed, Feb 10, 2010 at 02:44:44PM +0100, Roger Bivand wrote:
On Wed, 10 Feb 2010, strk wrote:
On Wed, Feb 10, 2010 at 12:35:46PM +0100, Roger Bivand wrote:
Are GEOSSymDifference() and GEOSIntersection() intended to take at least
POLYGON inputs, and then
realise that GEOS usually goes in at the base of the software stack, and
usually interfaces GIS-type systems, so this case is somewhat atypical.
Roger
Howard
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailma
On Wed, 3 Feb 2010, Roger Bivand wrote:
(reverting to list - link to test C code below).
For closure on the thread of touching polygons not being merged by union
operations:
The rgeos R/GEOS interface is now a GSoC project within the R project, and
the "student", Colin Rundel,
ith an int saying how many are present. Does anyone have any use examples
of GEOSSTRtree_query in the C API?
Grateful for any pointers,
Roger
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Berg
es (all I asked for) ... links?
Roger
On May 4, 2010, at 8:30 AM, Roger Bivand wrote:
Hi,
I'm investigating the use of STRtree functions in C API to find candidate
GEOS_MULTIPOLYGON or GEOS_POLYGON objects to test for contiguity, with
GEOSDisjoint() or GEOSTouches(). I think that I
On Tue, 4 May 2010, Gavin Heavyside wrote:
On 4 May 2010 14:30, Roger Bivand wrote:
Hi,
I'm investigating the use of STRtree functions in C API to find candidate
GEOS_MULTIPOLYGON or GEOS_POLYGON objects to test for contiguity, with
GEOSDisjoint() or GEOSTouches(). I think that I can se
74 matches
Mail list logo
