This change is being driven by:
- need for consistent terminology in the api. Currently there's
a confusing mix of border/outline used
- need for consistent terminology in the gui - we have a mix
of "border"/"outline"/"pen"
- bringing QGIS into line with the standard terminology used
in other graphic editing programs
features assigned to same color
This is the most cartographically pleasing color arrangement in my
opinion as it creates a nicely distributed set of colors.
When a new color is required, repeat the color assignment process.
This is the fastest part of the algorithm, so there's no noticable
speed drop. Repeating the whole coloring ensures that newly added
colors are properly balanced with respect to other colors, and avoids
the situation where one of the last features to be colored requires
a whole new class to be created, which will only have a few possible
members.
Overall this results in more balanced color assignment.
This mode attempts to assign colors in such a way that the total
area of features assigned to each color class is balanced. It helps
avoid larger features causing a single color class to appear more
dominant on a colored map.
This ports to old (pre 2.0!!) topocolor plugin to processing. It's based
off my beta 2.x fork (never publicly released) which implemented
a bunch of improvements to the algorithm allowing for minimal number
of required colors and also balanced counts of features assigned
each individual color.
** Pretty sure this plugin was highlighted in Victor's presentation
about plugins-which-shouldn't-be-plugins-and-should-be-processing-algs
instead. It's a prime example of a plugin where the amount of code
required for gui+setup exceeded the actual "guts" of the plugin by
a huge factor, and which is much more useful when it can be
integrated into a larger processing model.
If you have a layer with an unknown CRS, this algorithm gives a list
of possible candidate CRSes which the layer could be in.
It allows users to set the area (and corresponding CRS) which they know
the layer should be located near. The algorithm then tests every CRS
in the database to see what candidate CRSes would cause the layer
to be located at that preset area.
It's much faster than it sounds!! (just a couple of seconds)
Sponsored by SMEC/Surbana Jurong
