Thanks Andrea,
At first I played with using mercator as pixels are square anywhere in the world, just the pixel size changes with latitude. Then, I realized that this would present problems to the mosaic driver, as it wants fixed sized pixels. After thinking about it for a while, I came up with this:
It should be possible to use WGS84 to store all raster data. We will use a constant pixel size in order to use the GeoServer mosaicing for any amount of data, anywhere in the world.
The pixel size can calculated by: Since, degrees of latitude are (more or less) equidistant from the equator to the poles, we can use 1/4 of the polar circumference of the earth to compute a desired pixel height. For example, if the pixels are 1 meter square, we would choose
1/circumferance in meters/4 = 90 / 10001966 = 8.998230947795663372580950585115e-6
Dropping some of the lsd, = 8.998230947e-6 degrees per pixel. This can be scaled by the input pixel size, eg 1/3 meter, 2/3 meter etc.
So, we can use this pixel size universally for images with source of 1m/pixel without losing any resolution. Nearer the poles, the source pixels will stretch over several destination pixels in the x direction, but when re-projected back to something like UTM, state plane, or Mercator, will resume their previous values with little loss of information, even with fairly primitive resampling algorithms like nearest neighbor.
Plus creation of tiles for GE should be reasonably fast, as well as projecting to most other projections, including spherical mercator (google projection).
I’ve written a program in C# (easily translated to Python or whatever, it just calls the various GDAL utilities) that takes in various raster formats and projections, chops them into 3.25 minute chunks in 4326 without losing resolution, merges with any 3.25 minute existing chunks, then finishes off by compressing into GeoTIFF Jpeg YCBCR with overviews after all the input files have been processed for a raster coverage. Seems to be a reasonable approach, way faster than those big MrSids, and almost the same size. And, no ugly black lines between source SID images. There are the usual non-nearblack artifacts around the entire perimeter of the mosaic, but nothing inside. This is the result of the jpeg compression and “shouldn’t” be an issue.
I hope to write this up for the GeoServer website as a “User experience” shortly after we do some more testing and look at the WCS results.
Roger
Roger Bedell, President Sylvan Ascent Inc.
800-362-8971
+34 626 855 662
roger@anonymised.com
www.sylvanascent.com
www.topodepot.com
From: Andrea Aime [mailto:aaime@anonymised.com…]
Sent: Fri 12/19/2008 6:01 AM
To: Sylvan Ascent Inc.
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Single Projection for Raster Storage
Sylvan Ascent Inc. ha scritto:
We are using Geoserver for a largish data warehouse sort of application,
and have lots of raster coming in from a variety of MrSids, GeoTiffs,
and other. In the past, I always liked to put everything in a standard
projection and format in the back end to simplify, usually this being
USGS quadrangle size, JPEG, in UTM. However, I’ve never liked it.
First, I’d like a single projection rather than all the UTM zones. Any
suggestions? It should be worldwide, polar zones not particularly
important yet. What does Geoserver prefer?
GeoServer does not have a preference for any specific projection.
What about storing the coverages in 4326? Or in the google projection?
Afaik there is no single projection working with high accuracy
on large areas, so I guess you expect your users to reproject
on the fly anyways? In that case, storing in 4326 reduces
the amount of work as at most one datum change/projection change
is required.
Also look out for image degradation due to multiple reprojections,
say your data is in UTM, you store it in 4326, some reprojects
it in the same UTM, the coverage you’ll get won’t be the same…
Uuh… since GeoServer can reproject on the fly anways, I have
the impression the best solution quality wise is to just leave
the data into their native projection and have users that need
them into some other
Second, what format does Geoserver like best? Likely, we’ll need
something with overviews like GTiff with overviews, some compression
would be nice but not essential.
Well, if you can afford the format conversion tools, jpeg2000
seems to be fast and has very good compression ratio, and also
has a lossless option. Coupled with GDAL plugin gives you a
cheap but effective option, if you can afford to buy
the Kakadu JPEG2000 library you’ll get a blazing fast option
instead.
Otherwise, Geotiff + overview + native
tiling is an evergreen, mix in jpeg compression if your data
can tolerate some degradation (as jpeg is lossy), deflate
compression otherwise.
Third, any ideas on a standard image size for the base layer?
Not sure what you mean… but with geotiff you’ll be limited
by the 2GB file size limit. I was playing with a 160.000x20.000
JPEG2000 just yesterday and it was working well, you can get
it here:
http://www.microimages.com/gallery/jp2/
(g30moslossles.jp2)
Cheers
Andrea
–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.