[Geoserver-devel] WCS Bugs in 1.5.0 Beta 1

Edward_Nash · January 8, 2007, 1:40pm

Hi list,

just been having a play with the WCS and getting a couple of "interesting" results back (apart from these then it's all looking a very impressive piece of work!)

1: The result of this KVP request (attached a.tif):

http://localhost:8080/geoserver/wcs?service=WCS&request=GetCoverage&Version=1.0.0&coverage=nurc:Arc_Sample&crs=EPSG:4326&&response_crs=EPSG:32626&bbox=9.420000076293944,11.819999694824217,42.20000076293945,43.90000049273173&width=120&height=85&format=GEOTIFF

is different to the result of the example XML GetCoverage request with GEOTIFF instead of TIFF (attached b.tif):
<GetCoverage service="WCS" version="1.0.0"
   xmlns="http://www.opengis.net/wcs"
   xmlns:nurc="http://www.nurc.nato.int"
   xmlns:ogc="http://www.opengis.net/ogc"
   xmlns:gml="http://www.opengis.net/gml"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.opengis.net/wcs http://schemas.opengis.net/wcs/1.0.0/getCoverage.xsd">
  <sourceCoverage>nurc:Arc_Sample</sourceCoverage>
  <domainSubset>
    <spatialSubset>
      <gml:Envelope srsName="EPSG:4326">
        <gml:pos>9.420000076293944 42.20000076293945</gml:pos>
                 <gml:pos>11.819999694824217 43.90000049273173</gml:pos>
      </gml:Envelope>
      <gml:Grid dimension="2" srsName="EPSG:4326">
        <gml:limits>
          <gml:GridEnvelope>
            <gml:low>0 0</gml:low>
                         <gml:high>120 85</gml:high>
          </gml:GridEnvelope>
        </gml:limits>
      </gml:Grid>
    </spatialSubset>
  </domainSubset>
  <rangeSubset>
    <axisSubset name="Band">
      <singleValue>1</singleValue>
    </axisSubset>
  </rangeSubset>
  <output>
      <crs>EPSG:4326</crs>
      <responseCrs>EPSG:32626</responseCrs>
    <format>GEOTIFF</format>
  </output>
</GetCoverage>

from my reading of the WCS spec then these two requests should be identical (making other KVP requests has also delivered strange, and usually very small results similar to a.tif). It is of course possible that I've misread the spec - in which case can anyone correct my KVP request?

2: According to the spec then response_crs is an optional parameter - if it is missing then the crs-parameter will be used. If I omit response_crs I however get an exception that the requested response_crs is unsupported.

Thanks again for a nice piece of software, and in advance to any responses!

Cheers,

Ed

--
preagro TP7 - Geodateninfrastruktur
http://www.preagro.de

Universität Rostock
Agrar- und Umweltwissenschaftliche Fakultät
Professur für Geodäsie und Geoinformatik
Justus-von-Liebig-Weg 6
18059 Rostock

Tel: +49 381 498 2164
Fax: +49 381 498 2188
Web: http://www.auf.uni-rostok.de/gg

(attachments)

b.tif (18.7 KB)
a.tif (1.29 KB)

Alessio_Fabiani · January 9, 2007, 11:10am

Dear Dr. Edward Nash,

thank you very much for your feedbacks. Actually we have very few of them from users, while they are really useful for our work.

I’ll check those problems to see if there are errors on WCS and, eventually, how to fix them. I’ll reply to you as soon as possible.

Kind regards,
Alessio.

On 1/8/07, Edward Nash <edward.nash@anonymised.com> wrote:

Hi list,

just been having a play with the WCS and getting a couple of
“interesting” results back (apart from these then it’s all looking a
very impressive piece of work!)

1: The result of this KVP request (attached a.tif):

http://localhost:8080/geoserver/wcs?service=WCS&request=GetCoverage&Version=1.0.0&coverage=nurc:Arc_Sample&crs=EPSG:4326&&response_crs=EPSG:32626&bbox=9.420000076293944,11.819999694824217,42.20000076293945,43.90000049273173&width=120&height=85&format=GEOTIFF

is different to the result of the example XML GetCoverage request with
GEOTIFF instead of TIFF (attached b.tif):

nurc:Arc_Sample

<gml:Envelope srsName=“EPSG:4326”>
gml:pos9.420000076293944 42.20000076293945</gml:pos>
gml:pos11.819999694824217 43.90000049273173</gml:pos>
</gml:Envelope>
<gml:Grid dimension=“2” srsName=“EPSG:4326”>
gml:limits
gml:GridEnvelope
gml:low0 0</gml:low>
gml:high120 85</gml:high>
</gml:GridEnvelope>
</gml:limits>
</gml:Grid>

1

EPSG:4326
EPSG:32626
GEOTIFF

from my reading of the WCS spec then these two requests should be
identical (making other KVP requests has also delivered strange, and
usually very small results similar to a.tif). It is of course possible
that I’ve misread the spec - in which case can anyone correct my KVP
request?

2: According to the spec then response_crs is an optional parameter - if
it is missing then the crs-parameter will be used. If I omit
response_crs I however get an exception that the requested response_crs
is unsupported.

Thanks again for a nice piece of software, and in advance to any responses!

Cheers,

Ed

–
preagro TP7 - Geodateninfrastruktur
http://www.preagro.de

Universität Rostock
Agrar- und Umweltwissenschaftliche Fakultät
Professur für Geodäsie und Geoinformatik
Justus-von-Liebig-Weg 6
18059 Rostock

Tel: +49 381 498 2164
Fax: +49 381 498 2188
Web: http://www.auf.uni-rostok.de/gg

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 surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it

Alessio_Fabiani · January 12, 2007, 5:08pm

Dear Dr. Edward,

I checked your problems, and I noticed as follows:

1 - Your KVP request is wrong, the right one should be
http://localhost:8080/geoserver/wcs?service=WCS&request=GetCoverage&Version=1.0.0&coverage=nurc:Arc_Sample&crs=EPSG:4326&response_crs=EPSG:32626&bbox=9.420000076293944,42.20000076293945,11.819999694824217,43.90000049273173&width=120&height=85&format=GEOTIFF

NOTE: Make sure to start your Web Container with the Java option -Dorg.geotools.referencing.forceXY=true

2 - I tried to remove the responsecrs parameter and all works fine on my side, the crs is considered as default.

NOTE: is it possible for you compile the GeoServer version on 1.5.x SVN branch? A lot of bugfixes have been committed there recently.
https://svn.codehaus.org/geoserver/branches/1.5.x

Let me know of your progresses and tryes.

On 1/8/07, Edward Nash <edward.nash@anonymised.com> wrote:

Hi list,

just been having a play with the WCS and getting a couple of
“interesting” results back (apart from these then it’s all looking a
very impressive piece of work!)

1: The result of this KVP request (attached a.tif):

http://localhost:8080/geoserver/wcs?service=WCS&request=GetCoverage&Version=1.0.0&coverage=nurc:Arc_Sample&crs=EPSG:4326&&response_crs=EPSG:32626&bbox=9.420000076293944,11.819999694824217,42.20000076293945,43.90000049273173&width=120&height=85&format=GEOTIFF

is different to the result of the example XML GetCoverage request with
GEOTIFF instead of TIFF (attached b.tif):

nurc:Arc_Sample

<gml:Envelope srsName=“EPSG:4326”>
gml:pos9.420000076293944 42.20000076293945</gml:pos>
gml:pos11.819999694824217 43.90000049273173</gml:pos>
</gml:Envelope>
<gml:Grid dimension=“2” srsName=“EPSG:4326”>
gml:limits
gml:GridEnvelope
gml:low0 0</gml:low>
gml:high120 85</gml:high>
</gml:GridEnvelope>
</gml:limits>
</gml:Grid>

1

EPSG:4326
EPSG:32626
GEOTIFF

from my reading of the WCS spec then these two requests should be
identical (making other KVP requests has also delivered strange, and
usually very small results similar to a.tif). It is of course possible
that I’ve misread the spec - in which case can anyone correct my KVP
request?

2: According to the spec then response_crs is an optional parameter - if
it is missing then the crs-parameter will be used. If I omit
response_crs I however get an exception that the requested response_crs
is unsupported.

Thanks again for a nice piece of software, and in advance to any responses!

Cheers,

Ed

–
preagro TP7 - Geodateninfrastruktur
http://www.preagro.de

Universität Rostock
Agrar- und Umweltwissenschaftliche Fakultät
Professur für Geodäsie und Geoinformatik
Justus-von-Liebig-Weg 6
18059 Rostock

Tel: +49 381 498 2164
Fax: +49 381 498 2188
Web: http://www.auf.uni-rostok.de/gg

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 surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it

Chris_Holmes1 · January 12, 2007, 5:11pm

NOTE: is it possible for you compile the GeoServer version on 1.5.x SVN branch? A lot of bugfixes have been committed there recently.
https://svn.codehaus.org/geoserver/branches/1.5.x

Should we put out a beta2 release? Generally it's worthwhile if we get to the point where we're wanting people to use SVN so we're sure they're not testing things we've already fixed.

Chris

Let me know of your progresses and tryes.

On 1/8/07, *Edward Nash* <edward.nash@anonymised.com <mailto:edward.nash@anonymised.com>> wrote:

    Hi list,

    just been having a play with the WCS and getting a couple of
    "interesting" results back (apart from these then it's all looking a
    very impressive piece of work!)

    1: The result of this KVP request (attached a.tif):

    http://localhost:8080/geoserver/wcs?service=WCS&request=GetCoverage&Version=1.0.0&coverage=nurc:Arc_Sample&crs=EPSG:4326&&response_crs=EPSG:32626&bbox=9.420000076293944,11.819999694824217,42.20000076293945,43.90000049273173&width=120&height=85&format=GEOTIFF
    <http://localhost:8080/geoserver/wcs?service=WCS&request=GetCoverage&Version=1.0.0&coverage=nurc:Arc_Sample&crs=EPSG:4326&&response_crs=EPSG:32626&bbox=9.420000076293944,11.819999694824217,42.20000076293945,43.90000049273173&width=120&height=85&format=GEOTIFF>

    is different to the result of the example XML GetCoverage request with
    GEOTIFF instead of TIFF (attached b.tif):
    <GetCoverage service="WCS" version="1.0.0"
       xmlns=" http://www.opengis.net/wcs"
       xmlns:nurc="http://www.nurc.nato.int"
       xmlns:ogc="http://www.opengis.net/ogc"
       xmlns:gml="http://www.opengis.net/gml"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.opengis.net/wcs
    http://schemas.opengis.net/wcs/1.0.0/getCoverage.xsd ">
            <sourceCoverage>nurc:Arc_Sample</sourceCoverage>
            <domainSubset>
                    <spatialSubset>
                            <gml:Envelope srsName="EPSG:4326">
                                    <gml:pos>9.420000076293944
    42.20000076293945</gml:pos>
                     <gml:pos>11.819999694824217 43.90000049273173</gml:pos>
                            </gml:Envelope>
                            <gml:Grid dimension="2" srsName="EPSG:4326">
                                    <gml:limits>
                                            <gml:GridEnvelope>
                                                    <gml:low>0 0</gml:low>
                             <gml:high>120 85</gml:high>
                                            </gml:GridEnvelope>
                                    </gml:limits>
                            </gml:Grid>
                    </spatialSubset>
            </domainSubset>
            <rangeSubset>
                    <axisSubset name="Band">
                            <singleValue>1</singleValue>
                    </axisSubset>
            </rangeSubset>
            <output>
                <crs>EPSG:4326</crs>
                <responseCrs>EPSG:32626</responseCrs>
                    <format>GEOTIFF</format>
            </output>
    </GetCoverage>

    from my reading of the WCS spec then these two requests should be
    identical (making other KVP requests has also delivered strange, and
    usually very small results similar to a.tif). It is of course possible
    that I've misread the spec - in which case can anyone correct my KVP
    request?

    2: According to the spec then response_crs is an optional parameter - if
    it is missing then the crs-parameter will be used. If I omit
    response_crs I however get an exception that the requested response_crs
    is unsupported.

    Thanks again for a nice piece of software, and in advance to any
    responses!

    Cheers,

    Ed

    --
    preagro TP7 - Geodateninfrastruktur
    http://www.preagro.de

    Universität Rostock
    Agrar- und Umweltwissenschaftliche Fakultät
    Professur für Geodäsie und Geoinformatik
    Justus-von-Liebig-Weg 6
    18059 Rostock

    Tel: +49 381 498 2164
    Fax: +49 381 498 2188
    Web: http://www.auf.uni-rostok.de/gg

    -------------------------------------------------------------------------

    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 surveys - and earn cash
    http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
    <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>

    _______________________________________________
    Geoserver-devel mailing list
    Geoserver-devel@lists.sourceforge.net
    <mailto:Geoserver-devel@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/geoserver-devel
    <https://lists.sourceforge.net/lists/listinfo/geoserver-devel>

--
-------------------------------------------------------
Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it

--------------------------------------------------------- !DSPAM:1003,45a7c1b2296551665516417!

------------------------------------------------------------------------

-------------------------------------------------------------------------
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 surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

!DSPAM:1003,45a7c1b2296551665516417!

------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1003,45a7c1b2296551665516417!

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

jive · January 12, 2007, 6:08pm

Chris putting out a beta2 would be *great* from my standpoint; I would much rather perform an evaluation on a beta2 (then a war I produced on my own). I have enough fun with svn trying to get the OWS4 branch to go.

Cheers,
Jody

NOTE: is it possible for you compile the GeoServer version on 1.5.x SVN branch? A lot of bugfixes have been committed there recently.
https://svn.codehaus.org/geoserver/branches/1.5.x

Should we put out a beta2 release? Generally it's worthwhile if we get to the point where we're wanting people to use SVN so we're sure they're not testing things we've already fixed.

Chris

Let me know of your progresses and tryes.

On 1/8/07, *Edward Nash* <edward.nash@anonymised.com <mailto:edward.nash@anonymised.com>> wrote:

    Hi list,

    just been having a play with the WCS and getting a couple of
    "interesting" results back (apart from these then it's all looking a
    very impressive piece of work!)

    1: The result of this KVP request (attached a.tif):

    http://localhost:8080/geoserver/wcs?service=WCS&request=GetCoverage&Version=1.0.0&coverage=nurc:Arc_Sample&crs=EPSG:4326&&response_crs=EPSG:32626&bbox=9.420000076293944,11.819999694824217,42.20000076293945,43.90000049273173&width=120&height=85&format=GEOTIFF

    <http://localhost:8080/geoserver/wcs?service=WCS&request=GetCoverage&Version=1.0.0&coverage=nurc:Arc_Sample&crs=EPSG:4326&&response_crs=EPSG:32626&bbox=9.420000076293944,11.819999694824217,42.20000076293945,43.90000049273173&width=120&height=85&format=GEOTIFF>

    is different to the result of the example XML GetCoverage request with
    GEOTIFF instead of TIFF (attached b.tif):
    <GetCoverage service="WCS" version="1.0.0"
       xmlns=" http://www.opengis.net/wcs"
       xmlns:nurc="http://www.nurc.nato.int"
       xmlns:ogc="http://www.opengis.net/ogc"
       xmlns:gml="http://www.opengis.net/gml"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.opengis.net/wcs
    http://schemas.opengis.net/wcs/1.0.0/getCoverage.xsd ">
            <sourceCoverage>nurc:Arc_Sample</sourceCoverage>
            <domainSubset>
                    <spatialSubset>
                            <gml:Envelope srsName="EPSG:4326">
                                    <gml:pos>9.420000076293944
    42.20000076293945</gml:pos>
                     <gml:pos>11.819999694824217 43.90000049273173</gml:pos>
                            </gml:Envelope>
                            <gml:Grid dimension="2" srsName="EPSG:4326">
                                    <gml:limits>
                                            <gml:GridEnvelope>
                                                    <gml:low>0 0</gml:low>
                             <gml:high>120 85</gml:high>
                                            </gml:GridEnvelope>
                                    </gml:limits>
                            </gml:Grid>
                    </spatialSubset>
            </domainSubset>
            <rangeSubset>
                    <axisSubset name="Band">
                            <singleValue>1</singleValue>
                    </axisSubset>
            </rangeSubset>
            <output>
                <crs>EPSG:4326</crs>
                <responseCrs>EPSG:32626</responseCrs>
                    <format>GEOTIFF</format>
            </output>
    </GetCoverage>

    from my reading of the WCS spec then these two requests should be
    identical (making other KVP requests has also delivered strange, and
    usually very small results similar to a.tif). It is of course possible
    that I've misread the spec - in which case can anyone correct my KVP
    request?

    2: According to the spec then response_crs is an optional parameter - if
    it is missing then the crs-parameter will be used. If I omit
    response_crs I however get an exception that the requested response_crs
    is unsupported.

    Thanks again for a nice piece of software, and in advance to any
    responses!

    Cheers,

    Ed

    --
    preagro TP7 - Geodateninfrastruktur
    http://www.preagro.de

    Universität Rostock
    Agrar- und Umweltwissenschaftliche Fakultät
    Professur für Geodäsie und Geoinformatik
    Justus-von-Liebig-Weg 6
    18059 Rostock

    Tel: +49 381 498 2164
    Fax: +49 381 498 2188
    Web: http://www.auf.uni-rostok.de/gg

    -------------------------------------------------------------------------

    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 surveys - and earn cash
    http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

    <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>

    _______________________________________________
    Geoserver-devel mailing list
    Geoserver-devel@lists.sourceforge.net
    <mailto:Geoserver-devel@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/geoserver-devel
    <https://lists.sourceforge.net/lists/listinfo/geoserver-devel>

--
-------------------------------------------------------
Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it

--------------------------------------------------------- !DSPAM:1003,45a7c1b2296551665516417!

------------------------------------------------------------------------

-------------------------------------------------------------------------

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 surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

!DSPAM:1003,45a7c1b2296551665516417!

------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1003,45a7c1b2296551665516417!

-------------------------------------------------------------------------
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 surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Edward_Nash · January 15, 2007, 11:31am

Hi Alessio,

thanks for the reply.

Alessio Fabiani wrote:

I checked your problems, and I noticed as follows:

1 - Your KVP request is wrong, the right one should be
http://localhost:8080/geoserver/wcs?service=WCS&request=GetCoverage&Version=1.0.0&coverage=nurc:Arc_Sample&crs=EPSG:4326&response_crs=EPSG:32626&bbox=9.420000076293944,42.20000076293945,11.819999694824217,43.90000049273173&width=120&height=85&format=GEOTIFF

now I think your KVP request is wrong! According to the WCS spec, the coordinate order in the request is BBOX=minx, miny, maxx, maxy, minz, maxz (on p42 of the spec and p40 of the corrigendum). You've put them minx, maxx, miny, maxy (which to my mind makes more sense as well, particularly with optional z-values, but a spec is a spec!)

NOTE: Make sure to start your Web Container with the Java option -
Dorg.geotools.referencing.forceXY=true

2 - I tried to remove the responsecrs parameter and all works fine on my
side, the crs is considered as default.

I just tried again and it seems to be working fine for me as well (on 1.5.0 beta 1). I can't replicate the failure, it maybe had something to do with another parameter as well.

NOTE: is it possible for you compile the GeoServer version on 1.5.x SVN
branch? A lot of bugfixes have been committed there recently.
https://svn.codehaus.org/geoserver/branches/1.5.x

Let me know of your progresses and tryes.

On 1/8/07, Edward Nash <edward.nash@anonymised.com> wrote:

Hi list,

just been having a play with the WCS and getting a couple of
"interesting" results back (apart from these then it's all looking a
very impressive piece of work!)

1: The result of this KVP request (attached a.tif):

http://localhost:8080/geoserver/wcs?service=WCS&request=GetCoverage&Version=1.0.0&coverage=nurc:Arc_Sample&crs=EPSG:4326&&response_crs=EPSG:32626&bbox=9.420000076293944,11.819999694824217,42.20000076293945,43.90000049273173&width=120&height=85&format=GEOTIFF

is different to the result of the example XML GetCoverage request with
GEOTIFF instead of TIFF (attached b.tif):
<GetCoverage service="WCS" version="1.0.0"
   xmlns="http://www.opengis.net/wcs"
   xmlns:nurc="http://www.nurc.nato.int"
   xmlns:ogc="http://www.opengis.net/ogc"
   xmlns:gml="http://www.opengis.net/gml"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.opengis.net/wcs
http://schemas.opengis.net/wcs/1.0.0/getCoverage.xsd">
        <sourceCoverage>nurc:Arc_Sample</sourceCoverage>
        <domainSubset>
                <spatialSubset>
                        <gml:Envelope srsName="EPSG:4326">
                                <gml:pos>9.420000076293944
42.20000076293945</gml:pos>
                 <gml:pos>11.819999694824217 43.90000049273173</gml:pos>
                        </gml:Envelope>
                        <gml:Grid dimension="2" srsName="EPSG:4326">
                                <gml:limits>
                                        <gml:GridEnvelope>
                                                <gml:low>0 0</gml:low>
                         <gml:high>120 85</gml:high>
                                        </gml:GridEnvelope>
                                </gml:limits>
                        </gml:Grid>
                </spatialSubset>
        </domainSubset>
        <rangeSubset>
                <axisSubset name="Band">
                        <singleValue>1</singleValue>
                </axisSubset>
        </rangeSubset>
        <output>
            <crs>EPSG:4326</crs>
            <responseCrs>EPSG:32626</responseCrs>
                <format>GEOTIFF</format>
        </output>
</GetCoverage>

from my reading of the WCS spec then these two requests should be
identical (making other KVP requests has also delivered strange, and
usually very small results similar to a.tif). It is of course possible
that I've misread the spec - in which case can anyone correct my KVP
request?

2: According to the spec then response_crs is an optional parameter - if
it is missing then the crs-parameter will be used. If I omit
response_crs I however get an exception that the requested response_crs
is unsupported.

Thanks again for a nice piece of software, and in advance to any
responses!

Cheers,

Ed

Alessio_Fabiani · January 15, 2007, 1:57pm

Hi Ed,

I don’t understand your reply … on my request (bbox=9.420000076293944,42.20000076293945,11.819999694824217,43.90000049273173) I’ve put minx,miny,maxx,maxy as for the WCS specs. Can you be more explicit?

On 1/15/07, Edward Nash <edward.nash@anonymised.com> wrote:

Hi Alessio,

thanks for the reply.

Alessio Fabiani wrote:

I checked your problems, and I noticed as follows:

1 - Your KVP request is wrong, the right one should be
http://localhost:8080/geoserver/wcs?service=WCS&request=GetCoverage&Version=1.0.0&coverage=nurc:Arc_Sample&crs=EPSG:4326&response_crs=EPSG:32626&bbox=9.420000076293944,42.20000076293945,11.819999694824217,43.90000049273173&width=120&height=85&format=GEOTIFF

now I think your KVP request is wrong! According to the WCS spec, the
coordinate order in the request is BBOX=minx, miny, maxx, maxy, minz,
maxz (on p42 of the spec and p40 of the corrigendum). You’ve put them
minx, maxx, miny, maxy (which to my mind makes more sense as well,
particularly with optional z-values, but a spec is a spec!)

NOTE: Make sure to start your Web Container with the Java option -
Dorg.geotools.referencing.forceXY=true

2 - I tried to remove the responsecrs parameter and all works fine on my
side, the crs is considered as default.

I just tried again and it seems to be working fine for me as well (on
1.5.0 beta 1). I can’t replicate the failure, it maybe had something to
do with another parameter as well.

NOTE: is it possible for you compile the GeoServer version on 1.5.x SVN
branch? A lot of bugfixes have been committed there recently.
https://svn.codehaus.org/geoserver/branches/1.5.x

Let me know of your progresses and tryes.

On 1/8/07, Edward Nash < edward.nash@anonymised.com> wrote:

Hi list,

just been having a play with the WCS and getting a couple of
“interesting” results back (apart from these then it’s all looking a
very impressive piece of work!)

1: The result of this KVP request (attached a.tif):

http://localhost:8080/geoserver/wcs?service=WCS&request=GetCoverage&Version=1.0.0&coverage=nurc:Arc_Sample&crs=EPSG:4326&&response_crs=EPSG:32626&bbox=9.420000076293944,11.819999694824217,42.20000076293945,43.90000049273173&width=120&height=85&format=GEOTIFF

is different to the result of the example XML GetCoverage request with
GEOTIFF instead of TIFF (attached b.tif):

nurc:Arc_Sample

<gml:Envelope srsName=“EPSG:4326”>
gml:pos9.420000076293944
42.20000076293945</gml:pos>
gml:pos 11.819999694824217 43.90000049273173</gml:pos>
</gml:Envelope>
<gml:Grid dimension=“2” srsName=“EPSG:4326”>
gml:limits
gml:GridEnvelope
gml:low0 0</gml:low>
gml:high120 85</gml:high>
</gml:GridEnvelope>
</gml:limits>
</gml:Grid>

1

EPSG:4326
EPSG:32626
GEOTIFF

from my reading of the WCS spec then these two requests should be
identical (making other KVP requests has also delivered strange, and
usually very small results similar to a.tif). It is of course possible
that I’ve misread the spec - in which case can anyone correct my KVP
request?

2: According to the spec then response_crs is an optional parameter - if
it is missing then the crs-parameter will be used. If I omit
response_crs I however get an exception that the requested response_crs
is unsupported.

Thanks again for a nice piece of software, and in advance to any
responses!

Cheers,

Ed

–

Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it

Edward_Nash · January 15, 2007, 2:17pm

Hi Alessio,

sorry for being a time-waster - I've just realised that your request is indeed right! (I blame specification-induced dyslexia).

I still don't understand why the very small (10x5 pixel) file is returned in response to the 'wrong' requestt though: surely the width & height requested should be respected even if it means sending back lots of "nothing" with just a bit of a few pixels of useful data somewhere in there.

Thanks again,

Ed

Alessio Fabiani wrote:

Hi Ed,

I don't understand your reply ... on my request (bbox=9.420000076293944,
42.20000076293945,11.819999694824217,43.90000049273173) I've put
minx,miny,maxx,maxy as for the WCS specs. Can you be more explicit?

