UrbanNav hands you raw GNSS RINEX from Hong Kong and Tokyo urban canyons

The problem being targeted is GNSS failure between tall buildings

The dataset exists because positioning in deep urban canyons with low-cost sensors is still a hard problem, and the README is specific about why. The accuracy of GNSS can be severely challenged in urban canyons due to the high rising buildings, which leads to numerous non-line-of-sight receptions and multipath effects. The excessive dynamic objects can also distort the performance of LiDAR and camera. So the target is not general navigation but the failure mode where satellites are blocked and reflected, and the goal is to provide a challenging data source for the community to accelerate the study of accurate positioning in difficult conditions. The stated objectives follow from that. The first is open-sourcing positioning sensor data including GNSS, INS, LiDAR and cameras collected in Asian urban canyons. The second is raising awareness of the urgent navigation requirement in highly urbanised areas, especially in the Asia-Pacific region. The third is providing an integrated online platform for data sharing, and the fourth is benchmarking positioning algorithms on that data.

Raw RINEX is the difference from the datasets it is compared against

The README draws a contrast with the two datasets most people would name, Waymo and KITTI, and the difference is specific. Different from those existing datasets, UrbanNav provides raw GNSS RINEX data, which the README says means users can improve the performance of GNSS positioning via raw data. That is a substantial difference in what a researcher can do. A dataset that ships positions has already applied some estimator, and improving on it means reimplementing the sensor fusion that produced those positions. A dataset that ships the raw observations lets you build your own receiver front end, which is the point of the exercise for anyone working on multipath mitigation or NLOS detection. The README also makes the scope explicit in its summary line, that the dataset poses a special focus on improving GNSS positioning in urban canyons but also provides sensor measurements from LiDAR, camera and IMU. The raw data is the differentiator, and the multimodal data is the accompaniment.

The Hong Kong rig is a Honda Fit carrying eight sensor types

The Hong Kong collection platform is a Honda Fit, and the sensor list is what makes the dataset interesting. A 3D LiDAR, the HDL 32E Velodyne, gives 360 degrees horizontal field of view, a +10 to -30 degree vertical field of view, an 80 metre range at 10 Hz, and there are two slant lidars, the VLP16 Velodyne and the Lslidar C16. The IMU is an Xsens Mti 10 running at 400 Hz with AHRS. There are three GNSS receivers, two u-blox ZED-F9P and one EVK-M8T at 1 Hz, plus a NovAtel Flexpak6 at 1 Hz. A ZED2 stereo camera captures at 15 Hz. The ground truth is a NovAtel SPAN-CPT combined RTK GNSS and INS system with 5 cm RMSE at 1 Hz. For a positioning dataset, the 5 cm reference figure is the number that matters, because it sets the floor against which any algorithm is judged.

The data is split by canyon difficulty, not by one uniform sequence

The repository layout shows the Hong Kong data organised by collection, with directories for UrbanNav-HK-Data20190428, UrbanNav-HK-Data20200314, UrbanNav-HK-Deep-Urban-1, UrbanNav-HK-Harsh-Urban-1, UrbanNav-HK-Medium-Urban-1 and UrbanNav-HK-Tunnel-1. The names are the point. Rather than one drive, the dataset is stratified by how hard the environment is, from medium urban through deep urban and harsh urban to a tunnel case, and the table in the README lists for each entry the total size, the path length, the sensors, the urban canyon category and the download links, plus a link to a 3D point cloud of the urban map. The Medium Urban 1 entry is given as 33.7 GB covering 785 seconds over 3.64 km, with separate download links for the ROS bag, the GNSS data, the IMU data, the ground truth and a sky mask. A sky mask is a small detail that turns out to matter, because it tells an algorithm which part of the sky was actually visible, which is the variable that explains the non-line-of-sight receptions the dataset is built around.

Each sequence is published as separate sensor downloads, not one bundle

The download structure is worth understanding before you start pulling data. The table links separately to a ROS bag containing the sensor recordings, a separate GNSS download carrying the RINEX files, a separate IMU download, a separate ground truth file and a separate sky mask, and the row ends with a link to the urban map as a 3D point cloud. The ground truth file for the Medium Urban sequence is a plain text download named for the ground truth, and the sky mask is a CSV. So the practical workflow is that you choose a sequence by its canyon difficulty, then assemble the modalities you need from separate links, and the RINEX data is the part that is unique to this dataset. The tools/ directory at the top of the repository is where helper code for the data lives, and the docs/ directory holds the getting started guide, the acknowledgements, the related publications and a webinar slide deck.

GraphGNSSLib turns the RINEX files into something you can process

Accessing raw GNSS is not straightforward, and the dataset addresses that with a companion package. The README states that the GNSS measurements are provided as RINEX data and that the authors open-sourced a package, GraphGNSSLib, which provides easy access to the GNSS RINEX file and publishes the data as customised ROS messages. It also provides the capabilities of GNSS positioning and real-time kinematic using factor graph optimisation. That last point is significant for how you should read the release. GraphGNSSLib is not just a reader, it is a reference positioning stack, which means the baseline against which your own work is judged comes from the same authors who assembled the data. For a benchmark dataset that is the right design, because it removes the question of whether the reference solution was tuned with the ground truth in hand. The RINEX format itself is the standard observation format for GNSS, so the data is usable with other tooling as well.

The project wants contributions, and states the review process

The dataset is positioned as a platform rather than a finished artefact, and the README says how to participate in it. Researchers who wish to contribute their own dataset as part of UrbanNav are asked to contact the authors by email, and the goal is stated as making UrbanNav a platform for navigation solution development, validation and sharing. For algorithm results, researchers are welcomed to share their navigation solution results and source code with the dataset after a code review process, with examples given as code for GNSS and INS integration or for LiDAR SLAM. The code review step is the interesting part for anyone thinking about what counts as a valid submission, because it means results are not accepted on submission alone. The corresponding authors for issues and maintenance of the currently available Hong Kong dataset are listed from the Intelligent Positioning and Navigation Laboratory at The Hong Kong Polytechnic University, and the two related papers are cited with DOIs, one in NAVIGATION and one at the ION GNSS plus 2021 meeting.

Where UrbanNav is the wrong choice

Three situations argue against it. The first is a project that needs a ready made benchmark with a fixed evaluation protocol and a leaderboard. UrbanNav provides the data and the reference stack, and the benchmarking objective is stated as something the community does, not something the repository hands you as a scored result, so you would be building the evaluation harness yourself. The second is a project outside the Asia-Pacific urban canyon setting. The stated emphasis is on Asian urban canyons and the data is Hong Kong and Tokyo, with the objectives explicitly about the navigation requirement in highly urbanised areas in that region, and a research group studying, say, North American suburban positioning or open rural GNSS would find the geometry unfamiliar. The third is a team that needs continuous data rather than a handful of curated drives. These are collected routes with a path length and a duration per sequence, designed to be difficult rather than to be exhaustive coverage of a city. And there is a practical constraint that applies to every case, which is the size. A single sequence listed at 33.7 GB means that a full evaluation across several canyon categories is a storage and transfer problem before it is a research problem, so anyone planning a serious experiment should read the getting started document and the size column before committing to a download.

Editorial conclusion

Adopt UrbanNav when you are benchmarking a positioning algorithm and need raw GNSS observations in a hard urban environment rather than a pre-solved trajectory, and look elsewhere if you need a ready to use labelled sequence with a fixed evaluation protocol. Verify first which sequence and sensor combination matches your experiment, since the repository splits the data into medium, deep, harsh and tunnel urban categories, and read the getting started document in docs/ before downloading tens of gigabytes.

Frequently asked questions

Official sources

1. IPNL-POLYU/UrbanNavDataset on GitHub
2. Issues
3. License: MIT
4. README