Added combined placement option

[wibrahim]

List and simple placements were already supported by Shield and Text Symbolizers, but we can only use one of them at a time.
In the proposed changes, I combined both placements options into a single "combined" placements, were the engine tries the simple placement algorithm as specified first and if no placement is found, then it check its list placement options and re-applies the simple placement again.

A possible test case would be

<Map srs="+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs">
 <Style name="test_style">
        <Rule>
            <MarkersSymbolizer/>
            <TextSymbolizer face-name="DejaVu Sans Book" placement="point" dx="5" dy="-5" size="10" fill="green" justify-alignment="left" avoid-edges="true" adjust-edges="true" allow-overlap="false" clip="false" placement-type="combined" placements="N,NE,E,SE,S,SW,W,NW">[name]
                <Placement dx="10" dy="-10"  fill="blue"/>
                <Placement dx="10" dy="10"  fill="blue"/>
                <Placement dx="15" dy="-15"  fill="orange"/>
                <Placement dx="15" dy="15"  fill="orange"/>
                <Placement dx="20" dy="-20"  fill="yellow"/>
                <Placement dx="20" dy="20"  fill="yellow"/>
                <Placement dx="25" dy="-25"  fill="red"/>
                <Placement dx="25" dy="25"  fill="red"/>
                <Placement dx="35" dy="-35"  fill="purple"/>
                <Placement dx="35" dy="35"  fill="purple"/>
                <Placement dx="45" dy="-45"  fill="rgb(50,50,180)"/>
                <Placement dx="45" dy="45"  fill="rgb(50,50,180)"/>
            </TextSymbolizer>
        </Rule>
    </Style>

    <Layer name="test_layer" srs="+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs">
        <StyleName>test_style</StyleName>
        <Datasource>
            <Parameter name="type">csv</Parameter>
            <Parameter name="inline">
id|name|wkt
1|1st label|Point(-45 45)
2|2nd label|Point(-45 45)
3|3rd label|Point(-45 45)
4|4th label|Point(-45 45)
5|5th label|Point(-45 45)
6|6th label|Point(-45 45)
7|7th label|Point(-45 45)
8|8th label|Point(-45 45)
9|9th label|Point(-45 45)
10|10th label|Point(-45 45)
11|11th label|Point(-45 45)
12|12th label|Point(-45 45)
13|13th label|Point(-45 45)
14|14th label|Point(-45 45)
15|15th label|Point(-45 45)
16|16th label|Point(-45 45)
17|17th label|Point(-45 45)
18|18th label|Point(-45 45)
19|19th label|Point(-45 45)
20|20th label|Point(-45 45)
            </Parameter>
        </Datasource>
    </Layer>
</Map>

And the output is:

[springmeyer]

Thanks for the contribution! I can see the value in this. I'll try to find time to review in detail early next week.

[springmeyer]

Copyright should be Copyright (C) 2015 Artem Pavlenko as per https://github.com/mapnik/mapnik/blob/master/docs/contributing.markdown

[wibrahim]

no worries will change it, thanks for sharing the links

[talaj]

I think you should discard the first list placement before first call of this list_placement_info_->next(). The first list placement is default placement so you run through default placement twice.

[talaj]

I see adjust-edges="true" property of text symbolizer in your test case. What is it doing? It's not upstream feature : ).

[wibrahim]

@talaj it is a functionality I have been working on for awhile to fix marker placement across tile edges as they appear clipped. So far I got it working fine with MarkersSymbolizer, ShieldSymbolizers with point placement, and struggling to make it work with GroupSymbolizer.
The idea is simple, ensure that at least half the width and height of the bounding box of the placement for either marker or group symbolizers are within the un-buffered tile bounding box. This means that the actual placement will be moved from the original point placement.
I did not create a pull request yet cause I am still struggling to make it work with the GroupSymbolizer, but I am happy to share the code with you if you want to have a look.

Here is the original issue I reported before #2577

[springmeyer]

@wibrahim - sorry I've not had a chance to review this properly. I know I won't before upcoming 3.0.0 release, but I've assigned to post3x label so we prioritize reviewing soon after.