Part 3: Core Concepts
Quick Field Guide
Understanding Accuracy Specifications
RMSE (Root Mean Square Error):
- 3cm RMSE = ~68% of points within 3cm of true position
- ~95% of points within 6cm (2× RMSE)
- ~99.7% of points within 9cm (3× RMSE)
- Only achievable with proper workflow (RTK/GCP + correct technique)
L2 Pro:
- Relative: 1cm RMSE within 100m
- Absolute: 3-5cm horizontal, 5-10cm vertical (with RTK/PPK)
- With GCP: Can achieve 1-2cm RMSE
K1:
- Relative: 1cm RMSE within 50m
- Absolute: Same as L2 Pro (with proper georeferencing)
Relative vs. Absolute Accuracy
Relative Accuracy:
- Measures spatial relationships within a single scan
- "Are two points that are 10m apart measured as 10m apart?"
- Excellent for: As-built docs, volume calculations, dimensional verification
- Internal accuracy preserved regardless of georeferencing
Absolute Accuracy:
- Measures position in global coordinate system (WGS84, State Plane, UTM)
- "Where exactly is this scan located on Earth?"
- Required for: GIS integration, combining multiple scans, change monitoring
Learn more about accuracy types →
Local vs. Absolute Coordinates
Local Coordinate System (No RTK/GCP):
- Origin = (0, 0, 0) at initialization position
- Perfect for: Single-session projects needing only internal dimensions
- Cannot: Combine scans from different sessions or integrate with GIS
Absolute Coordinate System (With RTK/GCP):
- Coordinates reference established global/regional system
- Enables: Multi-session combination, GIS integration, change monitoring
- Requires: RTK/PPK positioning OR ground control points
Learn more about coordinate systems →
Three Paths to Absolute Coordinates
1. Real-Time Kinematic (RTK)
- Method: GNSS corrections streamed during scanning via NTRIP
- Accuracy: 3-5cm horizontal, 5-10cm vertical
- Best For: Large outdoor sites with good satellite visibility
- Limitations: Requires cellular connection
- Max Gap: <100m data-preserve-html-node="true" without RTK (L2 Pro), <50m data-preserve-html-node="true" (K1)
2. Post-Processed Kinematic (PPK)
- Method: Base station data merged with scan data after collection
- Accuracy: 3-5cm horizontal, 5-10cm vertical
- Best For: Areas with poor cellular or RTK unavailable during scan
- Requires: Base station observation files (RINEX format)
3. Ground Control Points (GCP)
- Method: Survey precise control points, mark during scanning
- Accuracy: 1-2cm RMSE (with proper surveying and distribution)
- Best For: Highest accuracy needs, indoor projects, RTK-challenged areas
- Requirements:
- Control point spacing: <100m data-preserve-html-node="true" (L2 Pro), <50m data-preserve-html-node="true" (K1)
- Minimum 3 points (4+ recommended)
- Survey accuracy ≤1cm
Learn more about georeferencing methods →
Coordinate System Types Quick Reference
Global Systems:
- WGS84: Latitude/Longitude/Height (GPS native)
- Angular measurements complicate distance calculations
- Ellipsoidal height ≠ elevation above sea level
Projected Systems:
- State Plane (US): Region-specific, optimized per state
- UTM: 6° longitude zones worldwide
- Linear units (meters/feet) suitable for engineering
- EPSG Codes: Standardized identifiers (e.g., EPSG:2263)
Datum Types:
- WGS84: GPS satellite reference
- NAD83: North American standard
- ITRF: Global high-precision reference
- Different datums = same point has different coordinates (0.5-2m difference)
Learn more about coordinate systems →
Height/Elevation Types
Ellipsoidal Height:
- Height above mathematical ellipsoid (WGS84 reference surface)
- RTK provides ellipsoidal heights by default
- Does NOT match "height above sea level"
Orthometric Height:
- Height above geoid (mean sea level)
- What people mean by "elevation"
- Requires geoid model to convert from ellipsoidal
- Common US models: GEOID18, GEOID12B
Conversion:
- Orthometric Height = Ellipsoidal Height - Geoid Separation
- Geoid separation varies by location (typically -50m to +50m)
- Must apply correct geoid model for accurate elevations
Learn more about height systems →
Coordinate Configuration Workflow
Before Scanning:
Identify required coordinate system
- Check project specs or client requirements
- Get EPSG code if possible
Determine RTK source coordinates
- Contact RTK provider for their output system
- Most output WGS84 (EPSG:4326 or EPSG:4978)
Configure RTK in LixelGO
- Navigate to RTK Settings
- Set Source Ellipsoid to match provider (usually WGS84)
- Enter NTRIP credentials (host, port, username, password)
- Test connection before leaving for field
After Scanning:
Configure in LixelStudio
- Open Project Processing → Coordinate Transformation
- Select GNSS (RTK) or GCP method
- Configure Source Coordinate (match RTK provider)
- Configure Target Coordinate (use EPSG code search)
Configure Datum Transformation
- Use standard parameters for WGS84 → NAD83
- Or calculate from control points if available
Configure Geoid Model (if needed)
- Download GEOID18 (US) or appropriate regional model
- Import into LixelStudio
- Set interpolation to Bilinear
Verify Results
- Use check points to confirm accuracy
- Measure known distances for verification
Learn more about configuration →
Common US Coordinate Systems (EPSG Codes)
New York City:
- EPSG:2263 - NAD83 NY Long Island (US Survey Feet)
Los Angeles:
- EPSG:2229 - NAD83 CA Zone 5 (US Survey Feet)
- EPSG:26945 - NAD83 CA Zone 5 (Meters)
Chicago:
- EPSG:3435 - NAD83 IL East (US Survey Feet)
- EPSG:26971 - NAD83 IL East (Meters)
Phoenix:
- EPSG:2223 - NAD83 AZ Central (US Survey Feet)
- EPSG:26949 - NAD83 AZ Central (Meters)
Salt Lake City:
- EPSG:32143 - NAD83 UT Central (US Survey Feet)
- EPSG:6620 - NAD83(2011) UT Central
Learn more about regional systems →
Common Configuration Mistakes
- ❌ RTK source ellipsoid doesn't match provider output
- ❌ Using wrong EPSG code (meters vs feet)
- ❌ Missing datum transformation parameters
- ❌ Forgetting geoid model for orthometric heights
- ❌ Control point spacing too wide (>100m)
- ❌ Control point names don't match coordinate file exactly
Getting Help
Resources:
- epsg.io - Search coordinate systems and EPSG codes
- geodesy.noaa.gov - Download geoid models (GEOID18)
- Contact RTK provider for their output coordinate system
- Consult local surveyor for regional standards
- Contact XGRIDS support with specific project details
Full Explanatory Guide
Understanding Accuracy
Accuracy specifications describe how closely measurements match true values. The Lixel system uses RMSE (Root Mean Square Error) to quantify accuracy, which requires explanation because RMSE differs from maximum error or tolerance band concepts familiar to many users.
RMSE Explained
RMSE represents the standard deviation of measurement errors under the assumption that errors follow a normal distribution. For a specification of 3cm RMSE, approximately 68% of points fall within 3cm of their true position (1 standard deviation), approximately 95% fall within 6cm (2 standard deviations), and approximately 99.7% fall within 9cm (3 standard deviations).
This statistical description means that some points will exceed the stated RMSE value. A system with 3cm RMSE will produce some points with errors of 4cm, 5cm, or occasionally larger. This is normal behavior, not a failure of the system. RMSE describes average performance across the entire dataset rather than guaranteeing all points meet a specific threshold.
The 3cm RMSE specification for the Lixel L2 Pro applies only when proper workflow is followed. This includes using RTK or properly distributed control points for absolute positioning, following correct scanning technique (stable initialization, smooth movement, loop closure), maintaining RTK fix or staying within control point spacing limits, and processing with appropriate settings for project requirements.
Scans performed without georeferencing achieve excellent relative accuracy (1cm RMSE within the scanned area) but have no absolute accuracy specification because their position relative to any global coordinate system is undefined.
Factors Affecting Accuracy
Multiple factors influence the achieved accuracy of a scan session. Understanding these factors helps users optimize workflow to achieve specifications.
Initialization quality establishes the reference frame for all subsequent measurements. Poor initialization (unstable surface, feature-poor environment, movement during countdown) introduces systematic errors throughout the scan. These errors cannot be fully corrected in processing. Initialization should receive careful attention as the foundation for accuracy.
SLAM tracking quality depends on feature availability and movement technique. Feature-poor environments (empty warehouses, blank corridors, parking lots) provide fewer constraints for SLAM optimization. Rapid movements or violent rotations exceed sensor measurement ranges and introduce gaps in trajectory estimation. Slow, smooth movements in feature-rich environments optimize SLAM performance.
RTK fix quality directly impacts absolute accuracy when using RTK georeferencing. Continuous fixed RTK (green indicator light) provides the specified 3-5cm horizontal accuracy. Float RTK (blue indicator) degrades to 10-20cm accuracy. No RTK (red indicator) forces the system to rely on SLAM dead reckoning, which drifts at approximately 0.5-1% of distance traveled. Sections exceeding 100 meters without RTK fix should be avoided or rescanned when satellite visibility improves.
Control point distribution affects GCP-based georeferencing quality. Control points should surround the scan area in three dimensions rather than forming linear or planar arrangements. Spacing between points should remain under 100 meters (L2 Pro) or 50 meters (K1). Points distributed at these intervals constrain SLAM drift and enable the transformation algorithm to achieve the specified 1-2cm RMSE. Wider spacing allows drift to accumulate between constraints, degrading accuracy.
Control point marking precision impacts the achievable accuracy when using GCP workflow. The control point base should align precisely with the surveyed marker. The scanner should remain perfectly stable during the 5-second marking interval. Movement or misalignment introduces errors that propagate into the coordinate transformation. Careful marking technique enables achievement of 1-2cm RMSE. Sloppy marking degrades results to 5-10cm or worse.
Environmental conditions affect measurement quality. Direct sunlight on the LiDAR receiver can increase noise in range measurements. Rain interferes with laser pulses and reduces maximum range. Temperature extremes affect IMU calibration and battery performance. Scanning in optimal conditions (overcast skies, moderate temperature, dry weather) produces best results. When environmental conditions are poor, consider reducing walking speed and increasing scan overlap to compensate.
Relative Versus Absolute Accuracy
Users frequently confuse relative accuracy and absolute accuracy because both specifications describe measurement quality but apply to different aspects of the data.
Relative Accuracy Definition
Relative accuracy describes the precision of spatial relationships within a single scan session. If two features are actually separated by 10.000 meters and the scan measures them as 10.015 meters apart, the relative error is 15mm or 0.15%. The L2 Pro achieves 1cm RMSE relative accuracy within 100 meters of the initialization point, meaning that dimensions and spatial relationships within this range are highly precise.
Relative accuracy remains excellent regardless of whether absolute georeferencing is used. A scan performed without RTK or GCP still achieves 1cm RMSE for internal dimensions. The scan might be in an arbitrary local coordinate system with no relationship to Earth's coordinate grid, but measurements within the scan are still accurate.
Applications requiring only relative accuracy include as-built documentation where the deliverable shows the existing condition of a single facility without needing to relate it to external references, volume calculations on stockpiles or excavations where the measurement is relative to a base plane within the scan area, dimensional verification where the question is "does this structure match the design dimensions" rather than "where exactly is this structure located," and clash detection in renovation projects where new design elements are checked for interference with existing conditions captured in a single scan.
These applications use point cloud data to extract dimensions, verify geometry, and support design decisions without requiring the data to be positioned in any specific coordinate system. The excellent relative accuracy of the Lixel system makes it suitable for these workflows even when absolute georeferencing is not performed.
Absolute Accuracy Definition
Absolute accuracy describes how precisely points are located within a global or regional coordinate system. If a scan point represents a location that should be at coordinates (500000.00m E, 4000000.00m N) in UTM Zone 12, and the scan places it at (500000.03m E, 4000000.07m N), the absolute error is approximately 8cm. The L2 Pro achieves 3-5cm horizontal and 5-10cm vertical absolute RMSE when using RTK georeferencing.
Absolute accuracy becomes critical when the scan must integrate with other geospatial data. This integration includes combining multiple scan sessions from different days into a unified model where each session must align to a common coordinate system, overlaying point clouds on GIS layers showing property boundaries, utilities, or regulatory zones, monitoring change over time by comparing scans from different dates where precise absolute positioning allows automated difference detection, and regulatory compliance where legal descriptions reference specific coordinate systems and accuracy standards.
Applications requiring absolute accuracy must implement appropriate georeferencing during data collection. The georeferencing method (RTK, PPK, or GCP) should be selected based on site conditions, accuracy requirements, and available resources.
Relationship Between Relative and Absolute Accuracy
Relative and absolute accuracy are independent characteristics. A scan can have excellent relative accuracy but poor absolute accuracy if georeferencing is performed incorrectly. Conversely, proper georeferencing places the scan accurately in the global coordinate system while the internal relative accuracy remains determined by SLAM quality.
The total error at any point combines both relative error from the SLAM solution and absolute error from the georeferencing process. For example, a point 50 meters from initialization might have 0.5cm relative error from SLAM. If RTK georeferencing has 4cm absolute error, the total error at that point is approximately √(0.5² + 4²) = 4.03cm, dominated by the absolute error component.
This relationship means that achieving high absolute accuracy requires both excellent relative accuracy from proper scanning technique and accurate georeferencing from RTK, PPK, or well-distributed control points. Neglecting either component degrades the final result.
Georeferencing Methods Compared
Three methods provide absolute coordinate output: Real-Time Kinematic (RTK), Post-Processed Kinematic (PPK), and Ground Control Points (GCP). Understanding the tradeoffs between these methods enables selection of the optimal approach for specific project conditions.
RTK (Real-Time Kinematic)
RTK provides real-time absolute positioning during scanning by receiving corrections from a base station or NTRIP (Networked Transport of RTCM via Internet Protocol) service. The RTK module communicates with GNSS satellites and correction sources simultaneously, computing centimeter-level position throughout the scan session.
Implementation: The RTK module connects to an NTRIP caster via cellular data connection. The caster streams correction data from a nearby base station. The RTK receiver processes satellite observations along with corrections to solve for precise position with centimeter accuracy. LixelGO displays RTK status through colored indicator lights and numeric displays. The scanner records position data synchronized with LiDAR and camera data.
Accuracy: 3-5cm horizontal RMSE and 5-10cm vertical RMSE with continuous RTK fix. The specification assumes fixed ambiguity resolution (indicated by green status light). Float solutions (blue light) degrade to 10-20cm accuracy. Loss of RTK (red light) forces reliance on SLAM dead reckoning which drifts at 0.5-1% of distance traveled. Maximum recommended gap without RTK fix is 100 meters for L2 Pro, 50 meters for K1.
Advantages: No control points required, eliminating the time and cost of control point surveying and placement. Immediate absolute coordinates output, allowing real-time verification of coverage and positioning during data collection. Fastest workflow from field to deliverable with no post-processing coordinate transformation step. Ideal for large sites or corridor mapping where control point placement would be impractical.
Limitations: Requires continuous satellite visibility with minimum 5 satellites in good geometric distribution. Urban canyons, heavy tree cover, and underground sections cause RTK loss. Requires correction signal availability through cellular connection to NTRIP service or radio link to base station. Connection loss during critical sections requires either rescanning or supplementing with control points. RTK accuracy degrades during satellite blockage even if SLAM maintains relative tracking. RTK-capable hardware required (L2 Pro only, not available on K1).
Best applications: Large outdoor sites with good sky visibility, corridor mapping along roads or utilities, rapid deployment projects where time is critical, and sites where control point placement is difficult or dangerous.
PPK (Post-Processed Kinematic)
PPK records GNSS observations during scanning and processes them afterward with base station data. This method tolerates temporary satellite blockage better than RTK because post-processing can resolve ambiguities that real-time processing cannot.
Implementation: The scanner records raw GNSS observations throughout the scan session while SLAM provides the primary positioning. After fieldwork, the user downloads base station observation files covering the same time period. LixelStudio imports both the scan data and base station files, then performs kinematic processing to solve for precise positions throughout the trajectory. The software merges the PPK solution with SLAM trajectory to produce georeferenced point clouds.
Accuracy: 3-5cm horizontal RMSE and 5-10cm vertical RMSE with successful PPK solution. The accuracy matches RTK when processing succeeds. Processing may fail in heavily obstructed areas where insufficient satellite observations exist even in post-processing. Failed sections revert to SLAM-only positioning.
Advantages: More reliable than RTK in partially obstructed environments where real-time processing struggles. No real-time correction signal needed, eliminating cellular connectivity requirements during scanning. Can achieve similar accuracy to RTK with proper processing. Works with recorded base station data from permanent networks which may be available for free in some regions. Post-processing provides quality metrics showing solution confidence throughout trajectory.
Limitations: Requires post-processing step before final coordinates are known, delaying deliverable compared to RTK. Operator cannot verify absolute positioning during collection, requiring experience to judge whether coverage is adequate. Needs base station observation files in RINEX format from a station within 30km of project site. Requires RTK-capable hardware even though positioning is post-processed (L2 Pro only). Processing may fail in GNSS-denied areas where RTK would also fail.
Best applications: Projects in areas with marginal satellite visibility where RTK would have frequent outages, sites near permanent base station networks where RINEX data is freely available, projects where real-time cellular connectivity is unavailable or unreliable, and situations where post-processing delay is acceptable.
GCP (Ground Control Points)
GCP workflow uses surveyed markers placed throughout the scan area. During scanning, the operator marks these points using the control point base and app function. Processing software aligns the scan to control point coordinates through least-squares optimization.
Implementation: Pre-scan surveying establishes precise coordinates for control point markers. The surveying uses total station, RTK GPS, or other methods achieving 1cm accuracy or better. Markers should be permanent or semi-permanent features that will not move during scanning. During scanning, the operator approaches each control point, places the scanner on the control point base aligned with the marker, and triggers the marking function in LixelGO. The app records the timestamp and estimated scanner position. After scanning, LixelStudio imports the control point coordinate file and matches the marked points to surveyed coordinates, solving for the coordinate transformation that best fits the scan to the control points.
Accuracy: 1-2cm RMSE achievable with proper control point network. Accuracy depends on control point spacing (recommended maximum 100 meters between points for L2 Pro, 50 meters for K1), marking precision during scanning (careful placement on control point base and stability during marking interval), control point survey accuracy (1cm or better), and network geometry (points should surround scan area in three-dimensional distribution rather than linear arrangement).
Advantages: Works without GNSS hardware, enabling georeferencing with K1 or when RTK module is unavailable. Effective in GNSS-denied environments including urban canyons, underground facilities, and indoor areas. Control point accuracy is independent of scan duration, whereas RTK accuracy can degrade during satellite outages. Achieves highest accuracy when control point network is properly designed and surveyed. Independent verification through check points not used in transformation.
Limitations: Requires pre-placed surveyed markers, adding time and cost to project preparation. Control point marking during scanning adds time compared to continuous RTK collection. Requires control point visibility from scan path, constraining route options. Coordinate file preparation and name matching required (point names in LixelGO must exactly match names in coordinate file, case-sensitive). Minimum 3-4 points needed with more recommended for large areas.
Best applications: Indoor environments where GNSS is unavailable, projects requiring maximum accuracy (engineering tolerance verification, deformation monitoring), GNSS-challenged outdoor areas (urban canyons, heavy tree cover), situations where control points already exist from previous surveys, and as verification or backup for RTK/PPK workflows.
Method Selection Guidelines
The optimal georeferencing method depends on project conditions and requirements. Large outdoor sites with good sky visibility benefit from RTK for speed and convenience. Partially obstructed outdoor sites with base station access should use PPK for better reliability. Indoor environments or GNSS-denied areas require GCP as the only option. Projects requiring maximum accuracy should use GCP with proper control point network regardless of GNSS availability. Budget constraints or K1 hardware limit to GCP workflow. Projects requiring maximum flexibility and reliability benefit from hybrid approach using GCP with RTK/PPK backup.
Coordinate Systems Explained
Coordinate systems provide frameworks for describing positions on Earth. Understanding coordinate system types, components, and conversions is essential for configuring georeferencing correctly.
Coordinate System Types
Geographic Coordinate Systems describe positions using latitude, longitude, and height. Latitude measures north-south position from -90° (South Pole) to +90° (North Pole). Longitude measures east-west position from -180° to +180° relative to the Prime Meridian. Height measures vertical distance above a reference surface (usually the ellipsoid).
WGS84 (World Geodetic System 1984) is the standard geographic coordinate system used by GPS satellites. All RTK and PPK positioning initially outputs WGS84 latitude, longitude, and ellipsoidal height. Most NTRIP services provide corrections that produce WGS84 coordinates even though they may use other systems internally.
Geographic coordinates have advantages for global applications because they work anywhere on Earth without zone boundaries or projection distortions. However, they have significant disadvantages for engineering applications. Angular units complicate distance calculations—computing the distance between two latitude/longitude points requires spherical trigonometry. Distance between longitude degrees varies with latitude (1° longitude equals 111km at equator but only 56km at 60° latitude).
Projected Coordinate Systems transform the curved Earth surface onto a flat plane using mathematical projection equations. This transformation produces coordinates in linear units (meters or feet) that simplify distance and area calculations. All projected systems introduce distortions because representing a curved surface on a plane requires compromising either angles, distances, areas, or shapes. Different projections optimize different properties for specific applications.
State Plane Coordinate Systems (US) divide each state into one or more zones, each with a custom projection optimized to minimize distortion within that zone. Zones use Lambert Conformal Conic projection (preserving shapes) or Transverse Mercator projection (preserving distances along central meridian). Each zone has unique parameters including central meridian, latitude of origin, standard parallels, false easting, and false northing. EPSG codes uniquely identify each State Plane zone.
UTM (Universal Transverse Mercator) divides the world into 6° longitude zones numbered 1-60, each using Transverse Mercator projection. UTM provides consistent coordinate system worldwide but zones are wider than State Plane zones, introducing more distortion at zone edges. UTM is popular for regional projects that span state boundaries or international projects.
Local Coordinate Systems define origin and orientation arbitrarily for project-specific use. The Lixel scanner creates a local coordinate system when RTK or GCP georeferencing is not used. The origin (0,0,0) is the initialization position. The axes align with gravity (Z vertical) and magnetic north (X pointing north, Y pointing east) or device orientation at initialization. Local coordinates are suitable for projects requiring only relative dimensions without integration to other geospatial data.
Height Systems Explained
Height measurement requires careful attention because multiple height systems exist with differences of tens of meters.
Ellipsoidal Height (also called geodetic height or HAE - Height Above Ellipsoid) measures vertical distance above the reference ellipsoid. The ellipsoid is a mathematical surface approximating Earth's shape. WGS84 ellipsoid is the standard reference for GPS. RTK and PPK positioning outputs ellipsoidal heights because GNSS satellites naturally measure distance to the ellipsoid surface.
Ellipsoidal heights do not match common understanding of "elevation" or "height above sea level." The ellipsoid is a smooth mathematical surface that does not follow terrain. Ellipsoidal heights can be negative even for locations above sea level.
Orthometric Height (also called elevation or AMSL - Above Mean Sea Level) measures vertical distance above the geoid. The geoid is the equipotential surface of Earth's gravity field that would coincide with mean sea level if oceans could flow through continents. The geoid follows terrain variations because it's determined by mass distribution. Orthometric heights match intuitive understanding of elevation.
Most engineering projects specify orthometric heights in project requirements. Topographic maps show orthometric elevations. Construction drawings reference orthometric heights. When clients request "elevation" without qualification, they mean orthometric height.
Geoid Separation (also called geoid undulation) is the vertical distance between ellipsoid and geoid at any location. Geoid separation varies globally from approximately -106 meters to +86 meters. In the United States, geoid separation ranges from approximately -50 meters to +50 meters depending on location.
The relationship between height systems is: Orthometric Height = Ellipsoidal Height - Geoid Separation. Converting from ellipsoidal (provided by RTK) to orthometric (required for deliverables) requires applying the correct geoid model for the project location.
Geoid Models are datasets providing geoid separation values at grid points covering a region. The values are interpolated for locations between grid points. NOAA (National Oceanic and Atmospheric Administration) publishes geoid models for the United States including GEOID18 (current model, published 2019), GEOID12B (previous model), and GEOID09 (older model). The models improve accuracy as surveying data and gravity measurements accumulate.
Using the wrong geoid model introduces systematic height errors of 5-20cm depending on location. Always use the most recent geoid model appropriate for your region. For United States projects, GEOID18 is recommended. For other countries, contact local surveying authorities for appropriate geoid models.
LixelStudio applies geoid corrections automatically when a geoid model is loaded in the coordinate transformation settings. Without a geoid model loaded, output heights remain as ellipsoidal heights which will not match expected elevations.
Coordinate System Configuration
Coordinate system configuration represents one of the most technically challenging aspects of the Lixel workflow. Errors in configuration produce meter-level positioning errors that corrupt deliverables. Following systematic configuration procedures prevents these errors.
Understanding EPSG Codes
EPSG (European Petroleum Survey Group, now OGP - International Association of Oil & Gas Producers) codes provide standardized numeric identifiers for coordinate systems. Each code uniquely identifies the complete coordinate system definition including datum, projection, zone, parameters, and units.
For example, EPSG:32143 identifies "NAD83 / Utah Central (ftUS)" which specifies datum NAD83, State Plane Utah Central zone, Lambert Conformal Conic projection with specific parameters, and US Survey Feet as linear units. Using EPSG codes prevents ambiguity that can arise from coordinate system names.
The online resource epsg.io provides searchable access to the EPSG database. Search by region name, coordinate system name, or EPSG code to find complete specifications. When client requirements specify a coordinate system, always obtain or verify the EPSG code to ensure exact match during configuration.
Configuration Workflow
The coordinate system configuration workflow has two phases: pre-scan RTK configuration in LixelGO, and post-scan coordinate transformation configuration in LixelStudio.
Pre-Scan Configuration (RTK Method):
Identify the RTK provider and obtain connection parameters including NTRIP caster URL, port number, username, password, and mount point identifier. Contact the provider and confirm what coordinate system they output. Most commercial providers output WGS84 geographic coordinates (latitude/longitude/ellipsoidal height). Some regional networks might output NAD83 or local datum coordinates. This information is critical for Source Ellipsoid setting.
Open LixelGO and navigate to Settings → RTK Settings. Set Type to Custom unless using Qianxun or China Mobile services which have predefined profiles. Set Source Ellipsoid to WGS84 or whatever the RTK provider confirmed. Enter Host (NTRIP caster IP address or domain name), Port (typically 2101), Mount Point (specific correction stream), Username, and Password. Tap Save.
Test the RTK connection before departing for the field. Power on the scanner with RTK module installed. LixelGO should show RTK status transitioning from red (no GNSS) to blue (GNSS without corrections) to green (fixed solution with corrections) within 1-3 minutes in open sky. If the connection fails, verify all parameters exactly match provider specifications.
Post-Scan Configuration (Both RTK and GCP Methods):
After scanning and importing the project into LixelStudio, open Project Processing and navigate to Coordinate Transformation section. Select the appropriate transformation method: GNSS for RTK or PPK workflows, or GCP for ground control point workflows.
For GNSS method, click Settings to open the transformation configuration dialog. In Source Settings section, set Source Coordinate to match the RTK provider output (usually WGS84 Geographic). Set Source Ellipsoid to WGS84. These settings must exactly match what the RTK provider actually outputs or meter-level errors will result.
For Target Settings, use EPSG code search (recommended) or manual parameter entry. EPSG search is faster and less error-prone. Click the search button next to Target Coordinate field. Enter the EPSG code for the required deliverable coordinate system. Select the result from the list. The software automatically populates all projection parameters.
If EPSG search does not find the required system, use manual parameter entry. Navigate to epsg.io and search for the required coordinate system. Note all projection parameters from the epsg.io listing. In LixelStudio, set Target Coordinate to Other. Set Target Ellipsoid to the appropriate reference (GRS 1980 for NAD83, WGS84 for WGS84-based systems). Set Projection to the appropriate type (Lambert Conformal Conic, Transverse Mercator, etc.). Enter all parameters exactly as shown on epsg.io including central meridian, latitude of origin, standard parallels, false easting, and false northing.
Configure datum transformation parameters if converting between different datums (e.g., WGS84 source to NAD83 target). Use standard published 7-parameter transformation (3 translation, 3 rotation, 1 scale) or calculate parameters from control points that have coordinates in both datums. Standard WGS84 to NAD83 parameters are published online and work adequately for most applications.
If orthometric heights are required, configure the geoid model. Download the appropriate geoid model for the project region (GEOID18 for United States). The model file is typically distributed as GeoTIFF raster. In LixelStudio Settings dialog, navigate to Geoid section. Click Import and select the downloaded GeoTIFF file. Set Interpolation to Bilinear for smooth height conversion.
Review all settings before processing. Verify Source Coordinate matches RTK provider output, Target Coordinate matches project requirements, datum transformation is configured if needed, and geoid model is loaded if orthometric heights are required. Click OK to save settings and process the project.
Verification After Processing
After processing with coordinate transformation, verify the results before delivering to clients. If surveyed check points are available, measure their coordinates in the processed point cloud using LixelStudio measurement tools. Compare measured coordinates to surveyed values. Differences reveal achieved accuracy and catch configuration errors.
Check points should be independent from control points used in the transformation. Using the same points for transformation and checking creates circular verification that cannot detect errors. Ideally, set aside 20-30% of surveyed points as check points not used in transformation.
Common error patterns and their causes:
Systematic offset of several meters typically indicates wrong projection parameters. Verify the EPSG code or manually entered parameters match requirements.
Transposed coordinate values (X and Y swapped) indicate wrong axis order in projection definition. Some systems define X as easting, others as northing. Verify axis order matches requirements.
Elevation errors of tens of meters indicate missing geoid model or wrong geoid model applied. Verify GEOID18 is loaded and interpolation is enabled.
Large rotational errors indicate wrong central meridian in projection parameters. Verify central meridian matches the EPSG specification.
Random errors of decimeters indicate control point marking problems or mismatched control point names. Verify marked points match coordinate file exactly.
Common Regional Coordinate System Examples
Understanding complete configuration for specific regions helps users apply the concepts to their projects.
New York City (Long Island)
Project requirement: NAD83 New York Long Island State Plane coordinates in US Survey Feet
EPSG code: 2263
Projection type: Lambert Conformal Conic
RTK source: WGS84 (EPSG:4326 geographic) from commercial NTRIP provider
Configuration steps: Set Source Coordinate to WGS84 Geographic. Set Source Ellipsoid to WGS84. Search for EPSG 2263 and select it for Target Coordinate. The software auto-populates projection parameters. Configure datum transformation from WGS84 to NAD83 using standard 7-parameter transformation. Import GEOID18 geoid model for orthometric heights. Process and verify with check points.
Los Angeles
Project requirement: NAD83 California Zone 5 State Plane coordinates in US Survey Feet
EPSG code: 2229 (feet) or 26945 (meters)
Projection type: Lambert Conformal Conic
RTK source: WGS84 from commercial NTRIP provider
Configuration: Source WGS84 Geographic, Target EPSG:2229, datum transformation WGS84 to NAD83, GEOID18 for orthometric heights.
Chicago
Project requirement: NAD83 Illinois East State Plane coordinates
EPSG code: 3435 (US Survey Feet) or 26971 (meters)
Projection type: Transverse Mercator
RTK source: WGS84 from commercial NTRIP provider
Configuration: Source WGS84 Geographic, Target EPSG:3435, datum transformation WGS84 to NAD83, GEOID18 for orthometric heights.
Phoenix
Project requirement: NAD83 Arizona Central State Plane coordinates
EPSG code: 2223 (US Survey Feet) or 26949 (meters)
Projection type: Transverse Mercator
RTK source: WGS84 from commercial NTRIP provider
Configuration: Source WGS84 Geographic, Target EPSG:2223, datum transformation WGS84 to NAD83, GEOID18 for orthometric heights.
Salt Lake City
Project requirement: NAD83 Utah Central State Plane coordinates
EPSG code: 32143 (NAD83 US Survey Feet) or 6620 (NAD83 2011)
Projection type: Lambert Conformal Conic
RTK source: WGS84 from commercial NTRIP provider
Configuration: Source WGS84 Geographic, Target EPSG:32143, datum transformation WGS84 to NAD83, GEOID18 for orthometric heights. Alternative configuration uses EPSG:6620 for NAD83(2011) which is the more recent datum realization but requires different datum transformation parameters.
Getting Help with Coordinate Systems
When struggling with coordinate system configuration, implement these strategies to resolve issues:
Contact the client and request the exact coordinate system specification preferably with EPSG code. Many confusion arises from ambiguous requirements like "State Plane coordinates" without specifying state, zone, datum, or units.
Contact the RTK provider and confirm what coordinate system they output. Explicitly ask "What is the datum and ellipsoid of your output coordinates?" Most providers output WGS84 but some use NAD83 or regional datums.
Consult with a local surveyor who knows regional standards and typical project requirements. Surveyors can identify the appropriate coordinate system for your area and may have EPSG codes readily available.
Use epsg.io to research coordinate systems by region, name, or partial information. The site provides complete specifications including all projection parameters.
Contact XGRIDS technical support with specific project information including project location (city, state, country), required deliverable coordinate system per client specifications, RTK provider name and connection details, and any error messages or incorrect results encountered. Support engineers can guide configuration for specific situations.
The coordinate system configuration represents the most technical aspect of the Lixel workflow. However, systematic approach, proper understanding of coordinate concepts, and using available resources enables successful configuration. The effort invested in correct configuration prevents costly rework and ensures professional-quality deliverables that integrate properly with client systems.
