[mapguide-internals] RFC 14(CartographicStylizationEngine)comments

Traian Stanev traian.stanev at autodesk.com
Thu Feb 15 12:09:41 EST 2007

Hi Ben. 

We decided to remove use of "px" to specify unit. So now everything in
the symbol uses the same units. If nothing else is specified, those
units will be treated as millimeters. 

The current symbol types (TextSymbol, W2DSymbol, FontSymbol, etc.) are
in my mind obsolete and we should remove them. The same should
eventually happen to all the current symbolizations. They are all
superseded by the new SymbolDefinition object. The
CompositeSymbolization object, being a Symbolization, inherits from the
Symbolization class. The new symbology stuff even has its own
FeatureTypeStyle, so the split between old and new styling actually
happens further up in the class hierarchy than one would generally think
reasonable. Here is an example of a point layer style using the current

   -- VectorScaleRange
      -- PointTypeStyle
         -- PointRule
             -- PointSymbolization2D
                 -- Symbol (one of Font, Text, W2D, etc)

Here is an example of a new symbology hierarchy:

   -- VectorScaleRange
      -- CompositeTypeStyle
         -- CompositeRule
             -- CompositeSymbolization 
                -- collection of SymbolInstances which reference
SymbolDefinition resources

This way, old way of defining styles is not affected and does not affect
the new way. The exception to this are properties that are common to the
Rule base class, i.e. label definitions. One could still use the current
labeling to label features that are styled with a

I am not (yet) convinced storing symbol design units is necessary. If we
do it, it will be stored in the symbol definition, not the layer
definition, so that every layer that references the symbol can know its
design units. Also, the Units tag will be optional and if not present,
the units will be millimeters. Does that make sense? If other people
agree, we can add this. My inclination would be to allow a two character
unit code (in, px, mm, m, ft, yd, ly). I specifically wanted to prevent
the old UI scheme where one is presented with a listbox of units for
everything and they could change the units without changing anything
else, which would then change the scale value by some crazy factor in
order to keep the relative size the same, and the default unit is always
wrong. I always thought that stuff like the default label font size of
"0.08523784623786 inches" in the Studio UI for example was really
unfriendly and useless. I want to avoid that. Disallowing units
explicitly was the way to remove that unnecessary degree of freedom.


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Ben
Sent: Tuesday, February 13, 2007 5:30 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC


Thanks for the answers to my questions.  I was thinking of the wrong
thing when I asked about specifying types for parameters - the system in
the schema should be fine.  Tom's response about dependent elements
makes sense, and I understand that the overposting issue may have to be
revisited.  I would like to look further into the size question.

All current point symbol types except TextSymbol inherit from
SymbolType, but it looks like the new CustomSymbolizationType will not
inherit from it - is that correct?  I guess that is reasonable given
that the new type isn't just for symbolizing points, but also lines and
areas.  But it leaves these symbols without the current mechanisms for
scaling a symbol (your comments suggest that this should be possible).

I see that the SymbolInstances within a CustomSymbolizationType will
provide some of the properties from SymbolType on a per instance basis
(scaling, insertion offsets, and size context).  Rotation is pushed down
into the new point-related elements, and MaintainAspect is gone (not a
problem for me).  The thing that is missing is Units, which allows a
users to set and RETAIN values in a way that is convenient to them.  I
suppose you could argue that such a setting is UI-dependent and
shouldn't be stored in the model (this argument holds for
MaintainAspect).  Did you consider storing Units in
CustomSymbolizationType?  In SymbolInstance?

I'm still not clear on the use of px.  Is it only allowed when
SizeContext is Device?  That would make more sense, but such a
definition might not work for both monitors and printers.


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Traian
Sent: Monday, February 12, 2007 3:09 PM
To: mapguide-internals at lists.osgeo.org
Subject: RE: [mapguide-internals] RFC 14

Here are some answers to the questions that I know the answer...


All sizes are in millimeters, unless otherwise specified. In general, we
felt like there are a couple of places where it could be useful to
specify a size in pixels. One of those places is image size, where exact
image size is known in pixels and the symbol author chooses explicitly
not to apply any scaling to the image -- for example when used as a fill
pattern. The px suffix is similar to what is used in CSS and I don't
think it's hard to check if a string ends with "px". It's a lot more
concise than having an extra tag to specify units. Everywhere else,
coordinates and sizes are in millimeters. I expect that any symbol
creation UI would convert all values to mm. If the value is in
millimeters, the mm suffix is not needed (and should not be there).
The "px" decision is simply there for convenience to people creating
symbols by directly writing XML.

Oh yeah, one could of course scale the whole symbol by whatever they
want, thus making the units seem like inches, if they scale by 25.4 for
example, but this is done externally to the symbol itself, in the layer


This question is in part answered by the new ParameterDefinition tag
that we added to the RFC last week. Here is an example 

        <DisplayName>Line Weight:<DisplayName>
        <Description>This is a sample</Description>
        <ValueList>1 2 3 4</ValueList>

This tag provides more information about a LINE_WEIGHT parameter. It
gives a default value and a list of possible values. This should be
sufficient for a UI to display information about the parameter,
including localized name and description. The data type of a parameter
is determined from the context it is used. For example if the parameter
is used for line weight, its data type is floating point. If the
parameter expression is used for a label, its data type is a string.
There is no need to specify the data type explicitly, since it is
implied by the owner of the parameter. I think it is counterproductive
to enforce data types on expressions, because often times a value that
is a number might come out as a string from the data source. In such a
case, the expression engine will automatically convert the string to the
required data type.

Parsing code for all of those structures will exist -- it is required if
we are going to be able to draw such symbols. I expect that code to be
reusable for the purposes of UI as well.


So far we have avoided use of attributes in the map and layer
definitions. This just keeps with the tradition -- does anyone know the
reason for that anyway? If not, we can consider changing some elements
to be attributes.


Yes, we allow different overposting rule per each symbol element. So far
I hope this will work out fine. If it doesn't we will have to rethink


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Ben
Sent: Monday, February 12, 2007 11:55 AM
To: mapguide-internals at lists.osgeo.org
Subject: [mapguide-internals] RFC 14 (CartographicStylizationEngine)

I would like to offer some comments/questions about this proposal.


I don't fully understand the way sizes are specified for ImageType
(SizeX and SizeY), PathType (LineWeight) and TextType (Height and
LineSpacing), as well as the assorted Position, Origin, Repeat,
BufferWidth and Offset parameters in the Usage elements.

Some of these values can be specified in mm or px, and some in just mm.
Are these values only used for relative sizing and positioning of
composite elements in a symbolization?  How are px values used with (or
converted to) mm values, or must they all be of the same type within an
element?  If px is meant to specify device-space sizes, how does it work
for devices with vastly different pixel sizes, such as monitors vs.
printers?  Why are units required hereat all?  Isn't it better to
specify sizes in the layer definition, as is done with the current

If both mm and px are required in these elements, I am not comfortable
having the units merged with the value.  It makes it harder to create
the input values from layer properties, and the input values are forced
to be strings (see PARAMETERS, below).  Style editing UI and
symbolization processors must all parse the string to use it.  Could a
separate element specify the units, perhaps making it optional with a
default value of mm?


I would like to see the parameter definitions include some type and
range information.  Passing everything as strings allows for expressions
to be used everywhere, which is great.  However, if the provided strings
can be parsed once and stored as known types in an object model, all the
code that uses the model can be simpler and faster.  Providing some
information about the parameter's expected type and range would support
such initialization.

It would also be very useful for any style editing UI that wants to set
those values.  Such UI could display the range and validate user
provided constants, or invoke the appropriate expression editor for the
required parameter type.  Types should include string, integer, real,
color, and possibly date/time.  Would we want to include a flag (and/or
possibly an optional length attribute) stating that the string
represented an array of values of the given type?


There are a number of elements in this schema that are only to be used
when another element has a certain value (search the doc for "only").
I'd like to see these become attributes of the element on which they
depend.  For example, there are several instances of Angle only being
used if AngleControl is set to FromAngle.  Instead of having an
AngleControl element with an enumerated set of values, we could use a
choice between two elements (FromGeometry and FromAngle) with FromAngle
having an Angle attribute.


It looks like the overposting parameters for a symbol have been moved
from the FeatureTypeStyle level into each individual SymbolInstance.
Was this intentional?  What happens when the symbols in a collection
specify different overposting values - do some parts of the composite
symbol sometimes disappear while others remain?  Must the values for all
symbols in a collection be the same?

Ben Trumbore

mapguide-internals mailing list
mapguide-internals at lists.osgeo.org

mapguide-internals mailing list
mapguide-internals at lists.osgeo.org

mapguide-internals mailing list
mapguide-internals at lists.osgeo.org

More information about the mapguide-internals mailing list