Skip to main content
  • EN
  • Home
  • Forums
  • FME Form
  • Transformers
  • How to evaluate if an input has a coordinate system, if yes do something, if not do something else, if mixed do something else again.

I have workbenchs published to FME server that lets an end user upload a file (KML, SHP, DWG, TAB) that will convert to (KML, SHP, DWG, TAB) plus re-project if the output coordinate is set.

If the input file has a coordinate system everything works fine, but if a uploaded file is missing a coordinate system the workbench fails and the end user doesn't know why as they can't see the error logs.

This is where I had the idea to give them a txt file saying, add an Input coordinate system. I don't want to make the input coordinate system required as the end user might not know or might enter it incorrectly (I'm trying to make it idiot proof as much as possible 😀 ).

Now comes my issue. How do I test for all three conditions;

Has coordinates = Converts data

Has no coordinates = Txt File

Has coordinates and no coordinates = Converts data and doesn't send txt file.

So far I can only do the first two. There is possibly a better way than what I have come up with. Any suggestions?

As far as i'm aware KML is always WGS84 but your question makes me doubt.

 

Put a CoordinateSystemExtractor after your reader and a Tester to check if _coordsys has a value.

 

Let the first (Sampler) failed feature read the Text File (FeatureReader). And FeatureMerge this Feature with all failed Features. Set the coordinates of all features with your CoordinateSystemSetter.

 

 

 

As far as i'm aware KML is always WGS84 but your question makes me doubt.

 

Put a CoordinateSystemExtractor after your reader and a Tester to check if _coordsys has a value.

 

Let the first (Sampler) failed feature read the Text File (FeatureReader). And FeatureMerge this Feature with all failed Features. Set the coordinates of all features with your CoordinateSystemSetter.

 

 

 

Yes KML should have a Coordinate system, some elements within it don't (see attached KML). I can apply this method to other workbenches with other inputs such as DWG (I just don't have data to meet the three conditions like the attached KML). As for the CoordinateSystemExtractor I already have this in the workbench (see attached) like you have suggested, but its testing for the three different conditions I'm having trouble with.

Yes KML should have a Coordinate system, some elements within it don't (see attached KML). I can apply this method to other workbenches with other inputs such as DWG (I just don't have data to meet the three conditions like the attached KML). As for the CoordinateSystemExtractor I already have this in the workbench (see attached) like you have suggested, but its testing for the three different conditions I'm having trouble with.

Ah.. after reading your question again, I think I understand.

For the KML you should use a geometryFilter and only allow features with geometry. Features that don't have geometry don't need coordsys.

 

This also solves for DWG.

 

If you have a format where multiple features with geometry exist where some have and some don't have a coordsys then there is a solution, but I don't think that will be your problem.

Another option is to use the NoFeatureTester. You can use this to control the flow. For example of you test for _coordsys​ and in the passed port you attach a NoFeatureTester only will a feature ever come out if absolutely no features have a coordinate system.

​

But to be fair the GeometryFilter is probably enough as suggested by @jkr_da​ 

So after a long day of testing, I finally found a solution. I ended up using StatisticsCalculator and counts of the attributes then test filters. not sure if this is the best way but it works. As for the suggestions above, I need to use CoordinateSystemExtractor to ensure if the user had entered an input coordinate it would register it. Anyway I have attached the working workbench. Cheers

Reply


Community Stats

30,176
Posts
114,544
Replies
37,836
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.