Jody Garnett ha scritto:
...
> I do like the idea of *time* as a measure of how hard the the code is
> to get right; how about 1 week Andrea?
I believe the thing should be considered from a different angle. When
do we say a solid "no" to a contribution that's adding a new dependency?
If we face a
Hello Martin,
>
>Hello Jan
>
>Jan Jezek a écrit :
>> sorry for bothering you but can I kindly ask you once again on the
>access to commit AdvancedAffineBuilder as described in e-mails few weeks
>ago? I've got a costumer for that and it is easier to point him to
>Geotools version than to GeoTools+
Martin uDig is still using it; the method that fetchs all the codes does
not work for me when I switch to epsg-hsql. The emails on this topic are
very old; but it amounted to a bunch of factory spi problems.
So no I am afraid we are stuck with epsg-wkt for now. And why was it
deprecated it is t
Vincent Heurteaux wrote:
> Hello Jody,
>> Vincent - is there any way you can organize things on your end so
>> Martin has more time to meet these responsibilities? If this is not
>> possible we should look at getting a co-module maintainer in here.
> Martin is involved on it now, I'm sure he will
A couple of things:
- there is a new Jira category for "license" - we will use this to flag
any issues that turned up in the review process
Yes that was only one thing; here is some more from our
http://docs.codehaus.org/display/GEOTOOLS/GeoTools+Provenance+Review page.
>
> Some code has been d
Go for it martin; I also consider the doc folder but by maven manners
are a bit rusty. The APT format is pretty cool.
Jody
> At last IRC meeting, it has been proposed to include the review document into
> the page generated by "mvn site:site". For this purpose, I would like to move
> every revi
Hi Andrea; just to let you know there have been some request on the user
list about making the method names consistent. If you can consider the
following requests I would like your feedback.
- FeatureType.getAttribute(): AttributeDescriptor
- Feature.getAttribute(): Attribute
The duplication of
Thanks everyone that was a great bit of discussion. What started this
thread was an guideline to use when trying to decide if we needed to
roll our own on any given Sunday. Andrea's numbers ring true to me; two
weeks are probably too much.
The other thing that rings true to me is that some code
Martin Desruisseaux wrote:
> Yes, rewriting GeoTools from scratch would be a mistake. What I'm
> suggesting is more a cleaning. The metadata and referencing modules
> would be close to identical, except for:
>
> * More uniform naming policy (the metadata renaming proposal would be
> applied only
Hi Vincent ... comments in line.
> Hello,
>
> The example given by Joel is not really relevant to the proposal. Here
> Martin is really suggesting some spring cleaning rather than any
> rewrite from scratch.
>
Understood. I think you may be surprised at the level of spring cleaning
I propos
Andrea Aime wrote:
> Am I seeing dark clouds at the horizon that are not really there?
> Jody, what is your point of view given the planned future of uDig?
I tried to be clear with my link to the Joel article on the peril of
putting a live codebase on hold while you do something pretty. Mozilla
Hello Jan
Jan Jezek a écrit :
> sorry for bothering you but can I kindly ask you once again on the access to
> commit AdvancedAffineBuilder as described in e-mails few weeks ago? I've got
> a costumer for that and it is easier to point him to Geotools version than to
> GeoTools+patch including
See http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/768/changes
Changes:
[jezekjan] Bug under spike/Jan/ - AdvancedAffineBuilder - calculation fixed.
--
[...truncated 5351 lines...]
Running org.geotools.sld.bindings.SLDDisplacementBindingTest
At last IRC meeting, it has been proposed to include the review document into
the page generated by "mvn site:site". For this purpose, I would like to move
every review.txt file (currently at the root of each module) to the following
location:
/src/site/apt/review.apt
"apt" stands for "Alm
I'm trying to complete the tasks I need for my "unsupported" GeoTools
module. One of these steps was completing the paper work necessary to
transfer my copyright for GeoTools code to the OSGeo. However, the
GeoTools developer guide does not contain a link to the appropriate
form:
http://docs.codeh
I agree with Martin here, we need to decide on per-case basis.
I usually try to reuse whatever is around, unless I found problems in
it or it is to big to carry it along, nut sometimes rewritingis the
best option.
I can provide another example which was interesting for me. In the
metadata module th
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
> thin
"Writting our own code" versus "introducing an other dependency" is probably a
case-by-case basis. In the particular case of Joda library, we have a standard
Java class (GregorianCalandar) with lot of defaults, but doing enough work for
allowing us to wait for the inclusion of a Joda-like librar
Hello,
The example given by Joel is not really relevant to the proposal. Here
Martin is really suggesting some spring cleaning rather than any
rewrite from scratch.
In our case, one of the major benefits of open source is to create a
project without business constraints ( "It will be releas
Hello Daniele and all
There is my comments about the latest Geographic metadata document from
Geosolution (http://www.geo-solutions.it/doc/nd-metadata-doc.odt):
Figure 5
This figure splits the CRS into 3 compenents: SpatialCRS, VerticalCRS and
TemporalCRS. I suggest to remove all of th
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
I have to register with Andrea under the dissenting opinion here. The
"invent here" policy does not sound like a good idea to me. In fact,
it seems to eliminate one of the great benefits of the Java language,
widespread use of popular and task-specific programming languages. If
you want to use a "e
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 s
Hi,
I'm trying to continue Justin's work on simple features backed
by arrays of Objects and I'm having issues with validation,
it seems to me I've found a design flaw with restrictions.
Restrictions in the new feature model are created by
using Filter objects attached to the attribute type definit
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
> sta
Jody Garnett ha scritto:
> I was looking at the "how to import a shapefile" page on the wiki - and
> it mentions the "do not invent here" policy and how that has lead to our
> massive amount of dependencies. Here are some ideas on how to set up a
> "positive" invent-here policy.
>
> How about t
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 -
Martin Desruisseaux ha scritto:
> Jody has posted rencently a number of wish for GeoTools 3. Do we have
> any idea when such project could be started? More specifically, is
> the following doable?
>
> * Start with a totally empty repository. Mercurial proposed because
> it is bundled with NetBeans
Jan Jezek a écrit :
> sorry for bothering you but can I kindly ask you once again on the access to
> commit AdvancedAffineBuilder as described in e-mails few weeks ago? I've got
> a costumer for that and it is easier to point him to Geotools version than to
> GeoTools+patch including new work.
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
Martin Desruisseaux ha scritto:
> A number of issues reported recently was related to gt-epsg-wkt and
> gt-epsg-hsql
> be both in the classpath. Do GeoServer or uDig still using epsg-wkt on
> GeoTools
> trunk? If no, can we delete epsg-wkt from trunk? It was already deprecated in
> the 2.4 rel
Hi list especially Martin,
sorry for bothering you but can I kindly ask you once again on the access to
commit AdvancedAffineBuilder as described in e-mails few weeks ago? I've got a
costumer for that and it is easier to point him to Geotools version than to
GeoTools+patch including new work.
Hello Jody,
> Vincent - is there any way you can organize things on your end so
> Martin has more time to meet these responsibilities? If this is not
> possible we should look at getting a co-module maintainer in here.
Martin is involved on it now, I'm sure he will get back to you soon.
Chee
Rob Atkinson a écrit :
> Our main goal in the meantime would be to see the Geotools 2.5+
> consolidated, and accesible from Geoserver using meaninfgul data schemas
> to give us a deployable tool. Until we get a chance to play with this,
> we probably wont have too much useful insight into GeoToo
A number of issues reported recently was related to gt-epsg-wkt and
gt-epsg-hsql
be both in the classpath. Do GeoServer or uDig still using epsg-wkt on GeoTools
trunk? If no, can we delete epsg-wkt from trunk? It was already deprecated in
the 2.4 release.
Martin
--
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
li
Jody Garnett a écrit :
> GeoTools 3 should adopt an "Invent here" policy:
> 1) unless a dependency offers significant benefit we should roll our own
> - A dependency that brings in additional dependencies is a bad thing
> - A dependency that is used by several modules is a good thing
I would entho
Jody Garnett a écrit :
> HOW ABOUT NOW?
> How about this for some short term plan:
> - Cut over to my to the worker pool classes *now* (we put it off for
> 2.4.x remember) and we can sort out the bugs before the 15th?
I started the review last week. I already a bit of metadata (org.geotools.util
Jody Garnett a écrit :
> Martin Desruisseaux wrote:
>> What peoples think?
> http://www.joelonsoftware.com/articles/fog69.html
Yes, rewriting GeoTools from scratch would be a mistake. What I'm suggesting is
more a cleaning. The metadata and referencing modules would be close to
identical
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 quic
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 overhe
Dear all,
I'm a peripheral player, but I'd like to register an enthusiastic vote
in favour of Jody's 'invent here' (sometimes) policy if it can help
cull the dependencies and consolidate the code a bit.
Michael
2008/6/28 Jody Garnett <[EMAIL PROTECTED]>:
> I was looking at the "how to import a s
42 matches
Mail list logo
