Hi list!
(Apologies in advance for the embedded image, I couldn't write this
post sensibly without it).
I had a novel request this week for calculation of buffers which
respect obstacle geometries. Given input features (the red dot below,
but could also be line/polygon features), and a layer of
On Sun, 29 Jan 2023 at 23:20, Regina Obe wrote:
>
> Even,
>
>
>
> You know the traction for viewing curves? Last I checked a couple years ago
> it was pretty weak on the OpenLayers, Leaflet, QGIS front. At a glance
> things seem better, but I haven’t heard people using curves beyond the CAD
On Wed, 7 Dec 2022 at 11:04, Daniel Baston wrote:
>
> Hi All,
>
> The "Priority 1" item in this list has been completed, and I've been chipping
> away at items #3 and #5 as well as many bug fixes and opportunistic
> optimizations. While there is plenty to keep busy with along this track, I
>
On Wed, 7 Sept 2022 at 07:37, Martin Davis wrote:
>
> I've started to build out operations on Polygonal Coverages in JTS ([1],
> [2]). These will be ported to GEOS (started here with CoverageValidator etc
> in C++ [3]). Hopefully these will be exposed in PostGIS as well (and of
> course other
On Mon, 13 Sept 2021 at 23:09, Sandro Santilli wrote:
>
> On Fri, Sep 10, 2021 at 04:03:39PM -0700, Paul Ramsey wrote:
> > We may have one last piece of functionality to add to 3.10 (new
> > triangulation code) and then will start the count-down to release. If
> > you've got work in progress
Hi list,
Apologies for bringing up a bug report on the mailing list, but I'd
love to get some more feedback on a rather scary regression I've found
on recent GEOS versions (https://github.com/libgeos/geos/issues/477)
In a nutshell, certain simple single-part linestrings magically become
On Fri, 31 Jul 2020 at 10:30, Daniel Baston wrote:
>>
>> What are people's thoughts on this? It is probably possible to build in the
>> old behaviour (with a bit of coding effort), and make it the default path.
>> But I think the new behaviour is preferable and more sensible.
>
>
> This
On Thu, 2 Jul 2020 at 01:12, Martin Davis wrote:
>
> On Tue, Jun 30, 2020 at 10:42 PM Nyall Dawson wrote:
>>
>> It's inspired by this question:
>> https://gis.stackexchange.com/questions/365901/finding-longest-straight-line-within-polygon-in-qgis
>> The routine
On Fri, 26 Jun 2020 at 23:35, Andrew Bell wrote:
>
> On Fri, Jun 26, 2020 at 2:25 AM Nyall Dawson wrote:
>>
>> On Fri, 26 Jun 2020 at 11:54, Martin Davis wrote:
>> >
>> >
>> >
>> > On Thu, Jun 25, 2020 at 6:02 PM Andrew Bell
On Fri, 26 Jun 2020 at 11:54, Martin Davis wrote:
>
>
>
> On Thu, Jun 25, 2020 at 6:02 PM Andrew Bell wrote:
>>
>> What is the real-life use-case for this? Are the lines that you're
>> projecting related to one another in some way? Related to the polygon in any
>> way?
>
>
> I'm curious about
gt; But there's room for further improvement. Reusing the index of the polygon
> edges would be improve performance. And given the simplicity of the single
> line segment, there might be a way to further reduce the number of edges of
> the polygon in a general way.
>
> On Wed, Jun 24, 20
Hi list!
I've a situation where I've got ~millions of lines (each consisting of
a single segment only) which I need to intersect against a complex
polygon.
Trying the naive way of multiple calls to GEOSIntersection_r gives
predictably horrendous performance. Is there a better way I can
approach
On Fri, 27 Dec 2019 at 23:38, Sandro Santilli wrote:
>
> On Mon, Dec 23, 2019 at 10:12:39AM +1000, Nyall Dawson wrote:
> > Hi list,
> >
> > Am I correct in concluding that GEOS_interruptRequest is only usable
> > in a single-threaded context? The method doesn't uti
Hi list,
Am I correct in concluding that GEOS_interruptRequest is only usable
in a single-threaded context? The method doesn't utilise a
GEOSContextHandle_t, and I can't see how GEOS would know which
operation to cancel if multiple operations are in place on different
threads...
Nyall
On Thu, 26 Sep 2019 at 07:34, Paul Ramsey wrote:
>
> If we are going to try and sneak 3.8 under the Pg12/PostGIS3 release, we
> should probably roll 3.8 out pretty darn fast. Thank you for triaging your
> tickets, we are down to a nice small list!
>
> https://trac.osgeo.org/geos/report/3
>
>
On Thu, 29 Aug 2019 at 03:42, Martin Davis wrote:
>>
>>
>>
>> > About the union question, probably no good news there, unless your data
>> > has some very unlikely characteristics. The GEOS Cascaded Union approach
>> > is remarkably efficient at unioning sets of overlapping polygons - which
any internal gaps which occur. You can then
> refine this by looking for segments which are nearly, but not exactly
> parallel. It would probably be nice to provide this as GEOS functionality at
> some point...
Thanks -- let me mull on that one!
Nyall
>
>
> [1] https://github.com/libg
Hey GEOS community!
I'm wondering if anyone has any sneaky/brilliant approaches on
speeding up GEOS operations with complex input geometries. Right now
I'm looking for a way to speed up a unary union operation with the
order of 100 input polygons, each of which is quite complex. I'm
currently
On Mon, 17 Dec 2018 at 04:08, Vicky Vergara wrote:
>
> More or less:
>
> C++14 adds to C++11:
>
> Relaxed constexpr constraints
> Generic lambdas (e.g., [](auto p) { return p*2; })
> Init-capture (e.g., [i = 2](auto p) { return p+i++; })
> Variable templates
> decltype(auto)
> Deduced return
On 4 September 2017 at 17:29, Sandro Santilli <s...@kbt.io> wrote:
> On Mon, Sep 04, 2017 at 04:28:32PM +1000, Nyall Dawson wrote:
>
>> However, after looking into this in more depth I think the original
>> python code is incorrectly used. It's being used by QGIS in orde
Hi list,
Quick question - is there any logic to the order of geometries in the
collection returned by calling GEOSDelaunayTriangulation?
I'm looking for a way to reliably associate the parts of the returned
collection with the original input nodes. Ideally I'd like to avoid
having to test for
21 matches
Mail list logo
