Re: [geos-devel] 3.9.0beta + GEOSwift + Linux

2020-11-30 Thread Andrew Hershberger 
Seems like the macOS builds are getting their  from llvm's libc++
but that the build in the Swift Docker container is using the GNU C++.
LLVM's vector
(Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector)
imports algorithm. The GNU C++ version doesn't (at least not directly). I
find this Swift Package Manager behavior on Linux strange because the
GEOSwift/geos package definition specifically requests "cxx11" (as opposed
to "gnucxx11"). I'll see whether someone from the Swift team can shed
some light on what's going on here.

On Mon, Nov 30, 2020 at 11:40 PM Andrew Hershberger <
andrew.d.hershber...@gmail.com> wrote:

> That works. I had to add it to KdTree.cpp as well. Agree that it's strange.
>
> On Mon, Nov 30, 2020 at 9:17 PM Paul Ramsey 
> wrote:
>
>>
>>
>> > On Nov 30, 2020, at 7:15 PM, Andrew Hershberger <
>> andrew.d.hershber...@gmail.com> wrote:
>> >
>> > Found another issue with the beta when testing GEOSwift on Linux
>> (specifically, compiling in a Docker container using the Swift Docker
>> image). Here's what I'm doing:
>> >
>> > $ sudo docker run -it --rm swift /bin/bash
>> > # cd home
>> > # git clone https://github.com/GEOSwift/GEOSwift.git
>> > # cd GEOSwift
>> > # git checkout geos-3.9.0-testing
>> > # swift test --enable-test-discovery -v
>> >
>> > Among other things, this yields the following line for LineLimiter.cpp:
>> >
>> > /usr/bin/clang -target x86_64-unknown-linux-gnu -fPIC -g -O0
>> -DSWIFT_PACKAGE=1 -DDEBUG=1 -fblocks -fmodules -fmodule-name=geos -I
>> /home/GEOSwift/.build/checkouts/geos/Sources/geos/public
>> -fmodules-cache-path=/home/GEOSwift/.build/x86_64-unknown-linux-gnu/debug/ModuleCache
>> -DUSE_UNSTABLE_GEOS_CPP_API
>> -I/home/GEOSwift/.build/checkouts/geos/Sources/geos/include -MD -MT
>> dependencies -MF
>> /home/GEOSwift/.build/x86_64-unknown-linux-gnu/debug/geos.build/src/operation/overlayng/LineLimiter.cpp.d
>> -std=c++11 -c
>> /home/GEOSwift/.build/checkouts/geos/Sources/geos/src/operation/overlayng/LineLimiter.cpp
>> -o
>> /home/GEOSwift/.build/x86_64-unknown-linux-gnu/debug/geos.build/src/operation/overlayng/LineLimiter.cpp.o
>> >
>> > And this corresponding error:
>> >
>> >
>> /home/GEOSwift/.build/checkouts/geos/Sources/geos/src/operation/overlayng/LineLimiter.cpp:121:24:
>> error: no member named 'unique' in namespace 'std'
>> > ptList->erase(std::unique(ptList->begin(), ptList->end()),
>> ptList->end());
>>
>> Add #include 
>> to LineLimiter.cpp see if that helps?
>>
>> Not sure why only your version would have this problem. Maybe it's in
>> different headers sometimes?
>>
>>
>> >   ~^
>> >
>> > Here's some clang version info:
>> >
>> > clang version 10.0.0 (g...@github.com:apple/llvm-project.git
>> 3093af41dd65ad466dcd5603e9289244edfee4f5)
>> > Target: x86_64-unknown-linux-gnu
>> > Thread model: posix
>> > InstalledDir: /usr/bin
>> >
>> > Any idea what might be going on here?
>> >
>> > ___
>> > geos-devel mailing list
>> > geos-devel@lists.osgeo.org
>> > https://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>> ___
>> geos-devel mailing list
>> geos-devel@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.9.0beta + GEOSwift + Linux

2020-11-30 Thread Andrew Hershberger 
That works. I had to add it to KdTree.cpp as well. Agree that it's strange.

On Mon, Nov 30, 2020 at 9:17 PM Paul Ramsey 
wrote:

>
>
> > On Nov 30, 2020, at 7:15 PM, Andrew Hershberger <
> andrew.d.hershber...@gmail.com> wrote:
> >
> > Found another issue with the beta when testing GEOSwift on Linux
> (specifically, compiling in a Docker container using the Swift Docker
> image). Here's what I'm doing:
> >
> > $ sudo docker run -it --rm swift /bin/bash
> > # cd home
> > # git clone https://github.com/GEOSwift/GEOSwift.git
> > # cd GEOSwift
> > # git checkout geos-3.9.0-testing
> > # swift test --enable-test-discovery -v
> >
> > Among other things, this yields the following line for LineLimiter.cpp:
> >
> > /usr/bin/clang -target x86_64-unknown-linux-gnu -fPIC -g -O0
> -DSWIFT_PACKAGE=1 -DDEBUG=1 -fblocks -fmodules -fmodule-name=geos -I
> /home/GEOSwift/.build/checkouts/geos/Sources/geos/public
> -fmodules-cache-path=/home/GEOSwift/.build/x86_64-unknown-linux-gnu/debug/ModuleCache
> -DUSE_UNSTABLE_GEOS_CPP_API
> -I/home/GEOSwift/.build/checkouts/geos/Sources/geos/include -MD -MT
> dependencies -MF
> /home/GEOSwift/.build/x86_64-unknown-linux-gnu/debug/geos.build/src/operation/overlayng/LineLimiter.cpp.d
> -std=c++11 -c
> /home/GEOSwift/.build/checkouts/geos/Sources/geos/src/operation/overlayng/LineLimiter.cpp
> -o
> /home/GEOSwift/.build/x86_64-unknown-linux-gnu/debug/geos.build/src/operation/overlayng/LineLimiter.cpp.o
> >
> > And this corresponding error:
> >
> >
> /home/GEOSwift/.build/checkouts/geos/Sources/geos/src/operation/overlayng/LineLimiter.cpp:121:24:
> error: no member named 'unique' in namespace 'std'
> > ptList->erase(std::unique(ptList->begin(), ptList->end()),
> ptList->end());
>
> Add #include 
> to LineLimiter.cpp see if that helps?
>
> Not sure why only your version would have this problem. Maybe it's in
> different headers sometimes?
>
>
> >   ~^
> >
> > Here's some clang version info:
> >
> > clang version 10.0.0 (g...@github.com:apple/llvm-project.git
> 3093af41dd65ad466dcd5603e9289244edfee4f5)
> > Target: x86_64-unknown-linux-gnu
> > Thread model: posix
> > InstalledDir: /usr/bin
> >
> > Any idea what might be going on here?
> >
> > ___
> > geos-devel mailing list
> > geos-devel@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/geos-devel
>
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] MSVC Unit Failure

2020-11-30 Thread Paul Ramsey 
I looked into the git log for TopologyPreservingSimplifierTest.cpp and found 
this:

commit 7014e2b6509709f70dc08ca3b4b4d843d3df2a71
Author: Daniel Baston 
Date:   Sat Dec 22 20:49:22 2018 -0500

Change std::map to std::unordered_map in TopologyPreservingSimplifier

If I change the unordered_map back to a map... I get the exact same unit test 
failure on my MacOS machine. I've pushed a branch to see if it now succeeds 
under MSVC.

P


> On Nov 30, 2020, at 8:31 PM, Mike Taves  wrote:
> 
> On Sat, 28 Nov 2020 at 17:59, Paul Ramsey  wrote:
>> 
>> The actual build logs you can see here
>> 
>> https://dev.azure.com/libgeos/geos/_build/results?buildId=772=logs=305851a9-a7bb-55db-0042-7e2b6f48aa1c=2bd7b19d-6351-5e7f-8417-63f327ab45bc
> 
> While I don't know how to fix the issue, I've recompiled the issue
> with tests\unit\simplify\TopologyPreservingSimplifierTest.cpp to show
> the expected/result info:
> 
> D:\src\GEOS\geos-git\build>ctest -C Release -R
> unit-simplify-TopologyPreservingSimplifier -V
> UpdateCTestConfiguration  from 
> :D:/src/GEOS/geos-git/build/DartConfiguration.tcl
> Parse Config file:D:/src/GEOS/geos-git/build/DartConfiguration.tcl
> UpdateCTestConfiguration  from 
> :D:/src/GEOS/geos-git/build/DartConfiguration.tcl
> Parse Config file:D:/src/GEOS/geos-git/build/DartConfiguration.tcl
> Test project D:/src/GEOS/geos-git/build
> Constructing a list of tests
> Done constructing a list of tests
> Updating test list for fixtures
> Added 0 tests to meet fixture requirements
> Checking test dependency graph...
> Checking test dependency graph end
> test 198
>Start 198: unit-simplify-TopologyPreservingSimplifier
> 
> 198: Test command: D:\src\GEOS\geos-git\build\bin\test_geos_unit.exe
> "geos::simplify::TopologyPreservingSimplifier"
> 198: Test timeout computed to be: 1500
> 198: ===
> 198:   GEOS Test Suite Application
> 198: ===
> 198:
> 198: geos::simplify::TopologyPreservingSimplifier:
> expected
> 01050002000102000200594001020003004940F03F5940
> 198: result 
> 01050002000102000200594001020002005940
> 198: [14=F]..
> 198:
> 198: ---> group: geos::simplify::TopologyPreservingSimplifier, test: test<14>
> 198:  problem: assertion failed
> 198:  failed assertion: `number of points do not match: expected
> `4` actual `5``
> 198:
> 198: tests summary: failures:1 ok:14
> 1/1 Test #198: unit-simplify-TopologyPreservingSimplifier ...***Failed
>   0.03 sec
> 
> 0% tests passed, 1 tests failed out of 1
> 
> Total Test time (real) =   0.07 sec
> 
> The following tests FAILED:
>198 - unit-simplify-TopologyPreservingSimplifier (Failed)
> Errors while running CTest
> 
> D:\src\GEOS\geos-git\build>ctest -C Release -R
> unit-simplify-TopologyPreservingSimplifier
> Test project D:/src/GEOS/geos-git/build
>Start 198: unit-simplify-TopologyPreservingSimplifier
> 1/1 Test #198: unit-simplify-TopologyPreservingSimplifier ...   Passed
>   0.04 sec
> 
> 100% tests passed, 0 tests failed out of 1
> 
> Total Test time (real) =   0.15 sec
> 
> 
> This test takes input:
> MULTILINESTRING((0 0, 50 0, 70 0, 80 0, 100 0), (0 0, 50 1, 60 1, 100 0))
> 
> And performs simplify with tolerance 10.0, and expects:
> MULTILINESTRING ((0 0, 100 0), (0 0, 50 1, 100 0))
> 
> But for whatever reason, gets:
> MULTILINESTRING ((0 0, 100 0), (0 0, 100 0))
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] MSVC Unit Failure

2020-11-30 Thread Mike Taves 
On Sat, 28 Nov 2020 at 17:59, Paul Ramsey  wrote:
>
> The actual build logs you can see here
>
> https://dev.azure.com/libgeos/geos/_build/results?buildId=772=logs=305851a9-a7bb-55db-0042-7e2b6f48aa1c=2bd7b19d-6351-5e7f-8417-63f327ab45bc

While I don't know how to fix the issue, I've recompiled the issue
with tests\unit\simplify\TopologyPreservingSimplifierTest.cpp to show
the expected/result info:

D:\src\GEOS\geos-git\build>ctest -C Release -R
unit-simplify-TopologyPreservingSimplifier -V
UpdateCTestConfiguration  from :D:/src/GEOS/geos-git/build/DartConfiguration.tcl
Parse Config file:D:/src/GEOS/geos-git/build/DartConfiguration.tcl
UpdateCTestConfiguration  from :D:/src/GEOS/geos-git/build/DartConfiguration.tcl
Parse Config file:D:/src/GEOS/geos-git/build/DartConfiguration.tcl
Test project D:/src/GEOS/geos-git/build
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 198
Start 198: unit-simplify-TopologyPreservingSimplifier

198: Test command: D:\src\GEOS\geos-git\build\bin\test_geos_unit.exe
"geos::simplify::TopologyPreservingSimplifier"
198: Test timeout computed to be: 1500
198: ===
198:   GEOS Test Suite Application
198: ===
198:
198: geos::simplify::TopologyPreservingSimplifier:
expected
01050002000102000200594001020003004940F03F5940
198: result 
01050002000102000200594001020002005940
198: [14=F]..
198:
198: ---> group: geos::simplify::TopologyPreservingSimplifier, test: test<14>
198:  problem: assertion failed
198:  failed assertion: `number of points do not match: expected
`4` actual `5``
198:
198: tests summary: failures:1 ok:14
1/1 Test #198: unit-simplify-TopologyPreservingSimplifier ...***Failed
   0.03 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.07 sec

The following tests FAILED:
198 - unit-simplify-TopologyPreservingSimplifier (Failed)
Errors while running CTest

D:\src\GEOS\geos-git\build>ctest -C Release -R
unit-simplify-TopologyPreservingSimplifier
Test project D:/src/GEOS/geos-git/build
Start 198: unit-simplify-TopologyPreservingSimplifier
1/1 Test #198: unit-simplify-TopologyPreservingSimplifier ...   Passed
   0.04 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) =   0.15 sec


This test takes input:
MULTILINESTRING((0 0, 50 0, 70 0, 80 0, 100 0), (0 0, 50 1, 60 1, 100 0))

And performs simplify with tolerance 10.0, and expects:
MULTILINESTRING ((0 0, 100 0), (0 0, 50 1, 100 0))

But for whatever reason, gets:
MULTILINESTRING ((0 0, 100 0), (0 0, 100 0))
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.9.0beta + GEOSwift + Linux

2020-11-30 Thread Paul Ramsey 



> On Nov 30, 2020, at 7:15 PM, Andrew Hershberger 
>  wrote:
> 
> Found another issue with the beta when testing GEOSwift on Linux 
> (specifically, compiling in a Docker container using the Swift Docker image). 
> Here's what I'm doing:
> 
> $ sudo docker run -it --rm swift /bin/bash
> # cd home
> # git clone https://github.com/GEOSwift/GEOSwift.git
> # cd GEOSwift
> # git checkout geos-3.9.0-testing
> # swift test --enable-test-discovery -v
> 
> Among other things, this yields the following line for LineLimiter.cpp:
> 
> /usr/bin/clang -target x86_64-unknown-linux-gnu -fPIC -g -O0 
> -DSWIFT_PACKAGE=1 -DDEBUG=1 -fblocks -fmodules -fmodule-name=geos -I 
> /home/GEOSwift/.build/checkouts/geos/Sources/geos/public 
> -fmodules-cache-path=/home/GEOSwift/.build/x86_64-unknown-linux-gnu/debug/ModuleCache
>  -DUSE_UNSTABLE_GEOS_CPP_API 
> -I/home/GEOSwift/.build/checkouts/geos/Sources/geos/include -MD -MT 
> dependencies -MF 
> /home/GEOSwift/.build/x86_64-unknown-linux-gnu/debug/geos.build/src/operation/overlayng/LineLimiter.cpp.d
>  -std=c++11 -c 
> /home/GEOSwift/.build/checkouts/geos/Sources/geos/src/operation/overlayng/LineLimiter.cpp
>  -o 
> /home/GEOSwift/.build/x86_64-unknown-linux-gnu/debug/geos.build/src/operation/overlayng/LineLimiter.cpp.o
> 
> And this corresponding error:
> 
> /home/GEOSwift/.build/checkouts/geos/Sources/geos/src/operation/overlayng/LineLimiter.cpp:121:24:
>  error: no member named 'unique' in namespace 'std'
> ptList->erase(std::unique(ptList->begin(), ptList->end()), ptList->end());

Add #include 
to LineLimiter.cpp see if that helps?

Not sure why only your version would have this problem. Maybe it's in different 
headers sometimes?


>   ~^
> 
> Here's some clang version info:
> 
> clang version 10.0.0 (g...@github.com:apple/llvm-project.git 
> 3093af41dd65ad466dcd5603e9289244edfee4f5)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
> 
> Any idea what might be going on here?
> 
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] 3.9.0beta + GEOSwift + Linux

2020-11-30 Thread Andrew Hershberger 
Found another issue with the beta when testing GEOSwift on Linux
(specifically, compiling in a Docker container using the Swift Docker
image). Here's what I'm doing:

$ sudo docker run -it --rm swift /bin/bash
# cd home
# git clone https://github.com/GEOSwift/GEOSwift.git
# cd GEOSwift
# git checkout geos-3.9.0-testing
# swift test --enable-test-discovery -v

Among other things, this yields the following line for LineLimiter.cpp:

/usr/bin/clang -target x86_64-unknown-linux-gnu -fPIC -g -O0
-DSWIFT_PACKAGE=1 -DDEBUG=1 -fblocks -fmodules -fmodule-name=geos -I
/home/GEOSwift/.build/checkouts/geos/Sources/geos/public
-fmodules-cache-path=/home/GEOSwift/.build/x86_64-unknown-linux-gnu/debug/ModuleCache
-DUSE_UNSTABLE_GEOS_CPP_API
-I/home/GEOSwift/.build/checkouts/geos/Sources/geos/include -MD -MT
dependencies -MF
/home/GEOSwift/.build/x86_64-unknown-linux-gnu/debug/geos.build/src/operation/overlayng/LineLimiter.cpp.d
-std=c++11 -c
/home/GEOSwift/.build/checkouts/geos/Sources/geos/src/operation/overlayng/LineLimiter.cpp
-o
/home/GEOSwift/.build/x86_64-unknown-linux-gnu/debug/geos.build/src/operation/overlayng/LineLimiter.cpp.o

And this corresponding error:

/home/GEOSwift/.build/checkouts/geos/Sources/geos/src/operation/overlayng/LineLimiter.cpp:121:24:
error: no member named 'unique' in namespace 'std'
ptList->erase(std::unique(ptList->begin(), ptList->end()),
ptList->end());
  ~^

Here's some clang version info:

clang version 10.0.0 (g...@github.com:apple/llvm-project.git
3093af41dd65ad466dcd5603e9289244edfee4f5)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Any idea what might be going on here?
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.9.0beta1 + GEOSwift

2020-11-30 Thread Andrew Hershberger 
Looks good. The GEOSwift test suite passes with your change. Thanks!

On Mon, Nov 30, 2020 at 4:13 PM Paul Ramsey 
wrote:

> Thanks for this report! Would you mind trying out the fix here:
>
> https://github.com/libgeos/geos/pull/360
>
> P.
>
> > On Nov 28, 2020, at 6:33 PM, Andrew Hershberger <
> andrew.d.hershber...@gmail.com> wrote:
> >
> > Hi all, I help maintain https://github.com/GEOSwift/GEOSwift
> >
> > I'm testing out 3.9.0beta1 and have run into a couple things to share.
> >
> > If you want to try any of these out directly with GEOSwift, I recommend
> using the Swift Package Manager. You can clone
> https://github.com/GEOSwift/GEOSwift.git and check out branch
> geos-3.9.0-testing. Then run `$ swift test` to build and run the tests. I'm
> using Swift 5.3.1. One way to get Swift is to use the Docker image:
> https://hub.docker.com/_/swift
> >
> > 1) GeometryConvertible_GEOSTests.testMakeValidWhenItIsAPolygon()
> >
> > This test is checking that makeValid() (a wrapper around the CAPI's
> GEOSMakeValid_r) produces an expected result given some pre-defined
> geometry. Here's what happened:
> >
> > Input:
> >
> > Polygon(
> >   exterior: LinearRing(
> > points: [
> >   Point(x: 0, y: 0),
> >   Point(x: 2, y: 0),
> >   Point(x: 1, y: 1),
> >   Point(x: 0, y: 2),
> >   Point(x: 2, y: 2),
> >   Point(x: 1, y: 1),
> >   Point(x: 0, y: 0)
> > ]
> >   )
> > )
> >
> > Actual (wrapped in a multipolygon)
> >
> > Polygon(
> >   exterior: LinearRing(
> > points: [
> >   Point(x: 0, y: 2),
> >   Point(x: 2, y: 2),
> >   Point(x: 1, y: 1),
> >   Point(x: 0, y: 2)
> > ]
> >   )
> > )
> >
> > Polygon(
> >   exterior: LinearRing(
> > points: [
> >   Point(x: 2, y: 0),
> >   Point(x: 0, y: 0),
> >   Point(x: 1, y: 1),
> >   Point(x: 2, y: 0)
> > ]
> >   )
> > )
> >
> > Expected (wrapped in any order in a multipolygon)
> >
> > Polygon(
> >   exterior: LinearRing(
> > points: [
> >   Point(x: 1, y: 1),
> >   Point(x: 2, y: 0),
> >   Point(x: 0, y: 0),
> >   Point(x: 1, y: 1)
> > ]
> >   )
> > )
> >
> > Polygon(
> >   exterior: LinearRing(
> > points: [
> >   Point(x: 1, y: 1),
> >   Point(x: 0, y: 2),
> >   Point(x: 2, y: 2),
> >   Point(x: 1, y: 1)
> > ]
> >   )
> > )
> >
> > Since these are topologically equivalent, I've just updated the test to
> check for that instead of exact equality (see GEOSwift commit
> 6c4b191646623159528433fbd112c11ddce7c5ea on the aforementioned branch), but
> I thought I'd share here just in case this behavior is unexpected.
> >
> > 2) GeometryConvertible_GEOSTests.testBufferAllTypes()
> >
> > This test is intended to be a sort of stress-test to make sure that all
> the types of geometry on which GEOSwift allows you to invoke buffer(by:)
> (wrapper around the CAPI's GEOSBuffer_r) can actually be buffered. In geos
> 3.8.1, all the sample geometries were able to be buffered without any
> issues.
> >
> > Here's what we get for one of the test cases with 3.9.0beta1:
> >
> > Input:
> >
> > GeometryCollection(
> >   geometries: [
> > GeometryCollection(
> >   geometries: [
> > Point(x: 1.0, y: 2.0),
> > MultiPoint(
> >   points: [
> > Point(x: 1.0, y: 2.0),
> > Point(x: 3.0, y: 4.0)
> >   ]
> > ),
> > LineString(
> >   points: [
> > Point(x: 1.0, y: 2.0),
> > Point(x: 3.0, y: 4.0)
> >   ]
> > ),
> > MultiLineString(
> >   lineStrings: [
> > LineString(
> >   points: [
> > Point(x: 1.0, y: 2.0),
> > Point(x: 3.0, y: 4.0)
> >   ]
> > ),
> > LineString(
> >   points: [
> > Point(x: 5.0, y: 6.0),
> > Point(x: 7.0, y: 8.0)
> >   ]
> > )
> >   ]
> > ),
> > Polygon(
> >   exterior: LinearRing(
> > points: [
> >   Point(x: 2.0, y: 2.0),
> >   Point(x: -2.0, y: 2.0),
> >   Point(x: -2.0, y: -2.0),
> >   Point(x: 2.0, y: -2.0),
> >   Point(x: 2.0, y: 2.0)
> > ]
> >   ),
> >   holes: [
> > LinearRing(
> >   points: [
> > Point(x: 1.0, y: 1.0),
> > Point(x: 1.0, y: -1.0),
> > Point(x: -1.0, y: -1.0),
> > Point(x: -1.0, y: 1.0),
> > Point(x: 1.0, y: 1.0)
> >   ]
> > )
> >   ]
> > ),
> > MultiPolygon(
> >   polygons: [
> > Polygon(
> >   exterior: LinearRing(
> > points: [
> >   Point(x: 2.0, y: 2.0),
> >   Point(x: -2.0, y: 2.0),
> >   Point(x: -2.0, y: -2.0),
> >   Point(x: 2.0, y: -2.0),
>

Re: [geos-devel] [GEOS] #1079: Inconsistent dimensionality change

2020-11-30 Thread GEOS 
#1079: Inconsistent dimensionality change
+--
 Reporter:  Mike Taves  |   Owner:  pramsey
 Type:  defect  |  Status:  new
 Priority:  minor   |   Milestone:  3.9.0
Component:  Default | Version:  master
 Severity:  Annoyance   |  Resolution:
 Keywords:  |
+--
Changes (by pramsey):

 * owner:  geos-devel@… => pramsey


-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [GEOS] #1079: Inconsistent dimensionality change

2020-11-30 Thread GEOS 
#1079: Inconsistent dimensionality change
+---
 Reporter:  Mike Taves  |   Owner:  geos-devel@…
 Type:  defect  |  Status:  new
 Priority:  minor   |   Milestone:  3.9.0
Component:  Default | Version:  master
 Severity:  Annoyance   |  Resolution:
 Keywords:  |
+---

Comment (by pramsey):

 Please check https://github.com/pramsey/geos/tree/geos-1079

-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [GEOS] #1079: Inconsistent dimensionality change

2020-11-30 Thread GEOS 
#1079: Inconsistent dimensionality change
+---
 Reporter:  Mike Taves  |   Owner:  geos-devel@…
 Type:  defect  |  Status:  new
 Priority:  minor   |   Milestone:  3.9.0
Component:  Default | Version:  master
 Severity:  Annoyance   |  Resolution:
 Keywords:  |
+---

Comment (by pramsey):

 Reading through WKTReader, it seems like the general goal is to promote
 the dimensionality of a given CoordinateSequence to the highest
 dimensionality encountered in the sequence. That doesn't seem to match the
 behaviour of the polygon case though, nor the new behaviour of the
 linestring case. In any event, the current model sort of sucks since it's
 possible to make a POLYGON with mixed dimension rings, or a
 multilinestring with mixed dimension members. Also you can make a
 linestringz with 2d coordinates, because the dimensionality tag is mostly
 ignored. (Not always).

-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [GEOS] #1079: Inconsistent dimensionality change

2020-11-30 Thread GEOS 
#1079: Inconsistent dimensionality change
+---
 Reporter:  Mike Taves  |   Owner:  geos-devel@…
 Type:  defect  |  Status:  new
 Priority:  minor   |   Milestone:  3.9.0
Component:  Default | Version:  master
 Severity:  Annoyance   |  Resolution:
 Keywords:  |
+---

Comment (by pramsey):

 It seems inconsistent all around, to me. What is the consistent rule
 supposed to be? My guess would have been "preserve the dimensionality of
 the first coordinate)" but this test belies that:
 {{{
 ('MULTIPOINT (1 1, 2 2 2)', 'MULTIPOINT Z (1 1 0, 2 2 2)'),
 }}}
 I suppose not changing behaviour is the highest good, I hate to see that
 version switch there when we haven't got consistent behaviour. I guess
 it's too late to be as strict as the PostGIS parser (dimensional mixing ==
 error).

-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.9.0beta1 + GEOSwift

2020-11-30 Thread Paul Ramsey 
Thanks for this report! Would you mind trying out the fix here:

https://github.com/libgeos/geos/pull/360

P.

> On Nov 28, 2020, at 6:33 PM, Andrew Hershberger 
>  wrote:
> 
> Hi all, I help maintain https://github.com/GEOSwift/GEOSwift
> 
> I'm testing out 3.9.0beta1 and have run into a couple things to share.
> 
> If you want to try any of these out directly with GEOSwift, I recommend using 
> the Swift Package Manager. You can clone 
> https://github.com/GEOSwift/GEOSwift.git and check out branch 
> geos-3.9.0-testing. Then run `$ swift test` to build and run the tests. I'm 
> using Swift 5.3.1. One way to get Swift is to use the Docker image: 
> https://hub.docker.com/_/swift
> 
> 1) GeometryConvertible_GEOSTests.testMakeValidWhenItIsAPolygon()
> 
> This test is checking that makeValid() (a wrapper around the CAPI's 
> GEOSMakeValid_r) produces an expected result given some pre-defined geometry. 
> Here's what happened:
> 
> Input:
> 
> Polygon(
>   exterior: LinearRing(
> points: [
>   Point(x: 0, y: 0),
>   Point(x: 2, y: 0),
>   Point(x: 1, y: 1),
>   Point(x: 0, y: 2),
>   Point(x: 2, y: 2),
>   Point(x: 1, y: 1),
>   Point(x: 0, y: 0)
> ]
>   )
> )
> 
> Actual (wrapped in a multipolygon)
> 
> Polygon(
>   exterior: LinearRing(
> points: [
>   Point(x: 0, y: 2),
>   Point(x: 2, y: 2),
>   Point(x: 1, y: 1),
>   Point(x: 0, y: 2)
> ]
>   )
> )
> 
> Polygon(
>   exterior: LinearRing(
> points: [
>   Point(x: 2, y: 0),
>   Point(x: 0, y: 0),
>   Point(x: 1, y: 1),
>   Point(x: 2, y: 0)
> ]
>   )
> )
> 
> Expected (wrapped in any order in a multipolygon)
> 
> Polygon(
>   exterior: LinearRing(
> points: [
>   Point(x: 1, y: 1),
>   Point(x: 2, y: 0),
>   Point(x: 0, y: 0),
>   Point(x: 1, y: 1)
> ]
>   )
> )
> 
> Polygon(
>   exterior: LinearRing(
> points: [
>   Point(x: 1, y: 1),
>   Point(x: 0, y: 2),
>   Point(x: 2, y: 2),
>   Point(x: 1, y: 1)
> ]
>   )
> )
> 
> Since these are topologically equivalent, I've just updated the test to check 
> for that instead of exact equality (see GEOSwift commit 
> 6c4b191646623159528433fbd112c11ddce7c5ea on the aforementioned branch), but I 
> thought I'd share here just in case this behavior is unexpected.
> 
> 2) GeometryConvertible_GEOSTests.testBufferAllTypes()
> 
> This test is intended to be a sort of stress-test to make sure that all the 
> types of geometry on which GEOSwift allows you to invoke buffer(by:) (wrapper 
> around the CAPI's GEOSBuffer_r) can actually be buffered. In geos 3.8.1, all 
> the sample geometries were able to be buffered without any issues.
> 
> Here's what we get for one of the test cases with 3.9.0beta1:
> 
> Input:
> 
> GeometryCollection(
>   geometries: [
> GeometryCollection(
>   geometries: [
> Point(x: 1.0, y: 2.0),
> MultiPoint(
>   points: [
> Point(x: 1.0, y: 2.0),
> Point(x: 3.0, y: 4.0)
>   ]
> ),
> LineString(
>   points: [
> Point(x: 1.0, y: 2.0),
> Point(x: 3.0, y: 4.0)
>   ]
> ),
> MultiLineString(
>   lineStrings: [
> LineString(
>   points: [
> Point(x: 1.0, y: 2.0),
> Point(x: 3.0, y: 4.0)
>   ]
> ),
> LineString(
>   points: [
> Point(x: 5.0, y: 6.0),
> Point(x: 7.0, y: 8.0)
>   ]
> )
>   ]
> ),
> Polygon(
>   exterior: LinearRing(
> points: [
>   Point(x: 2.0, y: 2.0),
>   Point(x: -2.0, y: 2.0),
>   Point(x: -2.0, y: -2.0),
>   Point(x: 2.0, y: -2.0),
>   Point(x: 2.0, y: 2.0)
> ]
>   ),
>   holes: [
> LinearRing(
>   points: [
> Point(x: 1.0, y: 1.0),
> Point(x: 1.0, y: -1.0),
> Point(x: -1.0, y: -1.0),
> Point(x: -1.0, y: 1.0),
> Point(x: 1.0, y: 1.0)
>   ]
> )
>   ]
> ),
> MultiPolygon(
>   polygons: [
> Polygon(
>   exterior: LinearRing(
> points: [
>   Point(x: 2.0, y: 2.0),
>   Point(x: -2.0, y: 2.0),
>   Point(x: -2.0, y: -2.0),
>   Point(x: 2.0, y: -2.0),
>   Point(x: 2.0, y: 2.0)
> ]
>   ),
>   holes: [
> LinearRing(
>   points: [
> Point(x: 1.0, y: 1.0),
> Point(x: 1.0, y: -1.0),
> Point(x: -1.0, y: -1.0),
> Point(x: -1.0, y: 1.0),
> Point(x: 1.0, y: 1.0)
>   ]
> )

[geos-devel] [GEOS] #1079: Inconsistent dimensionality change

2020-11-30 Thread GEOS 
#1079: Inconsistent dimensionality change
+--
 Reporter:  Mike Taves  |  Owner:  geos-devel@…
 Type:  defect  | Status:  new
 Priority:  minor   |  Milestone:  3.9.0
Component:  Default |Version:  master
 Severity:  Annoyance   |   Keywords:
+--
 Over in Shapely, there is a test suite
 
[https://github.com/Toblerity/Shapely/blob/b2b536004ee6b8316fffcee36ff8e1e65be71958/tests/test_create_inconsistent_dimensionality.py
 test_create_inconsistent_dimensionality.py] that checks WKT with
 inconsistent dimensionality. For most instances, a geometry with at least
 one 3D coordinate is promoted with a Z dimension, assuming Z=0 for other
 XY coordinates. There are a few isolated cases where the geometry remains
 as a 2D geometry if the 3D coordinate is not the first.

 Of these inconsistencies, one new inconsistency stands out as new and
 unusual.

 GEOS 3.8.1 and earlier:
 {{{
 # preserve 3rd dimension
 LINESTRING (1 1 1, 2 2) -> LINESTRING Z (1 1 1, 2 2 0)
 # drop 3rd dimension
 LINESTRING (1 1, 2 2 2) -> LINESTRING (1 1, 2 2)
 }}}
 Since GEOS 3.9.0beta1:
 {{{
 # drop 3rd dimension
 LINESTRING (1 1 1, 2 2) -> LINESTRING (1 1, 2 2)
 # preserve 3rd dimension
 LINESTRING (1 1, 2 2 2) -> LINESTRING Z (1 1 0, 2 2 2)
 }}}
 why is this the only geometry type scenario that swaps behaviour? Ideally
 any geometry with at lest one 3D coordinate would be promoted with a Z
 dimension.

-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [GEOS] #1046: Unary union does not combine all parts

2020-11-30 Thread GEOS 
#1046: Unary union does not combine all parts
+---
 Reporter:  Mike Taves  |   Owner:  geos-devel@…
 Type:  defect  |  Status:  closed
 Priority:  major   |   Milestone:  3.9.0
Component:  XML Tests   | Version:  master
 Severity:  Unassigned  |  Resolution:  fixed
 Keywords:  |
+---
Changes (by Mike Taves):

 * component:  Default => XML Tests
 * milestone:   => 3.9.0


-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [GEOS] #1046: Unary union does not combine all parts

2020-11-30 Thread GEOS 
#1046: Unary union does not combine all parts
+---
 Reporter:  Mike Taves  |   Owner:  geos-devel@…
 Type:  defect  |  Status:  closed
 Priority:  major   |   Milestone:
Component:  Default | Version:  master
 Severity:  Unassigned  |  Resolution:  fixed
 Keywords:  |
+---

Comment (by Mike Taves):

 This should have been closed with
 [80f78fb880a911262d4021aca4cf2b47715a40d9/git]

-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [GEOS] #996: Windows CMake Mingw64 32-bit gcc 8.1.0

2020-11-30 Thread GEOS 
#996: Windows CMake Mingw64 32-bit gcc 8.1.0
-+---
 Reporter:  robe |   Owner:  geos-devel@…
 Type:  defect   |  Status:  new
 Priority:  minor|   Milestone:  3.8.2
Component:  Default  | Version:  master
 Severity:  Significant  |  Resolution:
 Keywords:   |
-+---

Comment (by pramsey):

 This seems like an eternal ticket. How will it ever get closed?

-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [GEOS] #1064: Topology preserve simplify: unexpected behavior on similar polygons

2020-11-30 Thread GEOS 
#1064: Topology preserve simplify: unexpected behavior on similar polygons
+---
 Reporter:  uclaros |   Owner:  geos-devel@…
 Type:  defect  |  Status:  new
 Priority:  minor   |   Milestone:  GEOS Fund Me
Component:  Default | Version:  master
 Severity:  Unassigned  |  Resolution:
 Keywords:  |
+---
Changes (by pramsey):

 * milestone:  3.9.0 => GEOS Fund Me


-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [GEOS] #769: Robustness failure in GEOSVoronoiDiagram

2020-11-30 Thread GEOS 
#769: Robustness failure in GEOSVoronoiDiagram
+---
 Reporter:  dbaston |   Owner:  geos-devel@…
 Type:  defect  |  Status:  new
 Priority:  major   |   Milestone:  Upstream
Component:  Default | Version:  3.5.0
 Severity:  Unassigned  |  Resolution:
 Keywords:  |
+---
Changes (by pramsey):

 * milestone:  3.9.0 => Upstream


-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [GEOS] #1030: Retain order of inputs in GEOSVoronoiDiagram

2020-11-30 Thread GEOS 
#1030: Retain order of inputs in GEOSVoronoiDiagram
-+---
 Reporter:  dbaston  |   Owner:  geos-devel@…
 Type:  enhancement  |  Status:  new
 Priority:  major|   Milestone:  3.10.0
Component:  Default  | Version:  master
 Severity:  Unassigned   |  Resolution:
 Keywords:   |
-+---
Changes (by pramsey):

 * milestone:  3.9.0 => 3.10.0


-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] [GEOS] Batch modify: #344, #368, #522, #572, #614, #692, #340, #380

2020-11-30 Thread GEOS 
Batch modification to #344, #368, #522, #572, #614, #692, #340, #380 by pramsey:
milestone to Upstream

-- 
Tickets URL: 

GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [GEOS] #755: Overlay ops accept GeometryCollections when headers indicate that they don't

2020-11-30 Thread GEOS 
#755: Overlay ops accept GeometryCollections when headers indicate that they
don't
+---
 Reporter:  dbaston |   Owner:  geos-devel@…
 Type:  defect  |  Status:  new
 Priority:  major   |   Milestone:  3.10.0
Component:  Default | Version:  3.5.0
 Severity:  Unassigned  |  Resolution:
 Keywords:  |
+---
Changes (by pramsey):

 * milestone:  3.9.0 => 3.10.0


-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [GEOS] #760: Snapping leaves segments below tolerance

2020-11-30 Thread GEOS 
#760: Snapping leaves segments below tolerance
+---
 Reporter:  strk|   Owner:  geos-devel@…
 Type:  defect  |  Status:  new
 Priority:  major   |   Milestone:  3.10.0
Component:  Default | Version:  3.5.0
 Severity:  Unassigned  |  Resolution:
 Keywords:  |
+---
Changes (by pramsey):

 * milestone:  3.9.0 => 3.10.0


-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [GEOS] #572: Contains issue for complex LineStrings [JTS fails too]

2020-11-30 Thread GEOS 
#572: Contains issue for complex LineStrings [JTS fails too]
+---
 Reporter:  Mike Taves  |   Owner:  geos-devel@…
 Type:  defect  |  Status:  new
 Priority:  major   |   Milestone:  GEOS Fund Me
Component:  Default | Version:  3.3.4
 Severity:  Unassigned  |  Resolution:
 Keywords:  jtsfail |
+---
Changes (by pramsey):

 * milestone:  3.9.0 => GEOS Fund Me


-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [GEOS] #1046: Unary union does not combine all parts

2020-11-30 Thread GEOS 
#1046: Unary union does not combine all parts
+---
 Reporter:  Mike Taves  |   Owner:  geos-devel@…
 Type:  defect  |  Status:  closed
 Priority:  major   |   Milestone:
Component:  Default | Version:  master
 Severity:  Unassigned  |  Resolution:  fixed
 Keywords:  |
+---
Changes (by Mike Taves ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"aefdae974911aefe9bec1f1c2588a81d9e42407f/git" aefdae9/git]:
 {{{
 #!CommitTicketReference repository="git"
 revision="aefdae974911aefe9bec1f1c2588a81d9e42407f"
 Validate complex UnaryUnion test with OverlayNG

 Closes #1046
 }}}

-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [GEOS] #1046: Unary union does not combine all parts

2020-11-30 Thread GEOS 
#1046: Unary union does not combine all parts
+---
 Reporter:  Mike Taves  |   Owner:  geos-devel@…
 Type:  defect  |  Status:  new
 Priority:  major   |   Milestone:
Component:  Default | Version:  master
 Severity:  Unassigned  |  Resolution:
 Keywords:  |
+---

Comment (by Mike Taves):

 And I'll assume there are more geometry parts than the original to make a
 valid geometry.

-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [GEOS] #1046: Unary union does not combine all parts

2020-11-30 Thread GEOS 
#1046: Unary union does not combine all parts
+---
 Reporter:  Mike Taves  |   Owner:  geos-devel@…
 Type:  defect  |  Status:  new
 Priority:  major   |   Milestone:
Component:  Default | Version:  master
 Severity:  Unassigned  |  Resolution:
 Keywords:  |
+---

Comment (by Mike Taves):

 Revisiting this with 3.9.0beta1
 {{{
 ls = [x for x in mls.geoms]
 u = ops.unary_union(ls)
 print(len(u))  # 246
 print(u.length) # 27.7963165274577
 print(u.is_valid)  # True
 print(u.is_simple)  # True
 }}}
 so it looks like the unary union with OverlayNG cleaned up several
 redundant line segments, and created a valid/simple output.

 See https://github.com/libgeos/geos/pull/358 to add this as a test.

-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel