[mapguide-internals] RFC 14(CartographicStylizationEngine)comments
Ben Trumbore
ben.trumbore at autodesk.com
Thu Feb 15 18:44:24 EST 2007
Traian,
Thanks again for your replies. Between your responses and a
conversation I had with Carsten, I think I see where things are. I want
to reply to a few of your comments and attempt to summarize my
understanding to see if everyone agrees. I also think there are still a
few open questions.
* I'm happy to hear that "px" has been removed from the symbol sizes
(for many reasons that I won't reiterate). Storing all symbol
geometries in mm is great.
* As you mentioned, we need to decide whether the SymbolInstance should
scale the symbols relatively or aboslutely. The currently proposed
relative resizing is a departure from the existing style classes, but it
is more general than absolute sizing (which, as you note, we may not be
able to provide in all cases). Could we at least determine whether a
symbol has static geometry by seeing if it uses parameters in its
geometry definition? If a symbol has static geometry, it's bounds can
be determined and absolute scaling can be provided.
* I think there is agreement that allowing users to create their styles
in certain units and with a "maintain aspect ratio" option are functions
of the UI, and do not belong in the object model. This is a departure
from the previous symbolizations, but we should be able to provide
similar functionality through user preferences in the application.
* Do we have a formal, long-range plan for migrating the object model,
stylization engine and UI to use the proposed schema? Is it intended
that the old style specifications will eventually be eliminated? If so,
we might be better off making an abrupt switch to the proposed method,
rather than adding the new stuff, deprecating the old stuff, and then
eventually removing it. We might wind up inconveniencing more users to
a greater degree, and be left with a less desirable schema and object
model to boot.
Traian's email highlights an opportunity to streamline the proposed
hierarchy. I'm sure he is aware of this, but I'll discuss it anyway.
The original three derived FeatureTypeStyles were meant to steer the UI
and stylization engine to the appropriate style information for a
feature of a given geometry type. The proposed system could ignore
geometry type in the layer definition classes as it contains its own
steering mechanism (the "Usage" properties in SimpleSymbolDefinition).
Moving PointTypeStyle's overposting properties down to SymbolInstance
(as proposed) would remove the last barrier to eliminating
FeatureTypeStyle and having a class hiearchy that looks like this:
FeatureLayerDefinition
-- VectorScaleRange
-- CompositeRule (could be named Rule)
-- CompositeSymbolization (could be named Symbolization)
-- collection of SymbolInstances
Of course, this can only be done if the existing FeatureTypeStyles are
eliminated. This might not be as radical as it sounds. If such a
change is made sooner rather than later, fewer data sets will need to be
converted and fewer applications will have to change their layer
generation code. Also, it shouldn't be hard to convert a 1.0 layer
definition into the proposed classes silently and temporarily at
runtime. Anyway, I just wanted to throw that out for consideration (and
to provoke an answer to my question about the long-range plan in this
area!).
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: Thursday, February 15, 2007 12:10 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC
14(CartographicStylizationEngine)comments
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
schema:
FeatureLayerDefinition
-- VectorScaleRange
-- PointTypeStyle
-- PointRule
-- PointSymbolization2D
-- Symbol (one of Font, Text, W2D, etc)
Here is an example of a new symbology hierarchy:
FeatureLayerDefinition
-- 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
CompositeSymbolization.
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.
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: Tuesday, February 13, 2007 5:30 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC
14(CartographicStylizationEngine)comments
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
_______________________________________________
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
More information about the mapguide-internals
mailing list