MapInfo doesn't support writing DateTime type

[GladaFrasse]

I tried to convert/import an gpx file to mapinfo format. I have used FWtools2.2.6 and called the ogr2ogr with argument -f "MapnInfo File" test.tab tann15.gpx When run I get error and the message was "Error 1:IMapInfoFile::CreateField() called with unsupported field type 11." Does it mean that cant support gpx-files or does it med that it's missing some arguments to separate data?

I can send a file if someone want it.

/Frasse

[GladaFrasse]

file tried to convert to mapinfo

[warmerdam]

Field type 11 is OFTDateTime. The failures means that MapInfo does not have a specific datetime type.

I believe you should be able to add the -skipfailures switch on the ogr2ogr commandline to make it ignore errors creating unsupported field types, though you will loose the datetime field(s).

I'm not exactly clear on our protocol, but I think might be desirable for the mapinfo CreateField() method to fallback to creating fields requested as datetime as strings of an appropriate length.

[Even Rouault]

I confirm that the GPX driver can read successfully the file. Changing the title to reflect that

[Daniel Morissette]

The latest MITAB supports the DateTime field type. I think we just need to add proper type mapping in TABFile::SetFeatureDefn (mitab_tabfile.cpp) and MIFFile::SetFeatureDefn (mitab_miffile.cpp).

Assigning to Alan to fix this in MITAB. We'll port the fix to GDAL/OGR after.

[aboudreault]

This has been fixed in MITAB. Keep this ticket open until we merge the current mitab dev version in GDAL.

[Daniel Morissette]

I have upgraded the ogr/ogrsf_frmts/mitab driver this morning with a snapshot of the current MITAB CVS (2.0.0-dev). This fix should be in as well.

[Daniel Morissette]

Reopening. Looks like we added support for writing OFTDateTime but didn't add support for properly mapping the field type in read mode.

[Daniel Morissette]

While working on this, we have discovered that OGR's OFTDateTime carries only seconds but not milliseconds. This means that if we switch MITAB to use OFTDateTime instead of the current implementation that carries time as strings internally then we'll lose the milliseconds and users of MITAB outside of the OGR environment will complain.

Ticket #2680 has been created about adding more precision to OFTDateTime in a future release.

In the meantime, unless someone comes up with a better idea, we'll have to add the support for OFTDateTime inside #ifdef MITAB_USE_OFTDATETIME and enable it only in the ogrsf_frmts/mitab/GNUmakefile to enable this only when the code is built as part of OGR. By default, we'll continue to carry the TABFDateTime and TABFTime types as strings internally in MITAB when used outside of the OGR environment.

[Daniel Morissette]

I have updated the ogrsf_frmts/mitab source with Alan's fixes to support OFTDate/OFTTime/OFTDateTime in both read and write access. The code is inside #ifdef MITAB_USE_OFTDATETIME and I have added -DMITAB_USE_OFTDATETIME to the GNUmakefile and makefile.vc to enable it when building the MITAB driver in OGR.

Note that the current implementation could use some performance optimization to avoid an unnecessary conversion of the values to strings. This will be done after GDAL 1.6.0 and will be tracked in ​http://bugzilla.maptools.org/show_bug.cgi?id=1948