On 1/15/07, Edward Nash <edward.nash@anonymised.com> wrote:

Hi Alessio,

thanks for the reply.

Alessio Fabiani wrote:
> I checked your problems, and I noticed as follows:
>
> 1 - Your KVP request is wrong, the right one should be
>
http://localhost:8080/geoserver/wcs?service=WCS&request=GetCoverage&Version=1.0.0&coverage=nurc:Arc_Sample&crs=EPSG:4326&response_crs=EPSG:32626&bbox=9.420000076293944,42.20000076293945,11.819999694824217,43.90000049273173&width=120&height=85&format=GEOTIFF

>

now I think your KVP request is wrong! According to the WCS spec, the
coordinate order in the request is BBOX=minx, miny, maxx, maxy, minz,
maxz (on p42 of the spec and p40 of the corrigendum). You've put them
minx, maxx, miny, maxy (which to my mind makes more sense as well,
particularly with optional z-values, but a spec is a spec!)

> NOTE: Make sure to start your Web Container with the Java option -
> Dorg.geotools.referencing.forceXY=true
>
> 2 - I tried to remove the responsecrs parameter and all works fine on my
> side, the crs is considered as default.
>

I just tried again and it seems to be working fine for me as well (on
1.5.0 beta 1). I can't replicate the failure, it maybe had something to
do with another parameter as well.

