Sunday, June 29, 2008

GTData version is Available

Version of GTData is available.

----------- - 6/29/08

- FIX - #5063 - Computing element ranges with Data Only elements was causing the range to be invalid.

----------- - 6/23/08

- FIX - GTD #1025 - GTShapeConv - Filter Value was listed as a Fixed value.

- NEW - GTD #1026 - GTShapeDbfConv - Filter Value info now displayed.

- NEW - GTD #1027 - GTShapeDbfConv - Will now accept a and an = as the entry delimiter.

- FIX - GTD #1028 - GTShapeDbfConv, GTShapeConv - FilterAttribute did not work well with Float type attribute.

- FIX - GTD #1029 - GTShapeConv - The OrFlag had to be set manually for FilterAttribute entries, this is now done automatically.

- FIX - GTD #1030 - GTShapeConv - The AngleInDegrees flag did not work.

- NEW - #5039 - GTQuery - Support added for the "GIS1:" marker in the Filter file descriptions generated by the FME plug-in

Wednesday, June 25, 2008

New Features in the GTViewer FME Plug-In

Version of the GTViewer FME Plug-In has two new features: (1)an Enhanced Filter Creation mode and (2) an option to automatically prepend the destination feature name to the gti_styleName format attribute.

As users are creating more and more complex feature sets with the FME Plug-in, it has become apparent that the default filter file creation method in the FME Writer Plug-in has become insufficient. By default, filter files have been created for each category using the following simply procedure:

1) create a default group called Features

2) add each new filter id (which is tied to the Style Name) as a new component.

This approach is very simple and always works. The user also has the ability to define his or her own more complex filter file definition and the FME plug-in will continue to use the same filter ids as they are defined.

While the GTViewer G/Tech Loader (used to convert Intergraph’s G/Technology data to the GTViewer format) has very little in common with the FME Plug-in, the two applications do have a few conceptual commonalities. Primarily, in both conversion approaches, the Filter Id and the Style Definition are tied together to simplify the conversion process and symbology definition. Therefore, each filter id generated by both conversion methods are mapped to a specific style definition. For example, if you have a Pole feature with a dozen different symbologies, then there will be a dozen different filter ids created in the filter file and each one will be mapped to its own unique style definition. As the different styles are created for a specific feature with the G/Tech Loader, the feature and component numbers of the original feature are taken from the GIS and used to group all of the different styles/filter ids together and form a Group of all the feature’s individual styles. This approach worked so well that GTQuery was modified to accept a Feature and Component number list in addition to a filter id list when defining a query. Now, only the original G/Tech feature and component number are needed to identify a feature in the query definition instead of trying to determine all of the individual filter ids that were used to specify the individual feature’s styles. This approach overcomes the problem of new filter ids being introduced as new styles are used by the GIS; all filter id with a common Feature number are automatically treated as a single feature.

The new Enhanced Filter Creation Mode in the FME Plug-in mimics much of the G/Tech Loader’s approach to filter id so that it can provide richer filter file creation. The original GIS feature and component number may or may not be available to FME; however, the FME Plug-in can still operate in similar fashion by generating its own feature and component number based on the Feature name and Style names used in the conversion. In FME, the Feature name is the name you define on the Destination features (as Feature Type Name).

In the example below, the Streets destination is shown:

With the Enhanced Filter Creation mode:
  • The Streets feature will be given a unique Feature Number.
  • All Street features will be added to a Group called “Streets”.
  • Each different style used (different values of gti_styleName) for the Streets feature will be given a unique component number for that feature.
In the example shown above, the gti_styleName format property is assigned the value of the CFCC value (which is the type of road and makes it possible to assign each different road type a different symbology).

The second new feature in the FME Plug-In is the ability to automatically prepend the Feature name to the value assigned to the gti_styleName format property. In the past, it was necessary to use a Concatenator to generate the appropriate string for gti_styleName:

While using the Concatenator transformer is not difficult, it did require defining the concatenation for each feature using attribute driven symbology. When using a single attribute to drive symbology, this task becomes implicit; you just connect the driving attribute to the gti_styleName property in the destination. With the Use Feature in StyleName option active, the Destination feature name and a hyphen (“ – “) are automatically prepended to the gti_styleName value when creating the filter name.

In previous versions of the plug-in, you needed something like this:

However, with the Use Feature Name in StyleName active, you only need to connect the symbology driving attribute to the gti_styleName format attribute:

You will still need to use a Concatenator if you want to use multiple attributes multiple attribute to drive the symbology, but the Concatenator’s specification will still be simplified since it does not need to specify the Feature name.

The Use Feature in StyleName is not required and if you wish to use the explicit approach used by previous versions of the plug-in, simply turn this option off in the Destination parameters.

Using the new feature with exsting Workspaces
If you are using workspaces created with previous versions of the plug-in, the new options will not appear in the Parameters section in the Workbench Navigator. However, you can use the gtiParameters.txt file to define these options:

UseFeatureNameInStyleName=1 or 0
or standard

To use the gtiParameter.txt file, create a file with the desired entries and place this file in the output directory. The FME plug-in will look for this file each time the data is converted. If the file is present, the plug-in will use any settings it may define.


To get a better idea of the effect these new features will have on a filter file created by FME, I will walk through an example of the new setting combinations and show the filter file created for each:

File Creation Mode: Standard Use Feature Name in Stylename: No

This example produces the same output as all previous versions of the FME Plug-in: one group called Features, with each different gti_styleName value added as a different component.

File Creation Mode: Standard Use Feature Name in Stylename: Yes

