Re: [geos-devel] RFC 9: Restore C++ API as public API

[Mateusz Loskot]

Regina,

The first and third statements in the second paragraph of your response is
false.
I have ever asked to "guarantee a stable C++ API at this point in time" or
at any point ever.
It's a fact.

The second statement in the second paragraph of your response is also false.
GEOS users can and do depend on the C++ API.
It's a fact.

The arguments you present show to me you're pursuing goals of a package
manager but not a programmer who wrote that code.
This brought incompatible toys in to the common sandbox.
You do not want to recognise it.

I'm not going to keep convincing you anymore.
I've run out of rational arguments.


Mateusz Loskot, mate...@loskot.net
(Sent from mobile)


P. S. There is really no need for the epithets


On Fri, 17 May 2019, 14:13 Regina Obe,  wrote:

>
>
> I'm a developer and a package manager (inside Google and somewhat still
> around for fink on mac)...
>
>
>
> I count on both the C and C++ APIs for many projects.  Projects needing
> ABI stability know they need to stick to C interfaces.
>
>
>
> For those of us packagers that "live at head" (well mostly...), we know
> that ABI stability is out the window and it's up to us to manage things
> carefully.
>
>
>
> I've been successfully doing C++ management with GEOS and GDAL for many
> years.  It seems reasonable for debian to only support C, but please don't
> rule out C++ for others.  For me, C++ APIs are radically better than C for
> large scale work (aka google) and I really really don't want more
> custom/external to the package C++ wrappers for C (with or without wrapping
> C++).
>
>
>
> http://schwehr.org
>
> *[Regina Obe] *
>
>
>
> I don't think we should discuss this any further until at least GEOS 3.8
> is out.  As we said the C++ API may drastically change in GEOS, so if you
> are relying on it – you should be SEVERELY warned.  We have not taken away
> your ability to use it, so I'm not sure what all the fuss is about here.
> We just want to discourage sharing it (via the unstable C++ API).  If you
> live on the head – you compile everything on the head so you can be as
> unstable as you want.
>
>
>
> We said the C++ API is unstable and we aren't willing to put in the effort
> to guarantee a stable C++ API at this point, so NO it is not a first class
> citizen.  Something you can't depend on is NOT a first class citizen.
> Maybe in the future but NOT NOW.
>
>
>
> If you want fancy C++ niceties go use Boost Geometry -  I hear their
> hipster C++ developers.
>
>
>
>
>
>
>
> Thanks,
>
> Regina
>
>
>
>
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-development



On Fri, 17 May 2019, 14:13 Regina Obe,  wrote:

>
>
> I'm a developer and a package manager (inside Google and somewhat still
> around for fink on mac)...
>
>
>
> I count on both the C and C++ APIs for many projects.  Projects needing
> ABI stability know they need to stick to C interfaces.
>
>
>
> For those of us packagers that "live at head" (well mostly...), we know
> that ABI stability is out the window and it's up to us to manage things
> carefully.
>
>
>
> I've been successfully doing C++ management with GEOS and GDAL for many
> years.  It seems reasonable for debian to only support C, but please don't
> rule out C++ for others.  For me, C++ APIs are radically better than C for
> large scale work (aka google) and I really really don't want more
> custom/external to the package C++ wrappers for C (with or without wrapping
> C++).
>
>
>
> http://schwehr.org
>
> *[Regina Obe] *
>
>
>
> I don't think we should discuss this any further until at least GEOS 3.8
> is out.  As we said the C++ API may drastically change in GEOS, so if you
> are relying on it – you should be SEVERELY warned.  We have not taken away
> your ability to use it, so I'm not sure what all the fuss is about here.
> We just want to discourage sharing it (via the unstable C++ API).  If you
> live on the head – you compile everything on the head so you can be as
> unstable as you want.
>
>
>
> We said the C++ API is unstable and we aren't willing to put in the effort
> to guarantee a stable C++ API at this point, so NO it is not a first class
> citizen.  Something you can't depend on is NOT a first class citizen.
> Maybe in the future but NOT NOW.
>
>
>
> If you want fancy C++ niceties go use Boost Geometry -  I hear their
> hipster C++ developers.
>
>
>
>
>
>
>
> Thanks,
>
> Regina
>
>
>
>
> ___
> 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] RFC 9: Restore C++ API as public API

[Mateusz Loskot]

On Fri, 17 May 2019 at 08:36, Sebastiaan Couwenberg  wrote:
> On 5/17/19 3:23 PM, Andrew Bell wrote:
> > Frequent, breaking API changes seem a problem. ABI changes seem more like a
> > small annoyance. I can understand how a stable ABI would be nice, but I
> > personally don't think it's more important than a good interface for
> > library users.
>
> And that's the difference in perspective between a developer and
> distribution packager.

It is not my role of a library developer to make packaging easier.
There are many PMs and PDMs, OS-specific, distro-specific
as well as number of OS-agnostic ones. It is not a library developer
role to promise an easy life to maintainers of any of the PMs/PDMs.
It would be a sisyphean task.

Since day one, GEOS has been a C++ library.
Since version 2.2, GEOS offers C API.
Since version 3.6, things started shifting in a direction that transforms
the library, departing from the original concept.
It dents the trust inside the team (what else will get hastily broken?).

It's those who support the intrusive transformation should have forked
GEOS and make their way, not those who want to maintain GEOS
according to the original concept.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] RFC 9: Restore C++ API as public API

[Mateusz Loskot]

Dear All,

I'd like propose to effectively revert the RFC 6:

https://trac.osgeo.org/geos/wiki/RFC9

I'll appreciate if the PSC members considered to review my proposal
and arranged the voting.

Although I've made my best to prepare the write short,
clear and unambiguous proposal, I'll welcome your feedback.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [PSC] Commit access removal

[Mateusz Loskot]

On 2 October 2017 at 13:00, Sandro Santilli <s...@kbt.io> wrote:
> On Mon, Oct 02, 2017 at 12:20:22PM +0200, Mateusz Loskot wrote:
>> On 2 October 2017 at 11:57, Sandro Santilli <s...@kbt.io> wrote:
>> > On Mon, Oct 02, 2017 at 10:34:24AM +0200, Mateusz Loskot wrote:
>>
>> My policy is to always return any unused keys, also for security reason.
>
> I've removed osgeo userid `mloskot` from the `geos` LDAP group [1]
> and from the `core-committers` Gogs GEOS Team [2].
> Committers wiki page was updated too [3].
>
> Thanks for flying with us !

Thanks Sandro!

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [PSC] Commit access removal

[Mateusz Loskot]

On 2 October 2017 at 11:57, Sandro Santilli <s...@kbt.io> wrote:
> On Mon, Oct 02, 2017 at 10:34:24AM +0200, Mateusz Loskot wrote:
>
>> Following the procedure outlined in RFC2:
>>
>> I'd like to give up my privilege of write and commit access
>> to GEOS repositories.
>> Please, remove OSGeo ID mloskot from the committers.
>
> May I ask you why you came to this decision ?

Significant difference of opinions.

> I mean, you can always just not use your powers if you
> don't feel like, why giving back the key ?

My policy is to always return any unused keys, also for security reason.

If I ever arrive with any patch for GEOS, I will use PRs.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] [PSC] Commit access removal

[Mateusz Loskot]

Dear PSC,

Following the procedure outlined in RFC2:

I'd like to give up my privilege of write and commit access to GEOS
repositories.
Please, remove OSGeo ID mloskot from the committers.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [postgis-devel] RFC6 - Drop GEOS C++ API at GEOS 3.8

[Mateusz Loskot]

On 2 October 2017 at 10:08, Regina Obe <l...@pcorp.us> wrote:
> On 2 October 2017 at 09:30, Bas Couwenberg <sebas...@xs4all.nl> wrote:
>> On 2017-10-02 09:13, Mateusz Loskot wrote:
>>>>
>>>> As Bas said already it causes packagers headaches.
>>>
>>> So, the solution is to take the toys away from the kids...
>>>
>>>
>>> Please help us understand your point of view. Why do you want to keep
>>> the
>>> C++ API?
>
>> Please, don't try to help me solve my problems.
>> Those are orthogonal to the matter discussed here.
>
> They are not orthogonal when your use is hurting me.
> At that point you've made your problem my problem and I need to solve yours 
> to solve mine.

I only ask to keep deploying all GEOS headers and libraries, that's it.

You think that is dangerous because some projects may prefer to stick
to C++ API,
so you want to prevent them from such freedom of choice.

Please, consider me out of this discussion.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [postgis-devel] RFC6 - Drop GEOS C++ API at GEOS 3.8

[Mateusz Loskot]

On 2 October 2017 at 09:30, Bas Couwenberg <sebas...@xs4all.nl> wrote:
> On 2017-10-02 09:13, Mateusz Loskot wrote:
>>>
>>> As Bas said already it causes packagers headaches.
>>
>> So, the solution is to take the toys away from the kids...
>
>
> Please help us understand your point of view. Why do you want to keep the
> C++ API?

Please, don't try to help me solve my problems.
Those are orthogonal to the matter discussed here.

Since day one, GEOS was C++ library. Fullstop.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [postgis-devel] RFC6 - Drop GEOS C++ API at GEOS 3.8

[Mateusz Loskot]

-1 (as used-to-be-PSC)

> As Bas said already it causes packagers headaches.

So, the solution is to take the toys away from the kids...


Regards,
Mateusz



On 2 October 2017 at 04:49, Regina Obe <l...@pcorp.us> wrote:
> Okay I have created an RFC6 to officially drop GEOS C++ starting at GEOS 3.8  
> (so as soon as we release GEOS 3.7 (which should be next month), and flip the 
> switch, we drop the C++ headers as well so developers won't be tempted to use 
> them.
>
> https://trac.osgeo.org/geos/wiki/RFC6
>
>
> As Bas said already it causes packagers headaches.  It causes PostGIS 
> headaches because users can't easily migrate to newer versions of GEOS 
> because the packages they rely on e.g osm2pgsql (which is going away because 
> we broke ABI with C++ aPI between 3.5 and 3.6).
>
> If we can't support something, let's not provide it period.  It's disservice 
> to everybody.
>
> I know Sandro you think making it noisy would solve the issue.  Trust me it 
> won't.  There is so much noise with all dependencies people compile with that 
> most developers are trained to ignore them.
> The proof to them is it compiles and passes their tests.  Unless of course 
> you plan to introduce noise in production build, which makes GEOS useless 
> anyway.
>
>
> It is my understanding that only osm2pgsql (which is dropping GEOS anyway) 
> and osmium which has already dropped GEOS, were the only big projects using 
> the C++ API.  Lets not leave it in as that will just leave the whole open for 
> newer projects to start using it.
>
>
> As GEOS PSC member I vote +1 for dropping GEOS C++ API.
>
>
> Thanks,
> Regina
>
>
>
>
>
> ___
> postgis-devel mailing list
> postgis-de...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel



-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [postgis-devel] GEOS C++ API deprecated? (was: PostGIS 2.5 what should be minimum requirements?)

[Mateusz Loskot]

On 1 October 2017 at 22:17, Sebastiaan Couwenberg <sebas...@xs4all.nl> wrote:
> On 10/01/2017 10:05 PM, Mateusz Loskot wrote:
>> On 1 October 2017 at 21:47, Sebastiaan Couwenberg <sebas...@xs4all.nl> wrote:
>>> On 10/01/2017 09:33 PM, Mateusz Loskot wrote:
>>>> Unless, Sandro, your aim is to eventually mark C++ API deprecated
>>>> and stop installing C++ API libraries and headers.
>>>>
>>>> That will require RFC and that is what I'm debating about.
>>>
>>> To end this debate once and for all,
>>
>> Mind you, that does not ends anything, it starts it.
>
> Yes, you seem to want to keep this debate alive.

Sandro's answer has just finished it to me.

Please, accept my apologies for the continued annoyance,
could have been killed earlier by Sandro's earlier response.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [postgis-devel] GEOS C++ API deprecated? (was: PostGIS 2.5 what should be minimum requirements?)

[Mateusz Loskot]

On 1 October 2017 at 22:17, Sandro Santilli <s...@kbt.io> wrote:
> On Sun, Oct 01, 2017 at 10:05:43PM +0200, Mateusz Loskot wrote:
>
>> I only ask Sandro, as the GEOS leader/PSC member to answer one question:
>>
>> Do you plan to practically deprecate GEOS C++ API and stop installing
>> GEOS C++ headers?
>
> I don't have such plan

Sandro,

Thank you!

> , but it could be an idea to make it more
> noisy to use (like print a warning at compile time) or harder to
> install (like a ./configure switch to do so).

To me, you could even stick  "If you use GEOS C++ API, you are an idiot"
on the front page. It does not matter.
What matters is (was) the use of word deprecate.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [postgis-devel] GEOS C++ API deprecated? (was: PostGIS 2.5 what should be minimum requirements?)

[Mateusz Loskot]

On 1 October 2017 at 21:47, Sebastiaan Couwenberg <sebas...@xs4all.nl> wrote:
> On 10/01/2017 09:33 PM, Mateusz Loskot wrote:
>> Unless, Sandro, your aim is to eventually mark C++ API deprecated
>> and stop installing C++ API libraries and headers.
>>
>> That will require RFC and that is what I'm debating about.
>
> To end this debate once and for all,

Mind you, that does not ends anything, it starts it.

> I'd love for the C++ API to be officially deprecated and no longer installed 
> soon after.

As member of GEOS development team, I'm deeply concerned about
taking such comments seriously, by rest of GEOS team.

> As long as libgeos is provided alongside libgeos_c, C++ projects will be 
> tempted to
> keep using it.

So what.

> And from my perspective as a package maintainer, I would
> like for those projects to stop doing that and have them all use the C
> API instead.

Just stop accepting such GEOS-based software for packaging
and keep nagging authors of such projects to switch to GEOS C API,
but do not delegate your problem to GEOS.
It is not GEOS problem that someone uses GEOS C++ API.
GEOS is C/C++ library.

Having said enough, I'm not going to participate in the debate any longer.

I only ask Sandro, as the GEOS leader/PSC member to answer one question:

Do you plan to practically deprecate GEOS C++ API and stop installing
GEOS C++ headers?

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] GEOS C++ API deprecated? (was: PostGIS 2.5 what should be minimum requirements?)

[Mateusz Loskot]

On 1 October 2017 at 20:47, Sandro Santilli <s...@kbt.io> wrote:
> On Sat, Sep 30, 2017 at 09:26:42PM +0200, Mateusz Loskot wrote:
>> /topic changed
>> /cc geos-devel
>>
>> On 30 September 2017 at 20:47, Greg Troxel <g...@lexort.com> wrote:
>
>> >   ### Using the C++ interface (discouraged)
>> >
>> >   NB: The C++ interface should not be used directly; the GEOS project
>> >   views it as a bug for another program to use the C++ interface or even
>> >   to directly link against the C++ library.
>> > [...]
>
>> > Mateusz Loskot <mate...@loskot.net> writes:
>>
>> Moreover, this paragraph has no rights to be there or in any official
>> GEOS writing.
>> I'm very surprised Sandro allowed it in - I assume a merge in rush.
>
> Maybe "a bug" is too much, but the "discouraged" label is important.
> We don't want client software to use the C++ API,

So, we decide for clients?
Clients are warned, we don't care what API they decide to use.

> and you see the reason today (GEOS is kept back in Debian because a client 
> used the
> C++ API).

So what? It's still ac client's authors freedom to decide.
If they use the C++ API despite the no stability promise policy,
and they packaged it for a distro, perhaps authors of the software
should not be doing what they are doing if they don't care about
reading the basic info about the library they use.

>> Finally, even if GEOS C++ API was/is marked as deprecated, then I ask
>> where is the RFC, where is the PSC voting the motion,
>> where is the public announcement?
>
> Idea was announced here:
> https://lists.osgeo.org/pipermail/geos-devel/2005-April/001375.html
>
> Work was announced here:
> https://lists.osgeo.org/pipermail/geos-devel/2005-September/001574.html
>
> First release and recommendation to avoid C++ API was here:
> https://lists.osgeo.org/pipermail/geos-devel/2005-November/001619.html

Those are not related to this particular discussion.
Those are about developing the C API, but its introduction had not
deprecated anything. It just made life of developers easier.

> I'm not aware of any motion to explicitly mark C++ API as "deprecated"
> but as it's effectively not maintained, it is continuosly "deprecated".

The C++ API is maintained, but every new release introduces new C++ API
and saying it is becoming deprecated is incorrect.

Unless, Sandro, your aim is to eventually mark C++ API deprecated
and stop installing C++ API libraries and headers.

That will require RFC and that is what I'm debating about.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] GEOS C++ API deprecated? (was: PostGIS 2.5 what should be minimum requirements?)

[Mateusz Loskot]

/topic changed
/cc geos-devel

On 30 September 2017 at 20:47, Greg Troxel <g...@lexort.com> wrote:
> Mateusz Loskot <mate...@loskot.net> writes:
>
>>> There isn't agreement about whether it is a bug for packages to use the
>>> GEOS C++ API.  If it really is a bug, GEOS is buggy for installing the
>>> headers.
>>
>> Please, can we stop this heresy?
>> I'm tired of explaining GEOS C++ API status.
>
> So do you agree with this, taken from the geos README (in 3.6.2):
>
>   ### Using the C++ interface (discouraged)
>
>   NB: The C++ interface should not be used directly; the GEOS project
>   views it as a bug for another program to use the C++ interface or even
>   to directly link against the C++ library.
> [...]
>
> Or do you think something else?

Greg,

No, I don't agree with this.

Moreover, this paragraph has no rights to be there or in any official
GEOS writing.
I'm very surprised Sandro allowed it in - I assume a merge in rush.

It sneaked in (unnoticed) via [1] as follow-up to this thread [2] on geos-devel
which had not received any response declaring C++ API as deprecated
or even no response that uses word 'deprecate'.
Sandro clearly stated, C++ API users are warned [3].

Five years later, I answered the same question [4]:
"GEOS C++ API is not an internal API, but a public yet supported API
offered by GEOS."
and Sandro, as the project leader, had not arrived with any corrections.

Finally, even if GEOS C++ API was/is marked as deprecated, then I ask
where is the RFC, where is the PSC voting the motion,
where is the public announcement?


> It genuinely seems to me that there are multiple opinions out there.

It is not a matter of an opinion, but a fact.


[1] https://trac.osgeo.org/geos/ticket/553
[2] https://lists.osgeo.org/pipermail/geos-devel/2017-January/007652.html
[3] https://lists.osgeo.org/pipermail/geos-devel/2012-June/005861.html
[4] https://lists.osgeo.org/pipermail/geos-devel/2017-January/007653.html

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] GEOS 3.7.0 beta end this week

[Mateusz Loskot]

On 10 Sep 2017 1:37 am, "Regina Obe"  wrote:

I thought we were going to wait for that change in GEOS 3.8 but I see you
guys have started already.



Or tag/branch master at last commit before first C++11 change.

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

[geos-devel] [clang-tidy] modernize-use-nullptr and modernize-use-override

[Mateusz Loskot]

FYI,

(Part of GEOS RFC 5: C++11 Compilation Mode)

I have made two biggish commits in master
applying clang-tidy refactoring fixes for
modernize-use-nullptr [1] and modernize-use-override [2]

There might be places left out that would benefit from similar changes.

I would also suggest to use the two C++11 keywords in any new code
written, especially override in heavily OOP codebase makes
wonders for override/overload run-time bugs prevention.

[1] 
https://git.osgeo.org/gogs/geos/geos/commit/6f0c2bac087180369760e9fed244bb797582a3b2
[2] 
https://git.osgeo.org/gogs/geos/geos/commit/b7101be6533a1273f715a3309889c23b7ae02e4f

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Can we deprecate GeometryList class?

[Mateusz Loskot]

On 6 September 2017 at 21:13, Mateusz Loskot <mate...@loskot.net> wrote:
>
> AFAICT, GeometryList class is not used anywhere.
>
> Can we ditch the class completely?

FYI, GeometryList class has been ditched.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] Reviewing std::auto_ptr spaghetti

[Mateusz Loskot]

Hi,

In C++, well-established patterns when/how to use std::auto_ptr are:

void sink(std::auto_ptr p);
std::auto_ptr source();

TL;TR: Is it safe to assume GEOS follows the patterns?


In the code, there are uses of std::auto_ptr that are hard to reason about
what makes me suspicious:

class T
{
  auto_ptr items;
public
auto_ptr getItems()
{
return items;
}
};

Is the intention to give up the object's internal resource, really?

For example, in LineSegmentVisitor and possibly (lot) more places.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] GEOS 3.7.0 release in 2 weeks

[Mateusz Loskot]

On 1 September 2017 at 17:31, Regina Obe <l...@pcorp.us> wrote:
>
> Now for GEOS 3.8 I think we'll probably want an alpha since
> I think Mateusz wants to do some major refactoring and up the required GCC to 
> 4.8.

GEOS has accepted to require C++11 [1] as minimum C++ standard.
It means, we are free to use C++11 features in the codebase;
replace deprecated std::auto_ptr with std::unique_ptr and std::shared_ptr, etc.

Although RFC 5 opens the road to C++ modernization,
I don't plan any big refactoring though
If things change, they will change gradually.


[1] https://trac.osgeo.org/geos/wiki/RFC5

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Accompanying .editorconfig with .gitattributes?

[Mateusz Loskot]

Ok, dropped

-- 
Mateusz Łoskot

On 29 Aug 2017 22:43, "Regina Obe" <l...@pcorp.us> wrote:

> Forget my +1 earlier.  -1 one I change to -1 :)
>
>
>
> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Sandro Santilli
> Sent: Tuesday, August 29, 2017 4:10 PM
> To: GEOS Development List <geos-devel@lists.osgeo.org>
> Subject: Re: [geos-devel] Accompanying .editorconfig with .gitattributes?
>
> On Tue, Aug 29, 2017 at 05:56:17PM +0200, Mateusz Loskot wrote:
> > Hi,
> >
> > Since .editorconfig now forces LF/CRLF per file type in the codebase,
> > wouldn't it be a good idea to add .gitattributes with explicit eol=
> > specification per file type too?
> >
> > This would ensure git checkout/commit does not re-convert line endings
> > differently than as expected by .editorconfig.
>
> I still hadn't fully understood .gitattributes but I think with PostgGIS
> it was the culprit for the conversion (ie: getting rid of .gitattributes
> stopped performing conversions).
>
> On the contrary, .editorconfig only affects *editors*.
>
> Are you seeing automatic conversions on checkout/commit under GEOS ?
>
> --strk;
> ___
> 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

[geos-devel] Accompanying .editorconfig with .gitattributes?

[Mateusz Loskot]

Hi,

Since .editorconfig now forces LF/CRLF per file type in the codebase,
wouldn't it be a good idea to add .gitattributes with explicit
eol= specification per file type too?

This would ensure git checkout/commit does not re-convert line endings
differently than as expected by .editorconfig.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] Renaming svn-trunk branch to master (#822)

[Mateusz Loskot]

Hi,

I'll be working on renaming the git branches
https://trac.osgeo.org/geos/ticket/822

The plan is to rename, break, fix.

My apologies for inconvenience.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] github mirror broken by protected branches

[Mateusz Loskot]

On 11 April 2017 at 07:14, Sandro Santilli <s...@kbt.io> wrote:
> Someone enabled protected branches on GitHub,

That someone was me, you are aware of it.

> but this breaks mirroring. Please disable protected branches,

Done

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Breeding .editorconfig is bad

[Mateusz Loskot]

On 7 April 2017 at 13:35, Sandro Santilli <s...@kbt.io> wrote:
> On Fri, Apr 07, 2017 at 01:04:00PM +0200, Mateusz Loskot wrote:
>
>> Often, single file contains bits in styles and such scoped .editorconfig
>> will lead to commits mixing actual (logic/behaviour) code change
>> with code formatting changes. Unacceptable!
>
> I agree it is unacceptable to mix logic and style changes in
> the same commit.
>
> Also and I think we should minimize style changes as much as possible,
> which was the rationale for my adding per-directory .editorconfig.

Mind you, I did not apply any of the style changes.
The .editorconfig-driven editor did.

>> See the problem in action here:
>> https://github.com/OSGeo/geos/pull/81/files
>
> Could you briefly explain the problem we're seeing there ?
> Is it the removal of trailing blank spaces ?

eg. EOL code, insert new line.

> The way I've been addressing those cases has been first committing
> removal of trailing blank spaces and then committing a separate
> funtional change.

Are you being serious?
I rename a variable, editor reformats 100-s of LOCs on save, then you ask to
stash/revert-fiddle with my change, commit the style, then re-apply my change
and make separate commit?

First, tell me it's a joke.
Second, despite your objection to the RFC4, you do agree to apply big reformats.

>> My call, again, is to stop it and get rid of any spaces/indentation settings
>> in .editorconfig for as long as we don't get the code reformatted into
>> desired style.
>> Alternatively, please, make your editors ignore .editorconfig completely
>> and manually align with coding style as presented in actual file being 
>> edited.
>> That's what I'm going to do.
>
> If the problem is the one I described above there's no "pre-existing
> coding style" to be preserved. It's just that someone added too many
> blanks at the end of lines.

No, it's just there was freedom of styles from day one.
You also fiddled with 4 spaces, 2 spaces, then switched to tabs.
The current style is mixture.

> Note that `git diff --check` can do the trailing blanks check for you
> before it's committed.
>
> Please do not ignore .editorconfig as it's aimed to *reducing* the
> proliferation of code styles.

You do not listen. The code styles has been proliferating for decade+,
it is there.

I understand you refuse to use clang-format, but I can't understand why
you agree on .editorconfig to sneak style reformats.
Let's leave things as they are, do nothing.

> I've run a check under src/ and include/
> some days ago and found that only a single file is not using tabs
> (namely the CLocalizer class files introduced by Sean Gillies in 2008)

There is much, much more, eg.
https://github.com/OSGeo/geos/commit/6449265b48637fc94b8d91a034162fb01928d880

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Ready to switch from SVN to GIT ?

[Mateusz Loskot]

On 7 April 2017 at 13:26, Sandro Santilli <s...@kbt.io> wrote:
> On Fri, Apr 07, 2017 at 01:12:42PM +0200, Mateusz Loskot wrote:
>
>> approach based on suggesting/requesting to join SAC and join admin efforts
>> or join gogs/gitea and contribute, whenever someone expresses interest or
>> makes a feature request to SAC is not an acceptable policy.
>
> Why not ?
> OSGeo is a non-profit organization walking on the legs of its members.
> I find it perfectly acceptable to stimulate partecipation.

Because the stimulation has already reached level of annoyance.

If developers of OSGeo projects are being pulled down every time they
pass trenches of SAC,
they will quickly change routes and solve their admin problems
differently (eg. moving out).

Majority of the community members are perfectly aware who and what drives OSGeo
and if anyone has time, experience/knowledge and will to volunteer,
they do/will help. If nobody shows up, despite the clear advertisement
(ei. foundation/about.html, foundation_faq.html, wiki/Volunteers_Needed),
it means nobody can or want to help.

> As I'd really like for that service to continue, I campaign for growing
> the volunteers base.
> I think this is perfectably acceptable.

Forgive me, but it's long no longer a campaign, but delegating and
setting obstacles.
Starting with mantra case, I have received at least 4-5
close-to-unpleasant comments like
you want me to read the instructions? First, stop making it so
difficult to submit a bug report.
Second case, where is the Trac XML RPC plug-in I asked to install, I
asked who to ask,
next I'm going to ask who to found a bounty, shall I?
Mind you, I need the plug-in to actually do **volunteer** for OSGeo?
Mind you, no coordinators, SAC PSC members, nobody answered even
basic: Sorry, no manpower, can't be done.
That is Catch 22!

If there is nobody to admin OSGeo infrastructure, then OSGeo should
not run any infrastructure.

Keeping to annoy people won't solve anything for us.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Ready to switch from SVN to GIT ?

[Mateusz Loskot]

On 7 April 2017 at 11:41, Sandro Santilli <s...@kbt.io> wrote:
> On Thu, Apr 06, 2017 at 05:17:04PM -0400, Regina Obe wrote:
>
>> That said I only work for free on projects I contribute to and/or am
>> emotionally attached to.  If it helps OSGeo that's good.
>> If I'm getting paid for it to ensure it helps OSGeo, then I'd happily do it.
>
> I suggest you join the SAC mailing list and state your interest in
> the activities. I'd really love to see the SAC team grow !

Sandro, we certainly are free to activate ourselves in whatever areas
we like, but,
approach based on suggesting/requesting to join SAC and join admin efforts
or join gogs/gitea and contribute, whenever someone expresses interest or
makes a feature request to SAC is not an acceptable policy.

Although I perfectly understand (and often agree with) your motivation,
such attitude will make more harm than good.
It certainly won't help to justify self-hosted OSGeo infrastructure to
the Community.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] Breeding .editorconfig is bad

[Mateusz Loskot]

Hi,

Recently, I've been arguing with Sandro, that breeding .editorconfig
file per folder is a bad idea.

The rationale was this:
- if files in a directory use different (en)coding style than the one
specified in .editorconfig,
- then, create .editorconfig in such directory with settings matching
the style of directory.
Purpose of that was to automate cultivation of the current mixture of
code formatting/styles.

I objected this practice and tried to avoid the multitude of .editorconfig's
Often, single file contains bits in styles and such scoped .editorconfig
will lead to commits mixing actual (logic/behaviour) code change
with code formatting changes. Unacceptable!

See the problem in action here:

https://github.com/OSGeo/geos/pull/81/files

My call, again, is to stop it and get rid of any spaces/indentation settings
in .editorconfig for as long as we don't get the code reformatted into
desired style.
Alternatively, please, make your editors ignore .editorconfig completely
and manually align with coding style as presented in actual file being edited.
That's what I'm going to do.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Ready to switch from SVN to GIT ?

[Mateusz Loskot]

On 6 April 2017 at 23:17, Regina Obe <l...@pcorp.us> wrote:
>> Another problem w/ maintaining OSGeo-hosted infrastructure is lack of admins 
>> even remotely interested in getting a contract.
>> Year ago Sandro, if I'm correct, pioneered sysadmins contracting for OSGeo 
>> (https://lists.osgeo.org/pipermail/sac/2016-May/007032.html).
>> Year later... I have expected there would be more (actually, a lot) people 
>> within OSGeo community interested in hugging 5000 EUR for 50 hours job.
>> Sandro has done great job, he's also shown the value of sysadmins, capacity 
>> of OSGeo budget in action, but we need Sandro x 5 at least.
>
>> Nobody has come forward really. Why? I think we know :-)
>
> This is the first I'm hearing of this.  So my reason would be not lack of 
> interest but because it wasn't offered as an option.
> How many people in OSGeo community even know about such an offer?

I don't know.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Ready to switch from SVN to GIT ?

[Mateusz Loskot]

On 6 April 2017 at 22:46, Sandro Santilli <s...@kbt.io> wrote:
> On Thu, Apr 06, 2017 at 10:32:07PM +0200, Mateusz Loskot wrote:
>
>> Drone has zero value.
>
> At this very moment "Dronie" is the only green badge we have here:
> https://trac.osgeo.org/geos/
>
> But as Travis is also green in the README.md of trunk maybe the
> wiki suffered by the move of GitHub URL.
> Could you please fix that ?

Yup, fixed.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Ready to switch from SVN to GIT ?

[Mateusz Loskot]

On 6 April 2017 at 16:05, Sandro Santilli <s...@kbt.io> wrote:
> On Thu, Apr 06, 2017 at 03:59:21PM +0200, Mateusz Loskot wrote:
>
>> Anyhow, I am going to use GitHub (and PRs) as the primary
>> channel for commits, to allow myself the advantage of pre-factum CI..
>
> Pre-factum CI is currently also available via Gogs, although more
> convoluted (it takes explicitly adding your fork to the drone install,
> and then to link the badge to the PR summary).

Convoluted, indeed.

> From what I've heard new Drone instances will also support automatically
> building PRs, droping one of the two requirements listed above. Currently
> drone server is running on my own machines, I'd love to move it to OSGeo
> machines with its own DNS, want to help with that ?

Drone is rather an interesting addition, not something to rely on, from my POV.
It does not support builds on Windows. I'm not even sure it supports
builds on OS X.
(I mean 'guest' OS, not host).

> NOTE: I know your answer to the above question will likely be NO, because
> you prefer to use external working infrastructure, but I'll keep asking
> everyone in the hope to find somebody willing to help with improving the
> available infrastructural free software out there :)

If I had more/too much time/money, I might have considered it.
Tiny projects like GEOS, non-profits like OSGeo simply
can not afford investment in developing its infrastructure at low-level.
What's next, burning our own CPUs because Intel and AMD are proprietary?

I'll repeat myself, GitHub-based ecosystem is the only cost-effective solution
available for not-so-rich non-profits.
IMHO, GitLab with GitLab CI with its shared runners is the only
sensible alternative.
but still it will require lots of admin investment.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Ready to switch from SVN to GIT ?

[Mateusz Loskot]

On 6 April 2017 at 15:05, Sandro Santilli <s...@kbt.io> wrote:
> On Thu, Apr 06, 2017 at 11:47:25AM +0200, Mateusz Loskot wrote:
>> On 6 April 2017 at 11:39, Sandro Santilli <s...@kbt.io> wrote:
>
>> > This was the plan since February 2016:
>> > https://lists.osgeo.org/pipermail/geos-devel/2016-February/007404.html
>>
>> A plan rolling for year(s) is a plan to be ignored/forgotten about.
>
> Well, I hadn't forgotten. It's easy to upvote a proposal, not as easy
> to put it in practice. It took that much time for me.

I meant, I have.

>> >  2) We don't have to migrate wiki
>>
>> The whole Wiki should be moved to reST/Markdown file sin /docs folder,
>> easily to browse and read w/ Web,
>> easy to update (commit or pull request if one doesn't have access).
>
> I suggest looking for a Trac plugin to make that possible to do
> incrementally.

As you know, I am going to try automate the process.
Hence my request in https://trac.osgeo.org/osgeo/ticket/1903

> Or you could contribute to the
> migration tool to also import wiki:
> http://strk.kbt.io/projects/go/trac2gogs/

No, I don't plan to import/export Wiki.
The Wiki needs to be moved manually into flat files as docs.
In terms of collaborative writing, there is no difference between Wiki vs Git.
In terms of docs disintegration, the difference is clear. Wiki should go
or be used exclusively as scratchpad.

Once that is done, we can think of re-building GEOS website
with proper docs, etc. (see PROJ.4, PDAL as examples).

>> >  3) I can keep replying to trac tickets by mail
>> > (https://strk.kbt.io/blog/2015/11/11/trac-from-mutt/)
>> >  4) We get proper notifications upon ticket comments
>> > (Gogs is still short on features with this)
>> >  5) We get spam filtering (lacking in Gogs)
>>
>> Grr! I had been proposing switch to GitHub to save us a lot of time,
>> and things actually done/working .
>
> You can save a lot of time by not doing any migration
> (as we're doing now). Let me know what makes you waste
> time while working with Trac, so maybe we can improve that.

The GitHub vs others debate is a waste of time,
we choose the latter gaining zero technological advantage.

Anyhow, I am going to use GitHub (and PRs) as the primary
channel for commits, to allow myself the advantage of pre-factum CI..

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Ready to switch from SVN to GIT ?

[Mateusz Loskot]

On 6 April 2017 at 11:39, Sandro Santilli <s...@kbt.io> wrote:
> On Thu, Apr 06, 2017 at 02:27:26AM -0700, Mateusz Loskot wrote:
>>
>> I wasn't aware we are going to stick to Trac. PIT(Y|A).
>
> This was the plan since February 2016:
> https://lists.osgeo.org/pipermail/geos-devel/2016-February/007404.html

A plan rolling for year(s) is a plan to be ignored/forgotten about.

> I actually think it's much less pain this way as:
>
>  1) We don't have to migrate all tickets

Is that an obstacle really?
You have already written a tool, haven't you?

>  2) We don't have to migrate wiki

The whole Wiki should be moved to reST/Markdown file sin /docs folder,
easily to browse and read w/ Web,
easy to update (commit or pull request if one doesn't have access).

We already have to maintain README.md and Wiki...

>  3) I can keep replying to trac tickets by mail
> (https://strk.kbt.io/blog/2015/11/11/trac-from-mutt/)
>  4) We get proper notifications upon ticket comments
> (Gogs is still short on features with this)
>  5) We get spam filtering (lacking in Gogs)

Grr! I had been proposing switch to GitHub to save us a lot of time,
and things actually done/working .

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Ready to switch from SVN to GIT ?

[Mateusz Loskot]

Mateusz Loskot wrote
> On 4 April 2017 at 23:58, Regina Obe 

> lr@

>  wrote:
>> As a core maintainer, does it really matter so much to you whether you
>> make your commits to Gogs or Github?
> 
> No, it does not.

I wasn't aware we are going to stick to Trac. PIT(Y|A).






--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Ready-to-switch-from-SVN-to-GIT-tp5315643p5316081.html
Sent from the GEOS Developers mailing list archive at Nabble.com.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] github.com/libgeos vs github.com/OSGeo ?

[Mateusz Loskot]

On 5 April 2017 at 22:33, Sandro Santilli <s...@kbt.io> wrote:
> On Wed, Apr 05, 2017 at 10:07:59PM +0200, Mateusz Loskot wrote:
>
>> Next, I'd like to transfer
>>
>> https://github.com/libgeos/libgeos -> https://github.com/OSGeo/geos
>>
>> Do we agree?
>
> Will old git remotes still work transparently ?
> Will old url be redirected to new ?

AFAIU, the answer is yes.

After a repository transfer [1]:

- If the transferred repository has any forks, then those forks will
remain associated with the repository after the transfer is complete.
- All links to the previous repository location are automatically
redirected to the new location.

After repository rename [2]:

- In addition to redirecting web traffic, all git clone, git fetch, or
git push operations targeting the previous location will continue to
function as if made on the new location.
- However (...) we strongly recommend updating any existing local
clones to point to the new repository URL.

[1] https://help.github.com/articles/about-repository-transfers/
[2] https://help.github.com/articles/renaming-a-repository/


>> Then, the mirror updating scripts will need to be updated.
>> Could you do that Sandro?
>
> If it doesn't need to be done immediately/contextually, sure.

No rush, I think.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] github.com/libgeos vs github.com/OSGeo ?

[Mateusz Loskot]

On 5 April 2017 at 17:58, Sandro Santilli <s...@kbt.io> wrote:
> On Wed, Apr 05, 2017 at 05:39:06PM +0200, Mateusz Loskot wrote:
>>
>> In the spirit of community re-integration, wouldn't it be better to merge
>> into github.com/OSGeo/GEOS ?
>
> As long as my github user can still force-push to the `geos` and `php-geos`
> repositories I don't have a problem with that,

OK

> other than the effort of
> updating all the remotes (can github do this by itself?) and the wiki page
> (can github keep a redirect?).

AFAIK, it's not possible.

> If you can do all of the above transparently, please go ahead.

I have created new team to manage access privs:
https://github.com/orgs/OSGeo/teams/geos

Next, I'd like to transfer

https://github.com/libgeos/libgeos -> https://github.com/OSGeo/geos

Do we agree?

Then, the mirror updating scripts will need to be updated.

Could you do that Sandro?

> Note that for its nature, the mirror repository needs to have issues
> and ideally wiki off (not sure this is possible, on github).

Yes.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] github.com/libgeos vs github.com/OSGeo ?

[Mateusz Loskot]

Hi,

What is the benefit of having own GitHub organization?

In the spirit of community re-integration, wouldn't it be better to merge
into github.com/OSGeo/GEOS ?

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Ready to switch from SVN to GIT ?

[Mateusz Loskot]

And, as one of mantra requests processing admins, I can only confirm users
do get annoyed and often share comments how annoying it is.

Greg, most OSGeo projects have de facto switched to GitHub:

8 in 22 use OSGeo SVN
6 in 22 use OSGeo Track
21 in 22 use GitHub

It somewhat indicates preferences among OSGeo​ developers. Reasons are
unclear to me, or they are purely based on my interpretation of the facts.


Mateusz


On 5 Apr 2017 02:03, "Sebastiaan Couwenberg"  wrote:

> On 04/05/2017 01:27 AM, Greg Troxel wrote:
> > I am really unclear on the troubles with people getting osgeo accounts
> > (have had one for years), but it seems that if that's a reason to use a
> > proprietary hosting service then it's better to fix the problem.
>
> You need to get a mantra (request a token from an admin) to create an
> account, this is a significant barrier for users who want to contribute
> to OSGeo projects, especially when it's just a simple patch or bug report.
>
> For backgrounds see:
>
>  https://lists.osgeo.org/pipermail//sac/2016-June/007192.html
>
> Kind Regards,
>
> Bas
>
> --
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
>
>
> ___
> 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] Ready to switch from SVN to GIT ?

[Mateusz Loskot]

On 4 April 2017 at 23:58, Regina Obe <l...@pcorp.us> wrote:
> As a core maintainer, does it really matter so much to you whether you make 
> your commits to Gogs or Github?

No, it does not.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Ready to switch from SVN to GIT ?

[Mateusz Loskot]

On 4 April 2017 at 22:54, Regina Obe <l...@pcorp.us> wrote:
> Mat,
>
> Can you state things you like about github over gogs.

We have been discussing it over and over countless of times, with
Sandro and some other OSGeo admins, on IRC especially.
I see no point in debating GitHub vs alternatives, listing and ranking
features, detaioling costs, arguing ethics & politics,
down to manpower and resources required for self-hosting as well as
in-house development of gogs/gitea extras, etc.
Polluting this thread with round N of such debate does not sound interesting.

I just suggested to use GitHub and indicated my judgement is purely
based on features, services, integrations
and overall completeness of software development hosting.
As long as GitHub is alive, online and freely available for OSS, it is
hard to practically and economically justify any alternative.

> I don't know why it bugs me so much about reliance on GitHub, but it does.  
> Perhaps because I feel it's a free lunch that may not be so free in the future
> And also I don't like that policies may be pushed down on us that we don't 
> necessarily want and that the incentive structure of GitHub is not
> necessarily aligned with our own and may even change based on environmental 
> economics.

If GitHub dies, then you can migrate wherever you desire.
Meanwhile, doomsday prep is still only for the super-rich.

> Then again I understand that maintaining an infrastructure like Gogs requires 
> someone willing to do it or get paid for it, so that's even less of a free 
> lunch but does give us more control over our destiny and how we integrate 
> with other pieces of our infrastructure.

At the moment, do you really need more control?

Fact is, GEOS (OSGeo projects, 21 in 22 [1] projects) has already put
its roots down the GitHub ecosystem
that if anything dies (like Travis CI or AppVeyor), it will require
lots of work to migrate/replicate.

Don't get me wrong, I'm not GitHub advocate. I love/hate GitHub (tm [1]).
At the same time, I admit, I can't comprehend the resistance.
we use 90% of the surrounding services, but we die hard to not to say
the final "Yes, I do" :-)

[1] https://wiki.osgeo.org/wiki/InfrastructurePreferencesStatusQuo
[2] https://twitter.com/howardbutler/status/842766853088919552


Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Ready to switch from SVN to GIT ?

[Mateusz Loskot]

On 4 April 2017 at 22:19, Daniel Baston <dbas...@gmail.com> wrote:
> I'm not a PSC member, but I have done a bit of recent porting from JTS.
>
> I would also prefer hosting with GitHub.
>
> Especially lately, it is difficult to create an OSGeo account and I think
> this may discourage participation.

Indeed.

Alternatives like gogs/gitea are either close-to-inactive very young projects.
Feature-wise, as long as GitHub is there, it is no-brainer choice for an OSS.
IMHO, reasonable alternative is GitLab, seems it didn't catch much
appreciation in OSGeo due to, AFAIU, its not-so-kosher open core model.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Ready to switch from SVN to GIT ?

[Mateusz Loskot]

On 4 April 2017 at 12:09, Sandro Santilli <s...@kbt.io> wrote:
> I think we're finally ready to move the official repository
> from SVN to GIT, after dealing with the known issues in
> ticket https://trac.osgeo.org/geos/ticket/792
> [...]
>
> * So now which GIT repo ? *
>
> At the moment the GIT repository tracked by Trac is the one
> managed by Gogs.

https://github.com/OSGeo/GEOS

My opinion as a committer and developer, not PSC member.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] RFC 5: C++11 Compilation Mode

[Mateusz Loskot]

On 3 April 2017 at 23:48, Howard Butler <how...@hobu.co> wrote:
>> On Apr 3, 2017, at 3:55 PM, Mateusz Loskot <mate...@loskot.net> wrote:
>>
>>> but I too would note that range-based for loops don't work in MSVC 2013.
>>
>> Hmm, I'm not sure it's clear to me - I've not noticed any problem there.
>> Range-based statement should work pretty well in VS2013, even in VS2012:
>> https://msdn.microsoft.com/en-us/library/jj203382(v=vs.120).aspx
>
> I'm sorry, I meant array initializers. There's a few gotchas with 2013 that 
> were all cleaned up in 2015.

Right, I gotcha.

> It's reasonable in my mind to say GEOS only supports C++11 -compliant 
> compilers from version X.xx going forward.

Yes, that's what I'm hoping to achieve w/ the proposal.

> GDAL is also starting to have this discussion more seriously, and it is a 
> matter of time
> before some of the foundational libraries like GDAL and GEOS jump toward 
> C++11.

Yes, indeed.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] RFC 5: C++11 Compilation Mode

[Mateusz Loskot]

On 3 April 2017 at 17:19, Howard Butler <how...@hobu.co> wrote:
>> On Apr 1, 2017, at 11:44 AM, Sandro Santilli <s...@kbt.io> wrote:
>> On Sat, Apr 01, 2017 at 06:25:09PM +0200, Mateusz Loskot wrote:
>>> I'd rather wait for more votes than two.
>>> If no more votes arrive, I'll mark the RFC 5 as referred or withdrawn.
>>
>> You might have noticed that PSC has not been very active, lately, so
>> I would not wait for those votes to arrive.
>>
>> It's good to keep it open for more comments but I see no reason to
>> withdraw the proposal.
>
> I guess I'm still on the PSC...
>
> I'm +1,

Thanks Howard.

> but I too would note that range-based for loops don't work in MSVC 2013.

Hmm, I'm not sure it's clear to me - I've not noticed any problem there.
Range-based statement should work pretty well in VS2013, even in VS2012:
https://msdn.microsoft.com/en-us/library/jj203382(v=vs.120).aspx

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] RFC 5: C++11 Compilation Mode

[Mateusz Loskot]

On 29 March 2017 at 23:18, Mateusz Loskot <mate...@loskot.net> wrote:
> Dear PSC, All,
>
> For your delectation, RFC5 <https://trac.osgeo.org/geos/wiki/RFC5>
>
> This document proposes to switch GEOS to C++11 as
> minimum supported version of C++ language.
>
> Please review, provide your feedback.

+1


Rules reminder:
RFCs can be proposed by any interested party, not only PSC members.
A proposal will be accepted if it receives +2 (including the author)
and no vetoes (-1).
Only votes of PSC members will be counted.

[1] https://trac.osgeo.org/geos/wiki/RFC1

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] GEOS Matrix/IRC rooms

[Mateusz Loskot]

On 1 Apr 2017 13:33, "Sandro Santilli" <s...@kbt.io> wrote:

On Sat, Apr 01, 2017 at 01:25:14PM +0200, Mateusz Loskot wrote:
> On 1 Apr 2017 09:40, "Sandro Santilli" <s...@kbt.io> wrote:
>
> [ please pay more attention to quoting ! ]
>
> I do. Given I've been replying on my mobile lately, I'm sure you can live
> with any inconsistencies or quoting mistakes I may make

Sure, but makes communications *really* annoying. I just thought to
point that out in case your MUA doesn't make the quoting mistake evident
to you.

NOTE: I've been researching about this issue with another person I know
  from which I didn't expect bad quoting and he told me he recently
  started to use the gmail app on a mobile (just in case you're also
  affected by the same bug).



Yes, I use GMail and I'm not going to stop using it. You will forgive this
handful of responses I make from mobile.

Feel free to ignore my broken messages.

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

Re: [geos-devel] [geos-commits] r4387 - trunk/tests/unit

[Mateusz Loskot]

On 31 Mar 2017 21:32, "Sandro Santilli" <s...@kbt.io> wrote:

On Wed, Mar 29, 2017 at 06:47:37PM -0700, Mateusz Loskot wrote:

> The tests use mixture of whitespaces and indentation rules.

Is that also true within the same directory ?


I don't know, i haven't checked if tests/unit/a has the same style as
tests/unit/b

However, I sense where you're heading with this. Please, let's stop and
make a U-turn immediately!

I'm not going to respect .editorconfig per directory. I rather live
with/cultivate the styles mixture.

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

Re: [geos-devel] GEOS Matrix/IRC rooms

[Mateusz Loskot]

On 31 Mar 2017 21:43, "Sandro Santilli"  wrote:

FYI I've created a Matrix room bridged to a Freenode IRC channel:

 https://matrix.to/#/#osgeo-geos:matrix.org
 irc://irc.freenode.net/#osgeo-geos

Matrix also supports bridging to other chat systems, if needed,
which can be used to get the community back togheter.



Good one.


QGIS just
today merged again the IRC and Gitter users (finally!).



What does it mean they merged Gitter and IRC?

Perhaps we could do similar w/ libgeos oom on Gitter.

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

[geos-devel] RFC 5: C++11 Compilation Mode

[Mateusz Loskot]

Dear PSC, All,

For your delectation, RFC5 <https://trac.osgeo.org/geos/wiki/RFC5>

This document proposes to switch GEOS to C++11 as
minimum supported version of C++ language.

Please review, provide your feedback.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] RFC 4: Code Formatting Style

[Mateusz Loskot]

On 23 March 2017 at 18:25, Mateusz Loskot <mate...@loskot.net> wrote:
> Dear PSC, All,
>
> For your delectation, RFC4 <http://trac.osgeo.org/geos/wiki/RFC4>
> [...]
> Please review, provide your feedback.

FYI, I added "Miscellaneous" section and added a curious
example of the new GCC 6+ compiler warnings.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] RFC 4: Code Formatting Style

[Mateusz Loskot]

On 23 March 2017 at 18:42, Sandro Santilli <s...@kbt.io> wrote:
> On Thu, Mar 23, 2017 at 06:25:05PM +0100, Mateusz Loskot wrote:
>
>> For your delectation, RFC4 <http://trac.osgeo.org/geos/wiki/RFC4>
>
> Thanks for the time you put into this Mateusz.
> I like the idea of *enforcing* a style, but I'm of course concerned
> about being able to deal with this in the future, and about history
> destruction (git blame, as you call it).
>
> About the first concern (deal with it):
>
> We found out with PostGIS that changes in the formatting tool (astyle,
> in that case) made it hard for developers to enforce a given style (ie:
> different versions of the tool behaved differently).

I don't have any arguments-from-experience up my sleeve against AStyle,
but I have heard lots of such stories. Major advantage of clang-format
is the fact it is based on core of clang compiler.
An observation, biased or not, about large projects
(eg. Chromium, CMake, KDE, MongoDB, Apache Mesos)
switch to clang-format is an important indicator.

> On Debian stable (8.0) I find 3 distinct versions packaged (3.8,
> which you reference, from backports):
>
>   clang-format-3.4 - Tool to format C/C++/Obj-C code
>   clang-format-3.5 - Tool to format C/C++/Obj-C code
>   clang-format-3.8 - Tool to format C/C++/Obj-C code
>
> On Ubuntu LTS (16.04) I have 4 (or 5):
>
>   clang-format - Tool to format C/C++/Obj-C code
>   clang-format-3.5 - Tool to format C/C++/Obj-C code
>   clang-format-3.6 - Tool to format C/C++/Obj-C code
>   clang-format-3.7 - Tool to format C/C++/Obj-C code
>   clang-format-3.8 - Tool to format C/C++/Obj-C code

General agreement among clang-format users (eg. [1], [2])
seems to be that the recommended version is 3.8.
AFAIU, that is first version with complete/correct impl. of the
included base styles, with added a few new options to support that.

[1] https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst
[2] http://mesos.apache.org/documentation/latest/clang-format/

> For comparison: QGIS developers embedded a version of astyle.c in their
> codebase, so to ensure style won't change due to version of an external
> piece of software. Not that bad, as it's a single .c file IIRC.

Tell them about clang-format.

> About the specification:
>
> The clang-format document you suggest references an external entity
> (BasedOnStyle) which may make this more of a problem (what happens if
> the referenced style changes?).

That is for brevity.
For actual implementation, full version of `.clang-format` should be generated
using `clang-format -dump-config` option and BasedOnStyle commented.
I've updated RFC4.

> The format specification you propose does not mention line ending, why ?

clang-format does not enforce line endings and there is no need for that.
See EOL section I've just added to RFC4.

> About history destruction:
>
> You suggest to change .editor-config to match the new proposal, why not
> doing the contrary instead, to avoid changing too much the existing
> styles again?

I'm fine with any direction and I expected suggestions to the proposed settings.

"a standard is more important than which standard" summarises overall
spirit of the RFC4.

Although I'm not trying to sneak in style used in C++ standard library or Boost,
I do expect to avoid formatting styles exotic for any modern C++
codebases (and programmers) of XXI (eg. GNU, Whitesmiths).

> For example .editor-config requests the use of TAB, which
> are in use since a long time, why not keeping them ?

Currently, we have a mixture of tabs, spaces, 4-space indents,
2-space indents, everything really.
Year ago, the .editor-config sneaked in with 'breaking change' of
indent_size=2, new indentation width to the majority of codebase.
I take it as it is never a bad time to decide on new compromise.

Finally, as a member of the "heretic movements" [1] I just settled
with the 4-space indentation in the proposal.

[1] https://www.kernel.org/doc/Documentation/process/coding-style.rst

> Had you run tests with your suggested style to check how many lines
> would be changed ?

No, I haven't.
ATM, I'm doing my homework and getting buy-in.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] RFC 4: Code Formatting Style

[Mateusz Loskot]

Dear PSC, All,

For your delectation, RFC4 <http://trac.osgeo.org/geos/wiki/RFC4>

This document proposes and describes desired code formatting style
used across C/C++ source code in GEOS.

Please review, provide your feedback.

Is there any interest to put the RFC4 to the vote?
Please comment on that as well.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Porting recent JTS contributions to GEOS

[Mateusz Loskot]

On 21 March 2017 at 14:09, Mateusz Loskot <mate...@loskot.net> wrote:
> Daniel Baston wrote
>> Some interesting new code has recently gone into JTS, for example a KNN
>> search on STRtrees (https://github.com/locationtech/jts/pull/75).
>>
>> JTS is now under the Eclipse license.  Can post-1.14 contributions still
>> be
>> ported to GEOS and released under LGPL?
>
> We should be fine [1].
> Let's keep porting.

[1] https://twitter.com/opencholmes/status/695782382461276160
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Porting recent JTS contributions to GEOS

[Mateusz Loskot]

Daniel Baston wrote
> Some interesting new code has recently gone into JTS, for example a KNN
> search on STRtrees (https://github.com/locationtech/jts/pull/75).
> 
> JTS is now under the Eclipse license.  Can post-1.14 contributions still
> be
> ported to GEOS and released under LGPL?

We should be fine [1].
Let's keep porting.

-- 
Regards,
Mateusz



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Porting-recent-JTS-contributions-to-GEOS-tp5312578p5313416.html
Sent from the GEOS Developers mailing list archive at Nabble.com.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Slack: #geos

[Mateusz Loskot]

On 19 Mar 2017 09:41, "Sandro Santilli" <s...@kbt.io> wrote:

On Sun, Mar 19, 2017 at 12:41:53AM +0100, Mateusz Loskot wrote:

> FYI, there is OSGeo team on Slack [1]
> I have created #geos channel where I'm going go plug in
> GitHub, Travis CI, AppVeyor integrations.

I hope this won't contribute to further divide our community.
FYI: geos talk often happen in the #postgis IRC channel in
the Freenode network.



Divide and conquer ;)

It's going to be build status  & commits aggregator, don't expect lots of
talks there

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

[geos-devel] Slack: #geos

[Mateusz Loskot]

Hi,

FYI, there is OSGeo team on Slack [1]
I have created #geos channel where I'm going go plug in
GitHub, Travis CI, AppVeyor integrations.

[1] https://lists.osgeo.org/pipermail/sac/2015-August/005779.html

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] geos-3.6.1 released

[Mateusz Loskot]

On 14 March 2017 at 16:59, Rashad Kanavath <mohammedrasha...@gmail.com> wrote:
> On Sat, Dec 24, 2016 at 6:21 PM, Sandro Santilli <s...@kbt.io> wrote:
>> On Sat, Dec 24, 2016 at 05:39:34PM +0100, Sebastiaan Couwenberg wrote:
>>
>> > If your elves are not to busy, could you have them send a PR to fix:
>> >
>> >  https://github.com/ossimlabs/ossim/issues/79
>>
>> Your cookies and milk moved me a bit, enough to start some work which
>> you can see here: https://github.com/strk/ossim/tree/geos-capi
>>
>> But I could not configure the OSSIM source and the milk finished
>> before the C-API port completed. It didn't help to see that your
>> original report on ossim trac was left unanswered for 2+ months
>> and that the "cmake" call failed by not finding itself ?!
>>
>>   -- OSSIM_INCLUDE_DIR=OSSIM_INCLUDE_DIR-NOTFOUND
>>   -- OSSIM_LIBRARY=OSSIM_LIBRARY-NOTFOUND
>>   CMake Error at apps/CMakeLists.txt:16 (message):
>
>
> currently a bug/strange behaviour in ossim cmake.
>
> try building ossim using ./scripts/build.sh
> or disable apps with cmake -DBUILD_OSSIM_APPS=OFF

This has nothing to do with GEOS, so please post to OSSIM folks.

Or, if you still think it is GEOS issue, try to report the problem more
clearly, detailed explanation where/how GEOS failed.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Union of XYZ or XYM polygons

[Mateusz Loskot]

On 13 February 2017 at 10:36, seboricor <sebori...@gmail.com> wrote:
> Hello,
>
> I would like to know if it is planned that GEOS implements union of XYM or
> XYZ polygons ?
>
> I think it would be very interesting that the union of XYZ (or XYM) polygons
> returns an XYZ polygon and not only an XY (something as shown in the joined
> drawing)

You may read related threads about XYZ, XYM, XYZM support
https://lists.osgeo.org/pipermail/geos-devel/2012-July/005959.html
https://lists.osgeo.org/pipermail/geos-devel/2013-March/006245.html

AFAIK, GEOS has no M support.
You may try to implement coordinate interfaces, as briefely
explained here
https://trac.osgeo.org/geos/browser/trunk/include/geos/geom/CoordinateSequence.h#L46

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] status of C++ API - is it a bug to use it or not?

[Mateusz Loskot]

On 22 January 2017 at 20:32, Greg Troxel <g...@lexort.com> wrote:
> At:
>
>   https://trac.osgeo.org/geos
>
> it says
>
>   C and C++ API (C API gives long term ABI stability)
>
> and that gives a different impression.  It seems like the C++ API should
> be marked as "internal only,

No.
GEOS C++ API is not an internal API.
GEOS C++ API is a public yet supported API offered by GEOS.
GEOS just does not promise to keep the API/ABI stable
and compatible across releases.


> and it's a bug for other packages to use it".

No, it's not a bug.
It's a freedom of choice GEOS users have.

If one decides to use GEOS, she/he has to decide which GEOS API to use
and the frontpage you link above clearly states which one is stable.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.5 not built by Debbie?

[Mateusz Loskot]

On 8 June 2016 at 07:35, Sandro Santilli <s...@kbt.io> wrote:
> On Wed, Jun 08, 2016 at 01:51:12AM +0200, Mateusz Loskot wrote:
>
>> https://debbie.postgis.net/view/GEOS/ does not list 3.5 branch,
>> is that right?
>
> I'd think no. The 3.5 branch builds definitely exist:
> https://debbie.postgis.net/view/PostGIS/job/GEOS_Branch_3.5/

I see it is listed in All builds
https://debbie.postgis.net/

It seems, 3.5 build is not attached to GEOS category
https://debbie.postgis.net/job/GEOS_Branch_3.5/
and the top location bar shows path
Jenkins > GEOS_Branch_3.5
instead of
Jenkins > GEOS > GEOS_Branch_3.5
as it does for 3.4 and others.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] 3.5 not built by Debbie?

[Mateusz Loskot]

Hi,

https://debbie.postgis.net/view/GEOS/ does not list 3.5 branch,
is that right?

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Travis: xmltester/tests/bug176.xml: Failed to open file

[Mateusz Loskot]

On 7 March 2016 at 10:49, Sandro Santilli <s...@keybit.net> wrote:
> On Sun, Mar 06, 2016 at 12:57:41AM +0100, Mateusz Loskot wrote:
>> Hi,
>>
>> I noticed on Travis CI build [1], there seem to be some test data files 
>> missing:
>
> It sounds like a lack of CMakefile update:
>
>  $ grep bug176.xml Makefile.in
> $(srcdir)/tests/ticket/bug176.xml \
>  $ grep bug176.xml CMakeLists.txt
> ${XMLTESTS_DIR}/bug176.xml

Lazy me, thanks!
I've just updated relevant CMakeLists.txt.

> You know I'm not maintaining the CMake scripts at all...

The conversion is close! :P

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] Travis: xmltester/tests/bug176.xml: Failed to open file

[Mateusz Loskot]

Hi,

I noticed on Travis CI build [1], there seem to be some test data files missing:

Could not load 
/home/travis/build/libgeos/libgeos/tests/xmltester/tests/bug176.xml:
Failed to open file
Could not load 
/home/travis/build/libgeos/libgeos/tests/xmltester/tests/bug188.xml:
Failed to open file
Could not load 
/home/travis/build/libgeos/libgeos/tests/xmltester/tests/bug244.xml:
Failed to open file
Could not load 
/home/travis/build/libgeos/libgeos/tests/xmltester/tests/bug275.xml:
Failed to open file


[1] https://travis-ci.org/libgeos/libgeos/jobs/113971087

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] GeometryFilter vs GeometryComponentFilter on GeometryCollection

[Mateusz Loskot]

On 4 March 2016 at 15:44, Sandro Santilli <s...@keybit.net> wrote:
> On Fri, Mar 04, 2016 at 02:02:22PM +0100, Mateusz Loskot wrote:
>
>> Is this intentional that both filters pass the root geometry
>> (containing GeometryCollection or Multi*)
>> itself to apply_rw and apply_ro?
>
> I'd think the component filter should pass components, rather
> than the root, but might be missing something. Did you check if
> the class is used at all in the current codebase?

No, I simply implemented my own filters and compared the result.
I have just added new tests based on those filters
http://trac.osgeo.org/geos/changeset/4162

I included TODO comment wherever results are unclear to me.
http://trac.osgeo.org/geos/changeset/4162
I'll appreciate help in the actual vs expected results verification.

> Are there unit tests in JTS covering those classes ?

I have checked JTS current master [1] and I don't see any
tests for any of the filters.

[1] https://github.com/dr-jts/jts

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] GeometryFilter vs GeometryComponentFilter on GeometryCollection

[Mateusz Loskot]

Hi,

Is this intentional that both filters pass the root geometry
(containing GeometryCollection or Multi*)
itself to apply_rw and apply_ro?

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] GCC 6 build error

[Mateusz Loskot]

On 3 March 2016 at 11:10, Sandro Santilli <s...@keybit.net> wrote:
> On Thu, Mar 03, 2016 at 10:58:48AM +0100, Mateusz Loskot wrote:
>
>> However, we should be able to rely on that any C++11 compliant toolset
>> seeing #include  makes std::nan and std::isfinite available.
>
> And then what about OS/X and solaris ?

In the dark ages of pre-C++11 compilers, it a lot of 'fun' :-)
http://stackoverflow.com/a/2123781/151641
Since C++11, nan and isfinite along with other C99 utilities
have been added to C++.

I no longer care about non-C++11 compilers myself,
so for me std::{nan|isfinite} is always there.

> What would you think about removing all the many conditionals and:
>
>  #define ISNAN(x) ((x)!=(x))

Or,

namespage geos { bool is_nan(double x) { return x != x; } }

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] GCC 6 build error

[Mateusz Loskot]

On 3 March 2016 at 09:27, Sandro Santilli <s...@keybit.net> wrote:
> On Wed, Mar 02, 2016 at 05:21:33PM +0100, Mateusz Loskot wrote:
>> On 2 March 2016 at 17:13, Sandro Santilli <s...@keybit.net> wrote:
>> >
>> > This is the snippet, in configure.ac, to look for it:
>> >
>> >   AC_LANG_PUSH([C++])
>> >   AC_CACHE_CHECK([for isnan], ac_cv_isnan,
>> >[AC_TRY_LINK([#include ],
>> >[double x; int y; y = isnan(x);],
>>
>> I presume the test fails because it does not look for the function
>> inside std [1], but assumes nan is in global namespace.
>> I presume, it's especially the case for C++11 compilers.
>>
>> [1] http://en.cppreference.com/w/cpp/numeric/math/isnan
>
> I noticed the tests for finite/isfinite include 
> rather than , could that also change the namespacing
> of isnan ?

Possibly, yes.
I'm not sure about GCC extensions thought that might
make isnan or isfinite available as global names
even if C++ #include  is used,
IOW,  #include  might have the same effect as #include .

However, we should be able to rely on that any C++11 compliant toolset
seeing #include  makes std::nan and std::isfinite available.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Union of linestrings

[Mateusz Loskot]

On 1 March 2016 at 16:06, Sandro Santilli <s...@keybit.net> wrote:
> On Tue, Mar 01, 2016 at 03:41:37PM +0100, Mateusz Loskot wrote:
>> On 1 March 2016 at 15:09, Sandro Santilli <s...@keybit.net> wrote:
>> > On Tue, Mar 01, 2016 at 02:52:32PM +0100, Mateusz Loskot wrote:
>> >
>> >> What about constructing a single LineString from connected
>> >> segments, instead of a MultiLineString?
>> >
>> > LineMerge operation, aka GEOSLineMerge_r in C-API.
>>
>> Right, makes sense.
>>
>> So, by design, union of connected segments always yields MultiLineString.
>> Safe assumption?
>
> I think this is the current case, yes.
>
> The union operation makes no effort to drop nodes of degree 2
> (having just 2 edges connected) from the built topology.

Good. The test I have added [1] documents this behaviour,
at least for LineString geometries.

[1] 
https://trac.osgeo.org/geos/browser/trunk/tests/unit/operation/overlay/OverlayOpUnionTest.cpp?rev=4153#L61

Best regards,
-- 
Mateusz Łoskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Union of linestrings

[Mateusz Loskot]

On 1 March 2016 at 15:09, Sandro Santilli <s...@keybit.net> wrote:
> On Tue, Mar 01, 2016 at 02:52:32PM +0100, Mateusz Loskot wrote:
>
>> What about constructing a single LineString from connected
>> segments, instead of a MultiLineString?
>
> LineMerge operation, aka GEOSLineMerge_r in C-API.

Right, makes sense.

So, by design, union of connected segments always yields MultiLineString.
Safe assumption?

Best regards,
-- 
Mateusz Łoskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Union of linestrings

[Mateusz Loskot]

On 29 February 2016 at 20:10, Sandro Santilli <s...@keybit.net> wrote:
> On Mon, Feb 29, 2016 at 07:18:08PM +0100, Mateusz Loskot wrote:
>> Hi,
>>
>> I've started adding tests for OverlayOp [1] and I noticed
>> curious results for basic test case.
>>
>> OverlayOp(UNION) on Four segments of a sqare
>> always construct a MultiLineString.
>> I'd have expected a polygon, shouldn't I?
>
> No, you shouldn't.

Sandro,

What about constructing a single LineString from connected
segments, instead of a MultiLineString?

What are the criteria in such case?

Best regards,
-- 
Mateusz Łoskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] Union of linestrings

[Mateusz Loskot]

Hi,

I've started adding tests for OverlayOp [1] and I noticed
curious results for basic test case.

OverlayOp(UNION) on Four segments of a sqare
always construct a MultiLineString.
I'd have expected a polygon, shouldn't I?

In this case, I noticed OverlayOp always labels edges
as UNDEF or BOUNDARY this simply leads to non-area
results and the PolygonBuilder never receives any input
which qualifies as a polygon.

As you can see in the test, the union is constructed
incrementally:

GeometryPtr lines12(line1->Union(line2.get()));
GeometryPtr lines123(lines12->Union(line3.get()));
GeometryPtr lines1234(lines123->Union(line4.get()));

but the same result (MultiLineString) is returned
if I union via UnaryUnion on MultiLineString or GeometryCollection.

My questions are:
1. Is this expected behaviour?
2. Am I missing any trick to actually obtain the polygon?

[1] https://trac.osgeo.org/geos/changeset/4153

Best regards,
-- 
Mateusz Łoskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Moving GEOS repository to GIT

[Mateusz Loskot]

On 5 February 2016 at 09:16, Sandro Santilli  wrote:
> Are all GEOS committers ok with moving the code from SVN
> to GIT, while keeping the current trac instance ?

+1

Best regards,
-- 
Mateusz Łoskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] updating geos 3.5.0 source archive.

[Mateusz Loskot]

On 10 November 2015 at 01:42, Jürgen E. <j...@norbit.de> wrote:
> On Sun, 08. Nov 2015 at 22:01:53 +0100, Rashad M wrote:
>> > IIRC, ossim said it will stick to c++api as long as there is one. I know
>
>> GEOS recommends to use C-API but it also provides c++. So I don't see that
>> ossim is going to move away.
>
> Why not?  Other projects have to.  I'd prefer to keep the C++ API out
> of the picture.

Jürgen,

If I may, one correction: other projects do NOT have to, but they choose to.
GEOS C++ API is an official API perfectly supported and
recommended to use by GEOS users.

There is, however, cost involved. That is, GEOS does not promise C++ API/ABI
stability, so those who choose GEOS C++ API should be aware they may need
to update change their code more frequently.

So, I don't think it's a good idea to forbid the freedom of GEOS API choice,
especially if it is a choice between officially supported APIs.

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] updating geos 3.5.0 source archive.

[Mateusz Loskot]

On 10 November 2015 at 12:11, Jürgen E. <j...@norbit.de> wrote:
> On Tue, 10. Nov 2015 at 10:50:57 +0100, Mateusz Loskot wrote:
>
>> There is, however, cost involved. That is, GEOS does not promise C++ API/ABI
>> stability, so those who choose GEOS C++ API should be aware they may need
>> to update change their code more frequently.
>
> Also right - plus that we need to either pick one C++ compiler that works for
> everyone (Qt and reverse dependencies currently use 2010 in OSGeo4W - not
> 2012), leave some behind or ship a myriad of different packages to suit
> everyone.

I see. I'm not particularly experienced with OSGeo4W development issues.

>> So, I don't think it's a good idea to forbid the freedom of GEOS API choice,
>> especially if it is a choice between officially supported APIs.
>
> I just stated a preference - and asked whether it is feasible to port OSSIM to
> the C-API.

Right, certainly, C API is preferred from deployment point.

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Object Destruction

[Mateusz Loskot]

On 27 October 2015 at 12:48, thilo.fisc...@ksti.de
<thilo.fisc...@ksti.de> wrote:
> http://trac.osgeo.org/geos/ticket/325
> [...]
> Is it that a destroy function for CoordinateSequence is missing in GEOS
> (is it a bug?),

I'd say, Sandro's comment explains the reason:

"In JTS GeometryFactory? is a class while CoordinateSequenceFactory?
is an interface. In JTS neither GeometryFactory? nor
CoordinateSequenceFactory? have a destroy function."

> or did I fail to notice some detail in the GEOS API which solves this issue?

C API offers GEOSCoordSeq_destroy for this purpose.

> Is myGeosGeometry->getFactory()->destroyGeometry(myGeosGeometry) the intended
> way to delete Geometry objects?

IMO, yes, whenever you have access to "named destructor", call it.

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Object Destruction

[Mateusz Loskot]

On 30 October 2015 at 10:47, thilo.fisc...@ksti.de
<thilo.fisc...@ksti.de> wrote:
> On 30 October 2015 at 10:10, <geos-devel-boun...@lists.osgeo.org on behalf
> of mate...@loskot.net> wrote:
>>> http://trac.osgeo.org/geos/ticket/325
>>> [...]
>>> Is it that a destroy function for CoordinateSequence is missing in GEOS
>>> (is it a bug?),
>>
>>I'd say, Sandro's comment explains the reason:
>>
>>"In JTS GeometryFactory? is a class while CoordinateSequenceFactory?
>>is an interface. In JTS neither GeometryFactory? nor
>>CoordinateSequenceFactory? have a destroy function."
>
> I must confess: I don't fully understand this part of Sandro's comment. In
> JTS, we have Garbage Collection and thus no need for destruction
> functions, isn't it?

I understand it differently: JTS API does not provide such method(s),
so GEOS does not have it either - GEOS is a direct port of JTS without
any (or strictly limited) custom extension to the master API defined in JTS.

However, it would be best if Sandro chimed in and clarify that.

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] [wip] Windows builds on AppVeyor

[Mateusz Loskot]

Folks,

I have been trying to configure AppVeyor builds for GEOS

First stab at appveyor.xml is in svn-trunk branch at
https://github.com/mloskot/libgeos

First, I aimed at Visual Studio 2015 + NMAKE builds,
32 and 64 bit, debug and release.

Things work well for 32-bit builds.

Unfortunately, there is a strange issue with 64-bit build, see details:

http://help.appveyor.com/discussions/problems/3203-vs2015-and-incorrect-mspdb140dll-version

It seems, that the issue is strange to AppVeyor support folks too.

I'm looking for some AppVeyor gurus that could help here.

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [wip] Windows builds on AppVeyor

[Mateusz Loskot]

On 13 October 2015 at 16:05, Sandro Santilli <s...@keybit.net> wrote:
> Sorry for the ignorance, but ... what is appveyor ?

Think of Travis CI for Windows.

> Does it provide a nice-looking badge we can add to the README.md ? :>

Yes, of course :)

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] GEOS 3.5.0 remaining open tickets

[Mateusz Loskot]

On 16 Jul 2015 12:09, Sandro Santilli s...@keybit.net wrote:
 On Thu, Jul 16, 2015 at 03:28:22AM -0400, Paragon Corporation wrote:
  Strk et. al,
 
  --- this one I closed as a won't fix though I felt a bit guilty about it
  I only use CMake now for building and if someone who uses Makefile.vc
for
  building cares -- feel free to provide a patch and reopen
  #577  Makefile.vc lacks install / uninstall / test procedures

 Personally I don't care about vc, if nobody steps up within one week
 I think you can close as won't fix.

I do care about Makefile.vc but I don't care about install target in it.
IMHO this ticket can be closed.

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

[geos-devel] Port DoubleDouble and CGAlgorithmsDD support (PR #40)

[Mateusz Loskot]

Hi,

I've been experimenting with porting some of JTS features
aiming improved numerical robustness.
Namely, I added basic support for increased precision float-point
as analog to JTS DoubleDouble


Complete patched source tree is available in this branch
https://github.com/mloskot/libgeos/tree/doubledouble-cgalgorithms
It's ready to pull, build (using CMake, I haven't touched Autotools or
NMake makefiles)
and try out.

Here is Pull Request that extracts all the changes I have applied
https://github.com/libgeos/libgeos/pull/40

If anyone interested, have fun and if there is broad interest,
perhaps DD support could be applied to the upstream.

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] WKB representation is EWKB, not OGC

[Mateusz Loskot]

On 5 December 2013 19:52, Paul Ramsey pram...@cleverelephant.ca wrote:
 That thread includes a (dead) link to the (approved) OGC change that
 added PostGIS-style 2.5 D handling of WKB
 (http://lists.osgeo.org/pipermail/postgis-devel/2004-December/000695.html)

Here is another one with the original Adam Gawne-Cain's 99-402r2.pdf attached

http://lists.osgeo.org/pipermail/postgis-devel/2004-December/000695.html


Best regards,
-- 
Mateusz  Łoskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] help compiling windows library

[Mateusz Loskot]

On 22 November 2013 07:06, Riccardo Cohen r.co...@realty-property.com wrote:
 All compilation went all right, only linking seems to fail. Is there any
 additional option to set in nmake command to show more errors and line
 numbers, I could not find any (I'm not using nmake very often).

I guess, the NMAKE makefiles need to be updated by adding one of recently
added .cpp files to http://svn.osgeo.org/geos/trunk/src/Makefile.vc

If linker fails, then there must be name of unresolved external symbol
included in the error message.
This will give you clues what class/function may be missing,
search for it in the GEOS sources tree, check if corresponding
.cpp is in the makefile, add it if it isn't.

That's usually my take on this kind of problems with NMAKE.

p.s. Once you apply necessary update to makefile.vc,
please submit patch to http://trac.osgeo.org/geos/

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] geos_svn_revision.h and cmake

[Mateusz Loskot]

On 3 August 2013 18:30, David Burken dbur...@comcast.net wrote:
 Hey I think you forgot to commit a file:
 -- Found Subversion: C:/Program Files/TortoiseSVN/bin/svn.exe (found version
 1.8.1)
 CMake Error: File
 D:/dev/vs11_x64/geos/geos-svn/tools/geos_svn_revision_cmake.h.in does not
 exist.
 CMake Error at CMakeLists.txt:260 (configure_file):
   configure_file Problem configuring file

It was included in the commit:
http://trac.osgeo.org/geos/changeset/3861

and I can see it there:

http://svn.osgeo.org/geos/trunk/tools/

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net
Participation in this whole process is a form of torture ~~ Szalony,
wspinanie.pl
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] geos_svn_revision.h and cmake

[Mateusz Loskot]

On 3 August 2013 15:17, David Burken dbur...@comcast.net wrote:
 All,

 I have a patch to auto generate the geos_svn_revision.h.  After fixing my
 error, I wasn't sure if I should submit a ticket after reading the below
 links?  If you want it, I can do a ticket. I

David,

Please, submit your contributions, they're hugely welcome!
I'll try to test them and commit.

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net
Participation in this whole process is a form of torture ~~ Szalony,
wspinanie.pl
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] geos_svn_revision.h and cmake

[Mateusz Loskot]

On 3 August 2013 16:31, David Burken dbur...@comcast.net wrote:
 On 8/3/2013 10:42 AM, Mateusz Loskot wrote:

 On 3 August 2013 15:17, David Burken dbur...@comcast.net wrote:

 All,

 I have a patch to auto generate the geos_svn_revision.h.  After fixing my
 error, I wasn't sure if I should submit a ticket after reading the below
 links?  If you want it, I can do a ticket. I

 David,

 Please, submit your contributions, they're hugely welcome!
 I'll try to test them and commit.

 Best regards,


 Done:

 http://trac.osgeo.org/geos/ticket/643

Committed.
r
I'll be testing some corner cases later.

Thanks!

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net
Participation in this whole process is a form of torture ~~ Szalony,
wspinanie.pl
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Motion to give Regina commit rights - PSC members who haven't Please respond

[Mateusz Loskot]

On 19 July 2013 10:36, Sandro Santilli s...@keybit.net wrote:
 Mateusz, could you please also show your availability to do add the
 required bits (holiday season here!). Thanks.

Sandro,

I'm confused, what required bits you mean?
I thought this thread is about PSC voting.

Best regards,
--
Mateusz  Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Motion to give Regina commit rights - PSC members who haven't Please respond

[Mateusz Loskot]

On 19 July 2013 10:44, Sandro Santilli s...@keybit.net wrote:
 On Fri, Jul 19, 2013 at 10:41:43AM +0100, Mateusz Loskot wrote:
 On 19 July 2013 10:36, Sandro Santilli s...@keybit.net wrote:
  Mateusz, could you please also show your availability to do add the
  required bits (holiday season here!). Thanks.

 I'm confused, what required bits you mean?
 I thought this thread is about PSC voting.

 According to RFC2 you're the SVN Administrator.

 Actually, the same document says such role should be taken
 by one of the PSC members, so I'm confused too. Have you
 ever been on the PSC ?

AFAIR, I used to be PSC member, but I stepped down.

Best regards,
--
Mateusz  Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] SVN Administrator (was: Motion to give Regina commit rights - PSC members) who haven't Please respond

[Mateusz Loskot]

On 19 July 2013 11:38, Sandro Santilli s...@keybit.net wrote:
 On Fri, Jul 19, 2013 at 10:46:19AM +0100, Mateusz Loskot wrote:
 On 19 July 2013 10:44, Sandro Santilli s...@keybit.net wrote:
  On Fri, Jul 19, 2013 at 10:41:43AM +0100, Mateusz Loskot wrote:
  On 19 July 2013 10:36, Sandro Santilli s...@keybit.net wrote:
   Mateusz, could you please also show your availability to do add the
   required bits (holiday season here!). Thanks.
 
  I'm confused, what required bits you mean?
  I thought this thread is about PSC voting.
 
  According to RFC2 you're the SVN Administrator.
 
  Actually, the same document says such role should be taken
  by one of the PSC members, so I'm confused too. Have you
  ever been on the PSC ?

 AFAIR, I used to be PSC member, but I stepped down.

 Do we need another SVN Admin then ?

No idea.

 Or is someone already accounted ?

I think I may be SVN admin due to the fact I'm sort of
spare SVN admin of number of OSGeo projects.

Best regards,
--
Mateusz  Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Ability to preallocate the WKT stringstream buffer for really large geometries?

[Mateusz Loskot]

On 21 February 2013 09:22, Mats Taraldsvik mats.taralds...@norkart.no wrote:
 Locally, I have modified the WKTWriter::writeNumber(double d) method to use 
 boost::spirit::karma::real_generator for conversion
 of numbers, instead of std::stringstream.

Just to back up this idea:

http://alexott.blogspot.co.uk/2010/01/boostspirit2-vs-atoi.html

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Ability to preallocate the WKT stringstream buffer for really large geometries?

[Mateusz Loskot]

On 21 February 2013 09:41, Sandro Santilli s...@keybit.net wrote:
 On Thu, Feb 21, 2013 at 09:22:36AM +, Mats Taraldsvik wrote:

 Locally, I have modified the WKTWriter::writeNumber(double d) method to use 
 boost::spirit::karma::real_generator for conversion of numbers, instead of 
 std::stringstream. This improves writing WKT by 6x-10x on my datasets 
 (tested with linestrings with up to 1 points). This change *is not* part 
 of the patch for two reasons:

 - I don't know whether you want to introduce a dependency on 
 boost::spirit::karma, although it is header-only, so it might not be a large 
 barrier.

 - The precision and fixed notation parametres are changed by using policies, 
 essentially structs with static methods that return the precision, 
 trailing_zeros etc. I might be incorrect, but I would have to make policies 
 (structs) for every combination of fixed and decimalPlaces and determine at 
 runtime which of them to use, to make the approach suitable for GEOS. This 
 is easily done, but I don't know if you think it is worth it?

 No, I don't think we should introduce a dependency on boost yet.

Any chance to at least conditionally-compile for C++11 and use

http://en.cppreference.com/w/cpp/string/basic_string/stof

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Compiling geos with mingw64

[Mateusz Loskot]

On 15 February 2013 14:48, David Burken dbur...@comcast.net wrote:

 I'm attempting a 64 bit windows build with the mingw cross compiler on
 linux.  Here's my hacks to get geos to compile if anyone's interested.  See 
 below.

Feel free to add to
http://trac.osgeo.org/geos/wiki/BuildingOnWindowsWithCMake

You may also consider ticket with .patch file
attached, with svn diff  output.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Possible to link dynamically to GEOS C interface?

[Mateusz Loskot]

On 19 October 2012 12:22, Crispin Cooper coope...@cf.ac.uk wrote:
 Hi

 I am having trouble with my dll finding geos_c.dll at runtime - even though
 they're located together!  I wonder if it's possible to link
 dynamically/explicitly to it somehow, then I could specify the right path?

Yes, geos_i.lib is the import library for geos.dll.
Check:
http://trac.osgeo.org/geos/browser/trunk/nmake.opt#L160
http://trac.osgeo.org/geos/browser/trunk/src/Makefile.vc#L4

 The docs (http://geos.osgeo.org/doxygen/c_iface.html) only seem to describe
 static linking.

It doesn't say anything about static linking.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Possible to link dynamically to GEOS C interface?

[Mateusz Loskot]

On 19 October 2012 13:16, Crispin Cooper coope...@cf.ac.uk wrote:
 On 19/10/2012 12:53, Mateusz Loskot wrote:

 It doesn't say anything about static linking. Best regards,

 Sorry - think I need a new brain this afternoon!  I meant explicit linking.
 I'd like to link explicitly at runtime, rather than implicitly which is what
 linking to geos_c_i.lib seems to do.  Or, more generally, I'd like to be
 able to tell geos_c_i.lib where to look for geos_c.dll.  How can I do this?

http://msdn.microsoft.com/en-us/library/784bt7z7(v=vs.100).aspx

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] GEOS License and iOS usage

[Mateusz Loskot]

On 8 August 2012 10:15, Stefan Klug klug.ste...@gmx.de wrote:
 Are there any chances to license GEOS under a more permissive license
 like MPL or to tri-license it like stated
 in http://www.mozilla.org/MPL/boilerplate-1.1/mpl-tri-license-html ?

FYI, GEOS is a direct port of JTS [1].
IMO, your question fits the JTS mailing list first.

[1] http://en.wikipedia.org/wiki/JTS_Topology_Suite

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [GEOS] #556: Build error using cmake: ../geos_svn_revision.h: No such file or directory

[Mateusz Loskot]

On 25 June 2012 13:01, Sandro Santilli s...@keybit.net wrote:
 On Mon, Jun 25, 2012 at 10:59:31AM -, GEOS wrote:

  Simply, I'd suggest to avoid making the whole process unnecessarily obscure.

 What's obscure about ./configure  make ?

IMO, make should not generate intermediate env/platform/user-specific headers.
It's autoconf's job.

 The most obscure thing I see is cmake invocation, to be honest.

cmake invocation is equal to ./configure step.

 There's no need to explicitly invoke the svn file generator,
 it's all taken care of by make ...

I understand make can do it and make can (almost) do whatever you want,
but that is not the point.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [GEOS] #556: Build error using cmake: ../geos_svn_revision.h: No such file or directory

[Mateusz Loskot]

On 25 June 2012 15:08, Sandro Santilli s...@keybit.net wrote:
 On Mon, Jun 25, 2012 at 01:05:59PM +0100, Mateusz Loskot wrote:
 On 25 June 2012 13:01, Sandro Santilli s...@keybit.net wrote:
  On Mon, Jun 25, 2012 at 10:59:31AM -, GEOS wrote:
 
   Simply, I'd suggest to avoid making the whole process unnecessarily 
  obscure.
 
  What's obscure about ./configure  make ?

 IMO, make should not generate intermediate env/platform/user-specific 
 headers.
 It's autoconf's job.

  The most obscure thing I see is cmake invocation, to be honest.

 cmake invocation is equal to ./configure step.

  There's no need to explicitly invoke the svn file generator,
  it's all taken care of by make ...

 I understand make can do it and make can (almost) do whatever you want,
 but that is not the point.

 My point is that the SVN revision string serves the purpose of knowing
 which SVN revision you're actually using

Yes, it's clear.

 It's very weak to depend on the discipline of the builder to always run 
 ./configure (or cmake)
 after each and every SVN update, so the result would often be an outdated
 revision string in reported issues.

On the contrary, depending on the ./configure is actually the strength
of the solution.
Every svn update should be followed by ./configure, then make,
and skipping ./configure after svn update should not be supported whatsoever.

The svn update can bring lots of things changes at different levels
and users shall never
assume build configuration, templates of generated headers, and other
volatile stuff
will stay untouched. After svn update, all dangling headers, generated
by previous
calls to ./configure should be regenerated.

Any workflow within the development version of source code different than
svn update  ./configure  make
should neither be encouraged to follow, nor supported.

Also, geos/version.h should have something like
#define GEOS_REVISION  @GEOS_REVISION@
substituted during boostrap.

My 5 cents.

 By having make do that we're guaranteed that the revision number is
 always up to date.

This is not a solution, but obscure hack that interferes with typical
build steps.

My 2 cents.

 May I suggest you just add the script invocation and if any compatibility
 problem arises we try to fix it ?

Sure.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [GEOS] #556: Build error using cmake: ../geos_svn_revision.h: No such file or directory

[Mateusz Loskot]

On 25 June 2012 16:34, Mateusz Loskot mate...@loskot.net wrote:
 On 25 June 2012 15:08, Sandro Santilli s...@keybit.net wrote:

 It's very weak to depend on the discipline of the builder to always run 
 ./configure (or cmake)
 after each and every SVN update, so the result would often be an outdated
 revision string in reported issues.

 On the contrary, depending on the ./configure is actually the strength
 of the solution.
 Every svn update should be followed by ./configure, then make,
 and skipping ./configure after svn update should not be supported whatsoever.
 [...]

Sandro,

You may find this thread interesting:

http://lists.gnu.org/archive/html/automake/2009-05/msg00145.html

The GraphicsMagick's version.sh is interesting solution.

Simply, there are two cases where version info is used/generated:

1) Static version info stored currently in multiple places
(./configure, nmake.opt, CMakeLists.txt)
What about having such 'static' version info stored in plain text file
e.g. VERSION with number per line.

Then, this file could be parsed by ./configure, by cmake script and
even by NMAKE stuff too
so the general version info is consistent across all build configurations.

2) Volatile VCS-based version
In case of SVN/Git revision, version.sh could do this job as well for
./configure (see GraphicsMagick),
and native CMake scripting/modules could be used for CMake configuration.
For NMAKE, there could be simple .bat script.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Cutting a 3.3.5 release

[Mateusz Loskot]

Sandro,
I've been travelling in Poland with no solid connection.
I'll check what's there to be done and try to fix it within next few days.
-- 
Mateusz Loskot
(Sent from phone, apology for any top-posting or broken quoting)
On 22 Jun 2012 13:30, Sandro Santilli s...@keybit.net wrote:

 After figuring 3.3.4 was whipped with a CAPI library version
 inferior to the one shipped with 3.3.3 [1] I think it's urgent
 to release a 3.3.5 to fix the situation.

 [1] http://trac.osgeo.org/geos/ticket/558

 In addition to this specific bug there are other 6 items
 targetting a 3.3.5, one of which related to the CMAKE build
 system [2].

 [2] http://trac.osgeo.org/geos/ticket/556

 Given the push for this release has to do with build scripts
 I think it would be nice to have the CMAKE bug also fixed,
 so to possibly also set the version straight in it.

 Mateusz: are you planning to close those within a week ?

 --strk;

  Sent from our free software
  http://www.gnu.org/philosophy/free-sw.html

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

Re: [geos-devel] polygon with overlapping edges

[Mateusz Loskot]

On 13 April 2012 14:48, Jasmin FORMONT jform...@siradel.com wrote:
 I tried a buffer(0), but it splits my geometry in two separate polygons.

IMHO, that's most reasonable result you can get with GEOS.

 But is it a normal behavior that this kind of polygon is not supported ?

Yes, because this polygon is not simple, thus not valid according to
OGC SF spec.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Moving to github

[Mateusz Loskot]

On 27/09/11 13:45, Sandro Santilli wrote:
 On Sat, Sep 24, 2011 at 11:45:40PM +0100, Mateusz Loskot wrote:

 Also, Alex (wildintellect) mentioned [1] OSGeo may introduce Git support
 in near future.

 ...handing over to decision makers.

 [1] http://logs.qgis.org/slogs/%23qgis.2011-09-24.log
 
 I'd wait for Git support in OSGeo.

OK

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Moving to github

[Mateusz Loskot]

On 23/09/11 12:28, Sandro Santilli wrote:
 On Fri, Sep 23, 2011 at 11:46:23AM +0100, Mateusz Loskot wrote:
 On 21/09/11 17:08, Sandro Santilli wrote:
 On Wed, Sep 21, 2011 at 04:44:28PM +0100, Mateusz Loskot wrote:
 IOW, how someone can make the import, so you can configure the
 cronjob on different machine/setup?

 Actually I don't know what's the best way to do this kind of things by
 also including all branches. Neither my nor your setup did that, right ?

 First issue to solve is to find a machine which is online 24/7 and
 can run the cronjob. Manual maintenance/update is unreliable.
 
 I have that, no problem there.

I have asked [1] QGIS folks about their experiences with SVN - Git.
The big question is: are we going to migrate to Git or mirror SVN in Git?

According to what I have been told by Tim, the former is a good idea,
the latter is not.

Also, Alex (wildintellect) mentioned [1] OSGeo may introduce Git support
in near future.

...handing over to decision makers.

[1] http://logs.qgis.org/slogs/%23qgis.2011-09-24.log
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel