[mapserver-dev] MS vs GS aesthetics

[Steve Lime]

Here's a page that references a couple of centroid options:

  http://www.spatialanalysisonline.com/output/html/Polygoncentroidsandcentres.html 

MapServer uses the MBR method and then falls back on a scanline conversion method
derived from polygon fill algorithms to guarantee a point in the polygon.

I could see adding a layer level parameter like LABELMETHOD to support various 
algorithms.

Steve

>>> On 9/11/2008 at 5:20 PM, in message <48C952C8.5157.008F.0 at dnr.state.mn.us>,
"Steve Lime" <Steve.Lime at dnr.state.mn.us> wrote:
> 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 
> 
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev