[Geoserver-users] geotiff's Using the ImageMosaic plugin and displayed within geoserver appear to be less than full resolution (6 inch)

John_Mitchell · April 27, 2007, 4:07pm

Hi,

For Geotiff’s Using the ImageMosaic plugin and displayed within geoserver appear to be less than full resolution (6 inch), compared to looking at the same images within the desktop application global mapper or when displaying the data with UMN MapServer. Is there any additional parameters that need to be filled in when configuring using the http://docs.codehaus.org/display/GEOSDOC/Using+the+ImageMosaic+plugin link in order to get the best quality and resolution?
I have attached the info.xml, .properties and .prj files.

Thanks,

–
John J. Mitchell

info.xml (2.62 KB)

fullResolution.properties (159 Bytes)

fullResolution.prj (675 Bytes)

Andrea_Aime3 · April 27, 2007, 5:23pm

John Mitchell ha scritto:

Hi,

For Geotiff's Using the ImageMosaic plugin and displayed within geoserver appear to be less than full resolution (6 inch), compared to looking at the same images within the desktop application global mapper or when displaying the data with UMN MapServer. Is there any additional parameters that need to be filled in when configuring using the http://docs.codehaus.org/display/GEOSDOC/Using+the+ImageMosaic+plugin link in order to get the best quality and resolution?
I have attached the info.xml, .properties and .prj files.

Hmmm... are you sure it's not a matter of interpolation? Geoserver
default to not interolating data, showing pixels as they are,
many apps do use bilinear interpolation to give you the illusion
you have more resolution than real (but it's fake, and slows down
rendering).

Try enabling bilinear interpolation in the WMS settings, do you
get better results now?

Cheers
Andrea

John_Mitchell · April 27, 2007, 6:29pm

Hi,

I tried enabling bilinear interpolation in the WMS settings, and I still have the issue with 6 inch geotiff data pixelizing much sooner with geoserver compared to mapserver or the desktop application global mapper. I did find that a different 20 meter geotiff did not pixelize prematurely compared to other applications like the 6 inch geotiff did. So maybe geoserver just has a problem very high resolution imagery like 6 inch.

Has anyone who has both used geoserver and umn mapserver (in the past) for high resolution geotiff’s had similar problems?

Thanks,

John J. Mitchell

On 4/27/07, Andrea Aime <aaime@anonymised.com> wrote:

John Mitchell ha scritto:

Hi,

For Geotiff’s Using the ImageMosaic plugin and displayed within
geoserver appear to be less than full resolution (6 inch), compared to
looking at the same images within the desktop application global mapper
or when displaying the data with UMN MapServer. Is there any additional
parameters that need to be filled in when configuring using the
http://docs.codehaus.org/display/GEOSDOC/Using+the+ImageMosaic+plugin
link in order to get the best quality and resolution?
I have attached the info.xml, .properties and .prj files.

Hmmm… are you sure it’s not a matter of interpolation? Geoserver
default to not interolating data, showing pixels as they are,
many apps do use bilinear interpolation to give you the illusion
you have more resolution than real (but it’s fake, and slows down
rendering).

Try enabling bilinear interpolation in the WMS settings, do you
get better results now?

Cheers
Andrea

–
John J. Mitchell

Andrea_Aime3 · April 27, 2007, 6:32pm

John Mitchell ha scritto:

Hi,

I tried enabling bilinear interpolation in the WMS settings, and I still have the issue with 6 inch geotiff data pixelizing much sooner with geoserver compared to mapserver or the desktop application global mapper. I did find that a different 20 meter geotiff did not pixelize prematurely compared to other applications like the 6 inch geotiff did. So maybe geoserver just has a problem very high resolution imagery like 6 inch.

Has anyone who has both used geoserver and umn mapserver (in the past) for high resolution geotiff's had similar problems?

Nope. As you can see, imagery support in Geoserver is pretty new...
can you provide us a data sample?

Cheers
Andrea

Paul_McCullough · January 15, 2008, 3:31am

All,

Has this been resolved?
I believe I am having the same problem.
Background and environment:
- windows xp sp 2,
- geoserver 1.5.x "out of the box" (jetty etc)
- carefully followed these instructions (several times:-)

http://docs.codehaus.org/display/GEOSDOC/Using+the+ImageMosaic+plugin
- 7 level pyramid constructed using gdal tools
- level0: 33K files
- level6: 8 files
- each files at each level is about 775Kb, geotiff, no overview
- triple checked properties files, especially the levels parm
- recreated level0 and tested in isolation
- tried fiddling with resampling settings
- I have not double checked my prj files.

In all cases, geoserver is not serving up my six inch data (level0) - it
quite clearly samples to about 1 foot or there abouts. I thought I might
have level1 and level0 crossed up, or I though I might have my SLDs fouled
up - I triple check and reconstructed the coverages - all resulting in same
issue.

This is not a deal killer but it looks quite bad.

If this turns out to be a bug (doubtful), I would expect it to be a small
one. I am a competent oo/java developer - and would be able to assist with
a patch as long as I could get some guidance re where to start.

aaime wrote:

John Mitchell ha scritto:

Hi,

I tried enabling bilinear interpolation in the WMS settings, and I still
have the issue with 6 inch geotiff data pixelizing much sooner with
geoserver compared to mapserver or the desktop application global
mapper. I did find that a different 20 meter geotiff did not pixelize
prematurely compared to other applications like the 6 inch geotiff did.
So maybe geoserver just has a problem very high resolution imagery like
6 inch.

Has anyone who has both used geoserver and umn mapserver (in the past)
for high resolution geotiff's had similar problems?

Nope. As you can see, imagery support in Geoserver is pretty new...
can you provide us a data sample?

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
View this message in context: http://www.nabble.com/geotiff's-Using-the-ImageMosaic-plugin-and-displayed-within-geoserver-appear-to-be-less-than-full-resolution-(6-inch)-tp10222232p14827674.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Andrea_Aime3 · January 16, 2008, 3:18pm

Paul McCullough ha scritto:

All,

Has this been resolved?
I believe I am having the same problem.
Background and environment:
- windows xp sp 2, - geoserver 1.5.x "out of the box" (jetty etc)
- carefully followed these instructions (several times:-)

Paul, I've been looking into the mosaic you sent me and
I've reproduced the resolution problem as well... and fixed
it too.

The thing is, the prj you have looks nothing like the ones
contained in the EPSG database. It is similar to EPSG:2227,
but not equal.

When a coverage native prj does not match what you've been
providing an on the fly reprojection occurrs from the
native srs to the one declared and... there hell gates
do open because reprojection ruins your image.

There are two solutions for this illness:
* modify your prj to match exactly one of the official
   epsg codes definition (that's tricking, because your
   data is actually in a different system)
* add your definition to user_projection/epsg.properties
   as a custom projection, say epsg:200000 (pick a free code)
   and then use it to configure your data.

With vector data we allow two more srs handilng option:
* force: disregard the native srs because it's wrong (it
   happens) and use the official code provided instead
* leave: use the epsg code in the capabilities to make
   OGC happy, but keep on using the actual native
   (and nameless) srs

I guess we should add these to coverage handling too...
opened a jira issue to deal with it (at least to add
"force", "leave" has been only a source of troubles
so far in the vector land):
http://jira.codehaus.org/browse/GEOS-1677

Cheers
Andrea

Paul_McCullough · January 23, 2008, 7:29pm

All,
If you recall, my geoserver image mosaic had some strange behaviors:
- not displaying highest resoltution
- displaying black lines between tiles (new info)
- image quality poor in some cases (new info)
Turns out that I was confusing geoserver.
The data are in EPSG 102643.
I had told geoserver that the data were in EPSG 2227.
Thats not all though.
All details below.
Paul

DETAILS
Our organization uses ESRI state plane zone 3.
In preparing the mosiac with open source, I chose to use EPSG 2227
because a casual inspection suggested it was the same.
After all, it had the same name. Well, it's not the same.
You really must use exactly the same projection.
Thanks, Andrea, for helping me with this bit.
RE this thread

So, I studied projections a bit more; a good site for this is
  http://spatialreference.org/
