Allow multiple borders for areas with different offsets about libosmscout

[Framstag]

AREA.BORDER is now introduced to the style sheet, agg cairo and Qt backends have been adapted.

[vyskocil]

iOS and OSX backend have also been adapted.
Has the negative/positive offset already been implemented ?

[Framstag]

No, not yet. Next task would be:

• Extend OSS Syntax to allow multiple AREA.BORDER together with slot notation
• Extend StyleConfig to allow a list of BorderStyles (see existing objects with slot notation)
• Extend MapPainter to now handle list of BorderStyles returned by StyleConfig (instead of no or single instance)
• See how this gets mapped to AreaData
• Finally extends the OSS Syntax and BorderStyle with new attributes to define offset to area border, extend MapPainter to calculate new outline of area using offset and extend AreaData to hold this (optional) additional information

This will break StyleConfig API again and likely all render backends must be adapted again. It may be possible that one can handle the 1:n relation between area and its border by creating a new (special) AreaData for each border. This way MapPainter AreaData API would not break.

[Framstag]

Pushed change which introduced offset, displayOffset and priority attributes to BorderStyle. So we do not have multiple borders but backend could start implementing (with common to all backend changes to MapPainter, too) borders with offsets to the area shape.

[Framstag]

Now pushed support for multiple BORDERs in style sheet. MapPainter though only evaluates first entry in list. So the following tasks are now left:

• See how this gets mapped to AreaData
• extend MapPainter to calculate new outline of area using offset and extend AreaData to hold this (optional) additional information

[Framstag]

Next push:
Multiple borders are now syntactically possible an the MapPainter creates special AreaData instances for it. That means, multiple borders are now rendered if used in the style sheet.

However:

• The MapPainter derived class must be able to handle AreaData instances without a fillStyle (Qt backend was fixed)
• A border with an offset is not transformed well. That means that the resulting border line is overlapping some cases. Possibly e need a special TransformArea method instead of reusing the existing TransformWay method?
• An offset of 10m draws a 10m smaller area. This is irritating. Should be switch sign?
• The AreaData instances are not sorted optimally. In some cases neighbouring areas are overwriting parts of the (bigger than the original area) border. The bounding box must somehow get fixed for these borders :-/