Skip to main content
  • EN

I'm having a bit of an issue with text fields being truncated, and I can't figure out why...

The fields are all text fields of varying length, with writer definitions copied from reader, and for some reason they all come to the writer truncated to 4 or 5 character's length?!

This is how the read attribute info looks (reader is GDMMAPPERQUADRI):

...and here's the writer (Writer is GEODATABASE_FILE):

Note now the attribute LEDNINGSNETTVERKSTYPE is changed from length 13 to length 5. This behaviour seems consistent for most attributes, but not all (like OBJTYPE in the example).

I tested a different writer, just to see (ESRI Shape) and it's the same there, also doesn't matter if I port directly from reader to writer or if I mess round with the data inbetween. Is it the reader that "sends the wrong signals", despite the correct attribute definitions being listed?

Unfortunately, the automatic attribute definition isn't always super clever about data types and field lengths if there are several transformers between your reader and your writer.

My recommendation is that you switch over to manual attribute definition (top of the second screenshot) and modify the data types as needed.

There could also be a defect in the reader implementation.

I was not able to find out the reader named "GDMMAPPERQUADRI" in the List of Supported Formats. Is it correct name of the reader?

There could also be a defect in the reader implementation.

I was not able to find out the reader named "GDMMAPPERQUADRI" in the List of Supported Formats. Is it correct name of the reader?

 

I think there might be something on the reader side, yes. The reader is a third party plugin developed for the Norwegian market. I'll check with the developers if thsi is a known issue

Unfortunately, the automatic attribute definition isn't always super clever about data types and field lengths if there are several transformers between your reader and your writer.

My recommendation is that you switch over to manual attribute definition (top of the second screenshot) and modify the data types as needed.

I doubt the number of transformers is the problem here, as I've also tested without any transformers, and it is still the same... Guess I'll have to test a few things and discuss this with the developers of the reader.

 

 

While the situation is as it is I guess the only way is to do the manual definition, and I've resigned to doign that for now. Thanks for the input.

 

 

I doubt the number of transformers is the problem here, as I've also tested without any transformers, and it is still the same... Guess I'll have to test a few things and discuss this with the developers of the reader.

 

 

While the situation is as it is I guess the only way is to do the manual definition, and I've resigned to doign that for now. Thanks for the input.

 

 

Yes, I just re-read your original question and saw that you'd already tried a direct connection. I agree with Takashi, sounds like it might be a small bug. Maybe @sigtill from Norkart can help?

Another option can be to use the "Import Feature Types" menu on the Writer.

Import the definition on the GEODATABASE_FILE writer using the GDMMAPPERQUADRI format (after removing the copied writer feature type, but not the writer itself).

Another option can be to use the "Import Feature Types" menu on the Writer.

Import the definition on the GEODATABASE_FILE writer using the GDMMAPPERQUADRI format (after removing the copied writer feature type, but not the writer itself).

Tried that now, but the same result as before I'm afraid...

 

 

Yes, I just re-read your original question and saw that you'd already tried a direct connection. I agree with Takashi, sounds like it might be a small bug. Maybe @sigtill from Norkart can help?
Sigbjørn (sigtill) is my go-to guy on FME in Norkart, I'll see if he knows anything...

 

 

To get me on the line ASAP you need to add mention. I am not here every day 🙂 @sigtill

There could also be a defect in the reader implementation.

I was not able to find out the reader named "GDMMAPPERQUADRI" in the List of Supported Formats. Is it correct name of the reader?

It's odd that a space is shown before the value of Width.

 

I'm afraid that this indicates that there is a defect in the functionality of the reader for creating schema definition.

 

 

The conclusion, after a skype session with @sigtill is that a small adjustment in how I set up the writers helps: By changing the Feature Class or Table Definition setting under Add writer from 'Copy from Reader...' to 'Automatic...', it seems to work fine :)

To get me on the line ASAP you need to add mention. I am not here every day 🙂 @sigtill

Thanks. For some reason I can't type in the '@' here - when I do (i.e. Alt Gr+2 on my norwegian keyboard) in this editor it just changes the text size... Copy/pasting the mention tag doesn't seem to help either...

 

Thanks. For some reason I can't type in the '@' here - when I do (i.e. Alt Gr+2 on my norwegian keyboard) in this editor it just changes the text size... Copy/pasting the mention tag doesn't seem to help either...

 

Yeah, it's a known issue. The forum developers (not Safe) seem to intercept and remap AltGr-x to different heading styles rather than triggering the @ character. It's very annoying.

 

You can work around it by temporarily switching to a US keyboard and pressing Shift-2 for the @, but it's far from ideal... :-(

 

Reply


Community Stats

30,102
Posts
114,271
Replies
37,736
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.