[Geoserver-devel] svn wms renderering broken ?

Hi all,

I have just compiled the svn sources (for integrating gif support based on
GEOS-199 and Patrick Schlaepfer's work) and found that WMS returns a blank
image for image/png format (and a broken image for image/gif which so far
correct for git). I checked with geoserver 1.2.3, and WMS returns a correct
png image with the same getMap query.

Can someone tell me if the WMS rendering is stable enough in the svn sources ?

BTW, for image/svg+xml, i got the following :

7729266 [FIN] org.vfny.geoserver.responses.wms.GetMapResponse - setting up map
7729269 [FIN] org.geotools.data.postgis.PostgisDataStore - get Feature source
called on serie_rouge
7729270 [FIN] org.geotools.data.postgis.PostgisDataStore - returning pg
feature locking7729319 [FIN] org.vfny.geoserver.responses.wms.GetMapResponse
- asking delegate for aborting the process
7729321 [FIN] org.vfny.geoserver.responses.wms.map.SVGMapResponse - aborting
SVG map response
7729323 [INFO] org.vfny.geoserver.servlets.AbstractService - Had an undefined
error: Pending of implementation
7729344 [FIN] org.vfny.geoserver.ServiceException -
java.lang.UnsupportedOperationException: Pending of implementation

which seems to be a thrown exception from SVGMapResponse.java, produceMap().
Is the SVG encoder ready to be tested ?

didier

Hi Richard,

the move to geotools 2.1 came up with this issue. I noticed that getmap
requests were returning blank images and I'm currently working on it,
hope to have answers soon.

In order to afford the fix, I'm just creating some unit tests.
Preliminary work is on svn and also there is a demo for creating a cite
like map. This uses the property datastore to provide cite data.

Please check that it works for you. Just copy <geos-dir>/cite/confDemo
to <geos-dir>/conf,then run ant test, go to the demo section in the
geoserver web gui, and select the cite-map.url request.

It should return a map for the cite dataset.

In the mean time, I think this working example could serve you to go
forward in implementing gif output support, just implement the gif
support as explained bellow and run this same request.

I wonder if you'll need not to rely in the current JAI based map
producer.
If so, notice the architectural change in the process:
JaiMapResponse was refactored to JAIMapProducer

it no longer inherits from GetMapResponse. Instead, GetMapResponse just
does the job of obtaining the GetMapRequest and building a MapContext,
which in turn is passed to the GetMapProducer found for the required
output format. This finding is done by GetMapProducerFactorySpi
implementations, through FactoryFinder.

So, you'll have to:
- Create a "GIFMapProducerFactory", which implements
GetMapProducerFactorySpi and creates "GIFMapProducer"'s
- Add an entry to the file
src/META-INF/services/org.vfny.geoserver.responses.wms.GetMapProducerFactorySpi
which the full qualified name of your gif factory.

this way, GetMapResponse will be able of finding the factory and
creating a new GIFMapProducer whenever image/gif output format is
requested.

Hope this helps, please ask for any more problem you find.

About SVG support.. well... I think it has to be redone from scratch,
but if you need it I can manage to keep it working just as it was before
the mentioned change. (actually I will do it right now.)

best regards,

Gabriel.

On Wed, 2005-02-23 at 17:24 +0100, Richard didier wrote:

Hi all,

I have just compiled the svn sources (for integrating gif support based on
GEOS-199 and Patrick Schlaepfer's work) and found that WMS returns a blank
image for image/png format (and a broken image for image/gif which so far
correct for git). I checked with geoserver 1.2.3, and WMS returns a correct
png image with the same getMap query.

Can someone tell me if the WMS rendering is stable enough in the svn sources ?

BTW, for image/svg+xml, i got the following :

7729266 [FIN] org.vfny.geoserver.responses.wms.GetMapResponse - setting up map
7729269 [FIN] org.geotools.data.postgis.PostgisDataStore - get Feature source
called on serie_rouge
7729270 [FIN] org.geotools.data.postgis.PostgisDataStore - returning pg
feature locking7729319 [FIN] org.vfny.geoserver.responses.wms.GetMapResponse
- asking delegate for aborting the process
7729321 [FIN] org.vfny.geoserver.responses.wms.map.SVGMapResponse - aborting
SVG map response
7729323 [INFO] org.vfny.geoserver.servlets.AbstractService - Had an undefined
error: Pending of implementation
7729344 [FIN] org.vfny.geoserver.ServiceException -
java.lang.UnsupportedOperationException: Pending of implementation

which seems to be a thrown exception from SVGMapResponse.java, produceMap().
Is the SVG encoder ready to be tested ?

didier

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Le Jeudi 3 Mars 2005 19:08, Gabriel Roldán a écrit :

Hi Richard,

I'm also not pretty sure that using the bgcolor as the transparent one
is the optimal solution.
What happens, for example, if one have an sld which fills polygons or
strokes with that same color? (i.e., sld says polygon interior is blank,
map bgcolor is also blank.. will be polygon interiors be blank or
transparent?)

If I'm not wrong, you have to setup a color ramp (pallete?) for each gif
image. What if you choose ona "random" color that you know was not used
as a foreground color? is it possible or I am just plain wrong?

According to the WMS specs, TRANSPARENT set to TRUE addresses "pixels not
representing features or data values"... "When TRANSPARENT is set to FALSE,
non-data pixels shall be set to the value of BGCOLOR."

To my understanding, TRANSPARENCY only covers pixels where there is no data,
meaning that we have to choose a special color to be transparent (as you
wrote).
I believe that (for the moment) BGCOLOR is just a round-about solution, but
useful cause the white color (default BGCOLOR) is not often used as a
feature's color (except for ice/snow in which cases it is not a plain white
:-).
Any other thought ?

cheers,

Gabriel.

regards,

didier

Le Jeudi 3 Mars 2005 20:23, Gabriel Roldán a écrit :

do you have any idea why seems to return black backgrounds instead of
transparent ones? or it may be just my firefox not understanding it?

No idea. When BGCOLOR=0x000000 (BLACK) all is transparent. I suggested to
contact Patrick Schlaepfer cause he submitted to GIFOutputstream.java (See
GEOS-199).

didier

On Thu, 2005-03-03 at 19:24 +0100, Richard didier wrote:

Le Jeudi 3 Mars 2005 19:08, Gabriel Roldán a écrit :
> Hi Richard,
>
> I'm also not pretty sure that using the bgcolor as the transparent one
> is the optimal solution.
> What happens, for example, if one have an sld which fills polygons or
> strokes with that same color? (i.e., sld says polygon interior is blank,
> map bgcolor is also blank.. will be polygon interiors be blank or
> transparent?)
>
> If I'm not wrong, you have to setup a color ramp (pallete?) for each gif
> image. What if you choose ona "random" color that you know was not used
> as a foreground color? is it possible or I am just plain wrong?

According to the WMS specs, TRANSPARENT set to TRUE addresses "pixels not
representing features or data values"... "When TRANSPARENT is set to FALSE,
non-data pixels shall be set to the value of BGCOLOR."

To my understanding, TRANSPARENCY only covers pixels where there is no data,
meaning that we have to choose a special color to be transparent (as you
wrote).
I believe that (for the moment) BGCOLOR is just a round-about solution, but
useful cause the white color (default BGCOLOR) is not often used as a
feature's color (except for ice/snow in which cases it is not a plain white
:-).

Actually that's not true. You're right that white is the default
bgcolor, but is is used a lot for styling features, as in the very
example from the spec, where a road is colored by a thick red line with
a thin white line over it. Can you forward this issue to Patrick?

Any other thought ?

no more by now.

>
> cheers,
>
> Gabriel.
>

regards,

didier