> NOTE: is it possible for you compile the GeoServer version on 1.5.x SVN
> branch? A lot of bugfixes have been committed there recently.
> https://svn.codehaus.org/geoserver/branches/1.5.x
>
> Let me know of your progresses and tryes.
>
> On 1/8/07, Edward Nash <edward.nash@anonymised.com> wrote:
>>
>> Hi list,
>>
>> just been having a play with the WCS and getting a couple of
>> "interesting" results back (apart from these then it's all looking a
>> very impressive piece of work!)
>>
>> 1: The result of this KVP request (attached a.tif):
>>
http://localhost:8080/geoserver/wcs?service=WCS&request=GetCoverage&Version=1.0.0&coverage=nurc:Arc_Sample&crs=EPSG:4326&&response_crs=EPSG:32626&bbox=9.420000076293944,11.819999694824217,42.20000076293945,43.90000049273173&width=120&height=85&format=GEOTIFF

>>
>> is different to the result of the example XML GetCoverage request with
>> GEOTIFF instead of TIFF (attached b.tif):
>> <GetCoverage service="WCS" version="1.0.0"
>> xmlns="http://www.opengis.net/wcs"
>> xmlns:nurc="http://www.nurc.nato.int"
>> xmlns:ogc="http://www.opengis.net/ogc"
>> xmlns:gml="http://www.opengis.net/gml"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="http://www.opengis.net/wcs
>> http://schemas.opengis.net/wcs/1.0.0/getCoverage.xsd">
>> <sourceCoverage>nurc:Arc_Sample</sourceCoverage>
>> <domainSubset>
>> <spatialSubset>
>> <gml:Envelope srsName="EPSG:4326">
>> <gml:pos>9.420000076293944
>> 42.20000076293945</gml:pos>
>> <gml:pos>11.819999694824217 43.90000049273173
</gml:pos>
>> </gml:Envelope>
>> <gml:Grid dimension="2" srsName="EPSG:4326">
>> <gml:limits>
>> <gml:GridEnvelope>
>> <gml:low>0 0</gml:low>
>> <gml:high>120 85</gml:high>
>> </gml:GridEnvelope>
>> </gml:limits>
>> </gml:Grid>
>> </spatialSubset>
>> </domainSubset>
>> <rangeSubset>
>> <axisSubset name="Band">
>> <singleValue>1</singleValue>
>> </axisSubset>
>> </rangeSubset>
>> <output>
>> <crs>EPSG:4326</crs>
>> <responseCrs>EPSG:32626</responseCrs>
>> <format>GEOTIFF</format>
>> </output>
>> </GetCoverage>
>>
>> from my reading of the WCS spec then these two requests should be
>> identical (making other KVP requests has also delivered strange, and
>> usually very small results similar to a.tif). It is of course possible
>> that I've misread the spec - in which case can anyone correct my KVP
>> request?
>>
>> 2: According to the spec then response_crs is an optional parameter -
if
>> it is missing then the crs-parameter will be used. If I omit
>> response_crs I however get an exception that the requested response_crs
>> is unsupported.
>>
>> Thanks again for a nice piece of software, and in advance to any
>> responses!
>>
>> Cheers,
>>
>> Ed

