This document lists the bug fixes and known defects/limitations contained in this release.
For general information about this release, where to obtain it, and items that require specific attention, see the Release Notes.
For help, comments, and bug reports please send email to help@sedris.org. If you are an associate, please use se-coders@sedris.org.
Return to: Top
- The SE_CloneString() and EDCS_CloneString() functions fail to copy the "locale" field of the SE_String/EDCS_String when the string is the empty string.
- The SE_CompareStrings() and EDCS_CompareString() functions run into an infinity loop when comparing two identical strings.
- The 4x4 matrix in SE_SetRotateMatrix4x4() function produce wrong results because it is not initialized.
- The SE_GetImageData() function fails if called shortly after an Image has been created/modified.
- The SE_GetRearrangedImageData() function returns image upside-down or with texels shifted in unexpected directions (side-to-side, etc). This happens when the image scan direction is set to SE_IMG_SCAN_DIR_RIGHT_DOWN while the scanned image was originally stored with a scan direction of SE_IMG_SCAN_DIR_RIGHT_UP.
- The SE_GetElementOfDataTable() function crashes because of the misuse of Stores.
- The SE_CloseTransmittal() function crashes when processing inheritance.
- When using search bounds on geodetic coordinates, false is returned even for objects which are inside the bounds.
- Unable to compare the value of a SEDRIS Field against its default value because the the default value is not completely initialized.
- Possible safety issues when using zlib version 1.1.3. Need to upgrade it to version 1.1.4.
- No vertical and horizontal datum shift support for SRM conversions (see remaining limitations below).
- The Depth application does not include association link objects in its object counts.
Return to: Top
- Library linking problem due to missing exported symbols.
- Malformed macro definitions for SE_ClassCount() and SE_TypeCount() functions.
- Bug in label search EDCS_LabelToEECode() and EDCS_LabelToEGCode() functions.
- Infinite loop condition in DCS_CompareString() and SE_CompareString() functions.
- Bug in Rules Checker when using global SE_Store.
- Limitation on the STF file name length to be less than 256.
- The content of the return 4x4 matrix is not initialized in SE_SetRotateMatrix4x4().
- In SRM_Matrix3x3Multiply() and SRM_Matrix4x4Multiply(), the result of the operation is incorrect when one of the input matrices memory space is the same as the output matrix.
- Depth -vv option not printing out the data table values for data tables with only 1 axis and only 1 table property description.
- SE_HasComponents() returning "false" even when there is a component of the given type present.
- SE_RemoveFromTransmittal() core dumps when removing a SE_DRM_CLS_IMAGE object.
- Fixed the DRM diagrams and general documentation.
- SE_GetComponent( ) function returning a component object after it has been removed from the aggregate.
- SE_HasComponent( ) function not behaving correctly when the "process inheritance" or "directly attached tables component" arguments are set to true.
- SE_GetReferencedTransmittalList( ) function not working properly and may crash the software.
- SE_GetPublishedLabels( ) function to just return the label(s) under which the object is published and to allow an object to be published multiple times.
- Rules Checker not being able to process <Base Perimeter Data>, <Base Time Data> and <Separating Planes> classes.
- Using SE_OpenTransmittalByFile function opening a transmittal in update mode multiple times causes user editing changes to be lost.
- Microsoft compiler unable to handle the fields in <Base Reference Vector> correctly due to its particular type casting mechanism.
- Search bounds not crossing ITR boundaries to retrieve objects.
- In processing large transmittals, i.e. the ones that have large amount of relationships among objects, internal block caching was not processed properly and consequently causing excessive memory allocation and slow down in execution.
- SE_GetNumberOfPathsToTransmittalRoot( ) function incorrectly calculating the value for <Feature Node> instances bound to looped <Feature Edge> instances.
- Search filtering using the SE_COMPONENT_TYPE_MATCH search rule incorrectly returning zero results.
- Unable to retrieve <Data Table> data when <Data Table> has a set of identical elements.
- SE_ResolveTransmittalName( ) function incorrectly using an SE_Store, causing invalid names to be returned on subsequent calls.
- SE_RemoveComponentRelationship( ) function failing to remove relationships with link objects.
- Default options for the depth application were set incorrectly to true for the "process inheritance" and "directly attach table components" parameters.
- Altitude conversions incorrectly calculated for Geodetic (GD) SRF.
- GD <=> UTM conversions returning improper extended range warnings and incorrect longitudes.
- Problem with LTP conversions producing wrong results due to sine/cosine mix up.
Return to: Top
- The following SRM functions are not implemented:
- SRM_ChangeCoordinateSRFUnvalidated()
- SRM_ChangeCoordinateArraySRFUnvalidated()
- SRM_ConvertMatrix3x3()
- SRM_LocalTransformation()
- SRM Horizontal Datum Shift Operations are not possible on GC coordinates due to the lack of a horizontal datum specifier in the API for GC coordinates. This will be adressed by API changes taking place in next major SRM release.
- SRM Conversions between GC as source SRF and an SRF with a horizontal datum as target will use the horizontal datum specified in the target . Conversions between an SRF with a horizontal datum as source and GC as target will assume the destination horizontal datum. This may cause paradoxical results when horizontal datums other than SRM_HDATUM_WGS_1984 are used with GC in conversions.
- SRM Vertical Datum is ignored for LTP SRF's. All LTP coordinates are treated as being based on the ellipsoid specified by the horizontal datum. This interpretation matches the definition of LTP to be used in future releases. Paradoxical results may ensue for LTP operations in which both SRF's involved do not use SRM_VDATUM_WGS84E and SRM_HDATUM_WGS_1984.
- SRM LSR_3D Reflexive conversions are not possible for all axis orientations.
- The following SRM vertical datum and horizontal datum pairings are the only legal pairings in this release:
- SRM_VDATUM_MSL SRM_VDATUM_WGS84G are legal with any non-spherical horizontal datum.
- SRM_VDATUM_WGS84E is legal with SRM_HDATUM_WGS_1984.
- SRM_VDATUM_SPHERICAL_ACM is legal with SRM_HDATUM_SPHERICAL_ACM.
- SRM_VDATUM_SPHERICAL_COA is legal with SRM_HDATUM_SPHERICAL_COA
- SRM_VDATUM_SPHERICAL_NOG is legal with SRM_HDATUM_SPHERICAL_NOG
- SRM_VDATUM_SPHERICAL_MFE is legal with SRM_HDATUM_SPHERICAL_MFE
- SRM_VDATUM_SPHERICAL_MOD_M is legal with SRM_HDATUM_SPHERICAL_MOD_M
- SRM_VDATUM_SPHERICAL_MOD_S is legal with SRM_HDATUM_SPHERICAL_MOD_S
- SRM_VDATUM_SPHERICAL_MOD_T is legal with SRM_HDATUM_SPHERICAL_MOD_T
- SRM_VDATUM_SPHERICAL_MM5 is legal with SRM_HDATUM_SPHERICAL_MM5
- The following SRM vertical datums are unimplemented and thus not presently valid with any horizontal datum.
- SRM_VDATUM_EGM96
- SRM_VDATUM_NAVD88
- SRM_VDATUM_NGVD29
- The equivalence of the SRM vertical datums SRM_VDATUM_MSL and SRM_VDATUM_WGS84G is assumed by the software. In actuality they are not quite equivalent. A Rough Order of Magnitude estimate of the variation is +-2m in North America. Most other areas have limited data available for reliable comparison to the WGS84 Geoid.
- The GC to LTP vector conversion doesn't work properly.
- The SE_GetErrorDescription( ) function is not fully implemented and it will, in most cases, return a null pointer (no error message).
- Once a GMI is placed in an environment with a specific SRF (the SRF of the <Environment Root> object), then it can no longer be con sumed to a different SRF using the automatic conversion. If another SRF is needed for those objects, first the users have to ex tract the objects in their "native" SRF and then perform necessary conversions.
- The Rules checker incorrectly checks that <Axis> objects with the GCS SRF have angular coordinates instead of linear coordinates.
- The Rules Checker application in this release does not check all the DRM Constraints. Please read the Checker User's Guide for the list of constraints checked in this release. This application will be extended in subsequent releases to cover the remaining constraints.
- The read API's inheritance mechanism for <Colors> and <Rendering Properties> is incomplete. If an inherited <Color> or <Rendering Properties> object conflicts with a more "recent" object, the conflicting inherited object is completely overridden, rather than being deconflicted if possible. Consequently, the inherited information may be incomplete for these cases.
- The SE_EXACT_SEARCH option for search bounds is not implemented.
- An LSR <Model> can only be instanced into the following types of spatial reference frames:
- geodetic (2D or 3D),
- any projected spatial reference frame, e.g. Mercator,
- any augmented projected spatial reference frame, e.g. Augmented Mercator (3D),
- compatible LSR spatial reference frames
- The model_viewer application processes only polygonal <Primitive Geometry>; other primitives, e.g. <Lines> and <Points>, are currently ignored. Hence, a <Model> containing only a <Feature Model> without a <Geometry Model> will not be processed.
Return to: Top
Copyright © 2003 SEDRIS™