[mapguide-internals] RFC 14(CartographicStylizationEngine)comments

Fri Feb 16 01:23:53 EST 2007

Yes one could compute the bounds of a symbol that uses constant styling and geometry. I expect we will have code to do that, since it's necessary for other purposes as well (like labeling).

The long range plan (at least in my view) is to fully replace the current styling model with the new one. That's why the object model is designed in such a way that the old stuff can be removed completely and the new stuff won't even notice that there's a huge chunk gone from the object model. We could be aggressive and completely cut out the old styling now, but in my opinion it's too much to comfortably do in a single release. Keeping the old pipeline around lets us take our time and roll the thing out in a couple of releases if necessary. It's like when steering an oil tanker, one has to set the course 10 miles before he actually needs to be headed in the desired direction. It also hedges us against f-ing up the implementation or the design just not working right or the thing being too slow, etc.

In addition to the vague reasoning above, there are practical implications. Throwing out the old pipeline will mean implementing conversion tools to translate the old object model into the new one. We will also (for example) need to convert all the line patterns we currently support and all the fill patterns to the new scheme. Doing all that work could well be more code than the existing style engine code. Code we don't really have to write (and I am lazy). Also, DWF symbols would no longer work. I think the more reasonable first step would be to stop generating old-style styles from the authoring tools, thus cutting out the source of all the 1.0 layer styles. 

We'd like to hear more comments on this issue. If people think that it is not too aggressive to switch over completely, it would be good to know.

Traian

	-----Original Message----- 
	From: mapguide-internals-bounces at lists.osgeo.org on behalf of Ben Trumbore 
	Sent: Thu 2/15/2007 6:44 PM 
	To: MapGuide Internals Mail List 
	Cc: 
	Subject: RE: [mapguide-internals] RFC 14(CartographicStylizationEngine)comments

	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

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