Re: [Geoserver-users] Image Mosaic JDBC single band raster losing data values
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@1616dd6
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@1136019
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
Re: [Geoserver-users] Image Mosaic JDBC single band raster losing data values
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
[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
2. mapping.pgraster.xml.inc
3. test.pgraster.xml.inc
]>
&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
contents
0.0
255.0
linear
cubic
test
test
test
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
