[Geotools-devel] [Fwd: [jira] Closed: (GEOT-1884) plugin/gtopo30 need to clarify origin of data]
Hey all, This just for info since we had at one time worked so hard on the provenance of all the files in the project. You have undoubtedly already discussed this as a group and decided not to care where this file originated. However, since it came in to my inbox, I felt responsible to make you all aware this was what had happened. all the best, --adrian Forwarded Message From: Simone Giannecchini (JIRA) j...@codehaus.org To: acus...@gmail.com Subject: [jira] Closed: (GEOT-1884) plugin/gtopo30 need to clarify origin of data Date: Thu, 8 Apr 2010 16:54:22 -0500 (CDT) [ http://jira.codehaus.org/browse/GEOT-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Giannecchini closed GEOT-1884. - Resolution: Won't Fix plugin/gtopo30 need to clarify origin of data - Key: GEOT-1884 URL: http://jira.codehaus.org/browse/GEOT-1884 Project: GeoTools Issue Type: Sub-task Components: gc gtopo30 Reporter: Adrian Custer Assignee: Simone Giannecchini The origin and license of the data file W002N52.zip needs to be determined. -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] How to generate javadoc 2.5.x (and later?)
Hey all, Cedric is back from too much snow, the poor boy, and too much skiing. He's sharing with us the magic incantations to get the build generating javadocs. There are problems at various levels. 0) Protective, paranoid cleanup rm -Rf ~/.m2/repository/org/opengis rm -Rf ~/.m2/repository/org/geotools rm -Rf ~/.m2/repository/it/geosolutions 1) Checkout tag (2.5.3) 2) First compile: (with Java 6, maven 2.0.9) maven install -Dall -DskipTests = Build fails because coveragetools pom is borked. = If you don't skip tests: first, referencing and epsg-hsql fail, - well known issues, processor dependent, - tests of referencing and epsg-hsql pulled from trunk, patch attached for 2.5.x, then, renderer fails (pulling tests in same way works on trunk), then, jdbc-ng/jdbc-postgis: postgisEmptyTest seems to deadlock. (Adrian gives up.) = If you use -Dmaven.test.skip (which doesn't build the tests), you are asking for more issues: 1. legacy will fail because it depends on main-test. You'll have to go into main and compile its tests to get a build working. 2. gt-jdbc also breaks with dependency on some test. 3. jdbc-ng and possibly others (h2) possibly have issues, like depending on the existence of their tests to be able to compile. Here, we go faster with -DskipTests 3) Build, by hand, gt-imageio-ext-gdal cd modules/plugin/imageio-ext-gdal/ maven install cd ../../.. 4) Second compile maven install -Dall -DskipTests 5) Build javadocs cd modules/ mvn javadoc:javadoc -Dall -DskipTests = wait a while, suffer through a slew of warnings but it builds the docs in modules/target/site/apidocs/ 6) zip that dir and place online. (starting in modules) cd target/site/apidocs zip -r -9 geotools-2.5.3-javadocs.zip * = generates a 29M file Moral: * Renderer tests need love for Java6 * Our builds depend on our tests! * Coveragetools/gt-imageio-ext-gdal relationship is sick. Thanks to build master Cedric for slogging through the alternatives and finding the solutions, --adrian Index: modules/library/referencing/pom.xml === --- modules/library/referencing/pom.xml (revision 32436) +++ modules/library/referencing/pom.xml (working copy) @@ -155,8 +155,20 @@ /roles /contributor /contributors + + !-- === Skip Testing since this is broken on Java6 === -- + build +plugins + plugin +groupIdorg.apache.maven.plugins/groupId +artifactIdmaven-surefire-plugin/artifactId +configuration + skipTeststrue/skipTests + /configuration + /plugin +/plugins + /build - !-- === -- !-- Dependency Management -- !-- === -- Index: modules/plugin/epsg-hsql/pom.xml === --- modules/plugin/epsg-hsql/pom.xml (revision 32436) +++ modules/plugin/epsg-hsql/pom.xml (working copy) @@ -96,8 +96,22 @@ /roles /developer /developers + + !-- === Skip Testing since this is broken on Java6 === -- + build +plugins + plugin +groupIdorg.apache.maven.plugins/groupId +artifactIdmaven-surefire-plugin/artifactId +configuration + skipTeststrue/skipTests + /configuration + /plugin +/plugins + /build + !-- === -- !-- Dependency Management -- !-- === -- -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] testing and java 6
As per the mail ten seconds later, tests die in java6, required for java6 code should not be being modified so tests should not break anew revert as you will. --adrian On Mon, 2009-02-09 at 22:03 +1100, Jody Garnett wrote: Hi Adrian; I watched your commit go by: - (9:59:03 PM) CIA-21: acuster * r32439 /trunk/modules/ (library/referencing/pom.xml plugin/epsg-hsql/pom.xml): Build fixes: pull referencing and epsg-hsql from testing Something about removing epsh-hsql from testing; we actually like tests here as it is the only one that actually tests the referencing module handling of epsg codes; and lookup by identified object and all of that. What is up? Jody -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] testing and java 6
I've already spent way too much time on this today so I don't want to get into a long discussion as well. Right now, to build on Java6, you skip all the tests with -DskipTests. I disabled the tests in two modules, modules which are 'stable' (i.e. no one should be modifying those modules) and are scheduled for replacement. That buys you being able to see what else is blowing up in Java6 and starting to identify other failures and repair your way through them. That seems a whole lot more helpful than telling folk to skip all the tests so no one ever learns what's going on. If you don't like it, revert it. Or add a profile, or ... On Mon, 2009-02-09 at 12:23 +0100, Andrea Aime wrote: Adrian Custer ha scritto: As per the mail ten seconds later, tests die in java6, required for java6 code should not be being modified so tests should not break anew revert as you will. Afaik there is a way to make test disabling trigger only on java6, which is, using a profile with a jdk detection as its activation rule. Also, afaik there is just one test failing, and it's in epsg-hsql (at least, it's the only failure I have on my Ubuntu 64bit box with Sun java 6). Why were referencing tests disabled at all? because they fail. Cheers Andrea -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GeoTools and Maven
Hey, Maven rocks, it gets the job done, it is vastly easier than any alternative, and is comparatively a pure joy. There is quite simply zero chance that the use of maven would be changed. Learning maven is hard because what it is doing is immensely complex not because maven is hard as far a build tools go. If you want hard, play for ten minutes building any complex C program from source. Autoconf and Automake are very powerful too but it takes a programming god to master them. And after your ten minutes have become two weeks, come back and enjoy maven. The benefits of maven are too many to list. Having a single build tool for the whole project makes developers need only learn a single one. Using maven allows external tools like hudson to run the build. Using maven allows us to get libraries off the standard repositories. Using maven... cheers, -adrian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GeoTools and Maven
Hey, Honestly, you are so far off the mark that it's not worth discussing. Geotools needs a build tool. You say a Java project doesn't need to have a build tool and experience says otherwise. Not using a build tool would be plain idiotic. Any reasonably sized project has a build tool. So look around, notice that it is so, and ask yourself why. Geotools cannot afford to have more than one. That's experience from any number of projects. Every effort to mix tools that I have ever seen has been a total fiasco. Very tempting for the short sighted: Hey, we can do that in three lines of code with tool xyz. Very painful over the long term. Look around, see that very few projects mix build tools, and ask yourself why. Which one to choose? Doesn't matter, Geotools chose. Much like choosing a language determines the character of a project, choosing a build tool is something that happens along the way. Changing is very costly and only done for *really* good reasons. The only other tool with the power of maven in common use that I know of is Ant. Several projects use Ant with some success. When you compare the complexity of the OpenSSO system based on Ant with the complexity of a maven based system, you quickly see why projects are regularly moving to maven. But again, it doesn't matter, Geotools chose maven. Maven is not cast in bronze, merely carved in stone. For it to be worth replacing, the replacement would have to be absolutely fantastic, widely known, with repositories all over the place. So if you find something that good, that widely supported, and that commonly known, by all means suggest it. So, if maven is a blocker for you, no problem. Grab a mercurial/bzr/git copy of the full repository and hack away using whatever you like. Free software for free people. Want to mix in another language? Great, it's your code, do with it what you will. But, *if* you want to throw your code into the common pool, then you have to do the work to play by the same rules that everyone knows so that no one has to learn the particular rules you happened to choose to work with. And with that, you have wasted enough of my time for today. Have a good evening, --adrian And no, maven rocks is not a feeling---it's observation gleaned from the experience of all the other tools I have come across. I hate maven just like I hate all build tools---getting code to build is a pain all around. Maven rocks because it is far less painful than any alternative I have ever worked with. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] ECQL finished
On Tue, 2009-01-27 at 20:04 +0100, Mauricio Pazos wrote: Hi list, I have finished the ECQL documentation and I have changed to public the ECQL facade in trunk. User Doc http://docs.codehaus.org/display/GEOTDOC/03+ECQL+Examples Design http://docs.codehaus.org/display/GEOTOOLS/ECQL+Parser+Design cheers congratulations on all the hard work to get this to land! --adrian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [udig-devel] Easting crow and error messages
Hey Jody, 1) This should be on geotools, no? 2) gt2 doesn't build with java 6, only java 5 3) gt2 javadocs *do* require java6 --adrian, going out to brave the storm on the way home. On Tue, 2009-02-03 at 09:47 +1100, Jody Garnett wrote: Okay so legacy will not compile unless you build the tests for main (so mvn install -Dmaven.test.skip=true) is no longer a valid way to get going quickly. With that out of the way I have a failure when building with Java 6 in the coverage module:--- Test set: org.geotools.coverage.processing.OperationsTest --- Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.321 sec FAILURE! testSubtract(org.geotools.coverage.processing.OperationsTest) Time elapsed: 0.059 sec FAILURE! java.lang.AssertionError: at org.junit.Assert.fail(Assert.java:74) at org.junit.Assert.assertTrue(Assert.java:37) at org.junit.Assert.assertTrue(Assert.java:46) at org.geotools.coverage.processing.OperationsTest.testSubtract(OperationsTest.java:115) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie $2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner $1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140 ) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) ___ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] javadocs or 2.5.3
On Fri, 2009-01-30 at 16:04 -0700, Justin Deoliveira wrote: So I guess I will throw it out to other people. Could someone else try generating them. Remember it takes java 6 and apparently a non mac os. -Justin tried and failed; don't know the magic incantation. --adrian -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] javadocs or 2.5.3
Justin Deoliveira wrote: Hi Cedric, I was wondering if you would not mind generating the javadocs for the 2.5.3 release. Thanks a bunch. -Justin he just went skiing for a week. --adrianl -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] CSW INSPIRE
Hey Christian, It would be wonderful to work with you---our own projects, MdWeb, Constellation, and MapFaces, despite being free software, are almost entirely developed by us alone. We have not yet reached the point of having a rock solid base which we would want widely used nor the level where we feel the code is clean enough to be easy to understand. Indeed, we are right now in the middle of a big refactoring to tidy up the code of Constellation and, in the near future, we expect to move to use geotidy rather than the modified geotools we are currently using. So in the next month, we will be in some flux but, after that, we should have a foundation that I'm excited about (actually, maybe that's merely the lack of sleep recently). Anyhow, working with others is bound to make us work better. 1) Yes the version number of Geotools that is being used is 2.9, a *horrible* setup. I think of it as 'pissing in the version number pool' after the title of a novel a friend of mine was reading once. Had I been around when that happened, I would have yelled bloody murder to stop such a thing---but these developers have never suffered through being on the receiving end of that kind of version number mess. The actual code is an internal fork of geotools 2.5 from mid-2008. The code is on a mercurial server: http(s)://hg.geomatys.fr/gt_working and is deployed to geotools.fr. It should compile in the same way as your geotools would. I don't think anyone has changed that code in a few months. Note that this code will be re-worked in the near future once Martin finishes referencing in Geotidy. (The last critical piece in referencing is integrating the EPSG databases.) As soon as Geotidy is ready, we will make gt_working depend on it---warmup for porting Geotools-java5 to it. I'm hoping, at that point, to take a look at what's inside as well so that we could split it into three pieces: Md/Ref (dropped for Geotidy) - Feature - Our Extensions where the middle piece would be almost exactly what is in Geotools svn. Unfortunately, it's not going to be this clean so I'm not sure how complex that will be. The next two months then will see lots of changes in our code stack and we will come out of that work with something very clean and robust. 2) We do consider internationalization extremely important so we would be quite happy to improve that aspect of the code and work with you on German. 3) No idea about Websphere but we test and run on Tomcat and various flavours of Glassfish and only use standard JEE functionality so there is no reason this should be an obstacle. The service layer is a quite small part of the overall project anyhow so it should be trivial to integrate the work into any kind of server. 4) We actually have an abstraction of the backend which can also run on a raw filesystem. Martin is away traveling right now but I know he's also thinking of working on JavaDB and other backends. However, I'm not sure where things stand on that right now. All right, enough for now. Anytime you have questions, there are generally some of us on irc in #geotools or #geomatys or other channels like #osgeo. If you want to have a longer discussion, we can talk by phone or by other means. all the best, --adrian On Thu, 2009-01-22 at 16:34 +0100, Christian Müller wrote: Good news, as far as i see, there is no other csw implementation based on geotools. MDweb2 is a now a hot candidate. I would like to join your development efforts. Questions: 1) Which version of geotools do you use. Looking in the war file I see gt jars with version 2.9. ??? 2) I need a german translation which I could contribute, are all String externalized (I have seen en and fr property files) 3) I have to deploy into Webshpere Application Server (my challenge, I did the same successfully with geoserver) 4) I cannot use postgres/postgis. My target is DB2. Does your design make it possible to implement a db2 access module. (Btw, I can contribute an oracle/mysql module, I did the same for my geotools imagemosaic-jdbc plugin). christian Vincent Heurteaux writes: Salut Christian, We've the same concern and are involved in several project that needs INSPIRE conformance. MDweb2 is one of those (a metadata catalog application) and it's using extensively GT on it's backend. We're curently working on the metadata library to give it a full INSPIRE conformance, so if you've questions or comments about that, don't hesitate to chime us. Cheers, Vincent Le 22 janv. 09 à 08:11, Christian Müller a écrit : As far as I am concerned, I would try to enhance geotools to better support the INSPIRE EU directive. This directive is from the European Commission and all member states have to build a national GDI using all these ISO, W3C and OGC standards. The time frame ends with 2015, but many national projects have been launched
Re: [Geotools-devel] Request to move gt-imageio-ext-gdal to supported land (plugin modules).
On Wed, 2009-01-21 at 10:17 +0100, Andrea Aime wrote: ... Adrian Custer ha scritto: How did you resolve the 'advertising clause' issue? Are we expecting to change all our docs to include the credit requested by SUN? ... Reading into this GNU document about the nature of the BSD issue: http://www.gnu.org/philosophy/bsd.html It really seems the only issue GNU sees is a matter of practicality, that is, that if you have 70 different BSD style licenses, you have to add full page ad to the material you distribute to cite all of them... As usual, no lawyer, so I may be just plain wrong. That is my understanding as well. The GeoTools project and all dependent projects would gain the obligation to cite SUN in their core project document. Essentially, GeoTools becomes licensed under 'LGPL + documentation obligation', if you will. This is not incompatible but will be more work and imposes a new obligation so the change should be undertaken as a conscious decision rather than happen as an un-intended side-effect of other work. --adrian -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] time for a psc update?
Hey, As usual you three have wise thoughts, so I'll keep hoping that somehow this will all work out for the best and keep my more radical notions to myself. --adrian -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Request to move gt-imageio-ext-gdal to supported land (plugin modules).
On Wed, 2009-01-21 at 11:43 +0100, Andrea Aime wrote: Adrian Custer ha scritto: On Wed, 2009-01-21 at 10:17 +0100, Andrea Aime wrote: ... Adrian Custer ha scritto: How did you resolve the 'advertising clause' issue? Are we expecting to change all our docs to include the credit requested by SUN? ... Reading into this GNU document about the nature of the BSD issue: http://www.gnu.org/philosophy/bsd.html It really seems the only issue GNU sees is a matter of practicality, that is, that if you have 70 different BSD style licenses, you have to add full page ad to the material you distribute to cite all of them... As usual, no lawyer, so I may be just plain wrong. That is my understanding as well. The GeoTools project and all dependent projects would gain the obligation to cite SUN in their core project document. Essentially, GeoTools becomes licensed under 'LGPL + documentation obligation', if you will. This is not incompatible but will be more work and imposes a new obligation so the change should be undertaken as a conscious decision rather than happen as an un-intended side-effect of other work. What about the following: - someone takes a binary distribution of GeoTools, goes thru all the extra jas, and makes up a page with deps and their licenses. A simple table with the jar names grouped per license, and a reference to the license would do, wouldn't it? - we make it a project procedure that whoever adds a dependency to any supported module has to update that page - we also make it a project procedure that the release manager double checks the jars around during the release and sees if all of them are covered in the license page If that is ok, I'm ready to throw in a weekend of mine to setup the above wiki page Cheers Andrea Your proposal would be quite useful. The page would formally document where we stand and your procedural proposal would formalize our treatment of code dependencies. Together that would complete the review that the OSGeo incubation started us off on. We may also discover that we have additional responsibilities beyond what we thought. I suspect you will want to have separate sections for the core library, the plugins, and the experimental work. Since you are willing to write up the page, please do that work. That will give us a better sense of where we are today and should clarify the next steps. We may indeed want to change the formal statement of the overall project license from this is lgpl to some more accurate statement. The move to GPLv3+ would be wonderful as well. It would take me some time to evaluate the difference between moving to LGPLv3 or GPL +CLASSPATH since I have not read either license; I favour the latter merely out of deference to the CLASSPATH project. But either way, they are a better licenses for everyone, including GeoTools. And being able to work with Apache code seems nothing but fantastic, well, actually, merely reasonable in today's age. So let's clarify where we stand globally first, then figure out what our LICENSE files and headers should actually say to document that, and third, if there is consensus and it simplifies things, upgrade the license to a new version. You get the ball rolling and I'll pitch in on the second part. Yes, I know it's shitty work---I'd rather be watching the clouds too. --adrian -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] time for a psc update?
Hello Justin, On Mon, 2009-01-19 at 09:51 -0700, Justin Deoliveira wrote: Hi all, I have been thinking lately that perhaps it is time for a PSC update. You are right to raise this issue since we all realize the PMC is indeed quite ill. However, merely appointing new members to the board offers no promise of actually revitalizing the leadership. It seems more radical action is needed. Over the past two months I have been toying with the idea of asking you all to step down so that we could run the project by consensus rather than by fiat for a while, i.e change the dynamic. Please realize that none of this is intended as a comment personally to any of you as human beings,as coders, or as musicians but rather comes as my reflection on the leadership you six have brought to GeoTools in 2008-2009. While PMC members have moral responsibilities towards the community and technical obligations to the project, few of you are contributing to the level of a leader and none of you have been following your obligations. The moral responsibilities of the leaders of a free software project are obviously ambiguous but perhaps involve placing taking decisions in the best interests of the project, nurturing the community around the project, reaching out to other groups, addressing the divergent interests, and building the project for the long term. The technical responsibilities of PMC members are spelled out in the developers guide which I am sure none of us have read for a long, long time but contain clauses that none of the PMC members are following. Perhaps those requirements are obsolete but the correct course of action then would be to change such regulations not to ignore them. The juxtaposition of a governance system based on a PMC, coupled with a dis-functional and non-functioning board, exacerbates the difficulties we are having as a community. Having a board suggests we should turn to that leadership to resolve community issues yet that leadership is absent. In a community, perhaps the dynamic would be different and we would know we have to turn to each other for resolution. So that is my 'thinking lately'. This is not yet a formal call for no leadership or new leadership but a response to you about my feelings on the subject. Regardless of your perspective on that particular issue, the fact that I am even raising the suggestion ought to prompt each of you into a self-examination of your own position. Probably at this juncture, it would make sense for each of you members of the PMC to justify yourselves to the community: explain why you should still be assumed to have the time and interest to lead both the project and community, explain to what extent you consider yourselves involved, explain why you are still on the PMC rather than playing soccer with some kids in the back yard or playing music with the neighbours. In other words, perhaps you should act as if you were running for election --- it might help revitalize the full PMC. respectfully, --adrian On Mon, 2009-01-19 at 09:51 -0700, Justin Deoliveira wrote: Hi all, I have been thinking lately that perhaps it is time for a PSC update. Currently the PSC members include: * Andrea Aime * Ian Turton * Justin Deoliveira * Jody Garnett * Martin Desruisseaux * Simone Giannecchini People who I think would make great additions to the PSC: * Michael Bedward Michael has been doing a phenomenal job of supporting the users list. * Christian Mueller Christian has been actively contributing to DB2 and JDBC-NG, and active on the mailing list. * Ben Caradoc-Davies Ben has been actively working on complex feature stuff and has been making great strides. * Daniele Romagnoli Daniele has been doing great work on the coverage side of the library. If i missed anyone, my apologies. I encourage others to state their opinions about who they think would make good PSC candidates. And for those I did mention, if you are not interested in serving on the PSC, please just say so. -Justin -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Request to move gt-imageio-ext-gdal to supported land (plugin modules).
actually collaborate on this project given our different approaches? sadly, --adrian custer -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Request to move gt-imageio-ext-gdal to supported land (plugin modules).
On Tue, 2009-01-20 at 15:57 +0100, Simone Giannecchini wrote: So in the end we will resort to split down our code into basically two parts, one LGPL which contains the code compatible with LGPL, the other one, the one that comes from SUN' imageio code which will have a license similar to the IMAGEIO license, Yeah, that's a drag but probably the only legal resolution to that issue. This should address most concerns, since we will be in a similar situation to jai and imageio. Yes, if you have your SUN code as a separate download. Presumably this happens at the same time as you have your users download GDAL so that should not complicate their life greatly. At least if I have understood the outline of what you are doing. See here: http://jira.codehaus.org/browse/GEOT-2289 Ok We had a conditional dependency flag to avoid this code, why is that no longer suitable? Well, I guess that under the supported land there should be no such flags. It was used as long as gdal support was under unsupported. A flag seems like a possible resolution; indeed, I have trouble seeing how we could avoid such a thing. However, since I no longer understand what you are actually doing to the SVN, I'll wait until you tell us what the end result of the last 48 hours were and what you propose going forwards. However I was referring to sentences like this one: The first was a utility class (seems like a good place to start, no?) which contained only static methods but had a chaotic view of inheritance: it's not final but not instantiable and then has some public, some private and some package-protected methods. svn co https://imageio-ext.dev.java.net/svn/imageio-ext/trunk imageioext cd imageioext mvn eclipse:eclipse == load as existing projects into Eclipse == open lowermost project The entire project has one file (!?) called it.geosolutions.imageio.utilities.ImageIOUtilities.java -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Request to move gt-imageio-ext-gdal to supported land (plugin modules).
On Tue, 2009-01-20 at 16:35 +0100, Daniele Romagnoli wrote: On Tue, Jan 20, 2009 at 3:33 PM, Adrian Custer acus...@gmail.com However, we do not distribute JAI or Imageio, we get them directly from Sun, so we do not incur any responsibilities with regards to that code. I have found jai_imageio-1.1.jar and jai_codec-1.1.3.jar in the geotools-2.5.2-bin.zip. Therefore it seems that they are distributed and this could represent the same problem involved in distributing our libs. Sounds like you have found a possible legal issue with GeoTools. I don't have any knowledge of those jars, of their contents, and of why we thought we had the right to distribute them. --adrian -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] License Problems
Hey Christian, We should talk about your project since I am deep in the XACML/SAML P*P world these days, trying to help the OGC figure out what GeoXACML really means to them in the context of OGC web services, and looking at lots of different implementations. Apache 2.0 is incompatible with the GPL v2.0. Indeed, a major motivation of GPLv3.0 was to allow the integration of Apache and GNU code. GPLv3 is compatible with Apache 2.0. Unfortunately, I don't remember any of the details so I don't know how this affects the LGPL v2.0. If this could be a blocker for you, I'm sure the PMC could be persuaded to change the license back to include the , or at your option, any later version clause that would let you keep working. No one particularly cared if I remember right; the choice resulted partly because I had harmonized a bunch of code before I hit a header that used the 'or any later version' language so it was easier to kick it out that to keep it in. So it sounds like it could be a good project of GSOC. --adrian On Tue, 2009-01-20 at 18:40 +0100, Christian Müller wrote: Following the discussion about licensing problems causes me to ask a further question. I am thinking about impelementing the GeoXACML specification for geotools as GSOC 2009 project. http://www.opengeospatial.org/standards/geoxacml This is a geospatial extension for XACML (authorization) and uses SAML (authentification). For both exist OS implementations XACML http://code.google.com/p/enterprise-java-xacml/ SAML: https://spaces.internet2.edu/display/OpenSAML/Home/ Both use the Apache 2.0 License Is this a problem ?. If it is, I can stop thinking over the project. christian -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Request to move gt-imageio-ext-gdal to supported land (plugin modules).
Simone, thanks for the update. On Tue, 2009-01-20 at 20:22 +0100, Simone Giannecchini wrote: the only real problem, the licensing problem seems to be addressed as of now (see my previous email). How did you resolve the 'advertising clause' issue? Are we expecting to change all our docs to include the credit requested by SUN? --adrian -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] OsGEO repository is missing in pom.xml. Can we add it?
Hey, We have not made a decision to use the OsGeo repository but instead we still rely on Refractions and geotools.fr. Can you not simply work against the refractions repo? Adding another repo is not worth doing for a small number of files. It will slow our builds since it adds one more repo for maven to query. If we are going to add a new repo, we probably will want to populate it with a minimal set of recent files and add a section to the pom.xml so we can deploy to it, then we need to document what the login requirements are to deploy to that repo and add a section to the developer guide's how to cut a release step reminding us to deploy there as well. In other words, adding a repo is a bunch of work to do right---do you really want to do all that? --Adrian P.S. I saw your GeoTiff JIRA task go through; it needs work. The bug report is much too vague to be useful: Some geoserver users have problems and JAI has a bug doesn't say much. Also, are your really proposing to make the build depend on imageio-ext by default? If so, what has changed since the last time you proposed that? On Sun, 2009-01-18 at 19:36 +0100, Daniele Romagnoli wrote: Hi list, the main geotools pom.xml doesn't contain the OsGEO repository within the repositories section. (I guess the refraction one will be somehow deprecated) I'm adding some new jars within that repository but they can't be found. Should it be added? Can I add it to the pom or is there a specific reason to avoid it? (Maybe it has simply forgotten) Let me know. Regards, Daniele -- --- Eng. Daniele Romagnoli Software Engineer GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 328 0559267 http://www.geo-solutions.it --- -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Including module documentation in the GeoTools User Guide.
Hey, You would be welcome to add a section to the user guide on the wiki. For commit rights, look at the home page: http://docs.codehaus.org/display/Geotools/Home and for style rules look in the document itself. If it's not there, then try to mirror an existing section. cheers, --adrian On Tue, 2008-12-23 at 12:01 -0800, Sunburned Surveyor wrote: Is there any type of plan or process to include documentation for an unsupported module in the user guide for GeoTools, or is this only done for supported modules? If I could include my documentation for an unsupported module in the user guide, is there any rules regarding format and style? Thanks, The Sunburned Surveyor -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Some Questions on Setting Up an Unsupported Module
Hey, You are either going to have to answer your own questions by looking at what the other modules have done, or give us more to work with. The ID stucture is generally hierarchical, where the group is the name of the parent block and the specific ID is up to you. Generally, open a bunch of pom.xml at the same level and compare and contrast. For the parts of the maven doc, leave as much out as you can and still get your module to compile. Otherwise, look at the maven site at apache for full details about what each block does. --adrian On Tue, 2008-12-23 at 11:58 -0800, Sunburned Surveyor wrote: OK Guys. I downloaded the sample unsupported module from the SVN, and I am attempting to modify it so I can get the GPX2 module to be an actual GeoTools module. I started by editing the POM.xml file. Here are a couple of questions I had about editing that file: - What do I use as my ID? - What do I use as the Group ID for my modules dependencies? What about the Artifact ID for my dependencies? Do the dependencies inherit the project version number, or am I supposed to put the actual version of the dependency here? - Do I need to worry about anything in the plugin section of the POM.xml file? I also had a couple of other questions not related to the POM.xml file: - Do I need to worry about the site.xml file, or is this the same for all of the modules in GeoTools? - I won't modify the APT file until I have had someone do an intellectual property review of my module, correct? Thanks for the help and patience with my questions. The Sunburned Surveyor -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Some Questions on Setting Up an Unsupported Module
On Tue, 2008-12-23 at 13:14 -0800, Sunburned Surveyor wrote: Adrian wrote: For the parts of the maven doc, leave as much out as you can and still get your module to compile. I'm not sure what you mean by maven doc. Do you mean the site.xml file which I asked about? No, I was talking about the pom.xml. Leave out anything you don't strictly need---that seems to be the best policy. The site.xml and the .apt file are a bit of a lost cause within geotools right now since we can't generate the site without much cajoling. I would encourage you not to spend much time on those for now. Maybe over the next year or so, as part of our other work, we will cleanup the build to the point where we can deploy the website nightly---then it will be worth putting more into the web sites. I have downloaded a short tutorial on Maven, but I haven't read it over just yet. I need to decide if learning the ins and outs of Maven is a commitment that I will need to postpone for the time being. right. Postpone it. But if you get stuck, the web site has info. Many of the xml blocks of the pom are run for a specific maven plugin and the web site has info on what each parameter should mean. --adrian -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] OSGeo move ... mailing lists?
Jody Garnett wrote: So we have three votes for moving the mailing list to osgeo hardware. Talking to Paul it seems such a thing is possible/easy ... so here is a formal motion. It covers two things: 1. moving the mailing lists to osgeo hardware 2. changing the names so they are less consistent geotools-devel@lists.sourceforge.net -- geotools-de...@osgeo.org geotools-gt2-us...@lists.sourceforge.net -- geotools-us...@osgeo.org geotools-comm...@lists.sourceforge.net -- geotools-comm...@osgeo.org The other lists like geotools-administration, geotools-il18n, geotools-discussion will be left alone in their non used state. We can take our subscriber list over with us to the new hardware... Jody Hey Jody, Thanks for looking into this. It would be great to move to a listserv with no advertising. Merely wondering, what happens to our history? Does sf really let us get a dump of all our mails? cheers, --adrian -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Style components
Hello, Jody has essentially answered you already but I'll add my take which may flesh out the explanation. The style specification evolved greatly from its earlier incarnation which involved a fairly extensive re-design of the system in place. During that work the author of the new style system decided to follow the lead of another developer who was starting a major cleanup effort of the whole library. So the work has been completed but cannot, in its current form, be committed back to trunk; it has, among other things, been written against Java 1.6 rather than Java5. I believe the author is also waiting for an extensive code review to feel the code is of library quality and ready for release. The cleanup work started for many reasons but three main ones were: obtaining a code base which could be built completely every night, raise the quality of the code to the standard needed for a library, and use the benefits of the Java 6 virtual machine and language constructs. For the former, the current version of geotools cannot be completely built and no one is quite sure why: for example, we need a different compiler to generate the javadocs from that used to generate the code. For the quality issue, this is something everyone is facing since the geotools library has been written over a long time. Other recent efforts have aimed to clean up other parts of the code base such as cleaning the access systems for data hosted in a database and more recently for the file based data access systems. Finally the language issue is one where the official project policy regarding language does not actually reflect the reality of what the project decided or what the contributors want. Our official policy dates from back in the Java 1.4 days---it was intended to express a desire to follow the newer Java platform releases but with enough delay to ensure that institutional clients would have the platform installed or at the very least be able to install it. The official policy we adopted was intended to formalize that balance but, since it relies on a numbering system Sun no longer follows, our policy no longer works. Formally, we are not even allowed to use Java 5 but that change was made by consensus for the Geotools 2.5 release. Since then, there has been no consensus to move on; the real policy is much more focused now on the JEE platform than it was when our formal policy was adopted. Anyhow, the developer launching the cleanup effort decided that since it would take a while to finish, he would start the rewrite on Java 6 and leverage the improvements of that platform. The style work followed and is now stuck in limbo. So the style work will not land for a while yet. The first phase of the cleanup work is almost ready but once that is announced there will be lots of work remaining before the styling code can land. The JAXB question is more complex, raising the existence of the religious war that so tiringly rages in our midst. There are the two factions in Geotools, the eclipse sect and the sun fanatics. Neither can tolerate the technology of the other and both are too lazy to really learn the strengths and limitations of the technology of the other. SLD parsing has been done both ways, with JAXB and by hand parsing. Both work, and both could probably co-exist but religious wars tend not to produce a good environment for co-existence. Finally, on the matching of geoapi and SLD, you may very well be right. I know as part of the work on the new styling, the Geoapi interfaces were modified. That may indeed have aligned them better with the new specification. Geoapi in general is improving over time as we understand it better, as the specifications evolve and improve, and as we need to maintain the project over time. As I understand things, the plan is indeed to move towards the GeoAPI approach. cheers, --adrian Francisco Moura wrote: Srs., I´m working on a project that is being built on top of Geotools. One of our demands is some advanced styles, and so, I´ve been studing the current 2.5.1 version implmentation and reading the upcoming modifications. I saw that you are creating a new MarkFactory and some other great stuff, and I have some questions: - When should this new style version be released? - Is there any issue for not using a library like JAXB for doing the SLD parser and tranformer? - Are you going to make geotools style more like the geoapi style? Because geoapi style seems to be closer to the SLD specification. Thanks in advance, Francisco Moura Tecgraf - PUC-Rio -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at
[Geotools-devel] Java5/6 [was: Style components]
Michael Bedward wrote: Hi Adrian, Please excuse this slight hijack of the topic, but there have been mentions of eventually back-porting the new and beautiful code to work against Java5. Do you have any feelings on how realistic that idea is ? My guess is that it's unlikely to happen for all of the usual, real world reasons. I ask as someone who will probably be working with Java5 for some time yet. cheers Michael Hey, Porting the Geotools foundation, gt-utility, gt-metadata, and gt-referencing back to Java 5 will happen since that is the plan going forward for Geotools referencing. Martin is the only one among us who has wrapped his head fully around the referencing mathematics and the ISO specification so it is much better and easier to maintain a backport of his work than to try to follow his changes on Geotools 2. It actually is probably not going to be that hard since the language changes, while quite useful, are not major. We need to drop the JAXB annotations if they still bother people and tweak some of the calls to new methods like the new System.arrays calls. I know Martin is committed to helping the initial backport which is currently planned as a clone with patches to make it easy to maintain over time. How that backport is integrated into the Java5 code line and how it will be maintained will obviously be up to those working on that code. The styling work is a harder question since it's much higher up the stack and depends on feature. We'll find out what happens when we get closer to it becoming possible. We are going to end up with two lines of code, one for each generation of the language, that much is clear. That may or may not happen within the GeoTools framework, it kind of doesn't matter. It will obviously have to happen partly outside the SVN repository. Both Java and the cleanup effort are using mercurial so that means the most likely thing is the continuation of the SVN augmented by a series of Hg repositories. Architecturally the issue doesn't seem terrifically complex. We are going to have a repo with the base code (util/metadata/referencing) for each language version, and then have repositories working off of those. Whether those repos are a single SVN into which code is imported or a forest of mercurial clones is mostly personal working style preference. Structurally, we have seprate layers: base utilities (e.g. factory finding system) metadata referencing grid coverage (feature less) JTS (isogeometry someday) feature (growing to support formal coverages) data access rendering (w/ styling) and then a slew of packages in various states of support beyond that. So if an architect were to design the two code lines for the two language version, she would probably create, for each language version, a repo for each layer with Maven integrating the whole. That would allow users to depend on only the pieces they wanted. However, what will actually happen is anyone's guess. We may decide to work together to keep the parallelism or to work each on our end. To my mind, it no longer matters since I am no longer shackled to the SVN. I'll work with others as long as it is fun and seems worth it, and work on mercurial or bazaar or git for my own code, pulling in changes as I choose and offering it to all as they may choose. Ultimately, the distributed versionning systems completely change the game. One has to be structured about what work goes where but gains the freedom to run ahead of others and integrate back as needed. Merely as illustration, I can talk about *my* code stack which can be quite independent of anyone else's. I'm trying to use mercurial for everything and using Java 6 exclusively. One of my projects, my work on ISO 19107 compliant geometry, uses a fork of GeoAPI, Martin's geotidy, and then works in its own repo. The fork of GeoAPI allows me to prototype new interfaces for the geometry package without impacting anyone else. My own repo lets me do whatever I please, and maven does the right thing by me. Another of my projects, also on Java 6, extends further up the stack. It starts with a fork of Geotools 2 feature and data store packages which acts essentially as a feature freeze of those classes, integrates our recent revival of Martin's old render and the new styling work, pulls in code from our server, and then adds libraries for the code on which I am working. This stack is not suffciently clean and we are planning to clean up the stack for the begining of next year as we transition it to use Martin's geotidy and writing this mail has given me new ideas for cleaning it up. It's also got an SVN in the middle which makes everything harder. So, going forward, I expect that I will be building a formal set of mercurial repositories for Geotools code on Java 6 with geotidy as
Re: [Geotools-devel] Migration to OSGeo SVN and WebDAV: COMPLETE
Howard, Paul, Thank you both for the move. Seems to work fine after relocate. Howard, The idea that anyone can add a member is terrifying. I gather we will have to live with it since it's a 'feature' but it gives me one more reason to push for Hg. I hope you have good logs so we can recover if anything goes wrong. :-) Also, could you kick yourself out of the GeoTools group, please? Not that you wouldn't be welcome but we are trying to keep the committers strictly limited to those who have signed the agreement document---it's easier to be strict than to clean up any mess which has arose because we were lax. Paul, Any idea what our choices are with regards to our svn.geotools.org domain? My knowledge of DNS is not strong enough to know if we can automatically map svn.geotools.org/$ to svn.osgeo.org/geotools/$ but perhaps you know if it's possible in DNS and if it's feasible at OSGeo. cheers, --adrian On Sat, 2008-12-13 at 21:51 -0800, Paul Ramsey wrote: MIGRATION COMPLETE (at this hour, the webdav repository is still copying, but will be done shortly) See below for Howard's notes on the migration. -- Forwarded message -- From: Howard Butler hobu@gmail.com Date: Sat, Dec 13, 2008 at 8:37 PM Subject: Re: [Geotools-devel] Migration to OSGeo SVN and WebDAV To: Paul Ramsey pram...@cleverelephant.ca Geotools subversion has been migrated. Here is relevant info for you to administer things. svn is currently located at: http://svn.osgeo.org/geotools You will want to do 'svn --switch relocate http://svn.geotools.org/trunk http://svn.osgeo.org/geotools/trunk' to point your local copy to the new repository. This repository is mirrored at using svnsync http://svnmirror.osgeo.org/geotools/ If the osgeo machine were to completely implode you have an offsite backup that is only 15 minutes old. To commit to the repository, you will need an OSGeo id. You can find out how to create one here: http://www.osgeo.org/osgeo_userid After you have your id, you will have actually be added to the GeoTools group to be able to commit. Any committer can add any other committer to a group if they are a member of that group. So, for example, 'jive' (Jody) is a member of the GeoTools group currently, and he can add all of the committers that he needs. Or, he could add Adrian, and Adrian could add everybody. Individual projects can choose how they wish to regulate commit access, but this attribute of our of our group membership will probably not change (it's a feature not a bug!). The group can be modified here: https://www.osgeo.org/cgi-bin/auth/ldap_group.py?group=geotools When Adrian's adding people to the group, he may want to search for people's ids. He can do so at: http://www.osgeo.org/cgi-bin/ldap_web_search.py WebDAV is located at http://download.osgeo.org/webdav/geotools/ . You'll notice that it currently isn't SSL-enabled. Also, Paul mentioned a md5/sha processing script that needs to run that hasn't yet been added yet, but he plans to take care of it. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Migration to OSGeo SVN and WebDAV: COMPLETE
Okay, Deleted you from group, thanks. (I hadn't read the page carefully enough). On Sun, 2008-12-14 at 10:15 -0600, Howard Butler wrote: On Dec 14, 2008, at 9:07 AM, Adrian Custer wrote: The idea that anyone can add a member is terrifying. Anyone *who is already a member* can add a member. If you don't trust your devs, who do you trust? ;) Trust is a complex beast, as we are learning exploring security issues. First of all, trust to write and commit code != trust to manage users. That goes for a single person. As I get tired, I trust myself less and less to do various things. Late, late at night I might even close my root terminal so I can't trivially do stupid things. In distributed projects, I would not want to expect all users to be equally competent and knowledgeable about all parts of the system. Anyhow, I'll shut up now. You've probably heard much of this before and, since, I'm not going to step up to the plate to fix things differently, I'll have to trust your wisdom. :-) Also, could you kick yourself out of the GeoTools group, please? You should be able to delete me without fuss. done Any idea what our choices are with regards to our svn.geotools.org domain? My knowledge of DNS is not strong enough to know if we can automatically map svn.geotools.org/$ to svn.osgeo.org/geotools/$ Yes, I think we can do this, although it is a bit more involved. Additionally, ssl would have to be dealt with if you want ssl. A nice thing about everyone on the same host is many folks only have to accept one SSL cert, remember one password, and remember one URL for a bunch of repositories. A downside of this is if we make geotools' administration too special, it may get lost in the mix if we were to move our services, etc. We (OSGeo SAC committee) chose a single URL for subversion and a single URL for trac (rather than giving each project their own URLs for both) to make extension and addition easier and so we had regularized access to services. These are good reasons to stick with the new svn.osgeo.org. I don't think any of us particularly care about the svn being on the geotools.org domain as long as we have the website. thanks again, --adrian -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Better name for TXT Language
Andrea Aime wrote: Mauricio Pazos ha scritto: Adrian, What do you think about the new options?. Hmm, I must have missed a round. Mauricio, you don't want my opinion on something this trivial. Pick one, do a quick google search on it to see if our users will be able to find our docs if we put them up, commit, close your bug, and have a delicious beverage. If you ask for my opinon, we'll be here 'till 2009. My temptations are all wrong and self-conflicting. My first tempation would be to mix case, e.g. eCQL, extCQL but that probably doesn't match the *QL pattern. My second temptation would be towards EXTCQL to keep the alliteration to the TXT effort that spawned it, but that's getting too long. i.e. We could waste a lot of time asking Adrian for opinion. ECQL works better than CQL+ for searches and urls. all the best, --adrian -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Migration to OSGeo SVN and WebDAV
Paul, you rock! Thanks for organizing the move, coordinating with everyone, and doing the work. It will be nice to have a new home. --adrian -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] OSGeo username for Adrian Custer
Hey Jody, In case you don't have the link handy, the official list of committers is maintained by Tyler here: http://wiki.osgeo.org/wiki/Contributor_Agreements_Received If anyone is left out we might have to get Tyler to run through that mail pile again. For my part, on OSGeo, my username is the usual acuster in the tradition of Berkeley UNIX administrators. thanks, --adrian -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Question for PMC - About include TXT as new feature?
Hey Mauricio, Fantastic work on your language---sounds like a big effort and I'm glad to think it will pay off. 'Tis late in the game to bring this up, and I suspect I may have raised this before, but I got to say this nonetheless. THE NAME SUCKS. That's really too bad since the first impression adds a, totally avoidable, negative take on what looks like great work. TXT means something and absolutely *everyone* knows what it means. TXT is a file format. Using it as the name of a language is like calling a car ball. Probably we could figure out from context what is being said but why add the work to your users/readers/documentors? CQL has the advantage of having a memorable and descriptive acronym: something query language. I am not looking forward to confusion your TXT name will add to the mailing lists, documentation or other layers of the library. So I would encourage you to change the name. You surely can come up with something you like which is both descriptive and un-encumbered, e.g. TXTQL or some such. But please avoid us the cost of having to explain that TXT in geotools is actually the name of a language too. thanks, adrian On Wed, 2008-12-10 at 14:00 +0100, Mauricio Pazos wrote: Hi Jody Could we close this issue for the first release of TXT ? http://jira.codehaus.org/browse/GEOT-1666 The proposal have many +1 but I haven't any feedback from Ian and Martin. http://docs.codehaus.org/display/GEOTOOLS/Extention+of+CQL+to+match+abilities+of+Filter Are 4 votes enough to include TXT as new feature in the next release (maybe 2.6)? Does the PMC agree? cheers -- Mauricio Pazos www.axios.es -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [Geoapi-devel] Summary of GeoAPI meeting at OGC
Hey all, Perhaps to clarify things a little... GeoAPI should not really be affected by this standardization work. The fun work on GeoAPI such as defining new packages in GeoAPI and fixing existing packages to match improved understanding of the specifications can continue as is. GeoAPI will remain the place where all this interesting work and discussion takes place so all the productive communication should remain on the geoapi-devel mailing list. The standardization work is intended to help OGC members and users by bringing the conflicts which we encounter to the attention of the right bodies in the OGC and thereby to ISO. It should also formalize an API through which we believe it should be possible to build any of the OGC Web Services which are being designed at the OGC. To do this, we will be proceeding to formalize each GeoAPI package by declaring it standard. However, this will happen slowly; only once a package both has reached broad consensus in the GeoAPI community and has stopped changing beyond infrequent bug fixes will it be proposed for inclusion. So the only packages being brought into the standards will be the packages no one is talking about anymore---aka the boring stuff. In this initial effort, we consider the utility, metadata, and referencing to be the current boring packages. The work will be worse than boring but even tedious: meticulously documenting how GeoAPI has been defined. The discussions being handled on the OGC mailing lists should be equally boring, discussions such as meeting times or how one correctly writes up an OGC standard and brings it through the bureaucracy to get it passed. Now, don't you want to get involved? :-) --adrian On Thu, 2008-12-04 at 16:59 +0100, Martin Desruisseaux wrote: Hello all The december 2008 OGC Technical Committee Meeting was held in Valencia (Spain). We had a formal GeoAPI meeting Tuesday December 2 from 18h00 to 19h00. 12 peoples were attending. The slides can be viewed there: http://portal.opengeospatial.org/files/?artifact_id=31509 The meeting goal was to start a new official OGC Standard Working Group for GeoAPI. We got enough interrested parties for starting the work (the minimum according OGC rules is 3 different organisations). Peoples from the following organisations have already expressed their interest (in alphabetical order): - Centre National d'études spatiales (CNES, France) - ERDAS - Geomatys (France) - Institut Geographique National (IGN, France) - Laboratoire des Sciences de l’Information et des Systèmes (LSIS, France) Peoples from CSRIO and gvSig wish to consult their hierarchy. The GeoAPI Standard Working Group (SWG) will initially focus their work on the following packages: - org.opengis.util - org.opengis.metadata - org.opengis.parameter - org.opengis.referencing Only the above packages would be OGC standard for the initial release, because they are more stable and tested than other packages. All other packages will probably move to a pending module. The official and the pending modules will each have their own, separated, javadoc and JAR file in order to make clear what is OGC standard and what is work in progress. Right after the above packages are standardized, the GeoAPI SWG will shift its work to geometry, coverage and other modules (in an order to be determined). Participation to the SWG is open to any OGC member. If you wish to participate but are not an OGC member (and do not work for a compagny that could afford to be an OGC member), OSGEO can provide membership for a limited number of individuals. To participate, login to the OGC portal using your account and register yourself to the GeoAPI SWG (to be created on the OGC portal in about two weeks). If you are not an OGC member, don't worry. We got an agreement for keeping the discussion on the public GeoAPI mailing list hosted on SourceForge. The SVN is likely to stay on SourceForge too (an alternative could be to move to OSGEO). Your comments will still welcome as they are today. The initial work of the Standard Working Group would be: - Document the general rules and policies. - Check the interfaces defined in the initial list of packages (see above) and make sure they matches latest standards. - Make sure that any departure from ISO standard are documented and have good justification. - Make sure that any extension (GeoTools-specific interfaces or method) are documented and have good justification. Of course existing interfaces may be debated. I will post a new email when registration will be open on the OGC portal. Martin - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event
[Geotools-devel] DNS hosting has moved!
Hey all, The DNS domain is now under the control of OSGeo and has been renewed for the next few years. The dns records appear to be fully functional. If the code hosting gets changed over to OSGeo machines, that may be the time to change the place where the domain records are defined. When we need to change the DNS records, it will probably be easier to move them all to whatever OSGeo uses for the other records (from some free service). The only domains that I know we use are: geotools.org = codehaus www.geotools.org = codehaus svn.geotools.org = refractions of which only the latter would need to be redefined. Thanks to James for dealing with the hosting this last decade! cheers, --adrian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Sample Supplemental Module Documentation
Hey, DocBook is a decent format but, ultimately, has a non-zero threshold for getting started which eliminates a bunch of contributors. I wrote the gnumeric manual in docbook and it was pretty good once GNOME rewrote the whole help system to handle our manual. In consequence of that experience though, my advice to you is: write your doc in a word processor. You know how to do it, others can figure out how to copy paste your text to where they need it, and it is the most likely strategy to both yield a nice doc and a doc that can also have a future. Export to PDF and HTML is trivial, as is cut and paste. But do whatever works for you. You can wget these svg files: http://baobab.geomatys.fr/files/geotoolsGraphics.svg http://baobab.geomatys.fr/files/GeotoolsBoxLogo.svg which are inkscape .xml files. (Clicking on the links won't do what you want it to.) The former has a colour palette defined if you want to do more tweaks. --adrian On Tue, 2008-11-25 at 12:40 -0800, Sunburned Surveyor wrote: I've attached a sample of some very simple HTML documentation that I am working on for my GPX2 module. I've created a color scheme based on the current GeoTools website. I can make a template based on the sample available for other programmers if they are interested. My supplemental docs basically have three (3) sections: - Introduction/About - Code Examples - Opportunities for Extension/Improvement Is there a way to get a raster or SVG copy of the GeoTools logo that I can include in the template? Please let me know if you have suggestions for improving the HTML documentation. Remember that I wanted something simple, and something that would look decent coming off of a printer. I considered Martin's suggestion about using APT, and I noticed that Maven also supports and XML book format. On the OSGeo education committe mailing list we have talked about writing a simple DocBook to HTML converter. I'm wondering if the same thing wouldn't work for supplemental GeoTools module documentation. We could create a DocBook template and then write a tool that would convert this to the simple HTML format I have whipped up, or to something similar. The nice thing about using DocBook as the foundation is that you can convert it to other formats, and it is more computer digestable than HTML. Just thinking out loud... Landon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GPX Support and Some Latitude/Longitude questions.
Hey, Sunburned Surveyor wrote: Adrian wrote: It would be interesting to hear what you mean by testing your geotools code live from openjump since I've always thought those were very different projects. How does openjump deal with gps data, in plate-carre space? I'm working with TIGER data that is all in lat/long anyways. So I'm not dealing with any map projections. Not at this stage at least. Right now I'm just worried about building features from lat/long coordinates. Later I'll worry about displaying those features with a map projection. It seems like we have a problem of understanding. If you are working with geographic data (lat/long) using JTS (which only works in a Cartesian 2D system, then you have *necessarily* projected your data. If you have not controlled your projection, then you are undoubtedly working in a particular projection, often called Plate Carre (with various spellings). For doing anything analytically useful, that projection sucks. It is neither conformal nor equal area nor does it have any other redeeming characteristics. If you are hooking into geotools anyhow, that's something you might want to think about. Projecting coordinates is pretty trivial and takes your work from the 'random calculation' realm into geographic information systems proper. Adrian wrote: Wow! Your asking this question means either you have not understood what geotools is trying to do or you are distracted and so are not thinking. I think it is the first one. Right now my GPX module is basically stand-along. I want to make future releases of it play better with the rest of GeoTools. So I sort of went backwards. I have reinvented the wheel to get something working, now I want to slowly replace some of my home grown stuff with standard GeoTools components. I know this sounds like a silly way to design something, but I find GeoTools complex. It is easier for me to get a simple working design and then see how I can integrate code from the larger library. Great! Whatever keeps you working is good. The ever diplomatic Martin kept his response open for possible changes, I see. Indeed, if there were a structured block of functionality that was being proposed, he would welcome it. But we are a long way from that in this initial work. Glad that GeodeticCalculator looks useful. That class is a utility class, specific to Geotools, so if you propose new code for that class, those changes are much more likely to fit the design of the library and be welcomed in. Do look around if you are trying to do something new, there's a lot of power in that there library. --adrian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Thanks for your responses on the user list
Hey Michael, Thanks for fielding so many questions on the user mailing list. It something that's important to do and it looks like many of us are kept busy with other work so it's great to have you pitching it. --adrian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GPX Support and Some Latitude/Longitude questions.
On Thu, 2008-11-20 at 07:39 -0800, Sunburned Surveyor wrote: In this particular scenario unprojected lat/long data is exactly what I need. I'm not producing any maps at this stage in the game. I'm just collecting position data using GPS. My data will be available for other people to make their maps. They can take my lat/long data and project it into whatever coordinate system works for them. ... JTS is just serving as a convenient coordinate holder at this point. The Sunburned Surveyor so I'm back to being confused, where does OpenJUMP come into the picture? Are you not really using OpenJUMP either? --adrian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GPX Support and Some Latitude/Longitude questions.
Hey, Congrats on the hard work. It would be interesting to hear what you mean by testing your geotools code live from openjump since I've always thought those were very different projects. How does openjump deal with gps data, in plate-carre space? Sunburned Surveyor wrote: - Right now my code uses doubles to represent lat and long values. I'd like to create a convenient wrapper class to represent a lat/long coordinate (possible with an elevation). I noted that GeoTools has a latitude and longitude classes: http://javadoc.geotools.fr/2.5/org/geotools/measure/Latitude.html http://javadoc.geotools.fr/2.5/org/geotools/measure/Longitude.html Is there a class GeoTools uses to represent a Lat/Long pair? If there isn't, what interface or class might I extend/implement to do so? I don't want to roll my own lat/long wrapper if I don't have to. The geotools way to define a coordinate tuple is through an array of doubles; the way to define a series of tuples is through an array of doubles. This is because of the way we can then operate on those coordinates if we want to transform them---we follow a Java convention of working on a single long array containing all the ordinates. That also gives us access to the very nice System.array* types of functions including their improved versions in Java 6. The OGC/ISO way to reference a single coordinate tuple of geographic ordinates is with a direct position, a tuple plus a defining CRS to give it meaning (i.e. which ordinate is lat and which is long and how that coordinate system relates to the globe). You can find the classes you want in the referencing module's org.geotools.geometry package where you'll want to look at the GeneralDirectPosition, or DirectPosition2D classes. (Note this is *not* a Point, which for ISO is a very different data structure.) For the CRS, you could use the static org.geotools.referencing.crs.WGS84 if you keep in mind that its in long,lat order (it exists to provide a flipped alternative to the ubiquitous EPSG:4326 CRS without asking users to learn how to flip axes with a trivial affine). I'm angling for us to have a few more default CRS's going forward so we can skip the epsg database plugins in these simple cases. For now, you will have to find the EPSG code for the CRS you want to use and pull it out of one of the utility CRS.decode(.) methods. - I want to create some utility methods that work with lat/long coordinates on the ellipsoid. I only need a simple sphere, nothing fancier. Find the epsg code; I bet you can google it. Warning, they may be several with different radii. The epsg website has a lookup tool and geotools has some class that you can use from the command line to do the lookup. (Martin has recently greatly improved this by bringing all his mini-apps together into a single, powerful, sexy, colourized, localized, covered in whipped cream and with a cherry on top command line app. A goody in the pipeline for us.) I'm dealing with positional accuracies of several feet (if not tens of feet), so I'm not going to get exceited about the differences between a shpere and an ellipsoid at this point. I know that GeoTools offers the DefaultEllipsoid class: http://javadoc.geotools.fr/2.5/org/geotools/referencing/datum/DefaultEllipsoid.html Would there be objections to adding some methods to this class to perform the calculations I need, or should I whip up my own implementation of the Ellipsoid interface? Wow! Your asking this question means either you have not understood what geotools is trying to do or you are distracted and so are not thinking. So let's back up a second. Geotools is a *library*. It is not some random accumulation of code built to satisfy the particular need of whomever was writing it. Geotools is a library built along a *design*. The OGC and ISO design has been vetted through the two standards bodies, implemented in lots of different ways and refined over the years. It's not perfect by any means but it is designed systematically to satisfy the broadest range of needs. Furthermore, in the particular case of referencing, the module is one of the best written, best documented, and most stable parts of the project. So there is *no* chance whatsoever you could add any methods to that class---it doesn't make any sense to ask. Happily, you might not even need to add anything. Chances are high that what you want to do already exists you just need to learn how. (Yes, reading code is much harder than writing code; the benefit comes from learning better approaches and from discovering standard ways to do things which often gets repeated elsewhere.) For your needs, there's a geodetic calculator class around to do simple operations in geographic space which may be helpful. There's a lot of other code around as well, so you ought to browse the GeoAPI javadoc first and then poke around Geotools to find the helper classes. If you are still stuck
Re: [Geotools-devel] javadocs for unsupported modules
Michael Bedward wrote: Hi all, Just wondering how often do the online javadocs for unsupported modules (trunk) get refreshed ? I assumed it would be daily but some docs I added yesterday have not made it online yet. cheers Michael Building the javadocs for Geotools 2.x is black magic. You need java 6 and the right incantation so none of the automatic build tools has mastered it. From time to time someone succeeds and they get updated. It's one of the major reasons for Martin wanting to clean things up. --adrian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Domain transfer for geotools.org
Hey James, Looks like we may have taken a step forward. I sent a letter respectfully expressing my disgust to the director of easyspace which seems to have unblocked things. Frank Warmerdam today apparently managed to grab control of the domain for PairNIC but he got a message saying the admin of the domain would get an email with further instructions. Presumably that is you, so if you could do the parts you have to do yourself and pass on the info to us to do the rest, you will finally be free of us. :-) thanks in advance, --adrian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Integrate Edigeo module into geotools project
Hey, Some officer of the company should sign the same document you must have: http://docs.codehaus.org/download/attachments/9765352/GeotoolsAssignmentToOSGeo.pdf?version=1 and send it to the address on the document, --adrian On Wed, 2008-11-12 at 11:38 +0100, Mathieu Coudert wrote: Hi Adrian, Indeed, I did this as part of paid work for my company. Do you have any template or example of this document in order to provide you what OSGEO needs? Thanks, Mathieu On Mon, Nov 10, 2008 at 9:43 AM, Adrian Custer [EMAIL PROTECTED] wrote: Hey Mathieu, Congratulations on the module. Are you doing this for fun or do you have some further end goal in mind? BTW, if you are doing this as part of paid work for your company OSGeo needs a copyright transfer from them as well. --adrian On Fri, 2008-11-07 at 14:59 +0100, Mathieu Coudert wrote: As long as you or your company have sent a signed contributor agreement to OSGEO (which you told me already you did, by private mail) you have my +1 for committing on unsupported Thanks Andrea, I commit it to unsuported module. I will come back to the list next week to see what could be achieve to switch this module into the supported land! Cheers, Mathieu - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Mathieu Coudert [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] community-schemas ported to trunk, renamed app-schema
Hey, Congratulations on the work. Could you explain the rationale for the Applications name? As I understand it (badly), your work aims to build a mechanism for access to data defined through 'multiple', possibly 'distant', schemas. In that context Application at best means nothing at worst is misleading to new users. But perhaps that is wrong; either way, we need a rationale that we pass on to users when they ask questions. cheers, --adrian On Mon, 2008-11-10 at 11:01 +0900, Ben Caradoc-Davies wrote: To better conform to ISO 19101 nomenclature, after discussions with Rob Atkinson and others, I have renamed the GeoTools unsupported module community-schemas to app-schema on trunk. This change resolves the misleading complex/community-schemas naming tangle. Some significant changes: (1) Renamed classes ComplexDataStore* - AppSchemaDataAccess*. (2) Renamed artifact gt-community-schemas-ds - gt-app-schema. (3) Renamed containing module directory community-schemas - app-schema. (4) Changed dbtype connection parameter from complex to app-schema. The module app-schema now compiles and all unit tests pass. No regression tests have been performed as GeoServer integration has not been performed. Consider this software to be pre-alpha. More notes on the port can be found here: https://www.seegrid.csiro.au/twiki/bin/view/Infosrvices/GeoserverPortToTrunk - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [jira] Created: (GEOT-2144) ScriptTest failure on Linux w/ Java 6
Hey Jody, This is apparently known---I ran into it last week. Gt2 does not build with Java 6 (and docs only build with Java6). Yet another reason Martin wanted to clean, and clean and clean. --adrian On Sun, 2008-11-09 at 21:50 -0600, Jody Garnett (JIRA) wrote: ScriptTest failure on Linux w/ Java 6 - Key: GEOT-2144 URL: http://jira.codehaus.org/browse/GEOT-2144 Project: GeoTools Issue Type: Bug Components: core referencing Environment: Maven version: 2.0.9 Java version: 1.6.0_10 OS name: linux version: 2.6.27-7-generic arch: i386 Family: unix Reporter: Jody Garnett Assignee: Martin Desruisseaux Fix For: 2.6-M0 This is my first chance to try building on linux in years; after battling with dependency trouble I am now down to sorting out compile errors. Test set: org.geotools.referencing.ScriptTest --- Tests run: 16, Failures: 0, Errors: 2, Skipped: 2, Time elapsed: 0.842 sec FAILURE! testStereographic(org.geotools.referencing.ScriptTest) Time elapsed: 0.043 sec ERROR! org.opengis.referencing.operation.TransformException: Transformation doesn't produce the expected values. ... testOrthographic(org.geotools.referencing.ScriptTest) Time elapsed: 0.019 sec ERROR! org.geotools.referencing.operation.projection.ProjectionException: The transform result may be 1,943,446.412 mete rs away from the expected position. Are you sure that the input coordinates are inside this map projection area o f validity? The point is located 270°00.0'W away from the central meridian and 40°47.0'S away from the latitude o f origin. The projection is Orthographic. at org.geotools.referencing.operation.projection.MapProjection.checkReciprocal(MapProjection.java:630) at org.geotools.referencing.operation.projection.MapProjection.transform(MapProjection.java:821) at org.geotools.referencing.operation.projection.MapProjection.transform(MapProjection.java:855) at org.geotools.referencing.operation.transform.AbstractMathTransform.transform(AbstractMathTransform.jav a:256) at org.geotools.referencing.Console.test(Console.java:602) at org.geotools.referencing.ScriptRunner.test(ScriptRunner.java:61) Is this one of those cases where Java 5 handles things differently? - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Integrate Edigeo module into geotools project
Hey Mathieu, Congratulations on the module. Are you doing this for fun or do you have some further end goal in mind? BTW, if you are doing this as part of paid work for your company OSGeo needs a copyright transfer from them as well. --adrian On Fri, 2008-11-07 at 14:59 +0100, Mathieu Coudert wrote: As long as you or your company have sent a signed contributor agreement to OSGEO (which you told me already you did, by private mail) you have my +1 for committing on unsupported Thanks Andrea, I commit it to unsuported module. I will come back to the list next week to see what could be achieve to switch this module into the supported land! Cheers, Mathieu - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Transfer of geotools.org DNS domain to OSGeo's PAIRNIC hosting
Hey Frank and Tyler, As we discussed, we have been having trouble with the geotools.org DNS hosting and would like to transfer control of the domain from our founder (who is now inactive in the project) to OSGeo. I've just gotten the magic EPP code so we are ready for PAIRNIC to take over. Do either of you have a strategy for how to proceed? Tyler suggested openning a TRAC ticket which I have done http://trac.osgeo.org/osgeo/ticket/309 so I hope that gets the ball rolling down the right slope. Thanks for any help and tips. On behalf of the geotools community, --adrian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Moving the repository to OSGEO
Hey all, If you want to move the repo, OSGeo is ready to host it. The transfer would require something like: 1. open a TRAC issue and probably notify the OSGeo admin group 2. schedule the transfer with refractions admin and osgeo 3. freeze the repo 4. get a dump and get the list of committers 5. transfer the dump and load it 6. re-enable access from the committers' list although maybe I'm forgetting some step. Is this not the time to move to the more robust system of distributed versionning where we remove the single point of failure? As a totally separate issue, we need to regain control of geotools.org. I was sick yesterday but I'll try to advance on that front today. --adrian On Mon, 2008-11-03 at 18:04 +0100, Andrea Aime wrote: Hi, today during the meeting we were talking about moving the svn repo to OSGEO. The late svn issues have been taking most of us enough to consider the switch. During the meeting we gathered the following positive votes already: * aaime * groldan * jdeolive * simboss It's enough positives to make it a decision, but on such a move consensus is better. Also, we need to plan to avoid downtimes. Ideally, check with OSGEO, decide on a switch date, freeze commits, grab a dump from refractions and have it installed on OSGEO so that we have a short interim without any usable repo. Soo... votes, and details on how you'd like the transition to occur. Fire away. Cheers Andrea - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Correction to PostgisDataStore
Hey Milton,
Your mail is indeed *exactly* what belongs in a bug report (JIRA task).
You never need to ask permission to open bug reports.
good work,
--adrian
On Thu, 2008-10-30 at 19:46 -0200, Milton Jonathan wrote:
Hello there
I exchanged some e-mails a while ago with Jody, about issues with
spatial references when creating a schema on PostgisDataStore. Please see:
http://n2.nabble.com/SRID-problems-when-writing-to-PostGIS-td1093252.html
I guess the conversation kind of died out, but we here did implement
what I see as the solution to the problem. Basically, I exchanged lines
1287-1298 with the following code:
if (ident == null || ident.isEmpty()){
if (refSys == DefaultGeographicCRS.WGS84)
SRID = 4326;
else
SRID = CRS.lookupEpsgCode(refSys, true);
}
else{
String code = ((NamedIdentifier) ident.toArray()[0]).getCode();
SRID = Integer.parseInt(code);
}
If it's OK with you, I can open up a JIRA task and send the patch over
there. I'm just not sure about the best way to implement a test for
that, though, since method createSchema() is quite large and uses tests
shared with DataTestCase, something like that. One thing we could do
would be to separate the task of figuring out the SRID as an independent
private or protected method (say, getSRID), and then use Java
reflection to access that method for testing purposes. Just an idea.
Cheers
Milton
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] GeoTools DNS down
Hey all, Our DNS registration for the 'geotools.org' domain, held by our fearless but possibly lost leader James Macgill, appears to have lapsed. As explained below, we are working on resolving the issue. For practical purposes, these equivalents are true today: www.geotools.org -- docs.codehaus.org/display/Geotools/ svn.geotools.org -- gtsvn.refractions.net so you can map these equivalences in your hosts file (happens before the DNS system is queried), you can do an 'svn switch' for now. The resolution we are working on: 1) OSGeo is willing and able to maintain the domain for us if we can transfer it to them. 2) We have contacted James to see if we can get the control of the registration from him. 3) We have contacted the service provider to see if we can directly transfer the domain from them. If either 2 or 3 occurs, we should be able to do an orderly transition of the domain. Otherwise, we can wait until the domain lapses completely and then register the domain when it becomes available. The latter is dangerous since there are 'bots which automatically squat expired names and may be quicker than we are in grabbing the free domain. So we will see how things pan out. Regardless, it looks like this will take a little while to resolve. --adrian On Tue, 2008-10-28 at 09:20 +0100, Martin Desruisseaux wrote: Michael Bedward a écrit : Is this permanent Simone ? ie. should we do svn switch --relocate ? I have sent an email to James McGill yesterday, who is the owner of the geotools.org domain name. He was the creator of the GeoTools project years ago, but now works at Google Map in Australia. I'm waiting for the answer, but I actually don't know if the email adress I have still valid. You can watch the status of this issue there: http://jira.codehaus.org/browse/GEOT-2108 Martin - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [jira] Created: (GEOT-2055) Porting MAX_ALLOWED_TILES and MOSAIC_LOCATION_ATTRIBUTE Hints from GT-2.5 to GT-2.4
Why are these hints? Both of these seem to be module configuration information not a 'hint' for factories. Have 'hints' really reached this level now? The first seems like a configuration work around for a library that does not yet 'just do the right thing'. The second is an URL right? That doesn't seem to be something that should go through the 'hint' system. --adrian Daniele Romagnoli (JIRA) wrote: Porting MAX_ALLOWED_TILES and MOSAIC_LOCATION_ATTRIBUTE Hints from GT-2.5 to GT-2.4 --- Key: GEOT-2055 URL: http://jira.codehaus.org/browse/GEOT-2055 Project: GeoTools Issue Type: Improvement Components: core metadata Reporter: Daniele Romagnoli Assignee: Daniele Romagnoli Priority: Minor Fix For: 2.4.6 In order to port some code of the imageMosaic plugin from gt-2.5 to gt-2.4 we need to extends the Hints class with the following elements of geotools 2.5: /** * Key to control the maximum allowed number of tiles that we will load. * If this number is exceeded, i.e. we request an area which is too large * instead of getting stuck with opening thousands of files we throw an error. */ public static final Key MAX_ALLOWED_TILES = new Key(Integer.class); /** * Key to control the name of the attribute that contains the location for * the tiles in the mosaic index. */ public static final Key MOSAIC_LOCATION_ATTRIBUTE = new Key(String.class); - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] disappointing news from yesterdays meeting
Hey Jody, No time right now to answer fully. The IRC was to start a discussion and search for a good solution. Nothing in my proposal has any impact on existing code so there is no cause for alarm and no reason for disappointment. --adrian, under the departure gun On Tue, 2008-09-23 at 06:36 +0300, Jody Garnett wrote: Hi Adrian; I found your news in yesterday's meeting to be disappointing. I had let you take over stewardship of the geometry module as you had some work and interest in the area; as such you moved it to an unsupported module (to warn users you may change the api) and now are abandoning the work? This seems a fairly caviller attitude to what is now a couple person years of work; for how many changes in geoapi are you making this trade? I will talk to Graham when I return to Canada and see if this is a good direction for that code base. Since we both work for a consulting company - and take short term direction from clients - we do not always have the direction and planning perspective to see the way ahead. This is in conflict with my roll on the PMC - where we track a course for the library and ensure that time and effort of contributors is respected, this is a requirement for GeoTools to be a safe project to contribute effort into. I trust that each module maintainer feels a similar responsibility; and excitement; in working with others. This places me, personally, in a double bind; I need to respect your volunteer time in looking at (and revising) this work. As such I should do everything in my power to help you. I also need to respect those who originally did this work; and make sure it is not being disregarded without cause. This perhaps is a better conversation to have on the GeoAPI list as I understand the motivation to change is occurring there? Jody - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Long Plugin name Image+Mosaicing+Pyramidal+JDBC+Plugin
On Mon, 2008-09-22 at 12:07 +0200, Christian Müller wrote: Yes, the name is a little bit to long. There are 5 parts 1) Image 2) Mosaicing 3) Pyramidal 4) JDBC 5) Plugin I think 1) and 4) are mandatory. 5) could be omitted Since there are plugins called ImageMoasic and ImagePyramid I wanted to make clear that my plugin is doing both tasks. That is the reason for the long name. Any proposals ? Hey, From what I understand you aren't 'mosaicing' but are only reading tiles which were generated earlier through another mechanism. So you have written a tile reader backed by any of several databases. Perhaps something along the lines of JDBC Tile Reader or some such? congratulations on all the hard work, --adrian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] wiki writing guidelines - udpated
okay, I reverted my changes so all plugins appear again as their own page. I hope that takes care of your concerns because I am out of time on this. I kept the page providing an overview of the different kinds of plugins since it would be something I would want if I were starting up with GeoTools coverages. For now, the page is a stub but perhaps it will grow when we have more documentation time. --adrian On Thu, 2008-09-18 at 00:20 -0700, Jody Garnett wrote: Adrian Custer wrote: Those are my changes done yesterday. I had no idea you had guidelines now for the UserManual. I had them up for a while; mostly when I started to keep my head straight. I updated them this afternoon to reflect what was actually happening. The general idea is the user guide has examples; the javadocs have definitions. The rest is kind of details (details that keep it consistent of course; but details none the less). I separated out the different kinds of plugins into separate pages. Do you really want to mix I/O plugins with processing plugins? That's what you had before---it seemed confusing to me so I tried to clarify the difference. I suppose I do not understand the difference yet; to developers they all appear as new coverages formats do they not? Thinking ... my main motivation is to group plugin documentation as child pages of the module they contribute functionality to; perhaps this could be done with tags? That would allow us to cover the case where when module actually contributes several factories... What do you think? Jody - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] wiki writing guidelines - udpated
On Wed, 2008-09-17 at 14:39 -0700, Jody Garnett wrote: Hi everyone; I have been catching up to all the activity in the user guide this last week - and updated the writing guidelines to match what I was doing... - http://docs.codehaus.org/display/GEOT/6+Documentation As a quick example the 11 JDBC page has the following children: 01 Use of DataSource 02 JDBC DataStore Example DB2 Plugin PostGIS Plugin Those are my changes done yesterday. I had no idea you had guidelines now for the UserManual. I separated out the different kinds of plugins into separate pages. Do you really want to mix I/O plugins with processing plugins? That's what you had before---it seemed confusing to me so I tried to clarify the difference. --adrian The first two pages (with a number prefix) make up the reference documentation for this module; the pages without a number are the plug-ins that add functionality to this module. I can no longer tell (from looking at the 08 Grid Coverage page) what plug-ins are available... as a user I am not sure I care about the difference between any of the implementations so long as they work. Cheers, Jody - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] wiki writing guidelines - udpated
On Thu, 2008-09-18 at 00:20 -0700, Jody Garnett wrote: Adrian Custer wrote: Those are my changes done yesterday. I had no idea you had guidelines now for the UserManual. I had them up for a while; mostly when I started to keep my head straight. I updated them this afternoon to reflect what was actually happening. The general idea is the user guide has examples; the javadocs have definitions. The rest is kind of details (details that keep it consistent of course; but details none the less). I separated out the different kinds of plugins into separate pages. Do you really want to mix I/O plugins with processing plugins? That's what you had before---it seemed confusing to me so I tried to clarify the difference. I suppose I do not understand the difference yet; to developers they all appear as new coverages formats do they not? I don't imagine so but, now you ask, perhaps my understanding was wrong. I can't connect to the wiki now so I'll have to deal with this later. Thinking ... my main motivation is to group plugin documentation as child pages of the module they contribute functionality to; perhaps this could be done with tags? Well, they are all child pages, but you mean immediate children. I understand your design and will think about how to make it work. --adrian That would allow us to cover the case where when module actually contributes several factories... What do you think? Jody - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Need a friendly Encarta user to convert a pushpin file.
Hey all, For a canonical test case, I've been given a file with the 4d flight positions of the first ballon flight to go around the world. Unfortunately, it's in the Encarta 'pushpin' format and I can't find a copy of Encarta anywhere around here. Would someone with Encarta, please grab the file http://baobab.geomatys.fr/files/orbiter3.pvg and try to open it, see what it contains, and see if there's a way to get the coordinates out of the file? I would appreciate the help. thanks in advance, adrian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] First take on GridCoverage documentation
On Sun, 2008-09-14 at 20:38 -0700, Jody Garnett wrote:
Thanks Adrian; I added a {children} macro to that page so people can see
the contents.
Jody
I wondered about that. I took the existing one out because here I get
the list twice, once for the macro and once for the page. Is that
because I'm a power user of some kind?
--adrian
Adrian Custer wrote:
Hey all,
We had hoped to generate this documentation earlier in the summer but
better late than ...
The page http://docs.codehaus.org/display/GEOTDOC/08+Grid+Coverage
and the first few subsections hold our first draft of an explanation of
how the coverage module works at a programmatic level. Probably there is
a lot still to explain---we just realized that we should have a Why is
this so complicated? section---and we hope to have more examples,
possibly demo code of some sort.
Anyhow, if anyone is playing around with some interesting GridCoverage
format and feels like trying to decipher our explanations, feedback,
comments, or edits are welcome.
cheers,
--adrian
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [Geotools-gt2-users] First take on GridCoverage documentation
On Mon, 2008-09-15 at 09:03 +0200, Martin Desruisseaux wrote: Michael Bedward a écrit : Reading the notes about operations from the perspective of a relative beginner, it's not clear to me what the reasons / pros / cons are for invoking an operation via Operations.DEFAULT (as with the resample example on the Use a GridCoverage page) versus using the DefaultProcessor.doOperation method. Operations.DEFAULT is nothing else than a convenience wrapper around the DefaultOperation.doOperation. It provides typesafe method signatures. However it does nothing else than packaging the parameters and delegates to DefaultProcessor.doOperation. I should probably drop the DEFAULT part (I will do that in geotidy). This is a little bit like ReferencingFactoryFinder which is only a set of convenience typesafe methods delegating to FactoryRegistry. Martin Okay, I'll note that we need to clarify that. We also need to clarify that the projection is working backwards from what I would naively expect. If we have vector data, reprojection takes each point in the old CRS and finds the equivalent point in the new CRS. With raster data we do the opposite. For every point in the new CRS grid, we calculate the value at that point in the original CRS. It makes sense when you think about it but for the naive like me it is surprising. --adrian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] First take on GridCoverage documentation
Hey Simone, On a separate subject. We will need eventually to present, in this grid coverage chapter of Jody's user manual, all the work you have been doing. I haven't yet tried to come to grips with all that work and how to present it so I don't yet have a good sense of (1) the different areas you have been working and (2) how to integrate that discussion in the chapter. For (1), I think you have done work on developing operations, some on tiles and pyramids and some on i/o but I don't know of other things. Because I understand little about all this, I have not yet thought seriously about (2), I am only aware that it's TODO. If you have ideas on how to structure and present that work, we should follow them. You can obviously do the work if you want to do so. If not, I'll probably eventually try to do it myself and would try to present things in the way you think about them. So you might want to design the sections of that work, perhaps by adding stub sections to the chapter or by laying out a section with sub-sections for the various themes you have been writing code for. --adrian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] First take on GridCoverage documentation
On Mon, 2008-09-15 at 13:14 +1000, Michael Bedward wrote: This is great - thanks Adrian ! I just had a very quick look and I've already learned something (that I don't have to go down to JAI level to do a crop). Hmm, I'm not sure about that. That crop operation was floating around from earlier docs---it uses some mysterious 'processor' class which comes from somewhere I did not look for. If you find it, look at the code inside and see what it does. Either it goes down to the JAI level to do its work or it should, I suspect. JAI can undoubtedly crop more efficiently than we ever could. I'll read it properly later today and see if there's anything useful that I can contribute to it. I've been working on some raster algorithms recently (raster to vector, edge cell tracing, region buffering...) some of which may be useful demos - though probably after a lot of refactoring of my code :) cheers Michael 2008/9/15 Adrian Custer [EMAIL PROTECTED]: Hey all, We had hoped to generate this documentation earlier in the summer but better late than ... The page http://docs.codehaus.org/display/GEOTDOC/08+Grid+Coverage and the first few subsections hold our first draft of an explanation of how the coverage module works at a programmatic level. Probably there is a lot still to explain---we just realized that we should have a Why is this so complicated? section---and we hope to have more examples, possibly demo code of some sort. Anyhow, if anyone is playing around with some interesting GridCoverage format and feels like trying to decipher our explanations, feedback, comments, or edits are welcome. cheers, --adrian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] First take on GridCoverage documentation
Hey all, We had hoped to generate this documentation earlier in the summer but better late than ... The page http://docs.codehaus.org/display/GEOTDOC/08+Grid+Coverage and the first few subsections hold our first draft of an explanation of how the coverage module works at a programmatic level. Probably there is a lot still to explain---we just realized that we should have a Why is this so complicated? section---and we hope to have more examples, possibly demo code of some sort. Anyhow, if anyone is playing around with some interesting GridCoverage format and feels like trying to decipher our explanations, feedback, comments, or edits are welcome. cheers, --adrian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] going back to -r30106 FAIL? Is our history gone ...
Hey, Right after the svn change over, I asked everyone to do this kind of test so we could smooth out any of these issues. The reason to do it back *then* was to isolate what obstacles were do to the transition from what would happen in the future (ie. today). If we run in to obstacles today, how are we to know what is due to the transition and what is due to corruption since then? But we were lazy... That said, svn co -r 30106 http://svn.geotools.org/trunk works perfectly for me. Of course it does not build because we depend on geoapi snapshots and not releases which seems like an increasingly bad idea from my point of view. But you know that already. Yes, if you lazily try to go back across the refactoring boundary things will likely break---I would expect it to since the moving of the directories was particularly violent for a poor, old versionning system. Why history dies, I do not know. Sept 6th sounds like a date totally different from when the refactoring was done so it sounds like a separate issue. If it is a serious issue, you should try getting a dump of the repo and loading it on a separate svn server to see if the db is corrupted or what else is going on. --adrian On Fri, 2008-09-12 at 09:51 -0700, Jody Garnett wrote: Only thing I can think to do is take the old repository and load it up and then apply to changes made on the new repository... However I expect that these gaps we are encountering are the kind of thing Mr Custer warned us about when he was assembling a smaller repository. Our own sys admin was not able to help us; while they can add users (and have now stopped the website being taken down) their is no deep understanding of svn. Jody Indeed it seems the svn server is having serious troubles. I asked for the history of one class I've been working on lately, it does go back to September 6, then mysteriously ends. This is real bad... Cheers Andrea - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] GridCoverages in Geotools
Hey Andrea, Like everyone else, I'm getting exhausted by this endless discussion. Here's an overview as I best understand things. GRID COVERAGES IN GEOTOOLS -- Geotools, among other things, handles GridCoverages which are, in approximate language, massive matrices of numeric values. There are several separate issues with handling GridCoverages: * Accessing the information from its original source, * Instantiating the objects and all the associated structures, * Using the objects to do useful work. The Design of GridCoverage Objects: --- Skipping the first of these until later, we can discuss the object structure. 'GridCoverages' are build with classes in the 'Coverage' package. Note this package is misnamed, since true coverages are a more abstract notion, unifying vectorial and raster approaches, the nirvana of GIS. ISO 'Coverages' are based on the ISO 'Feature' object structure which is the heart of GeoTools 'main'---here we are still at a lower level. The Coverage package depends on the classes in the base layer of Geotools: Coverage (package) \/ Geotools Base: Referencing/Parameter/Metadata (packages) This class hierarchy was initially created for a separate project and its arrival into GeoTools is what gave rise to 'Geotools-2'. Martin designed all this code with 2 core interests in mind: (1) implementing well defined specifications designed by experts and (2) following the Java design and philosophy. As a consequence of (1), GeoTools coverage was designed for an older spec of the Open Geospatial Consortium (OGC) which has now been updated with a very closely related spec of the International Organization for Standardization (ISO) so there are some pending updates to the package. However, following these specifications guarantees a broad level of generality for the resulting code. The consequence of (2) is that the whole stack is designed, nay optimized, for Java. In particular, the code was designed to integrated deeply with the Java Advanced Imaging (JAI) system. As a consequence of the dependency on lower levels, GridCoverage is designed to work with the projection system in the Referencing package. Since both Referencing and JAI use affine transforms for much of their work, anyone wanting to play with this code effectively better really understand the power and value of matrix transforms---most computer graphics textbooks lay this out. Creating a GridCoverage involves creating lots of related classes which define the geo-referencing and data content aspects of the 'numeric matrix'. Since GridCoverage was built to leverage JAI, we can follow the basic layout of JAI which has: [JAI] ImageReader-- RenderedImage both of which are sub-classed for different file and image formats. The ImageReader classes provide access to the data while the RenderedImage classes allow us to work on the data with, among other fuctions, a way to get an Image out of the structure. The Geotools GridCoverage class is a wrapper around the RenderedImage construct which adds georeferencing and data content information along with extra methods to leverage that richer information. So we have: [Geotools] (missing) --- GridCoverage with the first part, discussed in greater depth below, being some implementation of the GridCoverageReader interface and the second the GridCoverage implementation. Working with GridCoverages: -- Because a GridCoverage wraps a JAI RenderedImage with georeferencing and data content information, once we have created a GridCoverage, we can work on it as if it were a RenderedImage but also we can work on it with georeferencing notions and with notions of the meaning of its data contents. This is possible because of the slew of definitional objects which were required to create the GridCoverage. So, for example, we can both readily run convolution filters on an image (JAI) or can convert images between reference systems (GeoTools). Martin wrote all this code so he could work studying tuna in the Indian ocean based on satellite imagery and oceanographic studies. So the bias in the design was originally towards exploiting GridCoverages for scientific statistical analysis. Actually visualizing the data is really only a side benefit of his leveraging JAI in the core design. Anyhow, the general idea is that once you have a GridCoverage, you have the data structure against which you can do your work. Going from data source to GridCoverage: -- Martin, having produced the metadata, referencing, and coverage packages did not add the last piece which provided a unified approach to reading data. This is simply due to not yet
Re: [Geotools-devel] move to another server
On Mon, 2008-08-25 at 10:25 -0700, Jody Garnett wrote: I have set up a proposal here: - http://docs.codehaus.org/display/GEOTOOLS/Move+to+another+Server We have talked about moving to another server - the above is a proposal to do so. ... The proposal outlines two options: CodeHaus or OSGeo hardware. I have written the proposal for CodeHaus hardware because that is my preference (rational: Single sign on with the wiki and I would rathersee our community work on code that managing svn). OSGeo already does SVN hosting so it would not require much to host the SVN there, merely a request to the admins. --adrian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GeoTools 2.5-RC0 released
Hey Gabriel, 1) I take it you fixed the distribution issues, is that right? 2) The release notes should note that much of the stuff added in the milestones has now been removed from the distribution: e.g. new Swing widgets, geometry as supported module, gpx datastore, jaxb annotations. 3) who is this opengeo that is now contributing to the community? --adrian On Tue, 2008-08-26 at 11:24 -0300, Gabriel Roldán wrote: The GeoTools 2.5-RC0 release candidate is available for download: * http://geotools.codehaus.org/2.5-RC0 The GeoTools 2.5 series is reaching stability. The target 2.5.0 release is centred around making a new Feature model available. The new feature model is based on formal GeoAPI interfaces and will allow the library to evolve into supporting complex data structures. GeoTools 2.5 also targets graduation as an OSGeo (The Open Source Geospatial Foundation) project, and includes usability and performance improvements, preview version for the new Swing Widgets, and online and downloadable User Guide, an ISO 19107 Geometry implementation available as a supported module, new GPX DataStore, a much more robust ArcSDE DataStore, and JAXB Bindings for xml marshaling of GeoAPI ISO-19115 metadata structures. This first release candidate of the series brings bug fixes related to raster coverage rendering, data access, ArcSDE, some improvements on the project build process, and the finalization of the switch to the new GeoAPI Feature Model (though remember 2.5 still focuses on Simple Features only). Thanks to everyone who provided feedback on our new Feature model. This release contains several usability improvements based on your feedback; thanks also go out to Andrea and Justin who spent some time making the switch to the GeoAPI Feature Model passing GeoServer CITE tests, and to Jody for improving our build system. Not to forget, a big thanks to Geomatys, GeoSolutions, Refractions Research, OpenGeo and the community for continuously leveraging the project and making it such a success every day! Features from 2.5-RC0: * Feature Model switch to GeoAPI completed with passing CITE tests from GeoServer as sanity check * Some major bug fixes related to raster coverage rendering, ArcSDE, and Filter to SQL simplification * Build system improvements Features from 2.5-M3: * OSGeo gradudation! All the headers have changed and we now track license use on a module by module basis * Usability and Performance improvements to the Feature * FeatureCollection no longer implements SimpleFeature or Collection; removal associated implementation classes such as ResourceCollection Features from 2.5-M2: * JAXB bindings for the metadata module (ie support for ISO 19139 documents) * FeatureAccess super class for DataStore, allowing data access using ISO Features from 2.5-M1: * Change over to GeoAPI SimpleFeature * Support GetGMLObject * Preview of new Swing Widgets (and a warm welcome to Eclesia) Features from 2.5-M0: * Online User Guide * Java 5 * Improved CRSAuthorityFactory implementations available for Java Enterprise Edition users * ISO 19107 Geometry implementation available as a supported module * DB2 returns to supported status * ArcSDE returns to supported status * GeometryBuilder utility class * A new GPX DataStore Release Notes: * http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14490styleName=HtmlprojectId=10270 For more information please visit: * http://docs.codehaus.org/display/GEOTDOC * http://docs.codehaus.org/display/GEOTOOLS/2.5.x * http://docs.codehaus.org/display/GEOTOOLS/Upgrade+to+2.5 * http://docs.codehaus.org/display/GEOTOOLS If you are new to GeoTools please consider this release as a good starting point, although the 2.4.x remains the stable branch we have no planned API changes and user documentation available for the 2.5.x series. Enjoy, The GeoTools Community - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/
Re: [Geotools-devel] GeoTools 2.5-RC0 released
On Tue, 2008-08-26 at 07:46 -0700, Jody Garnett wrote: Adrian Custer wrote: Hey Gabriel, 1) I take it you fixed the distribution issues, is that right? I am not sure we did; the assembly continues to pick up everything as I understand it. Well then what happens for (2) depends on what you do for (1) 2) The release notes should note that much of the stuff added in the milestones has now been removed from the distribution: e.g. new Swing widgets, geometry as supported module, gpx datastore, jaxb annotations. Should we remove the jaxb proposal as well? Sure. Martin has given up any hope of integrating this work with the geotools community and is doing it locally on mercurial. 3) who is this opengeo that is now contributing to the community? http://opengeo.org/ The geospatial division of The Open Planning Project. Aha, new company, same company. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Taking imageio-ext back out of build
Hey Andrea, I happened to notice you added imageio-ext to the build. It's cool that we can build without GDAL but unfortunately, for the reasons explained below, I have reverted that change on trunk at revision 31151. I expect that you will have to do the same on the 2.5 branch prior to release but, since that is critical for your work, I'll leave you to do the change when it works for you. As I understood things, the imageio-ext was isolated to a build profile for as long as it would take for the imageio-ext project to mature. Then we planned to have a formal review of that dependency like all the others and after that include it formally in Geotools. Unfortunately, this work is not yet done. Critically, a quick perusal of all the code files in imageio-ext shows that it's illegal for us to use. Legally we don't have the right even to read certain files (PROPRIETARY/CONFIDENTIAL) and there's at least one other issue I saw that makes it impossible for us to simply include in our build. That stuff will have to be cleared up in a convincing way. Hopefully, imageio-ext will undergo a formal review of its own, clean up what needs cleaning, and make an initial release when it's ready. After that, Geotools will be able to consider the formal dependency. For now we are stuck adding a -Pgdal flag to the build. --adrian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] supported / unsupported modules and the handling of dependencies
On Thu, 2008-08-07 at 19:23 +0200, Simone Giannecchini wrote: Hi all, As I mentioned in some previous emails, our goal for the imageio-ext project is mitigate as much as possible the risk of introducing a dependency which relies on a native library, even though such native library is well known as GDAL is. Having this objective in mind as well as the fact that imageio-ext is an open source project as well whose code is available on a public svn we have been , we are and we have always been open to suggestions/advice/RFEs, in a word collaboration. Therefore, in light of collaboration, if you have specific issues to report, like the one that you correctly reported (and that we already fixed) we are happy to take care of them, if, of course, you can share them with us. Moreover, if you have specific doubts/suggestions/criticism on the library, it would be great if you could detail them them a bit on the imageio-ml as I suggested already in the past, because otherwise it would be just us wasting our time trying to guess/understand what the reported problem could be. Ciao, Simone. Yes, I can imagine it would be nice for me to formalize all this for you, to take the time to do a full review of your work, to document in detail all the issues legal and otherwise with your library. The elegant thing would be for me to do that and file a useful bug report against your project. I'm not inclined to do that work for you because I have other priorities. Because it seemed Geotools was going to formally depend on your project, I took a quick look at it. I did notice that your code has been copied from lots of different sources. A few files make it illegal for me to download your project. Others appear at first analysis to conflict with the LGPL license you claim for your project so make it illegal for me to distribute a copy of the jars I compile on my local machine under the terms stated for Geotools. You may or may not want to address the issues I think I stumbled on---that's of course up to you. If you want to take the time someday, you might want to start by opening all your files, reading their headers and ensure (1) they are all legal to distribute (2) they all match the license of your project. You might also want to accumulate a list for your users of all the places from which you have taken code even if it's all shared under exactly the same license. A formal review would be more involved than those quick first steps. So maybe that interests you and maybe not, that's all up to you. either way good luck, adrian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] supported / unsupported modules and the handling of dependencies
On Thu, 2008-08-07 at 19:30 +0200, Andrea Aime wrote: Jody Garnett ha scritto: Adrian Custer wrote: I've already lost time on this, on top of a bunch of other things so I don't have time to chase down the problems and fix them. You lost me? The problems seem to be in the imageio-ext project right - I am mostly focused on the geotools unsupported plugin here. I was under the impression that we were getting formal when code moved to a supported module; and we were going to try and not make the unsupported modules available for download (or at least in a separate jar). yes, that seems reasonable and was my understanding as well. Suppose I better go visit the 2.5.x branch and make sure that happens. So, if my understanding is right, being that module still unsupported, it can be included in the build, right? Can I switch it back to be included in the build? Any other concern remaining? If memory serves, the last time we had this discussion we agreed to wait for a first release of the imageio-ext project before considering it as a formal dependency. Whenever we do decide to consider it, we will probably want to discuss the benefits and costs of becoming formally dependent on that project and its long-term impact on Geotools---that's what we usually do. Our discussions around dependencies tend to be rich with voices for keeping the library light and others for increasing capabilities. So we will undoubtedly need to go through such a discussion. This library is particular: it appears light on the download since it is mostly stubs but is also useless without a native dependency which breaks the Java intent of Geotools. I imagine the discussion will be lively. However, today we cannot legally include the project in our build. There were files with confidential/proprietary code in the library which may or may not have all been removed and other files which conflict with the LGPL. That is all merely from the documentation within the files themselves. It appears, next time the project is proposed, we will have to do another cursory review of the licensing situation and code origin to ensure we have done due diligence towards our users and to prevent trivially obvious licensing conflicts. This is not a project issued from a group like Apache or the FSF which is well known to take particular care with their code origins so I would not expect anyone to be satisfied with merely accepting some unknown group's word for things. --adrian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] supported / unsupported modules and the handling of dependencies
On Thu, 2008-08-07 at 22:05 +0200, Andrea Aime wrote: You told us about the header and we removed the file, what else do you remember? One last time: certain files have licenses which appear to be incompatible with the LGPL. --adrian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Revision 30258 broken?
Hey all, Yes the revision probably does 'break' the rules of SVN so that tools trying to follow the changes cannot cross that changeset. The repo afterwards is in a legal state but the transition through that change probably does not follow regular svn change rules. For bzr and hg we are forced to follow trunk after that revision rather than being able to convert the whole history of the geotools/udig repo. That's actually for the best since that older history is of less interest to us these days and is quite heavy. If your tools work against mercurial you could clone the repo at http://hg.geomatys.fr/geotools/trunk and then regularly update it with hg convert http://svn.geotools.org/trunk repoName and run your tools against that. --Adrian On Tue, 2008-07-22 at 15:34 -0400, Arne Kepp wrote: I don't see any CPU activity for Crucible, so I think it's just a TCP network timeout. I'm happy that the repository is sane, I don't advocate any further action. -Arne Chris Hodgson wrote: I wonder if the sheer number of changes (or the mixture of many different types of changes) all in one revision is just too much for these analysis tools to handle? Chris Jody Garnett wrote: I think this is when acuster split the repository into two; perhaps he can shed more light on the issue? Jody Arne Kepp wrote: Hi, In that case it's probably just timing out, you can try svn diff -r30258 http://svn.geotools.org The log suggests it's a big one: r30258 | acuster | 2008-05-08 11:02:00 -0400 (Thu, 08 May 2008) | 1 line Reshuffle the top level repo: drop uDig, move up trunk, tags, and branches. If the consistency of the repo is okay then it's not a big deal, just means we probably can't run Crucible / Fisheye against it. Thanks for checking, -Arne - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1896) User Guide must include all licenses used in all modules
User Guide must include all licenses used in all modules Key: GEOT-1896 URL: http://jira.codehaus.org/browse/GEOT-1896 Project: GeoTools Issue Type: Task Components: doc, license Reporter: Adrian Custer Assignee: Rueben Schulz While the bulk of GeoTools is LGPL, several modules have mixed licenses. All these licenses must be listed in the User Guide and the correct licenses added to the correct modules during assembly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1897) Spike zzorn has data of unknown origin
Spike zzorn has data of unknown origin -- Key: GEOT-1897 URL: http://jira.codehaus.org/browse/GEOT-1897 Project: GeoTools Issue Type: Bug Components: license, new modules Reporter: Adrian Custer The 3D renderer in spike/zzorn has data of unknown origin. Should be clarified or dropped. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1899) unsup/jts-wrapper has mixed headers
unsup/jts-wrapper has mixed headers --- Key: GEOT-1899 URL: http://jira.codehaus.org/browse/GEOT-1899 Project: GeoTools Issue Type: Sub-task Reporter: Adrian Custer The headers in several files of the JTS-wrapper module give copyright to the OGC rather than OSGeo. This needs to be clarified/fixed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1900) unsup/vpf has test classes with own copyright, test data of unkown origin
unsup/vpf has test classes with own copyright, test data of unkown origin - Key: GEOT-1900 URL: http://jira.codehaus.org/browse/GEOT-1900 Project: GeoTools Issue Type: Sub-task Reporter: Adrian Custer The VPF module has test data generated from some online system, therefore with own copyright The origins of the vpf data are unknown -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1901) unsup/caching has mixed copyright headers
unsup/caching has mixed copyright headers - Key: GEOT-1901 URL: http://jira.codehaus.org/browse/GEOT-1901 Project: GeoTools Issue Type: Sub-task Reporter: Adrian Custer The module needs cleanup of the headers, review.apt has info, possibly enough to decide how to clean things. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1902) unsup/community-schemas has data of unknown origin
unsup/community-schemas has data of unknown origin -- Key: GEOT-1902 URL: http://jira.codehaus.org/browse/GEOT-1902 Project: GeoTools Issue Type: Sub-task Components: license, new modules Reporter: Adrian Custer The data files in community-schemas need to be documented as to origin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1903) unsup/hsql has issue with sql driver
unsup/hsql has issue with sql driver Key: GEOT-1903 URL: http://jira.codehaus.org/browse/GEOT-1903 Project: GeoTools Issue Type: Sub-task Components: data-hsql, license Reporter: Adrian Custer review.apt has an open question about the driver -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1904) unsup/mappane has icons of unknown origin
unsup/mappane has icons of unknown origin - Key: GEOT-1904 URL: http://jira.codehaus.org/browse/GEOT-1904 Project: GeoTools Issue Type: Sub-task Components: ext mappane, license Reporter: Adrian Custer The icons in the mappane module are of unkown origin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1905) unsup/oracle-spatial needs to clarify testData.sql
unsup/oracle-spatial needs to clarify testData.sql -- Key: GEOT-1905 URL: http://jira.codehaus.org/browse/GEOT-1905 Project: GeoTools Issue Type: Sub-task Components: data oraclespatial, license Reporter: Adrian Custer Assignee: Andrea Aime The module has one file that needs clarificiation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1906) unsup/imageio-ext-gdal needs review of data origin
unsup/imageio-ext-gdal needs review of data origin -- Key: GEOT-1906 URL: http://jira.codehaus.org/browse/GEOT-1906 Project: GeoTools Issue Type: Sub-task Components: gc imageio, gcimageio-streams, license Reporter: Adrian Custer The data for this module need to be clarified -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1907) All, need to review the LICENSE* files in all modules
All, need to review the LICENSE* files in all modules - Key: GEOT-1907 URL: http://jira.codehaus.org/browse/GEOT-1907 Project: GeoTools Issue Type: Sub-task Components: admin, license Reporter: Adrian Custer Assignee: Jody Garnett Many modules have LICENSE.txt or similar files in them. We need a consistent story for these. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1908) plugin/geotiff has test data of unknown origin
plugin/geotiff has test data of unknown origin -- Key: GEOT-1908 URL: http://jira.codehaus.org/browse/GEOT-1908 Project: GeoTools Issue Type: Sub-task Reporter: Adrian Custer The test data in this module needs review -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] xsd module is holding us back
On Tue, 2008-07-08 at 02:49 -0700, Jody Garnett wrote: This is a similar game to the ogc module; only this time I think we only have a code generator to worry about? Acuster can we run the magic header updating script on these generated results? Just to get us out the door? As far as I know this is all origional work in here. Jody If they are generated, can't we simply fix the generator and recompile? --adrian - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1909) unsup/ogc needs a full copyright and licensing review
unsup/ogc needs a full copyright and licensing review - Key: GEOT-1909 URL: http://jira.codehaus.org/browse/GEOT-1909 Project: GeoTools Issue Type: Sub-task Components: license, new modules Reporter: Adrian Custer This module should have been reviewed but Justin did not do it in time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1910) extension/xsd modules need a full copyright and licensing review
extension/xsd modules need a full copyright and licensing review Key: GEOT-1910 URL: http://jira.codehaus.org/browse/GEOT-1910 Project: GeoTools Issue Type: Sub-task Reporter: Adrian Custer These modules should have been reviewed but Justin did not do it in time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1911) unsup/h2 needs a full copyright and licensing review
unsup/h2 needs a full copyright and licensing review Key: GEOT-1911 URL: http://jira.codehaus.org/browse/GEOT-1911 Project: GeoTools Issue Type: Sub-task Components: data h2, license Reporter: Adrian Custer The module has no review.apt and no info on its status. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1912) unsup/imagemosaic-jdbc needs a full copyright and licensing review
unsup/imagemosaic-jdbc needs a full copyright and licensing review -- Key: GEOT-1912 URL: http://jira.codehaus.org/browse/GEOT-1912 Project: GeoTools Issue Type: Sub-task Reporter: Adrian Custer No review.apt file in the module which is needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1913) unsup/notifying-collections needs full copyright and licensing review
unsup/notifying-collections needs full copyright and licensing review - Key: GEOT-1913 URL: http://jira.codehaus.org/browse/GEOT-1913 Project: GeoTools Issue Type: Sub-task Reporter: Adrian Custer The module needs review. Jody seemed to think Bryce might have ideas about it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1914) unsup/process needs a full licensing and copyright review
unsup/process needs a full licensing and copyright review - Key: GEOT-1914 URL: http://jira.codehaus.org/browse/GEOT-1914 Project: GeoTools Issue Type: Sub-task Reporter: Adrian Custer The module needs a review.apt. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1915) unsup/sql-datastore needs a full copyright and licensing review
unsup/sql-datastore needs a full copyright and licensing review --- Key: GEOT-1915 URL: http://jira.codehaus.org/browse/GEOT-1915 Project: GeoTools Issue Type: Sub-task Components: license, new modules Reporter: Adrian Custer Module has no review.apt, should have one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Some explanations on the current feature performance work
Hey Rob, This sounds like an interesting observation. What do you mean by normalized data management? I would be interested to have a bit more of your vision to see where it meshes into my (GIS) world view. --adrian On Fri, 2008-07-04 at 11:53 +1000, Rob Atkinson wrote: Performance is important, but as IT history shows, its not the fastest software or hardware that wins the race, it the one that best meets people's needs and capacity to use it, and usually this is perception based - will I get sacked or promoted for using it? GIS paradigms are fundamentally flawed from a data management perspective, and every organisation I come across is trying to unravel the mess created by clone the geometry and hack approach to data management. If we provide some help there (by allowing more normalised data management) there will IMHO be less need to stream large numbers of features for the usual purpose of eyeballing the to try to understand the data management failures of the past. So, getting back to where we were, but enabling improvements to allow the data to be meaningful so I might not have to ask for the whole lot every time, is in fact a huge step forward, and to be heartily congratulated! Rob A On Fri, Jul 4, 2008 at 5:13 AM, Jody Garnett [EMAIL PROTECTED] wrote: Andrea Aime wrote: Jody Garnett ha scritto: Thanks Andrea; that email is actually worth a blog post :-) For two reasons; it is very informative; and it can start to get people excited about 2.5 :-) Is trying hard to get back to an already established performance level worth a blog post? I'd blog about new achievements, getting back what we already had (by doing less) is the bare minimum to avoid apologizing and be ashamed imho ;) Well the story is interesting; it shows we care about performance; and it talks about the new feature model. Seems good to me. Also talks about the ability to work with unvalidated data which is a new thing. Jody - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Some explanations on the current feature performance work
Aha! As I thought, your rant is a mixture of a good vision of the issue, an interesting intent to improve things, and an unrealistic dream that we could replace the existing by the improved. You apparently have encountered the issue of reams of duplicated data much more deeply than I ever have so I look forward to your expounding on several archetypal examples of the hacks we have done so far to work around non-networked data, proprietary info, and other impediments to the open flow of information. Properly understanding those examples should help us better qualify any improvements we could offer. The distribution of reliable, incremental updates as killer-app extends some of my vague notions for the future. It is actually one of my prime motivations for switching my source code management system to the new generation of revision control systems: they do exactly that, the distribution of reliable (checksum hashes everywhere), incremental updates. Of course, source code can be handled more simply than GIS data: each atom of comparison in a source code system is either a single line of text or occasionally a binary blob. GIS data will probably have different atoms for different elements types up to the feature level, each of which will properly be an arboresence. The XML crowd is surely starting to think along these same lines so perhaps they can inspire this sort of work. So I'll look forward to engaging in that discussion as well. As far as stopping the mess we are in, I suspect the more interesting and realistic issue will be how to incrementally move people towards a better system. People will always need to copy info locally and have their own work branches for their own work. If I head off to the western escarpment of Ethiopia, I'd want all the data I'm going to need with me. So I'd copy the data, modify things locally and get work done. Perhaps the key issue will be simplifying the merging of my changes from diverse sources into a common system, e.g. we all wanted to describe a forest around here here are the various accumulated descriptions, can we get a consensus, a range of differences, or an evolution of the consensus in time? Anyhow, speculation for the future. thanks, --adrian On Mon, 2008-07-07 at 23:01 +1000, Rob Atkinson wrote: I have a plan to put some papers together over the next few months, but in a nutshell, GIS systems mess things up by attaching identity to geometries (the surrogates for real world features) then forcing (or not stopping) you having many copies of these geometries as derived datasets, e.g. to provide a choropleth map showing a bunch of polygons shaded a particular way, or generalising data to make it more efficient to display at a certain scale or a dozen other reasons. Suddenly we have many (usually undocumented) versions of the same real world feature, and sooner or later changes resulting in confusion over its identity. This all comes from treating the set of attributed geometries in a flat table as a dataset as a monolithic thing, rather than a set of features, linked to representations, and other more stable business objects (a normalised form), like you would find in any well designed business database. so, you end up with the need to (literally) fly people into a disaster zone data centre to deduplicate and interpret simple data like location of placenames, because of hundreds of practical simplifications in database structure creating massive complications in data management and re-use. A week of people going hungry because of systemic poor data management. Or agencies not being able to reliably propagate changes through hundreds of derived datasets, and actually stopping collecting new data because they cant use it properly. (I know of cases where land use survey mapping over 80 years old is still in use in agencies in Australia as the best available baseline, with hundreds of copies of 1935 vintage surveyed geometries in derived datasets) I have just observed (and personally felt) the need to start off by getting all the data to look at it closely to understand how badly it was managed. The goal of an SOA/SDI approach (IMHO) is to remove (or reduce) that need, not just to do obviously dumb things faster. I believe the killer-app for web services is distribution of releiable incremental updates to local caches, not inefficient bulk transfer and massage every use. It seems logical on many fronts, but I recognise the scale of the paradigm shift it will require to make people responsible for creating and using more stable feature identifiers. Good tools is a necessary start, and the easiest part of the problem to fix (but obviosuly not trivial!). rant over, for now :-) Rob On Mon, Jul 7, 2008 at 10:25 PM, Adrian Custer [EMAIL PROTECTED] wrote: Hey Rob, This sounds like an interesting observation. What do you mean by normalized data management? I
Re: [Geotools-devel] Do we have a wiki page for GeoTools 3?
Wohoo! Martin hath seen the light and been converted to the Distributed versionning control system meme. Welcome to the sect. ...only a few more m(|bi?)illion brains to go... --adrian - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1875) library/metadata confirm (C) transfer from Saul Farber
library/metadata confirm (C) transfer from Saul Farber -- Key: GEOT-1875 URL: http://jira.codehaus.org/browse/GEOT-1875 Project: GeoTools Issue Type: Sub-task Reporter: Adrian Custer Classes in the org.geotools.logging were shared copyright of Saul Farber, we need to confirm he is willing to transfer (c) to OSGeo. Martin says he has re-written the classes from scratch since then but kept Saul's copyright for the initial inspiration to match the logging levels between logging and log4j. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1876) library/render has test-data of unknown origin
library/render has test-data of unknown origin -- Key: GEOT-1876 URL: http://jira.codehaus.org/browse/GEOT-1876 Project: GeoTools Issue Type: Sub-task Components: license Reporter: Adrian Custer library/render has files in render/src/test/resources/org/geotools/referencing/piecewise/test-data: render/src/test/resources/org/geotools/renderer/lite/test-data: render/src/test/resources/org/geotools/renderer/lite/gridcoverage2d/test-data: that need to be vetted or tossed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1877) library/xml Origin of xml and xsd files needs to be established
library/xml Origin of xml and xsd files needs to be established Key: GEOT-1877 URL: http://jira.codehaus.org/browse/GEOT-1877 Project: GeoTools Issue Type: Sub-task Reporter: Adrian Custer The module has a bunch of xml and xsd files which come from somewhere; they need documenting. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1878) plugin/arcsde test-data needs to be documented.
plugin/arcsde test-data needs to be documented. Key: GEOT-1878 URL: http://jira.codehaus.org/browse/GEOT-1878 Project: GeoTools Issue Type: Sub-task Components: data arcsde, license Reporter: Adrian Custer Assignee: Gabriel Roldán The origin and license terms for the test-data in arcsde/datastore/src/test/resources/test-data/ need to be documented. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-1879) plugin/db2 Code encumbered by IBM license
plugin/db2 Code encumbered by IBM license -- Key: GEOT-1879 URL: http://jira.codehaus.org/browse/GEOT-1879 Project: GeoTools Issue Type: Sub-task Components: data db2, license Reporter: Adrian Custer The code origin for the plugin/db2 code has a (C) IBM which needs to be resolved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
