GeoTools, the Java GIS toolkit

In a question about open source licenses, I got the following response back=
=20
from our Open Source Program Director:

The Apache license is much more business-friendly than the LGPL, especially=
=20
when considering usage in IBM products.
While we have folks who contribute to a number of Linux related projects=20
under GPL and LGPL, most of the open source we consume in SWG products are=
=20
under the Apache, Eclipse, BSD, and CPL licenses.

I'm also looking into the copyright and code origin issues.

I don't seem able to post to the geotools-devel list and when I went to=20
http://www.geotools.org/, I ended up at  http://www.codehaus.org/ instead.

Regards,
David

At 11:17 AM 5/24/2006, Jody Garnett wrote:
>David Adler wrote:
>>Please note that I am not speaking in any official capacity on behalf of=
 IBM.
>No fear David we understand. Indeed we are more interested in making you=20
>happy, you contribute to our project and if this matters to you it matters=
=20
>to us.
>>IBM, and I expect most commercial software providers, is very concerned=20
>>about putting its IP portfolio at risk which is a possibility when=20
>>externally-developed software is mingled with internally-developed=20
>>software.  The various open source licenses have different comfort=20
>>levels.  I will need to check other concerns about copyright and code=20
>>originality.
>Understood, from my standpoint please understand that I am taking steps to=
=20
>address these kind of issues, and it is one of the reasons for my=20
>participation in the geotools OSGEO incubation process.
>>I have a number of project ideas where GeoTools and possibly GeoServer=20
>>would be useful but don't have management commitment to an official=20
>>plan.  As the open source approval process is fairly resource intensive,=
=20
>>I haven't pursued this yet, other than the contribution of the DB2=20
>>support for GeoTools a year ago.
>David any information you could provide me would be timely, the OSGEO=20
>incubation process is supposed to address these kind of concerns. While=20
>the information would be initially
>useful to OSGEO the geotools codebase would benefit.
>>It would be interesting to know if other commercial software companies=20
>>are or are considering using GeoTools and GeoServer.
>I have had plenty of under the table inquires, and Refractions is happy to=
=20
>provide support contracts to anyone reading along at home that
>does not want to be seen on the public email lists yet :-)
>
>Cheers,
>Jody
>>
>>FWIW - "For what its worth"
>>
>>David
>>At 09:21 AM 5/24/2006, Jody Garnett wrote:
>>>David Adler wrote:
>>>>I would like to consider GeoTools and GeoServer for some IBM offerings=
=20
>>>>but it is very difficult to get approval for anything other than the=20
>>>>Apache license.
>>>David this is good information to know, I got a proposal for you.  I am=
=20
>>>trying to complete a geotools IP check (anyone can help - please!) and am=
 then
>>>moving in the direction of assigning copyright to OSGEO as part of the=20
>>>incubation process. The reasons boil down to the GeoTools PMC is not=
 really
>>>set up to handle such things and a desire to attract involvement from=20
>>>organizations such as IBM.
>>>
>>>If this really is an issue for you can we revisit the license issue in a=
=20
>>>more formal capacity. I would wait until the IP review is completed, and=
=20
>>>the current
>>>RnD efforts have died down (everyone is having so much fun right now -=20
>>>lets wait for a release).
>>>
>>>If anyone else has sad tales of not being able to invest time and energy=
=20
>>>into GeoTools for a non technical reason please attend a meeting and=
 speak up,
>>>the GeoTools library is here to work with you, the PMC only facilitate.
>>>
>>>Cheers,
>>>Jody
>>>>FWIW.
>>>Pardon?
>>>>
>>>>David
>>>>
>>>>At 09:21 AM 5/24/2006, Gabriel Rold=E1n wrote:
>>>>>Hi all,
>>>>>I was just reading the part of the meeting I lost yesterday, and want=
=20
>>>>>to make
>>>>>a simple comment:
>>>>><quote>
>>>>>         cholmes Yeah, it's mostly a question of how much people who=20
>>>>> build on it have
>>>>>to give back.
>>>>>         jdeolive        yeah, that is why i like making WFS and WMS=20
>>>>> modules GPL
>>>>>         jdeolive        and just make the interfaces that are part of=
=20
>>>>> the framework LGPL
>>>>>         cholmes One other route we could consider going is dual=20
>>>>> licensing - GPL, and
>>>>>perhaps LGPL, Apache, or even a commercial license option to those who
>>>>>contribute back.
>>>>>         cholmes Like people can build on top of it if they want, they=
=20
>>>>> just have to
>>>>>let us know so they can request a more compatible license.
>>>>>         jdeolive        i like that actually
>>>>>         brent   is this also something that we should take to the=
 list?
