Some of those who read the previous posting on using GTCreate to convert non-GIS data into the GTViewer format asked how it could be done with Safe Software's FME. This approach was mentioned in the previous posting, but I did not describe how to do it. It turns out to be pretty simple as well. The hardest thing about using FME is describing how you did what you did to accomplish a task. So here goes my attempt.
The sample Lightning Strike data was comma separated data. I renamed the file (to lightning.csv from lightning.txt) and I also placed column headers as the first row. The column headers are not necessary, but FME will use them if they are there:
Time, X, Y
6/27/2005 12:42:27 PM, 457382500, 1515628500
6/27/2005 12:42:30 PM, 456551000, 1515066000
6/27/2005 12:42:47 PM, 457590400, 1514540200
In FME Workbench, I created a new workspace and selected a CSV file as the source and GTI_GTViewer as the destination:
This new workspace looks like the following:
Since the .CSV file is just tabular data, we have to add a few FME transformers to create the geometry like we want it. I want the resulting .gtg file to be equivalent to the one produced by GTCreate in the previous post, so this task is slightly more complicated that just doing a default conversion with a single 2DPointAdder transformer.
I am going to add three transformers: a Counter, a Concatenator, and a 2DPointAdder. The data in the .CSV file did not have any kind of ID, so I am using a Counter to just add a new value that gets incremented for each feature (the GTCreate example had a counter too that was incremented for each line read out of the file). The 2DPointAdder takes the X and Y values from the .CSV file and generates a point geometry. I am going to differ from the GTCreate version here by placing a point feature (Symbol) rather than a Circle, but this is a trivial change if you wanted to do it with a circle. Finally, I am going to use a Concatenator to generate the string of data to embed on the new elements. This embedded data string is the same string used with GTCreate that includes the Id and Time of the strike. A big difference can be seen here between the GTCreate and the FME approaches. FME will automatically create an ASCII Data set (data.txt, data.idx, and data.tab) and link the elements to the rows in the data file. However, I used embedded data in the GTCreate version so that the file would be a single self-contained file that still supports reviewable features. If you were going to add this data as a new Category in GTViewer, leaving the data separate and using the linkages is a better approach (See the Linkages and Embedded Data posting for more info on this).
The end result is the following workspace:
Run the Translation and you will get a complete GTViewer dataset that includes a Lightning.gtg file equivalent to the one produced by the GTCreate example.
Probably the only complicated part of this workspace is creating the embedded data. The GTViewer Writer for FME is geared for creating linked data (since this is what you typically do); nevertheless, it is still very easy to embed data on elements. The Concatenator just builds the string using the ID and Time data values and then on the Destination dataset, the gti_embeddedData is set to the result of the concatenation and gti_embeddedDataType is set to 1 (a constant value).
The FME approach is very different from the GTCreate approach, but the end result is the same. The approach you take will probably depend on which tools you have and what you are more comfortable doing. The GTCreate approach does requires some programming skills; however, they are pretty minimal. The FME approach is relatively easy too, but it does require some familiarity with using FME. So, if you can decide which one to use, try them both and see which one works the best for you.
I just have to write in and say just how great the last several Blog entries have been. Keep up the great writing for such a great product suite!
Post a Comment