OK, I think I have a formal +1 from Jody, support from Andrea (I have
taken this as +1, it that OK?), and a week has elapsed. Is the proposal
approved? Would you like me to commit the changes and update the
developer docs?
Kind regards,
Ben.
Jody Garnett wrote:
Got it. Checking that the
Ben Caradoc-Davies ha scritto:
I propose that an optional key be added to OnlineTestCase to cause test
failure on failed connection:
http://docs.codehaus.org/display/GEOTOOLS/OnlineTestCase+support+for+failure+on+failed+connection
Works for me. Just a minor note, there is one other case in
Andrea Aime wrote:
Ben Caradoc-Davies ha scritto:
I propose that an optional key be added to OnlineTestCase to cause test
failure on failed connection:
http://docs.codehaus.org/display/GEOTOOLS/OnlineTestCase+support+for+failure+on+failed+connection
Works for me. Just a minor note, there
Read over the proposal; I think this is a case were we can come to a
decision without a formal proposal since this just effects us the devel
community and the change is not visible to user code. But that is my take on
it - we are still sorting out when a proposal is useful and when it is a
waste
Jody Garnett wrote:
I think this is a case were we can come to a decision without a formal
proposal since this just effects us the devel community and the change is not
visible to user code. But that is my take on it - we are still sorting out
when a proposal is useful and when it is a
Ben Caradoc-Davies wrote:
Jody Garnett wrote:
I think this is a case were we can come to a decision without a
formal proposal since this just effects us the devel community and
the change is not visible to user code. But that is my take on it -
we are still sorting out when a proposal is
Got it. Checking that the proposal says what you mean... you even found the
developers guide page that needs to change :-D+1
Jody
On Wed, Feb 4, 2009 at 3:04 PM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au wrote:
Jody Garnett wrote:
Hrm you are right; Justin wanted proposals for things
I propose that an optional key be added to OnlineTestCase to cause test
failure on failed connection:
http://docs.codehaus.org/display/GEOTOOLS/OnlineTestCase+support+for+failure+on+failed+connection
--
Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
Software Engineer, CSIRO Exploration and
How would that be helpful? I could see throwing a java property to ask
the online tests to fail
Personally I log the first failed connection message.
Ben Caradoc-Davies wrote:
I propose that an optional key be added to OnlineTestCase to cause test
failure on failed connection:
I propose that the patch attached to GEOT-1951 be adopted on 2.4.x and
trunk:
http://jira.codehaus.org/browse/GEOT-1951
The patch (for 2.4.x) refactors OnlineTestCase into OnlineTestCase
(provides connection failure tolerance) and its superclass
FixtureTestCase (provides fixture handling).
Hi all,
A few days ago I asked about how to implement a coverage defined on a
mathematical function on the users' list. Simone and Martin replied
with info about using JAI's ImageFunction directly or indirectly -
this was a big help.
Sometime soon I'll have a need for a leaner (in terms of
Hey,
You are starting to talk about real 'coverages' rather than 'grid
coverages'. There is a spec to help you implement such a thing, ISO
19123, probably with antecedents in the OGC world. You are discussing an
'analytic coverage' or more specifically a time-dependent analytic
coverage.
The
Thanks Adrian - I just grabbed a copy of Bryce's document which I was
completely ignorant of.
It will probably turn out that my thoughts / needs will equate to a
cheap hack relative to the systematic framework set out in the
standard :) But in the event that I what I write for my own use looks
Michael Bedward a écrit :
One approach to this would be a type of coverage based on a
mathematical function (passed to its constructor perhaps). It would
use lazy instantiation so that the function would only be parsed into
some efficiently runnable form (an AST perhaps) when the coverage is
On Mon, Jun 30, 2008 at 1:36 PM, Michael Bedward
[EMAIL PROTECTED] wrote:
Hi all,
A few days ago I asked about how to implement a coverage defined on a
mathematical function on the users' list. Simone and Martin replied
with info about using JAI's ImageFunction directly or indirectly -
this
On Mon, 2008-06-30 at 23:09 +1000, Michael Bedward wrote:
Thanks Adrian - I just grabbed a copy of Bryce's document which I was
completely ignorant of.
It will probably turn out that my thoughts / needs will equate to a
cheap hack relative to the systematic framework set out in the
standard
Many thanks Martin, Simone and Adrian for those further comments -
they are very helpful for my thinking and much appreciated.
ciao
Michael
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell
I'm jumping into the middle of this conversation, but I wanted to
clarify something. I don't know if it will add to the discussion, but
I hope it will.
The Geoid is not a mathematical figure like an ellipsoid, so I don't
think you can really refer to conversion equations. A geoid is more
like a
On Mon, 2008-06-30 at 08:37 -0700, Sunburned Surveyor wrote:
I'm jumping into the middle of this conversation, but I wanted to
clarify something. I don't know if it will add to the discussion, but
I hope it will.
The Geoid is not a mathematical figure like an ellipsoid, so I don't
think you
Jody Garnett a écrit :
Andrea Aime wrote:
Again, I don't know how many people will be affected
by changes in the changes of the metadata module, so I may be
overestimating the issue.
People do use the metadata classes directly; and have to make use of
constructors to do it - so this
Martin Desruisseaux ha scritto:
Jody Garnett a écrit :
Andrea Aime wrote:
Again, I don't know how many people will be affected
by changes in the changes of the metadata module, so I may be
overestimating the issue.
People do use the metadata classes directly; and have to make use of
Jody Garnett ha scritto:
Andrea Aime wrote:
The first one is the size of the change. I would like to avoid seeing
massive change of code in the
gt2 codebase so close to GeoServer 1.7.x freeze. Can you svn diff you
changes and post them somewhere?
If they are really really big I'd prefer to
Many questions ...
Andrea Aime a écrit :
Hi,
here are a couple of bits about the upgrading styles proposal.
Generally speaking, the proposal sounds nice, and it's going
to introduce some very interesting new functionality, so
I'm favourable, but there are a couple of issues preventing
me
johann sorel ha scritto:
...
I guess I could do the work and come back with an svn diff in one week,
but if the
answer is no, I'll have lost my time for nothing.
Ok, no problem with that, I thought you were already working on it,
that's why I asked.
...
We are using a JaxB solution.
Will
Andrea Aime wrote:
I understand this perfectly, that's why I'm open to other solutions,
such as branching out 2.5.x even before an RC is out to accomodate
for this particular situation.
Agreed; so when we learn more from both groups we can make some
decisions here. Thanks for getting the
Jody Garnett a écrit :
I see the following:
- ColorMap in coverage; marked as since 2.4 - Martin what is your
integration plan if anything?
This ColorMap handle implementation details for the need of coverage module.
Should probably be hidden. Is not right now because not yet connected to an
Hi,
I've read the proposal, I have two concerns.
The first one has already been voiced by Jody, whenever the Metadata
classes are used, they should be used as interfaces and be created
with a factory, otherwise we'd tangle up GeoTools code and make it
difficult for future evolution. See what
Hi,
here are a couple of bits about the upgrading styles proposal.
Generally speaking, the proposal sounds nice, and it's going
to introduce some very interesting new functionality, so
I'm favourable, but there are a couple of issues preventing
me from voting +1 on it.
The first one is the size
Andrea Aime wrote:
The first one is the size of the change. I would like to avoid seeing massive
change of code in the
gt2 codebase so close to GeoServer 1.7.x freeze. Can you svn diff you changes
and post them somewhere?
If they are really really big I'd prefer to have GeoTools 2.5.x cut
Andrea Aime wrote:
Again, I don't know how many people will be affected
by changes in the changes of the metadata module, so I may be
overestimating the issue.
People do use the metadata classes directly; and have to make use of
constructors to do it - so this change *will* break some
Hi,
I've prepared this proposal so that GeoTools can support extensible
symbol sets (for Mark and ExternalGraphic) and dinamically generated
symbols, eventually dependent on feature attributes:
http://docs.codehaus.org/display/GEOTOOLS/Dynamic+SLD+Graphic+objects
Please discuss the proposal on
Looks good Andrea. A couple of very minor things:
* is there a reason for using String for url's in MarkFactory and and
java.net.URL. in ExternalGraphicFactory? I guess perhaps because the
ExternalGraphic is indeed *external* and you one needs to grab a
connection from it?
* I think the
Justin Deoliveira ha scritto:
Looks good Andrea. A couple of very minor things:
* is there a reason for using String for url's in MarkFactory and and
java.net.URL. in ExternalGraphicFactory? I guess perhaps because the
ExternalGraphic is indeed *external* and you one needs to grab a
Ha ha, touché... it's my laziness. Is square a valid URL?
I did not check, that's why I kept it a string. If not URL, would it
make sense to use URI?
Yeah... or perhaps just leave them both Strings? Leave it up to the
factory implementation to convert to whichever one they need.
* I think
Hello,
Sorry to stop this proposal but I'm actualy working on
multiple portrayal specification i'm willing to add in GeoAPI/GeoTools
Actually GeoTools is based on SLD style system v:1.0.0 , before making a
proposal to move
away from the OGC SLD specification I suggest we implement SLD v:1.1.0
johann sorel ha scritto:
Hello,
Sorry to stop this proposal but I'm actualy working on
multiple portrayal specification i'm willing to add in GeoAPI/GeoTools
Actually GeoTools is based on SLD style system v:1.0.0 , before making a
proposal to move
away from the OGC SLD specification I
Ok I see,
I misunderstood your proposal.
I thinked your were adding new functions (with the protocol thing) and
by doing so, no fallowing the SE.
sorry.
The font support for symbol is a good thing.
so +1 for your proposal.
Andrea Aime a écrit :
johann sorel ha scritto:
Hello,
Sorry to
johann sorel wrote:
Hello,
Sorry to stop this proposal but I'm actualy working onmultiple portrayal
specification i'm willing to add in GeoAPI/GeoTools
Actually GeoTools is based on SLD style system v:1.0.0 , before making a
proposal to move away from the OGC SLD specification I suggest
Thanks for updating the page with sld examples; it helped me :-) Even if
it made you late for dinner ...
You already know my feedback .. ie if I was the OGC fixing this problem
I would go with:
OnlineResource
http://www.iconrepo.com/PropertyNamefilenameAttribute/PropertyName.png
/OnlineResource
Justin Deoliveira ha scritto:
Ha ha, touché... it's my laziness. Is square a valid URL?
I did not check, that's why I kept it a string. If not URL, would it
make sense to use URI?
Yeah... or perhaps just leave them both Strings? Leave it up to the
factory implementation to convert to
Hey all,
During monday's IRC I will table the proposal listed here:
http://docs.codehaus.org/display/GEOTOOLS/
Proposal+to+assign+our+copyright+to+OSGeo
(you'll have to play with the link since email will butcher it).
The goal is to reach consensus of all the contributors who are
Ok, I will do it. I found a good documentation in Development Guide (good
work).
cheers
On Wednesday 11 April 2007 18:18, Jody Garnett wrote:
Yes - very cool.
I will move the proposal to accepted. (I added a Geometry WKT parser to
main using the package naming convention already).
How is
Hi Jody, I come back. I am checking the Common Parsers status in
http://docs.codehaus.org/display/GEOTOOLS/Provide+common+parsers+in+a+consistent+fashion
In trunk
- CQL was moved to library/cql
- new package name: org.geotools.filter.text.cql2 (it is not done)
if the debate about package name
Yes - very cool.
I will move the proposal to accepted. (I added a Geometry WKT parser to
main using the package naming convention already).
How is it going? Are you finding everything you need as a module maintainer?
Cheers,
Jody
Hi Jody, I come back. I am checking the Common Parsers status
Jody Garnett a écrit :
Andrea Aime wrote:
Can we try another path? The issue with having many jars is that
without maven it's hard to deal with them... unless we provide
users with a list of dependencies:
Just a reminder: The Geotools JAR created by Maven contains a Class-Path
entry
in
Well, cql is defined in OGC Cataloge Service Specification v1.1.1 and v
2.0.0 (OGC 02-087r3 y OGC 04-021r3)
There are a mandatory query language what can be extended (optional
languages).
In version 1.1.1 (OGC 02-087r3) present three types of query language:
- A common, mandatory query
Thanks for all the background - I will see if I can cut and paste it to
the wiki. Agreed - until someone needs to extend it
we need not worry about the dialects thing - unless that person is
called Andrea and the extension is to support
FIDs :-)
Jody
Well, cql is defined in OGC Cataloge
Jody Garnett ha scritto:
Justin Deoliveira wrote:
up to 1 MB. Merging them into main concerns me quite a bit.
Agreeed; it would be merged into xml (possible with child modules
if I understand Justin), main is big enough already (are you going to
write up a proposal for changing what code
Jody Garnett ha scritto:
I am going to start on the work now but will not commit until votes are
in. If you really want something changed let me know early :-)
-
http://docs.codehaus.org/display/GEOTOOLS/Provide+common+parsers+in+a+consistent+fashion
+1 on the package names
Related to the
Well I am new in this business, and I have not a serious knowledge of general
picture, but the first option inside Justin's comment looks right for me.
org.geotools.xml.filter.v1_0
org.geotools.xml.filter.v1_1
org.geotools.xml.gml.v2
org.geotools.xml.gml.v3
Maybe we need to add version for
Thanks Mauricio :-)
Indeed this proposal is my attempt to get your code and Justin's code
code into a similar package structure.
Based on Justin's feedback we ended up with the following guideline:
Of the format org.geotools.SUBJECT.PARSER.SPECIFICATION:
* SUBJECT - is the *output* being
Andrea Aime wrote:
Jody Garnett ha scritto:
Justin Deoliveira wrote:
up to 1 MB. Merging them into main concerns me quite a bit.
Agreeed; it would be merged into xml (possible with child modules
if I understand Justin), main is big enough already (are you going
to write up a proposal for
Andrea Aime wrote:
Jody Garnett ha scritto:
I am going to start on the work now but will not commit until votes
are in. If you really want something changed let me know early :-)
-
http://docs.codehaus.org/display/GEOTOOLS/Provide+common+parsers+in+a+consistent+fashion
+1 on the
Jody Garnett ha scritto:
Andrea Aime wrote:
I think we're down to the road of deep paths damnation, but lets
experience disprove me :-)
Andrea we are in close agreement; we both don't want to see a huge
dependency - and would like something more fine grained. I do not want
to see
many
Andrea Aime wrote:
xml compatibility pack 1:
- filter1_0, sld1_0, gml2
xml compatibility pack 2:
- filter1_1, sld1_1, gml3
Would you consider that kind of thing sane?
Apple and oranges? What xml parsers have to do with geometry
wkt parsers? Oh,you're missing sld too, we have two of them
Not sure i like the compatability pack idea Jody. I would rather keep
them separate and orgranize by specification, especially since a lot of
the implementations share code among versions. Not sure this will even work.
-Justin
Jody Garnett wrote:
Andrea Aime wrote:
xml compatibility pack 1:
Jody Garnett ha scritto:
Andrea Aime wrote:
xml compatibility pack 1:
- filter1_0, sld1_0, gml2
xml compatibility pack 2:
- filter1_1, sld1_1, gml3
Would you consider that kind of thing sane?
Apple and oranges? What xml parsers have to do with geometry
wkt parsers? Oh,you're missing sld
Andrea Aime wrote:
Can we try another path? The issue with having many jars is that
without maven it's hard to deal with them... unless we provide
users with a list of dependencies:
mvn project-info-reports:dependencies
Can we get that information punted out as part of our site? It would be
Hi Andrea - as always your feedback is fun (and blunt! Sorry that
should be honest :-D )
Jody Garnett ha scritto:
Hi Mauricio Justin,
Both of you have asked about moving stuff around in the last couple
of months, and I am finally writing up a proposal so we can do the
work. Right now
Justin Deoliveira wrote:
The new XML SLD, GML2, GML3 and filter parser are huge bad beasts,
their jars sum up to 700kb, whilst the current main module sums
up to 1 MB. Merging them into main concerns me quite a bit
Are we talking about rolling it into main? I am against this if this is
the
We are not; can you read and comment on the proposal please.
Sure, proposal updated with comments about packing naming structure with
regard to version numbers.
!DSPAM:4007,45fec2fb232381362196140!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
up to 1 MB. Merging them into main concerns me quite a bit.
Agreeed; it would be merged into xml (possible with child modules if I
understand Justin), main is big enough already (are you going to write
up a proposal for changing what code goes where? You started an email
discussion two
Thanks Justin; I do apologize if the focus of the proposal was not clear.
To be clear - I need to get a WKT parser in, and promised to find a home
for CQL as well. As long as it is being done I would like to match your
package naming conventions for your xml parsers.
So what is your package
Ha ha; my bad - you left a comment about xml package naming on the wiki
- for reference we tract the discussion on the JIRA item .. and always
update the page
to reflect our current thoughts. Yes that is insane; yes if you can
think of a better way we can do it.
Jody
Justin Deoliveira wrote:
So what is your package naming conventions?
Are you asking now? I dont really have one. the one in the proposal is
good, but does not take versions into account. The comment i made lists
two possibilities.
Cheers,
Jody
We are not; can you read and comment on the proposal please.
Justin Deoliveira wrote:
up to 1 MB. Merging them into main concerns me quite a bit.
Agreeed; it would be merged into xml (possible with child modules
if I understand Justin), main is big enough already (are you going to
write up a proposal for changing what code goes where? You started an
I kind ok liked both the same ... can you write one of them up on the
proposal page :-)
Oh here I will do it ... in general if you see a gap like this modify
the page and lets move on :-) If it is something worth discussion (like
this is, we can talk about it in email).
The v1_0 makes me sad -
Justin Deoliveira wrote:
up to 1 MB. Merging them into main concerns me quite a bit.
Agreeed; it would be merged into xml (possible with child modules
if I understand Justin), main is big enough already (are you going to
write up a proposal for changing what code goes where? You started an
I am going to start on the work now but will not commit until votes are
in. If you really want something changed let me know early :-)
-
http://docs.codehaus.org/display/GEOTOOLS/Provide+common+parsers+in+a+consistent+fashion
Thanks to everyone for feedback in todays meeting.
Cheers,
Jody
Jody Garnett ha scritto:
Hi Mauricio Justin,
Both of you have asked about moving stuff around in the last couple of
months, and I am finally writing up a proposal so we can do the work.
Right now you have different package naming conventions going on; the
proposal is about keeping it
Andrea Aime wrote:
Jody Garnett ha scritto:
Hi Mauricio Justin,
Both of you have asked about moving stuff around in the last couple of
months, and I am finally writing up a proposal so we can do the work.
Right now you have different package naming conventions going on; the
proposal is
Justin Deoliveira ha scritto:
There is no much diet around this neither, if you need to parse SLD,
according to dependencies, you need them all. Ah, and of course
you have to carry eclipse stuff in the bag too, that makes the
set of jars you need to actually use main quite big (in byte terms)
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Ouch! I did not check, but frankly did not image the dependency set
was so big.
Actually this figure can be somewhat revised. 3.2M is gt2-sample-data,
which is only a test dependency.
!DSPAM:4007,45fc32f8258334820651628!
--
Justin
Hi Mauricio Justin,
Both of you have asked about moving stuff around in the last couple of
months, and I am finally writing up a proposal so we can do the work.
Right now you have different package naming conventions going on; the
proposal is about keeping it consistent.
-
David Adler ha scritto:
I have a bunch of DB2 fixes on 2.2.x that need to go into 2.3. It
shouldn't be a problem except that mvn install fails on 2.3.x due to syntax
errors in the pom.xml files and I haven't pursued this for the past week.
I've built 2.3.0 a few time during the last
hey all,
I'd suggest doing a formal release of 2.3.0.
As I understand it Simone is using the branch. uDig will port to it.
That will flesh out bugs. Those bugs can be addressed in 2.3.x releases
just as well as they could prior to 2.3.0. Are there active bug fixes
happening on 2.3.x? Is there
Adrian Custer a écrit :
As I understand it Simone is using the branch. uDig will port to it.
That will flesh out bugs. Those bugs can be addressed in 2.3.x releases
just as well as they could prior to 2.3.0. Are there active bug fixes
happening on 2.3.x? Is there any reason to hold back on
On Mon, 2006-10-23 at 17:06 -0400, Martin Desruisseaux wrote:
So the question is: do we want to release Geotools anyway and tell the users
that the coverage part may be less frozen than some other Geotools parts?
If the alternative is for you to do a review, do you have any schedule
for such a
I have a bunch of DB2 fixes on 2.2.x that need to go into 2.3. It
shouldn't be a problem except that mvn install fails on 2.3.x due to syntax
errors in the pom.xml files and I haven't pursued this for the past week.
At 04:51 PM 10/23/2006, Adrian Custer wrote:
hey all,
I'd suggest doing a
Adrian Custer a écrit :
If the alternative is for you to do a review, do you have any schedule
for such a review?
Around one year ago... This is an other topic where I have been unable to meet
the deadline I told.
I hope to start looking at it next week.
Martin
Adrian Custer a écrit :
I propose creating a very simple skeleton for third party developers to
grab and expand into their applications. The skeleton would live in
demo/userApp.zip
which will be a zipped directory containing a simple maven project and
trivial running code (say a
Hi Adrian,
What you propose is exactly what I was doing for demo/example :-) So
lets combine forces. I too got a little stuck trying to untangle
normal what a normal maven project would look like, and was going to
confirm my understanding as Martin helps the rest of the geotools
codebase fall
I don't know if this applies exactly to what you were thinking Adrian,
but you might want to consider a maven archetype Archetypes are
indented to be used to provide a similar type of template app.
http://maven.apache.org/guides/mini/guide-creating-archetypes.html
-Justin
Jody Garnett wrote:
501 - 583 of 583 matches
Mail list logo
