See http://hudson.opengeo.org/hudson/job/geotools-2.5.x/298/changes
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterp
See http://hudson.opengeo.org/hudson/job/geotools-2.5.x/297/changes
--
started
Updating http://svn.osgeo.org/geotools/branches/2.5.x
At revision 32562
no change for http://svn.osgeo.org/geotools/branches/2.5.x since the previous
build
[gt_2.5.x] $ /opt/mave
See http://hudson.opengeo.org/hudson/job/geotools-2.5.x/296/changes
Changes:
[jdeolive] GEOT-2360, changed update and remove to check locks
[jdeolive] made createSchemaLocator() and createSchemaLocationResolver()
public, backport from trunk
--
started
Up
remove and update features on jdbc datastore does not take into account feature
locking
---
Key: GEOT-2360
URL: http://jira.codehaus.org/browse/GEOT-2360
Project: Geo
Many thanks for this further progress report Martin. Having an
untangled version of that part of the library will be so good !
Michael
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC
Rob Atkinson wrote:
> (warning - rhetorical question) Why do we want a SimpleFeature at all?
> It seems to me to be partly to implement an implied contract with all
> the previous users of Feature, not because there is any intrinsic
> reason that any of the previous uses actually needs to have the
Attribute order is in fact important. ISO have specified a
"implementation hint - aka a UML tag - for attribute order. Simon Cox
tells me is a technically mandatory part of the meta-model for
features - I'll chase dow the reference if anyone cares that much :-)
.
Rob
On Sat, Feb 28, 2009 at 3:15
Great to see the progress, and such constructive support from the community.
I'm not so sure I like the sound of moving the SimpleFeatureType out
of the hierarchy, though I suppose it does implement the
GeneralFeature API...
(warning - rhetorical question) Why do we want a SimpleFeature at all?
See http://hudson.opengeo.org/hudson/job/geotools-2.5.x/295/changes
Changes:
[groldan] GEOT-1744 backport the latest improvements to arcsde raster catalog
support
--
started
Updating http://svn.osgeo.org/geotools/branches/2.5.x
U
modules/plugin/a
Hi all,
The release train for geoserver 1.7.3 has started so I wanted to give a
heads up that we will be releasing gt 2.5.4 soon. For those developing
on 2.5.x i was hoping to start building the release next week. If you
you see any conflicts or prefer that I wait please me know.
Thanks,
-Jus
See http://hudson.opengeo.org/hudson/job/geotools-2.5.x/294/changes
Changes:
[jdeolive] set svn:ignore
[jdeolive] GEOT-2345, handling of maxFeatures specified by client
--
[...truncated 84 lines...]
[INFO] Temporal implementation
[INFO] Web Coverage S
Patch applied. Shall we open a new issue for breaking simple feature
type out of the complex type class hierarchy?
Justin Deoliveira wrote:
> Ok, I propose applying Ben's patch for the moment since simple feature
> type is pretty clearly broken. And make the clean break from the super
> class a
Hello again!
Jody Garnett wrote:
> Oh the reason is simple - the SLDParser has a job to do - namely parsing
> SLD files.
> If we are starting to work with UOM information we are looking at
> parsing SE files.
Ahm, sorry, ignorant here again: isn't the SLDParser already doing lots
of SE-specifi
Ok, I propose applying Ben's patch for the moment since simple feature
type is pretty clearly broken. And make the clean break from the super
class a separate issue.
Jody Garnett wrote:
> Hi Ben sorry to be slow to respond to this one; I am busy prepping for a
> meeting with Simone. I do have y
Gabriel Roldán wrote:
> On Thursday 26 February 2009 02:04:15 Jody Garnett wrote:
> > On Thu, Feb 26, 2009 at 2:54 PM, Ben Caradoc-Davies
> >
> > wrote:
> > > Justin Deoliveira wrote:
> > >> Changing the Query API will affect every DataStore. If this is done by
> > >>
> > >>> expanding Quer
Andrea Aime wrote:
> Ben Caradoc-Davies wrote:
>> I can either:
>> (1) Fix SimpleFeatureTypeBuilder.
>> (2) Implement a new WFSConfiguration that does not use
>> GML{2,3}EncoderUtils, and figure out how to get GeoServer to use it.
>
> Just to add my usual performance perspective to the mix, the g
Justin Deoliveira a écrit :
> This only affects geotools trunk correct? If so there should be no
> issues from our side.
Yes, as suggested by Jody GeoTools 2.5 stay unchanged on GeoAPI 2.2-SNAPSHOT.
We
can even do "pseudo-formal" release of GeoAPI 2.2 if this is useful to GeoTools.
Mar
On Thursday 26 February 2009 02:04:15 Jody Garnett wrote:
> On Thu, Feb 26, 2009 at 2:54 PM, Ben Caradoc-Davies
>
> wrote:
> > Justin Deoliveira wrote:
> >> Changing the Query API will affect every DataStore. If this is done by
> >>
> >>> expanding Query and DefaultQuery as you indicated, it shoul
Ben Caradoc-Davies wrote:
> I can either:
> (1) Fix SimpleFeatureTypeBuilder.
> (2) Implement a new WFSConfiguration that does not use
> GML{2,3}EncoderUtils, and figure out how to get GeoServer to use it.
Just to add my usual performance perspective to the mix, the gt-xsd
encoder is 2-4 times sl
Jody Garnett wrote:
>
>
> On Thu, Feb 26, 2009 at 2:54 PM, Ben Caradoc-Davies
> wrote:
>
> Justin Deoliveira wrote:
>
> Changing the Query API will affect every DataStore. If this
> is done by expanding Query and DefaultQuery as you
> indicated, it shou
Martin Desruisseaux wrote:
> Jody is ready to commit on the GeoTools SVN an upgrate from GeoAPI
> dependency,
> from 2.2-SNAPSHOT to 2.3-SNAPSHOT.
>
> There is at this time absolutly no API change. The only impact is that the
> Maven
> dependency declared in the pom.xml file, which was "geoapi
Christian Müller a écrit :
> Do you have a possiblity to initialze this instance variable with the
> default locale (Sun sdk does it, ibm sdk not) ?
I was expecting this locale to get the value of the actual Locale found by
ResourceBundle.getBundle(...), which may or may not be the default local
Yes, the problem is a null value in the locale instance var of
java.util.ResourceBundle, I did a debugging session and can confirm this
problem.
Do you have a possiblity to initialze this instance variable with the
default locale (Sun sdk does it, ibm sdk not) ?
Afterwards, can you send me
Hello Christian
Thanks for your encouragement with java.util.concurrent. I'm quite pleased with
it. It took me a few hours to get used to think in terms of "putIfAbsent" or
"replace" instead of the usual "get" and "put", but once I get used it was
really a charm.
Christian Müller a écrit :
> D
I am lucky to hear that you use the java.util.concurrent package. I did the
same with my imagemosaic-jdbc module, starting a thread for decoding each
tile and putting the resulting java image in a queue.
On an AIX ppc using 4 CPUs I get a CPU usage up to 390 %, which shows me
that the package
Jody is ready to commit on the GeoTools SVN an upgrate from GeoAPI dependency,
from 2.2-SNAPSHOT to 2.3-SNAPSHOT.
There is at this time absolutly no API change. The only impact is that the
Maven
dependency declared in the pom.xml file, which was "geoapi", would become
"geoapi-pending" for most
I'm close to the end. The port of the EPSG factory is under progress and I'm at
last looking at the "Threaded EPSG factory" work which was done a few years
ago.
In the process I rewrote some piece of code in order to take advantage of the
java.util.concurrent package, which we were not allowed
Understood; I am ready to commit on my end.
On Fri, Feb 27, 2009 at 8:24 PM, Martin Desruisseaux <
martin.desruisse...@geomatys.fr> wrote:
> Hello Jody
>
> I'm fine with aligning GeoTools trunk on GeoAPI 2.3-SNAPSHOT and keeping
> GeoAPI 2.2-SNAPSHOT for GeoTools 2.5. The change on trunk can be a
Hello Jody
I'm fine with aligning GeoTools trunk on GeoAPI 2.3-SNAPSHOT and keeping GeoAPI
2.2-SNAPSHOT for GeoTools 2.5. The change on trunk can be applied at any time
people wish. If you already did that, maybe you can just commit after we get
the
okay from other?
Martin
--
29 matches
Mail list logo
