So we have two "iso geometry" implementations on trunk/unsupported
unsupported/geometry - this is Sanjay's work :-D
unsupported/jts-wrapper - this is the jts wrapper from sys technology
(bryce?)
And then we have the following wiki pages:
- http://docs.codehaus.org/display/GEOTOOLS/Geometry
- htt
Stefan,
See my comments below.
You wrote: "aehm.. we (JUMP) currently has a DXF plugin by Michael Michaud?
Do you
now this?"
What about DWG?
Why do you chosen this format (It is rather usefull for CAD Geometries
than for GIS )"
I know about the DXF plug-in and have looked at the code. I've even
Andrea Aime wrote:
> I can confirm I'm using 1.1
Cool... I upgraded and the tests of course passed. Now we can cross our
fingers and hope the upgrade doesn't take out the uDig 1.1.x build.
If we can poke a larger hole in our firewall, we'll start sending out
trunk nightly build e-mails with on
Jody Garnett wrote:
> Some initial feedback ...
>
> The following packages no longer exist (uDig was explicitly exporting them):
> - org.geotools.coverage.io
> - org.geotools.data.coverage.grid.file
> - org.geotools.data.coverage.grid.stream
>
> I suspect these were line items on Simone's greatest
Some initial feedback ...
The following packages no longer exist (uDig was explicitly exporting them):
- org.geotools.coverage.io
- org.geotools.data.coverage.grid.file
- org.geotools.data.coverage.grid.stream
I suspect these were line items on Simone's greatest hits page:
-
http://docs.codehaus
On 2/27/07, Jody Garnett <[EMAIL PROTECTED]> wrote:
> Good timing - we were talking about this very topic in todays GeoTools
> meeting. And arriving at a similar spot - that OSGeo would be the best
> organization for the task.
>
> What we initial need however is someone on the "admin" side to get t
Hi Matthias - this email has now made it to the top of my "revisit"
stack :-D
> Question 1:
> Do I have the same goals/requirements as the GeoTools team in respect to
> expressions?
>
> A tough question. Yes, and no. With respect to its use for GIS purposes and
> looked at it "from some distan
Hey gabriel (and anyone else interested),
I'm finally getting trunk-on-trunk set up, and the first thing on my agenda is
to bring the 2.4.x arcsde plugin in-line with the 2.3.x package structure.
Once that's done then I can start porting the raster stuff into place.
Any objections if I start m
Cory Horner ha scritto:
> Martin Desruisseaux wrote:
>> Cory Horner a écrit :
>>
>>> So what *are* the requirements for building trunk? Our build box is
>>> running JDK-1.5.0_10 with JAI-1.1.3 and ImageIO-1.0_01 on linux. Am I
>>> doing something wrong, or is hsql just being flakey?
>>
>> Applie
Rob Atkinson ha scritto:
> I wouldnt mind answering questions, but actually watching the list would
> not be fun - is it possible to have a filter that sends messages to the
> module maintainer? Or if TOPP is committed to watching the list anyways
> can they undertake to forward using some stan
Re watching and answering user emails.
I can see the benefit of this, but its likely to be a showstopping
burden for many possible module maintainers.
I wouldnt mind answering questions, but actually watching the list would
not be fun - is it possible to have a filter that sends messages to the
Hi Andrea / Jesse - catch up to your comments.
What I would like out of this page is two fold:
a) a checklist so that some (ie me) can to some geotools work on a schedule
b) ensure we have written down what is needed (ie no new hurdles to jump
when a developer is near a deadline) while at the sam
Martin Desruisseaux wrote:
> Cory Horner a écrit :
>
>>So what *are* the requirements for building trunk? Our build box is
>>running JDK-1.5.0_10 with JAI-1.1.3 and ImageIO-1.0_01 on linux. Am I
>>doing something wrong, or is hsql just being flakey?
>
>
> Applied a fix on trunk as of revision
>> In terms of specifics ...you know how GeoServer extends plugins a
degree of trust (that the quality is good enough that you can handle
the support emails?). uDig has the same tradeoff but our user
community is different.
I don't really think we have a formal procedrue. It's about user aski
Andrea Aime wrote:
>> It is too bad I was not able to quantify the difference in needs
>> between GeoServer and uDig - it is mostly an "ease of use" thing -
>> basically uDig requires a plug-in to work out of the box and provide
>> errors/warnings in a form that do a casual user some good.
> Hum
Jody Garnett ha scritto:
> Andrea Aime wrote:
>>> It is too bad I was not able to quantify the difference in needs
>>> between GeoServer and uDig - it is mostly an "ease of use" thing -
>>> basically uDig requires a plug-in to work out of the box and provide
>>> errors/warnings in a form that do
Gabriel Roldán ha scritto:
> Hi all,
>
> I am going to move the CQL module to supported land in trunk under plugins,
> if
> nobody has an objection. As per the module page
> http://docs.codehaus.org/display/GEOTOOLS/CQL+Parser it seems to comply with
> the requirements to become supported. Ext
Jody Garnett ha scritto:
> Hi Gabriel
>
> I would like to fold CQL Parser into the core library; Mauricio's work
> is important enough on a usability side to be "core".
Hmmm I was thinking of exactly the opposite? That is, give it a
module, and split out the Filter XML parsers as modules to
Andrea Aime wrote:
> Jody Garnett ha scritto:
>
>> Although I am tempted to toughen up the language a bit: "A supported
>> module is a commitment from the PMC to the user community that this
>> stuff will work (and we confident enough that we can fix it in a
>> timely fashion)"
>>
>> Perhaps you
Victor Mauricio Pazos wrote:
> Ok, then you are right. I think that using CQL as utility is better option
> because it hides the implementation (the "new" statement) then we resolve
> future maintenance problems.
>
> I only would suggest a bit change in the protocol signatures thinking in
> l
Jody Garnett ha scritto:
> Okay thanks for the feedback and chat - at this stage of life "email
> support" should be near the top of the list - although for module
> maintainers that *cannot* budget the time to do this I think user
> documentation is an acceptable alternative.
>> Here is how a
Andrea Aime wrote:
> Jody Garnett ha scritto:
>
>> Although I am tempted to toughen up the language a bit: "A supported
>> module is a commitment from the PMC to the user community that this
>> stuff will work (and we confident enough that we can fix it in a
>> timely fashion)"
>>
>> Perhaps you
Hi Gabriel
I would like to fold CQL Parser into the core library; Mauricio's work
is important enough on a usability side to be "core".
Jody
> Hi all,
>
> I am going to move the CQL module to supported land in trunk under plugins,
> if
> nobody has an objection. As per the module page
> http:/
Jody Garnett ha scritto:
> Although I am tempted to toughen up the language a bit: "A supported
> module is a commitment from the PMC to the user community that this
> stuff will work (and we confident enough that we can fix it in a timely
> fashion)"
>
> Perhaps you mean in terms of bug fixes
Sorry for late response and sorry for improper list in previous mail,
>
>Could you try the following add see what we get please?
>
>System.out.println(CRS.findMathTransform(coverage.getCoordinateReferenceSystem(),
>derivedCRS)?
>
CRS.findMathTransform returns expected transformation for example
Hi all,
I am going to move the CQL module to supported land in trunk under plugins, if
nobody has an objection. As per the module page
http://docs.codehaus.org/display/GEOTOOLS/CQL+Parser it seems to comply with
the requirements to become supported. Extra feedback welcome though.
I also want t
Create CQL utility class and hide parser implementation
---
Key: GEOT-1174
URL: http://jira.codehaus.org/browse/GEOT-1174
Project: GeoTools
Issue Type: Improvement
Components: new
[
http://jira.codehaus.org/browse/GEOT-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriel Roldán reopened GEOT-1169:
--
reopening as it still needs to be ported to 2.3.x
> CQL Parser should allow nested function calls
> -
Andrea Aime a écrit :
> Hum, wondering if I could avoid reporting them in the srs list. I don't
> think we can do anything useful with them, Geoserver is dealing only
> with 2d data so far. Is there a way to tell that a CRS is 3D by using
> instanceof? Are these "compound" CRS?
Some are instance o
Jody Garnett ha scritto:
> If you want we can write up a proposal for FeatureSource.features(
> String query, String queryLanguage ) again ... I would like
> it so we can support SQL as in Gabriels community schema branch ie.
> source.features( sql, "SFSQL" );
So, the idea is to allow JDBC
Ok, then you are right. I think that using CQL as utility is better option
because it hides the implementation (the "new" statement) then we resolve
future maintenance problems.
I only would suggest a bit change in the protocol signatures thinking in
legibility and flexibility:
col = featur
Jesse Eichar ha scritto:
> Just reviewed Jody's Supporting your module WIKI page. Makes sense
> to my befuddled state. Any one else have opinions? Seems to say
> that there are procedures for obtaining supported module status. I'd
> suggest other check it out since it will impact anyone t
Jesse Eichar ha scritto:
> Hi all,
>
> I've just gone over Jody's write up about the GeoTools Change
> Proposal. You can check it out yourself at: http://docs.codehaus.org/
> display/GEOT/GeoTools+change+proposal. It looks fine to me. So
> speak now or forever hold you peace. I've removed
Martin Desruisseaux ha scritto:
> Begining with the first exception on the list...
>
> This is a 3D CRS, and there is no way I'm aware of to specify the unit of the
> vertical axis, since the only "UNIT" element is already used for the lat,long
> axis.
Hum, wondering if I could avoid reporting
34 matches
Mail list logo