>>>>></quote>
>>>>>
>>>>>So my comment is that I'm fine with whatever license we choose=20
>>>>>(actually I'm
>>>>>fine partially because of ignorance of the deep implications of=20
>>>>>choosing one
>>>>>over another), but its just that having the core LGPL and plugins GPL=
=20
>>>>>would
>>>>>be a great opportunity for giving back too.
>>>>>For example, I'm currently doing a CSW2 implementation and I would=20
>>>>>loved to
>>>>>base it on geoserver. Client didn't wanted to make it GPL, at least=20
>>>>>for now,
>>>>>so I wasn't able of using geoserver :(
>>>>>With that model I would been able of basing my project on geoserver=20
>>>>>and keep
>>>>>fighting with the client to release the service implementation as OS=20
>>>>>later.
>>>>>
>>>>>2c.-
>>>>>
>>>>>Gabriel
>>>>>
>>>>>--
>>>>>Gabriel Rold=E1n (groldan@...)
>>>>>Axios Engineering (http://www.axios.es)
>>>>>Tel. +34 944 41 63 84
>>>>>Fax. +34 944 41 64 90
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>All the advantages of Linux Managed Hosting--Without the Cost and Risk!
>>>>>Fully trained technicians. The highest number of Red Hat certifications=
 in
>>>>>the hosting industry. Fanatical Support. Click to learn more
>>>>>http://sel.as-us.falkag.net/sel?cmdk&kid7521&bid$8729&dat1642
>>>>>_______________________________________________
>>>>>Geoserver-devel mailing list
>>>>>Geoserver-devel@...
>>>>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>All the advantages of Linux Managed Hosting--Without the Cost and Risk!
>>>>Fully trained technicians. The highest number of Red Hat certifications=
 in
>>>>the hosting industry. Fanatical Support. Click to learn more
>>>>http://sel.as-us.falkag.net/sel?cmd=3Dk&kid7521&bid$8729&dat1642
>>>>_______________________________________________
>>>>Geoserver-devel mailing list
>>>>Geoserver-devel@...
>>>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>
>
>
>
>
>-------------------------------------------------------
>All the advantages of Linux Managed Hosting--Without the Cost and Risk!
>Fully trained technicians. The highest number of Red Hat certifications in
>the hosting industry. Fanatical Support. Click to learn more
>http://sel.as-us.falkag.net/sel?cmdk&kid7521&bid$8729&dat1642
>_______________________________________________
>Geoserver-devel mailing list
>Geoserver-devel@...
>https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Hey guys,

We've checked out the coverages branch and have been trying to get it to 
go...

My system is exploding for whatever reason -- can anyone make heads or 
tails of this?

I'm running JAI v1.1.2_01 on WinXP.

For java 1.4, "mvn clean install" from root project directory:

[surefire] Running org.geotools.coverage.CategoryListTest
[surefire] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.282 sec
[surefire] Running org.geotools.coverage.CategoryTest
[surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.141 sec
[surefire] Running org.geotools.coverage.grid.CropTest
[surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.485 sec
[surefire] Running org.geotools.coverage.grid.FilteredSubsampleTest
[surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.5 sec
[surefire] Running org.geotools.coverage.grid.FloatRasterTest
[surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.375 sec
[surefire] Running org.geotools.coverage.grid.GridCoverageTest
[surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.141 sec
[surefire] Running org.geotools.coverage.grid.GridGeometryTest
[surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.047 sec
[surefire] Running org.geotools.coverage.grid.InterpolatorTest
[surefire] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.407 sec
[surefire] Running org.geotools.coverage.grid.OperationsTest
[surefire] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.719 sec
[surefire] Running org.geotools.coverage.grid.ResampleTest

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at 
PC=0x37E0CA6
Function=[Unknown.]
Library=C:\java\j2sdk1.4.2_08\jre\bin\mlib_jai.dll

NOTE: We are unable to locate the function name symbol for the error
      just occurred. Please refer to release documentation for possible
      reason and solutions.

Current Java thread:
        at com.sun.medialib.mlib.Image.ZoomTranslate_Fp(Native Method)
        at 
com.sun.media.jai.mlib.MlibScaleBilinearOpImage.computeRect(MlibScaleBilinearOpImage.java:143)
        at javax.media.jai.ScaleOpImage.computeTile(ScaleOpImage.java:1195)
        at 
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:912)
        at javax.media.jai.OpImage.getTile(OpImage.java:1139)
        at javax.media.jai.PlanarImage.cobbleFloat(PlanarImage.java:3267)
        at javax.media.jai.PlanarImage.getData(PlanarImage.java:2194)
        at javax.media.jai.PlanarImage.getData(PlanarImage.java:2029)
        at javax.media.jai.RenderedOp.getData(RenderedOp.java:2277)
        at 
org.geotools.coverage.grid.ResampleTest.projectTo(ResampleTest.java:190)
        at 
org.geotools.coverage.grid.ResampleTest.testAffine(ResampleTest.java:246)
        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:324)
        at junit.framework.TestCase.runTest(TestCase.java:154)
        at junit.framework.TestCase.runBare(TestCase.java:127)
        at junit.framework.TestResult$1.protect(TestResult.java:106)
        at junit.framework.TestResult.runProtected(TestResult.java:124)
        at junit.framework.TestResult.run(TestResult.java:109)
        at junit.framework.TestCase.run(TestCase.java:118)
        at junit.framework.TestSuite.runTest(TestSuite.java:208)
        at junit.framework.TestSuite.run(TestSuite.java:203)
        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:324)
        at 
org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:242)
        at 
org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:216)
        at 
org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215)
        at org.apache.maven.surefire.Surefire.run(Surefire.java:163)
        at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
        at org.apache.maven.surefire.Surefire.run(Surefire.java:63)
        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:324)
        at 
org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785)

Dynamic libraries:
0x00400000 - 0x0040B000         c:\java\j2sdk1.4.2_08\bin\java.exe
0x7C900000 - 0x7C9B0000         C:\WINDOWS\system32\ntdll.dll
0x7C800000 - 0x7C8F4000         C:\WINDOWS\system32\kernel32.dll
0x77DD0000 - 0x77E6B000         C:\WINDOWS\system32\ADVAPI32.dll
0x77E70000 - 0x77F01000         C:\WINDOWS\system32\RPCRT4.dll
0x77C10000 - 0x77C68000         C:\WINDOWS\system32\MSVCRT.dll
0x08000000 - 0x08138000         c:\java\j2sdk1.4.2_08\jre\bin\client\jvm.dll
0x77D40000 - 0x77DD0000         C:\WINDOWS\system32\USER32.dll
0x77F10000 - 0x77F57000         C:\WINDOWS\system32\GDI32.dll
0x76B40000 - 0x76B6D000         C:\WINDOWS\system32\WINMM.dll
0x10000000 - 0x10007000         c:\java\j2sdk1.4.2_08\jre\bin\hpi.dll
0x00390000 - 0x0039E000         c:\java\j2sdk1.4.2_08\jre\bin\verify.dll
0x003B0000 - 0x003C9000         c:\java\j2sdk1.4.2_08\jre\bin\java.dll
0x003D0000 - 0x003DE000         c:\java\j2sdk1.4.2_08\jre\bin\zip.dll
0x03060000 - 0x03172000         C:\java\j2sdk1.4.2_08\jre\bin\awt.dll
0x73000000 - 0x73026000         C:\WINDOWS\system32\WINSPOOL.DRV
0x76390000 - 0x763AD000         C:\WINDOWS\system32\IMM32.dll
0x774E0000 - 0x7761D000         C:\WINDOWS\system32\ole32.dll
0x00950000 - 0x00973000         C:\java\j2sdk1.4.2_08\jre\bin\cmm.dll
0x036C0000 - 0x039F0000         C:\java\j2sdk1.4.2_08\jre\bin\mlib_jai.dll
0x03A00000 - 0x03A1E000         C:\java\j2sdk1.4.2_08\jre\bin\jpeg.dll
0x03A20000 - 0x03B0D000         C:\java\j2sdk1.4.2_08\jre\bin\clib_jiio.dll
0x03B10000 - 0x03B1F000         C:\java\j2sdk1.4.2_08\jre\bin\net.dll
0x71AB0000 - 0x71AC7000         C:\WINDOWS\system32\WS2_32.dll
0x71AA0000 - 0x71AA8000         C:\WINDOWS\system32\WS2HELP.dll
0x71A50000 - 0x71A8F000         C:\WINDOWS\System32\mswsock.dll
0x76F20000 - 0x76F47000         C:\WINDOWS\system32\DNSAPI.dll
0x76FB0000 - 0x76FB8000         C:\WINDOWS\System32\winrnr.dll
0x76F60000 - 0x76F8C000         C:\WINDOWS\system32\WLDAP32.dll
0x76FC0000 - 0x76FC6000         C:\WINDOWS\system32\rasadhlp.dll
0x662B0000 - 0x66308000         C:\WINDOWS\system32\hnetcfg.dll
0x71A90000 - 0x71A98000         C:\WINDOWS\System32\wshtcpip.dll
0x5AD70000 - 0x5ADA8000         C:\WINDOWS\system32\uxtheme.dll
0x03DD0000 - 0x03E21000         
C:\java\j2sdk1.4.2_08\jre\bin\fontmanager.dll
0x73760000 - 0x737A9000         C:\WINDOWS\system32\ddraw.dll
0x73BC0000 - 0x73BC6000         C:\WINDOWS\system32\DCIMAN32.dll
0x73940000 - 0x73A10000         C:\WINDOWS\system32\D3DIM700.DLL
0x74720000 - 0x7476B000         C:\WINDOWS\system32\MSCTF.dll
0x76C90000 - 0x76CB8000         C:\WINDOWS\system32\imagehlp.dll
0x59A60000 - 0x59B01000         C:\WINDOWS\system32\DBGHELP.dll
0x77C00000 - 0x77C08000         C:\WINDOWS\system32\VERSION.dll
0x76BF0000 - 0x76BFB000         C:\WINDOWS\system32\PSAPI.DLL

