[mapguide-internals] Updated MapGuide RFC 14 -CartographicStylization Engine

[Walt Welton-Lair]

My responses to your questions...

===========

1. We only have the updated layer definition schema and the new
symbolization schema.  The former currently includes the latter.

You mentioned a "symbolization resource schema" and a "schema for
symbolization elements".  I don't understand what you exactly mean by
these two.  The new CompositeTypeStyle and CompositeSymbolization
elements would be added to the layer definition schema.  Or were you
think of putting those in a separate file as well?

===========

2. The schema documentation is incorrect for LineWeightContext.
LineWeightContext is simply a boolean property that indicates whether
the line weight scales with the symbol.  IMO the default should be true,
since that's the behavior we're used to.

LineWeightContext is independent separate from SizeContext.  It also
applies to all contexts in which the symbol is used (point, line, area).

Should the name be changed?  IsLineWeightScalable?

Here's a simple example.  You have a symbol containing a square path of
length 10 on each side, and the line weight is set to 2.  If
LineWeightContext is true, then the path thickness is always 1/5 of the
symbol width, regardless of the SizeContext.  If LineWeightContext is
false, then the line weight is always 2 (mm) on the screen, regardless
of the size of the symbol.

[Traian, if I got that example wrong then please correct.]

===========

3. IMO there's some discrepancy between the layer definition schema and
the MdfModel code implementing it.  The schema does not have a Rule base
type from which PointRuleType, LineRuleType, and AreaRuleType inherit.
But it's how the MdfModel does it.

In the new schema I've purposely left out the old-style Label property
from the CompositeRule element because I don't want to mix the old and
new.  With the new symbology labels are defined using SymbolDefinitions.
You get the old style label using a SimpleSymbolDefinition containing
one Text graphic element.  Of course you need to also specify that the
symbol be treated as a label for rendering/overposting/positioning
purposes (more on that later).

The Rule class in MdfModel contains other things besides the Label - the
LegendLabel and the Filter.  I think CompositeRule therefore still needs
to extend Rule.  I would just ignore the Label property, as you
mentioned.  The documentation should clearly state that this property is
not used in the case of CompositeRule.

===========

4. The examples in the RFC really don't show true "labels".  They are
really just line styles that look like labels.  Example 1 sets the
StartOffset and Repeat parameters in LineUsage so that you draw the
highway shield symbol regularly along the feature, giving a labeling
effect.  For true labeling you typically also draw the symbol on top and
have it participate in overposting, and for that we now have additional
properties in SymbolInstance: DrawLast, CheckExclusionRegion, and
AddToExclusionRegion.

Furthermore, in the case of "true" labeling the position of the label
symbol is determined using some kind of labeling algorithm, while in the
normal drawing case the position of the symbol is determined from the
feature geometry using the rendering algorithm.

Some of us were discussion this earlier yesterday and today, and this
positioning behavior is one item that's still missing from the schema -
we need some hint that indicates how to compute the symbol position.
Maybe it's just a flag that says to use the rendering or labeling
algorithm - that's the simplest I think.

In the case of a symbol instance being used with a point layer, if you
set this algorithm hint to "labeling" then it would do the traditional
thing by computing the eight surrounding candidate positions and draw
the symbol at the first position that works.  In the case of a polygon
layer, it would compute one or more positions inside the polygon - the
AreaUsage is not used for this.

Note that I prefer adding this positioning algorithm hint rather than
adding a boolean IsLabel property, as this gives maximum flexibility.
To do labels as we have them today you would set:
    DrawLast=true
    CheckExclusionRegion=true
    AddToExclusionRegion=true
    PositionionAlgorithm=labeling

Each of these is independent.  For example, by changing DrawLast to
false the labeling symbol would now draw at the same time as regular
symbols.

You asked about CheckExclusionRegion.  This hint does not affect how the
symbol position is computed.  If set to true, it simply means always do
a check before drawing a symbol to find out if it overlaps anything in
the exclusion region, and if it does then don't draw it.

===========

