[Geotools-devel] Proposal: SQL Encoding of Vendor Provided Custom Functions

Hi there, first, many thanks for giving attention to this proposal :-) Basically, I will be fine with any solution or modification of the proposal, as long as "SQL Encoding of Vendor Provided Custom Functions" will be the outcome of the change. See remarks inline and some summary below:

Re: [Geotools-devel] Proposal: Java 11 LTS minimum, dropping Java 8

+1 Cheers, Torben On Fri, Oct 28, 2022 at 11:36 AM Jody Garnett wrote: > Proposal is available: > >- https://github.com/geotools/geotools/wiki/Java-11-LTS >- https://osgeo-org.atlassian.net/browse/GEOT-7254 >- Prior discussion is here > >

Re: [Geotools-devel] Proposal: Java 11 LTS minimum, dropping Java 8

I've made a draft PR for the switch here: https://github.com/geotools/geotools/pull/4097 Updates pom files, github actions, and documentation. The tutorials need to be re-tested, some of them seem really outdated (I've made a brief attempt on Windows and things have changed significantly there,

Re: [Geotools-devel] Proposal: Java 11 LTS minimum, dropping Java 8

+1, assuming that this proposal is for GeoTools 29.0 On Sat, Oct 29, 2022 at 1:54 PM Ian Turton wrote: > +1 > > Ian > > On Fri, 28 Oct 2022, 19:36 Jody Garnett, wrote: > >> Proposal is available: >> >>- https://github.com/geotools/geotools/wiki/Java-11-LTS >>-

Re: [Geotools-devel] Proposal: Java 11 LTS minimum, dropping Java 8

+1 Ian On Fri, 28 Oct 2022, 19:36 Jody Garnett, wrote: > Proposal is available: > >- https://github.com/geotools/geotools/wiki/Java-11-LTS >- https://osgeo-org.atlassian.net/browse/GEOT-7254 >- Prior discussion is here > >

[Geotools-devel] Proposal: Java 11 LTS minimum, dropping Java 8

Proposal is available: - https://github.com/geotools/geotools/wiki/Java-11-LTS - https://osgeo-org.atlassian.net/browse/GEOT-7254 - Prior discussion is here

Re: [Geotools-devel] Proposal for the HTTPResponse interface

Thanks for the feedback, Jody! First off, there are cases when the HTTPResponse is wrapped over a FileInputStream. Maybe it's mostly for unit tests, but I think I've seen it in other situations (like caching perhaps). Therefore I intentionally avoided the getStatusCode method, but surely we

Re: [Geotools-devel] Proposal for the HTTPResponse interface

Just saw my example was messed up, now uses httpResponse.getResponseStream consistently: try { if (httpResponse.getStatus() == 200) { return ImageIOExt.readBufferedImage(httpResponse.getResponseStream()); } if (httpResponse.getStatus() == 400) { if

Re: [Geotools-devel] Proposal for the HTTPResponse interface

Thanks for the proposal Roar: The GeoTools wiki is not restricted, we can consider setting that up as needed. If I understand correctly the proposal is: - boolean *isOK()*: returns true for HTTP status 200 - not quite sure if you want to consider some of the other success codes

[Geotools-devel] Proposal for the HTTPResponse interface

Hi, I have a Proposal for the gt-http library. More specific the HTTPResponse interface. I followed the instructions at the Wiki page, and created a New Page, but when I clicked Save Page I didn't get a Pull Request as the instructions indicated. It seems like the Page was created and freely

Re: [Geotools-devel] proposal: Use CC0 as an improved way to indicate code examples are public domain

This change is merged, and visible in our documentation (example the header on Quickstart.java example here ). The developers guide has the new header

Re: [Geotools-devel] proposal: Use CC0 as an improved way to indicate code examples are public domain

Thanks everyone, going ahead (to fix small sortpom issue first) with merge. -- Jody Garnett On Mar 29, 2022 at 10:24:04 AM, Torben Barsballe wrote: > +1 from me > Cheers, > Torben > > > On Fri, Mar 18, 2022 at 1:50 PM Jody Garnett > wrote: > >> I would like to do a quick proposal: >> >> >

Re: [Geotools-devel] proposal: Use CC0 as an improved way to indicate code examples are public domain

+1 from me Cheers, Torben On Fri, Mar 18, 2022 at 1:50 PM Jody Garnett wrote: > I would like to do a quick proposal: > > > Use CC0 for our documentation and source code examples, in keeping with > our public domain policy in the developers guide > > CC0 is as I understand it a more useful way

Re: [Geotools-devel] proposal: Use CC0 as an improved way to indicate code examples are public domain

Thanks Andrea, some good news - because of how the header regex was setup there was no need to use property expansion to select a different set of rules. As the QA check is not really desired in a standalone project I have isolated it into a profile (could not see any way to reduce duplication).

Re: [Geotools-devel] proposal: Use CC0 as an improved way to indicate code examples are public domain

Hi Jody, I did not know the answer, so I did a quick research. It seems one can configure property expansion in the checkstyle configuration file, that would allow to switch expected header on a per module basis:

Re: [Geotools-devel] proposal: Use CC0 as an improved way to indicate code examples are public domain

Thanks Ian, I actually have a technical question for Andrea on this one, one of the tasks is "Check if docs can skip QA check for LGPL headers". Any tips on how to set that up, or override the configuration to check for CC0 headers? -- Jody Garnett On Mar 19, 2022 at 2:20:08 AM, Ian Turton

Re: [Geotools-devel] proposal: Use CC0 as an improved way to indicate code examples are public domain

+1 Ian On Fri, 18 Mar 2022 at 20:59, Jody Garnett wrote: > Here is proposal > https://github.com/geotools/geotools/wiki/Change-tutorial-and-example-code-from-public-domain-to-CC0 > -- > Jody Garnett > > > On Fri, 18 Mar 2022 at 13:48, Jody Garnett wrote: > >> I would like to do a quick

Re: [Geotools-devel] proposal: Use CC0 as an improved way to indicate code examples are public domain

Here is proposal https://github.com/geotools/geotools/wiki/Change-tutorial-and-example-code-from-public-domain-to-CC0 -- Jody Garnett On Fri, 18 Mar 2022 at 13:48, Jody Garnett wrote: > I would like to do a quick proposal: > > > Use CC0 for our documentation and source code examples, in

[Geotools-devel] proposal: Use CC0 as an improved way to indicate code examples are public domain

I would like to do a quick proposal: > Use CC0 for our documentation and source code examples, in keeping with our public domain policy in the developers guide CC0 is as I understand it a more useful way to release copyright, while public domain can be american centric. Context - tripped over a

Re: [Geotools-devel] Proposal, adding vendor option support to Rule

Thanks to all that voted here on the list, or directly on the proposal. Not all votes have been cast, but according to our procedures "proposal is accepted ‘automatically’ within 15 days (unless objections are raised )" With

Re: [Geotools-devel] Proposal, adding vendor option support to Rule

+1 On Wed, Mar 24, 2021 at 10:24 AM Simone Giannecchini < simone.giannecch...@geo-solutions.it> wrote: > +0 > > Regards, > Simone Giannecchini > == > GeoServer Professional Services from the experts! > Visit http://bit.ly/gs-services for more information. > == > Ing. Simone Giannecchini >

Re: [Geotools-devel] Proposal, adding vendor option support to Rule

+0 Regards, Simone Giannecchini == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services for more information. == Ing. Simone Giannecchini @simogeo Founder/Director GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax:

[Geotools-devel] Proposal, adding vendor option support to Rule

Hi all, I have written a quick proposal to add vendor options to rules, since it's an API change: https://github.com/geotools/geotools/wiki/Vendor-options-options-map-for-rules Cheers Andrea == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. ==

Re: [Geotools-devel] Proposal: Switch DataAccess DataStore parameters from Map to Map

+1 On Fri, Nov 6, 2020 at 8:59 AM Simone Giannecchini < simone.giannecch...@geo-solutions.it> wrote: > +1 > > Regards, > Simone Giannecchini > == > GeoServer Professional Services from the experts! > Visit http://bit.ly/gs-services for more information. > == > Ing. Simone Giannecchini > @simogeo

Re: [Geotools-devel] Proposal: Switch DataAccess DataStore parameters from Map to Map

+1, looks like a good change and reasonably backwards-compatible. I was going to add a comment about GeoServer compatibility, since the proposal didn't mention it, but I see you've already got a seperate PR for that, so nevermind - everything looks good. Cheers, Torben On Fri, Nov 6, 2020 at

Re: [Geotools-devel] Proposal: Switch DataAccess DataStore parameters from Map to Map

+1 Regards, Simone Giannecchini == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services for more information. == Ing. Simone Giannecchini @simogeo Founder/Director GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax:

Re: [Geotools-devel] Proposal: Switch DataAccess DataStore parameters from Map to Map

+1 for the proposal, I understand the need for Map On Sat, Oct 31, 2020 at 4:01 AM Andrea Aime wrote: > Hi all, > as previously discussed, I've worked on switching DataStore/DataAccess > factory parameters from Map to Map > (yes, ?, not Object, the proposal has rationale for it). > > The

Re: [Geotools-devel] Proposal: Switch DataAccess DataStore parameters from Map to Map

+1 Ian On Sat, 31 Oct 2020 at 11:03, Andrea Aime wrote: > Looks like Github wiki does not like "<" and ">" in the page titles... > updated proposal reference here: > > https://github.com/geotools/geotools/wiki/Switch-DataAccess-DataStore-parameters-map-values-from-String-to-generic-object > >

Re: [Geotools-devel] Proposal: Switch DataAccess DataStore parameters from Map to Map

Looks like Github wiki does not like "<" and ">" in the page titles... updated proposal reference here: https://github.com/geotools/geotools/wiki/Switch-DataAccess-DataStore-parameters-map-values-from-String-to-generic-object Cheers Andrea == GeoServer Professional Services from the experts!

[Geotools-devel] Proposal: Switch DataAccess DataStore parameters from Map to Map

Hi all, as previously discussed, I've worked on switching DataStore/DataAccess factory parameters from Map to Map (yes, ?, not Object, the proposal has rationale for it). The proposal is here:

Re: [Geotools-devel] proposal: change from webdav to nexus

Master is now migrated, there is a pull request to update the docs also. This change should be back ported to active branches (although a redirect is possible our experience last time showed that maven was unable to process redirects). Note users

Re: [Geotools-devel] proposal: change from webdav to nexus

Sounds good, I have updated the wiki page based on this thread. -- Jody Garnett On Mon, 6 Apr 2020 at 16:39, Torben Barsballe wrote: > > 1) I will note that repo.boundlessgeo.com was set up to allow for >

Re: [Geotools-devel] proposal: change from webdav to nexus

1) I will note that repo.boundlessgeo.com was set up to allow for separate repos, we just chose not to use that option in GeoServer. I assume that was just done for convenience, and not for any particular reason... 2) I'm looking at the repo updates in GeoTools, and it turns out GeoTools does not

Re: [Geotools-devel] proposal: change from webdav to nexus

Good thinking, updated the repository accordingly. Worth discussing: 1) The approach has a clear distinction between "snapshot" and "release" repository (previously repo.boundlessgeo.com was used for both snapshots and releases) ... I think this approach will build faster 2) The release

Re: [Geotools-devel] proposal: change from webdav to nexus

One comment on the proposal itself - at least during the migration, we should avoid using the same repository id for the nexus repo as for the webdav repo ("osgeo") to make configuration credential management easier (I've been using "nexus" as the id of the nexus repo so far). If we want to change

Re: [Geotools-devel] proposal: change from webdav to nexus

With the build going out this week we have an opportunity to try out the repository management changes. -- Jody Garnett On Mon, 6 Apr 2020 at 12:16, Jody Garnett wrote: > Catching up on this activity. > > * Tom (and Torben) were able to transfer the vast majority of the > repo.boundlessgeo.com

[Geotools-devel] proposal: change from webdav to nexus

Catching up on this activity. * Tom (and Torben) were able to transfer the vast majority of the repo.boundlessgeo.com content over. * I am running the script to transfer webdav folder over now. To help with communication I wrote this activity up as a proposal here, the work is already in

Re: [Geotools-devel] proposal: reduce proposal time limit to ten days

+0 on length +1 on a limit Ian On Tue, 3 Mar 2020 at 19:36, Jody Garnett wrote: > Our current proposal time limit was set in the days of subversion when we > had a single "trunk" and relatively strong divisions between modules in our > library. The idea being that a 3-day waiting period was

Re: [Geotools-devel] proposal: reduce proposal time limit to ten days

I think 14 days is too much, but looks like everyone else is happy with 14 days, so +0 On Tue, 2020-03-03 at 11:42 -0800, Jody Garnett wrote: > Sorry I should of said 14 days (so that we get a balance of weekend, > workweek, and one of our meetings for discussion). Thanks! > > And here is my +1 >

Re: [Geotools-devel] proposal: reduce proposal time limit to ten days

+1 with having a limit (it's really missing in GeoServer I believe) Don't care too much if 14 or 10 days, minor difference. Cheers Andrea On Tue, Mar 3, 2020 at 8:45 PM Jody Garnett wrote: > Sorry I should of said 14 days (so that we get a balance of weekend, > workweek, and one of our

Re: [Geotools-devel] proposal: reduce proposal time limit to ten days

See other email. I would prefer 10 but if anybody else wants 10 who am I to disagree? Il giorno mar 3 mar 2020 alle 20:43 Jody Garnett ha scritto: > Sorry I should of said 14 days (so that we get a balance of weekend, > workweek, and one of our meetings for discussion). Thanks! > > And here is

Re: [Geotools-devel] proposal: reduce proposal time limit to ten days

Sorry I should of said 14 days (so that we get a balance of weekend, workweek, and one of our meetings for discussion). Thanks! And here is my +1 -- Jody Garnett On Tue, 3 Mar 2020 at 11:35, Jody Garnett wrote: > Our current proposal time limit was set in the days of subversion when we > had

Re: [Geotools-devel] proposal: reduce proposal time limit to ten days

+1 Il giorno mar 3 mar 2020 alle 20:36 Jody Garnett ha scritto: > Our current proposal time limit was set in the days of subversion when we > had a single "trunk" and relatively strong divisions between modules in our > library. The idea being that a 3-day waiting period was good enough for >

[Geotools-devel] proposal: reduce proposal time limit to ten days

Our current proposal time limit was set in the days of subversion when we had a single "trunk" and relatively strong divisions between modules in our library. The idea being that a 3-day waiting period was good enough for feedback before starting work :) To avoid stagnation by lack of

Re: [Geotools-devel] proposal: Approve up to $1500 to support code sprint participants

+1 Cheers, Torben On Tue, Oct 9, 2018 at 1:49 PM Jody Garnett wrote: > I would like to ask the GeoTools PMC to approve the following proposal: > > *Approve up to $1500 to support code sprint participants* > > > Our budget request is here >

Re: [Geotools-devel] proposal: Approve up to $1500 to support code sprint participants

+1 Cheers Andrea On Tue, Oct 9, 2018 at 10:51 PM Jody Garnett wrote: > I would like to ask the GeoTools PMC to approve the following proposal: > > *Approve up to $1500 to support code sprint participants* > > > Our budget request is here >

Re: [Geotools-devel] proposal: Approve up to $1500 to support code sprint participants

+1 On 10/10/2018 08:32 AM, Simone Giannecchini wrote: +1 Regards, Simone Giannecchini == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Simone Giannecchini @simogeo Founder/Director GeoSolutions S.A.S. Via di Montramito 3/A 55054

Re: [Geotools-devel] proposal: Approve up to $1500 to support code sprint participants

+1 Regards, Simone Giannecchini == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Simone Giannecchini @simogeo Founder/Director GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39

Re: [Geotools-devel] proposal: Approve up to $1500 to support code sprint participants

+1 from me Ian On Tue, 9 Oct 2018, 21:49 Jody Garnett, wrote: > I would like to ask the GeoTools PMC to approve the following proposal: > > *Approve up to $1500 to support code sprint participants* > > > Our budget request is here >

[Geotools-devel] proposal: Approve up to $1500 to support code sprint participants

I would like to ask the GeoTools PMC to approve the following proposal: *Approve up to $1500 to support code sprint participants* Our budget request is here where we asked for $1500 help attend bonn code sprint to look at JAI

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

> By the way, how does Jigsaw work with optional dependencies? Can we > still leave out unused dependencies like with the current classpath? Or > will Java 11 spit the dummy? > Good question, here is my speculation: If the dependency is something like log4j and we have adapting code that we can

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

On 27/09/2018 10:01, Jody Garnett wrote: Hey Ben - are you available for the code sprint? Completely understand if you are not being a small business, but we would really love your help. Sorry, I am not likely to be available. Additional comments/confusion inline: On Wed, 26 Sep 2018 at

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

Hey Ben - are you available for the code sprint? Completely understand if you are not being a small business, but we would really love your help. Additional comments/confusion inline: On Wed, 26 Sep 2018 at 14:50, Ben Caradoc-Davies wrote: > Does Jigsaw prevent classpath trickery like

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

Does Jigsaw prevent classpath trickery like gt-xsd-gml3 org.geotools.referencing.crs.EPSGCRSAuthorityFactory? This is required to make tests pass in Eclipse. Are modules like gt-app-schema that define classes in several packages also defined in other modules affected by this change? I guess

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

On Wed, Sep 26, 2018 at 8:12 PM Jody Garnett wrote: > > "I think it is a requirement for the work". The work is "Restructure >> GeoTools into Jigsaw modules" and covers two items: >> * Providing an automatic module name for each jar >> * Refactoring the codebase to avoid package conflicts >> >>

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

> "I think it is a requirement for the work". The work is "Restructure > GeoTools into Jigsaw modules" and covers two items: > * Providing an automatic module name for each jar > * Refactoring the codebase to avoid package conflicts > > Can you explain how this package renaming is required for the

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

On Tue, Sep 25, 2018 at 9:13 PM Jody Garnett wrote: > I like the direction, but does not seem a requirement, more of a nice to >> have. Can we do it towards the end, when everything >> is building and ready to merge in mainline? >> > > We may be able to move it near the end - but I think it is a

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

Okay Java 11 is here: - http://jdk.java.net/11 - https://www.oracle.com/technetwork/java/javase/downloads/jdk11-downloads-5066655.html I would like to start on branch for this restricting on Friday, or experiment to resolving any feedback/questions from this discussion thread. Candidates for

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

1. remove org.opengis packages > >> It seems like good timing, and with the module system any conflict over >> org.opengis packages will be more keenly felt. >> >> Here is the proposal renaming org.opengis to org.geotools.api: >> - org.geotools.api.filter.Filter >> -

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

Thanks for the discussion - you have given me some items to think about. For the plugins I only found a few conflicts, gt-epsg-hsql for example, where an implementation uses the same package name on purpose (I think to access some package visible API). Technically there is one other approach to

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

On Fri, Sep 21, 2018 at 8:10 PM Jody Garnett wrote: > That is great - which book? > This one, in its current "early access" version: https://www.manning.com/books/the-java-module-system So far good book, the prose flows and has good information. > 1. remove org.opengis packages > > It seems

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

That is great - which book? I trust your intelligence on a wide range of matters, while you research the technical side - there are a couple strategic decisions in the middle of this proposal that I would appreciate your guidance / input on. 1. remove org.opengis packages It seems like good

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

Hi Jody, I got myself a book on java modularity and reading through it in my spare time. Will take a couple of weeks I believe before I can add any intelligent comment on the proposal, sorry :-) Cheers Andrea On Tue, Sep 18, 2018 at 1:18 AM Jody Garnett wrote: > Proposal is here: Restructure

Re: [Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

I've looked over the proposal, and we reviewed it during yesterday's PMC meeting. First off, thanks for putting this together. During discussion, you mentioned we could have Eclipse generate a refactoring script to use when refactoring other projects to conform to the GeoTools API changes -

[Geotools-devel] proposal: Restructure GeoTools into Jigsaw modules

Proposal is here: Restructure GeoTools into Jigsaw modules Feedback welcome, I expect we will have some discussion before voting. -- Jody Garnett ___ GeoTools-Devel

Re: [Geotools-devel] Proposal: Allow usage of expressions in SelectChannelName

+1 Had nothing to add to the discussion :) On Wed, Jun 20, 2018 at 5:21 AM Andrea Aime wrote: > Ok, thanks everybody for your vote. > The request for vote has been out for a couple of weeks and the PR is > ready for merging so... merging :-) > > Cheers > Andrea > > On Tue, Jun 19, 2018 at 5:51

Re: [Geotools-devel] Proposal: Allow usage of expressions in SelectChannelName

Ok, thanks everybody for your vote. The request for vote has been out for a couple of weeks and the PR is ready for merging so... merging :-) Cheers Andrea On Tue, Jun 19, 2018 at 5:51 PM, Simone Giannecchini < simone.giannecch...@geo-solutions.it> wrote: > Ouch, > I am +1 on this one while I

Re: [Geotools-devel] Proposal: Allow usage of expressions in SelectChannelName

Ouch, I am +1 on this one while I wait for the Raster Algebra integration ;) Regards, Simone Giannecchini == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Simone Giannecchini @simogeo Founder/Director GeoSolutions S.A.S. Via di

Re: [Geotools-devel] Proposal: Allow usage of expressions in SelectChannelName

Hi folks, the proposal has been out a couple of weeks, anyone else plans to vote? We're missing Simone and Jody Cheers Andrea On Wed, Jun 6, 2018 at 4:38 PM, Andrea Aime wrote: > We already discussed in on the mailing list a bit, here is the format > proposal: > >

Re: [Geotools-devel] Proposal: Allow usage of expressions in SelectChannelName

+1. That looks quite useful. Kind regards, Ben. On 07/06/18 02:38, Andrea Aime wrote: We already discussed in on the mailing list a bit, here is the format proposal: https://github.com/geotools/geotools/wiki/Allow-usage-of-expressions-in-SelectChannelName Votes welcomed (and discussion too,

Re: [Geotools-devel] Proposal: Allow usage of expressions in SelectChannelName

On Wed, Jun 6, 2018 at 4:46 PM, Ian Turton wrote: > +1 from me. > Thanks! > PS now I'm worried I should have done a proposal for the change to like > filters to take expressions instead of propertynames (but I thought it was > just a bug :-)) > Why don't we discuss it on a separate mail,

Re: [Geotools-devel] Proposal: Allow usage of expressions in SelectChannelName

+1 from me. Ian PS now I'm worried I should have done a proposal for the change to like filters to take expressions instead of propertynames (but I thought it was just a bug :-)) On Wed, 6 Jun 2018 at 15:38, Andrea Aime wrote: > We already discussed in on the mailing list a bit, here is the

[Geotools-devel] Proposal: Allow usage of expressions in SelectChannelName

We already discussed in on the mailing list a bit, here is the format proposal: https://github.com/geotools/geotools/wiki/Allow-usage-of-expressions-in-SelectChannelName Votes welcomed (and discussion too, in case you missed it previously) :-) Cheers Andrea == GeoServer Professional Services

Re: [Geotools-devel] Proposal: Refactor ImageMosaic index management

As discussed during the meeting, I am going to merge now. Regards, Simone Giannecchini == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Simone Giannecchini @simogeo Founder/Director GeoSolutions S.A.S. Via di Montramito 3/A 55054

Re: [Geotools-devel] Proposal: Refactor ImageMosaic index management

Yes, we worked together to isolate the changes into simple SPI mechanism. Regards, Simone Giannecchini == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Simone Giannecchini @simogeo Founder/Director GeoSolutions S.A.S. Via di Montramito

Re: [Geotools-devel] Proposal: Refactor ImageMosaic index management

Dear All, me, Devon and Jody have worked together on refining the code being the proposal to round some corners. Now I can give my +1. Regards, Simone Giannecchini == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Simone Giannecchini

[Geotools-devel] Proposal: MosaicProducer changes

Hi all, Consider this email a pre-proposal of sorts, since we don't have a proposal for it ready yet, but wanted to get the ball rolling ASAP for feedback and discussion. Should have an actual proposal written soon-ish. As some of you know we've been working on support for heterogenous CRS with

Re: [Geotools-devel] Proposal: Refactor ImageMosaic index management

Dear Devon, some feedback on the proposal: -1- I would rename GranuleGeometryHandler to GranuleHandler (or something GranuleiNDEXHandler) like sine one can pretty much do anything with this -2- I would want two different methods just one like: void handleGeometry(

Re: [Geotools-devel] Proposal: Refactor ImageMosaic index management

Thanks, proposal is clear, scope/purpose clear, technical details are easier to follow with class diagram. +1 And it looks like you are pretty much done the work, except for user docs... -- Jody Garnett On 21 June 2016 at 17:04, Devon Tucker wrote: > Yes, it's ready

Re: [Geotools-devel] Proposal: Refactor ImageMosaic index management

Yes, it's ready for review :D On Tue, Jun 21, 2016 at 5:01 PM, Jody Garnett wrote: > We can always squash the commits when merging to master. > > Is the proposal ready for review now? > > -- > Jody Garnett > > On 21 June 2016 at 16:55, Devon Tucker

Re: [Geotools-devel] Proposal: Refactor ImageMosaic index management

We can always squash the commits when merging to master. Is the proposal ready for review now? -- Jody Garnett On 21 June 2016 at 16:55, Devon Tucker wrote: > Ok so after going down the road of using the PropertiesCollector interface > for doing the granule geometry

Re: [Geotools-devel] Proposal: Refactor ImageMosaic index management

Ok so after going down the road of using the PropertiesCollector interface for doing the granule geometry handling and decided to go with my original plan of creating a separate interface for this. I have updated the proposal accordingly. Also, I created a pull request for reference, since it

Re: [Geotools-devel] Proposal: Refactor ImageMosaic index management

The GranuleAcceptor stuff is done on that branch. I have the PropertiesCollector stuff done locally, but there's some iffy stuff there. Handling the granule envelope in a PropertiesCollector should be fine, but there is an issue with how StructuredGridCoverages are handled:

Re: [Geotools-devel] Proposal: Refactor ImageMosaic index management

Reviewing https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-Index-and-Catalog-management-for-improved-extensibility it appears up to date (with a remove CatalogManager heading). Are you going to verify the approach (on that branch) and then send us an email for the completed proposal?

Re: [Geotools-devel] Proposal: Refactor ImageMosaic index management

Hi all, Based on discussions with Simone and Jody we have made a few changes to this proposal: - CatalogManager gets deleted, its methods moved either to ImageMosaicConfigHandler, Utils, or the GranuleCatalog implementations - Instead of delegating granule acceptance to CatalogManager, as was

Re: [Geotools-devel] Proposal: Refactor ImageMosaic index management

Dear Devon, a few things: -0- we should really get rid of this CatalogManager as is (a class with only static methods as its state its spread over N other classes) -1- we can already mosaick images with different colormodels (to a certain extent, it does not make sense to mosaick a float raster

[Geotools-devel] Proposal: Refactor ImageMosaic index management

Hi all, After discussions about the ImageMosaic API proposal we have decided to break it up into a few smaller pieces that are hopefully both more manageable to implement and easier to understand. First up is a proposal to refactor the ImageMosaic CatalogManager to allow parts of it to be

Re: [Geotools-devel] Proposal: ask OSGeo for legal advice on copyright headers

Thanks Ben, the board has agreed to help (and have an open source law firm they have worked with previously). -- Jody Garnett On 6 June 2016 at 12:54, Ben Caradoc-Davies wrote: > Jody, > > the vote of the committee is unanimous: > > Andrea Aime: +1 > Ben Caradoc-Davies: +1 >

Re: [Geotools-devel] Proposal: ask OSGeo for legal advice on copyright headers

Jody, the vote of the committee is unanimous: Andrea Aime: +1 Ben Caradoc-Davies: +1 Christian Mueller: +1 Ian Turton: +1 Jody Garnett: +1 Justin Deoliveira: +1 Simone Giannecchini: +1 Kind regards, Ben. On 01/06/16 07:56, Ben Caradoc-Davies wrote: > I propose that we ask OSGeo to: "Obtain

Re: [Geotools-devel] proposal:

Ignore that: I think *everyone* has voted. Jody, I will summarise. Is there anything else you need? On 07/06/16 07:47, Ben Caradoc-Davies wrote: > I asked in my email last week, but have not yet received any more votes. > > On 07/06/16 06:08, Jody Garnett wrote: >> The 2nd person with an action

Re: [Geotools-devel] proposal:

I asked in my email last week, but have not yet received any more votes. On 07/06/16 06:08, Jody Garnett wrote: > The 2nd person with an action item is Ben (who is asking the PSC to > authorize me to get legal advice via OSGeo). -- Ben Caradoc-Davies Director Transient

Re: [Geotools-devel] proposal:

You are quick, I am making the pull request now - if you can review and merge. The 2nd person with an action item is Ben (who is asking the PSC to authorize me to get legal advice via OSGeo). -- Jody Garnett On 6 June 2016 at 11:06, Justin Deoliveira wrote: > Thanks Jody!

Re: [Geotools-devel] proposal:

Thanks Jody! I got a little lost in the shuffle so can you let me know what the next steps are for me? You had mentioned that you had some changes to the dev guide that you wanted me to review? On Mon, Jun 6, 2016 at 12:04 PM Jody Garnett wrote: > This motion is now

Re: [Geotools-devel] proposal:

This motion is now passed: "Apply OSGeo copyright on creation/contribution" And response via email: - Andrea Aime +1 (second) - Ben Caradoc-Davies +1 - Christian Mueller +1 - Ian Turton +1 - Jody Garnett +1 (motion) - Justin Deoliveira +1 - Simone Giannecchin +1 Community

Re: [Geotools-devel] proposal:

Hi Added my +1 to the proposal Cheers On Wed, Jun 1, 2016 at 8:49 PM, Ben Caradoc-Davies wrote: > Have you seen my old ring? I seem to have lost it. :-) > > On 02/06/16 00:48, Justin Deoliveira wrote: > > Been a long road to get essentially back to > > where we started :)

Re: [Geotools-devel] proposal:

Thanks, we are currently at: - Andrea Aime +1 (second) - Ben Caradoc-Davies +1 - Christian Mueller - Ian Turton +1 - Jody Garnett +1 (motion) - Justin Deoliveira +1 - Simone Giannecchini +1 Community response: - Torben: Seems like a good idea I am going to start on a

Re: [Geotools-devel] proposal:

Have you seen my old ring? I seem to have lost it. :-) On 02/06/16 00:48, Justin Deoliveira wrote: > Been a long road to get essentially back to > where we started :) -- Ben Caradoc-Davies Director Transient Software Limited New Zealand

Re: [Geotools-devel] proposal:

Updated proposal with my +1. Been a long road to get essentially back to where we started :) On Wed, Jun 1, 2016 at 2:34 AM Ian Turton wrote: > +1 > > Ian > On 31 May 2016 23:57, "Jody Garnett" wrote: > >> We have the following motion: >> >>

Re: [Geotools-devel] Proposal: ask OSGeo for legal advice on copyright headers

+1 Ian On 31 May 2016 21:57, "Ben Caradoc-Davies" wrote: > I propose that we ask OSGeo to: "Obtain legal advice on the need for and > form of source code copyright headers." > > So far we have three +1 votes but we need more. PMC? > > Kind regards, > > -- > Ben Caradoc-Davies

Re: [Geotools-devel] proposal:

+1 Ian On 31 May 2016 23:57, "Jody Garnett" wrote: > We have the following motion: > > "Apply OSGeo copyright on creation/contribution" > > And response via email: > >- Andrea Aime +1 (second) >- Ben Caradoc-Davies +0 (agreement but no clear vote) >-

  1   2   3   4   5   6   >