Jody Garnett ha scritto:
> I think the rendering code also is willing to "force" the CRS specified
> as part of the Layer (there was some horrible code that did this last
> time I did a code review).
Well, horrible or not, that's necessary if you want to deal with broken
data.
> GeoServer could
I think the rendering code also is willing to "force" the CRS specified
as part of the Layer (there was some horrible code that did this last
time I did a code review).
GeoServer could also provide a "default" CRS to use in this case.
Jody
> Hi all,
> on Geoserver we're having issues with peopl
> * There is also a mysterious test failure in main (I don't remember
> which one exactly). This test pass fine with Java 4 and 5 but fails
> with Java 6. I have not investigated this issue further.
>
Oh, yes, I have a fix for that too, there were a number of them. They
stem from the fact that
Here it goes:
File tiffFile = new File(rasterPath);
WorldImageReader wiR = (WorldImageReader) ((new
WorldImageFormat()).getReader(tiffFile));
GridCoverage imgCov = null;
try {
imgCov = wiR.read(null);
} catch (Exception e) {
e.prin
Andrea Antonello ha scritto:
> Alright, I finally build the 2.3.x branch and tried to visualize the
> famous geotiff. After a very long while it goes out of heap space:
>
> Jan 23, 2007 6:57:56 PM org.geotools.renderer.lite.StreamingRenderer paint
> SEVERE: Java heap space
> java.lang.OutOfMemoryE
Hi all,
on Geoserver we're having issues with people with missing
or broken CRS definitions that make the StreamingRenderer choke.
The issue boils down to geometric attribute types not having
CRS info at all (null CRS). How we should handle these?
My take would be to spit out a warning, and then do
Alright, I finally build the 2.3.x branch and tried to visualize the
famous geotiff. After a very long while it goes out of heap space:
Jan 23, 2007 6:57:56 PM org.geotools.renderer.lite.StreamingRenderer paint
SEVERE: Java heap space
java.lang.OutOfMemoryError: Java heap space
at javax.m
Thanks Paul, you hit on a key issues. I know I myself have fallen into
the trap of focusing too much on code reuse, and not enough on
maintainability. While I agree with the fact that there is too much
attempt at reuse in our code, I would not want to throw out the concept
of reuse entirely. I
All,
After thrashing about for a while on developing our FDO provider
templating off of the MySQL provider, and using the Generic RDBMS
interfaces we have decided to take a new tack.
I am cc'ing this to Geotools, because deep in their designy hearts they
appear to still hold onto the same cor
Geotools do not compiles with Java 6. I already reported this issue a
few weeks ago. There is two problems:
* Introduction of new methods in javax.sql.DataSource. This is not the
first time that Sun introduces new methods in JDBC interfaces. It does
happen at every new JDBC release. Lets remin
> > For those that do not know JGrass at all, it is a GIS heavily dedicated to
> > hydrogeomorphologic issues. While it is very advanced in that field, we
> > have problems on everything regarding vectors (features) and in general
> > to keep uptodate the more generic GIS related base.
> >
> > Lo
On Tue, 2007-01-23 at 09:46 +0100, Antonello Andrea wrote:
> Hi list,
> I'm Andrea Antonello, coordinator of JGrass.
> For those that do not know JGrass at all, it is a GIS heavily dedicated to
> hydrogeomorphologic issues. While it is very advanced in that field, we
> have problems on everything
James Macgill ha scritto:
> So,
>
> I hit errors like this the other night when trying to build geotools
> for the first time in ages.
>
> For me it was the introduction of Wrapper in 1.6 (which uses
> generics).
Indeed you're right, it does not compile with java 6.
Hey, this means Sun decided
Same here.
Simone.
On 1/23/07, Vincent Schut <[EMAIL PROTECTED]> wrote:
> FYI: I just did my regular rebuild of gt 2.3.x branch, and everything
> built fine.
> This is with sun-jdk 1.5.0_10.
>
> Cheers,
> Vincent.
>
> James Macgill wrote:
> > So,
> >
> > I hit errors like this the other night whe
FYI: I just did my regular rebuild of gt 2.3.x branch, and everything
built fine.
This is with sun-jdk 1.5.0_10.
Cheers,
Vincent.
James Macgill wrote:
> So,
>
> I hit errors like this the other night when trying to build geotools
> for the first time in ages.
>
> For me it was the introduction o
So,
I hit errors like this the other night when trying to build geotools
for the first time in ages.
For me it was the introduction of Wrapper in 1.6 (which uses
generics). Building against a 1.4 classes archive is one option, the
other is to add the methods in the wrapper interface but using Ob
This is quite strange man, I just did a full mvn clean install and
everything worked for me here.
Does it work for you andrea?
Simone.
On 1/23/07, Cédric Briançon <[EMAIL PROTECTED]> wrote:
> Andrea Aime a écrit :
> > Cédric Briançon ha scritto:
> >> Simone Giannecchini a écrit :
> >
> C:\pr
Andrea Aime a écrit :
> Cédric Briançon ha scritto:
>> Simone Giannecchini a écrit :
>
C:\projets\geotools\branches\2.3.x\module\referencing\src\org\geotools\referenci
ng\factory\epsg\SimpleDataSource.java:[99,7]
org.geotools.referencing.factory.ep
sg.SimpleDataSourc
Cédric Briançon ha scritto:
> Simone Giannecchini a écrit :
>>> C:\projets\geotools\branches\2.3.x\module\referencing\src\org\geotools\referenci
>>>
>>>
>>> ng\factory\epsg\SimpleDataSource.java:[99,7]
>>> org.geotools.referencing.factory.ep
>>> sg.SimpleDataSource is not abstract and does not o
Simone Giannecchini a écrit :
> Ciao Cedric,
> did you update the whole tree of gt 2.3.x?
>
> Simone.
>
Yes, I have updated all my gt2.3.x directory. When I launch "mvn
install" from the root directory of branches/2.3.x, I fail on the
referencing module, so I have tried to build only the coverage
Ciao Cedric,
did you update the whole tree of gt 2.3.x?
Simone.
On 1/23/07, Cédric Briançon <[EMAIL PROTECTED]> wrote:
> Hello I've just updated my version of Geotools2.3.1, and the compilation
> breaks on coverage and referencing modules (the same for maven with
> jdk1.6 and 1.5.0_09). Here is t
Hello I've just updated my version of Geotools2.3.1, and the compilation
breaks on coverage and referencing modules (the same for maven with
jdk1.6 and 1.5.0_09). Here is the stack traces :
C:\projets\geotools\branches\2.3.x\module\coverage>mvn install
[INFO] Scanning for projects...
[INFO]
---
Hi,
>Just one little question: are you using the UTF-8 encoding on yours
>machine? Current encoding of Geotools code is ISO-LATIN-1, which is a
>cause of conversion troubles when edited in a UTF-8 editor. If it appear
>that UTF-8 is okay for a majority of developpers, we should probably
>switch Ge
Null vendor information in TextImageReader.SPI breaks classpath JAI
Key: GEOT-1134
URL: http://jira.codehaus.org/browse/GEOT-1134
Project: GeoTools
Issue Type: Bug
> >However the geotiff jar was build, so I tried to use it and here my
> >doubts and problems:
> >
> >- using the geotiff plugin approach gives me the same error as before
> >(geokey
> >directory), which I expected.
> >- the WorldImageReader uses the geotiff library, right? (it is obvious,
> >but
Andrea Antonello ha scritto:
>
> Hi Andrea, Simone,
> I need some help to get out of this (confusion of mine).
>
> I checked out the sources and tried the maven2 build. The build fails at
> some point with:
>
> /home/moovida/codeapisexes/geotools_svn/trunk/gt/modules/plugin/epsg-postgresql/src/m
Hi Andrea, Simone,
I need some help to get out of this (confusion of mine).
I checked out the sources and tried the maven2 build. The build fails at
some point with:
/home/moovida/codeapisexes/geotools_svn/trunk/gt/modules/plugin/epsg-postgresql/src/main/java/org/geotools/referencing/factory/ep
27 matches
Mail list logo