5. Yes, we purposely avoided using "overpost" in any of the element
names.  The CheckExclusionRegion and AddToExclusionRegion hints are
independent.  See the previous item regarding CheckExclusionRegion.  If
AddToExclusionRegion is true that means add the extent of the rendered
symbol to the exclusion region *if* you rendered it.  The basic flow is
this:

    * compute symbol position, and symbol extent
    * if CheckExclusionRegion is true then:
        - if extent overlaps exclusion region then we're done
    * render symbol
    * if AddToExclusionRegion is true then:
        - add symbol extent to exclusion region

Note that the exclusion region is empty at the beginning of the map's
rendering pass, and grows as layers / features get rendered.

===========

6. Yes, CompoundSymbolDefinitions can be stored as resources.  The
documentation for the SymbolReference element says: "A library reference
to an existing SymbolDefinition."  Both Simple- and
CompoundSymbolDefinitions have base type SymbolDefinition, so I thought
it was enough.  But I can enhance the description a little more.

CompoundSymbolDefinitions are only allowed to have simple symbols as
children.  Of course someone could hack a compound symbol to have a
SimpleSymbolReference (a resource string) that points to another
compound symbol.  The code will have to check for that case and ignore
it.

We couldn't find a use case that required support for nesting of
compound symbols.  If done it would just be as a convenience to let a
map author reuse a set of his compound symbols to build up even more
complicated symbols.  But we don't think that case will come up often,
and we didn't feel it was worth the additional code complexity.  The
common case is to reuse simple symbols.


Walt
 

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Ben
Trumbore
Sent: Thursday, February 22, 2007 9:22 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] Updated MapGuide RFC 14
-CartographicStylization Engine

Walt,

I have a few questions about the updated schemas (version 5):

1. Now that the symbolization elements must be included in the layer
definition schema, will it be possible for both the layer and
symbolization resource schemas to reference (i.e. include) a single
schema for the symbolization elements?  I'm no XML expert - maybe the
answer to this is obvious.

2. How does the new LineWeightContext interract with the SizeContext of
a
SymbolInstance that refers to a LineUsage?  Does SizeContext only affect
point symbols and not lines?  What is the default for LineWeightContext?

3. By removing the Label element from CompositeRule, that class will not
cleanly derive from the Rule class in MdfModel.  We have competing
interests here: having the new classes fit into the existing object
model, and not providing two (incompatible) method for labeling the same
features.  We could, of course, derive from Rule just ignore the Label
member.  Thoughts?

4. Speaking of labels, the RFC gives several examples of graphic being
laid out along a line symbols (plain text labels would presumably be
similar), but no examples of labelling for points or polygons.  It isn't
clear to me how the position of such labels is controlled.

I assume DrawLast helps make labels show up on top of features.  That
name might be a bit misleading - is there something wrong with just
flagging it as a label?

How do we specify that a text symbol is meant to be dynamically placed
near a point feature (as it currently does) rather than being fixed at
the feature location?  If CheckExclusionRegion is false for a point
layer, is the symbolization placed right at the point (factoring in the
insertion point, etc).

Most of the AreaUsage elements seem relevant to specifying a fill
pattern for polygons, rather than to specifying a label that is
dynamically centered in the visible part of the polygon.  How do you
tell the difference between fill and and label here?  Does the
OriginControl element have anything to do with this?

5. Do I correctly understand that all "overpost" elements have been
replaced with a notion of an "exclusion region", and that symbolizations
can now say "Don't let anyone overpost me" and "I will overpost anything
I please"?  If so, which of those declarations takes precedence?

6. Can CompoundSymbols be stored as resources, or only SimpleSymbols?
The documentation for SymbolReference doesn't say.  The schema only
permits a CompoundSymbol to contain SimpleSymbols as children, and those
SimpleSymbols can be specified with a SimpleSymbolReference (essentially
the same as a SimpleSymbolReference, right?).  If CompountSymbols can be
resources, it's easy to imagine someone referring to a CompoundSymbol as
a child of a CompoundSymbol.  Would we treat that as bad data?  Is there
a good reason why we can't allow this?  It certainly isn't essential
functionality, and you've probably thought it through, so I'm just
curious.

	Ben

_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals