GeoServer

WorldWind DDS Map Producer

Details

  • Type: New Feature New Feature
  • Status: In Progress In Progress
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 2.1.x
  • Fix Version/s: 2.1.x
  • Component/s: WMS
  • Labels:
    None
  • Environment:
    Java
  • Number of attachments :
    3

Description

Test, upgrade and the DDS texture production capability from the plugin produced here:
http://forum.worldwindcentral.com/showthread.php?t=18819
to Geoserver core.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tisham Dhar added a comment -

BIL and DDS support compiled jar and source. Needs worldwind.jar as a dependency.

Show
Tisham Dhar added a comment - BIL and DDS support compiled jar and source. Needs worldwind.jar as a dependency.
Hide
Permalink
Tisham Dhar added a comment -

Updated build with resources included and new layout

Show
Tisham Dhar added a comment - Updated build with resources included and new layout
Hide
Permalink
Tisham Dhar added a comment -

New source code layout

Show
Tisham Dhar added a comment - New source code layout
Hide
Permalink
Tisham Dhar added a comment -

Working BIL/DDS community module

Show
Tisham Dhar added a comment - Working BIL/DDS community module
Hide
Permalink
Ivan Grcic added a comment -

Hi Tisham,

ive just tried module, it works ok for dds havent still tried with bil format but ill test it soon also.

Just few notices i had:

dds files are pretty large for transport (several times larger then jpegs, even larger then pngs), why wouldnt we make dds-zip format also?
I got 2-10 times smaller files then uncompressed dds.

That way we would have format that wwj client wont have to process much (only decompress which isnt so expensive) and it would be pretty smaller then normal dds files.

I think there is allready some code in WWJ that takes in account dds-zip format, but i dont know if its implmented somewhere yet. If you can take a look at:

wwj\src\gov\nasa\worldwind\layers\BasicTiledImageLayer.java

else if (contentType.contains("zip"))

{ // Assume it's zipped DDS, which the retriever would have unzipped into the buffer. this.layer.saveBuffer(buffer, outFile); }

and methods:
wwj\src\gov\nasa\worldwind\util

public static void deflateBufferToFile
public static ByteBuffer readZipEntryToBuffer

(Also, in AnalyticsSurface demo there is example how to read zipped bil entry)

What do you think?

Oh and by the way I guess GWC support for dds is coming (...you probably allready knew about it :
http://geowebcache.org/trac/changeset/826

Regards,
Ivan

Show
Ivan Grcic added a comment - Hi Tisham, ive just tried module, it works ok for dds havent still tried with bil format but ill test it soon also. Just few notices i had: dds files are pretty large for transport (several times larger then jpegs, even larger then pngs), why wouldnt we make dds-zip format also? I got 2-10 times smaller files then uncompressed dds. That way we would have format that wwj client wont have to process much (only decompress which isnt so expensive) and it would be pretty smaller then normal dds files. I think there is allready some code in WWJ that takes in account dds-zip format, but i dont know if its implmented somewhere yet. If you can take a look at: wwj\src\gov\nasa\worldwind\layers\BasicTiledImageLayer.java else if (contentType.contains("zip")) { // Assume it's zipped DDS, which the retriever would have unzipped into the buffer. this.layer.saveBuffer(buffer, outFile); } and methods: wwj\src\gov\nasa\worldwind\util public static void deflateBufferToFile public static ByteBuffer readZipEntryToBuffer (Also, in AnalyticsSurface demo there is example how to read zipped bil entry) What do you think? Oh and by the way I guess GWC support for dds is coming (...you probably allready knew about it : http://geowebcache.org/trac/changeset/826 Regards, Ivan
Hide
Permalink
Ivan Grcic added a comment -

Actually WWJ WMS server serves data as application/zip so its allready supported

( TiledImageLayer -> HTTPRetriever -> URLRetriever's method doRead handles it:

if (this.contentType != null && this.contentType.equalsIgnoreCase("application/zip"))
buffer = this.readZipStream(inputStream, connection.getURL()); // assume single file in zip and decompress it

Cheers,

Ivan

Show
Ivan Grcic added a comment - Actually WWJ WMS server serves data as application/zip so its allready supported ( TiledImageLayer -> HTTPRetriever -> URLRetriever's method doRead handles it: if (this.contentType != null && this.contentType.equalsIgnoreCase("application/zip")) buffer = this.readZipStream(inputStream, connection.getURL()); // assume single file in zip and decompress it Cheers, Ivan
Hide
Permalink
Tisham Dhar added a comment -

Geoserver gzip compresses data being sent out so over wire cost is low. There is no need to compress twice just configure your server:

http://geoserver.org/display/GEOSDOC/2.6+GeoServer+in+Production+Environment

Cheers,

Tisham.

Show
Tisham Dhar added a comment - Geoserver gzip compresses data being sent out so over wire cost is low. There is no need to compress twice just configure your server: http://geoserver.org/display/GEOSDOC/2.6+GeoServer+in+Production+Environment Cheers, Tisham.
Hide
Permalink
Ivan Grcic added a comment -

Hi,

Yes I thougt of that, but WWJ reads only zip format not gzip. I guess we'll just have to wait for them to implement gzip reader also, as its stated in URLRetriever class

// TODO: Make decompression of zip file configurable
// TODO: Make this more generally configurable based on content type
// todo: make a zip reader that handles streams of unknown length
// TODO: add a gzip reader
// TODO: this code is checking content type for compression when it should be checking content encoding,
// but the WW servers are sending application/zip as the content type, and null for the content encoding.

cheers

Show
Ivan Grcic added a comment - Hi, Yes I thougt of that, but WWJ reads only zip format not gzip. I guess we'll just have to wait for them to implement gzip reader also, as its stated in URLRetriever class // TODO: Make decompression of zip file configurable // TODO: Make this more generally configurable based on content type // todo: make a zip reader that handles streams of unknown length // TODO: add a gzip reader // TODO: this code is checking content type for compression when it should be checking content encoding, // but the WW servers are sending application/zip as the content type, and null for the content encoding. cheers
Hide
Permalink
Andrea Aime added a comment -

The gzip compression GeoServer is using is part of the HTTP 1.1 protocol, so WWJ should be able to use it transparently, afaik uDig is not doing anything special to read our gzip compressed GML data streams, the http library handles that.

However, for a mime type to be compressed it has to be included in the gzip filter white list found in the web.xml file:

<param-value>text/.,.*xml.,application/json,application/x-javascript</param-value>

I guess dds and bil are not covered

Show
Andrea Aime added a comment - The gzip compression GeoServer is using is part of the HTTP 1.1 protocol, so WWJ should be able to use it transparently, afaik uDig is not doing anything special to read our gzip compressed GML data streams, the http library handles that. However, for a mime type to be compressed it has to be included in the gzip filter white list found in the web.xml file: <param-value>text/.,.*xml.,application/json,application/x-javascript</param-value> I guess dds and bil are not covered

People

Vote (2)
Watch (5)

Dates

  • Created:
    Updated:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.