[mapguide-internals] RFC 14 (CartographicStylizationEngine)comments

Tue Feb 13 17:30:06 EST 2007

Traian,

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.

	Ben

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

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

SYMBOLIZATON SCHEMA - SIZES

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

SYMBOLIZATON SCHEMA - PARAMETERS

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

  <ParameterDefintion>
     <Parameter>
        <Identifier>%LINE_WEIGHT%</Identifier>
        <DefaultValue>1</DefaultValue>
        <DisplayName>Line Weight:<DisplayName>
        <Description>This is a sample</Description>
        <ValueList>1 2 3 4</ValueList>
     </Parameter>
  </ParameterDefintion>

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.

SYMBOLIZATON SCHEMA - DEPENDENT ELEMENTS

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.

LAYER DEFINITION SCHEMA - OVERPOSTING

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

Traian

-----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 12, 2007 11:55 AM
To: mapguide-internals at lists.osgeo.org
Subject: [mapguide-internals] RFC 14 (CartographicStylizationEngine)
comments

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

SYMBOLIZATON SCHEMA - SIZES

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
symbolizations?

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?

SYMBOLIZATON SCHEMA - PARAMETERS

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?

SYMBOLIZATON SCHEMA - DEPENDENT ELEMENTS

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.

LAYER DEFINITION SCHEMA - OVERPOSTING

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
Autodesk

_______________________________________________
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