[mapserver-dev] MS vs GS aesthetics

[Steve Lime]

I did some testing today with the test case. The mapfile as downloaded will give you GD output, for the 
world. If you adjust the extent to match the states shapefile and the switch the renderer to AGG you 
get something very close to the sample. My findings:

On line thickness. 

AGG renders 1 pixel outline like the sample, it's simply a bit thicker. As MapServer sits we support only 
integer SIZE and WIDTH values. I mucked with the code today and changed both of those to doubles
and with that change you can set "WIDTH .5" in a STYLE to achieve a thinner outline. (see my example 
below)

The changes are small:

  - mapserver.h: change struct member types, min values for size and width go to 0 instead of 1 (perhaps .001 
    or something like that is better)
  - mapfile.c: change parsing to expect a double, change writing to use %g in format strings
  - mapogcsld.c: 3 spots where need to write the size so changed %d to %g in format strings
  - mapagg.cpp: the were for spots where agg was expecting an int for style->width so I round (MS_NINT) the value

The last change would be the most questionable. I can commit these changes if folks are interested. I think
we do want to do this in some shape or form

On missing labels:

MS and GS render the same size label (e.g. 16) differently. MS labels are larger. In the sample the larger labels
lead to more collisions and fewer labels on the map.

On label position:

GS is better here. MS currently uses a bbox midpoint test as a quick way to position a label in a polygon. If the result
isn't in the feature then we fall back on another algorithm. In this case that method results in a few poorly placed 
labels (CA, ID for example) which lead to collisions that one might not exect.

Curiously the code to compute a centroid is right there in mapprimitive.c. I'm not sure why it's not being used. I imagine
for performance reasons. If I use that instead of the simple bbox center we get results very similar to the GS sample. On
Florida's location still sucks. Clearly we should provide a couple of methods, perhaps letting the user choose. For regular
geometries (e.g. parcels) the fast method is more than adequate. 

Anyway, if I use an outline width of .5 and the centroid algorithm for default placement we get something like:

  http://maps.dnr.state.mn.us/~stlime/test.png

Steve

>>> On 9/11/2008 at 4:51 PM, in message
<d2b988930809111451h114808edw7afb3b2bd91936ef at mail.gmail.com>, "thomas bonfort"
<thomas.bonfort at gmail.com> wrote:
> I may have missed something, but it seems to me from the mapfile that
> that output is gd rendered. The image seems to be a screenshot from
> images pasted in a spreadsheet, and it looks as if there's some
> softening coming from somewhere.
> 
>> I'm not sure I believe the gs folks when they say their width is 1px,
>> it almost looks like less... I'd be interested to know if a 0.5 width
>> line on the trunk ms results in a similar quality of border.
> there's no possibility yet to set fractional line widths in mapserver.
> 
> An area where ms is way ahead of gs is in rendering linear data, as
> the gs renderer has some recurrent artifacts, eg
> http://sigma.openplans.org/geowebcache/service/wms?SRS=EPSG%3A900913&LAYERS=g 
> s%3Ahomepage&FORMAT=image%2Fpng&TILED=true&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMa
> p&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&BBOX=-8237621.092929687,496
> 6872.681484375,-8237468.21890625,4967025.555507813&WIDTH=256&HEIGHT=256
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev