Contents:
1) Historical Markers
2) Complex Annotation Geometries
3) ArcGIS Image Server
4) Persistent SDE Connections
5) Text Size and Point Size
6) Quick Notes
Introduction
Hi FME’ers
In honour of the 2008 ESRI International User Conference, this post is a special on recent ESRI related updates in FME.
I think a key point of FME is how it easily integrates into spatial data workflows, simplifies processes, and helps people concentrate on using their data (rather than writing scripts or mucking about with text editors!). Therefore, for us at Safe, it’s vital that we keep our format support as up to date as possible; as even the smallest piece of unsupported functionality can force a user to take huge detours with their data.
That’s why it’s a real pleasure to be able to highlight improvements like these below. Browsing our user requests database I saw a number of funky ArcGIS functions - most of which I didn’t even realize existed - that we’d been asked to support. And here they are! Hopefully each one of these newly-implemented features will be a real time-saver.
The one caution is that, because these functions are newly added, they are very much still in beta form and subject to change and improvement as we get user feedback.
Regards,
Historical Markers
Historical markers are part of an archiving process introduced in ArcGIS v9.2 for ESRI’s SDE and Enterprise Geodatabase.
The basic idea is that - once activated - all database edits get stored in a separate archive class, with a date and time stamp. When viewing data you can - by specifying the appropriate time range - read the state of the spatial data as it existed at any particular moment in time. Additionally, an Historical Marker Manager lets you define moments in time with specific names that will obviously have greater meaning than dates (for example “As Designed” and “As Built”).
In FME2009 (as of beta build 5568) we now support querying data on the basis of these historical records. This is achieved by either selecting an historical marker on adding a reader, or entering a query into the appropriate reader parameter in an existing workspace.
Below: When adding a Geodatabase (SDE) reader to the workspace, the settings dialog includes this section. Here you can search out and specify a particular historical marker:
Below: Or you can choose to view data at a particular point in time by date:
Below: Once the reader is added to a workspace you can access historical data by setting the Archive Where Clause parameter:
Below: The Archive Where Clause is edited with this dialog. This example is a “range query” - ie the from and to dates are different.
According to the Readers and Writers Manual, a query can be a ‘moment’ query (the from and to dates are identical) or a ‘range’ query (the from and to dates are different). ESRI documentation tells me it’s also possible to query archives using attribute values (i.e. show me when <attr>=<value>) and Historical Markers, so - although I’ve no evidence - I believe this might also work in this FME parameter.
Complex Annotation Geometries
When, a few years ago, improvements were made to the FME geometry model, it enabled a whole deal of functionality which is still being unlocked. Support for complex ArcGIS annotation features is one of these.
By “complex” annotation geometries, we mean any text that is not a single piece of straight-line text, that originates at a specific point; i.e. text that is aligned to curves, arcs, polygons, multipoints, etc.
So, as of build 5555 we now support reading and writing of annotation with complex geometry.
Below: Bonus points for spotting the language of this curved annotation string.
Key things to remember:
- You MUST have the Geometry Handling parameter (shown below) set to “Rich”. You won’t be able to write complex annotation geometries (and maybe not read) if it is set to “Classic”.
- The data inspected in the FME Viewer will not show curved text - that’s because it isn’t supported (i.e. the Viewer is only meant for data inspection, not visualization)
- Splines and curves will be stroked into line features; we do hope to properly support these geometries in the near future.
Above: The Geometry Handling Mode must be Rich (not Classic)
ArcGIS Image Server
As of build 5550 Safe has added a new reader to FME: ArcGIS Image Server.
ArcGIS Image Server (or as of 9.3, ArcGIS Server Image) serves up file-based raster data to other applications. There are a number of applications with interfaces to use this data, including ArcGIS, AutoCAD and MicroStation; but the data can also be delivered as a web service, and this is where the FME reader might come into the picture.
Using FME on top of ArcGIS Server Image would firstly extend the format reach, secondly open up the data to all the raster transformation tools in FME, and thirdly allow everything to be integrated with all FME ETL functionality (for example, the ability to merge in vector datasources, live feeds, other raster data, text-based data etc etc) all “on-the-fly”.
The ArcGIS Server Image format is a reader only, since the product itself doesn’t have it’s own format (we read from a service). However for writing, it (the ArcGIS Server Image product) supports as source many of the same formats FME supports as a destination, plus I strongly suspect it would also accept a service as input, so you could create an “on-the-fly” FME writer using an FME Server service as an ArcGIS source.
NB: To get access to this format requires installation of the ArcGIS Image Server Client Core.
Persistent SDE Connections
Whenever FME connects to an SDE database it carries out the require processing and then shuts down the connection to save resources. However, when multiple tasks need to be carried out, creating a new connection each time is an expensive operation.
So that’s where a new keyword for FME2009 comes in. The PERSISTENT_CONNECTION keyword specifies whether to leave database connections open once their task is complete. That way other operations can use the same connection and avoid re-connection overheads.
Below: Persistent Connections are defined via a Reader Parameter:
This keyword isn’t intended for normal standalone translations, but for when the workspace is used in “super batch” mode or on FME Server; in these cases the reported improvement in connection time is a huge 50-60%. But just remember that an open connection is, effectively, an intentional one-time memory leak, so if you are not using SDE access in all translations it may not be worth the cost in system resources.
Text Size and Point Size
A curious discussion occurred here recently about whether “text size” and “font size” were the same thing, or different. It appears (from what I understand) that they are different; text size is the size of a text feature in ground (coordinate system) units, whereas font size is the size of the font to use in “point” units.
Therefore users were disappointed to find out that setting the format attribute geodb_text_size had no effect whatsoever on the size of the output font; and because font size is unrelated to geometry, the attribute geodb_text_ref_scale had no effect either.
The solution was for us to create a new format attribute: geodb_font_size
geodb_font_size defines the size of the font used to display the text string, in point units. However, there are some important points to note:
- Once more, you MUST have the Geometry Handling parameter set to “Rich”. The attribute would be ignored if the geometry handling mode is set to “Classic”.
- For the sake of backwards compatibility, geodb_text_size will overrule geodb_font_size if both are set. So remove any reference to geodb_text_size if you are wanting to set a text font size.
This fix was so important for a number of users we backported it to an updated FME2008 version. For more information see the Post-CD Fixes page on fmepedia.
Quick Notes
- The “Split Multi Part Annotations” option available on the Geodatabase_MDB reader has also been exposed on the SDE Geodatabase and File Geodatabase readers as of build 5564.
- An equivalent format attribute for the ArcGIS parameter “Character Width” has been created as of build 5531. It is called geodb_text_character_width
- The personal geodatabase metadata attribute, fme_num_entries, is also exposed in the file geodatabase reader/writer as of build 5529
- Did you catch Don Murray and Mark Stoakes presenting a pre-conference seminar on Data Interoperability? If not, don’t worry. Safe-hosted ArcGIS Data Interoperability Training will take place in Denver, Houston and Washington DC in the coming months. See the Safe training calendar for more information.
This Edition of the FME Evangelist…
…was written to the tune of “Greetings to the New Brunette” by Billy Bragg.
One of Britain’s best singer-songwriters. This is a slightly bizarre video, but you can’t argue with lines like:
“And if you hadn’t noticed yet, I’m more impressionable when my cement is wet.”
“How can you lie there and think of England, when you don’t even know who’s in the team?”
August 6th, 2008
Contents:
1) Raster To Vector Coercing
2) FFS Support for Raster Data
3) Visualizing Rasters
4) Persistent Cache and Raster
5) Transporting and CheckPointing Rasters
6) New Raster Formats
7) Raster Cell Origins
8) Raster Performance
9) Even more raster stuff…
Introduction
Hi FME’ers
This edition of the FME Evangelist is a special raster edition.
I know I wanted to vary topics in each post, to give something for everyone, but there’s so much raster info to go over that I can compile it into a single posting and still have enough left over to sprinkle into future posts. I have to say that our raster support is now very solid in FME, and well worth taking a look if you’ve not used it before. In particular I think being able to combine vector and raster data together, especially in FME Server applications, is going to be a big hit.
Regards,
Raster To Vector Coercing
Vectorizing raster data is a useful function that has just undergone a name change: RasterCellCoercer is the new name for the RasterToPointCoercer transformer. The reason it has been renamed is a very good one: the transformer now supports coercing raster data into polygons as well as points.
In the new ‘polygon’ mode a single polygon is output for each cell in the original raster. This results in a large number of polygon features - potentially useful in itself - but which you could dissolve together (based on the original cell value) to create a more manageable and realistic vector dataset.
In this example on fmepedia (screenshots below) a raster DEM dataset is converted into vector polygons using exactly this method.
FFS Support for Raster Data
I’m pleased to announce that as of FME 2009 beta build 5568 the FFS format is able to store raster features.
Rasters stored to an FFS file will have their data written to a corresponding .frs (FME Raster Store) file. One FRS file may hold the data for multiple raster features. FRS files hold up to 2GB of raster data; if the raster data surpasses the 2GB file size limit the data is automatically split across multiple files.
Above: A CDED raster dataset converted to FFS
Raster FFS datasets are used in FME (e.g. opened in the FME Viewer) by selecting the FFS file [though I tried opening the frs file and it did work - I just had to manually select the FFS format]. If you select an FFS file and the corresponding FRS file is missing then FME will just use the bounding box of the raster.
OK - writing raster to FFS might not seem like your idea of a good night out; however, it does integrate raster better with FME and open up some exciting benefits…
Visualizing Rasters
Did you see the previous FME Evangelist? If so, you may remember that:
“When you send data from Workbench to Viewer using a Visualizer transformer, what happens is that the data is simply written to a temporary FFS format dataset which is subsequently opened in the Viewer.”
In older versions of FME you’ve not been able to send raster data directly from Workbench to the Viewer - all you get is the dataset outline - because in between the data is written to FFS, and FFS doesn’t support raster.
But wait a moment! Hold the front page! FFS does now support raster.
So you are now able to direct raster data through the Visualizer transformer and get the correct view. One of those features a new user might say “yeah, so what?” about, but which an existing user will see as a great improvement.
Persistent Cache and Raster
Ever seen the FME Viewer option View > Options > View Persistent Cache and wondered what it does? Well turning it on causes all the data you open in the Viewer to be saved as FFS data in a temporary directory, so that every time you refresh the view or query the data you’re working on a local copy. That way you’re not having to re-read the source data, which can be a lengthy process if it is a web or database dataset.
Obviously this excludes raster, because raster can’t be saved as FFS. But wait! Hold the… er second page! FFS does now support raster.
So now using the Persistent Cache option in Viewer becomes a valuable time saver when inspecting raster data. The FME Viewer can even be shutdown and started at a later date and retain all the local copies of the data and thus the rapid access to the raster data.
The one word of warning is that this will create large amounts of data in the local temporary directory, for example, “C:/Documents and Settings/<username>/Local Settings/Temp/FMEUniversalViewer” - so make sure you have a lot of disk space, and try use your fastest disk.
Transporting and CheckPointing Rasters
Wait! Stop…. actually don’t stop the press on account of these functions; not many users are likely to have heard of these - let alone use them. But the ability to write raster to FFS also:
- Permits support for raster data in the TransporterReceiver and TransporterSender transformers.
- Lets the RasterCheckpointer transformer save the current state in FFS (rather than GeoTIFF) which means that any aspect of raster data expressible in FME can now be accurately stored on disk and restored without data loss.
…and trust me, these are important updates, even if part of slightly less used features.
New Raster Formats
FME 2009 has new support for a couple of raster formats; the first of which may be of interest even to folk who are not generally raster users.
The Shuttle Radar Topography Mission (SRTM) Height format (short name SRTMHGT) is DEM data created by NASA. FME now has a reader for this format. A writer is not planned. The nice thing is that data in this format is freely available at NASA’s repository (though it wasn’t working when I tried it last)
Image Courtesy NASA/JPL-Caltech.
The data comes in two levels: SRTM-1 with data sampled at one arc-second intervals in latitude and longitude, and SRTM-3 sampled at three arc-seconds.
Datasets are divided into individual height files that each contain one by one degree latitude and longitude tiles. Height file names refer to the latitude and longitude of the lower left corner of the tile, for example, N37W105 has its lower left corner at 37 degrees North latitude and 105 degrees West longitude. Height files have the extension ‘.hgt’ and express the height values in meters. These files always have the LL84 coordinate system.
One gotcha is that FME is currently unable to read height files that do not conform to the specified file naming convention, since the file name is the only means of reading the proper referencing for the file.
ER Mapper ERS format (short name ERS) is the internal raster format used by ER Mapper. FME now has a reader AND writer for this format.
The ERS format consists of a header with a .ers extension and a separate raw binary data file that can have any extension. The header file is considered the dataset in FME and contains information about the contents of the binary data file.
Limitations are that the ERS writer currently cannot write nodata values, and that the reader does not support ERS files containing algorithms for image creation and manipulation.
Raster Cell Origins
As you know, a raster is made up of cells, each of which is a single point but which in fact covers a small area. What’s less known (perhaps) is that each cell has an origin point which identifies the representative location of each cell. The origin is an x/y pair between 0.0 and 1.0 inclusively. The default value in most cases is (0.5,0.5) indicating the center of the cell.
Cell origin is particularly important when the cell value is taken from a single position - when the value is the average value of the area the cell covers then cell origin is less important.
FME2009 includes new functionality to set a raster’s cell origin to specified X and Y values. The transformer is the RasterCellOriginSetter and the underlying function is @RasterCellOrigin
Why would you need to do this? Two reasons spring to mind.
Some formats of raster data don’t store cell origin; it is assumed to be a certain location (often upper-left corner, which is counter-intuitive for many map users). So this new tool allows a user to properly adjust data read from those formats, if they so desire.
The second use case is during raster-to-vector, or vector-to-raster, operations. In these scenarios you want to be sure that cells converted to points (or vice versa) end up in the correct location. If you don’t correctly set the cell origin you could find the resulting output is out by up to half the width of a cell.
If you don’t know what the current cell origin is, you can retrieve that information into attributes using the RasterPropertiesExtractor or by inspecting data using the Logger transformer.
Raster Performance
If you’ve not tried an FME2009 beta yet, it might be worth doing just for performance reasons.
Our raster team tells me that several common raster operations take less time to execute in FME2009.
Specifically, raster resampling and rotation should now be faster in all cases. The magnitude of improvement may vary from translation to translation, but these operations should be approximately 30-50% faster than in previous versions.
Raster reprojection benefits primarily when dealing with multi-band rasters. The common case of reprojecting a 3-band raster is now up to 50% faster.
Even more raster stuff…
If you have used FME2009 you may well have noticed the new RasterExpressionEvaluator transformer, and the new Raster clipping capabilities. Since they are so important I’ll talk about them another time: for now check out Dmitri’s RasterExpressionEvaluator examples for some absolutely stunning uses of this transformer, and try for yourself clipping raster features into non-rectangular shapes (very simple and effective).
This Edition of the FME Evangelist…
…was written to the tune of “Only You” by Yazoo.
I’ve been re-watching The Office (UK version) and the great Tim/Dawn romance. Here’s the end of the second series, and here’s the end of the following Christmas special where “Only You” is the background music.
Or, if you only want the music itself, here’s the original.
July 31st, 2008
RSS 2.0
