[mapguide-internals] Updated MapGuide RFC14-CartographicStylization Engine

[Walt Welton-Lair]

More responses following yours...

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: Monday, February 26, 2007 10:18 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] Updated MapGuide
RFC14-CartographicStylization Engine

Walt,

Thanks for your reply.  My responses are at the end of each section.

	Ben

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Walt
Welton-Lair
Sent: Friday, February 23, 2007 7:46 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] Updated MapGuide RFC
14-CartographicStylization Engine

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?

[Ben Trumbore] I should have looked this up before writing.  I see now
that XSD has an <include> element that would allow layer definitions to
share a single definition for the new symbolization classes, which was
my main concern.  I would like to see us move towards having the MDF
object model classes and parsers automatically generated from the
schemas, and it isn't clear to me how that will work with included
schemas.  It would be undesirable to have two sets of symbolization
classes (one that is freestanding and another as part of the layer
definition classes).  Does anybody have experience with this sort of
situation?

[Walt Welton-Lair] Ideally the tools used to auto-generate classes
from a schema can handle include statements.

[Ben Trumbore] I somehow thought that a schema for a resource had some
overhead beyond the elements that described the important classes.  So,
I imagined that both a layer resource schema and a (tiny) symbolization
resource schema could refer to a symbolization "guts" schema.  If the
overhead is nonexistent or small and presents no conflicts, I'm fine if
the layer resource schema includes a complete symbolization resource
schema and never uses the overhead part that it contains.

[Walt Welton-Lair] The plan is simply to add the new symbolization
schema and make a few additions to the layer definition schema:
- add the new types in MDF_Changes_v5.xsd
- update VectorScaleRangeType to include CompositeTypeStyle as
  one of the type style choices
- use an <include> statement to reference the new symbolization
  schema

===========

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.]

[Ben Trumbore] Thanks for the explanation and example.  As for the name,
how about LineWeightIsScalable?

[Walt Welton-Lair] LineWeightIsScalable sounds reasonable to me.

===========

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.

[Ben Trumbore] Deriving from Rule and ignoring Label is OK with me (at
least for now).  If we automatically "bind" the schema to an object
model as I mention above, the layer definition schema will have to
change to formally specify the derivations from Rule.  There may be
other similar discrepancies between the schema and current object model.

===========

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.

[Ben Trumbore] I see your point about keeping the controls separate, and
it makes sense.  I would ask that we allow label position algorithms to
have parameters that control their behavior, which would require a
modification to the specific solution you suggest above.  We may want to
have placement algorithms that allow some or all of the following:
  one label per geometry
  one label per group of geometries with same feature ID
  multiple labels per geometry based on size or shape
  labels only on geometries that are large enough
  labels follow the spine of a polygon or a curve fit through points

[Walt Welton-Lair] Your request make sense, but it's not a trivial
amount of work to think the design through and update the schema.
Let me discuss this with some of the other people involved.

===========

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.

[Ben Trumbore] Is the exclusion region cleared before the DrawLast
symbolizations are drawn?  Is it desirable to make that an option so
feature overposting can be separated from label overposting?  Maybe when
a symbolization is added to the exclusion region it could be added to
the first pass or last pass or both.

[Walt Welton-Lair] The exclusion region is not cleared - I don't
think you want to do that.  Imagine having a point layer and you
don't want any of the point symbols to be obscured by labels.  You
render the symbols first - the symbolization settings would use:
    DrawLast=false
    CheckExclusionRegion=false
    AddToExclusionRegion=true
    PositionionAlgorithm=rendering
So after each point symbol is drawn its extent is aded to the
exclusion region.  Now we draw the labels - the symbolization
settings would be:
    DrawLast=true
    CheckExclusionRegion=true
    AddToExclusionRegion=true
    PositionionAlgorithm=labeling
So labels are tested against the exclusion region before getting
drawn.  Because the exclusion region contains the points, no
label will be drawn on top of a point.

Does your example of separating the feature and label overposting
have a good use case?  You could actually generalize this more.
If a symbolization specifies CheckExclusionRegion=true, does it
want to specify a list of which type of regions to check against?
E.g. layer 1 with symbolization A renders and adds "type A regions"
to the exclusion list.  Then layer 2 renders with symbolization B
and adds "type B regions".  Later on we have layer 5 that checks
the exclusion list, but only against "type A regions"...

===========

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.

[Ben Trumbore] That's fine by me.

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

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

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