Martin Da
Participants
---
Alessio Fabiani
Andrea Aime
Ben Caradoc Davies
Jody Garnett
Justin Deoliveira
Agenda
---
* Time boxed releases proposal
* RC and final for GeoTools and GeoServer
* CITE
* GeoTools Proposals
* Rendering transformations - ask Martin
Action items
--
The following is not yet done:
-
http://docs.codehaus.org/display/GEOTOOLS/Detailed+Argument+and+Return+Info+for+FunctionName
- http://jira.codehaus.org/browse/GEOT-3569
We may wish to open a separate Jira to handle updating the existing function
parameters; or mark it down as technical debt.
We have the following proposals listed as inflight:
- http://docs.codehaus.org/display/GEOTOOLS/Add+ability+to+remove+feature+types
The proposal is a straight forward removeSchema(String typeName) method; it
has not been touched since 2010 so I am marking it withdrawn.
- http://docs.codeha
Okay thanks.
Moved the proposal under 8.x; I assume we just did not record the voting
against it (or it got lost in the same voting around match case being needed
for the WFS 2.0 and Filter 2.0 work).
--
Jody Garnett
On Monday, 11 June 2012 at 8:00 PM, Mauricio Pazos wrote:
>
> On Monday,
Hi Adam,
Thanks for the explanation. I would argue that this is really an
implementation detail. The semantics seem the same to me, an
attribute/property value added to the feature. Perhaps append() might still
make sense in the light that complex features can have multiple values for
a single pro
On Monday, June 11, 2012 07:04:10 PM Jody Garnett wrote:
> Evening Maurcio:
>
> I am reviewing the outstanding proposals and came across:
> - http://docs.codehaus.org/display/GEOTOOLS/New+ILIKE+statement
>
> Most of the work (API change and so on) is now done as part of the WFS 2.0
> updates.
>
There has been no interest in these:
- http://docs.codehaus.org/display/GEOTOOLS/Publish+to+Maven+Central+Repository
- http://docs.codehaus.org/display/GEOTOOLS/Replacing+the+OLD+GCE+interfaces
-
http://docs.codehaus.org/display/GEOTOOLS/Add+bundle+information+to+jar+manifest
-
http://docs.cod
Evening Maurcio:
I am reviewing the outstanding proposals and came across:
- http://docs.codehaus.org/display/GEOTOOLS/New+ILIKE+statement
Most of the work (API change and so on) is now done as part of the WFS 2.0
updates.
Your description indicated two remaining tasks:
- Update the CQL or ECQL
Hi Justin,
What I meant by ComplexFeatureBuilder.append(Name, Property) and
SimpleFeatureBuilder.add(Object) being semantically different is that the
append(...) method associates a Property with a specific Name (this is
necessary for schemata that have multi-valued types) whereas add(...) just
Andrea Ai
Hi all,
first off, sorry for the late bad habit of cross positing to the two
communities :-p
We already discussed the idea of using a time boxed model for relases in
the two communities some time ago with general positive feedback.
I've prepared a formal proposal for it here:
http://geoserver.org
> PPIO are needed if you want a well rounded wps client, but I don't
> see how you need them in the process api?
>
>
I don't.
> And even in case of the WPS client, there is nothing to reverse engineer
> that I know of, they could be used pretty much as is.
> Can you clarify?
>
>
They ar
> So yeah, while WPS per se is still not ready for GeoServer core
> (over my dead body as long as it lacks of service limits and ability
> to hide processes),
>
>
Agreed.
> the process API looks like something we can commit to once these
> fixes are in.
>
>
That would make me cheerful / moti
Hi all,
have been looking at the proposal, I have to say I'm finding it difficult
to read as it crams into a single proposal a number of changes that
can be related togheter only under the assumption that one is
making a new wfs data store, and as such they do require some
familiarity with how the
On Sun, Jun 10, 2012 at 5:34 AM, Martin Davis wrote:
>> One borderline case would be a process that has no support for progress
>> notification, yet can take long and is not streaming.
>> I'd argue such process is likely broken, but implementors might argue back
>> that adding progress support is
On Sat, Jun 9, 2012 at 1:00 AM, Andrea Aime wrote:
> On Sat, Jun 9, 2012 at 9:21 AM, Martin Davis wrote:
> > So maybe provide both synch and asynch annotation attributes, but default
> > them both to true, so that the only thing that really needs to be
> supplied
> > is synch=false for long-runni
17 matches
Mail list logo
