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

[Carsten Hess]

Jason,

Yes, I think the use case is the symbol library and a way to describe
the content of the symbol library. Theoretically we wouldn't have needed
the parameters that are part of the symbols at all as we could have
created a new symbol for each use. That would have been faster and
easier for MapGuide but makes the symbols less reusable.

Creating good symbols like the FGDC library is quite a bit of work and
not trivial - in no GIS package I know off - and I am still hoping that
we will all contribute ultimately to create one big library that can be
part of MapGUide. I think that would make it easier to use...

In the end I think this metadata will make symbols easier to use ...
creating symbols a bit more complex. Personally I always push to make
using things easier after all that is what software is all about - make
the users life easier. 
With a platform like mapguide the question though is: who is not a user?
In this case we optimize for the person who is creating and viewing a
Map by reusing symbols not the person who creates the symbols.

Said all that ... I want to make sure that everyone is aware that these
sections in the XML are optional for symbols. They will work fine
without it :)

Cheers,
  Carsten

-----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 11: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