Skip to main content
Archived

More consistent reader logging

Related products:Integrations
  • December 15, 2016
  • 1 reply
  • 3 views
siennaatsafe
sigtill
hsamor
havmoejbv
  • siennaatsafe
    siennaatsafe
  • sigtill
    sigtill
  • hsamor
    hsamor
  • havmoejbv
    havmoejbv

redgeographics
Celebrity

I would like to argue for more consistency in the log messages that readers generate. Specifically the message about which source file is being read.

For example the Shape reader says: Opened Shape File 'C:FMEData2016DataElevationModelContoursJ11.shp' for input

The MITAB reader says: Opened native MapInfo file `C:FMEData2016DataParks\\Parks.tab'

The PostGIS reader says: Reading POSTGIS table: 'public.steden'...

The ACAD reader says: Successfully opened the 'Release2013' AutoCAD file 'C:/FMEData2016/Data/Transportation/Roads.dwg'

Note that the wording is slightly different but at least these readers all report which file they're reading. The GML reader doesn't though... it shows quite a lot of information about how it's reading the file, except the filename. So when I was doing a bulk load of a large dataset, 90+ GML files of 300+ Mb each into 15 PostGIS tables, which failed about halfway through I had no easy way of finding out which files had processed properly and thus could be skipped in the next load.

I ran into this issue when using the GML reader (FME 2016.1.2.1), but with 360+ readers there might be more that have this shortcoming.

This post is closed to further activity.
It may be a question with a best answer, an implemented idea, or just a post needing no comment.
If you have a follow-up or related question, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.

1 reply

fmelizard
Contributor
Forum|alt.badge.img+17
  • Contributor
  • December 15, 2016

Consistency is a great goal and we'll keep this in mind. I've also asked the XML team to check if there formats could echo the actual file better. Longer run as/if we move to "FeatureReader", we plan a Summary port that will shoot out a variety of statistics and metadata about what was just read, and that may prove to be the best long term solution.


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