[Geoserver-users] Image Mosaic JDBC single band raster losing data values

I'm trying to serve a single band raster from postgis though GeoServer using
the Image Mosaic JDBC plugin. In short I'm seeing an issue such that the
values in my single band are truncated to byte values between 0 and 255.
Additionally, what was a single band raster appears as 3 band when viewed
through GeoServer. My intention is to serve the raster such that I can
colorize it using an SLD in GeoServer for display through WMS and get data
points from the band through WCS. Further details follow.

I have setup my mosaic table in postgis as described here

http://docs.geotools.org/latest/userguide/library/coverage/pgraster.html

I insert the single band geotiff with Float32 data type as a single row in
to the table test using

raster2pgsql -s 4326 -I -C -M test.tif public.test | psql -d postgis -h
localhost -U postgres

and insert a value in the mosaic table with

insert into mosaic (name, tiletable) values ('test', 'test')

I can verify that the geotiff appears to be loaded into postgis properly by
running.

select st_numbands(rast) from test

to return the number of bands, this returns 1 as expected.

and running

select st_value(rast, 1, 50, 50) from test

to return the value at a specific point. This case returns
-7305.72021484375 which is an expected value

I have also verified that it appears to be a single band raster with data by
pulling the raster out of postgis using Quantum GIS and viewing the details
associated with it. I can apply color styles to the raster in Quantum GIS
and that works as expected.

I can also verify that GeoServer will serve the GeoTiff properly when
configured as a GeoTiff raster data store directly off the filesystem (not
going through postgis). It appears as a single band raster which I can
colorize with an SLD, everything works as expected.

When I try to load the raster into GeoServer from postgis as an
ImageMosaicJDBC raster data source, things go awry.

My config files are as such.

1. connect.pgraster.xml.inc

<connect>
  
  <dstype value="DBCP"/>
  
  <username value="postgres" />
  <password value="password1" />
  <jdbcUrl value="jdbc:postgresql://localhost:5432/postgis" />
  <driverClassName value="org.postgresql.Driver"/>
  <maxActive value="10"/>
  <maxIdle value="0"/>
</connect>

2. mapping.pgraster.xml.inc

<spatialExtension name="pgraster"/>
<mapping>
      <masterTable name="MOSAIC" >
              <coverageNameAttribute name="NAME"/>
              <maxXAttribute name="maxX"/>
              <maxYAttribute name="maxY"/>
              <minXAttribute name="minX"/>
              <minYAttribute name="minY"/>
              <resXAttribute name="resX"/>
              <resYAttribute name="resY"/>
              <tileTableNameAtribute name="TileTable" />
      </masterTable>
      <tileTable>
              <blobAttributeName name="rast" />
      </tileTable>
</mapping>

3. test.pgraster.xml.inc

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE ImageMosaicJDBCConfig [
      &lt;!ENTITY mapping PUBLIC &quot;mapping&quot;
&quot;mapping.pgraster.xml.inc&quot;>
      <!ENTITY connect PUBLIC &quot;connect&quot;
&quot;connect.pgraster.xml.inc&quot;>
]>

<config version="1.0">
      <coverageName name="test"/>
      <coordsys name="EPSG:4326"/>
      
      <scaleop interpolation="1"/>
      &mapping;
      &connect;
</config>

I can create the datasource and publish the layer all without error.
However, when I try to view the layer in GeoServer with the OpenLayers layer
preview I see a completely black and white image, not greyscale as expected.
Also, clicking a point in the image shows there are now 3 bands (test,
test_Band1, test_Band2) with values that appear to be either (0.0, 0.0, 0.0)
or (255.0, 255.0, 255.0). All of my data values appear to be lost.

If I issue a DescribeCoverage request against the WCS the range section
appears as such

<wcs:Range>
  <wcs:Field>
    <wcs:Identifier>contents</wcs:Identifier>
    <wcs:Definition>
      <ows:AllowedValues>
        <ows:Range>
          <ows:MinimumValue>0.0</ows:MinimumValue>
          <ows:MaximumValue>255.0</ows:MaximumValue>
        </ows:Range>
      </ows:AllowedValues>
    </wcs:Definition>
    <wcs:InterpolationMethods>
      <wcs:InterpolationMethod>linear</wcs:InterpolationMethod>
      <wcs:InterpolationMethod>cubic</wcs:InterpolationMethod>
    </wcs:InterpolationMethods>
    <wcs:Axis identifier="Bands">
      <wcs:AvailableKeys>
        <wcs:Key>test</wcs:Key>
        <wcs:Key>test</wcs:Key>
        <wcs:Key>test</wcs:Key>
      </wcs:AvailableKeys>
    </wcs:Axis>
  </wcs:Field>
</wcs:Range>

Does anyone know a reason why this would happen? Does the Image Mosaic JDBC
plugin only support 3 band images of Byte type? I'm running GeoServer
2.3.2, postgresql 9.2.4 and postgis 2.0.3. Let me know if I can provide any
additional details that might be helpful.

Thanks,

Mike

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Hi Mike

The plugin uses “as_tiff” when fetching raster data. If you do some test queries, include st_astiff. Example:

select st_numbands(st_astiff(rast)) from test

instead of

select st_numbands(rast) from test

Christian

···

2013/6/6 mrollans <mrollans@anonymised.com.>

I’m trying to serve a single band raster from postgis though GeoServer using
the Image Mosaic JDBC plugin. In short I’m seeing an issue such that the
values in my single band are truncated to byte values between 0 and 255.
Additionally, what was a single band raster appears as 3 band when viewed
through GeoServer. My intention is to serve the raster such that I can
colorize it using an SLD in GeoServer for display through WMS and get data
points from the band through WCS. Further details follow.

I have setup my mosaic table in postgis as described here

http://docs.geotools.org/latest/userguide/library/coverage/pgraster.html

I insert the single band geotiff with Float32 data type as a single row in
to the table test using

raster2pgsql -s 4326 -I -C -M test.tif public.test | psql -d postgis -h
localhost -U postgres

and insert a value in the mosaic table with

insert into mosaic (name, tiletable) values (‘test’, ‘test’)

I can verify that the geotiff appears to be loaded into postgis properly by
running.

select st_numbands(rast) from test

to return the number of bands, this returns 1 as expected.

and running

select st_value(rast, 1, 50, 50) from test

to return the value at a specific point. This case returns
-7305.72021484375 which is an expected value

I have also verified that it appears to be a single band raster with data by
pulling the raster out of postgis using Quantum GIS and viewing the details
associated with it. I can apply color styles to the raster in Quantum GIS
and that works as expected.

I can also verify that GeoServer will serve the GeoTiff properly when
configured as a GeoTiff raster data store directly off the filesystem (not
going through postgis). It appears as a single band raster which I can
colorize with an SLD, everything works as expected.

When I try to load the raster into GeoServer from postgis as an
ImageMosaicJDBC raster data source, things go awry.

My config files are as such.

  1. connect.pgraster.xml.inc
  1. mapping.pgraster.xml.inc
  1. test.pgraster.xml.inc
<?xml version="1.0" encoding="UTF-8" standalone="no"?>

]>

&mapping; &connect;

I can create the datasource and publish the layer all without error.
However, when I try to view the layer in GeoServer with the OpenLayers layer
preview I see a completely black and white image, not greyscale as expected.
Also, clicking a point in the image shows there are now 3 bands (test,
test_Band1, test_Band2) with values that appear to be either (0.0, 0.0, 0.0)
or (255.0, 255.0, 255.0). All of my data values appear to be lost.

If I issue a DescribeCoverage request against the WCS the range section
appears as such

wcs:Range
wcs:Field
wcs:Identifiercontents</wcs:Identifier>
wcs:Definition
ows:AllowedValues
ows:Range
ows:MinimumValue0.0</ows:MinimumValue>
ows:MaximumValue255.0</ows:MaximumValue>
</ows:Range>
</ows:AllowedValues>
</wcs:Definition>
wcs:InterpolationMethods
wcs:InterpolationMethodlinear</wcs:InterpolationMethod>
wcs:InterpolationMethodcubic</wcs:InterpolationMethod>
</wcs:InterpolationMethods>
<wcs:Axis identifier=“Bands”>
wcs:AvailableKeys
wcs:Keytest</wcs:Key>
wcs:Keytest</wcs:Key>
wcs:Keytest</wcs:Key>
</wcs:AvailableKeys>
</wcs:Axis>
</wcs:Field>
</wcs:Range>

Does anyone know a reason why this would happen? Does the Image Mosaic JDBC
plugin only support 3 band images of Byte type? I’m running GeoServer
2.3.2, postgresql 9.2.4 and postgis 2.0.3. Let me know if I can provide any
additional details that might be helpful.

Thanks,

Mike


View this message in context: http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549.html
Sent from the GeoServer - User mailing list archive at Nabble.com.


How ServiceNow helps IT people transform IT departments:

  1. A cloud service to automate IT design, transition and operations
  2. Dashboards that offer high-level views of enterprise services
  3. A single system of record for all IT processes
    http://p.sf.net/sfu/servicenow-d2d-j

Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

