Global Mapper v25.0

Shapefile Elevation Import/Export

dcoggin
dcoggin Global Mapper UserTrusted User
edited August 2010 in SDK
Mike,

When exporting lines and areas with elevations to shapefiles (GM_ExportVector) on a 32-bit system, the elevation is converted from meters to feet in the exported shapefile. In other words, if I export a line with vertex elevations valued at 1.0 (I confirmed the elevation values in the layer were 1.0 immediately prior to the GM_Export Vector call), the exported shapefile has elevation values of 3.2808. I have confirmed this by reading the shapefile in other software and examining the floating point value. This does not happen when the exact same code is compiled on a 64-bit system. I don't know if it matters, but I checked that the mElevUnits in the exported layer is zero (meters). Any ideas? Thanks for your help.

David

Comments

  • global_mapper
    global_mapper Administrator
    edited August 2010
    David,

    By default your SDK-based application shares settings with a Global Mapper installation on the same machine. What has likely happened is that the shared elevation display/export setting was changed to Statute, so your elevation values are being converted to feet on export. You can use GM_SetRegistryKey to have your application settings be separate from the Global Mapper application settings.

    I have added a way to programmatically set the vector elevation units using the GM_SetMiscOption setting in the SDK. I have placed a new build with this change at http://www.globalmapper.com/GlobalMapperSDK_v134_beta.zip. You will want to make the following call before your export to set the elevation units for 3D vector exports to meters:

    GM_SetMiscOption( GM_MiscOpt_SetVectorExportElevUnits, GM_ElevUnit_Meters );

    If you want the export to instead always just keep the elevation units as they are originally and not convert them, use the following:

    GM_SetMiscOption( GM_MiscOpt_SetVectorExportElevUnits, GM_ElevUnit_NumUnits );

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • dcoggin
    dcoggin Global Mapper User Trusted User
    edited August 2010
    Mike,

    So what is the difference in exporting after making the two calls

    GM_SetMiscOption( GM_MiscOpt_SetVectorExportElevUnits, GM_ElevUnit_Meters );

    or

    GM_SetMiscOption( GM_MiscOpt_SetVectorExportElevUnits, GM_ElevUnit_NumUnits ); ???

    I didn't think Global Mapper or the SDK looked at vertical information in the .prj file and I checked the shapefile without even reading the .prj file. I suppose that exporting after setting the MiscOptions with GM_ElevUnit_NumUnits causes the written number to be exactly what I would see by viewing the stored vertex elevations for the vector feature. In which cases would exporting after calling GM_SetMiscOptions with GM_ElevUnit_Meters be different? I would always expect the shapefile to write with the same value as the stored elevation value since (I believe you told me before) GM does not store elevation info in the .prj file.

    David
  • global_mapper
    global_mapper Administrator
    edited August 2010
    David,

    Every vector layer has an elevation unit associated with it indicating the units for unspecified values (such as per-vertex elevation lists or elevation attributes with no unit text). In most cases this will default to meters without asking the user, but you can always set the elevation units interpretation for a vector layer after loading using the GM_SetLayerElevationUnits function.

    If you set the elevation units for a layer to feet, then export with the GM_SetMiscOption set to metric, your values will be converted from feet to meters on export.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • dcoggin
    dcoggin Global Mapper User Trusted User
    edited August 2010
    Mike

    Thanks very much for your help. I don't mean to be dense, but I still don't understand how I control the vertical units for export.

    I don't understand if I had creaated a vector feature, set all elevation values to 1.0, then exported after setting:

    GM_SetMiscOption( GM_MiscOpt_SetVectorExportElevUnits, GM_ElevUnit_Meters );

    or

    GM_SetMiscOption( GM_MiscOpt_SetVectorExportElevUnits, GM_ElevUnit_NumUnits );

    what would be the difference? How is it affected by current registry or other application settings if there is an installed Global Mapper. Of course, I want this to work whether or not there is an installed Global Mapper on the machine.

    This has caused a lot of rework for me on my current project which I have finally been able to pinpoint to the SDK shapefile export.

    From your last post:
    Every vector layer has an elevation unit associated with it indicating the units for unspecified values (such as per-vertex elevation lists or elevation attributes with no unit text). In most cases this will default to meters . . .[End Quote]

    I checked that the layer value for mElevUnits was 0 prior to export, but yet it still wrote the shapefile with feet values. i.e. The vector feature elevation was 1.0 but the written shapefile z value for the point was 3.2808.

    David
  • global_mapper
    global_mapper Administrator
    edited August 2010
    David,

    That 1.0 elevation value has some elevation units associated with it, that being the elevation units for the layer, which was meters (a mElevUnits value of 0 in the GM_LayerInfo_t structure). The export elevation units (which is what the new GM_SetMiscOption flag controls) must have been set to statute, which means the meters value of 1.0 was converted to 3.28 feet on export since the newly exported file had elevation units of meters.

    If you don't ever want the values to change, just make sure that the export elevation units is the same as the layer elevation units, or use GM_ElevUnits_NumUnits for the export elevation units option, which causes no conversion to be done regardless of units.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com