MIGRATION GUIDE
SEDRIS SDK Release 4.0.x to Release 4.1 |
---|
This migration document describes the required changes to migrate applications developed using SEDRIS SDK Release 4.0.x to SEDRIS SDK Release 4.1. This document covers all aspects of the SDK. New SEDRIS SDK users do not need to read this document.
This document provides the key migration concepts and has links to the detail changes such as function and name changes.
For general information about this release and items that require specific attention, see the Release Notes.
For help with the migration process or other questions and comments please send email to [email protected]. If you are an associate, please send email to [email protected].
Return to: Top
This release includes a name replacement Perl script (name_change.pl) that can help users to replace old names in their source code (i.e. function names, data type names, etc.) with the new ones. This script covers most of the cases where there is a one-to-one mapping. However, there are cases where manual editing of the source code will be required. In addition, the script can be customized to map user-defined types. Please read the Name Change script Readme file for more information.
Return to: Top
This section describes the changes to the source tree structure and file names. This information is only relevant if you are using a source code distribution.
- The SRM has been changed significantly.
Return to: Top
This section summarizes the major changes to the DRM technology component. For detailed information on DRM type and function changes, see Migration Guide - DRM and DRM API. For further information on class field mappings, other individual class changes, and constraint changes, see Migration Guide - Classes.
The following are general DRM API changes:
- The NULL entry for SE_DRM_Class is now numbered one instead of zero, and all the other class tags' enumerants have been incremented by one accordingly.
The following are the major DRM changes that require a user to modify their processing of transmittals:
- <Access>
Instances of the <Legal Constraints> and <Security Constraints> classes that replaced <Access> are now required to always be components of an <Identification> instance. Consequently, for any object X that previously had an <Access> component, the <Identification> component of X will now have the corresponding Legal Constraints and / or <Security Constraints> instances as components. In a 4.0.x to 4.1 conversion, if X did not previously have a <Description> component, X would have a new <Identification> component added for this purpose.- <Citation>
If a <Citation> instance C was previously a component of an object X, where X is an instance of any class other than <Keywords> or <Source>, C shall instead be a component of the <Identification> component of X, unless X was a <Cross Reference> instance. (In that case, C shall not be converted.)- <Conformal Behaviour>
Consult the clarified constraints on this class to ensure that instances of it are being used in a valid context.- <Literal>, <State Data>, <State Related Features>, <State Related Geometry>
In conversion from 4.0.x to 4.1, the old value_characteristic union member has been removed in compliance with EDCS. This was not previously a valid case, so during conversion an occurrence of this will generate an error message.- The universal flag of a topology volume has been moved from the shell class to the volume class.
- <Property Description>, <Property Value>
The inheritance of <Property> instances are explicitly stated through the new apply_property_inheritance field of <Property>.- <Responsible Party>
For every <Responsible Party> component R of an object X, the relationship between X and R shall now have a <Role Data> link object, taking over what was previously the role field of <Responsible Party>.- The DRM changes due to SRM changes are described in Migration Guide - SRM.
Return to: Top
This section summarizes the major changes to the EDCS technology component. For detailed information on EDCS changes see Migration Guide EDCS API.
The following are the general EDCS changes:
- This version of EDCS is the implementation of the ISO EDCS specificaion FDIS version. Consequently, the concepts defined herein will be consistent with that specification.
- EDCS_Attribute_Value's EDCS_Value_Characteristic_Code field has been removed. Any object needing to specify this information shall specify a <Property Characteristic> component instead. See also <<Property Characteristic Constraints>> for the constraints affecting some of the most frequently asked questions.
Return to: Top
This section summarizes the major changes to the SRM technology component. For detailed information on SRM data types and structure changes see Migration Guide - SRM and SRM C API 4.0 to 4.1 Migration Guide.htm.
- The SRM C API has changed significantly to take a more object-oriented approach.
- The SRM C++ API has mostly remained as in 4.0. There is a set new SRF data structure that consolidates all the SRF parameters under one single data structure. This new data structure is as follows:
- There is a new SRF parameter type that combines all the individual SRF parameter types under one single data structure. This new data type is used as an input parameter to the SRF creation functions. The new SRF parameter type is as follows:
typedef struct { SRM_SRF_Parameters_Info_Code srf_params_info_code; SRM_RT_Code rt_code; union _SRM_SRF_Parameters_Info_Union { SRM_SRFT_Parameters srf_template; SRM_SRFS_Info srf_set; SRM_SRF_Code srf_instance; } value; } SRM_SRF_Parameters_Info; typedef struct { SRM_SRFT_Code template_code; SRM_ORM_Code orm_code; union _SRM_SRFT_Parameters_Union { SRM_Unused cc_srf_parameters; SRM_LSR_3D_Parameters lsr_3d_srf_parameters; SRM_Unused cd_srf_parameters; SRM_Unused pd_srf_parameters; SRM_LTSE_Parameters ltse_srf_parameters; SRM_Local_Tangent_Parameters ltsas_srf_parameters; SRM_Local_Tangent_Parameters ltsc_srf_parameters; SRM_LCE_3D_Parameters lce_3d_srf_parameters; SRM_Unused cm_srf_parameters; SRM_Unused ei_srf_parameters; SRM_Unused sec_srf_parameters; SRM_Unused seq_srf_parameters; SRM_Unused sme_srf_parameters; SRM_Unused smd_srf_parameters; SRM_Unused haec_srf_parameters; SRM_Unused heec_srf_parameters; SRM_Unused heeq_srf_parameters; SRM_M_Parameters m_srf_parameters; SRM_Oblique_Mercator_Parameters oms_srf_parameters; SRM_TM_Parameters tm_srf_parameters; SRM_LCC_Parameters lcc_srf_parameters; SRM_PS_Parameters ps_srf_parameters; SRM_EC_Parameters ec_srf_parameters; SRM_LSR_2D_Parameters lsr_2d_srf_parameters; SRM_Unused lsa_srf_parameters; SRM_Unused lsp_srf_parameters; } parameters; } SRM_SRFT_Parameters; typedef struct { SRM_ORM_Code orm_code; SRM_SRFS_Code_Info srfs_code_info; } SRM_SRFS_Info;- Three SRF template parameter types have their latitude parameter removed:
- For Polar Stereographic (PS) SRF:
In 4.0 typedef struct { SRM_Polar_Aspect polar_aspect; SRM_Long_Float origin_longitude; SRM_Long_Float true_scale_latitude; SRM_Long_Float true_scale; SRM_Long_Float false_easting; SRM_Long_Float false_northing; } SRM_PS_Parameters; In 4.1 typedef struct { SRM_Polar_Aspect polar_aspect; SRM_Long_Float origin_longitude; SRM_Long_Float central_scale; SRM_Long_Float false_easting; SRM_Long_Float false_northing; } SRM_PS_Parameters;- For Equidistant Cylindrical (EC) SRF:
In 4.0 typedef struct { SRM_Long_Float origin_longitude; SRM_Long_Float standard_latitude; SRM_Long_Float central_scale; SRM_Long_Float false_easting; SRM_Long_Float false_northing; } SRM_EC_Parameters; In 4.1 typedef struct { SRM_Long_Float origin_longitude; SRM_Long_Float central_scale; SRM_Long_Float false_easting; SRM_Long_Float false_northing; } SRM_EC_Parameters;- For Mercator (M) SRF:
In 4.0 typedef struct { SRM_Long_Float origin_longitude; SRM_Long_Float origin_latitude; SRM_Long_Float central_scale; SRM_Long_Float false_easting; SRM_Long_Float false_northing; } SRM_Mercator_Parameters; In 4.1 typedef struct { SRM_Long_Float origin_longitude; SRM_Long_Float central_scale; SRM_Long_Float false_easting; SRM_Long_Float false_northing; } SRM_M_Parameters;Return to: Top
This section summarizes the major changes to the Transmittal Access C API technology component.For detailed information on Transmittal Access C API changes see Migration Guide - Transmittal Access C API.
- The storage and retrieval of <Mesh Face Table> data is now performed with 2 new functions.
- Level 0 functions that previously took char * parameters now take SE_URN, SE_URL, or SE_String parameters as appropriate. This affects the functions for opening transmittals and those that manipulate object ID strings, among others. See the documentation of the individual functions for details of their parameter lists.
- Three new macros - SE_SetString(), SE_SetURL(), SE_SetURN() - have been added that populate variables of these types given a character string input. SE_SetString() also has a macro, SE_SetStringWithDefaultLocale().
- Three new macros - SE_GetStringAsCharString(), SE_GetURLAsCharString(), SE_GetURNAsCharString() - have been added that return the characters portion of each of these; they may simplify migration tasks where the user wishes to avoid rewriting print statements.
This section summarizes the major changes to the Transmittal Access C++ API technology component.
- STF changes to align with SEDRIS ISO Part 3.
|