[mapguide-internals] For
Review:MapguideRFC31-SymbolDefinitionSupport
forEditControlsandRichTextSupport (Markup)
Thomas M. Tuerke
thomas.m.tuerke at autodesk.com
Thu Sep 20 14:41:21 EDT 2007
> 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
More information about the mapguide-internals
mailing list