Patch for Seamless Tables - Allows Discovery of original tablename

[plasmab]

This patch adds functionality to OGR to allow the discovery of the table of origin for a feature in a seamless mapinfo table.

The patch uses special fields and uses the name OGR_MAPINFO_KEY, in keeping with its counterpart feature in MapXtreme. I have no preference if anyone wants to refactor this.

The patch is attached.

Stephen Leary

[plasmab]

Patch to add the above feature.

[plasmab]

OGR_MAPINFO_KEY

This special field only contains a value for MapInfo Seamless data sources. MapInfo seamless data sources are comprised of multiple tables which appear as one single data source. This special field stores the original table name from which the feature originated. For all other data sources an empty string is returned.

SELECT * FROM seamless_table WHERE OGR_MAPINFO_KEY='originating_table'

[plasmab]

2 test data sets. seamlesstest (freely distributable, very simple) Redbridge (Production data, do not distribute)

[warmerdam]

Stephen,

I'm sorry to say I don't think this patch is a good idea. The mapinfo file special attribute does not seem like a general thing that belongs in the core ogrfeature. I suspect you will need to keep this as a local patch at your site.

I'm adding Daniel in case he has some suggestion or opinion on how this should be handled. If I don't hear for a bit, I'll close it as "wontfix". If you feel very strongly, you could still try and bring the issue to the GDAL PSC to override me.

[plasmab]

Frank,

As per our discussions on #gdal I tend to agree with you on the issue of the modifications to the core. I would never try to force something through like this no matter how strongly I felt. I do, however, feel strongly that this is a worthwhile and much needed feature and may beg your indulgence to overview possible alternative mechanisms for storing and most importantly retrieving "special fields" from the drivers.

The only thing I would like to insist upon is that you place a note in GDAL RFC6 that warns again adding accessors for special fields (which are driver specific) in the core ogrfeature. This way the guildlines for special fields are clear to all.

I realise I'm repeating what we've already discussed in this message. This is mostly here for the benefit of Daniel.

Thanks for taking the time to review the patch and give feedback.

[plasmab]

Simpler patch. Modifications mitab driver only. Adds a field to only the mapinfo driver.

[plasmab]

Frank/Daniel,

I've created an alternative patch. This one does not use the special fields mechanism. It simply adds a field called "OGR_MAPINFO_KEY" to all MapInfo files a populates it for seamless files. The patch does not alter the core in any way.

I would have made this patch only for seamless tables but the m_poDefn field which holds the definitions is not accessible from the seamless table (and rightly so), therefore the only way i could see to do this would be to grab a feature when the base table loads and get the definition from that before ResetReading(). This I felt to be a bit ugly.

I did not populate this field for normal tabfiles in this patch, although I think doing so may be appropriate for consistency in the driver if the approach is considered sound.

If this seems too much to change in the driver then please consider this patch as being optional at compile time, with a configure option.

[tamas]

I could imagine to set up a metadata section in the OGRFeature to hold the driver specific information that a particular driver would like to expose additionally. After that we can easily represent the metadata keys in the queries as additional fields in an unique manner. For example in GetFieldAsString we would lookup the metadata based on the given key right before accessing the OGRFieldDefn fields.

We could only represent values of string types but it isn't a big problem in this case.

[plasmab]

With regard to implementing a meta-data system, I would be happy to do the actual work if it could be agreed on how this was to be implemented.

[Jukka Rahkonen]

No discussion lately about these seamless MapInfo tables. Does it mean that there will be no fix? By the way, MapInfo can also have seamless raster layers.

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.