Re: [Geotools-devel] MapContext extends MapContent

Hi Andrea and Jody, A few minor comments from the back row... Having content specific Layers makes the swing module much easier to code in a readable and reliable manner. I imagine the same will be true for the swt module. It would be good, well essential really, to have a StyleLayer with getSty

Re: [Geotools-devel] plugin branch created

> Don't know about the rest, but gt-util seems like a bad name to me > would make me think it's a module filled with assorted utility classes. I do agree with Andrea: I would intuitively look for "optional" utilities/helpers in a module named gt-util. > I took the name from a discussion we ha

Re: [Geotools-devel] plugin branch created

> * As long as FactoryFinders work the library will function > And leaves me with the following problem to wrestle with: > - Can we "fix" FactoryRegistery (and fold out code in behind it?) > - Or do we need to just flat out replace it I just bumped in the Apache Commons Discovery project (via an A

Re: [Geotools-devel] plugin branch

> Thanks! I have added you into the mix - indeed welcome to the geotools > project :-) Thanks, I'll do my best. I have successfully checked out and built the branch. I will now start trying some OSGi prototypes, which will probably give me a better guts feeling of the challenges, classes and conc

Re: [Geotools-devel] MapContext extends MapContent

A few minor comments from the back row... > > Having content specific Layers makes the swing module much easier to > code in a readable and reliable manner. I imagine the same will be > true for the swt module. > > It would be good, well essential really, to have a StyleLayer with > getStyle / se

Re: [Geotools-devel] [udig-devel] udig 1.2.2 work party - antlr?

Hi Jody, Andrea, The reason for the two versions is that the ANTLR StringTemplate library shipped with ANTLR 3.3 actually depends on ANTLR 2.7.7. I know that's weird but it's just how it is. The Jiffle scripting language uses ANTLR 3.3 for its parser and StringTemplate for its run-time code genera

Re: [Geotools-devel] plugin branch created

On Sunday, 8 May 2011 at 6:54 PM, Mathieu Baudier wrote: * As long as FactoryFinders work the library will function > > And leaves me with the following problem to wrestle with: > > - Can we "fix" FactoryRegistery (and fold out code in behind it?) > > - Or do we need to just flat out replace it > I

Re: [Geotools-devel] [udig-devel] udig 1.2.2 work party - antlr?

So in other words I am a noodle for removing antlr 2.7.7 every other time; putting poor movida through grief :-) Okay putting it back... -- Jody Garnett On Sunday, 8 May 2011 at 9:49 PM, Michael Bedward wrote: > Hi Jody, Andrea, > > The reason for the two versions is that the ANTLR StringTempl

Re: [Geotools-devel] [udig-devel] udig 1.2.2 work party - antlr?

No, I noodled you because I told you it was ok to take it out a while ago, and then I snuck off and made Jiffle depend on it. On 8 May 2011 22:00, Jody Garnett wrote: > So in other words I am a noodle for removing antlr 2.7.7 every other time; > putting poor movida through grief :-) > Okay puttin

[Geotools-devel] eclipse cross-project dependencies

I have a basic question about how projects are/should be set up in eclipse. I used maven eclipse:eclipse to create .project and .classpath files for all the projects. But I see that the .classpath files have cross-project dependencies done using jar files rather than depending directly on the o

Re: [Geotools-devel] Removing old/unused/aborted

Dear All, trying to reach a first step in this cleaning effort, I have identified this list: - caching? Looks like an abandoned module to me - db2 - mysql - oracle-spatial - sql-datastore - geometryless - gpx2 Can I move forward and remove these modules? We can then discuss about better ways to h

Re: [Geotools-devel] eclipse cross-project dependencies

On Sun, May 8, 2011 at 4:13 PM, lee-verizon wrote: > I have a basic question about how projects are/should be set up in > eclipse. I used maven eclipse:eclipse to create .project and .classpath > files for all the projects. But I see that the .classpath files have > cross-project dependencies done

[Geotools-devel] Build failed in Hudson: geotools-trunk #3542

See Changes: [simonegiannecchini] removing deprecated methods from NumberRage -- [...truncated 12868 lines...] Running org.geotools.geometry.iso.primitive.BoundaryTest Tests run: 1, Failure

Re: [Geotools-devel] eclipse cross-project dependencies

I did run it in the root originally, and I see now that the supported modules indeed have the correct dependencies, but the unsupported modules do not. In particular, the unsupported module I'm working on - CSV. Should I just do it by hand, or is there a way to persuade maven to do the unsuppo

Re: [Geotools-devel] Removing old/unused/aborted

On 7 May 2011 19:44, Jody Garnett wrote: > Quick question; the excel plugin was mentioned recently on the geoserver > (http://jira.codehaus.org/browse/GEOS-4461) list by Shane. > Shane we we considering dropping things from GeoTools unsupported that do > not have a friend. > Perhaps you would cons

[Geotools-devel] [jira] Created: (GEOT-3572) Add ZonalStats operation to GeoTools based on JAI-Tools code

Add ZonalStats operation to GeoTools based on JAI-Tools code Key: GEOT-3572 URL: http://jira.codehaus.org/browse/GEOT-3572 Project: GeoTools Issue Type: Task Components:

[Geotools-devel] Build failed in Hudson: geotools-trunk #3543

See Changes: [simonegiannecchini] fixed JAI-tools version -- [...truncated 12854 lines...] Running org.geotools.geometry.iso.primitive.BoundaryTest Tests run: 1, Failures: 0, Errors: 0, Ski

[Geotools-devel] Build failed in Hudson: geotools-trunk #3544

See Changes: [simonegiannecchini] GEOT-3572 [simonegiannecchini] GEOT-3572 [simonegiannecchini] GEOT-3572 [simonegiannecchini] GEOT-3572 -- Started by an SCM change Updating http://svn.o

Re: [Geotools-devel] eclipse cross-project dependencies

On Sun, May 8, 2011 at 7:23 PM, lee-verizon wrote: > I did run it in the root originally, and I see now that the supported > modules indeed have the correct dependencies, but the unsupported modules do > not. In particular, the unsupported module I'm working on - CSV.  Should I > just do it by han

Re: [Geotools-devel] Removing old/unused/aborted

Hi, I actually completed and submitted the changes to the GeoServer Excel output format plugin. You can see the code here: http://svn.codehaus.org/geoserver/trunk/src/extension/excel/src/main/java/org/geoserver/wfs/response/

Re: [Geotools-devel] eclipse cross-project dependencies

Ah. I thought I had done that before. I'm a bit of a maven novice, so thanks. That fixed it. Lee On 5/8/2011 12:15 PM, Andrea Aime wrote: > On Sun, May 8, 2011 at 7:23 PM, lee-verizon wrote: >> I did run it in the root originally, and I see now that the supported >> modules indeed have the corr

[Geotools-devel] Build failed in Hudson: geotools-trunk #3545

See Changes: [simonegiannecchini] fix in world file writer [moovida] fixing testcase names [moovida] new testcases to check odd behaviour -- Started by an SCM change Updating http://svn.o

Re: [Geotools-devel] CSV tutorial with ContentDataStore

On Monday, 9 May 2011 at 12:07 AM, lee-verizon wrote: I'm making (slow) progress on the CSV store. I have the count() thing fixed. Now moving on to the actual updating. > Cool. > A couple more questions: > > 1. It looks like ContentFeatureStore.getWriter(Query, int) does not (yet) > implem

Re: [Geotools-devel] Removing old/unused/aborted

The svn repository moved some time ago to osgeo hardware: - http://svn.osgeo.org/geotools/trunk/modules/unsupported/excel/ GeoTools and GeoServer in general get along very well together so installation would stay simple; Ian Turton also expressed interest in the Excel plugin and may be able to i

[Geotools-devel] Build failed in Hudson: geotools-trunk #3546

See Changes: [simonegiannecchini] GEOT-3572 [simonegiannecchini] fix in world file writer -- [...truncated 3874 lines...] at org.geotools.data.shapefile.ShapefileDataStore.openSha

[Geotools-devel] coverage tests / build fixes

A couple of coverage tests were broken this morning: Tests in error: testGoogleWorld(org.geotools.coverage.processing.ResampleTest) testWarpCompareGoogleWorld(org.geotools.coverage.processing.ResampleTest) > testGoogleWorld(org.geotools.coverage.processing.ResampleTest) Time elapsed: > 0.087 se

Re: [Geotools-devel] coverage tests / build fixes

I continue to get merge conflicts as Simone is also fixing the build; sigh. Cannot find him on IRC or skype to collaborate. -- Jody Garnett On Monday, 9 May 2011 at 8:26 AM, Jody Garnett wrote: > A couple of coverage tests were broken this morning: > > Tests in error: > testGoogleWorld(org.g

[Geotools-devel] Build failed in Hudson: geotools-trunk #3547

See Changes: [simonegiannecchini] cleaning up tabs [simonegiannecchini] fixing build [simonegiannecchini] fixed test data -- [...truncated 12888 lines...] Running org.geotools.geometry.is

Re: [Geotools-devel] coverage tests / build fixes

Okay now that simone has fixed things we have jgrass raster: Failed tests: testDifferentResolution2(org.geotools.gce.grassraster.AdvancedReaderTest) testRasterReaderBoundsAndRes(org.geotools.gce.grassraster.AdvancedReaderTest) testScaling(org.geotools.gce.grassraster.JGrassUtilsTest) -- Jody G

Re: [Geotools-devel] MapContext extends MapContent

Nope, watermarking is handled as post processing after the rendering process > happened. Watermarking, and map decoration handling in general, is indeed the > only > cleanup we'd get in GeoServer land, updating the rest of the code to use > MapContent/Layer looks like a mere refactoring otherwise

Re: [Geotools-devel] coverage tests / build fixes

After a brief chat with moovida this morning I know he is having platform specific trouble for the jgrass code. Moovda I have commented out your tests with a TODO comment; I have indicated the value produced on mac for your reference. I figured you would like the geotools build working today; r

[Geotools-devel] Hudson build is back to normal : geotools-trunk #3548

See -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset availab

[Geotools-devel] NumberRange huh?

Okay there is a random breakage; I thought perhaps I was not paying attention and some compile settings changed? NumberRange( double, double ) needs to be: NumberRange(Double.class, min, max ); I did not plan this change; it is breaking geoserver now; any ideas? -- Jody Garnett On Monday, 9

Re: [Geotools-devel] CSV tutorial with ContentDataStore

So I'd like to run the JDBC unit tests regularly while I'm hacking around to make sure I don't break anything. I went to gt-jdbc and ran "mvn test" but that doesn't seem to run very many tests. Do I need to run all the tests in org.geotools.jdbc, and if so how? Thanks, Lee On 5/8/2011 2:30

[Geotools-devel] EMF Jars (ie GEOT-3567)

Justin; I expect we are all waiting for your feedback on this one: - http://jira.codehaus.org/browse/GEOT-3567 Kenneth is blocked on further development of his community module until this is applied; and we want to make sure you are content with the change as so much of your code requires EMF. -

Re: [Geotools-devel] NumberRange huh?

Removal of deprecated constructors is an API change and should have been discussed on the list, at the least. Or did I miss it? There are no Jira issues for gt-metadata since 20 April, and there was no Jira issue recorded in the commit log for this change. Please think of the impact on client c

Re: [Geotools-devel] CSV tutorial with ContentDataStore

There is a trick; gt-jdbc is "abstract" and does not do much :-) You need to run the tests for gt-jdbc-h2; it uses a pure java database so the tests can self contained. -- Jody Garnett On Monday, 9 May 2011 at 11:26 AM, lee-verizon wrote: > So I'd like to run the JDBC unit tests regularly whi

Re: [Geotools-devel] NumberRange huh?

Simone has been updating a JIRA to this effect; - http://jira.codehaus.org/browse/GEOT-3557 I also ask that we update the following page: - http://docs.codehaus.org/display/GEOTOOLS/Upgrade+to+8.0 -- Jody Garnett On Monday, 9 May 2011 at 11:40 AM, Ben Caradoc-Davies wrote: > Removal of depre

Re: [Geotools-devel] MapContext extends MapContent

Sorry to be slow of brain, but I'm getting a bit lost now... Perhaps if I just explain what JMapPane currently does (plus the branch code updates) someone can help me to understand how this does, or doesn't, fit with the ideas being discussed. There are two bounding rectangles: map and display. W

Re: [Geotools-devel] Doc Module Maintainer offer

G'day Jody, Many thanks for this offer which I would be pleased to accept - especially since you've done all of the hard work :) Michael On 8 May 2011 13:14, Jody Garnett wrote: > Afternoon Micheal: > I was thinking about the docs module; and I would like to extend to you an > offer / idea. >

Re: [Geotools-devel] MapContext extends MapContent

Sorry to be slow of brain, but I'm getting a bit lost now... Perhaps > if I just explain what JMapPane currently does (plus the branch code > updates) someone can help me to understand how this does, or doesn't, > fit with the ideas being discussed. The ideas being discussed seem to be going okay;

Re: [Geotools-devel] MapContext extends MapContent

Many thanks for the explanations Jody - thanks great. I'm catching up now :) > Q: How does angle effect your worldToScreen and screenToWorld transforms? Do > you need to > make the extra concatenated transform available for tools to work etc? I'm embarrassed to admit it's been so long since I loo

Re: [Geotools-devel] coverage tests / build fixes

Hi Jody, definitely yes, thanks for commenting them out. Strange thing is I tested those both on win and linux. I'll check this. Thanks, Andrea On Mon, May 9, 2011 at 1:43 AM, Jody Garnett wrote: > After a brief chat with moovida this morning I know he is having platform > specific trouble for

[Geotools-devel] coverage scaling issue

Hi coverage friends, I have a strange scaling issue that is giving troubles to my testcases and need some advice. Let's assume I have a small raster containing the data: {1000.0, 1000.0, 1200.0, 1250.0, 1300.0, 1350.0, 1450.0}, // {750.0, 850.0, 860.0, 900.0, 1000.0, 1200.0, 1250.0}, // {700.0, 7