Status of AGG support?
Steve Lime
Steve.Lime at DNR.STATE.MN.US
Mon Jul 16 13:03:42 EDT 2007
Yes, I know that's there. I just don't have time before the 23rd. Will have to wait until 5.2.
Steve
>>> On 7/13/2007 at 9:42 PM, in message <4698381F.3090204 at swoodbridge.com>, Stephen
Woodbridge <woodbri at SWOODBRIDGE.COM> wrote:
> 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&ma
> p_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