NIM075701 for ArcSDE/Enterprise Geodatabase

Bug ID Number	NIM075701
Submitted	November 23, 2011
Last Modified	June 5, 2024
Applies to	ArcSDE/Enterprise Geodatabase
Version found	10.0
Status	Will Not Be Addressed

Additional Information

We apologize that we were unable to address this issue within the current product support cycle. If the issue continues to affect your work in a supported release, please contact Technical Support.

Workaround

From: <a href="mailto:support@safe.com" target="_blank">support@safe.com</a> [mailto:<a href="mailto:support@safe.com" target="_blank">support@safe.com</a>] Sent: Thursday, December 08, 2011 2:03 PMTo: Margaret MaherSubject: RE: C50224 - #981920 Data Interoperability Export from Geomedia Warehouse coordinates lose precision [ ref:00D3ePES.5003HUml3:ref ]Hi Margaret,This is a long email, but explains what the problem is and suggests a workaround. Please let us know if your client is ok using the workaround. There are 2 issues:1. FME doesn't know about the ETRS89 datum id for Geomedia, so does not pick up the coordinate system when it is not defined by the user. The coordinate system is used when creating the Geodatabase feature class. If it is known to be LL-ETRS89/01, the resolution is 0.000000001 degrees. If it is unknown, the resolution is 0.0001 unknown units. 0.0001 degrees is a huge distance, and vertices can be moved arbitrarily up to this far (or maybe it's half that far, but the effect is similar).This is easy to fix; we need to add two lines to<install>/Reproject/Fm0Datums.db:ETRS89/01492. The coordinate systems are identified by guids in the GCoordSystem table. You find the coordinate system for a geometry column in a table in part by finding this guid in the GeometryProperties table. The attached mdb has a mismatch between these two places. All of the entries in GeometryProperties point to GUID E3B59468-D654-467F-83AC-B9A2F4EBB089 but Geomedia Pro somehow uses this to look up the GUID 83E91EF7-0BF8-4F84-801F-C3A80E8E6822 in GCoordSystem.Evidence: (a) I renamed the system with GUID 83E91EF7-0BF8-4F84-801F-C3A80E8E6822 inGCoordSystem. Geomedia Pro sees the new name associated with all the featuretypes. (b) I deleted the system with GUID 83E91EF7-0BF8-4F84-801F-C3A80E8E6822 inGCoordSystem. Geomedia Pro sees that all of the feature types have an invalidcoordinate system. (c) I changed the system with GUID 83E91EF7-0BF8-4F84-801F-C3A80E8E6822 inGCoordSystem to have GUID E3B59468-D654-467F-83AC-B9A2F4EBB089 (thinking thatthis is what Geomedia must be looking for -- not so). Geomedia Pro sees thatall of the feature types have an invalid coordinate system. (d) Using database utilities, I see that the original file has no coordinatesystem associated with any feature type. After applying change (c), databaseutilities sees the correct coordinate system associated with every featuretype. This suggests that Geomedia Pro's database utility program is making thesame (obviously wrong) assumptions that FME and I am, in contract to GeomediaPro. (e) Using database utilities and the original file, I reassigned thecoordinate system for a feature type. This changed the row inGeometryProperties from pointing to GUID E3B59468-D654-467F-83AC-B9A2F4EBB089to start pointing to GUID 83E91EF7-0BF8-4F84-801F-C3A80E8E6822. This thenworked in Geomedia Pro.Item (e) suggests a workaround. If the user is willing to use database utilities to reassign the coordinate system associated with each feature type -- they may not as a warning is printed that metadata may be lost, but I think all will be well -- then FME will work with the text file additions (see #1) shown above.Regards,MitaNew email from Safe Software:-----Original Message-----From: <a href="mailto:support@safe.com" target="_blank">support@safe.com</a> [mailto:<a href="mailto:support@safe.com" target="_blank">support@safe.com</a>] Sent: Tuesday, January 17, 2012 12:27 PMTo: Margaret MaherSubject: RE: C50224 - Reminder from Safe Support [ref:00D3ePES.5003HUml3:ref]Hi Margaret,I have an update to PR #35318. We had one our Integraph contacts take a look at your client's .mdb file:The mdb file has likely been corrupted due to edits outside of Geomedia. The coordinate system associated with the feature classes inside has been deleted, and so Geomedia knows to use the default coordinate system instead. This default is stored in a hidden database property ("DefaultCoordinateSystem") in the mdb. See:<a href="http://news.office-watch.com/t/n.aspx?a=1101&z=0" target="_blank">http://news.office-watch.com/t/n.aspx?a=1101&z=0</a><a href="http://office-watch.com/t/n.aspx?a=1102&z=0" target="_blank">http://office-watch.com/t/n.aspx?a=1102&z=0</a>The important bit is that the Microsoft Access application lets you see and edit custom database properties, but the ones shown in the GUI are *different* than the set relevant here.As discussed earlier, the user can (at least partially) repair their mdb using the Database Utilities program to re-point the feature classes at the correct coordinate system.On our end we have modified the PR so now the task is to make FME warn users when it encounters an invalid coordinate system GUID for a feature class. I will be in touch again when this PR is resolved.Thanks,Mita