Brent Owens ha scritto:
> Yeh sounds good.
> 1.4 seems stable and ready so I say we make the official release friday.
Friday? Brent, Friday means you have to do gt2 and geoserver release all
alone, I'm not around that day of the week...
Cheers
Andrea
-
Cory Horner a écrit :
> Ah, so someone using 1.1.3 has managed to get the tests to pass? A
> couple months ago I upgraded to 1.1.3, watched the uDig reprojection
> code die, and quickly reverted (it seemed that some important classes
> had been removed). So 1.1.3 actually works :)? (I kept get
Hi Gianluca,
I am forwarding your email to the geotools list where they will be
better able to answer your question.
Maybe one of the Oracle datastore developers can jump in and help.
If you could supply us with some more information on what you are trying
to accomplish and what is holding you
I think Cory is talking about 2.2.x. I also was unable to build with
1.1.3 (or I think that was the version at the time). It was
essentially any GridCoverage plugin that would fail. I finally
switched back to the old version from before the open sourcing of it.
Jesse
On 29-Nov-06, at 3:
I installed the version with native code ... you got a geotools test
case capturing the reported problem?
Jody
> Jody Garnett wrote:
>
>> Martin if the developers guide says 1.1.3 (and we send out an email)
>> you can make that assumption...
>>
>> I tried updating the developers guide in Monday's
Yeh sounds good.
1.4 seems stable and ready so I say we make the official release friday.
Brent Owens
(The Open Planning Project)
Andrea Aime wrote:
> Adrian Custer ha scritto:
>> Hey all,
>>
>> It's come to my attention that some people do not know. We will try to
>> release 2.3.0 on Friday. I
Jody Garnett wrote:
> Justin Deoliveira wrote:
>> Jody Garnett wrote:
>>> The GeoAPI interface should already have a method that accepts Name
>>> class (ie namespace plus localpart). You can choose to store both in our
>>> implementation and do as you see fit.
>>>
>> I don't think so. PropertyName
Jody Garnett wrote:
>Martin if the developers guide says 1.1.3 (and we send out an email) you
>can make that assumption...
>
>I tried updating the developers guide in Monday's meeting - can you
>review the page and send out
>an email if you are happy?
>
>
Ah, so someone using 1.1.3 has managed
GeoTools Factory lookup for OSGi Envorinment
Key: GEOT-1048
URL: http://jira.codehaus.org/browse/GEOT-1048
Project: GeoTools
Issue Type: Task
Reporter: Jody Garnett
Priorit
Review Catalog implementation
-
Key: GEOT-1047
URL: http://jira.codehaus.org/browse/GEOT-1047
Project: GeoTools
Issue Type: Task
Affects Versions: 2.4
Reporter: Jody Garnett
Assigned To: J
Adrian Custer ha scritto:
> Hey all,
>
> It's come to my attention that some people do not know. We will try to
> release 2.3.0 on Friday. If you have changes that need to happen, please
> get them in now!
I guess 2.2.2 will be released on Monday instead. Brent, what do you
think? 2.2.2 during t
Hey all,
It's come to my attention that some people do not know. We will try to
release 2.3.0 on Friday. If you have changes that need to happen, please
get them in now!
carry on,
adrian
-
Take Surveys. Earn Cash. Influence
On Wed, 2006-11-29 at 15:08 -0500, Saul Farber wrote:
> I've got two in there.
>
> One is this:
> http://jira.codehaus.org/browse/GEOT-803
>
> This is resolved and fixed on 2.3.x. I think it's just open because it
> was unclear whether it made it to 2.3.x, when geoserver was still in 2.1.x.
co
Martin if the developers guide says 1.1.3 (and we send out an email) you
can make that assumption...
I tried updating the developers guide in Monday's meeting - can you
review the page and send out
an email if you are happy?
Cheers,
Jody
> An annoying JAI 1.1.2 bug is fixed in 1.1.3 release:
>
The handle attribute allows a client application to assign a
client-generated request identifier to a WFS request. The handle is
included to
facilitate error reporting. A WFS may report the handle in an
exception report to identify the offending request or action. If the
handle is not pre
So we have shown that I am not in the know here :-P
Why don't we ask Jesse can we ask for help (he does rendering and he has
a checkout of both branches).
Jody
> Jody,
>
> this is why I wanted someone in the know to look at things. The class
> you are talking about is totally different from the cl
Andrea Aime wrote:
Fair enough Andrea; but this is the third implementation (GeoTools
has throw out two already) - the only way I am going to get this
documented to your satisfaction is to set uDig and GeoServer up to
actually use it - and this is what is happening.
>>> Nope.
Justin Deoliveira wrote:
> Jody Garnett wrote:
>> The GeoAPI interface should already have a method that accepts Name
>> class (ie namespace plus localpart). You can choose to store both in our
>> implementation and do as you see fit.
>>
> I don't think so. PropertyName is just an xpath expression
Just a quick check on this (closed) issue. I'm not sure that I
understand how this got resolved. As best I can tell, the fix is in the
new typing system in trunk (2.4.x), but there was no specific fix for 2.3.x.
Since this affects 2.3.0, and I think it's a pretty significant bug
(certainly bi
An annoying JAI 1.1.2 bug is fixed in 1.1.3 release:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4906854
If we can assume that everybody upgrated to JAI 1.1.3
(https://jai.dev.java.net/binary-builds.html), it would allow us to remove a
very ugly hack in Resample2D, which is used for rast
Andrea Aime wrote:
Jody Garnett ha scritto:
Andrea Aime wrote:
becomes non 0 when it is replaced (so revision==0 always represents
the "live" data). Having two columns is not bad, does having both
help you ask for data in a specific range? Or could we get by with
just a single column.
I'm
I've got two in there.
One is this:
http://jira.codehaus.org/browse/GEOT-803
This is resolved and fixed on 2.3.x. I think it's just open because it
was unclear whether it made it to 2.3.x, when geoserver was still in 2.1.x.
The other is this:
http://jira.codehaus.org/browse/GEOT-1025
Should
Jody Garnett ha scritto:
> Andrea Aime wrote:
>>> Fair enough Andrea; but this is the third implementation (GeoTools
>>> has throw out two already) - the only way I am going to get this
>>> documented to your satisfaction is to set uDig and GeoServer up to
>>> actually use it - and this is what
Jody,
this is why I wanted someone in the know to look at things. The class
you are talking about is totally different from the class I was looking
at. Run
java -jar gt2-demo-intro...
and push the buttons--you'll see the spew. However if you change the
line, not in the class you mention, but in
Jody Garnett wrote:
> The GeoAPI interface should already have a method that accepts Name
> class (ie namespace plus localpart). You can choose to store both in our
> implementation and do as you see fit.
>
I don't think so. PropertyName is just an xpath expression, which may
have multiple namesa
Andrea - of course your apology is accepted. Indeed I had not take
offense :-)
I would rather have more peer review in blunt terms then anybody
worrying about being perfectly polite.
Jody
> Andrea Aime ha scritto:
>
>> Chris, need help here... what do you think?
>>
>> Message from the gt2/geo
Andrea Aime ha scritto:
> Chris, need help here... what do you think?
>
> Message from the gt2/geoserver mailing list...
> I have the impression Jody not only wants to provide feedback,
> but also wants to leave his on mark on the thing :-p
> Or maybe it's just me being too defensive...
Crap... t
The GeoAPI interface should already have a method that accepts Name
class (ie namespace plus localpart). You can choose to store both in our
implementation and do as you see fit.
If your GMLDataStore knows about such things as namespace you can make a
special PropertyAccessor just for it that ta
Aside: Andrea I am done w/ feedback ... I feel what you are doing is
important so I gave you one round of feedback, and then tried to answer
any questions you had about my comments.
You can carefully ignore me (I won't even mind); part of it being a
review by your peers is knowing when to ignor
Andrea Aime wrote:
>> Fair enough Andrea; but this is the third implementation (GeoTools
>> has throw out two already) - the only way I am going to get this
>> documented to your satisfaction is to set uDig and GeoServer up to
>> actually use it - and this is what is happening.
> Nope... this is
Hi all,
I am working on getting actual xpath expressions to evaluate correctly
against our feature model. For instances "//gml:description" evaluates
to a "description" on a feature.
My problem is that the PropertyName implementation (AttributeExpressionI
mpl) knows nothing about namespaces. W
Andrea Aime wrote:
>> Version was part of the GeoTools 2.0 feature model (and was removed
>> as it was unused), and it is part of the general OGC feature model.
>> So add it back in now that you have a use for it.
> Jody, if I start to implement the thing this week, it'll be against gt2
> 2.3 or
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> Sorry for the cold shower Jody, but GeoResource and the like are stuff
>> for the "catalog" module which has basically received no discussion
>> and it's not documented.
> Fair enough Andrea; but this is the third implementation (GeoTools has
> thr
Just looked on trunk and it says (so somebody did this already?)
> // if everything else fails fall back on a default font
> distributed
> // along with the jdk
> return new java.awt.Font("Serif",java.awt.Font.PLAIN,12);
Now if we can ask somebody with a 2.3 checkout to con
Chris, need help here... what do you think?
Message from the gt2/geoserver mailing list...
I have the impression Jody not only wants to provide feedback,
but also wants to leave his on mark on the thing :-p
Or maybe it's just me being too defensive...
+1.
If you make the changes I will review. Then we hunt down where any
setters on the interfaces are being used and replace them with factory
methods. Should be pretty painless.
-Justin
Jody Garnett wrote:
> Guys I *really* want to make filter and expression immutable - but I
> need your help
Jody Garnett ha scritto:
> Andrea Aime wrote:
>>> GetLog
>>> - making it available as a normal feature is fine, collections
>>> support can be done if you need it.
>> Indeed, it's true... I just don't have any idea of how complex that
>> would be and which GML producer we would need to use...
> S
Guys I *really* want to make filter and expression immutable - but I
need your help (ie vast agreement and a "mandate" to go fix the GeoAPI
interfaces before we start using them in anger).
Any suggestions on how to proceed without annoying others would be
great; the coding thing is easy on this
Andrea Aime wrote:
> Sorry for the cold shower Jody, but GeoResource and the like are stuff
> for the "catalog" module which has basically received no discussion
> and it's not documented.
Fair enough Andrea; but this is the third implementation (GeoTools has
throw out two already) - the only way
Jody Garnett ha scritto:
> Andrea Aime wrote:
>>> becomes non 0 when it is replaced (so revision==0 always represents
>>> the "live" data). Having two columns is not bad, does having both
>>> help you ask for data in a specific range? Or could we get by with
>>> just a single column.
>> I'm doin
Jody Garnett ha scritto:
> Andrea wrote:
>>> GetFeature
>> Hmm... I hear ya, yet there are downsides:
>> * I would no more be able to query the feature type for a specific
>> revision using a plain GetFeature. This could be done in a
>> GetFeatureVersioning extra method instead (something we are
>> Transation:
>> - throwing errors out of Transaction is cool; consider any conflict
>> to be the same as a locking conflict (ie the modification has been
>> made by another so that feature is "locked")
>> - leave revision columns out of the describe feature type so that you
>> do not have to
Jody Garnett ha scritto:
> Andrea Aime wrote:
> Don't follow you about generating code? The Transaction format is quite
> clear though - broken down into delete, update, add ... think this one
> is perfect. If you want to talk further I suggest we make a real example
> and work through both app
Andrea Aime wrote:
>> GetLog
>> - making it available as a normal feature is fine, collections
>> support can be done if you need it.
> Indeed, it's true... I just don't have any idea of how complex that
> would be and which GML producer we would need to use...
Same one as for GetFeatures
Andrea Aime wrote:
>> becomes non 0 when it is replaced (so revision==0 always represents
>> the "live" data). Having two columns is not bad, does having both
>> help you ask for data in a specific range? Or could we get by with
>> just a single column.
> I'm doing performance tests now, to see
Andrea wrote:
>> GetFeature
>> - so out of the box it returns the latest
>>
>> I am a bit concerned that making the revision columns available
>> messes up the origional schema (this simply will not work in the case
>> where the schema is provided by a third party authority for example).
>> Alth
Andrea Aime wrote:
> Forgot this one... man, your feedback was quite big :-p
Heh - and this was the only idea I thought was actually good.
>> GetDiff - GetTransaction Request option
>> It would be *nice* if the result was *not* a GetFeatures extensions
>> but instead the exact Transaction request
Andrea Aime wrote:
>> - part of the feature identifier
>> ..> fid="people.wilma.432455">...
> The result of which is a GML document where the revision is either:
> Oh, it occurred to me that having a changing fid for features
> simply breaks the notion of an identifier and makes it hard
> for clien
Thanks!
I knew there was an earlier bug, since I didn't come up with your
solution on my own, but couldn't find it. Linked the latter bug and
closed it.
--adrian
On Wed, 2006-11-29 at 16:25 +, Combe, Colin wrote:
> Also, http://jira.codehaus.org/browse/GEOT-1046 is a duplicate of
> http://j
Also, http://jira.codehaus.org/browse/GEOT-1046 is a duplicate of
http://jira.codehaus.org/browse/GEOT-981
colin
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Adrian Custer
> Sent: 29 November 2006 14:08
> To: Geotools-Devel list
> Subject: [G
Hi all,
I've tried to validate the performance of the versioning
dastastore design with a benchmark with some real size
data, and posted the results here:
http://docs.codehaus.org/display/GEOS/Datastore+design
Well... I have to say I'm more than pleased with the results,
especially with the scalab
Adrian Custer a écrit :
> We currently have 46 bugs outstanding on 2.3.x. Since we are going to
> release 2.3.0 on friday, could you all work through the list and triage
> the bugs, bumping what needs to be bumped to 2.4? We originally thought
> that 2.3.x was going to be more significant than what
Forgot this one... man, your feedback was quite big :-p
Jody Garnett ha scritto:
> Hi Andrea,
> GetDiff - GetTransaction Request option
> It would be *nice* if the result was *not* a GetFeatures extensions but
> instead the exact Transaction request documented required to make the
> change; no
Hey all,
We currently have 46 bugs outstanding on 2.3.x. Since we are going to
release 2.3.0 on friday, could you all work through the list and triage
the bugs, bumping what needs to be bumped to 2.4? We originally thought
that 2.3.x was going to be more significant than what it has now turned
out
hey all,
http://jira.codehaus.org/browse/GEOT-1046 reports a trivial styling bug
and fix. Could someone who knows the module please take a look and apply
it to both 2.3.x and trunk? Thanks, adrian
-
Take Surveys. Earn Cash.
StyleFactoryImpl looking for lower case 'serif' as default font
---
Key: GEOT-1046
URL: http://jira.codehaus.org/browse/GEOT-1046
Project: GeoTools
Issue Type: Bug
Affects Versi
Vitali Diatchkov ha scritto:
>
> Hello!
>
> I have faced with a problem of concurrent modification of Filter that leads
> to exception throwing:
...
> This use case is coming from UDIG.
>
> Shouldn't all the Filter objects be immutable? (Just a quick mind). Or what
> does the Filter design sa
Hello!
I have faced with a problem of concurrent modification of Filter that leads
to exception throwing:
java.util.ConcurrentModificationException
at
java.util.AbstractList$Itr.checkForComodification(AbstractList.java:449)
at java.util.AbstractList$Itr.next(AbstractList.java:42
OK, :)
We will do it
regards
On Tuesday 28 November 2006 19:50, Jody Garnett wrote:
> Sure - point of reference Victor - geotools is a projection of module
> maintainers (so what you like happens!)
>
> Jody
>
> > Hi Jody, I agree with "org.geotools.text.filter", I see it is nice to
> > maintain
Jody Garnett ha scritto:
> Hi Andrea,
> The result of which is a GML document where the revision is either:
> - part of the feature identifier
> .. fid="people.wilma.432455">...
Oh, it occurred to me that having a changing fid for features
simply breaks the notion of an identifier and makes it ha
Jody Garnett ha scritto:
> Hi Andrea,
...
> You are clear on your scope (and yes everyone's hopes ask for more, but
> I respect your decision to start small).
>
> Datastore Desgin:
>
> Data table:
> - I was not going to assume the revisionCreated - revisionExpired
> columns; instead used to a s
TemporalAttributeType does not allow for different date parsing
---
Key: GEOT-1045
URL: http://jira.codehaus.org/browse/GEOT-1045
Project: GeoTools
Issue Type: Improvement
Jody Garnett ha scritto:
> We also dropped some proposed GridCoverage DataAccess interfaces into
> your module (so our friend simboss can
> provide feedback). So if you wonder what these things are - please don't
> delete them :-) The other interesting proposal
> in there is how to provide "conne
63 matches
Mail list logo
