Question

Unexpected Input. How to adopt feature types from another reader?

B
Badge
Hello,

 

 

I am working on a reader, that connects to a remote database and receives a .gml file.

 

Because I do not want to implement the CityGML specification, the received file is forwarded to the CityGML reader (provided by FME itself). 
 IFMEUniversalReader* additionalReader_; additionalReader_ = fmeSession_->createReader(kSysCityGML, FME_FALSE, directiveReader); additionalReader_->open(dataset_.c_str(), *params);
 dataset_ stores the path to the received .gml file. However, I have no idea how to adopt the feature types to my reader during the read operation. The read method contains a simple forwarding: 
 additionalReader_->read(feature, endOfFile);
 Using this code I get a warning each time the reader is running: 
 Unexpected Input: During translation, some feature were read that did not match a reader feature type in the workspace. This can happen if the reader dataset if changed, or a reader feature type removed or renamed.
 Of course this message makes perfect sense, since my reader has no idea what type of features it gets from the CityGML reader (additionalReader_). My question is, how can I avoid this message? Somehow, my reader has to adopt the given feature types from the CityGML reader at runtime.

 

 

I could not find any tutorials or blog posts dealing with this problem, so I hope someone here can help me.  

 

The code is written in cpp.

 

 

I known that the CityGML reader can handle files from a database directly. Unfortunately, I need special parameters for the connection, which are not provided by the CityGML reader.  

 

 

Thanks.

 

ben

6 replies

takashi
Rank
Userlevel 2
Badge +17
Hi Ben,

 

 

In general, you can limit the feature types by the "IDLIST" directive, which can be passed to the reader through the 3rd argument of the IFMESession.createReader function. The value of the directive is a string containing feature type names in comma-separated format.

 

But I'm not sure if there is something special usage for the CityGML format.

 

 

See also the "FME Objects C++ API" documentation in your system.

 

<FME_HOME>\\fmeobjects\\cpp\\apidoc\\index.html

 

 

Takashi
takashi
Rank
Userlevel 2
Badge +17
... maybe it's not an issue on the directive.

 

 

Did you implement the readSchema function of your reader class so that the CityGML schema will be read?
B
Badge
Thank you for your answer. 
 Did you implement the readSchema function of your reader class so that the CityGML schema will be read?
 Yes and no. The readSchema method of my reader class forwards the feature just as the read method does: 
 additionalReader_->readSchema(feature, endOfSchema);
 However, this method is never called during the process anyway. I am using a metafile (in combination with gMappingFile) to handle all input parameters. Do I have to call the readSchema method manually and if yes, when should I do this? And how do I implement the readSchema method correctly? 

 

 

I am familiar with the api doc (well, at least I have read it ;-) ). But to be honest, I do not understand complety when FME is calling read() and when readSchema(). According to the api doc, "A reader may be opened to read schema features or data features but not both". Since I am using data feature (=> read() is called), I am a little confused: why do I need to implement readSchema() as well?

 

 

 
takashi
Rank
Userlevel 2
Badge +17
In my observation, the "readSchema" function will be called repeatedly until you set FME_TRUE to the endOfSchema variable, before starting to read data features.

 

To make sure where the problem is, I always log the status in a function using the FMELogFile object, which was passed as an argument of the "FME_createReader" function.

 

e.g.

 

    gLogFile->logMessageString("MyReader::readSchema was called.", FME_WARN);

 

 

How about logging the status to know what is happening (or not happening)?
B
Badge
Thanks again for answering.

 

 

I know what is happening.

 

1) myReader::open() is called. This method fetches all enduser`s parameters and uses them to establish a connection to my remote database. My database sends a CityGML file. At last, myReader::open() creates a CityGML reader and passes the received CityGML file to it (see my code above).

 

2) myReader::read() is called. This method simply forwards all features to the CityGML reader. 

 

3) myReader::close() is called.

 

 

That`s it, no other methods are touched during the process. After these steps, FME says everything is fine, except that 
 Unexpected Input: During translation, some feature were read that did not match a reader feature type in the workspace. This can happen if the reader dataset is changed, or a reader feature type removed or renamed.
 

 

So, if readSchema() is required, I have to call it manually. Is this necessary?

 

 

I think my problem is step 2), I have to do more than just forwarding every feature. But what I need to do in addition and how can I do it?
B
Badge
If that is unclear: My logger confirms that the forwarding in step 2) is successful for every feature.     gLogFile->logFeature(feature) shows the correct attributes and information of each feature, after it was read by the CityGML reader.

Reply


Community Stats

28,670
Posts
109,364
Replies
36,531
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.