Heap at VM Abort:
Heap
 def new generation   total 896K, used 835K [0x10010000, 0x10100000, 
0x12770000)
  eden space 832K,  97% used [0x10010000, 0x100dab40, 0x100e0000)
  from space 64K,  37% used [0x100f0000, 0x100f60d0, 0x10100000)
  to   space 64K,   0% used [0x100e0000, 0x100e0000, 0x100f0000)
 tenured generation   total 10872K, used 9690K [0x12770000, 0x1320e000, 
0x30010000)
   the space 10872K,  89% used [0x12770000, 0x130e6a88, 0x130e6c00, 
0x1320e000)
 compacting perm gen  total 10240K, used 10065K [0x30010000, 0x30a10000, 
0x34010000)
   the space 10240K,  98% used [0x30010000, 0x309e44e8, 0x309e4600, 
0x30a10000)

Local Time = Mon May 29 14:46:19 2006
Elapsed Time = 8
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_08-b03 mixed mode)
#
# An error report file has been saved as hs_err_pid2680.log.
# Please refer to the file for further information.
#
[INFO] 
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] 
------------------------------------------------------------------------
[INFO] There are test failures.
[INFO] 
------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] 
------------------------------------------------------------------------
[INFO] Total time: 1 minute 25 seconds
[INFO] Finished at: Mon May 29 14:46:20 PDT 2006
[INFO] Final Memory: 16M/55M
[INFO] 
------------------------------------------------------------------------

Please make an svn update. it should be fixed now.

Simone.

On 5/30/06, Cory Horner <chorner@...> wrote:
> Hey guys,
>
> We've checked out the coverages branch and have been trying to get it to
> go...
>
> My system is exploding for whatever reason -- can anyone make heads or
> tails of this?
>
> I'm running JAI v1.1.2_01 on WinXP.
>
> For java 1.4, "mvn clean install" from root project directory:
>
> [surefire] Running org.geotools.coverage.CategoryListTest
> [surefire] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.282 sec
> [surefire] Running org.geotools.coverage.CategoryTest
> [surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.141 sec
> [surefire] Running org.geotools.coverage.grid.CropTest
> [surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.485 sec
> [surefire] Running org.geotools.coverage.grid.FilteredSubsampleTest
> [surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.5 sec
> [surefire] Running org.geotools.coverage.grid.FloatRasterTest
> [surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.375 sec
> [surefire] Running org.geotools.coverage.grid.GridCoverageTest
> [surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.141 sec
> [surefire] Running org.geotools.coverage.grid.GridGeometryTest
> [surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.047 sec
> [surefire] Running org.geotools.coverage.grid.InterpolatorTest
> [surefire] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.407 sec
> [surefire] Running org.geotools.coverage.grid.OperationsTest
> [surefire] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.719 sec
> [surefire] Running org.geotools.coverage.grid.ResampleTest
>
> An unexpected exception has been detected in native code outside the VM.
> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
> PC=3D0x37E0CA6
> Function=3D[Unknown.]
> Library=3DC:\java\j2sdk1.4.2_08\jre\bin\mlib_jai.dll
>
> NOTE: We are unable to locate the function name symbol for the error
>      just occurred. Please refer to release documentation for possible
>      reason and solutions.
>
>
> Current Java thread:
>        at com.sun.medialib.mlib.Image.ZoomTranslate_Fp(Native Method)
>        at
> com.sun.media.jai.mlib.MlibScaleBilinearOpImage.computeRect(MlibScaleBili=
nearOpImage.java:143)
>        at javax.media.jai.ScaleOpImage.computeTile(ScaleOpImage.java:1195=
)
>        at
> com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.jav=
a:912)
>        at javax.media.jai.OpImage.getTile(OpImage.java:1139)
>        at javax.media.jai.PlanarImage.cobbleFloat(PlanarImage.java:3267)
>        at javax.media.jai.PlanarImage.getData(PlanarImage.java:2194)
>        at javax.media.jai.PlanarImage.getData(PlanarImage.java:2029)
>        at javax.media.jai.RenderedOp.getData(RenderedOp.java:2277)
>        at
> org.geotools.coverage.grid.ResampleTest.projectTo(ResampleTest.java:190)
>        at
> org.geotools.coverage.grid.ResampleTest.testAffine(ResampleTest.java:246)
>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>        at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39)
>        at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
>        at java.lang.reflect.Method.invoke(Method.java:324)
>        at junit.framework.TestCase.runTest(TestCase.java:154)
>        at junit.framework.TestCase.runBare(TestCase.java:127)
>        at junit.framework.TestResult$1.protect(TestResult.java:106)
>        at junit.framework.TestResult.runProtected(TestResult.java:124)
>        at junit.framework.TestResult.run(TestResult.java:109)
>        at junit.framework.TestCase.run(TestCase.java:118)
>        at junit.framework.TestSuite.runTest(TestSuite.java:208)
>        at junit.framework.TestSuite.run(TestSuite.java:203)
>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>        at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39)
>        at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
>        at java.lang.reflect.Method.invoke(Method.java:324)
>        at
> org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.=
java:242)
>        at
> org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:=
216)
>        at
> org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215)
>        at org.apache.maven.surefire.Surefire.run(Surefire.java:163)
>        at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
>        at org.apache.maven.surefire.Surefire.run(Surefire.java:63)
>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>        at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39)
>        at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
>        at java.lang.reflect.Method.invoke(Method.java:324)
>        at
> org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785)
>
> Dynamic libraries:
> 0x00400000 - 0x0040B000         c:\java\j2sdk1.4.2_08\bin\java.exe
> 0x7C900000 - 0x7C9B0000         C:\WINDOWS\system32\ntdll.dll
> 0x7C800000 - 0x7C8F4000         C:\WINDOWS\system32\kernel32.dll
> 0x77DD0000 - 0x77E6B000         C:\WINDOWS\system32\ADVAPI32.dll
> 0x77E70000 - 0x77F01000         C:\WINDOWS\system32\RPCRT4.dll
> 0x77C10000 - 0x77C68000         C:\WINDOWS\system32\MSVCRT.dll
> 0x08000000 - 0x08138000         c:\java\j2sdk1.4.2_08\jre\bin\client\jvm.=
dll
> 0x77D40000 - 0x77DD0000         C:\WINDOWS\system32\USER32.dll
> 0x77F10000 - 0x77F57000         C:\WINDOWS\system32\GDI32.dll
> 0x76B40000 - 0x76B6D000         C:\WINDOWS\system32\WINMM.dll
> 0x10000000 - 0x10007000         c:\java\j2sdk1.4.2_08\jre\bin\hpi.dll
> 0x00390000 - 0x0039E000         c:\java\j2sdk1.4.2_08\jre\bin\verify.dll
> 0x003B0000 - 0x003C9000         c:\java\j2sdk1.4.2_08\jre\bin\java.dll
> 0x003D0000 - 0x003DE000         c:\java\j2sdk1.4.2_08\jre\bin\zip.dll
> 0x03060000 - 0x03172000         C:\java\j2sdk1.4.2_08\jre\bin\awt.dll
> 0x73000000 - 0x73026000         C:\WINDOWS\system32\WINSPOOL.DRV
> 0x76390000 - 0x763AD000         C:\WINDOWS\system32\IMM32.dll
> 0x774E0000 - 0x7761D000         C:\WINDOWS\system32\ole32.dll
> 0x00950000 - 0x00973000         C:\java\j2sdk1.4.2_08\jre\bin\cmm.dll
> 0x036C0000 - 0x039F0000         C:\java\j2sdk1.4.2_08\jre\bin\mlib_jai.dl=
l
> 0x03A00000 - 0x03A1E000         C:\java\j2sdk1.4.2_08\jre\bin\jpeg.dll
> 0x03A20000 - 0x03B0D000         C:\java\j2sdk1.4.2_08\jre\bin\clib_jiio.d=
ll
> 0x03B10000 - 0x03B1F000         C:\java\j2sdk1.4.2_08\jre\bin\net.dll
> 0x71AB0000 - 0x71AC7000         C:\WINDOWS\system32\WS2_32.dll
> 0x71AA0000 - 0x71AA8000         C:\WINDOWS\system32\WS2HELP.dll
> 0x71A50000 - 0x71A8F000         C:\WINDOWS\System32\mswsock.dll
> 0x76F20000 - 0x76F47000         C:\WINDOWS\system32\DNSAPI.dll
> 0x76FB0000 - 0x76FB8000         C:\WINDOWS\System32\winrnr.dll
> 0x76F60000 - 0x76F8C000         C:\WINDOWS\system32\WLDAP32.dll
> 0x76FC0000 - 0x76FC6000         C:\WINDOWS\system32\rasadhlp.dll
> 0x662B0000 - 0x66308000         C:\WINDOWS\system32\hnetcfg.dll
> 0x71A90000 - 0x71A98000         C:\WINDOWS\System32\wshtcpip.dll
> 0x5AD70000 - 0x5ADA8000         C:\WINDOWS\system32\uxtheme.dll
> 0x03DD0000 - 0x03E21000
> C:\java\j2sdk1.4.2_08\jre\bin\fontmanager.dll
> 0x73760000 - 0x737A9000         C:\WINDOWS\system32\ddraw.dll
> 0x73BC0000 - 0x73BC6000         C:\WINDOWS\system32\DCIMAN32.dll
> 0x73940000 - 0x73A10000         C:\WINDOWS\system32\D3DIM700.DLL
> 0x74720000 - 0x7476B000         C:\WINDOWS\system32\MSCTF.dll
> 0x76C90000 - 0x76CB8000         C:\WINDOWS\system32\imagehlp.dll
> 0x59A60000 - 0x59B01000         C:\WINDOWS\system32\DBGHELP.dll
> 0x77C00000 - 0x77C08000         C:\WINDOWS\system32\VERSION.dll
> 0x76BF0000 - 0x76BFB000         C:\WINDOWS\system32\PSAPI.DLL
>
> Heap at VM Abort:
> Heap
>  def new generation   total 896K, used 835K [0x10010000, 0x10100000,
> 0x12770000)
>  eden space 832K,  97% used [0x10010000, 0x100dab40, 0x100e0000)
>  from space 64K,  37% used [0x100f0000, 0x100f60d0, 0x10100000)
>  to   space 64K,   0% used [0x100e0000, 0x100e0000, 0x100f0000)
>  tenured generation   total 10872K, used 9690K [0x12770000, 0x1320e000,
> 0x30010000)
>   the space 10872K,  89% used [0x12770000, 0x130e6a88, 0x130e6c00,
> 0x1320e000)
>  compacting perm gen  total 10240K, used 10065K [0x30010000, 0x30a10000,
> 0x34010000)
>   the space 10240K,  98% used [0x30010000, 0x309e44e8, 0x309e4600,
> 0x30a10000)
>
> Local Time =3D Mon May 29 14:46:19 2006
> Elapsed Time =3D 8
> #
> # The exception above was detected in native code outside the VM
> #
> # Java VM: Java HotSpot(TM) Client VM (1.4.2_08-b03 mixed mode)
> #
> # An error report file has been saved as hs_err_pid2680.log.
> # Please refer to the file for further information.
> #
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] There are test failures.
> [INFO]
> ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 1 minute 25 seconds
> [INFO] Finished at: Mon May 29 14:46:20 PDT 2006
> [INFO] Final Memory: 16M/55M
> [INFO]
> ------------------------------------------------------------------------
>
>
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications i=
n
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D107521&bid=3D248729&dat=
=3D121642
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>