Alessio_Fabiani · January 15, 2007, 2:24pm

I don’t understand that too … on my version here I got an error if the bbox is wrong … however, GeoServer heavily depends on the below GeoTools jars … in most cases the GeoServer behaviour is different just because of the below libraries.

Anyway, as Jody said, I think that we could release a GeoServer 1.5.0-beta2 soon.

On 1/15/07, Edward Nash <edward.nash@anonymised.com> wrote:

Hi Alessio,

sorry for being a time-waster - I’ve just realised that your request is
indeed right! (I blame specification-induced dyslexia).

I still don’t understand why the very small (10x5 pixel) file is
returned in response to the ‘wrong’ requestt though: surely the width &
height requested should be respected even if it means sending back lots
of “nothing” with just a bit of a few pixels of useful data somewhere in
there.

Thanks again,

Ed

Alessio Fabiani wrote:

Hi Ed,

I don’t understand your reply … on my request (bbox= 9.420000076293944,
42.20000076293945,11.819999694824217,43.90000049273173) I’ve put
minx,miny,maxx,maxy as for the WCS specs. Can you be more explicit?

On 1/15/07, Edward Nash < edward.nash@anonymised.com> wrote:

Hi Alessio,

thanks for the reply.

Alessio Fabiani wrote:

I checked your problems, and I noticed as follows:

1 - Your KVP request is wrong, the right one should be

http://localhost:8080/geoserver/wcs?service=WCS&request=GetCoverage&Version=1.0.0&coverage=nurc:Arc_Sample&crs=EPSG:4326&response_crs=EPSG:32626&bbox=9.420000076293944,42.20000076293945,11.819999694824217,43.90000049273173&width=120&height=85&format=GEOTIFF

now I think your KVP request is wrong! According to the WCS spec, the
coordinate order in the request is BBOX=minx, miny, maxx, maxy, minz,
maxz (on p42 of the spec and p40 of the corrigendum). You’ve put them
minx, maxx, miny, maxy (which to my mind makes more sense as well,
particularly with optional z-values, but a spec is a spec!)

NOTE: Make sure to start your Web Container with the Java option -
Dorg.geotools.referencing.forceXY=true

2 - I tried to remove the responsecrs parameter and all works fine
on my
side, the crs is considered as default.

I just tried again and it seems to be working fine for me as well (on
1.5.0 beta 1). I can’t replicate the failure, it maybe had something to
do with another parameter as well.

NOTE: is it possible for you compile the GeoServer version on 1.5.x SVN
branch? A lot of bugfixes have been committed there recently.
https://svn.codehaus.org/geoserver/branches/1.5.x

Let me know of your progresses and tryes.

On 1/8/07, Edward Nash < edward.nash@anonymised.com> wrote:

Hi list,

just been having a play with the WCS and getting a couple of
“interesting” results back (apart from these then it’s all looking a
very impressive piece of work!)

1: The result of this KVP request (attached a.tif):

http://localhost:8080/geoserver/wcs?service=WCS&request=GetCoverage&Version=1.0.0&coverage=nurc:Arc_Sample&crs=EPSG:4326&&response_crs=EPSG:32626&bbox=9.420000076293944,11.819999694824217,42.20000076293945,43.90000049273173&width=120&height=85&format=GEOTIFF

is different to the result of the example XML GetCoverage request with
GEOTIFF instead of TIFF (attached b.tif):

nurc:Arc_Sample

<gml:Envelope srsName=“EPSG:4326”>
gml:pos 9.420000076293944
42.20000076293945</gml:pos>
gml:pos11.819999694824217 43.90000049273173
</gml:pos>
</gml:Envelope>
<gml:Grid dimension=“2” srsName=“EPSG:4326”>
gml:limits
gml:GridEnvelope
gml:low0 0</gml:low>
gml:high120 85</gml:high>
</gml:GridEnvelope>
</gml:limits>
</gml:Grid>

1

EPSG:4326
EPSG:32626
GEOTIFF

from my reading of the WCS spec then these two requests should be
identical (making other KVP requests has also delivered strange, and
usually very small results similar to a.tif). It is of course possible
that I’ve misread the spec - in which case can anyone correct my KVP
request?

2: According to the spec then response_crs is an optional parameter -
if
it is missing then the crs-parameter will be used. If I omit
response_crs I however get an exception that the requested
response_crs
is unsupported.

Thanks again for a nice piece of software, and in advance to any
responses!

Cheers,

Ed

–

Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it