Skip to main content
Solved

No definition was found for coordinate system

  • February 13, 2020
  • 6 replies
  • 313 views

Hoping someone can help with this. Since upgrading to 2019.2 our existing workbenches have begun to fail. Each time a coordinate system is called on it appears to be missing a curly brace at the end.

E.g. "{EPSG:27700 is not a valid key name." or

"{OSGB-GPS-2015 is not a valid key name.

... Last line repeated 11 times ..."

These are only warnings until eventually the workbench fails under:

"No definition was found for coordinate system `{EPSG:27700' "

Wondering if this is a bug or if we are missing something?

Let me know if I need to provide more info.

Best answer by mark2atsafe

OK, so we've got this tracked down. It's all fine in 2020 (shouldn't be an issue unless you're running an early beta) and there is a fix going in to 2019.2 as well, so that will be all good if you use that too.

If you do want a fixed 2019.2 version, just keep an eye on the downloads page under Past Versions and look for an updated build/comment in the Whats New file.

Basically features are emerging from the FeatureReader without a coordinate system, if you set the coordinate system in the transformer itself. So you could ignore the issue, and it might not cause any problems for you. But the data would get written without a coordinate system attached.

The best workaround is to use a CoordinateSystemSetter transformer directly after the FeatureReader; alternatively, set a coordinate system on the writer. Better, of course, to upgrade to 2020 if possible or to a newer a 2019 when it becomes available.

Apologies for the issues, but at least we've got it pinned down now.

Update: This has been fixed in the last release of FME 2019.2.3.2, which can be found here. The issue is also resolved in FME 2020

View original
Did this help you find an answer to your question?

6 replies

Setting the coordinate system in the Feature Writer fixes the issue somewhat. The workbench no longer fails but is still full of warnings.

The issue seems to stem from an Esri Geodatabase (File Geodb Open API) feature reader.

The warnings do not occur if a File Geodb feature reader is used, but we need to use Open API as we run multiple instances of the workbench simultaneously.


mark2atsafe
Safer
Forum|alt.badge.img+44
  • Safer
  • February 13, 2020

Hi

It looks like this has just been reported by another user too. It's filed with our developers under the reference number FMEENGINE-62991.

I'm not sure it's related to Geodatabase, since the other user wasn't using Geodatabase. For the time being the best workaround seems to be to ensure a coordinate system is set in the writer (and ignore the warning messages). But I'll push to get this fixed as soon as possible.

Apologies for the inconvenience this must be causing,

Mark


lindsay
Contributor
Forum|alt.badge.img+3
  • Contributor
  • February 28, 2020

As a further point of reference, I just encountered this issue during some intermediate processing.

I'm using the Reprojector on a set of rasters, so I can combine them in a RasterMosaicker and the issue occurs in this scenario, with no geodatabase involved.

Using the CoordinateSystemSetter after reprojecting seems to remove the error from the Translation Log.

I'm using FME Desktop Esri Edition Version 2019.2.3.1 (build 19823).


samisnunu
Contributor
Forum|alt.badge.img+10
  • Contributor
  • February 28, 2020

Me too have the same issue or behavior recently on FME 2019.2.3.1 (20200212 - Build 19823 - WIN642)

|WARN |{NG_Equidistant_Conic_U is not a valid key name.

Alos noticed it trimmed the full name (NG_Equidistant_Conic_USft)

Might be because this is a custom coordinates system, reading from external .fme file?

I just ignored it for now..thanks @mark2atsafe


mark2atsafe
Safer
Forum|alt.badge.img+44
  • Safer
  • Best Answer
  • March 16, 2020

OK, so we've got this tracked down. It's all fine in 2020 (shouldn't be an issue unless you're running an early beta) and there is a fix going in to 2019.2 as well, so that will be all good if you use that too.

If you do want a fixed 2019.2 version, just keep an eye on the downloads page under Past Versions and look for an updated build/comment in the Whats New file.

Basically features are emerging from the FeatureReader without a coordinate system, if you set the coordinate system in the transformer itself. So you could ignore the issue, and it might not cause any problems for you. But the data would get written without a coordinate system attached.

The best workaround is to use a CoordinateSystemSetter transformer directly after the FeatureReader; alternatively, set a coordinate system on the writer. Better, of course, to upgrade to 2020 if possible or to a newer a 2019 when it becomes available.

Apologies for the issues, but at least we've got it pinned down now.

Update: This has been fixed in the last release of FME 2019.2.3.2, which can be found here. The issue is also resolved in FME 2020


lindsay
Contributor
Forum|alt.badge.img+3
  • Contributor
  • March 16, 2020
mark2atsafe wrote:

OK, so we've got this tracked down. It's all fine in 2020 (shouldn't be an issue unless you're running an early beta) and there is a fix going in to 2019.2 as well, so that will be all good if you use that too.

If you do want a fixed 2019.2 version, just keep an eye on the downloads page under Past Versions and look for an updated build/comment in the Whats New file.

Basically features are emerging from the FeatureReader without a coordinate system, if you set the coordinate system in the transformer itself. So you could ignore the issue, and it might not cause any problems for you. But the data would get written without a coordinate system attached.

The best workaround is to use a CoordinateSystemSetter transformer directly after the FeatureReader; alternatively, set a coordinate system on the writer. Better, of course, to upgrade to 2020 if possible or to a newer a 2019 when it becomes available.

Apologies for the issues, but at least we've got it pinned down now.

Update: This has been fixed in the last release of FME 2019.2.3.2, which can be found here. The issue is also resolved in FME 2020

Thanks for the update, @mark2atsafe.

I've installed 2020 and can confirm that I no longer encounter the warning message when running my workbench.


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings