Why all these different versions? Read on for an explanation.
In the very beginning (MapGuide Open Source 1.0), the available types of resources you can have in a Site Repository were initially defined. All such resources used v1.0.0 of their respective XML schemas, which defines the XML content model of each respective resource type. Any XML document is a valid Feature Source, Layer Definition, Map Definition, etc if their XML content validates against their respective XML schema.
As time went on, new features have been added to the product. To expose settings for these new features in the resources you are editing and authoring, either a new resource type has to be introduced with a respective initial XML schema (Application Definition, Watermark Definition, etc). Or, a new version of the existing XML schema is introduced, that contains the new XML content model elements that define settings for these newly introduced features.
As you can see from the dialog above, some resource types like the Layer Definition have had many revisions to their respective XML schema due to the multi-phased introduction of Advanced Stylization
So why is Maestro making so many different versions available to you? One simple reason: data compatibility with older versions of MapGuide/AIMS.
This author understands that some of you may not be on the latest version of MapGuide/AIMS so Maestro offers you the ability to choose the appropriate resource schema version of the resource you want to create. Where Studio will automatically use the latest schema version of a given resource (making it difficult to package such data and load it onto an older MapGuide/AIMS server), Maestro gives you the choice of what version you want to work with. Maestro will never automatically upgrade your resources to the latest schema version. The choice to upgrade is yours alone to make.
Notice that these items are filtered and sorted by MapGuide/AIMS version, indicating the first release where this resource version was introduced, giving you a clear idea what versions of MapGuide/AIMS you can load this data into should you package it up from your current server.
Also, the editors are also aware of schema versions, and will appropriate enable/disable relevant parts of the UI to ensure that you will always be creating resources that match the underlying XML content model as defined by its XML schema. For example, take a look at the editor for a v1.0.0 Layer Definition document.
KML elevation and Composite Style settings are disabled because they were introduced in later revisions of the XML schema and are appropriately disabled by the editor.
So what features are introduced in each new version? Well for now you will have to refer to this text file. Having this information available in the New Resource dialog is definitely something worth my consideration.
Finally with all these choices available, what version do you use when authoring? That choice is completely up to you. Always going to be using the latest and greatest MapGuide/AIMS? Go for the latest schema version. Need to be able to load this data back into a AIMS/MapGuide x.y.z server? Pick the matching version from the dialog.
With Maestro, it's all about freedom of choice (even if there's a lot of them!)
Posts
4 comments:
Hello,
I have maestro 5.0 beta 2 and when I trie to theme a area layer I recieve this:
"The selected column contains more tha 100 different values, and thus cannot be used for theming"
The among of different values are about 180 and I need to represent it with different collors.
What can I do?
Thank you.
Think about this.
Do you *really* need a 180-rule theme?
You won't be able to practically display such a themed layer in the legend.
Users probably will have difficulty distinguishing the 180 various shades of your A -> B theme colors.
I'm not saying it's impossible (I can easily remove this message and let you generate your 180-rule theme), but consider the practicalities of what you are trying to achieve.
Hello,
I need to represent the vegetation of a park. I thought of using colors and textures to represent all the different plants. Another option would be represented by family rather than per plant, in this case would be about 70 different families. What do you think is better?
Thank you very much.
I'll probably blog about this in more detail, but what you're saying is essentially what I would suggest as a way theme such a large set of attributes. Divide and conquer.
Theme by the attribute(s) that they have in common (plant family). 70 theme rules still sounds a bit excessive, so you could probably theme by alphabet (family names starting with A, starting with B, C, D, ... Z).
You could then create family-specific layers (filtered on the family name), that are themed on plant name if the number of rules isn't too large.
So the resulting layer structure on your map would be like:
> [Group: Plants by Family]
>>> [Group: Families - A]
>>>>> [Themed Layer: Families - A]
>>>>>>> [Group: Aceraceae]
>>>>>>>>> [Themed Layer: Plant Names for Aceraceae]
>>>>>>> [Group: Araliaceae]
>>>>>>>>> [Themed Layer: Plant names for Araliaceae]
>>>>>>> [Group: A...]
>>> [Group: Families - B]
>>> [Group: Families ...]
>>> [Group: Families - Z]
This allows flexibility in the presentation of your plant features, you could see the plants themed by family, toggle on the layers for the families you're interested in intereted in and then drill-down to specific plants in that family, etc.
It doesn't have to be this granular, but it will make layer presentation much more manageable.
Post a Comment