Martin,
I admit that is 1:30 am and my brain left me here alone a copule of
hours ago, but I am wondering if there is a way to force buffering the
creation of transformation between two crs by forcing geotools to use
the BufferedCoordinateOperationFactory class in methods like
CRS.transform or CRSU
Fine, at least I'm not getting crazy.
I tried your gdal_translate solution and in fact it works well.
There is only one problem, which I already noticed also with the world
image files. If I zoom in once or twice I get the following exception:
Error: One factory fails for the operation "Filtere
On 1/25/07, Jody Garnett <[EMAIL PROTECTED]> wrote:
> So we have been quite happy changing our process over the last four
> months; the developers guide has been updated to reflect this ... but a
> sanity check is needed.
>
> Can I ask anyone to review the following pages:
> - http://docs.codehaus.
Let's ping GeoTools, as I remember some discussions about such things there.
Do you have a longer stack trace at all? And what was the last release
candidate that was working for you?
thanks,
Chris
Stephen Crawford wrote:
All,
Well, it's happening again. This message writes to the logs,
So we have been quite happy changing our process over the last four
months; the developers guide has been updated to reflect this ... but a
sanity check is needed.
Can I ask anyone to review the following pages:
- http://docs.codehaus.org/display/GEOT/3+Module+Maintainers
- http://docs.codehaus.
Ciao guys,
sorry for crossposting and sorry for bothering.
I am here again asking you to vote on this issue:
https://jai-core.dev.java.net/issues/show_bug.cgi?id=85
which is bothering with the mosaic.
Thx a lot,
Simone.
--
---
Eng. Simone G
No problem Michael, this is a surprise to me too :). Glad it is working
for you. That was an easy one to fix ;).
-Justin
Michael Lutz wrote:
> Hi Justin and all,
>
> thanks again for the help on this. I'm afraid the error was lying on my
> side though. I just noticed that I hadn't included any
Hi Justin and all,
thanks again for the help on this. I'm afraid the error was lying on my
side though. I just noticed that I hadn't included any of the epsg
modules in my project (I'm never sure which of the many GT libs I really
need...). When I include gt2-epsg-wkt-2.4-SNAPSHOT.jar for examp
Thanks ... is adding this method enough for a change request? We are
taking on responsibility for new capability ... or can we just go
through Martin as the module maintainer.
I was under the impression that raw WKT was also allowed for an
element (although perhaps not for an SRS attribute).
Unfortunately, changing the GeoServer version is not so easy. I am
accessing our group's GeoServer WFS, so I have to live with version
1.3.0 (for now).
However, a local test with GeoServer 1.5 gave me the same result. It
also gives the srs name as
"http://www.opengis.net/gml/srs/epsg.xml#4326"
Handle srsName of the form http://www.opengis.net/gml/srs/epsg.xml#
-
Key: GEOT-1136
URL: http://jira.codehaus.org/browse/GEOT-1136
Project: GeoTools
Issue Type: Improve
Done.
http://jira.codehaus.org/browse/GEOT-1136
Martin Desruisseaux wrote:
> Le mercredi 24 janvier 2007 à 07:59 -0800, Justin Deoliveira a écrit :
>> We solved this before by implementing an adapter which wrapped the
>> normal EPSGProvider. I believe the same solution will work for this case.
>
Le mercredi 24 janvier 2007 à 07:59 -0800, Justin Deoliveira a écrit :
> We solved this before by implementing an adapter which wrapped the
> normal EPSGProvider. I believe the same solution will work for this case.
>
> > (...)
> >
> >
> >
> > http://www.opengis.net/gml/srs/epsg.x
They are already a vast improvement; if you need a reference point there
are some uDig installation instructions here. We made use of
{include:JRE} and {include:ImageIO} statements. Where JRE and ImageIO
pages only contain a link to the current version. Saves on updating content.
- http://udig.
Hi Michael,
Could you try a newer version (1.4, or 1.5) of GeoServer you will get
the srsName that the parser can handle.
-Justin
Michael Lutz wrote:
> I'm using GeoServer v1.3.0 and the GT sources from
> http://svn.geotools.org/geotools/trunk
>
> Cheers,
> Michael
>
> Andrea Aime wrote:
>>
Michael Lutz ha scritto:
> I'm using GeoServer v1.3.0 and the GT sources from
> http://svn.geotools.org/geotools/trunk
GeoServer 1.3.0 against geotools trunk? Erk...
May I ask why?
Cheers
Andrea
-
Take Surveys. Earn Cash. I
I'm using GeoServer v1.3.0 and the GT sources from
http://svn.geotools.org/geotools/trunk
Cheers,
Michael
Andrea Aime wrote:
> Michael Lutz ha scritto:
>> Hi,
>>
>> I just did a rebuild of geotools, and now it fails to parse geometries
>> with srsName="http://www.opengis.net/gml/srs/epsg.xml#42
Jody, be aware that they are still under construction. I want to mamek
them as precise as possible!
Simone.
On 1/24/07, Jody Garnett <[EMAIL PROTECTED]> wrote:
> I will try following them next install :-)
>
> Jody
>
--
---
Eng. Simone Gianne
Martin,
We solved this before by implementing an adapter which wrapped the
normal EPSGProvider. I believe the same solution will work for this case.
-Justin
Michael Lutz wrote:
> Hi,
>
> I just did a rebuild of geotools, and now it fails to parse geometries
> with srsName="http://www.opengis.
From the WFS 1.1 spec:
"Any valid URI value can be assigned to the srsName attribute. However,
in order to enhance interoperability, a web feature service must be able
to process srsName attribute values with the following format models:
- EPSG:
- http://www.opengis.net/gml/srs/epsg.xml#
- urn
I will try following them next install :-)
Jody
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief
We really need to provide:
CRS.fromSRS
CRS.toSRS
Their existing method "decode" is not intended to handle an Open Web
Service SRS element ... Michael do you think we can hunt down a range
of example SRS values for use with testing.
Jody
> Hi,
>
> I just did a rebuild of geotools, and now it fa
Michael Lutz ha scritto:
> Hi,
>
> I just did a rebuild of geotools, and now it fails to parse geometries
> with srsName="http://www.opengis.net/gml/srs/epsg.xml#4258"; (which I get
> from a GeoServer WFS), e.g.
H... which branch or geotools, which branch of Geoserver?
(the latter is needed
Andrea Aime wrote:
> [EMAIL PROTECTED] ha scritto:
>
>> Hi,
>>
>> I noticed that most (all?) of the coverage data sets in Geoserver 1.5.0 beta2
>> aren't working. If I use them to create a new coverage I get an exception
>> (see
>> below). For example, try creating a coverage that uses gtopo3
Hi,
I just did a rebuild of geotools, and now it fails to parse geometries
with srsName="http://www.opengis.net/gml/srs/epsg.xml#4258"; (which I get
from a GeoServer WFS), e.g.
(...)
http://www.opengis.net/gml/srs/epsg.xml#4258";>
(...)
I get th
Andrea, Simone,
I still don't have a solution, but I think I do have some hints
on what's happening. I've attached a working app (with the same
JAI initialization code used by Geoserver).
If I try to renderer the indexed file as is, I get an OOM.
If I create an alternate version that does not use
[EMAIL PROTECTED] ha scritto:
> Hi,
>
> I noticed that most (all?) of the coverage data sets in Geoserver 1.5.0 beta2
> aren't working. If I use them to create a new coverage I get an exception
> (see
> below). For example, try creating a coverage that uses gtopo30.
>
> Looks like a problem
Make axis comparison lenient vs axis names
--
Key: GEOT-1135
URL: http://jira.codehaus.org/browse/GEOT-1135
Project: GeoTools
Issue Type: Improvement
Components: core referencing
Affects
28 matches
Mail list logo