With the Use Feature Name in StyleName set to yes, the Destination feature name is automatically prepended to the style name (“STREETS – “ in this example).

File Creation Mode: Enhanced Use Feature Name in Stylename: No

With the Filter Creation Mode set to Enhanced, this version of the filter file is somewhat different from the previous two examples. Two groups are created, one for “Streets” and one for “Water”. All of the street types and water type are created as separate components within each feature group. The “GIS1:” tag and “Group:” tag are used in the description fields instead of the “FME:” tag used by the standard mode. This difference helps the FME plug-in manage the different mode of filter creation and also is supported by GTQuery to allow feature and component specifications.

File Creation Mode: Enhanced Use Feature Name in Stylename: Yes

This final example shows the filter file with both the Enhanced Filter Creation Mode and the Use Feature Name in Stylename option active. In addition to the information discussed in the previous example, a few other items of interest are worth pointing out. With the Enhanced mode, the unique Feature numbers that are generated (1 and 2 in this example) which is the second item in each record. Also, the component numbers (the 3rd item in each record) are now unique for each group. The Water group also demonstrates the entry that gets generated if the gti_styleName is empty.

GTVx version 7.0.x.20 is Available

Version 7.0.x.20 of GTVx is available.

----------------------- - 06/25/08

- FIX - GTV #1038 - Computing element ranges with Data Only elements was causing the range to be invalid.

- FIX - #5002 - Weight setting in Thematic Query dialog did not work.

----------------------- - 05/23/08

- CHG - GTVX #1037 - Default Stroke Angle for Style rules has been changed to 5 degrees instead of 15.

- FIX - GTVX #1038 - Style Rule object was not getting set for Draw methods. Initial rendering could be different without any style rules defined.

Friday, June 13, 2008

GTViewer version is Available

Version 7.0.x.30 of GTViewer is available.

----------------------- - 06/13/08

- FIX - GTV #1038 - Computing element ranges with Data Only elements was causing the range to be invalid.

----------------------- - 05/13/08

- NEW - GTV #1032 - FontMap_NoJust entry added to dgnExport.ini.

- CHG - GTV #1037 - Default Stroke Angle for Style rules has been changed to 5 degrees instead of 15.

Thursday, June 12, 2008

TechEd 2008 in Orlando

The TechEd 2008 Deveveloper’s Conference was in Orlando last week. I have always attended MEDC (Mobile and Embedded Developer’s Conference) before, but it has now been merged into TechEd. I believe that I prefer the more focused content of MEDC, but if my only way to get this information is to go to TechEd, then it is not too bad of an alternative. However, there were only 11 Windows Mobile session at TechEd 2008.

There is always a flavor to a Microsoft conference. I don’t know if this is directed by the powers that be or simply a natural alignment to the new features they are providing (or a combination of both). This year, the flavor definitely tastes of LINQ (Language Integrated Query). LINQ is undeniably an interesting concept that directly integrates SQL-like statement into the language syntax of any .NET language (VB.NET, C#, etc.). What makes this new feature somewhat interesting is that the SQL statements can be applied to data in arrays, enumerable objects, XML, and databases. So, the SQL way of querying a database can now be directly applied to data in your application, not just databases.

It also appears that most of the new language features we get from Visual Studio 2008 are directly related to LINQ: Anonymous Types, Extension Methods, Lambda Expressions, Implicitly typed locals, and Object Initializers. All of these new features were added just to support LINQ. One session on the Visual Studio 2008 IDE revealed that there wasn’t much added to the IDE because all of the developers were working on LINQ. On the downside, while LINQ does run on Windows Mobile, it will only work with your application data and does not work with SQL CE. There are a lot of things in the Compact Framework I would have rather had than a partially implemented version of LINQ.

While just about every session had to work LINQ in somehow, there were a couple of other technologies that were shown off. The Windows Presentation Manager (WPF) has developed a good deal since last year and can really produce some spectacular looking demos. The new support in Visual Studio 2008 for WPF is nice, but really seems to be early in its development. All of the WPF sessions seem to highlight a few points: it has great potential, it’s not here yet, and you will need a graphic designer to properly use it. A common phrase I heard in the session is “I’m not a graphic designer, so my WPF doesn’t look very good.” Nevertheless, I still found the Technology compelling enough to pursue. As an aside, Silverlight, which is an offshoot of WPF, came across as a very immature technology. Maybe it will mature quickly.

The Window Communication Foundation (WCF) was also a popular topic. It is just the extension of Web Services to what it probably should have been in the first place.

The Windows Workflow Foundation (WF, because WWF was already taken), was new to me and looks really interesting. An oversimplified description of it would be a project type in Visual Studio that lets you create a flow chart or diagram of your business logic and then can add the code behind the items in the diagram. The WF demos were compelling, but I have to question how well it really works in the real world. The demos used very simplistic logic. How well WF scales to a real application would be interesting to know. I think time will tell on this technology. It will become really popular or just disappear.

Another interesting thing about TechEd 2008 is what they didn’t talk about. Normally, these conferences are all using beta versions of something that hasn’t been released. I went to MEDC two years in a row and all they talked about was Whidbey (VS2005). Then it was all about Orcas (VS2008). With the exception of running VS2008 service pack 1 betas and a Silverlight beta, everyone was pretty content with the released software (quite a change from previous conferences). Does this mean there isn’t anything new in the queue or they are just taking a little longer to ramp up to the new stuff.

All and all, I was pretty pleased with the conference. Visual Studio 2008 looks good enough now to upgrade to (although I may wait until SP1 until I start upgrading all of my projects). Check out the full video and text of Bill Gates’ key: