Skip to main content
  • EN
Hi everybody, 

 

 

I have a weird problem with my reader. 

 

 

My reader was written in C++ and requires a coordinate system for the reading procedure. So, the FME user clicks "Add Reader", selects my reader as format and a coordinate system (for example EPSG:3493). Afterwards he chooses all remaining parameters and clicks "Ok". The translation process starts automatically.

 

 

Next, my reader`s open() method starts and fetches all parameters. I use the keyword "_COORDINATE_SYSTEM" to receive the entered coordinate system.  

 

 

gMappingFile->fetchWithPrefix(readerKeyword_.c_str(), readerTypeName_.c_str(), "_COORDINATE_SYSTEM", outputString)

 

My problem:

 

This line only works, when the reader is already added to user`s workspace and the user click on the button "Run or Resume translation of the workspace" (green play button at toolbar). It does not work at the first translation, when the user clicks "Ok" on the "Add Reader" dialog (again, the translation start automatically after the dialog is closed). Maybe the mapping file is not completly generated at this point in time? I don`t know. Other parameters do not cause this problem, they are immediately available.

 

 

 How can I receive the entered coord. system using a C++ reader? I could not find another way but the keyword method described above. 

 

 

Thanks

 

ben

 

 

If I understand your problem, you need to make sure your parameter is listed in your metafile's SOURCE_READER entry. Only parameters listed there are available during "workspace generation", which includes Reader and Feature Type addition.

Even at that point you may find that some parameters are available only in your open() parameters. See http://docs.safe.com/fme/html/FME_Metafiles/index.... for details on how to use a hyphen prefix to ensure your parameter always shows up in the mapping file object.

Thanks for answering.

But...how does that make sense? The coordinate system parameter is provided by FME itself, it is not part of my reader`s metafile.

My reader requires access to the coordinate system during workspace generation. The user can set the coordinate system within the "Add reader" dialog. Not as part of "my" parameter settings (specify within my reader`s metafile), but as part of FME.

If I understand you answer correctly, I now have to write my own coordinate system GUI field in the metafile?

I believe this is the first time I've heard of a reader using the standard coordinate system field during workspace generation.  May I ask what you are doing with it?

At any rate, I couldn't figure out a metafile trick to convince FME to pass the native coordinate system through during workspace generation, so you are stuck defining your own field.  It would look something like the following:

SOURCE_READER MSSQL_JDBC_SPATIAL    \
   -MYCS "$(MYCS)"   \
   -QUERY_TIMEOUT "$(QUERY_TIMEOUT)"   \
   EXPOSED_ATTRS  "$($(FORMAT_SHORT_NAME)_EXPOSE_FORMAT_ATTRS)"

SOURCE_SETTINGS
DEFAULT_VALUE MYCS $(MYCS)
GUI CSMAP_COORDSYS MYCS EnableReadFromFeature:No Coordinate System:
Â...]

Please send an enhancement request on through the official support channels if you want to use the native CoordSys picker.

Ok. Thanks for the metafile code.

I am still a little bit confused. What is the different between the translation process and the "workspace generation"? Because FME calls the exact same methods in both processes.

I need the coordinate system, because my reader allows a user to request a scene, that is stored on a remote database. In addition, a user can set coordinates to specify which part of the scene he wants to request. So I have to make sure that user and database work with the same coordinate system. Both, coordinates and coordinate system, should be set by the user in the "Add Reader" dialog.

Ok. Thanks for the metafile code.

I am still a little bit confused. What is the different between the translation process and the "workspace generation"? Because FME calls the exact same methods in both processes.

I need the coordinate system, because my reader allows a user to request a scene, that is stored on a remote database. In addition, a user can set coordinates to specify which part of the scene he wants to request. So I have to make sure that user and database work with the same coordinate system. Both, coordinates and coordinate system, should be set by the user in the "Add Reader" dialog.

During workspace generation, FME does call the `read()` method on a reader, but the `open()` parameters will have indicated that you are supposed to be producing schema features rather than data features. I wouldn't expect schema features to differ based on a search envelope coordinate system.

That being said, the coordinate system on the reader itself has a very specific meaning: all features emitted by that reader will be tagged with that coordinate system, regardless of whether it makes any sense. Search envelopes are always assumed to be in the same coordinate system as the data being queried.

(There is a way to specify that the envelope needs to be reprojected into the source coordinate system, but I can't find a good example of that and I'm not sure if that would help you anyway.)

Ok. Thanks for the metafile code.

I am still a little bit confused. What is the different between the translation process and the "workspace generation"? Because FME calls the exact same methods in both processes.

I need the coordinate system, because my reader allows a user to request a scene, that is stored on a remote database. In addition, a user can set coordinates to specify which part of the scene he wants to request. So I have to make sure that user and database work with the same coordinate system. Both, coordinates and coordinate system, should be set by the user in the "Add Reader" dialog.

Ok, thanks again for your support. I think I can work with that ;-)

Reply


Community Stats

30,109
Posts
114,302
Replies
37,745
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.