[Geoserver-devel] First set of feedback about WCS

This section contains issues that a normal user can notice, that is,
external behavior of the WCS module, not code related.
1)Why data stores were renamed to FeatureDataSets?

2)Mixing data and configuration does not seem to be the best
situation... it would be nicer to allow people to refer data where they
are, and mimic the featureType folder instead. The coverageDataSet
configuration allows for data outside of the coverages dir, but then
creating the actual coverage does not work.

3)Creating a new CoverageDataSet lists descriptions, yet I guess people
would understand “Image + world file” better than “A raster file
accompanied by a spatial data file”, it would be nice to have both the
plugin id and description.

4)Adding a single file is as inconvenient as adding a shapefile
(requires two steps). Both should be one shot every time the bbox and
CRS can be determined out of the box. This is something that we may
should be doing with the new UI I guess.

5)WMS layers for coverages are non queryable. Well, in fact it would be
nice to be able an pick the value (or values) at that location. Worthy
improvement imho.

6)Gtopo30, describe feature curiosity: why is 0 reported as the null
value? The native null is -9999. The data store convert the value on the
fly to 0, but this should be just for the rendered coverage?

7)The GetCoverage demo request is invalid according to the schema,
misses the axis information (<gml:axisName>Lon</gml:axisName>
<gml:axisName>Lat</gml:axisName>)

8)GetCoverage ArcGrid -> ArcGrid does not work?
Caused by: java.io.IOException: The provided metadata are
illegal!CellSizeX!=CellSizeY.
  at
org.geotools.gce.imageio.asciigrid.AsciiGridsImageWriter.checkMetadata(AsciiGridsImageWriter.java:239)
  at
org.geotools.gce.imageio.asciigrid.AsciiGridsImageWriter.write(AsciiGridsImageWriter.java:144)
  at
org.geotools.gce.arcgrid.ArcGridWriter.writeGridCoverage(ArcGridWriter.java:361)
  ... 32 more
but the error message you get is: “Problems Rendering ImageIOError
writing”... does not help much the user to understand what went wrong.
Knowing that you cannot create an arcgrid file with different
resolutions would help more (the demo request has different x and y
resolutions indeed, the envelope requested is more or less 32° in both
width and height, but rows and cols are 120 and 85).

9)When returning a coverage in GIF or PNG format, what do you do? Render
it as a WMS using the default style?

10)It seems with GET request you can describe the grid either with
resolution or grid envelope, with POST the xml limits you to the grid
envelope? Anyways, it would be nice to have some GET style requests too.

11)This slightly modified GetCoverage request:

<!-- Performs a get coverage. Feel free to play with the elements,
    -->
<!-- to get different results.
    -->
<GetCoverage service="WCS" version="1.0.0"
   xmlns="http://www.opengis.net/wcs&quot;
   xmlns:nurc="http://www.nurc.nato.int"
   xmlns:ogc="http://www.opengis.net/ogc&quot;
   xmlns:gml="http://www.opengis.net/gml&quot;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
   xsi:schemaLocation="http://www.opengis.net/wcs
http://schemas.opengis.net/wcs/1.0.0/getCoverage.xsd&quot;&gt;
  <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.20000049273173</gml:pos>
      </gml:Envelope>
      <gml:Grid dimension="2" srsName="EPSG:4326">
        <gml:limits>
          <gml:GridEnvelope>
            <gml:low>0 0</gml:low>
                         <gml:high>120 120</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>TIFF</format>
  </output>
</GetCoverage>

provides quite a cryptic error message:
“java.lang.IllegalArgumentException: The operation name parameter may
not be null.”,

which is really related to a coding error afaik:

[AVVERTENZA] org.vfny.geoserver.wcs.WcsException - encountered error:
java.lang.IllegalArgumentException: The operation name parameter may notbe null.
org.vfny.geoserver.wcs.WcsException: java.lang.IllegalArgumentException:
The operation name parameter may not be null.
  at
org.vfny.geoserver.wcs.responses.CoverageResponse.execute(CoverageResponse.java:247)
  at
org.vfny.geoserver.wcs.responses.CoverageResponse.execute(CoverageResponse.java:191)
  at
org.vfny.geoserver.servlets.AbstractService.doService(AbstractService.java:535)
  at
org.vfny.geoserver.servlets.AbstractService.doPost(AbstractService.java:461)
  at org.geoserver.request.Dispatcher.post(Dispatcher.java:301)
  at org.geoserver.request.Dispatcher.dispatch(Dispatcher.java:185)
  at
org.geoserver.request.Dispatcher.handleRequestInternal(Dispatcher.java:58)
  at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:139)
  at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:44)
  at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:684)
  at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:625)
  at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:392)
  at
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:357)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
  at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1050)
  at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:122)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1041)
  at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:354)
  at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:226)
  at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:627)
  at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141)
  at org.mortbay.jetty.Server.handle(Server.java:269)
  at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:430)
  at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:701)
  at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:617)
  at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:199)
  at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339)
  at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:208)
  at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
Caused by: java.lang.IllegalArgumentException: The operation name
parameter may not be null.
  at javax.media.jai.JAI.createNS(JAI.java:1058)
  at
org.geotools.coverage.processing.operation.Resampler2D.reproject(Resampler2D.java:526)
  at
org.geotools.coverage.processing.operation.Resample.doOperation(Resample.java:201)
  at org.vfny.geoserver.util.WCSUtils.scale(WCSUtils.java:205)
  at
org.vfny.geoserver.wcs.responses.CoverageResponse.getFinalCoverage(CoverageResponse.java:430)
  at
org.vfny.geoserver.wcs.responses.CoverageResponse.execute(CoverageResponse.java:235)
  ... 30 more

Ah hem, I just tried to make the x/y resolution more or less equal?

Cheers
Andrea

Oh, btw, I also tried to load into WCS the following
sample Geotiff coverage:
ftp://ftp.remotesensing.org/pub/geotiff/samples/usgs/c41078a1.tif

and unfortunately what I get is the following error:

...
java.lang.UnsupportedOperationException: Unsupported revision
  at org.geotools.gce.geotiff.IIOMetadataAdpaters.GeoTiffIIOMetadataDecoder.<init>(GeoTiffIIOMetadataDecoder.java:130)
  at org.geotools.gce.geotiff.GeoTiffReader.getHRInfo(GeoTiffReader.java:257)
  at org.geotools.gce.geotiff.GeoTiffReader.<init>(GeoTiffReader.java:201)
  at org.geotools.gce.geotiff.GeoTiffFormat.getReader(GeoTiffFormat.java:252)
  at org.geotools.gce.geotiff.GeoTiffFormat.getReader(GeoTiffFormat.java:212)
  at org.vfny.geoserver.global.CoverageStoreInfo.getReader(CoverageStoreInfo.java:407)
  at org.vfny.geoserver.action.data.DataCoveragesNewAction.execute(DataCoveragesNewAction.java:94)
  at org.vfny.geoserver.action.ConfigAction.execute(ConfigAction.java:102)

Funny... how many revisions of the Geotiff standard are there?
Gdal handles it fine (that's not to say that we have to be as good
as GDAL, this won't happen overnight anyways).
Cheers
Andrea

...

Andrea Aime wrote:

This section contains issues that a normal user can notice, that is,
external behavior of the WCS module, not code related.
1)Why data stores were renamed to FeatureDataSets?
  

I'm looking at changing this. I would like all datasets to be called "DataStores" (for now), be it coverage or feature.
In the future I want something other than "DataStore" because to new users this means nothing. Maybe 'Data Locations' is better.

2)Mixing data and configuration does not seem to be the best
situation... it would be nicer to allow people to refer data where they
are, and mimic the featureType folder instead. The coverageDataSet
configuration allows for data outside of the coverages dir, but then
creating the actual coverage does not work.
  

This is also a change I would like to make before release. I think it might be possible to jump to a different "Type" editor depending whether it is a feature or a coverage. But it should be seamless.
We also need a common name to represent both types, maybe "DataSets" will work, but might be too similar to 'Data Location'.

3)Creating a new CoverageDataSet lists descriptions, yet I guess people
would understand “Image + world file” better than “A raster file
accompanied by a spatial data file”, it would be nice to have both the
plugin id and description.

4)Adding a single file is as inconvenient as adding a shapefile
(requires two steps). Both should be one shot every time the bbox and
CRS can be determined out of the box. This is something that we may
should be doing with the new UI I guess.
  

It would be a lot of work and I think is best saved for the new UI
+1 for moving new UI development up the priority list!

I would also like to add Simone's handy raster tools into the UI.

5)WMS layers for coverages are non queryable. Well, in fact it would be
nice to be able an pick the value (or values) at that location. Worthy
improvement imho.

6)Gtopo30, describe feature curiosity: why is 0 reported as the null
value? The native null is -9999. The data store convert the value on the
fly to 0, but this should be just for the rendered coverage?

7)The GetCoverage demo request is invalid according to the schema,
misses the axis information (<gml:axisName>Lon</gml:axisName>
<gml:axisName>Lat</gml:axisName>)

8)GetCoverage ArcGrid -> ArcGrid does not work?
Caused by: java.io.IOException: The provided metadata are
illegal!CellSizeX!=CellSizeY.
  at
org.geotools.gce.imageio.asciigrid.AsciiGridsImageWriter.checkMetadata(AsciiGridsImageWriter.java:239)
  at
org.geotools.gce.imageio.asciigrid.AsciiGridsImageWriter.write(AsciiGridsImageWriter.java:144)
  at
org.geotools.gce.arcgrid.ArcGridWriter.writeGridCoverage(ArcGridWriter.java:361)
  ... 32 more
but the error message you get is: “Problems Rendering ImageIOError
writing”... does not help much the user to understand what went wrong.
Knowing that you cannot create an arcgrid file with different
resolutions would help more (the demo request has different x and y
resolutions indeed, the envelope requested is more or less 32° in both
width and height, but rows and cols are 120 and 85).

9)When returning a coverage in GIF or PNG format, what do you do? Render
it as a WMS using the default style?

10)It seems with GET request you can describe the grid either with
resolution or grid envelope, with POST the xml limits you to the grid
envelope? Anyways, it would be nice to have some GET style requests too.

11)This slightly modified GetCoverage request:

<!-- Performs a get coverage. Feel free to play with the elements,
    -->
<!-- to get different results.
    -->
<GetCoverage service="WCS" version="1.0.0"
   xmlns="http://www.opengis.net/wcs&quot;
   xmlns:nurc="http://www.nurc.nato.int"
   xmlns:ogc="http://www.opengis.net/ogc&quot;
   xmlns:gml="http://www.opengis.net/gml&quot;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
   xsi:schemaLocation="http://www.opengis.net/wcs
http://schemas.opengis.net/wcs/1.0.0/getCoverage.xsd&quot;&gt;
  <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.20000049273173</gml:pos>
      </gml:Envelope>
      <gml:Grid dimension="2" srsName="EPSG:4326">
        <gml:limits>
          <gml:GridEnvelope>
            <gml:low>0 0</gml:low>
                         <gml:high>120 120</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>TIFF</format>
  </output>
</GetCoverage>

provides quite a cryptic error message:
“java.lang.IllegalArgumentException: The operation name parameter may
not be null.”,

which is really related to a coding error afaik:

[AVVERTENZA] org.vfny.geoserver.wcs.WcsException - encountered error:
java.lang.IllegalArgumentException: The operation name parameter may notbe null.
org.vfny.geoserver.wcs.WcsException: java.lang.IllegalArgumentException:
The operation name parameter may not be null.
  at
org.vfny.geoserver.wcs.responses.CoverageResponse.execute(CoverageResponse.java:247)
  at
org.vfny.geoserver.wcs.responses.CoverageResponse.execute(CoverageResponse.java:191)
  at
org.vfny.geoserver.servlets.AbstractService.doService(AbstractService.java:535)
  at
org.vfny.geoserver.servlets.AbstractService.doPost(AbstractService.java:461)
  at org.geoserver.request.Dispatcher.post(Dispatcher.java:301)
  at org.geoserver.request.Dispatcher.dispatch(Dispatcher.java:185)
  at
org.geoserver.request.Dispatcher.handleRequestInternal(Dispatcher.java:58)
  at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:139)
  at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:44)
  at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:684)
  at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:625)
  at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:392)
  at
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:357)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
  at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1050)
  at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:122)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1041)
  at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:354)
  at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:226)
  at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:627)
  at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141)
  at org.mortbay.jetty.Server.handle(Server.java:269)
  at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:430)
  at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:701)
  at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:617)
  at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:199)
  at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339)
  at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:208)
  at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
Caused by: java.lang.IllegalArgumentException: The operation name
parameter may not be null.
  at javax.media.jai.JAI.createNS(JAI.java:1058)
  at
org.geotools.coverage.processing.operation.Resampler2D.reproject(Resampler2D.java:526)
  at
org.geotools.coverage.processing.operation.Resample.doOperation(Resample.java:201)
  at org.vfny.geoserver.util.WCSUtils.scale(WCSUtils.java:205)
  at
org.vfny.geoserver.wcs.responses.CoverageResponse.getFinalCoverage(CoverageResponse.java:430)
  at
org.vfny.geoserver.wcs.responses.CoverageResponse.execute(CoverageResponse.java:235)
  ... 30 more

Ah hem, I just tried to make the x/y resolution more or less equal?

Cheers
Andrea

-------------------------------------------------------------------------
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
  
Brent Owens
(The Open Planning Project)

Ciao Andrea,
I tested this geotiff to understand
the reason for this failure.

This is maybe the first geotiff that declares a revision number that
is not 1.0 but 0. The actual implementation of geotiff package gets
pretty mad, as you noticed, if you do not declare 1 as revision
number.

As far as I know the only revision number around is 1. Anyway, for
sure I am not aware of any 0.0 revisions.

I am going to make the geotiff module a bit less restrictive when
parsing the revision number (I am cheating I already did it :slight_smile: and
the geotiff worked very well, it is a scanned map btw). because for
example gdal seems to just not care about it.

Simone.

Well the problem is that this geotiff declares to use
On 1/11/07, Andrea Aime <aaime@anonymised.com> wrote:

Oh, btw, I also tried to load into WCS the following
sample Geotiff coverage:
ftp://ftp.remotesensing.org/pub/geotiff/samples/usgs/c41078a1.tif

and unfortunately what I get is the following error:

...
java.lang.UnsupportedOperationException: Unsupported revision
       at
org.geotools.gce.geotiff.IIOMetadataAdpaters.GeoTiffIIOMetadataDecoder.<init>(GeoTiffIIOMetadataDecoder.java:130)
       at org.geotools.gce.geotiff.GeoTiffReader.getHRInfo(GeoTiffReader.java:257)
       at org.geotools.gce.geotiff.GeoTiffReader.<init>(GeoTiffReader.java:201)
       at org.geotools.gce.geotiff.GeoTiffFormat.getReader(GeoTiffFormat.java:252)
       at org.geotools.gce.geotiff.GeoTiffFormat.getReader(GeoTiffFormat.java:212)
       at
org.vfny.geoserver.global.CoverageStoreInfo.getReader(CoverageStoreInfo.java:407)
       at
org.vfny.geoserver.action.data.DataCoveragesNewAction.execute(DataCoveragesNewAction.java:94)
       at org.vfny.geoserver.action.ConfigAction.execute(ConfigAction.java:102)

Funny... how many revisions of the Geotiff standard are there?
Gdal handles it fine (that's not to say that we have to be as good
as GDAL, this won't happen overnight anyways).
Cheers
Andrea

-------------------------------------------------------------------------
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. Simone Giannecchini
President /CEO GeoSolutions

http://www.geo-solutions.it

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