Interactive and Persistent Legend
- Display order of legend entries can be manipulated in the same fashion as GeoMedia (i.e. drag a legend entry up or down the list)
- The user can modify the legend symbology on the client side and it will be saved for future sessions using the same map by the same user
I don’t find too many folks needing to rearrange the display order on the maps. So, I don’t personally think the legend re-ordeingr is that valuable. However I’m a real big fan of the persistent symbology as I can really imagine folks wanting to change colors that better suit their needs from the map and application. This is especially important when looking to print the output to a color printer or to PDF.
Support for Complex Data Models
Different types of relationships between different feature classes (tables) can be setup at the application level. This is great when you would like to interact with many different tables in a more logical and straightforward. manner. Here’s a picture of the overall administrator interface.
- Parent/Child Relationships – Define a relationship between two features. Then, you have the option to examine all of the children that relate to the parent. In the two images below, you can see that in tab 1, the parent is "States". If you click on the state feature (in the example they’re using Maine), you can then receive a tab showing the 24 cities that are in Maine. The best part is that you can page through the attributes of each state (see the second screen shot).
Here’s a picture of the administrator to setup the parent/child relationship
- Free Relationships – The information on this is a little rough. However it looks as if you can really define any type of relationship you’d like regardless of how it appears in the database. I don’t have a good example off of the top of my head, but this looks to be what the dialog is illustrating.
- Code List – The information on this is a little rough as well. However it looks like you can decode feature class (table) values to output the more verbose meanings in the application. In other words, if Code 01 were to decode to a main leak and Code 02 were to decode to a lateral leak, if the codes were stored in the database, they could be decoded by GWME and the verbose values (main leak and lateral leak) could be shown in the graphic’s property dialog box.
Personally, I tend to handle my data model at the database and create views, etc. if I need to produce more denormalized output. So, with that said, the bottom two bullets do not appear to be as useful to me. However, I can’t state enough that for those that prefer to remove themselves from the database (or don’t have permission), I can really see how the bottom two bullets could be of great use.
As for the top bullet (parent/child); I really think this is a great function. In fact, I’d love to see this in the core GeoMedia product. If I recall correctly, this functionality is available in GeoMedia Parcel Manager. But, it would be great (and probably should be) in the core product…eventually.
More tomorrow…