FME Evangelist: The Feature Presentation

Hi FME’ers
Here’s another cut and paste job – this time it’s something from our upcoming user conference workshops.

Mark Stoakes – the head of our Professional Services team – is giving a workshop on Stretching FME Boundaries. In this he’ll talk about some of the techniques we’ve used in recent projects at Safe.

When writing the workshop, what came out was a diagram about data and what FME describes as a “Feature”. In training courses I always say a feature is the smallest unit of FME data; but if you think about it that turns out not to be the case. There are many different sub-components to a feature that you may not even be aware of.

So below is the diagram. Yes we’re hoping for someone in marketing to pretty it up!

To me three things spring to mind here.

Firstly there is the concept of a multiple-geometry feature. That isn’t an aggregate (or collection) as such, but an actual feature composed of more than one geometry; for example a line feature with related annotation. Many GIS systems and formats support this concept, and it won’t be too long (I boldly predict) before FME transformers don’t only ask you to select attributes, but also ask you to select which geometry you wish to process.

That’s because each geometry could have a different name, and one set of features could have multiple geometries with different names – for example an engineering project might have a feature with two representations; as-designed and as-built.  Cool eh?

The second item that sprang to mind related to traits. Traits are like attributes but – in general terms – persist on a feature even when it is processed further. So, for example, (and assuming I understand this correctly) if I combine a line, arc and another line into a “path” feature, whatever traits the original features had will persist in the path, and if I split them up again then they will still retain their original traits.

I’m not sure exactly what use we put these to, but I’m hoping all will be revealed in Mark’s workshop.

The final item relates to measures. Measures – for me – are usually a representation of how far along a line feature each vertex is. So for example, vertex one has a measure of zero, vertex two has a measure of 100 (ie it’s 100m along the line), vertex three is 200, etc, etc. However Mark highlights the case where each vertex represents an event – in this case an event along a bus route. So a measure of 1 indicates start of the route, 2 indicates a mid point, 3 is the end of the route, and 4 is a bus stop on the route. Mark calls these Discrete Measures.

Again measures are sometimes preserved even when you process the data. So it appears you could use measures within a workspace – without even wanting to read or write them – just to make use of the ability to keep a record attached to each point on a larger feature.

Anyway, I think this all promises to be a very interesting workshop. It will first take place the day before the conference in our advanced training sessions. If you’re not attending the conference then it’s not too late to sign up and attend. If you are attending the conference, but not the workshops day, then don’t despair: this workshop is one of those being repeated during the conference itself (though of course you’d have to miss some of the fascinating talks on at the same time).

Check out the website at www.fmeuc.com for more information. I hope to see you there,

Regards

This Edition of the FME Evangelist…
…was written to the tune of Paul McCartney’s excellent James Bond theme, Live and Let Die; but if you want to know why you’ll have to come to the user conference!