University-1652 pairs drone, satellite and street views of 1652 buildings

Two tasks, one drone and one satellite image

The benchmark is built around two retrieval tasks that read as inverses of each other. Task 1 is drone-view target localization, given a drone-view image or video, and the aim is to find the most similar satellite-view image in order to localize the target building in the satellite view. Task 2 is drone navigation, given one satellite-view image, where the drone finds the most relevant place among the drone-view images it has passed by, so that according to its flight history it can be navigated back to the target place. That pairing is what makes the dataset unusual. Most cross-view retrieval datasets pair ground-level street photos with satellite imagery, and this one inserts the aerial drone perspective in between, which is a much harder geometry because a drone sees a building from above and at an angle, while a satellite view is nearly orthographic. The repository also lists earlier related datasets in its topic tags, and the code includes a prepare_cvusa.py script alongside the University-1652 preparation, which tells you the authors treat the two as neighbouring problems rather than isolated ones.

The split table is where the difficulty lives

The dataset split is published in full, and it is the most important thing to understand before running anything. The training split has 50,218 images across 701 buildings on 33 universities. The query sets are drone, satellite and ground, with 37,855 drone images, 701 satellite images and 2,579 ground images, all over the same 701 buildings but now on 39 universities. The gallery sets are larger and different: 51,355 drone images and 951 satellite images over 951 buildings, plus 2,921 ground images over 793 buildings. So the evaluation runs over 39 universities while training ran over 33, and the query buildings and gallery buildings are not the same set. That last point is the interesting design. When the query building is not in the gallery, the retrieval task becomes finding a visually similar but different building, which is what a real drone operator faces. The three view types also have wildly different counts, 701 satellite images against more than 50,000 drone images, and any method that treats views symmetrically will be surprised by that imbalance.

The data arrives on request, not by download

This is the practical constraint that catches new users. The dataset is available upon request, and the README says the author usually replies within five minutes, with a request template provided in the repository so the request follows a fixed format. The repository itself contains the dataset link and the code for the paper, University-1652: A Multi-view Multi-source Benchmark for Drone-based Geo-localization, published at ACM Multimedia 2020, with the official paper link given in the ACM Digital Library. Alongside the imagery, the repository hosts a set of auxiliary files that are useful and easy to miss: a building name list, a file of latitude and longitude coordinates, and a flight path file, all linked from the README. The flight path in particular is what makes the navigation task meaningful, since it describes where the drone actually went. There is also a video demonstration and a Chinese introduction linked, and the data volume implied by those counts is the reason a request workflow rather than a public bucket is the sensible approach.

The repository is a bag of training scripts, not a framework

What you get in code is best described as a working set of experiments. The top level contains train.py alongside a family of variants that differ by how much training data they use, train_1_sample.py, train_3_sample.py, train_9_sample.py, train_18_sample.py and train_27_sample.py, which tells you the sample count is a first class experimental variable rather than an accident. There is also train_no_street.py, which trains without the street-view data, and train_cvusa.py, which trains on the related CVUSA data instead. Evaluation is split by input size and by dataset, with test.py, test_4K.py, test_160k.py, test_cvusa.py, test_ImageNet.py, test_Place365.py and test_train.py, and there is a separate test_4K.py alongside demo_4K.py and image_4K/ for high resolution imagery. Inference helpers are demo.py and evaluate_gpu.py, the latter being what the workshop challenge workflow tells participants to modify to save the top 10 gallery image names in query order. Supporting pieces include model.py, model/, utils.py, folder.py, circle_loss.py, autoaugment.py, random_erasing.py, gallery_name.txt, query_name.txt and new_name_list.txt, plus a tool/ directory and a tutorial/ directory. The list of pretrained state-of-the-art methods under a State-of-the-art/ directory and the SIFT/ and GPU-Re-Ranking/ folders show this has grown into a comparison bench rather than a single implementation.

The model family and the evaluation contract

The README links a paper, a slide deck and a video, and the code follows the paper's structure. The topic tags name the mechanisms the project is associated with, and among them are gem-pooling, the aggregation method the paper is known for, and image retrieval more generally. What the repository does not do is hide the details of a single production pipeline. The model.py file and the model/ directory hold the network definitions, the training scripts take a sample count and a dataset as their distinguishing arguments, and the evaluation scripts are separated by resolution because the benchmarks are not always run at the same input size. The four K variants are worth a note. University-1652 imagery comes from different platforms and a later release adds a 16k variant, which suggests the authors found that resolution changes the retrieval behaviour enough to warrant separate experiments rather than one configuration for all cases. The circle loss and the autoaugment and random erasing modules are training-time regularisation choices, and having them as separate files means each can be switched off, which matters when you want to attribute a result to the architecture rather than to the training recipe.

The workshop track is where the dataset keeps being used

The README documents a sequence of workshops and challenges, and this is the clearest evidence of how the benchmark is being used in practice. The 2026 workshop and special session includes ACM MM UAVM 2026, described as the fourth edition, with a challenge hosted on Codabench. The 2025 entry, the third workshop, spells out the challenge workflow step by step: train on University-1652 with drone, satellite and street data, download the name-masked test set from OneDrive, extract features with your own model, and then modify demo.py or evaluate_gpu.py to save the top 10 gallery image names following the query order. The name-masking is the interesting detail, because it means the organisers hold back the labels so that submissions can be scored automatically. The 2024 entries cover an ACM MM workshop, an ACM ICMR workshop on multimedia object re-identification, and an ACM WWW workshop, and the 2023 entries list an IEEE ITSC special session and a Remote Sensing special issue. The author also advertises open positions for PhD students, postdocs and research assistants on spatial intelligence for UAVs, person analysis, and video diffusion and world models.

What this repository is not

Three limits are worth naming before you build on it. The first is access. There is no public download, so reproducibility depends on a request going through and on the requester receiving the data, and the auxiliary files such as the latitude and longitude list and the flight path are separately linked, so you need all of them and not just the images. The second is that this is a research baseline, and a baseline is a reference point rather than a system. The scripts are arranged around paper experiments, with a dozen training variants, and the evaluation contract is defined by what the challenge organisers expect, which is a top 10 ranking in query order. If you need a maintained, general purpose cross-view retrieval library with a stable API, this is not that, and the repository's own State-of-the-art/ directory is a better indication of its purpose, since it holds other people's methods for comparison. The third is maintenance timing. The last push was on 2026-10-07 and the most recent release is v1.2, titled Updating bfloat16, from 2025-05-07, with v1.1 back in December 2021, so the code moves in small steps tied to the workshops and the dataset rather than on a release cadence you can plan against. The licence is MIT, which is permissive enough for commercial work, and the code claims Python 3.6 or newer in its badge.

Editorial conclusion

Adopt University1652-Baseline if you are working on drone-based geo-localization or cross-view image retrieval and you need the standard split and the reference training and evaluation scripts. Skip it if you need the imagery to be downloadable from a public URL, because the dataset is released on request after a form, and skip it if your task is street-level retrieval, since the street-view split exists but is not the focus of either benchmark task. Before you plan a run, count the images in each split from the table in the README, because the training and query splits do not use the same building list, and read the request template so you know what you have to send to obtain the data.

Frequently asked questions

Official sources

1. layumi/University1652-Baseline on GitHub
2. License: MIT
3. Project website
4. README
5. Releases