--=20
=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=
=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=
=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0

GeoTools 2.2-RC3 is now available for download!
- http://geotools.codehaus.org/2.2-RC3

This release includes several bug fixes and was made entirely with Maven 2.

Our next release should be 2.2 final.

To take part in GeoTools development join the devel list, check out the 
RnD page, or attend one of the weekly IRC Meetings.
- http://docs.codehaus.org/display/GEOTOOLS/RnD
- http://docs.codehaus.org/display/GEOTOOLS/Communication

GeoTools Project Management Committee

WFSCapabilities.getFeatureSetDescription() has empty conditional where it should return a value
-----------------------------------------------------------------------------------------------

         Key: GEOT-861
         URL: http://jira.codehaus.org/browse/GEOT-861
     Project: GeoTools
        Type: Bug

  Components: data wfs  
    Versions: 2.2-RC2    
 Environment: OS X, Java 1.5
    Reporter: Ryan Hofschneider
 Assigned to: David Zwiers 

In org.geotools.data.ows.WFSCapabilities.getFeatureSetDescription(), it goes to the effort to check for feature type names with namespaces, but does not take any action -- the if-statement is empty. This breaks getSchema requests in WFSDataStore.

The if-statement should look like this:
if(index!=-1 && typename.equals(name.substring(index+1))){
   return fsd;   
}

This allows the check to succeed, even if name has the namespace used by the cascaded WFS server.

-- 
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

FeatureTranslator.handleFeature() and endFeature() don't handle feature type names with an existing namespace
-------------------------------------------------------------------------------------------------------------

         Key: GEOT-860
         URL: http://jira.codehaus.org/browse/GEOT-860
     Project: GeoTools
        Type: Improvement

    Versions: 2.2-RC2    
 Environment: OS X, Java 1.5
    Reporter: Ryan Hofschneider
    Priority: Minor

org.geotools.gml.producer.FeatureTransformer$FeatureTranslator.handleFeature() and endFeature() do not account for the situation where the feature type name already contains a namespace. This edge case will occur in GeoServer when it cascades WFS requests using the WFS DataStore. The resulting WFS response is invalid XML since the feature element will have two namespaces (e.g., topp:topp:tasmania_roads).

I have no idea if the fix should be at the GeoTools level or the GeoServer level, but a quick fix to permit cascaded WFS requests in GeoServer was to change the logic in both handleFeature() and endFeature() to something like:

if (currentPrefix != null) {
    int index = name.indexOf(':');
    if (index != -1) {
        name = name.substring(index+1);
    }
    name = currentPrefix + ":" + name;
}

-- 
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

Ciao Martin, ciao a tutti,
I would like to expose some thougths about the proposed solution.

I read and understood all objections and concerns stated by different
people in these set of emails. My objection is (do not yell at me
please...) that we are not solving the problem or at least not the
problem I stated at the beginning of this thread.

I think this solution looks promising in the mid term, but I see a big
problem if try to look at the short term (1-2 months).

Let's look at the actual GeoTools-GeoServer supposing that the
proposed solution is in place. If we remove epsg-wkt from classpath
and we drop epsg-hsql things will not work again (especially if you
try to reproject). This does not surprise for various reasons.

1>I do not have any control on the plugins and if one plugin (for
example shapefile) is not making use of the proposed HINT things will
not be as expected due to the axes swap. This means that if I
substitute epsg-wkt with epsg:hsql I will get coordinates in the wrong
CRS.