(Thanks Christopher and Howard!)
Spatialreference.org calls our particular ESRI projection "102643".
Here it is (from http://spatialreference.org/ref/epsg/102643/)
PROJCS["NAD_1983_StatePlane_California_III_FIPS_0403_Feet",
    GEOGCS["GCS_North_American_1983",
          DATUM["North_American_Datum_1983",
          SPHEROID["GRS_1980",6378137,298.257222101]],
          PRIMEM["Greenwich",0],
          UNIT["Degree",0.017453292519943295]
    ],
      PROJECTION["Lambert_Conformal_Conic_2SP"],
      PARAMETER["False_Easting",6561666.666666666],
      PARAMETER["False_Northing",1640416.666666667],
      PARAMETER["Central_Meridian",-120.5],
      PARAMETER["Standard_Parallel_1",37.06666666666667],
      PARAMETER["Standard_Parallel_2",38.43333333333333],
      PARAMETER["Latitude_Of_Origin",36.5],
      UNIT["Foot_US",0.30480060960121924],
      AUTHORITY["EPSG","102643"]
  ]
I added the Spatialreference.org definition as a user projection to
geoserver
  RE
http://docs.codehaus.org/display/GEOSDOC/Custom+projection+definition+in+Geoserver+1.5.0+(onwards)
and had the same problem as above
  RE this thread

Time for a diff.
So, here is one of our projection files created by ArcMap 9.2:
PROJCS["NAD_1983_StatePlane_California_III_FIPS_0403_Feet",
    GEOGCS["GCS_North_American_1983",
      DATUM["D_North_American_1983",
      SPHEROID["GRS_1980",6378137.0,298.257222101]],
      PRIMEM["Greenwich",0.0],
      UNIT["Degree",0.0174532925199433]
    ],
    PROJECTION["Lambert_Conformal_Conic"],
    PARAMETER["False_Easting",6561666.666666666],
    PARAMETER["False_Northing",1640416.666666667],
    PARAMETER["Central_Meridian",-120.5],
    PARAMETER["Standard_Parallel_1",37.06666666666667],
    PARAMETER["Standard_Parallel_2",38.43333333333333],
    PARAMETER["Latitude_Of_Origin",36.5],
    UNIT["Foot_US",0.3048006096012192]
  ]
See the difference?
It may not matter to you, but apparently it matters to Geoserver.
- units are rounded by ESRI
- projection is different
- other seemingly immaterial differences (0 vs 0.0)
I don't know which difference is material.
In any case, once I put the exact ESRI projection into geoserver, everthing
worked.

--
View this message in context: http://www.nabble.com/geotiff's-Using-the-ImageMosaic-plugin-and-displayed-within-geoserver-appear-to-be-less-than-full-resolution-(6-inch)-tp10222232p15048940.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Andrea_Aime3 · January 24, 2008, 9:03am

Paul McCullough ha scritto:

Spatialreference.org calls our particular ESRI projection "102643".
Here it is (from http://spatialreference.org/ref/epsg/102643/)
PROJCS["NAD_1983_StatePlane_California_III_FIPS_0403_Feet",
    GEOGCS["GCS_North_American_1983",
          DATUM["North_American_Datum_1983",
          SPHEROID["GRS_1980",6378137,298.257222101]],
          PRIMEM["Greenwich",0],
          UNIT["Degree",0.017453292519943295]
    ],
      PROJECTION["Lambert_Conformal_Conic_2SP"],
      PARAMETER["False_Easting",6561666.666666666],
      PARAMETER["False_Northing",1640416.666666667],
      PARAMETER["Central_Meridian",-120.5],
      PARAMETER["Standard_Parallel_1",37.06666666666667],
      PARAMETER["Standard_Parallel_2",38.43333333333333],
      PARAMETER["Latitude_Of_Origin",36.5],
      UNIT["Foot_US",0.30480060960121924],
      AUTHORITY["EPSG","102643"]
  ]
I added the Spatialreference.org definition as a user projection to
geoserver RE
http://docs.codehaus.org/display/GEOSDOC/Custom+projection+definition+in+Geoserver+1.5.0+(onwards)
and had the same problem as above
  RE this thread

Time for a diff.
So, here is one of our projection files created by ArcMap 9.2:
PROJCS["NAD_1983_StatePlane_California_III_FIPS_0403_Feet",
    GEOGCS["GCS_North_American_1983",
      DATUM["D_North_American_1983",
      SPHEROID["GRS_1980",6378137.0,298.257222101]],
      PRIMEM["Greenwich",0.0],
      UNIT["Degree",0.0174532925199433]
    ],
    PROJECTION["Lambert_Conformal_Conic"],
    PARAMETER["False_Easting",6561666.666666666],
    PARAMETER["False_Northing",1640416.666666667],
    PARAMETER["Central_Meridian",-120.5],
    PARAMETER["Standard_Parallel_1",37.06666666666667],
    PARAMETER["Standard_Parallel_2",38.43333333333333],
    PARAMETER["Latitude_Of_Origin",36.5],
    UNIT["Foot_US",0.3048006096012192]
  ]
See the difference?
It may not matter to you, but apparently it matters to Geoserver.
- units are rounded by ESRI
- projection is different
- other seemingly immaterial differences (0 vs 0.0)
I don't know which difference is material.
In any case, once I put the exact ESRI projection into geoserver, everthing
worked.

I believe the unit difference is the one that causes the issue, since
it forces a different interpretation of the grid.
Cheers
Andrea