This post is about a new parameter in the File Geodatabase writer in FME, which lets you take an ArcGIS XML Workspace Document (what I would call a template) and create a new Geodatabase from that. It’s the first of what I hope will be many video Evangelist podcasts. Enjoy.
January 12th, 2012
This short post is about what to do when FME doesn’t recognize your coordinate system - and highlights a very little known transformer: the CoordinateSystemDescriptionConverter.
November 18th, 2009
1) Historical Markers
2) Complex Annotation Geometries
3) ArcGIS Image Server
4) Persistent SDE Connections
5) Text Size and Point Size
6) Quick Notes
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.
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.
- 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
Hi folks. This is my first true posting to the FME Evangelist blog. In fact I’m on vacation at the moment, but can set a date for this to be published automatically. Ain’t technology great?!
Anyway, this issue has a nice mix of FME2009 updates, example workspaces, important notices, and an FME Server demo.
1) FME2009 Beta: Update
2) Logger Transformer: Feature Type in FFS Output
3) PointDisperser Customer Transformer
4) FME and ArcGIS v9.2 SP5
5) FME Server: Data Streaming Example
6) StringAttributeRounder Custom Transformer
7) VirtualEarthTiler: Spherical Mercator Coordinate System
8) Chopper Transformer: Overhaul for FME2009
FME2009 Beta: Update
Issue #12 noted that we were aware of a number of performance issues with the first FME2009 beta. I’m happy to say that all known issues are now reported as resolved and the current build (5557) back to normal.
Logger Transformer: Feature Type in FFS Output
The Logger transformer already had an example of its use on fmepedia, but with a number of updates since then (July 2006) it’s worth re-visiting this unassuming little transformer.
The main change you’ll find since that example was created is that features written to the Logger are now automatically written to a spatial Log file in FFS format. This is a great for visually inspecting features, rather than trying to interpret their representation in a plain text log file.
The other change is something new for FME2009; the ability to specify the feature type to which to write the spatial log features.
Previously the features sent to a Logger would go into a feature type named after the preceding transformer, for example Tester->Failed.
However, in FME2009 you are able to specify the feature type name, and so can be more descriptive – for example “Bad Address Data”, or “Unused Line Features”.
Above: The Feature Type to Log setting in the Logger transformer in FME2009
Visit the Logger example on fmepedia to see the updated version of the workspace.
Did You Know?
Did you know that FFS datasets come in both file and folder based flavours?
For me, the Logger transformer is particularly nice to use because multiple Loggers in the same workspace write their data to the same file-based dataset.
Compare this to the FFS format writer, where different feature types write to different FFS files within a folder (folder-based dataset).
There are benefits to both, but my preference is for a tidy, single-file dataset, so I choose the Logger every time to write my FFS files.
Below: The Logger transformer produces a file <workspaceName>_log.ffs…
…and that single FFS file contains two different feature types (Invalid Day and Invalid Month):
PointDisperser Custom Transformer
The PointDisperser custom transformer is a tool to create a form of structure suitable for thematic mapping. Where a number of points all belong to a certain parent location, the transformer can disperse them around the parent in a sort of radial diagram.
With a little more work the points and lines can be easily turned into coloured nodes and sectors.
These features look very effective when overlaid on a map background using some form of mapping or visualization tool.
In line with the concept of “eating one’s own dog food“, at Safe we use this tool for mapping sales figures, where the parent point represents a country or city, and each node represents an FME sale at that location.
No doubt you could envisage similar uses for your organization.
FME and ArcGIS v9.2 SP5
This is an important note for users of the Geodatabase readers and writers who upgrade their ArcGIS v9.2 installation to SP5.
FME 2007 and 2008 – which were both created before the release of SP5 – are both adversely affected by this upgrade. In particular you may receive a specific error message:
“The procedure entry point SgCodeFree could not be located in the dynamic link library sg.dll.”
Of course this will also impact any SpatialDirect and FME Server installations that use these readers and writers.
The quick-fix we have for this problem is to copy a number of files from the ArcGIS installation, and paste them into the FME installation folder, overwriting files of the same name.
The files are:
No problems have been reported using this workaround, but we don’t guarantee it because it’s a newer library than what FME was compiled against.
The long term fix is for us to issue updated versions of both FME2008 and FME2009, which we intend to do in the near future. If you want to be notified when this happens please email firstname.lastname@example.org and quote PR#15697
NB: Only update the DLL files if you get the above error message. They should not need to be changed for any other reason.
FME Server: Data Streaming Example
Data streaming is a service provided by FME Server that delivers data right into an external application.
This example - which you may have seen as a demonstration before - is a very good illustration of that technique, and one of our favourites here at Safe.
Source data - in this case a live feed of Earthquake data from the USGS (GeoRSS format) - is translated into KML using a workspace that also restructures the data from simple points into extruded columns.
By uploading the workspace to FME Server the output data can be streamed directly into Google Earth – by anyone! The end user does not need FME to be able to visualize this data as all of the processing is done on an FME Server installation.
You can do this too! By simply clicking on this URL (or entering it into a web browser):
…you’ll make a call to an FME Server, which will carry out a translation, convert the data to KML, and stream it straight into Google Earth on your computer.
Above: The output viewed in Google Earth
The source data doesn’t need to be a live feed (as it is in this example). It can be any source data that you have on your system and that FME Server has access to - for example your spatial database (SDE, Oracle, SQL Server, etc). This means any person in your organisation can view your data - in Google Earth - immediately, and without you having to translate it for them.
Also, you can use more than one source dataset, in effect creating a Google Earth mashup with very little effort.
For example, you could merge a set of delivery routes with a live traffic alert feed (http://developer.yahoo.com/traffic/rss/V1/index.html) to show where a delivery schedule could be interrupted by traffic congestion.
StringAttributeRounder Custom Transformer
The AttributeRounder transformer is great for rounding the values of attributes (for example 123.456789 to 123.46) – but not so good when the attribute contains some sort of alphabetic character (for example 123.456789m). But rounding this form of text can be a requirement when the data is annotation read directly from a cartographic input.
The StringAttributeRounder is a custom transformer created in order to allow users to round off numeric attributes that are contained within a longer string.
The user can choose whether the text part of the string is at the start or end of the attribute.
Start Attribute: m234.5555
Text Part At: Start
Decimal Places: 2
Result Attribute: m234.56
Start Attribute: 234.5555m
Text Part At: End
Decimal Places: 2
Result Attribute: 234.56m
The transformer also handles <space> characters, for example:
Start Attribute: x y234.5555
Text Part At: Start
Decimal Places: 2
Result Attribute: x y234.56
If you want to use the transformer, or are interested to see how it works, then visit the StringAttributeRounder page on fmepedia. It requires FME2008, though there is also a version specifically for FME2007.
Above: In brief, the transformer strips off the text part of the string (from either the start or end), rounds off the remaining number, then glues it all back together with a Concatenator.
There is one specific best practice technique to look out for; the AttributeExpressionRemover transformer is used to clean up any temporary attributes created during the process, so the user is not distracted with extra data on the output.
VirtualEarthTiler: Spherical Mercator Coordinate System
A couple of users have experienced a problem with the VirtualEarthTiler in the last week, so I wanted to try to explain the cause (neither obvious nor simple), how to workaround it in FME2008, and how it has been resolved with FME2009.
The VirtualEarthTiler is used to turn a raster feature into a number of smaller tiles for use in Virtual Earth. It essentially does the same job as the MSR MapCruncher, but without the registration process.
The problem experienced was that the tiles that got written were not square; instead of being 256×256 they would be something like 400×256. To get square tiles required the ‘World File’ option to be turned on, posing the puzzling question “why should a world file make any difference to the size of the actual raster file itself?”
There are in fact two issues causing this to happen:
Tiling data for VE (or GE) is more complicated than you’d think. Because source data is in plain LL and Virtual Earth uses a spherical coordinate system the output ends up with a latitude distortion. This distortion exhibits itself as non-square pixels in the raster output.
For example, in a test workspace I sent the VirtualEarthTiler output to a Logger and got this:
Number of Rows : 256
Number of Columns : 256
Cell Spacing : 0.0003433,0.00029677
As you can see, the cell spacing is different making these cells/pixels non-square in shape.
However the PNG format (as with many other raster formats) only has a single “field” in which to record cell spacing; i.e. it is assumed that X spacing is the same as Y. Therefore, because the PNG writer can’t write non-square cells, the data is resampled to make the cells square.
It’s this resampling that causes the overall size of the file to be changed from the expected 256×256.
FME resamples the data to create square cells because, if it did write non-square cells, how would another application know that there is odd spacing?
The answer is the world file.
That’s why writing a world (WLD) file makes a difference to the output.
FME is happy to write non-square cells provided there is a world file, because the world file tells other applications what the cell spacing is.
So, if you do write the world file then the cells will be non-rectangular, but you MUST keep the WLD file with the PNG else any application that reads the PNG will not know what the cell spacing is and so will not show the raster in its correct size and location.
So, when you are using FME2008, you MUST have the ‘write world files’ setting turned on in your writer, and you MUST store the world files alongside the tiles for Virtual Earth to interpret the data correctly.
Getting to the real point of this topic, FME2009 supports a new coordinate system called the Spherical Mercator, aka Web Mercator, EPSG:3785 or EPSG:900913*
Spherical Mercator is the coordinate system required for correct tiling of data. So convert your source raster to this coordinate system using the Reprojector, pipe it into the VirtualEarthTiler and you will get… tiles with perfectly square cells; without the need for world files either.
* Get it? No neither did I for the longest time. I must be a n00b.
Chopper Transformer: Overhaul for FME2009
Many people who use the Chopper transformer do so to convert lines into points. However, did you know it can also be used to chop polygons into smaller area features? This might be useful where you have a maximum number of vertices requirement for your destination data.
Simply feed polygon features into the Chopper, and use a chop value of x (4 or greater), and the polygon will be split into a number of smaller area features. Each feature will have a maximum of x vertices.
Above: In this example the Chopper vertices parameter was set to 6, so no output polygon has more than 6 vertices.
This isn’t new functionality in itself, but what is new is that as of build 5556 in FME2009 beta the Chopper transformer has undergone a major improvement in the algorithm used to chop polygons.
The improvement results in:
- Faster Computation
- A Reduced number of output features
- More visually appealing output
Above: A polygon chopped using FME2008
Above: The same dataset chopped with FME2009
This Edition of the FME Evangelist…
…was written to the tune of “It doesn’t have to be this way” by the Blow Monkeys.
I don’t know how I came across this one, but it brought back some memories. 80’s music videos eh? Nothing like ‘em.
June 25th, 2008
- FME 2008 Release Updates
- AutoCAD Map 3D Object Data Reading Examples
- Shape Datasets and the Age of Innocence
- Google Spreadsheets Reader/Writer
- Creating a Shape Index with FME
- OIDs in PostGIS
- Measurement Unit Converters
1) FME 2008 Release Updates
The first of the (previously mentioned) FME2008 Update builds is now available for download. Remember, these are minor fixes made available in lieu of an FME2009 beta.
You can download the first FME2008 update online (it’s now the default 2008 download) at:
You can find a list of the changes in each particular build (this one is build 5200) on fmepedia at:
I’d suggest you read the list of updates before automatically installing this build, since only a very small minority of our users would be likely to find any benefit in the new build; but if you do have any questions don’t hesitate to contact email@example.com
2) AutoCAD Map3D Object Data Reading - Example Workspaces
AutoCAD Map3D Object Data is a very flexible and open-ended format, which is great for you users but a challenge for us when creating the reader.
What we did was add one fairly unusual setting - a reading mode (right) - that affects how the source schema is displayed in your workspace.
Is essence you can get different views of the data model depending on what actions you want to carry out on the data.
To explain the different modes we created a set of example workspaces, based on the same dataset but each in a different reading mode.
These demonstrate the different results you can obtain with each mode and help explain when you would want to use them.
See the examples on fmepedia at: http://www.fmepedia.com/index.php/AutoCAD_Map_3D_Object_Data_Reading
3) Shape Datasets and the Age of Innocence
The Safe support team has just received their first Shape dataset more than 2GB in size. As Dale puts it, the age of innocence is over. The content below explains why.
NB: If your eyes glaze over at technical details then skip the bits marked with ###.
What is the Problem?
In theory a Shape dataset greater than 2GB in size is - if not impossible - certainly very implausible and difficult to handle. It should be noted that when I refer to a Shape dataset I mean the .shp part (the .dbf part has it’s own 2GB limit which is another problem by itself…)
### In technical terms this is because internal pointers between the index (shx) and spatial data (shp) are usually stored as signed 32-bit integers, so any size over 2^31 (2^31=2147483648 or 2GB) would need a larger number than that can store. So a computer application writing Shape data would find its counter overflows at (2^31)+1 and - if it didn’t crash at that point - start writing invalid pointers. ###
However, any software that writes a Shape file might ignore the problem, and just churn out bad indexes, which is how invalid datasets more than 2GB in size come to exist.
What does FME do?
When FME reaches the 2GB maximum it too ignores the problem (we were obviously still innocent when we implemented it) and continues to write data. However - while that leads to bad index pointers, they are bad in a way that is predicatable. So we made a change to our reader to handle this and now (in FME2008 build 5199 or greater) FME is able to read back any oversize datasets created by FME. We’d also be able to read Shape datasets from other naive applications that wrote data in the same way.
That sounds like a workaround. Is there anything else you can do?
Good question. ### Getting technical again, Shape internal pointers are actually measured in “words”. A “word” is a unit of data that depends on a computer’s architecture. For backwards compatibility reasons a 32-bit computer usually uses 16-bit words. So FME counts using a 32-bit signed integer but then divides by two to get the correct pointer. If you’re following along you might now say, “Ah! Since you divide everything by two, there’s no reaon why you can’t double the size of the pointers”; and you’d be right. We just can’t do the counting using a 32-bit integer, as an application usually would, because that would overflow at the 2GB mark. ###
So a future version of FME (FME2009, build 5525+) will be able to write up to 4GB Shape (again that’s .shp not .dbf) files. A fixed limit of 4GB will be hard-coded so we don’t get datasets any larger, which really would be invalid.
Not only will FME be able to read these 4GB datasets back, we believe the data is the format most likely to be readable by other applications.
Any problems to look out for?
Yes! Technically our theory is sound - and not contrary to the official Shape specification - just complex and relatively obscure. I don’t know of another application that is using this technique so we can’t guarantee that these applications (i.e. those still sweet and innocent) would be able to read our oversized datasets correctly, nor can we guarantee that we can read an oversized dataset created by another application (though even if they’ve created invalid data, if it’s in a predictable way, there’s a good chance we will).
Will a 64-bit computer support 4GB+ files?
Yes, but it would need a change in the Shape specification, along the same lines as recent changes in the TIFF format.
The TIFF format also had a size limit [### 4GB, so presumably they were using unsigned 32-bit pointers as opposed to signed with the 2GB-limited Shape ###] and so a new specification - BigTIFF - was created to allow Large File Support (LFS). Similar updates would need to occur to the Shape format to permit files greater than 4GB in size.
### So with (unsigned) 64-bit pointers we get 2^64 = 17 million TB - that’s Terabytes not Gigabytes folks, and even the most avid data collector is unlikely to have a Shape dataset that size. To put it in perspective, this is equivalent to 16,384 Petabytes (apparently Microsoft’s Virtual Earth imagery dataset is 14 petabytes in size) or 16 exabytes. According to wikipedia 16 exabytes of disk space would cost you $3 billion at today’s prices! ###
For the techno-confused amongst you (that includes me) here are some useful explanatory articles on wikipedia:
Now if you ever appear on Jeopardy you can feel confident in saying, “I’d like Shape datasets for one thousand please Alex”.
4) Google Spreadsheets Reader/Writer
If you weren’t aware, Google makes a Python API available for reading and writing Google data - ie data on any of the Google web services such as Documents, Picasa, YouTube (I didn’t even know that was a Google service), Calendar, etc
Pro-services dude Aaron has taken advantage of this - and FME’s ability to run Python scripts - to create an FME reader/writer (actually custom transformers) for Google Spreadsheets.
There are two versions of the Writer; full and fast.
The ‘full’ version writes features one at a time. It is slow but enables the use of multiple worksheets in a single spreadsheet.
The ‘fast’ version writes to a CSV file and uploads it as a new spreadsheet (but cannot write to an existing spreadsheet).
This is another great example of using FME to access web services.
For more details get the download from fmepedia at:
5) Creating a Shape Index with FME
A frequent question to the FME support team is, “How can I create a spatial index when I write a Shape dataset?” That’s something that previously wasn’t thought possible with FME, but now a combination of Python script and ArcObjects will let you do this.
How important would it be to have indexing when your Shape file is 4GB in size, eh?!
The key is that an ArcObjects Python script can index Shape files, and FME can run Python scripts passing into it such useful values as ‘destination dataset’. So by adding such a script as a Shutdown Python Script, it’s possible to create a spatial index for any dataset you have just written.
You can find an example workspace demonstrating this technique on fmepedia at:
It’s simpler than it sounds because you just need to copy the Python script into the Shutdown script setting dialog (Navigator Pane > Workspace Settings > Advanced) and away you go. You can use the script in our workspace, but what’s really nice is that you can export a Python script from almost any tool in ArcToolbox and use that to do any number of things!
A few quick notes:
- You’ll need Python installed to run this (unlike TCL it isn’t included with FME). It can be found here.
- You’ll need ArcObjects installed (or at least the ArcGIS scripting library), which means you need an ESRI product such as ArcGIS.
- We didn’t get great results with Python v2.5 and ArcGIS v9.2, so we’d suggest using Python v2.4.
- A minor FME/Python fault means you can’t run a shutdown script without a startup script (at least not one that accesses parameters). So make sure to create a startup Python script in your workspace, even if it is empty.
No promises, but this functionality may even find its way into FME as a properly supported parameter! Remember, you heard it here first.
6) OIDs in PostGIS
Here’s a question and answer on the FMETalk user group that is probably worth passing on.
On 01/04/2008, Jeff wrote:
> Hi there,
> Could someone point out how to get FME to see the postgis oid column
> (created by FME when you choose ‘with oids’ in the format parameters)
> in the source features?
On 02/04/2008, Roland wrote:
> Morning Jeff,
> You can put in your own select statement in the feature properties.
> Under the ‘Parameters’ tab you’ll find inputs for WHERE clause and SELECT statement.
> In the SELECT box type in something like: select oid,* from <table_name>
> Attach an AttributeExposer with [an attribute] called ‘oid’ so that you can see it, and you’ll have OIDs (sounds painful).
Thanks to Jeff for posting the question and Roland for answering it; plus thanks to everyone else on the user group who participates in the FME community in this way.
7) Measurement Unit Converters
Safer Aaron Koning has really been busy (at salary review time - coincidence?!) - he’s also produced a series of custom transformers that translates length, area or volume attributes from one set of units into another.
This is a nice example of lots of things - using a Custom (Independent) published parameter, creating a custom transformer, use of the ValueMapper transformer, etc. I think I will add these to the FMEData sample dataset.
It’s not just yards or metres that it will convert either; there are lots of different units such as miles, chains, hectares, acres and six different types of foot measurement!
So if you ever wanted to convert your LengthCalculator results from your current units into twips, light-years or angstroms, here’s your chance!
Check out fmepedia to get these great custom transformers:
- The Spring 2008 edition of the FME Insider newsletter is now available. Apologies to the southern hemisphere for whom it is anything but Spring!
- An Austrian FME user conference will take place in Vienna on 20th May 2008. Click here for more details.
- Interested in Mastermap and/or SQL Server Spatial? See this blog posting for a great example that uses both.
- A month or two old, but here’s a blog posting about Don Murray’s visit to a conference on Geospatial Data Standards.
This week’s Weekly was written to the tune of…
Gerry Rafferty’s superb album North and South.
It’s my favourite of his albums, but relatively unknown. The only track I can find on YouTube is “Nothin’ Ever Happens Down Here“.
May 5th, 2008