Hi Christian,

Thanks for the suggestion. I attempted what you said, but learned that
st_numbands expects a raster type not a bytea type as returned by st_astiff.

Running

select st_numbands(st_astiff(rast)) from test

in pgadmin returns

ERROR: function st_numbands(bytea) does not exist
LINE 1: select st_numbands(st_astiff(rast)) from test

If you know a way to make this work in some other way, let me know.

As an additional data point, I found something else that I think supports my
hypothesis that the plugin does not support bands of any type other than
8BUI or 16BUI. I attempted to create a store in the same way in my previous
email, except this time I used an older version of GeoServer and the Image
Mosaic JDBC plugin (2.1.4). When I attempt to create the store, I
immediately get the following stacktrace in the log.

10 Jun 13:53:15 ERROR [jdbc.custom] - ERROR: The pixel type of band 1 in the
raster is not 8BUI or 16BUI. The PNG format can only be used with 8BUI and
16BUI pixel types.
org.postgresql.util.PSQLException: ERROR: The pixel type of band 1 in the
raster is not 8BUI or 16BUI. The PNG format can only be used with 8BUI and
16BUI pixel types.
  at
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2062)
  at
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1795)
  at
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
  at
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:479)
  at
org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:367)
  at
org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:271)
  at
org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
  at
org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
  at
org.geotools.gce.imagemosaic.jdbc.custom.JDBCAccessPGRaster.startTileDecoders(JDBCAccessPGRaster.java:194)
  at
org.geotools.gce.imagemosaic.jdbc.ImageMosaicJDBCReader.loadTiles(ImageMosaicJDBCReader.java:460)
  at
org.geotools.gce.imagemosaic.jdbc.ImageMosaicJDBCReader.read(ImageMosaicJDBCReader.java:316)
  at
org.geoserver.catalog.CatalogBuilder.buildCoverage(CatalogBuilder.java:906)
  at
org.geoserver.catalog.CatalogBuilder.buildCoverage(CatalogBuilder.java:815)
  at
org.geoserver.web.data.layer.NewLayerPageProvider.getItemsInternal(NewLayerPageProvider.java:90)
  at
org.geoserver.web.data.layer.NewLayerPageProvider.getItems(NewLayerPageProvider.java:56)
  at
org.geoserver.web.wicket.GeoServerDataProvider.fullSize(GeoServerDataProvider.java:225)
  at
org.geoserver.web.wicket.GeoServerTablePanel$PagerDelegate.updateMatched(GeoServerTablePanel.java:519)
  at
org.geoserver.web.wicket.GeoServerTablePanel$PagerDelegate.<init>(GeoServerTablePanel.java:512)
  at
org.geoserver.web.wicket.GeoServerTablePanel.<init>(GeoServerTablePanel.java:200)
  at
org.geoserver.web.wicket.GeoServerTablePanel.<init>(GeoServerTablePanel.java:91)
  at
org.geoserver.web.data.layer.NewLayerPage$1.<init>(NewLayerPage.java:104)
  at org.geoserver.web.data.layer.NewLayerPage.<init>(NewLayerPage.java:104)
  at
org.geoserver.web.data.store.CoverageStoreNewPage.onSave(CoverageStoreNewPage.java:71)
  at
org.geoserver.web.data.store.AbstractCoverageStorePage$1.onSubmit(AbstractCoverageStorePage.java:114)
  at
org.apache.wicket.ajax.markup.html.form.AjaxSubmitLink$1.onSubmit(AjaxSubmitLink.java:68)
  at
org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:143)
  at
org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177)
  at
org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:300)
  at
org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:119)
  at
org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
  at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
  at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
  at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436)
  at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
  at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:484)
  at
org.apache.wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:160)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
  at
org.springframework.web.servlet.mvc.ServletWrappingController.handleRequestInternal(ServletWrappingController.java:158)
  at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
  at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
  at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
  at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
  at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
  at
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
  at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
  at
org.geoserver.filters.ThreadLocalsCleanupFilter.doFilter(ThreadLocalsCleanupFilter.java:23)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at
org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter(SpringDelegatingFilter.java:74)
  at
org.geoserver.filters.SpringDelegatingFilter.doFilter(SpringDelegatingFilter.java:45)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at
org.geoserver.platform.AdvancedDispatchFilter.doFilter(AdvancedDispatchFilter.java:49)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:394)
  at
org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
  at
org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
  at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
  at
org.springframework.security.ui.ExceptionTranslationFilter.doFilterHttp(ExceptionTranslationFilter.java:101)
  at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
  at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
  at
org.springframework.security.providers.anonymous.AnonymousProcessingFilter.doFilterHttp(AnonymousProcessingFilter.java:105)
  at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
  at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
  at
org.springframework.security.ui.rememberme.RememberMeProcessingFilter.doFilterHttp(RememberMeProcessingFilter.java:116)
  at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
  at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
  at
org.springframework.security.wrapper.SecurityContextHolderAwareRequestFilter.doFilterHttp(SecurityContextHolderAwareRequestFilter.java:91)
  at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
  at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
  at
org.springframework.security.ui.AbstractProcessingFilter.doFilterHttp(AbstractProcessingFilter.java:278)
  at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
  at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
  at
org.springframework.security.ui.logout.LogoutFilter.doFilterHttp(LogoutFilter.java:89)
  at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
  at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
  at
org.springframework.security.context.HttpSessionContextIntegrationFilter.doFilterHttp(HttpSessionContextIntegrationFilter.java:235)
  at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
  at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
  at
org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:185)
  at
org.springframework.security.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:99)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:71)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at
org.geoserver.filters.ReverseProxyFilter.doFilter(ReverseProxyFilter.java:183)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at
org.geoserver.filters.SessionDebugFilter.doFilter(SessionDebugFilter.java:46)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
  at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
  at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
  at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
  at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
  at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
  at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
  at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
  at org.mortbay.jetty.Server.handle(Server.java:324)
  at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
  at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842)
  at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
  at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
  at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
  at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
  at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)
10 Jun 13:53:15 INFO [geoserver.web] - Getting list of coverages for saved
store file:coverages/test.pgraster.xml
java.lang.RuntimeException: Could not list layers for this store, an error
occurred retrieving them: ERROR: The pixel type of band 1 in the raster is
not 8BUI or 16BUI. The PNG format can only be used with 8BUI and 16BUI
pixel types.
  at
org.geoserver.web.data.layer.NewLayerPageProvider.getItemsInternal(NewLayerPageProvider.java:123)
  at
org.geoserver.web.data.layer.NewLayerPageProvider.getItems(NewLayerPageProvider.java:56)
  at
org.geoserver.web.wicket.GeoServerDataProvider.fullSize(GeoServerDataProvider.java:225)
  at
org.geoserver.web.wicket.GeoServerTablePanel$PagerDelegate.updateMatched(GeoServerTablePanel.java:519)
  at
org.geoserver.web.wicket.GeoServerTablePanel$PagerDelegate.<init>(GeoServerTablePanel.java:512)
  at
org.geoserver.web.wicket.GeoServerTablePanel.<init>(GeoServerTablePanel.java:200)
  at
org.geoserver.web.wicket.GeoServerTablePanel.<init>(GeoServerTablePanel.java:91)
  at
org.geoserver.web.data.layer.NewLayerPage$1.<init>(NewLayerPage.java:104)
  at org.geoserver.web.data.layer.NewLayerPage.<init>(NewLayerPage.java:104)
  at
org.geoserver.web.data.store.CoverageStoreNewPage.onSave(CoverageStoreNewPage.java:71)
  at
org.geoserver.web.data.store.AbstractCoverageStorePage$1.onSubmit(AbstractCoverageStorePage.java:114)
  at
org.apache.wicket.ajax.markup.html.form.AjaxSubmitLink$1.onSubmit(AjaxSubmitLink.java:68)
  at
org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:143)
  at
org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177)
  at
org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:300)
  at
org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:119)
  at
org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
  at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
  at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
  at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436)
  at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
  at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:484)
  at
org.apache.wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:160)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
  at
org.springframework.web.servlet.mvc.ServletWrappingController.handleRequestInternal(ServletWrappingController.java:158)
  at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
  at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
  at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
  at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
  at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
  at
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
  at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
  at
org.geoserver.filters.ThreadLocalsCleanupFilter.doFilter(ThreadLocalsCleanupFilter.java:23)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at
org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter(SpringDelegatingFilter.java:74)
  at
org.geoserver.filters.SpringDelegatingFilter.doFilter(SpringDelegatingFilter.java:45)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at
org.geoserver.platform.AdvancedDispatchFilter.doFilter(AdvancedDispatchFilter.java:49)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:394)
  at
org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
  at
org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
  at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
  at
org.springframework.security.ui.ExceptionTranslationFilter.doFilterHttp(ExceptionTranslationFilter.java:101)
  at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
  at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
  at
org.springframework.security.providers.anonymous.AnonymousProcessingFilter.doFilterHttp(AnonymousProcessingFilter.java:105)
  at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
  at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
  at
org.springframework.security.ui.rememberme.RememberMeProcessingFilter.doFilterHttp(RememberMeProcessingFilter.java:116)
  at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
  at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
  at
org.springframework.security.wrapper.SecurityContextHolderAwareRequestFilter.doFilterHttp(SecurityContextHolderAwareRequestFilter.java:91)
  at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
  at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
  at
org.springframework.security.ui.AbstractProcessingFilter.doFilterHttp(AbstractProcessingFilter.java:278)
  at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
  at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
  at
org.springframework.security.ui.logout.LogoutFilter.doFilterHttp(LogoutFilter.java:89)
  at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
  at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
  at
org.springframework.security.context.HttpSessionContextIntegrationFilter.doFilterHttp(HttpSessionContextIntegrationFilter.java:235)
  at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
  at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
  at
org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:185)
  at
org.springframework.security.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:99)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:71)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at
org.geoserver.filters.ReverseProxyFilter.doFilter(ReverseProxyFilter.java:183)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at
org.geoserver.filters.SessionDebugFilter.doFilter(SessionDebugFilter.java:46)
  at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
  at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
  at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
  at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
  at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
  at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
  at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
  at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
  at org.mortbay.jetty.Server.handle(Server.java:324)
  at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
  at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842)
  at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
  at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
  at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
  at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
  at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)
Caused by: java.io.IOException: ERROR: The pixel type of band 1 in the
raster is not 8BUI or 16BUI. The PNG format can only be used with 8BUI and
16BUI pixel types.
  at
org.geotools.gce.imagemosaic.jdbc.custom.JDBCAccessPGRaster.startTileDecoders(JDBCAccessPGRaster.java:234)
  at
org.geotools.gce.imagemosaic.jdbc.ImageMosaicJDBCReader.loadTiles(ImageMosaicJDBCReader.java:460)
  at
org.geotools.gce.imagemosaic.jdbc.ImageMosaicJDBCReader.read(ImageMosaicJDBCReader.java:316)
  at
org.geoserver.catalog.CatalogBuilder.buildCoverage(CatalogBuilder.java:906)
  at
org.geoserver.catalog.CatalogBuilder.buildCoverage(CatalogBuilder.java:815)
  at
org.geoserver.web.data.layer.NewLayerPageProvider.getItemsInternal(NewLayerPageProvider.java:90)
  ... 96 more

This seems to suggest that what I'm trying to do - setting up a store with a
single band raster of type 32BF from postgis is not possible on GeoServer
2.1.4. I am confused about why the code would be concerned about what can
be displayed as a PNG before any styles are applied, but the stacktrace
seems to suggest that is the case. Is it possible that in GeoServer 2.3.2
this error has been eliminated and instead the code is silently doing some
conversion to a type that will work with as a PNG? In my case a 3 band
raster of type 8BUI.

Thanks again,

Mike

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5059213.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Hi Mike

Do you have the possibility to store the output of

select st_astiff(rast) from test

into a file. (I assume you have to code a little bit).

On success, you could examine this file (test.tif) with gdalinfo.

Cheers

···

2013/6/10 mrollans <mrollans@anonymised.com>

Hi Christian,

Thanks for the suggestion. I attempted what you said, but learned that
st_numbands expects a raster type not a bytea type as returned by st_astiff.

Running

select st_numbands(st_astiff(rast)) from test

in pgadmin returns

ERROR: function st_numbands(bytea) does not exist
LINE 1: select st_numbands(st_astiff(rast)) from test

If you know a way to make this work in some other way, let me know.

As an additional data point, I found something else that I think supports my
hypothesis that the plugin does not support bands of any type other than
8BUI or 16BUI. I attempted to create a store in the same way in my previous
email, except this time I used an older version of GeoServer and the Image
Mosaic JDBC plugin (2.1.4). When I attempt to create the store, I
immediately get the following stacktrace in the log.

10 Jun 13:53:15 ERROR [jdbc.custom] - ERROR: The pixel type of band 1 in the
raster is not 8BUI or 16BUI. The PNG format can only be used with 8BUI and
16BUI pixel types.
org.postgresql.util.PSQLException: ERROR: The pixel type of band 1 in the
raster is not 8BUI or 16BUI. The PNG format can only be used with 8BUI and
16BUI pixel types.
at
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2062)
at
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1795)
at
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:479)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:367)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:271)
at
org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
at
org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
at
org.geotools.gce.imagemosaic.jdbc.custom.JDBCAccessPGRaster.startTileDecoders(JDBCAccessPGRaster.java:194)
at
org.geotools.gce.imagemosaic.jdbc.ImageMosaicJDBCReader.loadTiles(ImageMosaicJDBCReader.java:460)
at
org.geotools.gce.imagemosaic.jdbc.ImageMosaicJDBCReader.read(ImageMosaicJDBCReader.java:316)
at
org.geoserver.catalog.CatalogBuilder.buildCoverage(CatalogBuilder.java:906)
at
org.geoserver.catalog.CatalogBuilder.buildCoverage(CatalogBuilder.java:815)
at
org.geoserver.web.data.layer.NewLayerPageProvider.getItemsInternal(NewLayerPageProvider.java:90)
at
org.geoserver.web.data.layer.NewLayerPageProvider.getItems(NewLayerPageProvider.java:56)
at
org.geoserver.web.wicket.GeoServerDataProvider.fullSize(GeoServerDataProvider.java:225)
at
org.geoserver.web.wicket.GeoServerTablePanel$PagerDelegate.updateMatched(GeoServerTablePanel.java:519)
at
org.geoserver.web.wicket.GeoServerTablePanel$PagerDelegate.(GeoServerTablePanel.java:512)
at
org.geoserver.web.wicket.GeoServerTablePanel.(GeoServerTablePanel.java:200)
at
org.geoserver.web.wicket.GeoServerTablePanel.(GeoServerTablePanel.java:91)
at
org.geoserver.web.data.layer.NewLayerPage$1.(NewLayerPage.java:104)
at org.geoserver.web.data.layer.NewLayerPage.(NewLayerPage.java:104)
at
org.geoserver.web.data.store.CoverageStoreNewPage.onSave(CoverageStoreNewPage.java:71)
at
org.geoserver.web.data.store.AbstractCoverageStorePage$1.onSubmit(AbstractCoverageStorePage.java:114)
at
org.apache.wicket.ajax.markup.html.form.AjaxSubmitLink$1.onSubmit(AjaxSubmitLink.java:68)
at
org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:143)
at
org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177)
at
org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:300)
at
org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:119)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:484)
at
org.apache.wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:160)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.springframework.web.servlet.mvc.ServletWrappingController.handleRequestInternal(ServletWrappingController.java:158)
at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
at
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at
org.geoserver.filters.ThreadLocalsCleanupFilter.doFilter(ThreadLocalsCleanupFilter.java:23)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter(SpringDelegatingFilter.java:74)
at
org.geoserver.filters.SpringDelegatingFilter.doFilter(SpringDelegatingFilter.java:45)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
org.geoserver.platform.AdvancedDispatchFilter.doFilter(AdvancedDispatchFilter.java:49)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:394)
at
org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
at
org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
at
org.springframework.security.ui.ExceptionTranslationFilter.doFilterHttp(ExceptionTranslationFilter.java:101)
at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
at
org.springframework.security.providers.anonymous.AnonymousProcessingFilter.doFilterHttp(AnonymousProcessingFilter.java:105)
at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
at
org.springframework.security.ui.rememberme.RememberMeProcessingFilter.doFilterHttp(RememberMeProcessingFilter.java:116)
at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
at
org.springframework.security.wrapper.SecurityContextHolderAwareRequestFilter.doFilterHttp(SecurityContextHolderAwareRequestFilter.java:91)
at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
at
org.springframework.security.ui.AbstractProcessingFilter.doFilterHttp(AbstractProcessingFilter.java:278)
at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
at
org.springframework.security.ui.logout.LogoutFilter.doFilterHttp(LogoutFilter.java:89)
at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
at
org.springframework.security.context.HttpSessionContextIntegrationFilter.doFilterHttp(HttpSessionContextIntegrationFilter.java:235)
at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
at
org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:185)
at
org.springframework.security.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:99)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:71)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
org.geoserver.filters.ReverseProxyFilter.doFilter(ReverseProxyFilter.java:183)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
org.geoserver.filters.SessionDebugFilter.doFilter(SessionDebugFilter.java:46)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:324)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)
10 Jun 13:53:15 INFO [geoserver.web] - Getting list of coverages for saved
store file:coverages/test.pgraster.xml
java.lang.RuntimeException: Could not list layers for this store, an error
occurred retrieving them: ERROR: The pixel type of band 1 in the raster is
not 8BUI or 16BUI. The PNG format can only be used with 8BUI and 16BUI
pixel types.
at
org.geoserver.web.data.layer.NewLayerPageProvider.getItemsInternal(NewLayerPageProvider.java:123)
at
org.geoserver.web.data.layer.NewLayerPageProvider.getItems(NewLayerPageProvider.java:56)
at
org.geoserver.web.wicket.GeoServerDataProvider.fullSize(GeoServerDataProvider.java:225)
at
org.geoserver.web.wicket.GeoServerTablePanel$PagerDelegate.updateMatched(GeoServerTablePanel.java:519)
at
org.geoserver.web.wicket.GeoServerTablePanel$PagerDelegate.(GeoServerTablePanel.java:512)
at
org.geoserver.web.wicket.GeoServerTablePanel.(GeoServerTablePanel.java:200)
at
org.geoserver.web.wicket.GeoServerTablePanel.(GeoServerTablePanel.java:91)
at
org.geoserver.web.data.layer.NewLayerPage$1.(NewLayerPage.java:104)
at org.geoserver.web.data.layer.NewLayerPage.(NewLayerPage.java:104)
at
org.geoserver.web.data.store.CoverageStoreNewPage.onSave(CoverageStoreNewPage.java:71)
at
org.geoserver.web.data.store.AbstractCoverageStorePage$1.onSubmit(AbstractCoverageStorePage.java:114)
at
org.apache.wicket.ajax.markup.html.form.AjaxSubmitLink$1.onSubmit(AjaxSubmitLink.java:68)
at
org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:143)
at
org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177)
at
org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:300)
at
org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:119)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:484)
at
org.apache.wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:160)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.springframework.web.servlet.mvc.ServletWrappingController.handleRequestInternal(ServletWrappingController.java:158)
at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
at
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at
org.geoserver.filters.ThreadLocalsCleanupFilter.doFilter(ThreadLocalsCleanupFilter.java:23)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter(SpringDelegatingFilter.java:74)
at
org.geoserver.filters.SpringDelegatingFilter.doFilter(SpringDelegatingFilter.java:45)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
org.geoserver.platform.AdvancedDispatchFilter.doFilter(AdvancedDispatchFilter.java:49)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:394)
at
org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
at
org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
at
org.springframework.security.ui.ExceptionTranslationFilter.doFilterHttp(ExceptionTranslationFilter.java:101)
at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
at
org.springframework.security.providers.anonymous.AnonymousProcessingFilter.doFilterHttp(AnonymousProcessingFilter.java:105)
at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
at
org.springframework.security.ui.rememberme.RememberMeProcessingFilter.doFilterHttp(RememberMeProcessingFilter.java:116)
at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
at
org.springframework.security.wrapper.SecurityContextHolderAwareRequestFilter.doFilterHttp(SecurityContextHolderAwareRequestFilter.java:91)
at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
at
org.springframework.security.ui.AbstractProcessingFilter.doFilterHttp(AbstractProcessingFilter.java:278)
at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
at
org.springframework.security.ui.logout.LogoutFilter.doFilterHttp(LogoutFilter.java:89)
at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
at
org.springframework.security.context.HttpSessionContextIntegrationFilter.doFilterHttp(HttpSessionContextIntegrationFilter.java:235)
at
org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at
org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:406)
at
org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:185)
at
org.springframework.security.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:99)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:71)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
org.geoserver.filters.ReverseProxyFilter.doFilter(ReverseProxyFilter.java:183)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
org.geoserver.filters.SessionDebugFilter.doFilter(SessionDebugFilter.java:46)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:324)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)
Caused by: java.io.IOException: ERROR: The pixel type of band 1 in the
raster is not 8BUI or 16BUI. The PNG format can only be used with 8BUI and
16BUI pixel types.
at
org.geotools.gce.imagemosaic.jdbc.custom.JDBCAccessPGRaster.startTileDecoders(JDBCAccessPGRaster.java:234)
at
org.geotools.gce.imagemosaic.jdbc.ImageMosaicJDBCReader.loadTiles(ImageMosaicJDBCReader.java:460)
at
org.geotools.gce.imagemosaic.jdbc.ImageMosaicJDBCReader.read(ImageMosaicJDBCReader.java:316)
at
org.geoserver.catalog.CatalogBuilder.buildCoverage(CatalogBuilder.java:906)
at
org.geoserver.catalog.CatalogBuilder.buildCoverage(CatalogBuilder.java:815)
at
org.geoserver.web.data.layer.NewLayerPageProvider.getItemsInternal(NewLayerPageProvider.java:90)
… 96 more

This seems to suggest that what I’m trying to do - setting up a store with a
single band raster of type 32BF from postgis is not possible on GeoServer
2.1.4. I am confused about why the code would be concerned about what can
be displayed as a PNG before any styles are applied, but the stacktrace
seems to suggest that is the case. Is it possible that in GeoServer 2.3.2
this error has been eliminated and instead the code is silently doing some
conversion to a type that will work with as a PNG? In my case a 3 band
raster of type 8BUI.

Thanks again,

Mike


View this message in context: http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5059213.html
Sent from the GeoServer - User mailing list archive at Nabble.com.


This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev


Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

Hi Christian,

I was curious what that would reveal too, so I tried that yesterday
afternoon. I put together a small java jdbc program to run

select st_astiff(rast) from test

from my postgis database and dumped the result to a file. I then gdalinfo
my original file (prior to the postgis load) and the one output from postgis
and diffed the results.

The only differences between the two were the reported file names and a
slight difference in the reported NoData Value (which I suspect was due to
rounding differences). Otherwise, the output was identical, 1 reported band
of type Float32, ColorInterp=Gray etc.

I could open the tif output from postgis in QuantumGis and apply a color
style and view the data values just fine.

I suspect this means the problem is somewhere downstream of the st_astiff
call. Perhaps something with the construction of the GridCoverage2d based
on the image in ImageComposerThread? I don't have the familiarity or
context around the GeoTools code to really understand what it is trying to
do just yet, but it seems like a strong possibility that something is going
wrong in there someplace.

As a point of interest, with fine detail logging turned on in GeoServer I
can see the following output when I try to preview my layer from the geotiff
loaded from the filesystem.

11 Jun 13:01:47 DEBUG [geoserver.ows] - Getting layers and styles from
LAYERS an
d STYLES
11 Jun 13:01:47 DEBUG [geoserver.ows] - establishing raster style for
cite:testf
s
11 Jun 13:01:47 DEBUG [geoserver.wms] - setting up map
11 Jun 13:01:47 DEBUG [wms.map] - setting up 578x330 image
11 Jun 13:01:47 DEBUG [geotools.rendering] - Drawing coverage
GridCoverage2D["te
st", GeneralEnvelope[(-104.053125, 46.359375), (-99.415625, 49.003125)],
Default
GeographicCRS["WGS 84"]]
? RenderedSampleDimension("GRAY_INDEX":[-3.402823E38 ... -3.402823E38])
? ? Category("No data":[-3.402823E38 ... -3.402823E38])
? Image=RenderedOp["ImageRead"]

11 Jun 13:01:47 DEBUG [geotools.rendering] - Transforming coverage envelope
with
transform PARAM_MT["Affine",
  PARAMETER["num_row", 3],
  PARAMETER["num_col", 3]]
11 Jun 13:01:47 DEBUG [geotools.rendering] - Using interpolation
javax.media.jai
.InterpolationNearest@anonymised.com

Versus similar output when trying layer preview for my postgis raster.

11 Jun 13:15:56 INFO [imagemosaic.jdbc] - Coverage test using spatial table
null
, image table test
11 Jun 13:15:56 INFO [jdbc.custom] - Using 2 CPU(s)
11 Jun 13:15:56 INFO [jdbc.custom] - Getting 1 Tiles needs 125 millisecs
11 Jun 13:15:57 INFO [jdbc.custom] - Getting and decoding 1 Tiles needs 406
mil
lisecs
11 Jun 13:15:57 INFO [imagemosaic.jdbc] - Mosaic Reader needs : 422
millisecs
11 Jun 13:15:57 DEBUG [geotools.rendering] - Drawing coverage
GridCoverage2D["te
st", GeneralEnvelope[(-104.35202636719, 46.186743164062), (-99.116723632811,
49.
175756835937)], DefaultGeographicCRS["WGS 84"]]
? RenderedSampleDimension("test":[0.0 ... 255.0])
? ? Category("test":[0...255])
? RenderedSampleDimension("test":[0.0 ... 255.0])
? ? Category("test":[0...255])
? RenderedSampleDimension("test":[0.0 ... 255.0])
? ? Category("test":[0...255])
? Image=WritableRenderedImageAdapter

11 Jun 13:15:57 DEBUG [geotools.rendering] - Transforming coverage envelope
with
transform PARAM_MT["Affine",
  PARAMETER["num_row", 3],
  PARAMETER["num_col", 3]]
11 Jun 13:15:57 DEBUG [geotools.rendering] - Using interpolation
javax.media.jai
.InterpolationNearest@anonymised.com

So, by the point the GridCoverage2d is logged, the RenderedSampleDimensions
are wrong in the second case.

Mike

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5059493.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Hi Mike

I think I found the problem. It is in

ImageComposerThread.getStartImage

The unlucky code sequence is

if (imageType == BufferedImage.TYPE_CUSTOM)
imageType = ImageMosaicJDBCReader.DEFAULT_IMAGE_TYPE;

I think your image type is custom and the default type is RGB wit 3 bands using bytes.

Should I try to fix this code and send you a jar file for testing. The idea would be to create the start image with
the following constructor

public BufferedImage (ColorModel cm,
WritableRaster raster,
boolean isRasterPremultiplied,
Hashtable<?,?> properties) {

Perhaps this will do the trick.
Please let me know

Christian

···

2013/6/11 mrollans <mrollans@anonymised.com>

Hi Christian,

I was curious what that would reveal too, so I tried that yesterday
afternoon. I put together a small java jdbc program to run

select st_astiff(rast) from test

from my postgis database and dumped the result to a file. I then gdalinfo
my original file (prior to the postgis load) and the one output from postgis
and diffed the results.

The only differences between the two were the reported file names and a
slight difference in the reported NoData Value (which I suspect was due to
rounding differences). Otherwise, the output was identical, 1 reported band
of type Float32, ColorInterp=Gray etc.

I could open the tif output from postgis in QuantumGis and apply a color
style and view the data values just fine.

I suspect this means the problem is somewhere downstream of the st_astiff
call. Perhaps something with the construction of the GridCoverage2d based
on the image in ImageComposerThread? I don’t have the familiarity or
context around the GeoTools code to really understand what it is trying to
do just yet, but it seems like a strong possibility that something is going
wrong in there someplace.

As a point of interest, with fine detail logging turned on in GeoServer I
can see the following output when I try to preview my layer from the geotiff
loaded from the filesystem.

11 Jun 13:01:47 DEBUG [geoserver.ows] - Getting layers and styles from
LAYERS an
d STYLES
11 Jun 13:01:47 DEBUG [geoserver.ows] - establishing raster style for
cite:testf
s
11 Jun 13:01:47 DEBUG [geoserver.wms] - setting up map
11 Jun 13:01:47 DEBUG [wms.map] - setting up 578x330 image
11 Jun 13:01:47 DEBUG [geotools.rendering] - Drawing coverage
GridCoverage2D[“te
st”, GeneralEnvelope[(-104.053125, 46.359375), (-99.415625, 49.003125)],
Default
GeographicCRS[“WGS 84”]]
? RenderedSampleDimension(“GRAY_INDEX”:[-3.402823E38 … -3.402823E38])
? ? Category(“No data”:[-3.402823E38 … -3.402823E38])
? Image=RenderedOp[“ImageRead”]

11 Jun 13:01:47 DEBUG [geotools.rendering] - Transforming coverage envelope
with
transform PARAM_MT[“Affine”,
PARAMETER[“num_row”, 3],
PARAMETER[“num_col”, 3]]
11 Jun 13:01:47 DEBUG [geotools.rendering] - Using interpolation
javax.media.jai
.InterpolationNearest@anonymised.com

Versus similar output when trying layer preview for my postgis raster.

11 Jun 13:15:56 INFO [imagemosaic.jdbc] - Coverage test using spatial table
null
, image table test
11 Jun 13:15:56 INFO [jdbc.custom] - Using 2 CPU(s)
11 Jun 13:15:56 INFO [jdbc.custom] - Getting 1 Tiles needs 125 millisecs
11 Jun 13:15:57 INFO [jdbc.custom] - Getting and decoding 1 Tiles needs 406
mil
lisecs
11 Jun 13:15:57 INFO [imagemosaic.jdbc] - Mosaic Reader needs : 422
millisecs
11 Jun 13:15:57 DEBUG [geotools.rendering] - Drawing coverage
GridCoverage2D[“te
st”, GeneralEnvelope[(-104.35202636719, 46.186743164062), (-99.116723632811,
49.
175756835937)], DefaultGeographicCRS[“WGS 84”]]
? RenderedSampleDimension(“test”:[0.0 … 255.0])
? ? Category(“test”:[0…255])
? RenderedSampleDimension(“test”:[0.0 … 255.0])
? ? Category(“test”:[0…255])
? RenderedSampleDimension(“test”:[0.0 … 255.0])
? ? Category(“test”:[0…255])
? Image=WritableRenderedImageAdapter

11 Jun 13:15:57 DEBUG [geotools.rendering] - Transforming coverage envelope
with
transform PARAM_MT[“Affine”,
PARAMETER[“num_row”, 3],
PARAMETER[“num_col”, 3]]
11 Jun 13:15:57 DEBUG [geotools.rendering] - Using interpolation
javax.media.jai
.InterpolationNearest@anonymised.com

So, by the point the GridCoverage2d is logged, the RenderedSampleDimensions
are wrong in the second case.

Mike


View this message in context: http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5059493.html

Sent from the GeoServer - User mailing list archive at Nabble.com.


This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev


Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

Hi Christian,

I concur, I was looking at that same bit of code as the likely culprit. I can also verify from some of my test code that

my image is likely being read in through

ImageDecodedThread.readImage2

When I read in my image using similar code, it’s type is indeed BufferedImage.TYPE_CUSTOM.

If you can send me a jar for testing, that would be fantastic!

Thanks again,

Mike

···

On Wed, Jun 12, 2013 at 2:45 AM, Christian Mueller <christian.mueller@anonymised.com> wrote:

Hi Mike

I think I found the problem. It is in

ImageComposerThread.getStartImage

The unlucky code sequence is

if (imageType == BufferedImage.TYPE_CUSTOM)
imageType = ImageMosaicJDBCReader.DEFAULT_IMAGE_TYPE;

I think your image type is custom and the default type is RGB wit 3 bands using bytes.

Should I try to fix this code and send you a jar file for testing. The idea would be to create the start image with
the following constructor

public BufferedImage (ColorModel cm,
WritableRaster raster,
boolean isRasterPremultiplied,
Hashtable<?,?> properties) {

Perhaps this will do the trick.
Please let me know

Christian

2013/6/11 mrollans <mrollans@anonymised.com>

Hi Christian,

I was curious what that would reveal too, so I tried that yesterday
afternoon. I put together a small java jdbc program to run

select st_astiff(rast) from test

from my postgis database and dumped the result to a file. I then gdalinfo
my original file (prior to the postgis load) and the one output from postgis
and diffed the results.

The only differences between the two were the reported file names and a
slight difference in the reported NoData Value (which I suspect was due to
rounding differences). Otherwise, the output was identical, 1 reported band
of type Float32, ColorInterp=Gray etc.

I could open the tif output from postgis in QuantumGis and apply a color
style and view the data values just fine.

I suspect this means the problem is somewhere downstream of the st_astiff
call. Perhaps something with the construction of the GridCoverage2d based
on the image in ImageComposerThread? I don’t have the familiarity or
context around the GeoTools code to really understand what it is trying to
do just yet, but it seems like a strong possibility that something is going
wrong in there someplace.

As a point of interest, with fine detail logging turned on in GeoServer I
can see the following output when I try to preview my layer from the geotiff
loaded from the filesystem.

11 Jun 13:01:47 DEBUG [geoserver.ows] - Getting layers and styles from
LAYERS an
d STYLES
11 Jun 13:01:47 DEBUG [geoserver.ows] - establishing raster style for
cite:testf
s
11 Jun 13:01:47 DEBUG [geoserver.wms] - setting up map
11 Jun 13:01:47 DEBUG [wms.map] - setting up 578x330 image
11 Jun 13:01:47 DEBUG [geotools.rendering] - Drawing coverage
GridCoverage2D[“te
st”, GeneralEnvelope[(-104.053125, 46.359375), (-99.415625, 49.003125)],
Default
GeographicCRS[“WGS 84”]]
? RenderedSampleDimension(“GRAY_INDEX”:[-3.402823E38 … -3.402823E38])
? ? Category(“No data”:[-3.402823E38 … -3.402823E38])
? Image=RenderedOp[“ImageRead”]

11 Jun 13:01:47 DEBUG [geotools.rendering] - Transforming coverage envelope
with
transform PARAM_MT[“Affine”,
PARAMETER[“num_row”, 3],
PARAMETER[“num_col”, 3]]
11 Jun 13:01:47 DEBUG [geotools.rendering] - Using interpolation
javax.media.jai
.InterpolationNearest@anonymised.com

Versus similar output when trying layer preview for my postgis raster.

11 Jun 13:15:56 INFO [imagemosaic.jdbc] - Coverage test using spatial table
null
, image table test
11 Jun 13:15:56 INFO [jdbc.custom] - Using 2 CPU(s)
11 Jun 13:15:56 INFO [jdbc.custom] - Getting 1 Tiles needs 125 millisecs
11 Jun 13:15:57 INFO [jdbc.custom] - Getting and decoding 1 Tiles needs 406
mil
lisecs
11 Jun 13:15:57 INFO [imagemosaic.jdbc] - Mosaic Reader needs : 422
millisecs
11 Jun 13:15:57 DEBUG [geotools.rendering] - Drawing coverage
GridCoverage2D[“te
st”, GeneralEnvelope[(-104.35202636719, 46.186743164062), (-99.116723632811,
49.
175756835937)], DefaultGeographicCRS[“WGS 84”]]
? RenderedSampleDimension(“test”:[0.0 … 255.0])
? ? Category(“test”:[0…255])
? RenderedSampleDimension(“test”:[0.0 … 255.0])
? ? Category(“test”:[0…255])
? RenderedSampleDimension(“test”:[0.0 … 255.0])
? ? Category(“test”:[0…255])
? Image=WritableRenderedImageAdapter

11 Jun 13:15:57 DEBUG [geotools.rendering] - Transforming coverage envelope
with
transform PARAM_MT[“Affine”,
PARAMETER[“num_row”, 3],
PARAMETER[“num_col”, 3]]
11 Jun 13:15:57 DEBUG [geotools.rendering] - Using interpolation
javax.media.jai
.InterpolationNearest@anonymised.com

So, by the point the GridCoverage2d is logged, the RenderedSampleDimensions
are wrong in the second case.

Mike


View this message in context: http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5059493.html

Sent from the GeoServer - User mailing list archive at Nabble.com.


This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev


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

DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

Hi Mike and Christian,

I am having the same problem with 32bit rasters as Mike experienced. I did
attempt to fix it by using a different BufferedImage constructor as
Christian suggested, which allowed me to get past the
imageComposerThread.getStartImage() issue, however, now rescaleImage is
producing a blank image for me.

I tried to work around that by creating BufferedImage differently in the
AbstractThread.rescaleImage() method, but perhaps I am doing something
incorrectly because Graphics2D.drawImage() appears to produce an image
filled with '0' values.

Any suggestions would be welcome!

Thanks,
Nataliya

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5086765.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Hi Nataliya

Which geotools version do you use.

Are you working on trunk ?

···

On Thu, Oct 31, 2013 at 8:02 AM, nroberts <nataliya_roberts@anonymised.com> wrote:

Hi Mike and Christian,

I am having the same problem with 32bit rasters as Mike experienced. I did
attempt to fix it by using a different BufferedImage constructor as
Christian suggested, which allowed me to get past the
imageComposerThread.getStartImage() issue, however, now rescaleImage is
producing a blank image for me.

I tried to work around that by creating BufferedImage differently in the
AbstractThread.rescaleImage() method, but perhaps I am doing something
incorrectly because Graphics2D.drawImage() appears to produce an image
filled with ‘0’ values.

Any suggestions would be welcome!

Thanks,
Nataliya


View this message in context: http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5086765.html

Sent from the GeoServer - User mailing list archive at Nabble.com.


Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk


Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

Hi Christian,

I am using 9.5.

I checked trunk svn a few weeks back (assuming this is a correct location
for it:
http://svn.osgeo.org/geotools/trunk/modules/plugin/imagemosaic-jdbc/src/main/java/org/geotools/gce/imagemosaic/jdbc)
and didn't spot any changes in the code in comparison to my my 9.5 version.
Should I try version 10+?

Thanks
Nataliya

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5086815.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

On Thu, Oct 31, 2013 at 12:34 PM, nroberts <nataliya_roberts@anonymised.com>wrote:

Hi Christian,

I am using 9.5.

I checked trunk svn a few weeks back (assuming this is a correct location
for it:

http://svn.osgeo.org/geotools/trunk/modules/plugin/imagemosaic-jdbc/src/main/java/org/geotools/gce/imagemosaic/jdbc
)
and didn't spot any changes in the code in comparison to my my 9.5 version.
Should I try version 10+?

Way off the mark I'm afraid, GeoTools has not been using svn for a long
time now.
The sources are on github:
https://github.com/geotools/geotools

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

Some weeks ago, I did some major changes. Please switch to the lastest version or check out trunk from github.

Christian

···

On Thu, Oct 31, 2013 at 12:45 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Oct 31, 2013 at 12:34 PM, nroberts <nataliya_roberts@anonymised.com> wrote:


Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk


Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

Hi Christian,

I am using 9.5.

I checked trunk svn a few weeks back (assuming this is a correct location
for it:
http://svn.osgeo.org/geotools/trunk/modules/plugin/imagemosaic-jdbc/src/main/java/org/geotools/gce/imagemosaic/jdbc)
and didn’t spot any changes in the code in comparison to my my 9.5 version.
Should I try version 10+?

Way off the mark I’m afraid, GeoTools has not been using svn for a long time now.
The sources are on github:
https://github.com/geotools/geotools

Cheers
Andrea

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


Hi Christian,

thank you for the suggestion!

I have upgraded to 10.1 and the situation is a bit better, but I am still
having a problem with my 32bit raster, albeit a slightly different one - all
I can see now is a solid black image filling an entire image area in the
Layer Preview.

It looks to me as rescaleImage still doesn't rescale single band 32 bit
raster image correctly: if I check image properties after rescale operation,
the underlying raster contains all '0' values.

Here is what I tried so far in an attempt to diagnose the problem:
* exported raster into a .tiff file and reimported it into GeoServer using
GeoTiff plugin - it appears to work fine (i.e I can see expected
visualisation in the Layer Preview and featureinfo displays correct
information).
* commented out ImageComposerThread.rescaleImage - Layer Preview displays
raster correctly (as long as I don't zoom out)
* tried to create GridCoverage2D using GridCoverageFactory.create() method
that accepts MathTransform and using this transform to scale instead of
rescaling the image beforehand (this approach doesn't work with zoom out
either)

Since I am no expert in image processing or coverages, I am not sure how
best to fix this.

I may be doing something unconventional when creating my raster, so, just in
case, here is a list of sql commands I use to create test data:

Thanks
Nat

( I am using geoserver 2.4.1 and geotools 10.1 version)

Christian Mueller-3 wrote

Some weeks ago, I did some major changes. Please switch to the lastest
version or check out trunk from github.

Christian

On Thu, Oct 31, 2013 at 12:45 PM, Andrea Aime
&lt;

andrea.aime@

&gt;wrote:

On Thu, Oct 31, 2013 at 12:34 PM, nroberts &lt;

nataliya_roberts@anonymised.com

&gt;wrote:

Hi Christian,

I am using 9.5.

I checked trunk svn a few weeks back (assuming this is a correct
location
for it:

http://svn.osgeo.org/geotools/trunk/modules/plugin/imagemosaic-jdbc/src/main/java/org/geotools/gce/imagemosaic/jdbc
)
and didn't spot any changes in the code in comparison to my my 9.5
version.
Should I try version 10+?

Way off the mark I'm afraid, GeoTools has not been using svn for a long
time now.
The sources are on github:
https://github.com/geotools/geotools

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform
that
developers love is also attractive to malware creators. Download this
white
paper to learn more about secure code signing practices that can help
keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list

Geoserver-users@anonymised.com

https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform
that
developers love is also attractive to malware creators. Download this
white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list

Geoserver-users@anonymised.com

https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5087186.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Yep, the rescale op is the problem.

Do you have a 32 bit float or integer raster. As far as I can remember, integer rasters should work fine, float is causing the problem. I also tried some different implemenations for the rescale operation, but none was working for float values.

Cheers
Christian

···

On Mon, Nov 4, 2013 at 8:32 AM, nroberts <nataliya_roberts@anonymised.com> wrote:

Hi Christian,

thank you for the suggestion!

I have upgraded to 10.1 and the situation is a bit better, but I am still
having a problem with my 32bit raster, albeit a slightly different one - all
I can see now is a solid black image filling an entire image area in the
Layer Preview.

It looks to me as rescaleImage still doesn’t rescale single band 32 bit
raster image correctly: if I check image properties after rescale operation,
the underlying raster contains all ‘0’ values.

Here is what I tried so far in an attempt to diagnose the problem:

  • exported raster into a .tiff file and reimported it into GeoServer using
    GeoTiff plugin - it appears to work fine (i.e I can see expected
    visualisation in the Layer Preview and featureinfo displays correct
    information).
  • commented out ImageComposerThread.rescaleImage - Layer Preview displays
    raster correctly (as long as I don’t zoom out)
  • tried to create GridCoverage2D using GridCoverageFactory.create() method
    that accepts MathTransform and using this transform to scale instead of
    rescaling the image beforehand (this approach doesn’t work with zoom out
    either)

Since I am no expert in image processing or coverages, I am not sure how
best to fix this.

I may be doing something unconventional when creating my raster, so, just in
case, here is a list of sql commands I use to create test data:

Thanks
Nat

( I am using geoserver 2.4.1 and geotools 10.1 version)

Christian Mueller-3 wrote

Some weeks ago, I did some major changes. Please switch to the lastest
version or check out trunk from github.

Christian

On Thu, Oct 31, 2013 at 12:45 PM, Andrea Aime
<

andrea.aime@

wrote:

On Thu, Oct 31, 2013 at 12:34 PM, nroberts <

nataliya_roberts@anonymised.com

wrote:

Hi Christian,

I am using 9.5.

I checked trunk svn a few weeks back (assuming this is a correct
location
for it:

http://svn.osgeo.org/geotools/trunk/modules/plugin/imagemosaic-jdbc/src/main/java/org/geotools/gce/imagemosaic/jdbc
)
and didn’t spot any changes in the code in comparison to my my 9.5
version.
Should I try version 10+?

Way off the mark I’m afraid, GeoTools has not been using svn for a long
time now.
The sources are on github:
https://github.com/geotools/geotools

Cheers
Andrea

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it



Android is increasing in popularity, but the open development platform
that
developers love is also attractive to malware creators. Download this
white
paper to learn more about secure code signing practices that can help
keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk


Geoserver-users mailing list

Geoserver-users@anonymised.com

https://lists.sourceforge.net/lists/listinfo/geoserver-users


DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH


Android is increasing in popularity, but the open development platform
that
developers love is also attractive to malware creators. Download this
white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk


Geoserver-users mailing list

Geoserver-users@anonymised.com

https://lists.sourceforge.net/lists/listinfo/geoserver-users


View this message in context: http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5087186.html

Sent from the GeoServer - User mailing list archive at Nabble.com.


Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk


Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

both 32 bit integer and float don't work for me.

32 bit integer produces solid black image due to alll values being turned
into '0' and 32 bit float throws ArrayOutOfBounds exception when attempting
to rescaleImage.

cheers
Nataliya

Christian Mueller-3 wrote

Yep, the rescale op is the problem.

Do you have a 32 bit float or integer raster. As far as I can remember,
integer rasters should work fine, float is causing the problem. I also
tried some different implemenations for the rescale operation, but none
was
working for float values.

Cheers
Christian

On Mon, Nov 4, 2013 at 8:32 AM, nroberts &lt;

nataliya_roberts@anonymised.com

&gt;wrote:

Hi Christian,

thank you for the suggestion!

I have upgraded to 10.1 and the situation is a bit better, but I am still
having a problem with my 32bit raster, albeit a slightly different one -
all
I can see now is a solid black image filling an entire image area in the
Layer Preview.

It looks to me as rescaleImage still doesn't rescale single band 32 bit
raster image correctly: if I check image properties after rescale
operation,
the underlying raster contains all '0' values.

Here is what I tried so far in an attempt to diagnose the problem:
* exported raster into a .tiff file and reimported it into GeoServer
using
GeoTiff plugin - it appears to work fine (i.e I can see expected
visualisation in the Layer Preview and featureinfo displays correct
information).
* commented out ImageComposerThread.rescaleImage - Layer Preview displays
raster correctly (as long as I don't zoom out)
* tried to create GridCoverage2D using GridCoverageFactory.create()
method
that accepts MathTransform and using this transform to scale instead of
rescaling the image beforehand (this approach doesn't work with zoom out
either)

Since I am no expert in image processing or coverages, I am not sure how
best to fix this.

I may be doing something unconventional when creating my raster, so, just
in
case, here is a list of sql commands I use to create test data:

Thanks
Nat

( I am using geoserver 2.4.1 and geotools 10.1 version)

Christian Mueller-3 wrote
> Some weeks ago, I did some major changes. Please switch to the lastest
> version or check out trunk from github.
>
> Christian
>
>
> On Thu, Oct 31, 2013 at 12:45 PM, Andrea Aime
> <

> andrea.aime@

> >wrote:
>
>> On Thu, Oct 31, 2013 at 12:34 PM, nroberts <

> nataliya_roberts@anonymised.com

> >wrote:
>>
>>> Hi Christian,
>>>
>>> I am using 9.5.
>>>
>>> I checked trunk svn a few weeks back (assuming this is a correct
>>> location
>>> for it:
>>>
>>>
http://svn.osgeo.org/geotools/trunk/modules/plugin/imagemosaic-jdbc/src/main/java/org/geotools/gce/imagemosaic/jdbc
>>> )
>>> and didn't spot any changes in the code in comparison to my my 9.5
>>> version.
>>> Should I try version 10+?
>>>
>>
>> Way off the mark I'm afraid, GeoTools has not been using svn for a
long
>> time now.
>> The sources are on github:
>> https://github.com/geotools/geotools
>>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more
>> information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via Poggio alle Viti 1187
>> 55054 Massarosa (LU)
>> Italy
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39 339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> -------------------------------------------------------
>>
>>
>>
------------------------------------------------------------------------------
>> Android is increasing in popularity, but the open development platform
>> that
>> developers love is also attractive to malware creators. Download this
>> white
>> paper to learn more about secure code signing practices that can help
>> keep
>> Android apps secure.
>>
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Geoserver-users mailing list
>>

> Geoserver-users@anonymised.com

>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>
>>
>
>
> --
> DI Christian Mueller MSc (GIS), MSc (IT-Security)
> OSS Open Source Solutions GmbH
>
>
------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform
> that
> developers love is also attractive to malware creators. Download this
> white
> paper to learn more about secure code signing practices that can help
keep
> Android apps secure.
>
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> Geoserver-users mailing list

> Geoserver-users@anonymised.com

> https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5087186.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform
that
developers love is also attractive to malware creators. Download this
white
paper to learn more about secure code signing practices that can help
keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list

Geoserver-users@anonymised.com

https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform
that
developers love is also attractive to malware creators. Download this
white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list

Geoserver-users@anonymised.com

https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5087377.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Hi Christian,

In terms of rescaling, the following seems to work at least for 32 bit
integer rasters:

Now my problem is with startImage - it is created with underlying values of
'0', so when I pan or zoom out in Layer Preview, I get a black border around
my image (please see screenshots below)

Layer Preview for my test raster:
<http://osgeo-org.1560.x6.nabble.com/file/n5087386/test-raster.jpg&gt;

Moved test raster a bit to the right top corner:
<http://osgeo-org.1560.x6.nabble.com/file/n5087386/test-raster-panned.jpg&gt;

It looks as this happens because startImage is created with all '0' values
in the underlying raster. So when we put tile image from PostGIS over the
top of it, there is a band of '0' values left over (which shows up in black)
as the tile image doesn't cover the entire start image.

I am experimenting with creating startImage using nodata values from PostGIS
and it seems to fix the black border problem. (hacked it for now to suit my
raster, but I imagine that it may be a bit more complicated to implement for
multi-band rasters)

Does that sound as an acceptable approach?

thanks
Nataliya

nroberts wrote

both 32 bit integer and float don't work for me.

32 bit integer produces solid black image due to alll values being turned
into '0' and 32 bit float throws ArrayOutOfBounds exception when
attempting to rescaleImage.

cheers
Nataliya
Christian Mueller-3 wrote

Yep, the rescale op is the problem.

Do you have a 32 bit float or integer raster. As far as I can remember,
integer rasters should work fine, float is causing the problem. I also
tried some different implemenations for the rescale operation, but none
was
working for float values.

Cheers
Christian

On Mon, Nov 4, 2013 at 8:32 AM, nroberts &lt;

nataliya_roberts@anonymised.com

&gt;wrote:

Hi Christian,

thank you for the suggestion!

I have upgraded to 10.1 and the situation is a bit better, but I am
still
having a problem with my 32bit raster, albeit a slightly different one -
all
I can see now is a solid black image filling an entire image area in the
Layer Preview.

It looks to me as rescaleImage still doesn't rescale single band 32 bit
raster image correctly: if I check image properties after rescale
operation,
the underlying raster contains all '0' values.

Here is what I tried so far in an attempt to diagnose the problem:
* exported raster into a .tiff file and reimported it into GeoServer
using
GeoTiff plugin - it appears to work fine (i.e I can see expected
visualisation in the Layer Preview and featureinfo displays correct
information).
* commented out ImageComposerThread.rescaleImage - Layer Preview
displays
raster correctly (as long as I don't zoom out)
* tried to create GridCoverage2D using GridCoverageFactory.create()
method
that accepts MathTransform and using this transform to scale instead of
rescaling the image beforehand (this approach doesn't work with zoom out
either)

Since I am no expert in image processing or coverages, I am not sure how
best to fix this.

I may be doing something unconventional when creating my raster, so,
just
in
case, here is a list of sql commands I use to create test data:

Thanks
Nat

( I am using geoserver 2.4.1 and geotools 10.1 version)

Christian Mueller-3 wrote
> Some weeks ago, I did some major changes. Please switch to the lastest
> version or check out trunk from github.
>
> Christian
>
>
> On Thu, Oct 31, 2013 at 12:45 PM, Andrea Aime
> <

> andrea.aime@

> >wrote:
>
>> On Thu, Oct 31, 2013 at 12:34 PM, nroberts <

> nataliya_roberts@anonymised.com

> >wrote:
>>
>>> Hi Christian,
>>>
>>> I am using 9.5.
>>>
>>> I checked trunk svn a few weeks back (assuming this is a correct
>>> location
>>> for it:
>>>
>>>
http://svn.osgeo.org/geotools/trunk/modules/plugin/imagemosaic-jdbc/src/main/java/org/geotools/gce/imagemosaic/jdbc
>>> )
>>> and didn't spot any changes in the code in comparison to my my 9.5
>>> version.
>>> Should I try version 10+?
>>>
>>
>> Way off the mark I'm afraid, GeoTools has not been using svn for a
long
>> time now.
>> The sources are on github:
>> https://github.com/geotools/geotools
>>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more
>> information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via Poggio alle Viti 1187
>> 55054 Massarosa (LU)
>> Italy
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39 339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> -------------------------------------------------------
>>
>>
>>
------------------------------------------------------------------------------
>> Android is increasing in popularity, but the open development
platform
>> that
>> developers love is also attractive to malware creators. Download this
>> white
>> paper to learn more about secure code signing practices that can help
>> keep
>> Android apps secure.
>>
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Geoserver-users mailing list
>>

> Geoserver-users@anonymised.com

>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>
>>
>
>
> --
> DI Christian Mueller MSc (GIS), MSc (IT-Security)
> OSS Open Source Solutions GmbH
>
>
------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform
> that
> developers love is also attractive to malware creators. Download this
> white
> paper to learn more about secure code signing practices that can help
keep
> Android apps secure.
>
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> Geoserver-users mailing list

> Geoserver-users@anonymised.com

> https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5087186.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform
that
developers love is also attractive to malware creators. Download this
white
paper to learn more about secure code signing practices that can help
keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list

Geoserver-users@anonymised.com

https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform
that
developers love is also attractive to malware creators. Download this
white
paper to learn more about secure code signing practices that can help
keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list

Geoserver-users@anonymised.com

https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5087386.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Can you send a diff file of your hack.

Christian

···

On Tue, Nov 5, 2013 at 8:28 AM, nroberts <nataliya_roberts@anonymised.com> wrote:

Hi Christian,

In terms of rescaling, the following seems to work at least for 32 bit
integer rasters:

Now my problem is with startImage - it is created with underlying values of
‘0’, so when I pan or zoom out in Layer Preview, I get a black border around
my image (please see screenshots below)

Layer Preview for my test raster:
<http://osgeo-org.1560.x6.nabble.com/file/n5087386/test-raster.jpg>

Moved test raster a bit to the right top corner:
<http://osgeo-org.1560.x6.nabble.com/file/n5087386/test-raster-panned.jpg>

It looks as this happens because startImage is created with all ‘0’ values
in the underlying raster. So when we put tile image from PostGIS over the
top of it, there is a band of ‘0’ values left over (which shows up in black)
as the tile image doesn’t cover the entire start image.

I am experimenting with creating startImage using nodata values from PostGIS
and it seems to fix the black border problem. (hacked it for now to suit my
raster, but I imagine that it may be a bit more complicated to implement for
multi-band rasters)

Does that sound as an acceptable approach?

thanks
Nataliya

nroberts wrote

both 32 bit integer and float don’t work for me.

32 bit integer produces solid black image due to alll values being turned
into ‘0’ and 32 bit float throws ArrayOutOfBounds exception when
attempting to rescaleImage.

cheers
Nataliya
Christian Mueller-3 wrote

Yep, the rescale op is the problem.

Do you have a 32 bit float or integer raster. As far as I can remember,
integer rasters should work fine, float is causing the problem. I also
tried some different implemenations for the rescale operation, but none
was
working for float values.

Cheers
Christian

On Mon, Nov 4, 2013 at 8:32 AM, nroberts <

nataliya_roberts@anonymised.com

wrote:

Hi Christian,

thank you for the suggestion!

I have upgraded to 10.1 and the situation is a bit better, but I am
still
having a problem with my 32bit raster, albeit a slightly different one -
all
I can see now is a solid black image filling an entire image area in the
Layer Preview.

It looks to me as rescaleImage still doesn’t rescale single band 32 bit
raster image correctly: if I check image properties after rescale
operation,
the underlying raster contains all ‘0’ values.

Here is what I tried so far in an attempt to diagnose the problem:

  • exported raster into a .tiff file and reimported it into GeoServer
    using
    GeoTiff plugin - it appears to work fine (i.e I can see expected
    visualisation in the Layer Preview and featureinfo displays correct
    information).
  • commented out ImageComposerThread.rescaleImage - Layer Preview
    displays
    raster correctly (as long as I don’t zoom out)
  • tried to create GridCoverage2D using GridCoverageFactory.create()
    method
    that accepts MathTransform and using this transform to scale instead of
    rescaling the image beforehand (this approach doesn’t work with zoom out
    either)

Since I am no expert in image processing or coverages, I am not sure how
best to fix this.

I may be doing something unconventional when creating my raster, so,
just
in
case, here is a list of sql commands I use to create test data:

Thanks
Nat

( I am using geoserver 2.4.1 and geotools 10.1 version)

Christian Mueller-3 wrote

Some weeks ago, I did some major changes. Please switch to the lastest
version or check out trunk from github.

Christian

On Thu, Oct 31, 2013 at 12:45 PM, Andrea Aime
<

andrea.aime@

wrote:

On Thu, Oct 31, 2013 at 12:34 PM, nroberts <

nataliya_roberts@anonymised.com

wrote:

Hi Christian,

I am using 9.5.

I checked trunk svn a few weeks back (assuming this is a correct
location
for it:

http://svn.osgeo.org/geotools/trunk/modules/plugin/imagemosaic-jdbc/src/main/java/org/geotools/gce/imagemosaic/jdbc

)
and didn’t spot any changes in the code in comparison to my my 9.5
version.
Should I try version 10+?

Way off the mark I’m afraid, GeoTools has not been using svn for a
long
time now.
The sources are on github:
https://github.com/geotools/geotools

Cheers
Andrea

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it



Android is increasing in popularity, but the open development
platform
that
developers love is also attractive to malware creators. Download this
white
paper to learn more about secure code signing practices that can help
keep
Android apps secure.

http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk


Geoserver-users mailing list

Geoserver-users@anonymised.com

https://lists.sourceforge.net/lists/listinfo/geoserver-users


DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH


Android is increasing in popularity, but the open development platform
that
developers love is also attractive to malware creators. Download this
white
paper to learn more about secure code signing practices that can help
keep
Android apps secure.

http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk


Geoserver-users mailing list

Geoserver-users@anonymised.com

https://lists.sourceforge.net/lists/listinfo/geoserver-users


View this message in context:
http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5087186.html
Sent from the GeoServer - User mailing list archive at Nabble.com.


Android is increasing in popularity, but the open development platform
that
developers love is also attractive to malware creators. Download this
white
paper to learn more about secure code signing practices that can help
keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk


Geoserver-users mailing list

Geoserver-users@anonymised.com

https://lists.sourceforge.net/lists/listinfo/geoserver-users


DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH


Android is increasing in popularity, but the open development platform
that
developers love is also attractive to malware creators. Download this
white
paper to learn more about secure code signing practices that can help
keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk


Geoserver-users mailing list

Geoserver-users@anonymised.com

https://lists.sourceforge.net/lists/listinfo/geoserver-users

View this message in context: http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5087386.html

Sent from the GeoServer - User mailing list archive at Nabble.com.


November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk


Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

Hi Cristian,

the patch for the hack is attached.

32bit_raster.patch
<http://osgeo-org.1560.x6.nabble.com/file/n5087564/32bit_raster.patch&gt;

I did update my test raster to explicitely set noDataValue.

This patch only works for 32bit Integer rasters at the moment.

Also, there are some problems - zoom out still have some issues: either
black border surrounding the image or ArrayOutOfBoundsException, but panning
doesn't produce black border any more.

I am working on fixing these issues... Will attach another patch if/when I
fix it. If you think this solution is not suitable at all, can you please
let me know so I don't waste time on it

Thanks!
Nataliya

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5087564.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Attaching a slighly better patch (ArrayOutOfBoundsException in fixed on zoom
out)

32bit_raster-patch2.patch
<http://osgeo-org.1560.x6.nabble.com/file/n5087572/32bit_raster-patch2.patch&gt;

nroberts wrote

Hi Cristian,

the patch for the hack is attached.
32bit_raster.patch
<http://osgeo-org.1560.x6.nabble.com/file/n5087564/32bit_raster.patch&gt;

I did update my test raster to explicitely set noDataValue.

This patch only works for 32bit Integer rasters at the moment.

Also, there are some problems - zoom out still have some issues: either
black border surrounding the image or ArrayOutOfBoundsException, but
panning doesn't produce black border any more.

I am working on fixing these issues... Will attach another patch if/when I
fix it. If you think this solution is not suitable at all, can you please
let me know so I don't waste time on it

Thanks!
Nataliya

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5087572.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

yet another patch (detects single band 32 bit rasters and executes slightly
different code, otherwise using original code)

32bit_raster-patch3.patch
<http://osgeo-org.1560.x6.nabble.com/file/n5087775/32bit_raster-patch3.patch&gt;

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Image-Mosaic-JDBC-single-band-raster-losing-data-values-tp5058549p5087775.html
Sent from the GeoServer - User mailing list archive at Nabble.com.