Opened 16 years ago
Closed 5 years ago
#2534 closed enhancement (wontfix)
Add XML Metadata support to PGEO driver
| Reported by: | warmerdam | Owned by: | warmerdam |
|---|---|---|---|
| Priority: | normal | Milestone: | closed_because_of_github_migration |
| Component: | OGR_SF | Version: | unspecified |
| Severity: | normal | Keywords: | PGEO |
| Cc: |
Description
Mike Childs (Global Mapper) reports:
I did get a request from a user to provide access to the XML metadata in an ESRI MDB file in the GM_UserMetadata table, so I went ahead and added support to the pgeo library for that. I'm not sure exactly where to submit this changes to the community, so I thought I would just provide them to you for review and possible inclusion. The changes are pretty minor.
Updated code attached...
Attachments (2)
Change History (8)
by , 16 years ago
| Attachment: | pgeo_xml.zip added |
|---|
follow-up: 2 comment:1 by , 16 years ago
It appears the patch exposes the metadata via a special method on the OGRPGeoLayer called GetMetadata(). It is not clear how generally useful this will be since it is not part of the OGR data model.
I've asked Mike to comment here.
comment:2 by , 16 years ago
That is correct, the extra information is currently exposed only through the GetMetadata function in the OGRPGeoLayer class. I wasn't too sure the best place to put this in the OGR data model for easier access. Perhaps in the OGRFeatureDefn class? Anyone have any suggestions?
comment:3 by , 16 years ago
Mike,
There are a couple possible approaches (at least).
1) Extend the OGRLayer interface so that GetMetadata() is a proper part of the OGR data model and general API. To do this we would need to write an RFC and clearly document the intended semantics of the method on different datasources.
2) Treat the metadata as a layer - essentially expose GDB_UserMetadata as a non-spatial OGR Layer in the PGEO driver. It would then be up to application code to query it much as you have done in the driver. This would not require an RFC, and would remain a local change in the PGEO driver. It would be a non-trivial amount of change from the current patch, but it would also leave an obvious approach to exposing any other GDB_ tables we decide are of broader interest.
comment:4 by , 16 years ago
Since the metadata is really tied to an existing layer I think that adding something to the OGRLayer interface would make more sense than creating a separate non-spatial layer for the table that users would then have to know how to join up to the appropriate spatial layer themselves. That logic should be hidden in the pgeo library.
I'm not sure what all is involved in a RFC. I think if this was moved up to the OGRLayer level that it should maybe be called GetXmlMetadata (it probably should be called that in the OGRPGeoLayer as well) since it should always contain XML-formatted metadata for the layer. I supposed a new virtual GetXmlMetadata function could be added to OGRLayer and any layers that have additional metadata available in XML format (like OGRPGeoLayer) could override that. I think I have seen XML metadata files accompanying data in other formats that I have seen.
comment:5 by , 9 years ago
Note that since GDAL 2.0, OGRLayer derives from GDALMajorObject, so the metadata could be reported properly.
comment:6 by , 5 years ago
| Milestone: | → closed_because_of_github_migration |
|---|---|
| Resolution: | → wontfix |
| Status: | new → closed |
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.
updated driver code.