Sad yes GEOS doesn’t handle curves, and GIS people seem to not care.
Actually, that's quite the contrary. A number of people would love to
see GEOS handle curves. They are part of a number of official GIS data
models in Europe. But that would be a huge work undertaking. Would
probably require
Le 18/01/2023 à 18:02, Kurt Schwehr a écrit :
All,
Related... especially since the GDAL RFC is based on GEOS RFC 5
https://trac.osgeo.org/geos/wiki/RFC5
https://gdal.org/development/rfc/rfc68_cplusplus11.html
And where does PROJ say the C/C++ requirements?
==>
for what it's worth, neither GDAL nor PROJ have VS2015 testing any
longer, partly because maintaining a specific AppVeyor setup for that
was too painful.
Le 17/11/2022 à 13:28, Paul Ramsey a écrit :
I have no skin in the game, so I'm OK for dropping MSVC 2015 going forward...
for what that's
Le 18/10/2022 à 20:52, Martin Davis a écrit :
An interesting idea for sure.
Do you need only the area of the intersection?
Yes.
--
http://www.spatialys.com
My software is free, but my time generally not.
___
geos-devel mailing list
Hi,
While improving the sum resampling method of gdalwarp, to make it really
preserve the sums of pixel values accross the whole raster, I need to do
a lot of intersections of polygons, and get the area of the
intersection. Typically this involves 4 intersections for each target
pixel in a
Since C++11, std::sqrt() is required to have an integral overload. See
https://en.cppreference.com/w/cpp/numeric/math/sqrt
Looking at
https://github.com/google/sentencepiece/issues/432#issuecomment-639434698,
it seems this is a known defect of Solaris world
Using 5.0 should be a no-brainer
Paul,
I'd say you should add a deleted default copy constructor and assignment
operator in PolygonHull:
PolygonHull(const PolygonHull&) = delete;
PolygonHull& operator=(const PolygonHull&) = delete;
Even
Le 08/05/2022 à 01:11, Paul Ramsey a écrit :
Hi all,
I have again been
d 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 aga
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
I haven't laid out a scheme, I'd presume to borrow one from another old-school
project like GDAL or Proj and use that for our issue tags and issue tagging
process. Maybe Even or someone could point us to what's the state of the art in
their poject.
Really simple (but we don't use a lot
Hi,
as an occasional contributor, I'm fully supportive.
What is the intent of the "Web scraping the Trac ticket contents and
placing in a geos-old-tickets repo" ? (I assume you mean a github repo).
To have a "backup" of the Trac content that is easily browsable by
non-Trac users ? That
[Regina Obe]
I think GH has a mechanism for autogenerating sites triggered on commit or
using a GH action. Maybe we should ask gdal.org how they publish theirs for
guidance unless Paul already knows.
==> https://github.com/OSGeo/gdal/blob/master/gdal/doc/.azure-pipelines.yml
It is actually
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
$ pkg-config geos --libs-only-L
$ pkg-config geos --libs-only-l
-lgeos_c
$ pkg-config geos
Roger,
$ pkg-config geos --libs
-L/usr/local/lib -lgeos_c
which remains curious.
Check if you don't have a /usr/local/lib/pkgconfig/geos.pc file
and/or set PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
Hi Paul,
no impact for GDAL test suite. It tests MakeValid() in a very light way
(using mostly the "hourglass" looking invalid polygon)
Even
Le 19/04/2021 à 22:44, Paul Ramsey a écrit :
Important question for downstream maintainers: how wedded are you to
current 'makevalid' output? If you
On lundi 11 janvier 2021 10:09:58 CET Roger Bivand wrote:
> 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
> I'm pretty sure the majority of the above committers (also)
> use autotools, so the first motivation is not enough.
I'd be fine with a CMake-only build system.
https://travis-ci.org/github/uclouvain/openjpeg is an exemple of cmake used
with cross-compilation targets (mingw compiler with Linux
On mercredi 9 décembre 2020 12:13:17 CET Sandro Santilli wrote:
> I found out that GEOSMakeValid will remove EMPTY components from
> collections. The PostGIS implementation of it does not do this.
>
> The rationale was that a collection with EMPTY component is NOT
> invalid as per OGC
Sandro,
> I found out that GEOSMakeValid will remove EMPTY components from
> collections. The PostGIS implementation of it does not do this.
>
> The rationale was that a collection with EMPTY component is NOT
> invalid as per OGC specification, so why removing them ? Isn't
> that a job for
Hi,
Github is a proprietary trap, but not being on it as the
primary repository is just a waste of time and a lost battle.
Rationale: https://github.com/libgeos/geos/pull/
328#issuecomment-702390885
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
Hi Paul,
I gave a try to GEOS git head built with -DDISABLE_OVERLAYNG=OFF, and ran it
against
GDAL autotest suite.
The needed changes are in https://github.com/OSGeo/gdal/pull/2942
Most of them are boring, due to polygon vertices not being returned in the same
order, and
fixed by using
Hi,
> Yes, what Dan said is true.
>
> After updating clang that false positive is gone and the build is
> clean, but now a failure is accepted. Depending on useful it turns out
> to be I might do some grep-foo to just throw the errors and summary in
> the future.
I faced a similar issue with
Martin,
thanks for the hint. Let me mention alternatives :-)
For those who prefer QGIS, I suggest the QuickWKT plugin where you can paste
WKT or WKB.
If you select a feature (existing, or just created), copy and paste it in a
text application, you will get the WKT.
Otherwise (limited to WKT),
>it appears the osgeo/geos is no longer associated with travis.
Ah, I probably should have warned more loudly. Sorry for this. Due to the
upgrade to the paid plan, the OSGeo Travis account has been migrated to
travis-ci.com (anyway all projects even in the free tier will be migrated to
it
On vendredi 6 octobre 2017 17:03:58 CEST Regina Obe wrote:
> I'm only softly proposing this but want to get a feel if anyone has issues
> before we do.
>
> https://git.osgeo.org/gogs/geos/geos/pulls/14
>
> I would like to back port this pull to GEOS 3.6 and GEOS 3.5 branches.
>
> The reason
On jeudi 29 juin 2017 23:19:30 CEST Tamas Szekeres wrote:
> Dear developers,
>
> We have encountered thread safety issues when invoking the geos C api from
> multiple threads on a site with strong traffic.
>
> Specifically CLocalizer is using std::setlocale which is not thread safe. (
>
On jeudi 16 mars 2017 09:48:44 CET Bas Couwenberg wrote:
> On 2017-03-16 09:42, Sandro Santilli wrote:
> > On Thu, Mar 16, 2017 at 09:41:12AM +0100, Bas Couwenberg wrote:
> >> On 2017-03-16 09:38, Sandro Santilli wrote:
> >> >I don't know why JTS copyright holders wanted to "eclipse" their
> >>
Le mardi 25 octobre 2016 21:43:05, Jeff McKenna a écrit :
> On 2016-10-25 4:23 PM, Sebastiaan Couwenberg wrote:
> > On 10/25/2016 06:07 PM, Sandro Santilli wrote:
> >> - C++ API changes:
> >> - Automatic memory management for GeometryFactory objects
> >
> > This change seems to cause the
Le mercredi 27 janvier 2016 19:06:12, Jeff McKenna a écrit :
> Hello everyone,
>
> Compiling on Windows with Visual Studio 2008 I get the same errors with
> the 3.5.0 release, SVN trunk, and branch 3.5, but I can't find any
> mention of this problem in Trac or on this list. Here is the error:
>
--strk;
On Wed, Jun 18, 2014 at 06:52:58PM +0200, Sandro Santilli wrote:
On Wed, Jun 18, 2014 at 06:32:25PM +0200, Even Rouault wrote:
I've hit an integration problem with QGIS using the non _r API and
spatialite calling (accidently) finishGEOS() when closing a spatialite
DB, causing
Le mardi 17 juin 2014 23:07:52, Even Rouault a écrit :
Hi,
Currently it is difficult to ensure that ones code only uses the _r C API.
I would propose to put the 2 kind of API into 2 separate files.
geos_c_r.h would contain the _r C API only, and the few requirements
(typedefs, etc
Le mercredi 18 juin 2014 17:17:36, Paul Ramsey a écrit :
On Wed, Jun 18, 2014 at 3:24 AM, Even Rouault
even.roua...@mines-paris.org wrote:
Thinking more about this, for the sake of simplicity of user code of
GEOS, I'd rather suggest
geos.c.h:
#ifndef USE_ONLY_GEOS_R_API
Here go
Hi,
Currently it is difficult to ensure that ones code only uses the _r C API. I
would propose to put the 2 kind of API into 2 separate files.
geos_c_r.h would contain the _r C API only, and the few requirements
(typedefs, etc...) self sufficient so that libraries/applications using GEOS
33 matches
Mail list logo