I frankly doubt that in the short term we will ever be able to align
all the codebase with this HINT.

2>I have to go look all over the GeoTools-GeoServer code to track down
all the places where that HINT should have been used. It is not just
about Referencing or plugins, I am also talking about for example the
Renderer. This applies also to all the  applications built upon
geotools where a CRS is instantiate using the EPSG:CODE fashion.

In all and every module/plugin/app where the epsg-wkt has been used if
you just drop the epsg-hsql you will run into a lot of troubles unless
you have been really really careful with checking the axis order. If
you ever made the assumption (wrong assumption but you might have made
it) to get always coords as easting,northing nothing will not work
anymore.

>>Conclusion

For the above mentioned reasons as a short short term hack I would
have really loved to see the refactor of
OrderedForgotTheNameAuthority.
I know it has  a system wide effect but it is really what I would like
to have as a hack!!!  If you have to make an hack make it visible and
consistent therefore when you will remove it nothing will change in
the rest of the code.

If we go with the proposed solution we will have probably to change
many plugins, modules and applications built on top of them, which
will bring confusion and bugs (hopefully not), just to substitute
epsg-wkt.

Frankly, If I were a user with an application built on top of GeoTools
I would NEVER drop epsg-wkt for epsg-hsql and change all my code
around it. I would rather use something that guarantee that my
codebase wil continue to work so that I can start removing all the
wrong assumptions I made and get aligned with the correct codeline.
That *something* would be a system wide switch as I proposed with the
refactor of the old authority (and as also someone else before me
proposed since OrderedBlahBlahAuthority was the answer to some user's
question, it did not fall from the sky see
http://jira.codehaus.org/browse/GEOT-694).
It is worth to point out that this quick hack would not clash with the
solution proposed by Martin that is btw elegant and correct but would
be more like a transition thing to help people remove wrong assumption
from their applications. Once we are sure that all geotools codebase
is using Martin's HINT we could deprecate and then remove the
OrderedBlahBlahAuthority.

I think (and many people say this as well ) that one of the most
annoying things of Geotools and of Open Source Software in general is
that it changes too much!! (correct Bryce?). You write your app now
and in 6 months if you recompile nothing will work (I am being a bit
pessimistic sorry).

So my proposal is:

1>Martin's HINT is correct and more than welcome(I would say mid.-term
solution).

2>Quick awful bad dirty system wide hack to help people (module
maintainers and external  applications) check their code and make it
stronger. This would be the refactoring of
OrderedForgotTheNameAuthority.

3>Have all the module maintainers review their code looking for wrong
assumptions to be removed (mid term).

4>URI based authority (mid-term to long term solution).

I hope that this contribution from me is of help. I always try to
suggest what I believe would make Geotools more popular and accepted.

Simone.

On 5/25/06, Martin Desruisseaux <martin.desruisseaux@...> wrote:
> Thanks Jody, Bryce, Paul and everyone for your input.
>
> So the best compromise I can imagine right now is:
>
>   * CRS created from EPSG codes will still as specified in the EPSG datab=
ase
>     (i.e. latitude,longitude axis order) by default. The EPSG factories s=
tay
>     basically unchanged - no hack.
>
>   * Users need to be able to force (longitude,latitude) axis order on a c=
ase-
>     by-case basis. It must be entirely under user control - the referenci=
ng
>     module will never swap axis without user request. It is up to the use=
r
>     (or to the DataStore implementor) to decide if the DataStore in use r=
equires
>     such axis swapping or not.
>
>   * Deprecate the OrderedAxisAuthorityFactory.register(String) method, be=
cause
>     it has a system-wide effect: it violate the "case-by-case" requiremen=
t above.
>     Note that the OrderedAxisAuthorityFactory class itself will still in =
use.
>
>   * Introduce a new hint in the org.geotools.factory package: Hints.FORCE=
_ORDERED_AXIS.
>
>   * If a user want to create CRS from EPSG codes with (longitude,latitude=
) axis
>     order, he must provides explicitly the above-cited hint when requesti=
ng for
>     a CRSAuthorityFactory:
>
>       Hints hints =3D new Hints(Hints.FORCE_ORDERED_AXIS, Boolean.TRUE);
>       CRSAuthorityFactory factory =3D FactoryFinder.getCRSAuthorityFactor=
y("EPSG", hints);
>
>     If the FORCE_ORDERED_AXIS hint is not provided, the default value if =
Boolean.FALSE.
>     Under the hood, when Hints.FORCE_ORDERED_AXIS is set to Boolean.TRUE,=
 Geotools's
>     FactoryFinder will just returns the standard EPSG factory wrapped in =
a
>     OrderedAxisAuthorityFactory instance.
>
>   * Maybe add a CRS.decode(String code, boolean forceOrderedAxis) conveni=
ence method.
>
>   * As Jody pointed out, all CRS arguments should be CoordinateReferenceS=
ystem objects,
>     never a plain String, in order to avoid ambiguity. The referencing mo=
dule should be
>     able to handle correctly CoordinateReferenceSystem objects in all cas=
es, no matter
>     what the axis order is, as long as axis are correctly defined in the =
CRS object.
>
>   * The potentially dangerous side-effect is that the same running JVM ma=
y have different
>     CRS with different axis order while claiming the same EPSG code. It c=
an lead to some
>     errors like StackOverflowError in non-cautious code. The referencing =
module has been
>     made more robust (GEOT-854). However, I'm not sure if the same kind o=
f error may occurs
>     in client code.
>
>   * Changes will be applied on the trunk (toward 2.3 release) only. The c=
hanges seems a
>     little bit too significant to me for the 2.2 branch.
>
> Does it make sense?
>
>        Martin.
>

--=20
=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=
=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=
=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0

Simone Giannecchini a =E9crit :
> I would like to expose some thougths about the proposed solution.
> [...snip...]

OrderedAxisAuthorityFactory is not going to be removed. Even with the Hin=
t proposal, it still the=20
class performing the work under the hood, so this class is there to stay.=
 The=20
OrderedAxisAuthorityFactory.register("EPSG") method is not removed neithe=
r; it is just deprecated in=20
favor of the case-by-case approach. We may undeprecate this particular me=
thod if it appears that it=20
is going to stay there for a while.

	Martin.

That would be good for me as long as I do not get the "modified axis"
metadata but the EPSG plain name. Since the registration has a system
wide effect it should not clash with anything else.

I hope I made my point clearly.

Simone.

On 5/29/06, Martin Desruisseaux <martin.desruisseaux@...> wrote:
> Simone Giannecchini a =E9crit :
> > I would like to expose some thougths about the proposed solution.
> > [...snip...]
>
> OrderedAxisAuthorityFactory is not going to be removed. Even with the Hin=
t proposal, it still the
> class performing the work under the hood, so this class is there to stay.=
 The
> OrderedAxisAuthorityFactory.register("EPSG") method is not removed neithe=
r; it is just deprecated in
> favor of the case-by-case approach. We may undeprecate this particular me=
thod if it appears that it
> is going to stay there for a while.
>
>        Martin.
>

--=20
=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=
=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=
=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0

Hi folks,

I would imagine that this will be a topic of discussion at tonights IRC=20
meeting. I know Martin came up with someone but there seems to be more=20
to this issue.

Could someone please summarize so that poor souls like myself can follow=20
at tonights meeting.

Thanks.

-Justin

Simone Giannecchini wrote:
> That would be good for me as long as I do not get the "modified axis"
> metadata but the EPSG plain name. Since the registration has a system
> wide effect it should not clash with anything else.
>=20
> I hope I made my point clearly.
>=20
> Simone.
>=20
> On 5/29/06, Martin Desruisseaux <martin.desruisseaux@...> wro=
te:
>=20
>> Simone Giannecchini a =E9crit :
>> > I would like to expose some thougths about the proposed solution.
>> > [...snip...]
>>
>> OrderedAxisAuthorityFactory is not going to be removed. Even with the=20
>> Hint proposal, it still the
>> class performing the work under the hood, so this class is there to=20
>> stay. The
>> OrderedAxisAuthorityFactory.register("EPSG") method is not removed=20
>> neither; it is just deprecated in
>> favor of the case-by-case approach. We may undeprecate this particular=
=20
>> method if it appears that it
>> is going to stay there for a while.
>>
>>        Martin.
>>
>=20
>=20

--=20
Justin Deoliveira
The Open Planning Project
jdeolive@...

Simone Giannecchini a =E9crit :
> That would be good for me as long as I do not get the "modified axis"
> metadata but the EPSG plain name. Since the registration has a system
> wide effect it should not clash with anything else.

This part is already done and commited on trunk since revision 19642:=20
http://jira.codehaus.org/browse/GEOT-854

The work currently under progress (which is much more difficult than I in=
itially though) is=20
http://jira.codehaus.org/browse/GEOT-858

	Martin.

Justin Deoliveira a =E9crit :
> Could someone please summarize so that poor souls like myself can follo=
w=20
> at tonights meeting.

A wiki page was started there: http://docs.codehaus.org/display/GEOTOOLS/=
The+axis+order+issue (may=20
need to be completed...)

	Martin

Martin Desruisseaux wrote:
> Justin Deoliveira a =E9crit :
>> Could someone please summarize so that poor souls like myself can=20
>> follow at tonights meeting.
> A wiki page was started there:=20
> http://docs.codehaus.org/display/GEOTOOLS/The+axis+order+issue (may=20
> need to be completed...)
Thanks martin, let me try ...

The page above represents:
- a great breakdown of the problem
- a proposed solutions using a  HINT
- guidelines for what geotools developers should do

There are three outstanding requests
1- SHORT-TERM: the request for a "EPSG:code" authority that can be used=20
short term as a replacement for epsg-wkt
2- MEDIUM-TERM: the request for a "URI....epsg/6.1/code" authority that=20
can be used with WMS 1.3 and new GML3 work
3- MEDIUM-TERM: provide someway for client code to "tweak" the CRS used=20
at the datastore level (ie where data is read)

Request 1: is needed today, it feels the same need as epsg-wkt, and=20
would probably used by uDig and GeoServer in the next available release
Request 2: is just something I want, so I have clear example code that=20
nobody can get confused over
Request 3: is probably going to need to wait for your FeatureModel=20
improvements where DataStore could be injected by a CRSFactory

If I have missed out on any requests let me know...
Jody

Jody Garnett wrote:
>>> Could someone please summarize so that poor souls like myself can 
>>> follow at tonights meeting.
>> A wiki page was started there: 
>> http://docs.codehaus.org/display/GEOTOOLS/The+axis+order+issue (may 
>> need to be completed...)
> Thanks martin, let me try ...
>
Bleah tried to update the page but the email was clearer, can someone 
else have a kick at this?

I would take a look here

http://docs.codehaus.org/display/GEOTOOLS/The+axis+order+issue?focusedComme=
ntId=3D53165#comment-53165

 in case you haven't yet.

Simone.

On 5/29/06, Justin Deoliveira <jdeolive@...> wrote:
> Hi folks,
>
> I would imagine that this will be a topic of discussion at tonights IRC
> meeting. I know Martin came up with someone but there seems to be more
> to this issue.
>
> Could someone please summarize so that poor souls like myself can follow
> at tonights meeting.
>
> Thanks.
>
> -Justin
>
> Simone Giannecchini wrote:
> > That would be good for me as long as I do not get the "modified axis"
> > metadata but the EPSG plain name. Since the registration has a system
> > wide effect it should not clash with anything else.
> >
> > I hope I made my point clearly.
> >
> > Simone.
> >
> > On 5/29/06, Martin Desruisseaux <martin.desruisseaux@...> wro=
te:
> >
> >> Simone Giannecchini a =E9crit :
> >> > I would like to expose some thougths about the proposed solution.
> >> > [...snip...]
> >>
> >> OrderedAxisAuthorityFactory is not going to be removed. Even with the
> >> Hint proposal, it still the
> >> class performing the work under the hood, so this class is there to
> >> stay. The
> >> OrderedAxisAuthorityFactory.register("EPSG") method is not removed
> >> neither; it is just deprecated in
> >> favor of the case-by-case approach. We may undeprecate this particular
> >> method if it appears that it
> >> is going to stay there for a while.
> >>
> >>        Martin.
> >>
> >
> >
>
>
> --
> Justin Deoliveira
> The Open Planning Project
> jdeolive@...
>

--=20
=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=
=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=
=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0

Hi

I feel that we really need to move forward with Simone's short term =20
plan so that he can get the GC branch merged onto trunk.  I am ok =20
with doing what he suggests for a short term solution and migrating =20
towards the suggested medium range plans.  I will happily do the work =20=

to the shapefile modules in order to provide an example of what needs =20=

to be done for the medium-long term goal.

I've added a chat I just had with Simone about the topic.
http://docs.codehaus.org/display/GEOTOOLS/The+axis+order+issue?=20
focusedCommentId=3D53215#comment-53215

Jesse

On 29-May-06, at 7:51 AM, Simone Giannecchini wrote:

> I would take a look here
>
> http://docs.codehaus.org/display/GEOTOOLS/The+axis+order+issue?=20
> focusedCommentId=3D53165#comment-53165
>
> in case you haven't yet.
>
> Simone.
>
> On 5/29/06, Justin Deoliveira <jdeolive@...> wrote:
>> Hi folks,
>>
>> I would imagine that this will be a topic of discussion at =20
>> tonights IRC
>> meeting. I know Martin came up with someone but there seems to be =20
>> more
>> to this issue.
>>
>> Could someone please summarize so that poor souls like myself can =20
>> follow
>> at tonights meeting.
>>
>> Thanks.
>>
>> -Justin
>>
>> Simone Giannecchini wrote:
>> > That would be good for me as long as I do not get the "modified =20
>> axis"
>> > metadata but the EPSG plain name. Since the registration has a =20
>> system
>> > wide effect it should not clash with anything else.
>> >
>> > I hope I made my point clearly.
>> >
>> > Simone.
>> >
>> > On 5/29/06, Martin Desruisseaux =20
>> <martin.desruisseaux@...> wrote:
>> >
>> >> Simone Giannecchini a =E9crit :
>> >> > I would like to expose some thougths about the proposed =20
>> solution.
>> >> > [...snip...]
>> >>
>> >> OrderedAxisAuthorityFactory is not going to be removed. Even =20
>> with the
>> >> Hint proposal, it still the
>> >> class performing the work under the hood, so this class is =20
>> there to
>> >> stay. The
>> >> OrderedAxisAuthorityFactory.register("EPSG") method is not removed
>> >> neither; it is just deprecated in
>> >> favor of the case-by-case approach. We may undeprecate this =20
>> particular
>> >> method if it appears that it
>> >> is going to stay there for a while.
>> >>
>> >>        Martin.
>> >>
>> >
>> >
>>
>>
>> --
>> Justin Deoliveira
>> The Open Planning Project
>> jdeolive@...
>>
>
>
> --=20
> =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=
=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0
> Simone Giannecchini
> Software Engineer
> Freelance Consultant
>
> http://simboss.wordpress.com/
>
> =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=
=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and =20
> Risk!
> Fully trained technicians. The highest number of Red Hat =20
> certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=107521&bid$8729&dat=121642=

> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel

Richard Gould a =E9crit :
> One of the issues brought up in today's IRC meeting was that we are ove=
r=20
> our quota of space on the sourceforget shell server. We are using 600 M=
B=20
> and are only allowed 100 MB.

I took the following actions:

    - Verified that http://geotools.sourceforge.net was not working.
      The site was trying to connect to some MySQL server and failed.

    - Verified (not extensively) that no file were most recent than
      2004. A lot of files are from 2002. So the site really seems
      unmaintained.

    - Assumed that, because the site was not working anymore for a
      long time (years?) and nobody seems to complains, we will not
      get any complains if I move the sourceforge website elsewhere.

    - Zipped all directories and stored the ZIP files in the "backup"
      directory. I zipped everything I could, but have not been able
      to zip everything. Symbolic links in particular were losts.

    - Deleted the previous directories. So http://geotools.sourceforge.ne=
t
      is now empty.

Nevertheless, we are still using 222 MB, so we still over our quotas. Cou=
ld someone with fast=20
Internet access download the ZIP files using the following command:

scp <yours SF login>@shell.sourceforge.net:/home/groups/g/ge/geotools/bac=
kup/*.zip .

and burn the ZIP files on a CD, so we can delete them from SourceForge?

	Martin.

I'm on it Martin.  I'll let you know when I'm done

Jesse

On 29-May-06, at 3:59 AM, Martin Desruisseaux wrote:

> scp <yours SF login>@shell.sourceforge.net:/home/groups/g/ge/ 
> geotools/backup/*.zip

Ok I've downloaded and burned all the files onto a CD.

The list of files are:
backup.zip 6kb
cgi-bin.zip 22kb
code.zip 27mb
gt2-db.tar.zip 956kb
htdocs.zip 24.3mb
html.zip 366kb
langage_zho.zip 130kb
pn_12.zip 130kb
postnuke.zip 118.4MB
postnuke703.zip 10.9MB
postnuke713.zip 7.MB
rogue714cn.zip 30.9MB
xbr.zip 402kb
xthemes.zip 4kb

Jesse

On 29-May-06, at 3:59 AM, Martin Desruisseaux wrote:

> Richard Gould a =E9crit :
>> One of the issues brought up in today's IRC meeting was that we =20
>> are over our quota of space on the sourceforget shell server. We =20
>> are using 600 MB and are only allowed 100 MB.
>
> I took the following actions:
>
>    - Verified that http://geotools.sourceforge.net was not working.
>      The site was trying to connect to some MySQL server and failed.
>
>    - Verified (not extensively) that no file were most recent than
>      2004. A lot of files are from 2002. So the site really seems
>      unmaintained.
>
>    - Assumed that, because the site was not working anymore for a
>      long time (years?) and nobody seems to complains, we will not
>      get any complains if I move the sourceforge website elsewhere.
>
>    - Zipped all directories and stored the ZIP files in the "backup"
>      directory. I zipped everything I could, but have not been able
>      to zip everything. Symbolic links in particular were losts.
>
>    - Deleted the previous directories. So http://=20
> geotools.sourceforge.net
>      is now empty.
>
> Nevertheless, we are still using 222 MB, so we still over our =20
> quotas. Could someone with fast Internet access download the ZIP =20
> files using the following command:
>
> scp <yours SF login>@shell.sourceforge.net:/home/groups/g/ge/=20
> geotools/backup/*.zip .
>
> and burn the ZIP files on a CD, so we can delete them from =20
> SourceForge?
>
> 	Martin.
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and =20
> Risk!
> Fully trained technicians. The highest number of Red Hat =20
> certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=107521&bid$8729&dat=121642=

> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel

Hi Michael,

I was preparing for a demo so it is possible that the classes are  
redundant and I didn't have time to correctly investigate the issue.   
I'm looking into it now and this is my current understanding, anyone  
can correct me I'm still learning postgis.

OIDFidMapper and PostGISAutoIncrementMapper are not redundant because:
1.  OIDFidMapper is used when there is no Primary key and as a last  
resort.  PostGISAutoIncrementMapper is used when there is a primary key.
2.  The implementation of createID in PostGISAutoIncrementMapper only  
works on postgres 8+ databases.  If the db is not a postgres 8+ then  
it uses the AutoIncrementFIDMapper to obtain the featureID.

MaxIncFIDMapper and AutoIncrementFIDMapper are not redundant because  
MaxIncFIDMapper is used when the primary key is NOT autoincrement.   
The implementations are the same because I don't know a way in SQL to  
query for the last returned item in the sequence and so ended up  
using the same query.  If there is no way to make that query then  
perhaps AutoIncrementFIDMapper should be abstract and all datastore  
should have their own subclass of AutoIncrementFIDMapper.

Comments are welcome.

Jesse

On 26-May-06, at 1:09 AM, Michael Brasser wrote:

> Jesse,
>
> THANK YOU for your updates to the PostGIS feature id mapper (and  
> AutoIncrementFIDMapper). This one has been bugging us for a while  
> (GEOT-847, which I have now closed).
>
> It seems like the updates have made a couple classes redundant  
> (correct me if I'm wrong):
>
> +OIDFidMapper.java or PostGISAutoIncrementFIDMapper.java
> One uses PGStatement, and the other use SQL, but I think they do  
> the same thing...
>
> +MaxIncFIDMapper.java or AutoIncrementFIDMapper.java
> One uses "Select MAX...", and the other uses "...order by...", but  
> again I think they do the same thing...
>
> Michael
>
> Jesse Eichar (JIRA) wrote:
>
>> postgis doesn't raise events
>> ----------------------------
>>
>>         Key: UDIG-809
>>         URL: http://jira.codehaus.org/browse/UDIG-809
>>     Project: uDIG
>>        Type: Bug
>>
>>  Components: postgis
>>    Versions: UDIG 1.1.RC0
>>    Reporter: Jesse Eichar
>> Assigned to: Jody Garnett
>>     Fix For: uDig Alberta Demo
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel

Hey, if anyone's hacking on this code, could you put in a bit of a 
better error report?

Now that many people are using postgres 8, when they forget their 
primary key they get a message about oid's not found.  Perhaps have that 
error report say 'no oid's found - if you are using postgres 8 or later 
you need to define a primary key on your data'.

The more elegant way would be to check the version before trying to use 
the oidfidmapper, and if there's no primary key and it's later than when 
oid's were phased out raise the right message about no primary key.  But 
the former's probably easier, and would work fine.

Chris

Jesse Eichar wrote:
> Hi Michael,
> 
> I was preparing for a demo so it is possible that the classes are  
> redundant and I didn't have time to correctly investigate the issue.   
> I'm looking into it now and this is my current understanding, anyone  
> can correct me I'm still learning postgis.
> 
> OIDFidMapper and PostGISAutoIncrementMapper are not redundant because:
> 1.  OIDFidMapper is used when there is no Primary key and as a last  
> resort.  PostGISAutoIncrementMapper is used when there is a primary key.
> 2.  The implementation of createID in PostGISAutoIncrementMapper only  
> works on postgres 8+ databases.  If the db is not a postgres 8+ then  it 
> uses the AutoIncrementFIDMapper to obtain the featureID.
> 
> MaxIncFIDMapper and AutoIncrementFIDMapper are not redundant because  
> MaxIncFIDMapper is used when the primary key is NOT autoincrement.   The 
> implementations are the same because I don't know a way in SQL to  query 
> for the last returned item in the sequence and so ended up  using the 
> same query.  If there is no way to make that query then  perhaps 
> AutoIncrementFIDMapper should be abstract and all datastore  should have 
> their own subclass of AutoIncrementFIDMapper.
> 
> Comments are welcome.
> 
> Jesse
> 
> On 26-May-06, at 1:09 AM, Michael Brasser wrote:
> 
>> Jesse,
>>
>> THANK YOU for your updates to the PostGIS feature id mapper (and  
>> AutoIncrementFIDMapper). This one has been bugging us for a while  
>> (GEOT-847, which I have now closed).
>>
>> It seems like the updates have made a couple classes redundant  
>> (correct me if I'm wrong):
>>
>> +OIDFidMapper.java or PostGISAutoIncrementFIDMapper.java
>> One uses PGStatement, and the other use SQL, but I think they do  the 
>> same thing...
>>
>> +MaxIncFIDMapper.java or AutoIncrementFIDMapper.java
>> One uses "Select MAX...", and the other uses "...order by...", but  
>> again I think they do the same thing...
>>
>> Michael
>>
>> Jesse Eichar (JIRA) wrote:
>>
>>> postgis doesn't raise events
>>> ----------------------------
>>>
>>>         Key: UDIG-809
>>>         URL: http://jira.codehaus.org/browse/UDIG-809
>>>     Project: uDIG
>>>        Type: Bug
>>>
>>>  Components: postgis
>>>    Versions: UDIG 1.1.RC0
>>>    Reporter: Jesse Eichar
>>> Assigned to: Jody Garnett
>>>     Fix For: uDig Alberta Demo
>>
>> _______________________________________________
>> User-friendly Desktop Internet GIS (uDig)
>> http://udig.refractions.net
>> http://lists.refractions.net/mailman/listinfo/udig-devel
> 
> 
> 
> 
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel

-- 
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Martin Desruisseaux wrote:
> Bryce L Nordgren a =E9crit :
>> There's significant opportunity to create resuable unit tests for the
>> GeoAPI geometry interfaces to determine implementation compliance and
>> correctness.  This potential presumably exists for other GeoAPI=20
>> modules as
>> well.  For now, let's keep it simple: should the geometry tests live=20
>> in the
>> GeoTools project, the GeoAPI project, or in a third project?
>
> I would like a test suite in the GeoAPI project, if we can write it=20
> abstract enough so that it doesn't contains any explicit reference to=20
> any implementation.
>
> If we can find volunter time, we may try to move some Geotools tests=20
> from the referencing module (at least the parts that do not involve=20
> any geotools-specific API) as a proof of concept.
That sounds great, for the GeoAPI project - in that test cases are a=20
great way to specify things in a manner stronger then just reading=20
javadocs :-)

Problem is this will make geotools much harder to maintain for anyone=20
who is not a member of both GeoTools and GeoAPI. Already on the FM=20
branch this kind of things is proving annoying, if you move test cases=20
over it will be much worse.

-1 (Be nice to your developers)

Jody

With the exception of a select few I do not expect many geotools=20
developers to actually build geoapi. Which would mean that the tests=20
that get moved out would be run less often which imho would decrease=20
their effectiveness.
-Justin

Martin Desruisseaux wrote:
> Bryce L Nordgren a =E9crit :
>=20
>> There's significant opportunity to create resuable unit tests for the
>> GeoAPI geometry interfaces to determine implementation compliance and
>> correctness.  This potential presumably exists for other GeoAPI=20
>> modules as
>> well.  For now, let's keep it simple: should the geometry tests live=20
>> in the
>> GeoTools project, the GeoAPI project, or in a third project?
>=20
>=20
> I would like a test suite in the GeoAPI project, if we can write it=20
> abstract enough so that it doesn't contains any explicit reference to=20
> any implementation.
>=20
> If we can find volunter time, we may try to move some Geotools tests=20
> from the referencing module (at least the parts that do not involve any=
=20
> geotools-specific API) as a proof of concept.
>=20
>=20
>> See page:
>> http://docs.codehaus.org/display/GEOTOOLS/Test+Plan+for+JTS+Geometry
>=20
>=20
>=20
> Thanks for that page. Its look like it could apply to other module like=
=20
> CRS also.
>=20
>     Martin.
>=20
>=20
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications=
 in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=107521&bid$8729&dat=12164=
2
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel

--=20
Justin Deoliveira
The Open Planning Project
jdeolive@...

Justin Deoliveira wrote:
> With the exception of a select few I do not expect many geotools=20
> developers to actually build geoapi. Which would mean that the tests=20
> that get moved out would be run less often which imho would decrease=20
> their effectiveness.

I think the idea is that either,
- we configure up our FactorySPI system so that GeoAPI can run the tests=20
with our implementation, problem is it will be hard as a test writer to=20
indicate what is broken (imagine the failure: "Expected 3 but was 4"),=20
you can do it "Coordinate System Axis for 4326 expected 2 but was 3")
- we could also subclass the tests, in the setup method provide them=20
with the factory instances they need to run and then stand back..same=20
approach used by MemoryDataStore and PropertyDataStore for a common test=20
fixture.

I could imagine using this for some data objects (like Name in=20
feature.type), but not for much else unless a fixture was provided with=20
the tests (like Name in util).

Interesting problems, one good thing would come of this - I have not had=20
great success in communicating with Javadocs thus far - test cases are a=20
bigger stick.
Jody

> -Justin
>
> Martin Desruisseaux wrote:
>> Bryce L Nordgren a =E9crit :
>>
>>> There's significant opportunity to create resuable unit tests for the
>>> GeoAPI geometry interfaces to determine implementation compliance and
>>> correctness.  This potential presumably exists for other GeoAPI=20
>>> modules as
>>> well.  For now, let's keep it simple: should the geometry tests live=20
>>> in the
>>> GeoTools project, the GeoAPI project, or in a third project?
>>
>>
>> I would like a test suite in the GeoAPI project, if we can write it=20
>> abstract enough so that it doesn't contains any explicit reference to=20
>> any implementation.
>>
>> If we can find volunter time, we may try to move some Geotools tests=20
>> from the referencing module (at least the parts that do not involve=20
>> any geotools-specific API) as a proof of concept.
>>
>>
>>> See page:
>>> http://docs.codehaus.org/display/GEOTOOLS/Test+Plan+for+JTS+Geometry
>>
>>
>>
>> Thanks for that page. Its look like it could apply to other module=20
>> like CRS also.
>>
>>     Martin.
>>
>>
>> -------------------------------------------------------
>> All the advantages of Linux Managed Hosting--Without the Cost and Risk=
!
>> Fully trained technicians. The highest number of Red Hat=20
>> certifications in
>> the hosting industry. Fanatical Support. Click to learn more
>> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=107521&bid$8729&dat=1216=
42
>> _______________________________________________
>> Geotools-devel mailing list
>> Geotools-devel@...
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>

GeoTools, the Java GIS toolkit

Email Archive: geotools-devel (read-only)