Status of AGG support?
Stephen Woodbridge
woodbri at SWOODBRIDGE.COM
Fri Jul 13 22:42:39 EDT 2007
Steve,
Have you seen that AGG has TrueType support and the ability to render
text directly along a curve? Although it seems to indicate that
performance is not great.
http://antigrain.com/demo/index.html#PAGE_DEMO_truetype_test
I'm not sure if there is a way to streat a polyline as a 1-degree
bspline or a curve to take advantage of that.
-Steve W
Steve Lime wrote:
> Steve (et. al): It's definitely the alpha channel issue mentioned in the RFC. AGG writes a value of 255 (opaque) which gdInterprets as 127 (transparent) and that leads munged text. Try turning the text in your example from ANGLE FOLLOW to ANGLE 45 and watch what happens as text crosses AGG pixels.Until we either:
>
> - write all symbols and text in AGG or
> - GD gets a proper RGBA representation
>
> this will be a problem. One easy solution is just to reset the alpha channel to 0 after rendering vector layers using AGG. In mapdraw.c around line 692 you do:
>
> /* Must be a Vector layer */
> else
> {
> retcode = msDrawVectorLayer(map, layer, image_draw);
> if( MS_RENDERER_AGG(image_draw->format) && layer->opacity == 100 ) { /* reset alpha channel */
> int x, y;
> for (y = 0; (y < image_draw->img.gd->sy); y++) {
> for (x = 0; (x < image_draw->img.gd->sx); x++) {
> int c = gdImageGetPixel(image_draw->img.gd, x, y);
> gdImageSetPixel(image_draw->img.gd, x, y, gdTrueColorAlpha(gdImageRed(image_draw->img.gd, c), gdImageGreen(image_draw->img.gd, c), gdImageBlue(image_draw->img.gd, c), 0));
> }
> }
> }
> }
>
> It's going slower and blows away the alpha values (only a rasters can set them) but it certainly works. I'm looking for other ideas. Ideally it would be great if AGG just skipped the alpha channel altogether and just left it alone. Haven't figured out how to do that.
>
> Steve
>
>
>>>> Stephen Woodbridge <woodbri at swoodbridge.com> 07/12/07 12:29 AM >>>
> Steve Lime wrote:
>> I can re-create on my box. Switching to GD (e.g. IMAGETYPE PNG24)
>> doesn't exhibit the same problem. It doesn't make any sense though
>> since AGG isn't rendering the text, it's just handing off to the
>> GD-based label cache. Looking into it.
>>
>> Your example didn't contain the palette you had defined.
>
> Sorry, attached.
>
>> Also, your
>> arial.ttf file is huge, 24Mb, why?
>
> It is the full UNICODE version of the font. it should not matter, you
> can delete it and point it to the smaller version that you might have.
>
> -Steve W.
>
>> Steve
>>
>>>>> Stephen Woodbridge <woodbri at SWOODBRIDGE.COM> 07/11/07 9:07 AM
>> Assefa,
>>
>> I created and ran this test last night, based on the current svn
>> source. Can you reproduce the black ugly text that follows the
>> spiral. Can anyone else reproduce the image below on their local
>> builds? If not, then I might have a .configure or build issue with my
>> system:
>>
>> woodbri at carto:/u/data$ uname -a Linux carto 2.6.15-1-em64t-p4-smp #2
>> SMP Tue Mar 7 08:19:39 UTC 2006 x86_64 GNU/Linux
>>
>> You can download a zip file with everything you need to reproduce
>> this test locally. http://imaptools.com/downloads/spiral-test.zip
>>
>> http://imaptools.com/cgi-bin/mapserv-4.99?mode=map&map=/u/data/test/spiral.map
>>
>> http://imaptools.com/cgi-bin/mapserv-4.99?mode=map&map=/u/data/test/spiral.map&map_imagetype=PNG8
>>
>>
>> MAP NAME "spiral test map" EXTENT -26 -26 26 26 SIZE 700 700 FONTSET
>> "fontset.txt" IMAGECOLOR 153 179 204 UNITS DD IMAGETYPE "agg/png24"
>>
>> OUTPUTFORMAT NAME "agg/png24" MIMETYPE "image/png; mode=24bit" DRIVER
>> "AGG/PNG" EXTENSION "png" IMAGEMODE "RGB" FORMATOPTION
>> "PALETTE_FORCE=TRUE" FORMATOPTION
>> "PALETTE=/u/data/maps/palette-google-agg.txt" END
>>
>> OUTPUTFORMAT NAME PNG8 DRIVER "GD/PNG" EXTENSION "png" MIMETYPE
>> "image/png" IMAGEMODE RGBA TRANSPARENT OFF FORMATOPTION
>> "QUANTIZE_FORCE=ON" FORMATOPTION "QUANTIZE_DITHER=OFF" FORMATOPTION
>> "QUANTIZE_COLORS=256" END
>>
>> LAYER NAME "Annotation" STATUS DEFAULT TYPE ANNOTATION FEATURE POINTS
>> -25 -25 END TEXT "Simple Label" END LABELCACHE OFF CLASS COLOR 0 0 0
>> LABEL FONT "arial" TYPE TRUETYPE POSITION ur SIZE 14 BUFFER 4 COLOR
>> 50 50 50 OUTLINECOLOR 238 238 238 ANTIALIAS TRUE PARTIALS FALSE
>> MINDISTANCE 250 MINFEATURESIZE 10 END END END
>>
>> LAYER NAME "Spiral" STATUS DEFAULT DATA "spiral" TYPE LINE
>> TRANSPARENCY ALPHA LABELITEM "NAME" CLASS STYLE COLOR 170 153 136
>> WIDTH 20 ANTIALIAS TRUE END STYLE COLOR 255 255 255 WIDTH 17
>> ANTIALIAS TRUE END LABEL ANGLE FOLLOW FONT "arial" TYPE TRUETYPE
>> POSITION CC SIZE 14 BUFFER 4 COLOR 0 0 0 ANTIALIAS TRUE PARTIALS
>> FALSE END END END
>>
>> END
>>
>>
>> -Steve
>>
>>
>> Yewondwossen Assefa wrote:
>>> screen grab for label ALIGN FOLLOW
>>>
>>>
>>> Stephen Woodbridge wrote:
>>>> Assefa,
>>>>
>>>> Thanks.
>>>>
>>>> 1) Can you confirm that the code you explained below is what is
>>>> currently in SVN? 2) What does your OUTPUTFORMAT look like? 3) Is
>>>> there anything special that I need to do to reproduce this? Does
>>>> not scheme for generating the palette.txt file meet the
>>>> requirements of the implemented algorithm. 4) Did you try LABEL
>>>> ALIGN FOLLOW? and did you get labels that looked better than the
>>>> comparison that I showed below?
>>>>
>>>> Best regards, -Steve
>>>>
>>>>
>>>> Yewondwossen Assefa wrote:
>>>>> Steve,
>>>>>
>>>>> We tried different ways to allocate an appropriate color
>>>>> palette for 24-8 bit conversion and at the end the following
>>>>> seems to give a good results from the tests we did (function
>>>>> in mapgd.c msImageCreateWithPaletteGD):
>>>>>
>>>>> - use gd function gdImageCreatePaletteFromTrueColor to create
>>>>> an image with a number of colors 256 - number of colors from
>>>>> the static palette file - final image would use the generated
>>>>> colors + the ones that are defined in the palette color.
>>>>>
>>>>> It adds an additional step/time to do it and there could
>>>>> probably be some optimizing but It seems to work ok specially
>>>>> for maps generated for tiled environment like kaMap.
>>>>>
>>>>> Best Regards
>>>>>
>>>>>
>>>>> Stephen Woodbridge wrote:
>>>>>> Paul, Assefa,
>>>>>>
>>>>>> How would I use that?
>>>>>>
>>>>>> Also, I commented out the
>>>>>>
>>>>>> #FORMATOPTION "PALETTE_FORCE=TRUE" #FORMATOPTION
>>>>>> "PALETTE=/u/data/maps/palette-google-agg.txt"
>>>>>>
>>>>>> but the label follows test still looks the same.
>>>>>>
>>>>>> -Steve
>>>>>>
>>>>>> Paul Spencer wrote:
>>>>>>> Steve (and Steve),
>>>>>>>
>>>>>>> I believe Assefa committed a change that allows you to
>>>>>>> specify a fixed partial palette and GD interpolates the
>>>>>>> remaining colours.
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>> Paul
>>>>>>>
>>>>>>> On 7-Jul-07, at 12:53 AM, Stephen Woodbridge wrote:
>>>>>>>
>>>>>>>> Steve Lime wrote:
>>>>>>>>> Thanks, that's why the output blows. The forced palette
>>>>>>>>> has no room for interpretation those are the only
>>>>>>>>> colors allocated in the output image and all colors are
>>>>>>>>> mapped to that palette. That is done after all
>>>>>>>>> rendering is complete. It works this way to support
>>>>>>>>> tiling to that colors are absolutely consistent from
>>>>>>>>> tile to tile. The option really isn't useful beyond
>>>>>>>>> offline mass tiling.
>>>>>>>> OK, well then have we tried an alternative approach to
>>>>>>>> handling the palette. That would be to take the approach
>>>>>>>> that I thought it was doing :)
>>>>>>>>
>>>>>>>> If you define the palette using the method that I
>>>>>>>> described that would freeze the primary colors used in
>>>>>>>> the mapfile. All other palette colors would be allowed to
>>>>>>>> be generated dynamically as needed. When the color
>>>>>>>> reduction process runs it would have to honor those
>>>>>>>> colors in the palette, but could also add additional
>>>>>>>> colors as needed in the additional slots. This would fix
>>>>>>>> the big color shifts that we were seeing in the tiling
>>>>>>>> and any shifting in the anti-aliasing between meta-tiles
>>>>>>>> would probably not be noticeable.
>>>>>>>>
>>>>>>>> I think the current approach it way to rigid and
>>>>>>>> absolute, but it might be useful for some situations.
>>>>>>>>
>>>>>>>> If the above is relatively easy to implement, I would be
>>>>>>>> happy to run some tests on it.
>>>>>>>>
>>>>>>>> -Steve W
>>>>>>>>
>>>>>>>>> Steve
>>>>>>>>>>>> Stephen Woodbridge <woodbri at SWOODBRIDGE.COM>
>>>>>>>>>>>> 07/05/07 11:28 PM
>>>>>>>>> Steve Lime wrote:
>>>>>>>>>> For comparison purposes I would use 24-bit png
>>>>>>>>>> regardless. My question would be how is the palette
>>>>>>>>>> being constructed? Ideally
>>>>>>>>> I take a very simple approach to the palette.txt file
>>>>>>>>> and that is: grep -i color mapfile.map > a.txt #edit
>>>>>>>>> a.txt a bunch sort -u a.txt > palette.txt wc -l
>>>>>>>>> palette.txt 36 so the rest of the colors can be
>>>>>>>>> allocated for anti-alias colors. -Steve W
>>>>>>>>>> you would create a representative image with lot's of
>>>>>>>>>> linework and annotation and then use Gimp,
>>>>>>>>>> Imagemagick or Photoshop to reduce colors to a 8-bit
>>>>>>>>>> palette and use that. Otherwise the palette force
>>>>>>>>>> option will do a distance computation and the results
>>>>>>>>>> could get ugly (and these images are proof)... Steve
>>>>>>>>>>>>> Paul Spencer <pspencer at DMSOLUTIONS.CA> 07/05/07
>>>>>>>>>>>>> 9:32 PM >>>
>>>>>>>>>> PHP? Steve, I'm shocked its not a perl page ;) I have
>>>>>>>>>> noticed that the text gets 'bolder' when reducing the
>>>>>>>>>> palette, but not like this. Have you tried without
>>>>>>>>>> the formatoption for reducing the image? One thing
>>>>>>>>>> that may happen is that the antialiasing colours are
>>>>>>>>>> getting mapped to black because there isn't room in
>>>>>>>>>> the palette to allocate the needed colours. That
>>>>>>>>>> does seem unlikely, though. Cheers Paul On 5-Jul-07,
>>>>>>>>>> at 4:56 PM, Stephen Woodbridge wrote:
>>>>>>>>>>> Steve,
>>>>>>>>>>> http://imaptools.com/maps/compare-maps2.php?loc=2&ll=41.85
>>>>>>>>>>>
>>>>>>>>>>> +-87.65&address=&city=&state=&zipcode=&country=&asrv=1&amf=%2Fu%
>>>>>>>>>>>
>>>>>>>>>>> 2Fdata%2Fmaps%2Fgoogle-aa2.map&msa=mapserv-4.10&bsrv=1&bmf=%2Fu%
>>>>>>>>>>>
>>>>>>>>>>> 2Fdata%2Fmaps%2Fgoogle-agg.map&msb=mapserv-4.99&submit=Show
>>>>>>>>>>> Here is a side by side comparison. google-aa2 is
>>>>>>>>>>> using "PNG8" google-agg is using "agg/png24"
>>>>>>>>>>> OUTPUTFORMAT NAME "agg/png24" MIMETYPE "image/png;
>>>>>>>>>>> mode=24bit" DRIVER "AGG/PNG" EXTENSION "png"
>>>>>>>>>>> IMAGEMODE "RGB" FORMATOPTION "PALETTE_FORCE=TRUE"
>>>>>>>>>>> FORMATOPTION
>>>>>>>>>>> "PALETTE=/u/data/maps/palette-google-agg.txt" END
>>>>>>>>>>> ONE of the differences is mapserver-4.10 vs
>>>>>>>>>>> mapserv-4.99 and the fact that 4.99 has broken
>>>>>>>>>>> support for: OUTPUTFORMAT NAME PNG8 DRIVER "GD/PNG"
>>>>>>>>>>> EXTENSION "png" MIMETYPE "image/png" IMAGEMODE RGBA
>>>>>>>>>>> TRANSPARENT OFF FORMATOPTION "QUANTIZE_FORCE=ON"
>>>>>>>>>>> FORMATOPTION "QUANTIZE_DITHER=OFF" FORMATOPTION
>>>>>>>>>>> "QUANTIZE_COLORS=256" END as none of the roads
>>>>>>>>>>> render. -Steve Steve Lime wrote:
>>>>>>>>>>>> Would be nice to have a non-tiled, side-by-side
>>>>>>>>>>>> browser to do the comparison with... ;-) It
>>>>>>>>>>>> doesn't look to me like identical mapfiles. For
>>>>>>>>>>>> example, I'm looking at Chicago and there look to
>>>>>>>>>>>> be some differences in scale settings. For
>>>>>>>>>>>> example, the shape of Lake Michigan changes
>>>>>>>>>>>> dramatically, see:
>>>>>>>>>>>> http://maps.dnr.state.mn.us/~stlime/chicago_gd.gif
>>>>>>>>>>>>
>>>>>>>>>>>> http://maps.dnr.state.mn.us/~stlime/chicago_agg.gif
>>>>>>>>>>>> I'll wait on other comments until that can be
>>>>>>>>>>>> confirmed. Steve
>>>>>>>>>>>>>>> On 7/4/2007 at 10:47 AM, in message
>>>>>>>>>>>>>>> <468BC11E. 2050101 at swoodbridge.com>,
>>>>>>>>>>>>>>> Stephen
>>>>>>>>>>>> Woodbridge <woodbri at SWOODBRIDGE.COM> wrote:
>>>>>>>>>>>>> Hi Zak, Thank you and the others for all the
>>>>>>>>>>>>> responses. I got it working this morning:
>>>>>>>>>>>>> http://imaptools.com/agg-test.html I have a few
>>>>>>>>>>>>> questions and observations: The OL app above
>>>>>>>>>>>>> has two base layers. Both use the same mapfile,
>>>>>>>>>>>>> except one supports AGG and is using 5.0 and
>>>>>>>>>>>>> the other is using 4.10. 1) Notice the white
>>>>>>>>>>>>> lines in the water boarding some of the
>>>>>>>>>>>>> polygons. What is causing that? How do you get
>>>>>>>>>>>>> rid of these? 2) If you switch between 4.10 and
>>>>>>>>>>>>> 5.0 AGG base layers notice that the road widths
>>>>>>>>>>>>> change. What is causing this? I assume this is
>>>>>>>>>>>>> the same issue as the polygons above. 3) If you
>>>>>>>>>>>>> zoom in to 15K scale of closer so street names
>>>>>>>>>>>>> are displayed the text looks really bad on text
>>>>>>>>>>>>> ALIGN FOLLOW labels. And the text is much
>>>>>>>>>>>>> bolder and blacker than the 4.10 example. more
>>>>>>>>>>>>> below ... Zak James wrote:
>>>>>>>>>>>>>> Steve, In our testing, the AGG renderer is
>>>>>>>>>>>>>> about 10% faster than GD over a variety of
>>>>>>>>>>>>>> conditions. One caveat is that the sub-pixel
>>>>>>>>>>>>>> positioning of vertices (which greatly
>>>>>>>>>>>>>> improves the appearance of features) can
>>>>>>>>>>>>>> cause far longer rendering times if suitable
>>>>>>>>>>>>>> overview data aren't available for a given
>>>>>>>>>>>>>> scale. We discussed but did not implement
>>>>>>>>>>>>>> strategies for mitigating this problem.
>>>>>>>>>>>>> I think that discussion should get added to the
>>>>>>>>>>>>> RFC. If I wanted to provide my own overview
>>>>>>>>>>>>> data what are we talking about. Just having
>>>>>>>>>>>>> generalized data? Any rule of thumb on when you
>>>>>>>>>>>>> need to provide this?
>>>>>>>>>>>>>> Another issue is that the antialiasing tends
>>>>>>>>>>>>>> to cause larger image file sizes.
>>>>>>>>>>>>> There really is not much that you can do about
>>>>>>>>>>>>> this. It will impact on bandwidth and tile
>>>>>>>>>>>>> repository sizes. -Steve
>>>>>>>>>>>>>> zak On 7/3/07, Stephen Woodbridge
>>>>>>>>>>>>>> <woodbri at swoodbridge.com> wrote:
>>>>>>>>>>>>>>> Paul, Steve, A few questions: 1) could one
>>>>>>>>>>>>>>> of you do a short post on what if anything
>>>>>>>>>>>>>>> needs to be done to use AGG other than
>>>>>>>>>>>>>>> install the libs and select some ./
>>>>>>>>>>>>>>> configure options. 2) Any sense on how this
>>>>>>>>>>>>>>> compares speed wise to the GD
>>>>>>>>>>>>>>> implementation. 3) is what is in the trunk
>>>>>>>>>>>>>>> all that 5.0 will see or is there some
>>>>>>>>>>>>>>> additional work that is planed to be
>>>>>>>>>>>>>>> implemented. I would like to give it a try.
>>>>>>>>>>>>>>> -Steve W Paul Spencer wrote:
>>>>>>>>>>>>>>>> The other thing that I am very keen to
>>>>>>>>>>>>>>>> have is text rendered/ placed using AGG.
>>>>>>>>>>>>>>>> Not sure if it will be done for 5.0
>>>>>>>>>>>>>>>> though. Cheers Paul On 3-Jul-07, at 1:25
>>>>>>>>>>>>>>>> PM, Steve Lime wrote:
>>>>>>>>>>>>>>>>> Hi Tom: AGG support is in the codebase
>>>>>>>>>>>>>>>>> for 5.0. I still owe an RFC to explain
>>>>>>>>>>>>>>>>> what was done although the addition of
>>>>>>>>>>>>>>>>> AGG doesn't affect any other portions
>>>>>>>>>>>>>>>>> of MapServer. It's a big user feature
>>>>>>>>>>>>>>>>> though. I recently got a big time sink
>>>>>>>>>>>>>>>>> off my plate and will work that up
>>>>>>>>>>>>>>>>> ASAP. The support is relatively
>>>>>>>>>>>>>>>>> complete. The guys from DM Solutions
>>>>>>>>>>>>>>>>> can probably comment further as they've
>>>>>>>>>>>>>>>>> been using it the most. The AGG vs. GD
>>>>>>>>>>>>>>>>> images DM has supplied are very nice.
>>>>>>>>>>>>>>>>> The quality difference is noticeable
>>>>>>>>>>>>>>>>> with roads in
>>>>>>>>>>>>>>> particular.
>>>>>>>>>>>>>>>>> The only missing capability that I am
>>>>>>>>>>>>>>>>> aware of has to do with PIXMAP symbols
>>>>>>>>>>>>>>>>> that contain an alpha channel. There is
>>>>>>>>>>>>>>>>> a fundamental difference in how AGG and
>>>>>>>>>>>>>>>>> GD handle alpha blending (GD is flat
>>>>>>>>>>>>>>>>> out backwards). We use GD to manage
>>>>>>>>>>>>>>>>> the pixel buffer that AGG is rendering
>>>>>>>>>>>>>>>>> into so that becomes a problem. I'll go
>>>>>>>>>>>>>>>>> into options in the RFC. Anyway, other
>>>>>>>>>>>>>>>>> than that the support seems to be
>>>>>>>>>>>>>>>>> working nicely is worth trying. Steve
>>>>>>>>>>>>>>>>>>>> On 7/1/2007 at 10:08 PM, in
>>>>>>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>>>> <7b5b710d0707012008i59c41e8bq8e0ef4d8022f40f8 at mail.gmail.com>,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> T om
>>>>>>>>>>>>>>> Beard
>>>>>>>>>>>>>>>>> <tom at PROJECTX.CO.NZ> wrote:
>>>>>>>>>>>>>>>>>> Hi there, This is my first time
>>>>>>>>>>>>>>>>>> posting here, and I hope this is the
>>>>>>>>>>>>>>>>>> right forum to ask this question. I
>>>>>>>>>>>>>>>>>> was wondering what the status of AGG
>>>>>>>>>>>>>>>>>> support was for the 5.0 release. On
>>>>>>>>>>>>>>>>>> searching the archives, the most
>>>>>>>>>>>>>>>>>> recent reference I could find was
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> minutes from the May 22 IRC meeting
>>>>>>>>>>>>>>>>>> that said that there would be
>>>>>>>>>>>>>>> an RFC
>>>>>>>>>>>>>>>>>> freeze on June 15, and that an RFC
>>>>>>>>>>>>>>>>>> for AGG was "forthcoming". Did AGG
>>>>>>>>>>>>>>>>>> support make it into that freeze? Is
>>>>>>>>>>>>>>>>>> it listed somewhere online? I'd also
>>>>>>>>>>>>>>>>>> be interested to know if there is a
>>>>>>>>>>>>>>>>>> version currently in Subversion that
>>>>>>>>>>>>>>>>>> includes AGG sub-pixel rendering and
>>>>>>>>>>>>>>>>>> that works well enough to have a go
>>>>>>>>>>>>>>>>>> at compiling on Windows. Regards, Tom
>>>>>>>>>>>>>>>>>> Beard
>>>>>>>>>>>>>>>> +----------------------------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -+ |Paul Spencer pspencer at dmsolutions.ca
>>>>>>>>>>>>>>>> |
>>>>>>>>>>>>>>>> +----------------------------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -+ |Chief Technology Officer | |DM
>>>>>>>>>>>>>>>> Solutions Group Inc http://
>>>>>>>>>>>>>>>> www.dmsolutions.ca/ |
>>>>>>>>>>>>>>>> +----------------------------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -+
>>>>>>>>>> +-----------------------------------------------------------------+
>>>>>>>>>> |Paul Spencer
>>>>>>>>>> pspencer at dmsolutions.ca |
>>>>>>>>>> +-----------------------------------------------------------------+
>>>>>>>>>> |Chief Technology Officer | |DM Solutions Group Inc
>>>>>>>>>> http://www.dmsolutions.ca/ |
>>>>>>>>>> +-----------------------------------------------------------------+
>>>>>>>>>>
>>>>>>> +-----------------------------------------------------------------+
>>>>>>> |Paul Spencer
>>>>>>> pspencer at dmsolutions.ca |
>>>>>>> +-----------------------------------------------------------------+
>>>>>>> |Chief Technology Officer
>>>>>>> | |DM Solutions Group Inc
>>>>>>> http://www.dmsolutions.ca/ |
>>>>>>> +-----------------------------------------------------------------+
>>>>>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
More information about the mapserver-dev
mailing list