Hi.
In the context of gvtools, we have a basic viewer with selection
capabilities. We have followed this approach[1] to manage selection
and as long as there is no selection (empty SetFeatureId), rendering
is ok. However, the bigger the SetFeatureId holding the selection
is, the slower the
Niels
The Proposal:
http://docs.codehaus.org/display/GEOTOOLS/Separate+general+complex+feature+classes+from+gt-app-schema
Please vote, or provide criticism.
Kind Regards
Niels Charlier
--
LogMeIn Rescue: Anywhere, Anytime
See http://hudson.opengeo.org/hudson/job/geotools-master-docs/1850/
--
Started by upstream project geotools-master build number 4651
[INFO] Using Maven 3 installation: maven-3.0.4
[INFO] Checking Maven 3 installation environment
[workspace] $
See http://hudson.opengeo.org/hudson/job/geotools-master-docs/1851/
--
This message is automatically generated by Hudson.
For more information on Hudson, see: http://hudson-ci.org/
--
LogMeIn Rescue: Anywhere, Anytime
Folks,
I have been seeking to have Google sign a corporate CLA
to cover contributions to the GeoTools projects so we could
feed back a few existing improvements, and some future
potential improvements. During internal review of the CLA
we have encountered some concerns from our legal staff.
Thanks for contacting us Frank, we have not had any feedback to this effect
previously.
I am sure we can tightening up the language in the CLA, and could issue a new
version of the document following our usual change procedure.
Our project is open allowing you to assemble a proposal to change
On 12 December 2012 09:06, Jody Garnett jody.garn...@gmail.com wrote:
If we stole some of the language from here ( or here ) would it be
appropriate? Or even just GeoTools is an open source Java library that
provides tools for geospatial data. from our website.
The reason the scope of our
Good idea. I also like our traditional 'toolkit' wording. Perhaps we should ask
Frank to provide an example of a project wording google is comfortable with?
(This after all an agreement which wants to be specific - rather than a project
tag line)
We could get all technical and discuss project
Thanks for the investigation. Report the issue with patch test case. Or via
pull request and we should be good to go.
In many cases functionality such as this was tested with small data sets for
completeness / correctness and can be revisited now that we work with larger
datasets and an
+1. This change is long overdue and much needed. I have asked Rini and
Adam to review the proposal. gt-app-schema changes should go for review
to Rini as component lead.
Kind regards,
Ben.
On 11/12/12 19:15, Niels Charlier wrote:
The Proposal:
We could even say software as well. Should we drop Java? There might
be Python, Javascript, and Scala bits, and more in the future. The Java
bit is descriptive, but not definitive. We could go crazy and rewrite it
in another language, like a future version of Java (I think you know who
I am
On 12 December 2012 12:36, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au wrote:
Framework is a bit too generic in my opinion. I think we need to include the
word software to make it clear that we are not talking about a physical
thing, which I think, from my reading of Frank's email, is
On 12/12/12 10:59, Michael Bedward wrote:
I read their concern as being that the current wording was so open it
was asking them to sign up to an undefined and possibly moving target.
Probably any of software or toolkit or framework or library and
utilities etc. would be an improvement.
I
14 matches
Mail list logo
