Skip to content

georeferencing trouble #447

Closed
Closed

Description

@jude-mb

i'm following the manual and having some trouble using HDMapping to georeference Mandeye-MR data using GNSS files

open multi_view_tls_registration step 2
open session (from step 1)
load all .gnss files
where is "show GNSS correspondences" button?
click Manual Loop Closure
where is "initial poses as motion model" button ?
Compute Pose Graph SLAM
export as Global Scan
output .laz file is not georeferenced?

Activity

  1. JanuszBedkowski commented on Jun 27, 2026

    @JanuszBedkowski
    Member

    Hi I am working on release 101, lets back to this issue ASAP

  2. jude-mb commented on Jul 8, 2026

    @jude-mb
    Author

    Hi, I am still having this issue with v101

  3. self-assigned this
    on Jul 8, 2026
  4. jude-mb commented on Jul 8, 2026

    @jude-mb
    Author

    when loading GNSS files i received error pj_obj_create: Cannot find proj.db and fixed by copying a valid proj.db (from an OSGeo4W proj install) into the same folder as multi_view_tls_registration_step_2.exe and proj_9_3.dll - not sure if this is expected?

  5. jude-mb commented on Jul 8, 2026

    @jude-mb
    Author

    also the issue does not seem to be the GNSS file themselves, lat and lon seem correct

  6. pinned this issue on Jul 8, 2026
  7. michalpelka commented on Jul 8, 2026

    @michalpelka
    Contributor

    It should be copied by itself, I am not sure if Janusz added it to release properly. I will check it.
    You need proj.db next to exe file on Windows.
    Here is my dev build on linux loading NMEA / GNSS using Proj:
    https://youtu.be/7aXIvFPzBww

    Current startus is like that:

    • Proj is available for use both on Linux and Windows and has some great features (e.g. support for multiple coordiante system, currrently PUWG92 and UTM and LLA). Also it is industry standard for dealing with geographical coordinate systems.
    • Old, hand-written functions are available and marked as deprecated.
    • To use correctly, you need to download chose GPX geoid model, if not, exported data can have incorrect height.
    • There is possibility that proj.db is not delivered.
  8. jude-mb commented on Jul 9, 2026

    @jude-mb
    Author

    Hi, thanks for the video! It was unclear before that i needed to press "save metascan points to ...". I'm still having some issues though. When I save metascan points to WGS84 LLA the laz file is corrupted:

    Image

    Otherwise saving to PUWG92 or UTM_AUTO or WebMercator works fine.

    Image

    Converting this to EPSG: 27700 and viewing in CloudCompare with georeferenced ALS data from the UK National LiDAR programme it seems they are vertically misaligned but seem to be aligned in X and Y.

    Image

    There is only the option to save geoid to WGS84Ellipsoid ...

    Image
  9. JanuszBedkowski commented on Jul 9, 2026

    @JanuszBedkowski
    Member

    Hi are You in Oxford?

  10. jude-mb commented on Jul 9, 2026

    @jude-mb
    Author

    No, I am not XD

  11. JanuszBedkowski commented on Jul 10, 2026

    @JanuszBedkowski
    Member

    Can I consider this issue is solved?

  12. jude-mb commented on Jul 11, 2026

    @jude-mb
    Author

    There a a couple of issues to solve still ... when exporting metascan points to WGS84 LLA, the output .laz file collapses to a line of points - are you able to fix this issue? Is there a way to add vertical datums other than "WGSEllipsoid" (this is unclear)? Also, working around these issues and exporting .laz as UTM AUTO using .gnss files as shown in the youtube video then reprojecting using a compound CRS (EPSG:32630+4979) the file is hugely tilted compared to georeferenced ALS data ... how can I avoid this?

    Image
  13. JanuszBedkowski commented on Jul 11, 2026

    @JanuszBedkowski
    Member

    can You share data and detailed info how to reconstruct problem?

  14. michalpelka commented on Jul 12, 2026

    @michalpelka
    Contributor

    Coming back, I've tested UTM, it works fine.
    Here is data, if you want to do repro on your side:

    Data Link
    Mandeye session https://drive.google.com/file/d/1Mx_0BWuykzY8g-1zdMQteJM0PlxWGtSR/view?usp=sharing
    UTM Airborne Lidar https://drive.google.com/file/d/12YZuES_bgDDc_EgprU7VwceF9iLGaH58/view?usp=sharing
    Puwg92 Airborne Lidar https://drive.google.com/file/d/1WeId-nfs0hMGOkfG8-_mogK5M3iQWMAl/view?usp=sharing

    You can add vertical datums, simply download https://github.com/OSGeo/proj-datumgrid/blob/master/egm96_15.gtx and place next to EXE - it should be listed:

    Image

    I've converted Airborne Lidar from Polish national system to UTM and used SaveMetascan in UTM_AUTO with geoid egm96_15.gtx. Results looks fine:
    Image

    The WGS84 export works fine, but this data won't be visulaized since they are not Cartesian. X and Y are degrees, Z is meters. It will be rendered as line, box dimensions for WGS84 LLA makes total sense:

    Image

    I will remove this export, since it confusing and adds no value.
    I think except this LLA, georeferecing works as expected.
    Note that you can probably export EPSG:32630+4979 ( it is British national system, isn't it?). Simply add it to

    std::vector<Eigen::Vector3d> GNSS::CRTConvert(
        const std::vector<Eigen::Vector3d>& llaPointcloud, const std::string targetCRT, const std::string geoid)
    
  15. michalpelka commented on Jul 12, 2026

    @michalpelka
    Contributor

    PR to remove this export : #459

  16. JanuszBedkowski commented on Jul 14, 2026

    @JanuszBedkowski
    Member

    Can we considered this issue is addressed?

  17. jude-mb commented on Jul 17, 2026

    @jude-mb
    Author

    thank you! this makes more sense now:)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

questionFurther information is requested

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions