[mapguide-internals] For Review:MapguideRFC31-SymbolDefinitionSupport forEditControlsandRichTextSupport (Markup)

[Thomas M. Tuerke]

> I'd also hate to think that MapGuide would require someone to hire a
consultant in order to generate nice maps.

It's not certain that this is where symbolization is heading, but on the
other hand, I see libraries of open-source symbol definitions a very
real possibility out of this: collections of symbols that can be
described in such a way that the UI can intelligently interact with,
because this parameter is described as an angle, that a fill color, this
other one a line color, etc.

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason
Birch
Sent: Thursday, September 20, 2007 8:49 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] For
Review:MapguideRFC31-SymbolDefinitionSupport
forEditControlsandRichTextSupport (Markup)

Carsten wrote:
 
>The industry though thought we need a better, descriptive and parsable 
>way  of describing this content as a road. Redundant? Yes ... needed?
Yes ...
 
Do you have the same user-demand for the style metadata?  What are the
real-world use cases for this?  I can't pretend to understand the style
definition language, but I haven't typically seen this requirement for
visualization elements.
 
MapGuide is fast and powerful software, but it is also getting a
reputation for being large and complex.  I don't think that we want to
go the way of GML; massive functionality with relatively few users.  I'd
also hate to think that MapGuide would require someone to hire a
consultant in order to generate nice maps.
 
Jason