Re: [deegree-devel] WMS image decode/encode
OSGeo project deegree
Brought to you by:
deegreesfadmin,
tfr
From: Andreas S. <sc...@la...> - 2010-02-16 16:29:21
|
Falko Bräutigam wrote: Hi, > I'm new to this list so first of all: thanks for your great work on Degree2 and especially > Deegree3! thank you! > Although I'm new to the list we have been using Deegree2 for a long time in the current > version 2 of our project Polymap. In Polymap2 we are just using the client WFS code of > Deegree2 to connect to remote (Deegree) WFS servers. Works great! :) Thanks again. > > The upcoming Polymap3 is a complete new codebase based on Eclipse/RAP. We are planning to > use Deegree3 as the standard WMS/WFS server. I'm currently testing and figuring out how to > do it best. For Polymap3 I'm interested in the WMS/WFS controllers of Deegree3. I need to > use them without the XML configuration. > > The overall architecture: > > [Deegree WMS/WFS servler/controller] <-> [Processing pipeline] <-> [Datastores] > > The Processing Pipeline is something we introduced in Polymap2. It allows to freely > configure the data processing by building a chain of Processors. Processors can transform > data, cache result etc. In Polymap2 we did this just for image data of WMS. For Polymap3 > we are going to implement this also for features of WFS. > > My first concrete question in this regard is about the semantics of > org.deegree.services.wms.MapService. It seem to serve as the backend of the WMS > controllers. It exposes some methods that could be a good API of the WMS Processing > Pipeline: Those methods are: > > - getLegend( GetLegendGraphic req ) > - getMap( GetMap gm ) > - getFeatures( GetFeatureInfo fi ) > - ... The MapService is indeed supposed to be the layer between the datastores/the rendering and the protocol layer. It knows about some layer structure, and produces a result based on that and a abstract request object. > Unfortunately the getMapImage() returns a BufferedImage and the encoding code is in the > WMSController. In my eyes this introduces the following disadvantages: It's not completely thought/implemented through yet, so all suggestions/use cases are highly welcome. > - if the backend system is a WMS, then the image data gets > unnecessarily decoded/encoded granted. > - the entire image data is loaded before reponse is send (no > streaming) I'm a little unsure how streaming will work for a WMS. Are you referring to streamed GIF/PNG images? In comparison with the rest of the map service processing, the en/decoding of images seems not to matter too much (for us at least). > - for Polymap3 a cannot have the image encoding as a regular step in > the processing pipeline What else would you suggest instead? My first thought was to use a Graphics2D object, which I did not favour because it limits the use of rendering backends (we're thinking of an alternative OpenGL based 2D renderer). And the conceptual 'goal' of the map service is to produce maps (or features, for GFI). But I've got a fourth point for the list: - to produce a vector format such as KML/SVG one needs more detailed information about the map (which cries out for the Graphics2D parameter again). But it's funny that you have the requirement of switching the MapService. We were thinking of switching the controller classes, switching the data stores, switching the rendering engine etc., but I think we were never thinking of switching the map service... Would it be an option for you to write a custom map service, which eg. produces its result into an output stream? If so, it could be made configurable pretty easy I guess. Best regards, Andreas -- l a t / l o n GmbH Aennchenstrasse 19 53177 Bonn, Germany phone ++49 +228 18496-0 fax ++49 +228 1849629 http://www.lat-lon.de http://www.deegree.org |