Add API for "Annotation layers"

[nyalldawson]

This PR adds the underlying API for a new QgsMapLayer subclass: "QgsAnnotationLayer".

An annotation layer is designed for freeform drawing of georeferenced objects, which don't have any of the constraints of adding objects to a standard vector layer. They don't have fields, and can contain many different types of drawing objects in a single layer (e.g. markers, lines, text objects, etc). The annotation items are all spatially referenced, so are attached to particular geographic geometries (potentially allowing for them to be converted to real vector layers in future).

Use cases for annotation layers include:

• exposing very simple and quick to use drawing tools for users who are not "GIS savvy", yet who have a need to digitize/draw geographically referenced markup
• allowing easy to use tools for cartographically touching up a map, e.g. adding specific text labels to a map which aren't associated with any particular layer or feature, and which can be moved and manipulated in a freeform way
• exposing drawing tools which don't fit into the "simple features specification" for vector layers, e.g. a curved text object which follows a bezier curve

An annotation layer consists of a set of items which are subclasses of QgsAnnotationItem. Included in this PR are three annotation item types:

• QgsAnnotationMarkerItem, for placement of a marker symbol on a map
• QgsAnnotationLineStringItem, for drawing a linestring which is styled by a line symbol
• QgsAnnotationPolygonItem, for drawing polygon regions styled by a fill symbol

(future PRs will add various text item subclasses too)

This work is loosely based off the redlining tools support from Sourcepole's Kadas fork, but with many changes:

• rendering has been made thread safe
• item classes are managed by a central registry, allowing for easy addition of new item types and for plugin based annotation item types
• the included marker/line/polygon item types all rely on QgsSymbol classes for rendering, and each individual item of these types in an annotation layer can have its own unique appearance using the full range of QGIS symbology which is available for point/line/polygon items (including draw effects)

No GUI is exposed for working with annotation layers -- funding is sought for adding this (I'll be launching a crowdfund for this shortly). For now, it's the underlying API only.

Sponsored by the QGIS Swiss user group.

[Saijin-Naib]

😭🙇‍♂️🙏

This is so important!

Thanks Nyall & SUG!

[nyalldawson]

@m-kuhn @nirvn any chance of a review?

[m-kuhn]

Very cool stuff !!!!!

[m-kuhn]

What's the reason for items having individual crs (rather than all being in layer crs)?

[nyalldawson]

Good question! I had my slyr hat on here, and annotations in ESRI world are stored using a referenced geometry + crs pair. So approaching it like this makes it easier to translate between the two. I don't see any problem in particular with this approach, expect a bit of extra code complexity. But I'm not set on it if you think it's a mistake...

[m-kuhn]

I was wondering what we gain (not sure if ESRI compatibility alone is convincing). I was a bit afraid of complexity: project crs vs layer crs vs item crs seems a lot of reprojection and possible room for missing one.

[nyalldawson]

Ah - but an annotation layer itself has no CRS. So it's just map CRS vs item CRS.

[m-kuhn]

Hmm, every layer has a QgsMapLayer::crs() by design.

[nyalldawson]

...But since a while we've supported returning invalid crs objects from this as a reflection of "no crs" 😁

[m-kuhn]

How are you going to work with this UI wise? Add it with the current project CRS? Will the CRS change if an item is moved?

[nyalldawson]

Ok, I'm convinced. I'll rework this!

[nirvn]

Great stuff.

[nyalldawson]

Unrelated test failure