E57 translation means making 3D scanning records understandable in another language without changing their measured points, scan poses, image associations or technical provenance. ASTM E57 is a structured exchange format for laser scans and related three-dimensional imaging data, combining descriptive XML information with binary point data and optional images. The purpose of a trustworthy language edition is not to produce a different scan: it is to help new readers understand the same captured scene and its limitations.
If you need to translate an E57 point-cloud file, localize E57 scan names or descriptions, preserve Cartesian and spherical coordinates, inspect scan GUIDs, maintain pose and coordinate metadata, or validate E57 images2D and data3D records, the key is to work with format-aware tools. Human descriptions and approved labels may change. Binary headers, numerical observations, coordinate transformations, validity flags, structured field names and image links need strict protection. A literal text substitution is not a safe engineering workflow.
This article serves surveyors, architects, civil engineers, cultural-heritage specialists, construction teams, reality-capture technicians, records managers, translators and international researchers. It concentrates on the E57 scan package, not on the separate LAS 1.4 LiDAR point-record format or a generic geographic information system. It explains how to read the data model, draw the boundary between translation and measurement, validate exports and communicate uncertainty in a clear, practical way.
ASTM E57 is a 3D imaging exchange format, not a page of text
The E57 format can store measured three-dimensional points, associated attributes and two-dimensional imagery in a structured exchange file. Natural-language metadata is a small part of that evidence.
Example in practice: A heritage team transfers terrestrial scanner data to a foreign conservation consultant. The receiving team needs readable scan descriptions but exactly the same measured interior geometry.
Common failure: Translating words without a data boundary can change scan identity, coordinate meaning or measurement validity. A seemingly successful import may hide those differences.
What to check: Preserve a source copy, identify human-readable fields separately and require point-level and scan-level acceptance tests after approved language edits.
Identify the current standard and actual file profile
ASTM E2807 defines the E57 3D imaging exchange format. It is important to distinguish a standard reapproval from an entirely new file-format revision.
Example in practice: A project refers to E2807-11 reapproved in 2026 while a client calls it E57 Version 1.0. These references do not automatically imply incompatible binary layouts.
Common failure: A translator might mistake a year appearing on a standard’s publication record for an instruction to rewrite file headers or increment the E57 major version.
What to check: Record the declared E57 file version, exporter and relevant ASTM edition, then use a compatible library to validate the file without fabricating migration.
Recognize the file header as structural data
The file begins with a binary header that includes a signature, version and offsets for locating its XML and associated data. The header is not editable prose.
Example in practice: An editor sees the signature ASTM-E57 and a few readable bytes while examining a scan file. Those bytes tell software how to find the rest of the document.
Common failure: Changing a header value because it resembles an English phrase can make the entire file unreadable. Text editors are not safe tools for rewriting E57 binary packages.
What to check: Check file integrity with an E57-aware parser and compare the file’s declared sizes, offsets and version values after any approved export.
Understand the XML and binary combination
E57 contains a structured XML description together with binary data storage for compressed point vectors or image blobs. The two parts are linked through format-specific references.
Example in practice: A scan name appears in XML metadata while millions of points live in binary sections. The title can be localized through a compliant writer; the measurements remain untouched.
Common failure: Editing XML bytes in place without updating physical offsets, lengths or checksums can corrupt the surrounding binary container.
What to check: Use a standards-aware reader and writer and re-open the resulting file. Compare technical values as data, not as raw text snippets.
Respect page checksums and storage layout
E57 uses a page-based integrity structure, including checksums, to protect its stored content. File offsets and physical pages have specific meanings.
Example in practice: A localization team adds a longer UTF-8 description. A compatible writer handles new allocation; a hand edit of the binary file cannot safely assume equal byte lengths.
Common failure: An output can look intact until a library checks a later page’s checksum. Replacing text in a hex editor is not a dependable localization workflow.
What to check: Run integrity verification across the entire E57 package and verify both metadata and point records can be read successfully.
Distinguish root data3D and images2D
The E57 root can include data3D scan records and images2D records for associated imagery. These collections have different roles and relationships.
Example in practice: A construction survey contains ten laser scans and two panoramas. Translating an image description must not make the panorama appear to be an additional point-cloud scan.
Common failure: Dropping images2D or duplicating data3D entries while processing captions changes the evidentiary package, even when the visible point cloud still opens.
What to check: Compare counts and identifiers in both collections, then test that each image remains attached to the intended scan.
Keep scan GUIDs stable
A GUID identifies a scan or related image record. This identifier connects data across tools and is different from the scan’s human-readable name.
Example in practice: An engineer knows a scan as West Staircase, while the archive tracks it by a GUID. Another language may show a different staircase label without creating a new scan identity.
Common failure: Replacing GUIDs with translated titles or regenerating them during every export can make cross-references, duplicates and audit histories unreliable.
What to check: Compare each record’s GUID exactly and inspect references from images or adjacent records that identify the original scan.
Translate scan names with context
A scan name can refer to a room, scanner station, survey position, date or project convention. Translating it requires understanding which part is descriptive and which part is a controlled code.
Example in practice: A scan called LEVEL-B2_STATION-04_North Wall combines a structural identifier and a human orientation note. A language edition might display the note separately while protecting the code.
Common failure: A literal translation that changes the station ID can break a shared survey index. Translating North without project context might imply a different physical side.
What to check: Use a controlled naming glossary and keep stable scan IDs. Check translated descriptors against survey plans and known stations.
Distinguish descriptions from machine fields
E57 metadata may include human-readable name and description, alongside structural fields such as pose, points, bounds and sensor identification.
Example in practice: A conservation report wants a clearer description of a vaulted ceiling. The description can improve in another language while the recorded points and scan pose remain measured evidence.
Common failure: A string-replacement script that touches every readable XML element may corrupt type names or link references necessary for parsing.
What to check: Allowlist language fields by their documented data roles, and compare all other node names and values after writing.
Preserve point coordinates and their declared units
Cartesian point coordinates represent measured positions, ordinarily expressed in meters under the E57 conventions. These numeric triples are not captions to adapt culturally.
Example in practice: A tunnel scan has a point at a measured X, Y and Z location. A Spanish label for the tunnel entrance does not justify changing any component of that triple.
Common failure: Converting coordinate values into locale-formatted strings or rounding them without surveying rules can displace features in engineering models.
What to check: Compare point count, coordinate ranges and selected full-precision samples. Use spatial control to verify reconstructed geometry.
Understand Cartesian versus spherical records
E57 can carry Cartesian coordinates or spherical range and angular components, depending on the data produced and the representation encoded in the scan.
Example in practice: A terrestrial scanner records range, azimuth and elevation and an importer derives XYZ positions. The two representations are connected by geometry, not a translation convention.
Common failure: Changing the meaning of an angular field or assuming it is measured in degrees when the format uses radians can rotate or distort the reconstructed scene.
What to check: Confirm which coordinate fields are present, how they are interpreted and whether reconstructed points agree with the known scanner geometry.
Do not alter spherical angle conventions
Spherical range, azimuth and elevation encode physical observations in the scanner frame. They are mathematical quantities and should never be translated as descriptive headings in the file.
Example in practice: A multilingual manual explains azimuth in plain language while the raw records keep the same radian values. The explanation helps users without touching observations.
Common failure: A localized import routine that changes angle values on the assumption that readers prefer degrees can move every point before global registration is applied.
What to check: Reconstruct a handful of points from spherical fields and compare them to the source-coordinate interpretation.
Protect rigid-body scan poses
A scan pose connects a scanner’s local coordinate system to the file-level coordinate system using translation and rotation. It may use quaternion components.
Example in practice: Two scanning stations observe the same wall from opposite sides. Their poses align both observations. A language change to station notes should not affect their relative alignment.
Common failure: Swapping quaternion components or translating the data field named translation as if it were a note can break registration and make walls appear doubled.
What to check: Compare pose values and verify overlapping scan targets still align after export and import.
Treat coordinate metadata as an engineering declaration
Coordinate metadata can record information about the spatial reference system, often using WKT or equivalent technical notation. It is not a free-form place description.
Example in practice: A survey uses a national projected CRS. A foreign team needs to understand the projection, but the numeric survey points should not be relabeled as geographic latitude and longitude.
Common failure: An attractive translated CRS name cannot replace its formal definition. A false label causes false confidence in the placement of scanned assets.
What to check: Keep the authoritative coordinate reference description intact and independently verify location through known survey control points.
Separate scanner-local coordinates from world coordinates
The same point can be represented in a scanner frame and a project coordinate frame through a pose transformation. These frames must not be confused.
Example in practice: A doorway is a few meters from one scanner but thousands of meters in a regional project system. The two positions are different expressions of the same observation.
Common failure: A localization project that rewrites a point caption without documenting the frame may imply an impossible physical displacement or wrong elevation.
What to check: State the frame used by any displayed coordinates and test both local and project reconstruction for a known target.
Respect scan point counts
Each scan’s count establishes how many point records and associated attributes are expected. It is an integrity signal and not a prose statistic to embellish.
Example in practice: A scan contains 12 million points. A target-language note can say approximately twelve million, but the underlying count must still match the actual records.
Common failure: A rewritten summary that confuses sampled display points with the full exported dataset can mislead survey users about density or completeness.
What to check: Compare decoded point counts per scan, including any invalid points and exporter-specific filtering rules.
Read CompressedVector correctly
Point data is represented in a structured compressed vector with a declared prototype. The prototype defines fields and value types for the point records.
Example in practice: A scan prototype contains cartesianX, cartesianY, cartesianZ and intensity. A translator should not turn field identifiers into other-language labels inside the encoded vector.
Common failure: Altering prototype field names or numeric storage declarations can make the data unreadable or change which values applications interpret as measurements.
What to check: Verify the prototype, field types and decoded sample values with a compatible library before and after the language edition.
Preserve scaled integers and floating-point precision
Point fields may use floating-point or scaled-integer representations. The chosen encoding affects precision and reconstruction and must not be changed incidentally.
Example in practice: A high-precision factory scan uses scaled integers to store positions efficiently. Translating its descriptive notes does not authorize re-quantizing measurement values.
Common failure: An exporter that silently converts double precision to single precision may lose detail even if every word is correct. Large coordinate offsets magnify such issues.
What to check: Compare data types, scales, offsets and numerical error budgets. Flag precision changes as technical conversions requiring approval.
Honor Cartesian invalid-state fields
An invalid-state field can identify points whose Cartesian representation should not be treated as ordinary valid observations. These flags are measurement qualifiers.
Example in practice: A scan includes returns marked invalid because the device could not establish a trustworthy position. A viewer that filters such records may show fewer points than the raw record count.
Common failure: Dropping invalid-state flags in a supposedly linguistic export can turn uncertain measurements into apparently valid geometry or change the visible cloud.
What to check: Compare flags and valid-point counts separately from total record counts. Verify importer filtering behavior is documented.
Honor spherical invalid-state fields
Spherical records can also mark measurements as invalid or unusable. The state value is not equivalent to a descriptive note about visibility.
Example in practice: A scanner emits a range value but marks it unreliable. The translated survey summary should not infer a confirmed surface where the sensor did not establish one.
Common failure: Omitting the uncertainty state can introduce phantom walls or false coverage in reconstructed point-cloud views.
What to check: Check state distributions and source-to-target behavior for invalid spherical points, especially when converting them to Cartesian positions.
Preserve point intensity as measured evidence
Intensity represents returned signal strength under instrument and processing conventions. It is not generally an ordinary language value or universal reflectance.
Example in practice: A concrete wall and a dark-painted beam differ in intensity. A multilingual report may explain contrast but should not translate or re-scale the raw intensity values.
Common failure: Treating intensity as a normalized brightness percentage without checking source limits and calibration can misrepresent material or surface properties.
What to check: Preserve numeric intensity fields and declared limits. Describe their interpretation only within the documented scanner and processing context.
Respect intensityLimits and display ranges
An E57 scan may declare limits for intensity, helping readers interpret its values. Display normalization should be separated from the recorded measurement.
Example in practice: One scanner writes values across a different range from another scanner. A common grayscale visualization can be useful, but it is an application transform.
Common failure: Changing the stored limits merely to make two screenshots match conceals genuine acquisition differences and may alter downstream analyses.
What to check: Compare declared limits and source distributions. Report any visualization normalization explicitly and never confuse it with a revised measurement.
Preserve RGB color channels and their limits
E57 can store per-point red, green and blue attributes, with ranges declared by the encoding. These attributes are data, even if they appear decorative.
Example in practice: A heritage survey records the visible colors of a painted wall. Translating a caption does not give permission to recolor the points or change channel ranges.
Common failure: Assuming every E57 file uses identical color bit depth or replacing channels to make a new language banner visible can distort the archived appearance.
What to check: Verify channel datatypes, limits and representative colors after decoding. Localize explanatory overlays separately from color measurements.
Preserve color-invalid markers
Some point records declare whether color attributes are reliable. The flag protects users against assuming every point has a valid associated color.
Example in practice: A scan combines geometric points with photography available only in some directions. Points without color should remain explicitly distinguishable from black-colored surfaces.
Common failure: Converting missing color to an ordinary RGB triplet without retaining validity can make absence look like a measured dark surface.
What to check: Compare color validity and coverage. Display missing color with an appropriate viewer convention that does not misstate source observations.
Protect row and column scan indexes
Structured scans can include rowIndex and columnIndex fields describing how observations map onto a scan grid or image-like acquisition pattern.
Example in practice: A stationary laser scanner records a structured panorama. Row and column coordinates help link scans and visual representations; they are not labels for a spreadsheet translation.
Common failure: Reversing rows or reassigning columns for reading direction can make points connect to the wrong panorama positions.
What to check: Compare grid dimensions and selected indexed points. Verify panoramic colorization and scan-grid consistency in the target application.
Respect return information and grouping schemes
Some scan records include returnIndex, returnCount or grouping information. They describe observations and how measurements are grouped, not narrative text.
Example in practice: A pulse generates multiple returns from a partially transparent scene. A translated description can explain the sensor behavior while maintaining return identities.
Common failure: Dropping return data or redefining grouping intervals may mislead later processing of surfaces, vegetation or complex industrial scenes.
What to check: Compare return distributions and group references. Preserve any grouping schemes that the receiving survey workflow needs.
Preserve acquisition start and end timestamps
Scan metadata can include acquisitionStart and acquisitionEnd. These are evidence of when a measurement was made and may use GPS-related time conventions.
Example in practice: An archaeological scan documents a structure before restoration. A second-language report must preserve the acquisition interval so comparisons with later scans remain valid.
Common failure: Formatting a timestamp ambiguously or confusing GPS-based time with local civil time can change the stated chronology of a measured event.
What to check: Keep underlying timestamp values and declared interpretation stable. Format display dates separately, with the time basis explained where necessary.
Distinguish scan time from export time
A processing application may set metadata differently during export, and not every acquisition field should be treated as an immutable capture clock without checking provenance.
Example in practice: A scanner collected data on Monday, but the processing package was exported on Thursday. A multilingual archive should not silently call Thursday the scanning date.
Common failure: Overconfident wording can convert software export metadata into a false historical claim. Automated workflows need to track provenance rather than infer it from a field name alone.
What to check: Inspect source instrument records and exporter documentation. Label capture, registration, modification and export dates accurately.
Protect sensor manufacturer and model identity
Metadata can record sensor vendor, model, firmware and serial details. Proper nouns and controlled equipment identifiers serve provenance rather than literary expression.
Example in practice: A museum archive names the scanner model used in a survey. Translate an explanatory sentence about the equipment, but preserve its formal model and serial reference.
Common failure: Literal translation of a product model name can make it impossible for a recipient to trace calibration records or manufacturer documentation.
What to check: Check identifiers against the original acquisition report and retain the exact technical strings while providing understandable surrounding prose.
Keep calibration and environmental context
Where present, acquisition metadata may include temperature, humidity or other environmental values. They have units and uncertainty independent of language.
Example in practice: A factory scan captured under high temperature later supports an alignment assessment. The translated note should not convert that observation into a certainty about material movement.
Common failure: Altering units or dropping context can make later engineers overstate what the survey proves. Environmental numbers are not promotional descriptors.
What to check: Keep numeric readings, units, source and measurement time stable. Review translated explanations against the survey record rather than inventing physical interpretations.
Recognize images2D as associated imagery
The optional images2D structure can hold images and projection information, including panoramic or pinhole representations depending on acquisition and export.
Example in practice: A facade point cloud is linked to a panorama that helps inspectors interpret a crack. A localized caption can explain the view without rewriting image geometry.
Common failure: If the image link is lost, a future viewer may retain points but lose color context or the basis for identifying the crack.
What to check: Compare image counts, associations, relevant pose and image representations. Test image loading and scan overlay in a real target viewer.
Preserve associatedData3DGuid links
An image can refer to the scan it belongs to through an associated data GUID. The reference ties camera evidence to a particular point collection.
Example in practice: A warehouse scan has three panoramas that reference one station GUID. Translating file labels must not regenerate the scan identifier or detach those images.
Common failure: A photograph can become attached to the wrong scan, leading users to attribute damage or equipment to the wrong location.
What to check: Verify every image-to-scan reference resolves, and inspect corresponding content after export.
Understand image projection representations
A panorama, pinhole image and visual reference image do not necessarily follow the same camera model. Their metadata determines how imagery aligns with points.
Example in practice: A panoramic room image wraps across a sphere, while a perspective photograph follows a pinhole model. A language edition can label both appropriately.
Common failure: Calling a visual-reference photograph a metrically aligned panorama exaggerates what the source encodes. Altering a projection for presentation can destroy alignment.
What to check: Keep the declared projection model and inspect whether the chosen viewer actually supports it.
Do not move image camera poses
Images can carry poses that determine their spatial relationship with scans. These are part of the measurement or alignment evidence.
Example in practice: A visitor clicks a point-cloud marker to see a panorama from the scanner station. A translated control label must not change the image camera’s position.
Common failure: A changed image pose can make a photograph appear to document a different surface or viewing direction.
What to check: Compare image pose values and check known image-to-point correspondences in the receiving application.
Handle XML Unicode and escaping carefully
Human-readable E57 metadata can contain international scripts, but it must remain valid XML in the encoded package. Unicode handling differs from editing raw binary data.
Example in practice: A scan description includes accented names, a non-Latin location and a quoted room title. A compliant writer encodes those strings without damaging the XML structure.
Common failure: Unescaped ampersands, invalid byte substitutions or length-changing edits made outside an E57 writer can prevent the document from parsing.
What to check: Round-trip translated strings through a standards-aware library and verify they appear correctly in the intended software.
Keep technical XML node names unchanged
Node names such as data3D, points, pose and cartesianBounds are part of the E57 schema. Their English appearance does not make them editable labels.
Example in practice: An import interface may translate the term point cloud for users while still recognizing the file’s exact XML member names.
Common failure: Renaming cartesianX to a translated word changes the technical contract and stops tools from recognizing the measured coordinate field.
What to check: Use schema-aware field mapping rather than arbitrary find-and-replace. Compare standardized node names and required types.
Manage descriptions as evidence claims
A scan description can distinguish observed damage, suspected causes and later interpretation. Translation must preserve that evidential distinction.
Example in practice: A conservation survey states that a stain is visible but its source is unconfirmed. A translated summary should not assert water ingress as a proven diagnosis.
Common failure: Improving style by removing uncertainty can turn an observation into a definitive engineering or historical claim.
What to check: Have the domain reviewer distinguish observation, inference and decision and check each translated description against its source.
Respect survey confidentiality and security
Interior scans can reveal private rooms, access routes, sensitive facilities or people captured inadvertently in imagery. A new language can widen the audience.
Example in practice: A hospital facility scan includes restricted equipment areas. Translating its descriptions for a public portal does not authorize wider distribution of those measured images.
Common failure: Privacy risk may remain even when every point is technically correct. An accessible multilingual file can reveal details never intended for public release.
What to check: Review consent, asset ownership, location sensitivity and publication permissions before distributing a localized dataset.
Differentiate E57 from LAS and LAZ
E57 can preserve multiple scan stations, image associations, poses and broader 3D imaging metadata, while LAS is a distinct point-record exchange format with its own header and classification conventions.
Example in practice: A team must choose between passing raw terrestrial scan stations in E57 and exporting a flattened cloud as LAS. The formats support different workflow assumptions.
Common failure: Treating a conversion to LAS as a translation can silently discard scan poses, image links or per-station metadata.
What to check: Name any format conversion separately and document which source fields were preserved, transformed or lost.
Do not mistake clipping for successful localization
A viewer may show fewer points than the archive contains because of performance settings, invalid-point filtering, clipping or decimation.
Example in practice: A lightweight web preview displays half the points to save memory. A translation reviewer should not conclude that the source file lost half its measurements.
Common failure: Comparing only visible screenshots can confuse client rendering choices with changes in stored evidence.
What to check: Compare decoded record counts and raw file metrics, then inspect visual output with documented display settings.
Use an independent scan alignment control
Fixed physical targets and overlapping geometry make it possible to detect subtle registration shifts after import and export.
Example in practice: A building survey contains three well-measured control markers across two rooms. The localization release should reconstruct each marker in the same coordinates.
Common failure: A small pose error can remain hidden in a dense point cloud but change the apparent width of a doorway or stair.
What to check: Check control-point residuals and overlap alignment rather than relying solely on the impression that a cloud looks correct.
Create a traceable language field inventory
The safest localization workflow documents every string approved for change, its source scan GUID, context, target language and reviewer.
Example in practice: An international survey team translates human-readable station names, descriptions and public legends but protects numeric coordinates, GUIDs, sensor models and time evidence.
Common failure: Without a field inventory, later correction of a label can cause a fresh export that inadvertently changes measured data or scan associations.
What to check: Compare the accepted set of changed fields to the approved list and retain the original edition for audit.
Test with at least two E57 readers
E57 support varies between applications, including images, structured scans, unknown extensions and how invalid points are filtered. Cross-reader testing reveals assumptions.
Example in practice: An archive opens in one point-cloud package but another discards image associations. The language layer may be correct; the interoperability limit still matters to recipients.
Common failure: A successful export-import cycle with the same vendor tool can hide metadata loss because the importer and exporter share the same assumptions.
What to check: Use independent readers and report which fields were parsed, displayed and preserved. Do not claim full compatibility without testing.
Build a release receipt that distinguishes changes
A useful delivery record states the source file, standard profile, approved language changes, scan counts, point counts, GUID correspondence and validation outcomes.
Example in practice: A building authority issues an English and Indonesian description edition. The release receipt notes that descriptions changed, but scan coordinates and image links did not.
Common failure: A claim that an E57 file has been fully translated can conceal partial support, lost metadata or unresolved naming questions.
What to check: Publish a precise change summary, remaining limitations and contact for correcting labels without altering the underlying survey.
An eleven-step E57 localization and preservation procedure
Step 1. Collect the untouched E57 source, source checksum, acquisition records, software and version information, intended audience and the legal right to distribute the scan or its imagery. Translation begins with understanding the original evidence.
Step 2. Open the source with an E57-aware reader and inventory root metadata, the data3D scan collection, images2D attachments, scan GUIDs, poses, point counts, point-field prototypes and coordinate declarations.
Step 3. Create a baseline of engineering evidence. Record sample XYZ and spherical values, invalid-state distributions, scan and image counts, declared ranges, scan positions and known physical control targets.
Step 4. Approve a small list of language-editable fields. Separate scan names, human descriptions and viewer-only captions from formal node names, GUIDs, device identifiers, numeric data and spatial metadata.
Step 5. Build a terminology register for rooms, building parts, physical directions, damage descriptions and survey procedures. Determine when to keep official names, transliterate them or explain them in the destination language.
Step 6. Use a compatible E57 API to produce a test localized output. Never perform blind text replacement in the binary container or repair changed XML offsets by hand.
Step 7. Reopen the target file and check package integrity, header and XML parsing, scan counts, GUID correspondence, field datatypes, image associations, coordinate metadata and every required binary data record.
Step 8. Compare representative full-precision points, reconstructed poses and known control geometry. Measure any numeric differences and reject unexpected modifications to source observations.
Step 9. Review translated human claims with a reader who understands surveying, heritage documentation or the relevant engineering domain. Preserve observational uncertainty and time context.
Step 10. Import both editions into the receiving application. Test independent viewers when available and report any unsupported fields or differences in invalid-point filtering or imagery projection.
Step 11. Publish the language edition with an accurate manifest: source version, approved field paths, language reviewers, technical comparisons, known interoperability limits and any unresolved proper-name issues.
Frequently asked questions about E57 translation
Can E57 files contain both point clouds and photographs?
Yes. The standard supports three-dimensional point records and optional two-dimensional imagery. An E57 archive can contain multiple scans with associated images, including panoramas. Not every exporter populates every field and not every importer presents every supported feature. A language edition should inventory what is actually present rather than assuming that all possible standard fields appear in every file.
Can I translate the E57 field name cartesianX?
No. Standard node and field names are machine-readable syntax, not ordinary display language. A user manual or UI can explain that cartesianX is the first Cartesian coordinate component, but renaming the field in the package prevents compliant software from recognizing it correctly. Keep technical keys and their datatypes untouched.
Is a scan name the same as its GUID?
No. A scan name is usually a human-readable descriptor, while its GUID serves as a stable identity reference. A name may have an approved translation or transliteration. Replacing or regenerating GUIDs can damage associations with images, reports and other scans. The translation ledger should relate the display name to the original GUID.
What if two programs show different numbers of points?
They may apply different invalid-point filters, decimation or import settings. Inspect the raw decoded record count and compare it to the number of valid, displayed or filtered points. Do not conclude that a localization lost evidence solely from the point count visible on screen. Cross-reader documentation should describe the relevant differences.
Can I change meters to feet for an overseas recipient?
You can display an additional clearly labeled conversion in a translated report, but rewriting the stored E57 Cartesian measurements is a technical transformation. It changes data, potentially affects precision and must be carried out by qualified surveying software under a separate controlled workflow. Keep canonical units and measured coordinates stable through language localization.
What is the relationship between an image and a scan?
Associated images can refer to a scan through identifiers and include camera pose or projection metadata. This context helps software align the photograph with measured points. A caption translation must not detach the link or suggest that a visual-reference image has a different geometric status from what the file records.
Does a valid E57 import prove a correct translation?
No. A compatible parser can detect technical problems but cannot judge whether an engineering note preserves uncertainty or whether an official room name has been accurately rendered. Conversely, a fluent translated note does not demonstrate that poses, point coordinates and validity flags survived. Use technical and human review as separate acceptance tests.
Why not convert E57 to LAS during translation?
A format conversion may be appropriate for an engineering exchange, but it is different from translation. E57 can retain scan-station structure, imagery and pose relationships that are not identical to ordinary LAS point records. If conversion is requested, document retained, transformed and unsupported data. Do not hide information loss within a new-language delivery.
How should acquisition dates be presented?
Keep source timestamp evidence intact and distinguish scan capture time from processing or export time. Present dates in the reader’s preferred format only after confirming the time basis and zone assumptions. Avoid ambiguous numeric formats and identify missing or uncertain timestamps instead of inferring them.
What should an E57 release receipt contain?
The source checksum and format profile, approved textual changes, scan counts, GUID consistency, coordinate and pose comparisons, image links, point-field and invalid-state checks, target reader tests, proper-name review and any remaining limitations. This helps another recipient verify that accessibility improved without measured geometry being altered.
Conclusion: better words, identical measured points
Professional E57 localization protects the survey while improving its explanation. Use approved translations for names and descriptions, but retain scan identities, measured coordinates, poses, point attributes, image relationships, validity states and formal metadata. A survey is evidence; language access should help people interpret that evidence without changing it. Test the whole data package, review uncertainty honestly and keep a clear receipt for every language edition.
Reference standards and further reading
ASTM E2807 3D Imaging Data Exchange specification; Library of Congress: E57 format description; libE57Format documentation; Companion: LAS 1.4 LiDAR point records.