Andrea Aime wrote:
Also, filter capabilities as is may not handle this case
properly. The thing is, the capabilities as of today tell
us which filters and functions the datastore supports
_natively_, whilst for these dynamic function case,
we'd need an information on whether the function is
Justin Deoliveira ha scritto:
Technically... but we have not been doing a very good job of holding to
it as commits keep coming in :). So commit what you need to. It does not
seem there is much point to calling a freeze until we are sure we will
be releasing.
Does it mean I can backport
I mean, patching a known problem, testcase provided, a core developer
has checked the patch. I would say go ahead.
Simone.
On Tue, Oct 21, 2008 at 11:49 AM, Simone Giannecchini
[EMAIL PROTECTED] wrote:
I think we are safe with the commit.
Simone.
On Tue, Oct 21, 2008 at 11:45 AM, Andrea
See http://hudson.opengeo.org/hudson/job/geotools-trunk/1080/changes
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great
I think we are safe with the commit.
Simone.
On Tue, Oct 21, 2008 at 11:45 AM, Andrea Aime [EMAIL PROTECTED] wrote:
Justin Deoliveira ha scritto:
Technically... but we have not been doing a very good job of holding to it
as commits keep coming in :). So commit what you need to. It does not
Hi list, I am working in the TXT proposal
http://docs.codehaus.org/display/GEOTOOLS/Extention+of+CQL+to+match+abilities+of+Filter
A week ago, we was analysing a possibility to improve the spatial relation
predicates.
Nowadays, TXT implements the spatial predicate - OGC Filter 1.1 - That is
Mauricio Pazos ha scritto:
Hi list, I am working in the TXT proposal
http://docs.codehaus.org/display/GEOTOOLS/Extention+of+CQL+to+match+abilities+of+Filter
A week ago, we was analysing a possibility to improve the spatial relation
predicates.
Nowadays, TXT implements the spatial
Hi list,
since freeze seems actually delayed, I would like to committ a little
improvement on GeoTiff metadata parser which should allow to better manage
Mercator projection.
If it's ok, I will committ it.
Daniele
On Tue, Oct 21, 2008 at 11:49 AM, Simone Giannecchini [EMAIL PROTECTED]wrote:
I
+1, it is a needed fix and it is pain-free.
Simone.
On Tue, Oct 21, 2008 at 3:11 PM, Daniele Romagnoli
[EMAIL PROTECTED] wrote:
Hi list,
since freeze seems actually delayed, I would like to committ a little
improvement on GeoTiff metadata parser which should allow to better manage
Mercator
Fair enough. I do ask one thing though. That commits are made against
jira issues. I am trying to figure out what has changed between 2.5.0
and 2.5.1 and am realizing none of the commits are being tracked against
bug fixes. Makes it hard to generate a change log.
Simone Giannecchini wrote:
CRS2GeoTiffMetadataAdapter doesn't properly handle latitude_of_origin mercator
parameter for Mercator_1/2SP projection
--
Key: GEOT-2092
URL:
Hi Justin,
I have pressed the create button on JIRA a second before I have received
this email :)
Daniele
On Tue, Oct 21, 2008 at 5:48 PM, Justin Deoliveira [EMAIL PROTECTED]wrote:
Fair enough. I do ask one thing though. That commits are made against jira
issues. I am trying to figure out
Hi all,
I would like to start the GeoTools 2.5.1 / GeoServer 1.7.0 release
trains today. I know commits are still trickling into 2.5.x so if folks
could give me the go ahead when everything they want in is committed I
can start the qa and testing phase for the release.
-Justin
--
Justin
Cool, thanks Daniele :)
Daniele Romagnoli wrote:
Hi Justin,
I have pressed the create button on JIRA a second before I have
received this email :)
Daniele
On Tue, Oct 21, 2008 at 5:48 PM, Justin Deoliveira [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Fair enough. I do ask
Improved handling of GeoTIFF metadata
-
Key: GEOT-2093
URL: http://jira.codehaus.org/browse/GEOT-2093
Project: GeoTools
Issue Type: Improvement
Components: gc geotiff
Affects Versions: 2.5.0
Sorry, one more request. To include the jira key in the commit message.
Not sure if that was clear or not, thanks! :).
Daniele Romagnoli wrote:
Hi Justin,
I have pressed the create button on JIRA a second before I have
received this email :)
Daniele
On Tue, Oct 21, 2008 at 5:48 PM,
+1 for me as well frm the other guys on this side
On Tue, Oct 21, 2008 at 5:59 PM, Justin Deoliveira [EMAIL PROTECTED] wrote:
Hi all,
I would like to start the GeoTools 2.5.1 / GeoServer 1.7.0 release
trains today. I know commits are still trickling into 2.5.x so if folks
could give me the
So does this mean I can resolve this issue? Or is it still in progress?
http://jira.codehaus.org/browse/GEOT-2058
Simone Giannecchini wrote:
+1 for me as well frm the other guys on this side
On Tue, Oct 21, 2008 at 5:59 PM, Justin Deoliveira [EMAIL PROTECTED] wrote:
Hi all,
I would like
I am sure daniele fixed it for the 2.5.x branch, I am not sure he
already ported to trunk.
So the answer is you can go ahead, tomorrow I'll make sure he has
forward ported the patch.
Simone.
On Tue, Oct 21, 2008 at 6:47 PM, Justin Deoliveira [EMAIL PROTECTED] wrote:
So does this mean I can
Hi Garbiel; I am going to be mostly out of touch over the next couple of
weeks can you field this one.
If this is indeed a case we do not handle well then we will need to go
through the usual process; make a change proposal etc...
I do understand the central conflict; a simple type and a
Ben Caradoc-Davies wrote:
Andrea Aime wrote:
Also, filter capabilities as is may not handle this case
properly. The thing is, the capabilities as of today tell
us which filters and functions the datastore supports
_natively_, whilst for these dynamic function case,
we'd need an information
On Tuesday 21 October 2008 15:07:23 Andrea Aime wrote:
Both syntaxes are fine to me, I'd suggest to choose
the one that keeps the module the simplest and/or
takes less time to implement.
I agree, the first syntax (function like) is implemented. My idea is to close
this iteration now and extend
Hi Cedric,
Any chance you would be willing to generate the 2.5.1 javadocs for us?
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
-
This SF.Net email is sponsored
I was having an issue in uDig with loading WFS data.
The problem boiled down to Geotools trying to encode a filter that
looked similar to Filter.EXCULDES AND bbox This encoding failed
because org.opengis.filter.ExcludeFilter cannot be cast to
org.geotools.filter.Filter.
The simple
I've done a bunch more digging on this error and am going to attempt to
describe what I've discovered.
When the feature schema is read for the topp:states layers if parses
this request:
http://localhost:8765/geoserver/wfs?request=DescribeFeatureTypeSERVICE=WFSVERSION=1.0.0TYPENAME=topp:states
25 matches
Mail list logo
