[mapserver-dev] MS vs GS aesthetics

[David Fuhry]

In a recent release, Oracle MapViewer added automatic label rotation for 
polygons (in 45-degree increments only).  It's not configurable and 
there's no information available on their methods, but the result is 
looks good:

http://kddb1.kddb.cs.kent.edu/tmp/oracle_mapviewer_wv.jpeg

A LABELMETHOD tag would be nice to allow a choice of labeling 
techniques, assuming some more advanced ones get implemented.

-Dave


Steve Lime wrote:
> 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
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev