SDTagNet: Leveraging Text-Annotated Navigation Maps for Online HD Map Construction
Extracted source text · arXiv 2506.08997
% ubtwq@student.kit.edu\ubtwq@student.kit.edu
\documentclass{article}
% if you need to pass options to natbib, use, e.g.:
% \PassOptionsToPackage{numbers, compress}{natbib}
% before loading neurips_2025
\PassOptionsToPackage{numbers}{natbib}
% ready for submission
\usepackage[final]{neurips_2025}
%\usepackage[preprint]{neurips_2025}
% to compile a preprint version, e.g., for submission to arXiv, add add the
% [preprint] option:
% \usepackage[preprint]{neurips_2025}
% to compile a camera-ready version, add the [final] option, e.g.:
% \usepackage[final]{neurips_2025}
% to avoid loading the natbib package, add option nonatbib:
% \usepackage[nonatbib]{neurips_2025}
\usepackage[utf8]{inputenc} % allow utf-8 input
\usepackage[T1]{fontenc} % use 8-bit T1 fonts
\usepackage{hyperref} % hyperlinks
\usepackage{url} % simple URL typesetting
\usepackage{booktabs} % professional-quality tables
\usepackage{amsfonts} % blackboard math symbols
\usepackage{nicefrac} % compact symbols for 1/2, etc.
\usepackage{microtype} % microtypography
\usepackage{xcolor} % colors
\usepackage{subcaption}
\usepackage[export]{adjustbox}
\usepackage{array}
\usepackage{multirow}
\usepackage{arydshln}
\usepackage{amssymb}
\usepackage{MnSymbol}
\usepackage{pifont}
\newcommand{\cmark}{\ding{51}}%
\newcommand{\xmark}{\ding{55}}%
\usepackage{booktabs}
\usepackage[dvipsnames]{xcolor}
\usepackage[nolist]{acronym}
\usepackage{csquotes}
\usepackage{tikz}
\usepackage{xspace}
\usepackage{siunitx}
\usepackage{cleveref}
% Useful stuff from CVPR/ICCV template
% Add a period to the end of an abbreviation unless there's one
% already, then \xspace.
\makeatletter
\DeclareRobustCommand\onedot{\futurelet\@let@token\@onedot}
\def\@onedot{\ifx\@let@token.\else.\null\fi\xspace}
\def\eg{\emph{e.g}\onedot} \def\Eg{\emph{E.g}\onedot}
\def\ie{\emph{i.e}\onedot} \def\Ie{\emph{I.e}\onedot}
\def\cf{\emph{cf}\onedot} \def\Cf{\emph{Cf}\onedot}
\def\etc{\emph{etc}\onedot} \def\vs{\emph{vs}\onedot}
\def\wrt{w.r.t\onedot} \def\dof{d.o.f\onedot}
\def\iid{i.i.d\onedot} \def\wolog{w.l.o.g\onedot}
\def\etal{\emph{et al}\onedot}
\makeatother
\title{SDTagNet: Leveraging Text-Annotated Navigation Maps for Online HD Map Construction}
% The \author macro works with any number of authors. There are two commands
% used to separate the names and addresses of multiple authors: \And and \AND.
%
% Using \And between authors leaves it to LaTeX to determine where to break the
% lines. Using \AND forces a line break at that point. So, if LaTeX puts 3 of 4
% authors names on the first line, and the last on the second line, try using
% \AND instead of \And before the third author name.
% \thanks{Use footnote for providing further information about author (webpage, alternative address)---\emph{not} for acknowledging funding agencies.}
\author{%
Fabian Immel$^{1}$ \quad Jan-Hendrik Pauls$^{2}$ \quad Richard Fehler$^{1}$ \quad Frank Bieder$^{1}$ \\
\textbf{Jonas Merkert$^{2}$ \quad Christoph Stiller$^{2}$}\\
$^{1}$FZI Research Center for Information Technology \quad $^{2}$Karlsruhe Institute of Technology\\
\texttt{\{immel, fehler, bieder\}@fzi.de} \quad \texttt{\{jan-hendrik.pauls, stiller\}@kit.edu}\\
% examples of more authors
% \And
% Fabian Immel \\
% Institute of Measurement and Control Systems\\
% Karlsruhe Institute of Technology\\
% \texttt{\{jan-hendrik.pauls, stiller\}@kit.edu} \\
% Coauthor \\
% Affiliation \\
% Address \\
% \texttt{email} \\
% \AND
% Coauthor \\
% Affiliation \\
% Address \\
% \texttt{email} \\
% \And
% Coauthor \\
% Affiliation \\
% Address \\
% \texttt{email} \\
% \And
% Coauthor \\
% Affiliation \\
% Address \\
% \texttt{email} \\
}
\begin{document}
\maketitle
\input{sec/0_abstract}
\input{sec/1_intro}
\input{sec/2_related_work}
\input{sec/3_method}
\input{sec/4_experiments}
\input{sec/5_conclusion}
{
%\newline
%\todo{REFERENZEN CHECKEN!}
\small
\bibliographystyle{ieeenat_fullname}
\bibliography{bibliography}
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \newpage
% \section*{NeurIPS Paper Checklist}
% \begin{enumerate}
% \item {\bf Claims}
% \item[] Question: Do the main claims made in the abstract and introduction accurately reflect the paper's contributions and scope?
% \item[] Answer: \answerYes{} % Replace by \answerYes{}, \answerNo{}, or \answerNA{}.
% \item[] Justification: We summarize and highlight the main contributions and claims in the abstract and introduction, matching the methodological and experimental scope, supported by the results of our work.
% %Our work does not make major or critical assumptions on the input or deployed system.
% %Generalization of our method can be assessed through the evaluation on two distinct datasets.
% \item[] Guidelines:
% \begin{itemize}
% \item The answer NA means that the abstract and introduction do not include the claims made in the paper.
% \item The abstract and/or introduction should clearly state the claims made, including the contributions made in the paper and important assumptions and limitations. A No or NA answer to this question will not be perceived well by the reviewers.
% \item The claims made should match theoretical and experimental results, and reflect how much the results can be expected to generalize to other settings.
% \item It is fine to include aspirational goals as motivation as long as it is clear that these goals are not attained by the paper.
% \end{itemize}
% \item {\bf Limitations}
% \item[] Question: Does the paper discuss the limitations of the work performed by the authors?
% \item[] Answer: \answerYes{}{} % Replace by \answerYes{}, \answerNo{}, or \answerNA{}.
% \item[] Justification: We discuss limitations in \Cref{sec:limitations} and also qualitatively highlight limitations of our work and the used dataset ground truth maps.
% \item[] Guidelines:
% \begin{itemize}
% \item The answer NA means that the paper has no limitation while the answer No means that the paper has limitations, but those are not discussed in the paper.
% \item The authors are encouraged to create a separate "Limitations" section in their paper.
% \item The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g., independence assumptions, noiseless settings, model well-specification, asymptotic approximations only holding locally). The authors should reflect on how these assumptions might be violated in practice and what the implications would be.
% \item The authors should reflect on the scope of the claims made, e.g., if the approach was only tested on a few datasets or with a few runs. In general, empirical results often depend on implicit assumptions, which should be articulated.
% \item The authors should reflect on the factors that influence the performance of the approach. For example, a facial recognition algorithm may perform poorly when image resolution is low or images are taken in low lighting. Or a speech-to-text system might not be used reliably to provide closed captions for online lectures because it fails to handle technical jargon.
% \item The authors should discuss the computational efficiency of the proposed algorithms and how they scale with dataset size.
% \item If applicable, the authors should discuss possible limitations of their approach to address problems of privacy and fairness.
% \item While the authors might fear that complete honesty about limitations might be used by reviewers as grounds for rejection, a worse outcome might be that reviewers discover limitations that aren't acknowledged in the paper. The authors should use their best judgment and recognize that individual actions in favor of transparency play an important role in developing norms that preserve the integrity of the community. Reviewers will be specifically instructed to not penalize honesty concerning limitations.
% \end{itemize}
% \item {\bf Theory assumptions and proofs}
% \item[] Question: For each theoretical result, does the paper provide the full set of assumptions and a complete (and correct) proof?
% \item[] Answer: \answerNA{} % Replace by \answerYes{}, \answerNo{}, or \answerNA{}.
% \item[] Justification: No formal proofs or theories as contribution or supporting method.
% \item[] Guidelines:
% \begin{itemize}
% \item The answer NA means that the paper does not include theoretical results.
% \item All the theorems, formulas, and proofs in the paper should be numbered and cross-referenced.
% \item All assumptions should be clearly stated or referenced in the statement of any theorems.
% \item The proofs can either appear in the main paper or the supplemental material, but if they appear in the supplemental material, the authors are encouraged to provide a short proof sketch to provide intuition.
% \item Inversely, any informal proof provided in the core of the paper should be complemented by formal proofs provided in appendix or supplemental material.
% \item Theorems and Lemmas that the proof relies upon should be properly referenced.
% \end{itemize}
% \item {\bf Experimental result reproducibility}
% \item[] Question: Does the paper fully disclose all the information needed to reproduce the main experimental results of the paper to the extent that it affects the main claims and/or conclusions of the paper (regardless of whether the code and data are provided or not)?
% \item[] Answer: \answerYes{} % Replace by \answerYes{}, \answerNo{}, or \answerNA{}.
% \item[] Justification: We describe the methods, data, experimental setup and architecture to reproduce our results. Additionally all necessary code, model weights and data will be published.
% \item[] Guidelines:
% \begin{itemize}
% \item The answer NA means that the paper does not include experiments.
% \item If the paper includes experiments, a No answer to this question will not be perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not.
% \item If the contribution is a dataset and/or model, the authors should describe the steps taken to make their results reproducible or verifiable.
% \item Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution is a novel architecture, describing the architecture fully might suffice, or if the contribution is a specific model and empirical evaluation, it may be necessary to either make it possible for others to replicate the model with the same dataset, or provide access to the model. In general. releasing code and data is often one good way to accomplish this, but reproducibility can also be provided via detailed instructions for how to replicate the results, access to a hosted model (e.g., in the case of a large language model), releasing of a model checkpoint, or other means that are appropriate to the research performed.
% \item While NeurIPS does not require releasing code, the conference does require all submissions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example
% \begin{enumerate}
% \item If the contribution is primarily a new algorithm, the paper should make it clear how to reproduce that algorithm.
% \item If the contribution is primarily a new model architecture, the paper should describe the architecture clearly and fully.
% \item If the contribution is a new model (e.g., a large language model), then there should either be a way to access this model for reproducing the results or a way to reproduce the model (e.g., with an open-source dataset or instructions for how to construct the dataset).
% \item We recognize that reproducibility may be tricky in some cases, in which case authors are welcome to describe the particular way they provide for reproducibility. In the case of closed-source models, it may be that access to the model is limited in some way (e.g., to registered users), but it should be possible for other researchers to have some path to reproducing or verifying the results.
% \end{enumerate}
% \end{itemize}
% \item {\bf Open access to data and code}
% \item[] Question: Does the paper provide open access to the data and code, with sufficient instructions to faithfully reproduce the main experimental results, as described in supplemental material?
% \item[] Answer: \answerYes{} % Replace by \answerYes{}, \answerNo{}, or \answerNA{}.
% \item[] Justification: We will publish all code, model weights and data to reproduce all experimental results. This will be accompanied by instructions and scripts to easily accomplish reproduction. For review we provide the code in the supplementary material.
% \item[] Guidelines:
% \begin{itemize}
% \item The answer NA means that paper does not include experiments requiring code.
% \item Please see the NeurIPS code and data submission guidelines (\url{https://nips.cc/public/guides/CodeSubmissionPolicy}) for more details.
% \item While we encourage the release of code and data, we understand that this might not be possible, so “No” is an acceptable answer. Papers cannot be rejected simply for not including code, unless this is central to the contribution (e.g., for a new open-source benchmark).
% \item The instructions should contain the exact command and environment needed to run to reproduce the results. See the NeurIPS code and data submission guidelines (\url{https://nips.cc/public/guides/CodeSubmissionPolicy}) for more details.
% \item The authors should provide instructions on data access and preparation, including how to access the raw data, preprocessed data, intermediate data, and generated data, etc.
% \item The authors should provide scripts to reproduce all experimental results for the new proposed method and baselines. If only a subset of experiments are reproducible, they should state which ones are omitted from the script and why.
% \item At submission time, to preserve anonymity, the authors should release anonymized versions (if applicable).
% \item Providing as much information as possible in supplemental material (appended to the paper) is recommended, but including URLs to data and code is permitted.
% \end{itemize}
% \item {\bf Experimental setting/details}
% \item[] Question: Does the paper specify all the training and test details (e.g., data splits, hyperparameters, how they were chosen, type of optimizer, etc.) necessary to understand the results?
% \item[] Answer: \answerYes{} % Replace by \answerYes{}, \answerNo{}, or \answerNA{}.
% \item[] Justification: We provide details on the evaluation setting, evaluation parameters and training details in \Cref{sec:experiments}. This is supplemented by the published code.
% \item[] Guidelines:
% \begin{itemize}
% \item The answer NA means that the paper does not include experiments.
% \item The experimental setting should be presented in the core of the paper to a level of detail that is necessary to appreciate the results and make sense of them.
% \item The full details can be provided either with the code, in appendix, or as supplemental material.
% \end{itemize}
% \item {\bf Experiment statistical significance}
% \item[] Question: Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?
% \item[] Answer: \answerNo{} % Replace by \answerYes{}, \answerNo{}, or \answerNA{}.
% \item[] Justification: We do not provide error bars or statistical metrics of our experimental results. Considering dataset sizes, training stability and compute requirements, established practice in the field of online HD map construction relies on the number of ablations and evaluation on multiple large datasets.
% %, considering only large experimental differences as significant.
% \item[] Guidelines:
% \begin{itemize}
% \item The answer NA means that the paper does not include experiments.
% \item The authors should answer "Yes" if the results are accompanied by error bars, confidence intervals, or statistical significance tests, at least for the experiments that support the main claims of the paper.
% \item The factors of variability that the error bars are capturing should be clearly stated (for example, train/test split, initialization, random drawing of some parameter, or overall run with given experimental conditions).
% \item The method for calculating the error bars should be explained (closed form formula, call to a library function, bootstrap, etc.)
% \item The assumptions made should be given (e.g., Normally distributed errors).
% \item It should be clear whether the error bar is the standard deviation or the standard error of the mean.
% \item It is OK to report 1-sigma error bars, but one should state it. The authors should preferably report a 2-sigma error bar than state that they have a 96\% CI, if the hypothesis of Normality of errors is not verified.
% \item For asymmetric distributions, the authors should be careful not to show in tables or figures symmetric error bars that would yield results that are out of range (e.g. negative error rates).
% \item If error bars are reported in tables or plots, The authors should explain in the text how they were calculated and reference the corresponding figures or tables in the text.
% \end{itemize}
% \item {\bf Experiments compute resources}
% \item[] Question: For each experiment, does the paper provide sufficient information on the computer resources (type of compute workers, memory, time of execution) needed to reproduce the experiments?
% \item[] Answer: \answerYes{} % Replace by \answerYes{}, \answerNo{}, or \answerNA{}.
% \item[] Justification: We provide these details in \Cref{subsec:nlp_tag_embeddings}, \Cref{subsec:implementation} and \Cref{subsec:implementation_details_baseline}.
% \item[] Guidelines:
% \begin{itemize}
% \item The answer NA means that the paper does not include experiments.
% \item The paper should indicate the type of compute workers CPU or GPU, internal cluster, or cloud provider, including relevant memory and storage.
% \item The paper should provide the amount of compute required for each of the individual experimental runs as well as estimate the total compute.
% \item The paper should disclose whether the full research project required more compute than the experiments reported in the paper (e.g., preliminary or failed experiments that didn't make it into the paper).
% \end{itemize}
% \item {\bf Code of ethics}
% \item[] Question: Does the research conducted in the paper conform, in every respect, with the NeurIPS Code of Ethics \url{https://neurips.cc/public/EthicsGuidelines}?
% \item[] Answer: \answerYes{} % Replace by \answerYes{}, \answerNo{}, or \answerNA{}.
% \item[] Justification: We have reviewed and conform to the NeurIPS Code of Ethics.
% \item[] Guidelines:
% \begin{itemize}
% \item The answer NA means that the authors have not reviewed the NeurIPS Code of Ethics.
% \item If the authors answer No, they should explain the special circumstances that require a deviation from the Code of Ethics.
% \item The authors should make sure to preserve anonymity (e.g., if there is a special consideration due to laws or regulations in their jurisdiction).
% \end{itemize}
% \item {\bf Broader impacts}
% \item[] Question: Does the paper discuss both potential positive societal impacts and negative societal impacts of the work performed?
% \item[] Answer: \answerNA{} % Replace by \answerYes{}, \answerNo{}, or \answerNA{}.
% \item[] Justification: No positive/negative societal impact outside of the field of autonomous driving.
% \item[] Guidelines:
% \begin{itemize}
% \item The answer NA means that there is no societal impact of the work performed.
% \item If the authors answer NA or No, they should explain why their work has no societal impact or why the paper does not address societal impact.
% \item Examples of negative societal impacts include potential malicious or unintended uses (e.g., disinformation, generating fake profiles, surveillance), fairness considerations (e.g., deployment of technologies that could make decisions that unfairly impact specific groups), privacy considerations, and security considerations.
% \item The conference expects that many papers will be foundational research and not tied to particular applications, let alone deployments. However, if there is a direct path to any negative applications, the authors should point it out. For example, it is legitimate to point out that an improvement in the quality of generative models could be used to generate deepfakes for disinformation. On the other hand, it is not needed to point out that a generic algorithm for optimizing neural networks could enable people to train models that generate Deepfakes faster.
% \item The authors should consider possible harms that could arise when the technology is being used as intended and functioning correctly, harms that could arise when the technology is being used as intended but gives incorrect results, and harms following from (intentional or unintentional) misuse of the technology.
% \item If there are negative societal impacts, the authors could also discuss possible mitigation strategies (e.g., gated release of models, providing defenses in addition to attacks, mechanisms for monitoring misuse, mechanisms to monitor how a system learns from feedback over time, improving the efficiency and accessibility of ML).
% \end{itemize}
% \item {\bf Safeguards}
% \item[] Question: Does the paper describe safeguards that have been put in place for responsible release of data or models that have a high risk for misuse (e.g., pretrained language models, image generators, or scraped datasets)?
% \item[] Answer: \answerNA{} % Replace by \answerYes{}, \answerNo{}, or \answerNA{}.
% \item[] Justification: The model and data is based on already publicly available datasets and OpenStreetMap data without risk for misuse.
% \item[] Guidelines:
% \begin{itemize}
% \item The answer NA means that the paper poses no such risks.
% \item Released models that have a high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model, for example by requiring that users adhere to usage guidelines or restrictions to access the model or implementing safety filters.
% \item Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images.
% \item We recognize that providing effective safeguards is challenging, and many papers do not require this, but we encourage authors to take this into account and make a best faith effort.
% \end{itemize}
% \item {\bf Licenses for existing assets}
% \item[] Question: Are the creators or original owners of assets (e.g., code, data, models), used in the paper, properly credited and are the license and terms of use explicitly mentioned and properly respected?
% \item[] Answer: \answerYes{} % Replace by \answerYes{}, \answerNo{}, or \answerNA{}.
% \item[] Justification: We credit OpenStreetMap, Argoverse 2 and nuScenes for providing the experimental data.
% \item[] Guidelines:
% \begin{itemize}
% \item The answer NA means that the paper does not use existing assets.
% \item The authors should cite the original paper that produced the code package or dataset.
% \item The authors should state which version of the asset is used and, if possible, include a URL.
% \item The name of the license (e.g., CC-BY 4.0) should be included for each asset.
% \item For scraped data from a particular source (e.g., website), the copyright and terms of service of that source should be provided.
% \item If assets are released, the license, copyright information, and terms of use in the package should be provided. For popular datasets, \url{paperswithcode.com/datasets} has curated licenses for some datasets. Their licensing guide can help determine the license of a dataset.
% \item For existing datasets that are re-packaged, both the original license and the license of the derived asset (if it has changed) should be provided.
% \item If this information is not available online, the authors are encouraged to reach out to the asset's creators.
% \end{itemize}
% \item {\bf New assets}
% \item[] Question: Are new assets introduced in the paper well documented and is the documentation provided alongside the assets?
% \item[] Answer: \answerNA{} % Replace by \answerYes{}, \answerNo{}, or \answerNA{}.
% \item[] Justification: We do not use any new assets that are not already publicly available.
% \item[] Guidelines:
% \begin{itemize}
% \item The answer NA means that the paper does not release new assets.
% \item Researchers should communicate the details of the dataset/code/model as part of their submissions via structured templates. This includes details about training, license, limitations, etc.
% \item The paper should discuss whether and how consent was obtained from people whose asset is used.
% \item At submission time, remember to anonymize your assets (if applicable). You can either create an anonymized URL or include an anonymized zip file.
% \end{itemize}
% \item {\bf Crowdsourcing and research with human subjects}
% \item[] Question: For crowdsourcing experiments and research with human subjects, does the paper include the full text of instructions given to participants and screenshots, if applicable, as well as details about compensation (if any)?
% \item[] Answer: \answerNA{} % Replace by \answerYes{}, \answerNo{}, or \answerNA{}.
% \item[] Justification: No crowdsourcing or human research subjects performed in this work.
% \item[] Guidelines:
% \begin{itemize}
% \item The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.
% \item Including this information in the supplemental material is fine, but if the main contribution of the paper involves human subjects, then as much detail as possible should be included in the main paper.
% \item According to the NeurIPS Code of Ethics, workers involved in data collection, curation, or other labor should be paid at least the minimum wage in the country of the data collector.
% \end{itemize}
% \item {\bf Institutional review board (IRB) approvals or equivalent for research with human subjects}
% \item[] Question: Does the paper describe potential risks incurred by study participants, whether such risks were disclosed to the subjects, and whether Institutional Review Board (IRB) approvals (or an equivalent approval/review based on the requirements of your country or institution) were obtained?
% \item[] Answer: \answerNA{} % Replace by \answerYes{}, \answerNo{}, or \answerNA{}.
% \item[] Justification: No crowdsourcing or human research subjects performed in this work.
% \item[] Guidelines:
% \begin{itemize}
% \item The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.
% \item Depending on the country in which research is conducted, IRB approval (or equivalent) may be required for any human subjects research. If you obtained IRB approval, you should clearly state this in the paper.
% \item We recognize that the procedures for this may vary significantly between institutions and locations, and we expect authors to adhere to the NeurIPS Code of Ethics and the guidelines for their institution.
% \item For initial submissions, do not include any information that would break anonymity (if applicable), such as the institution conducting the review.
% \end{itemize}
% \item {\bf Declaration of LLM usage}
% \item[] Question: Does the paper describe the usage of LLMs if it is an important, original, or non-standard component of the core methods in this research? Note that if the LLM is used only for writing, editing, or formatting purposes and does not impact the core methodology, scientific rigorousness, or originality of the research, declaration is not required.
% %this research?
% \item[] Answer: \answerNA{} % Replace by \answerYes{}, \answerNo{}, or \answerNA{}.
% \item[] Justification: No LLM involvement.
% \item[] Guidelines:
% \begin{itemize}
% \item The answer NA means that the core method development in this research does not involve LLMs as any important, original, or non-standard components.
% \item Please refer to our LLM policy (\url{https://neurips.cc/Conferences/2025/LLM}) for what should or should not be described.
% \end{itemize}
% \end{enumerate}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\input{sec/X_suppl}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
\begin{abstract}
% The abstract paragraph should be indented \nicefrac{1}{2}~inch (3~picas) on
% both the left- and right-hand margins. Use 10~point type, with a vertical
% spacing (leading) of 11~points. The word \textbf{Abstract} must be centered,
% bold, and in point size 12. Two line spaces precede the abstract. The abstract
% must be limited to one paragraph.
%Autonomous vehicles require detailed and accurate information to behave correctly within their environment.
%Using high definition (HD) maps is a promising approach, but the required effort to maintain them is a major obstacle to scalable autonomous driving.
%Online HD map construction aims to solve this issue by perceiving local HD maps from live sensor data, but is therefore limited in perception range.
%To boost HD map construction performance% in the far range
%, recent approaches have proposed to use standard definition (SD) maps which are much easier to maintain.
Autonomous vehicles rely on detailed and accurate environmental information to operate safely.
High definition (HD) maps offer a promising solution, but their high maintenance cost poses a significant barrier to scalable deployment.
This challenge is addressed by online HD map construction methods, which generate local HD maps from live sensor data.
% Online HD map construction methods address this challenge by generating local HD maps from live sensor data.
%To address this, online HD map construction methods generate local HD maps from live sensor data.
However, these methods are inherently limited by the short perception range of onboard sensors.
To overcome this limitation and improve general performance, recent approaches have explored the use of standard definition (SD) maps as prior, which are significantly easier to maintain.
We propose SDTagNet, the first online HD map construction method that fully utilizes the information of widely available SD maps, like OpenStreetMap, to enhance far range detection accuracy.
Our approach introduces two key innovations.
First, in contrast to previous work, we incorporate not only polyline SD map data with manually selected classes, but additional semantic information in the form of textual annotations.
In this way, we enrich SD vector map tokens with NLP-derived features, eliminating the dependency on predefined specifications or exhaustive class taxonomies.
%In this way, we enhance SD vector map tokens with NLP embeddings, removing the need for structure, completeness, or closed-category definitions.
%Second, we introduce a point-level SD map encoder together with orthogonal element identifiers to acquire the flexibility of integrating additional types of map elements.
Second, we introduce a point-level SD map encoder together with orthogonal element identifiers to uniformly integrate all types of map elements.
Experiments on Argoverse~2 and nuScenes show that this boosts map perception performance by up to +5.9~mAP (+45\%) w.r.t.\ map construction without priors and up to +3.2~mAP (+20\%) w.r.t.\ previous approaches that already use SD map priors.
\href{https://github.com/immel-f/SDTagNet}{\textnormal{\texttt{https://github.com/immel-f/SDTagNet}}}
\end{abstract}
\section{Introduction}
\label{sec:introduction}
\begin{figure}
%\hspace*{-1cm}
\centering
\includegraphics[trim={0cm 0.4cm 0cm 0cm},clip,width=0.95\linewidth]{pics/sdtagnet_overview_v2_1.pdf}
\caption{Overview of the model architecture of SDTagNet. To fully exploit textual annotations and all element types in large public SD map databases like OpenStreetMap~\cite{OpenStreetMap}, SDTagNet introduces novel NLP tag embedding and SD map encoder modules. Text annotation embeddings are first computed with a BERT~\cite{devlin-etal-2019-bert} embedding model. They are then fused with scene-level context in a SD map encoder, which uses graph transformer-like methods to flexibly encode points, polylines and element relations. The encoded information is finally supplied to the base model via cross-attention.}
\label{fig:sdtagnet_overview}
\end{figure}
Autonomous vehicles require a variety of information about their static environment to drive safely.
This information is usually provided in form of high definition (HD) maps that contain highly accurate and detailed lane-level road geometry, traffic lights, road signs, traffic rules, \etc
The extension of self-driving fleets to larger and larger areas showed that the creation and maintenance of HD maps requires a huge amount of computational and manual effort, hence, posing a major obstacle for scalable autonomous driving.
To overcome this issue, a variety of approaches have proposed to construct or perceive HD maps online from onboard sensor data~\cite{HDMapNet,maptr,maptrv2}.
Online HD map construction has the downside of being limited by the range and coverage of onboard sensors.
A variety of prior information and representations can be used to mitigate this restriction and improve performance especially in the long range and for occluded areas.
These priors can include data from previously visited scenes~\cite{xiong2023neuralmapprior, zhang2024hrmapnet, shi2024globalmapnetonlineframeworkvectorized, yang2025histrackmapglobalvectorizedhighdefinition} as well as data from existing prior maps~\cite{sun2024mapex, immel2025m3trgeneralistmodelrealworld, jiang2024pmapnet, luo2023augmentingSMERF, yang2024toposdtopologyenhancedlanesegment}.
This prior map data is usually provided in the form of dense grids, sparse vectorized graph representations, or both~\cite{zeng2024unifiedvectorpriorencoding} with different levels of richness.
Using HD maps as priors only partially alleviates the issues of their creation and maintenance and raises new issues like map change detection~\cite{av2_trust_but_verify}.
In contrast, standard definition (SD) maps, currently used for navigation and routing, have a far lower demand on accuracy and level of detail, hence, reducing the maintenance effort by orders of magnitude. This motivates the use of SD maps as prior for online HD map construction.
With OpenStreetMap~\cite{OpenStreetMap}, crowd-sourced SD map data is freely available on a global scale and kept up-to-date by a community of volunteers.
As we show in this work, existing approaches for incorporating SD map priors do not fully utilize all valuable data contained in OpenStreetMap, but are restricted to dense or sparse representations of a subset of so-called \textit{ways}, \ie polylines of roads and streets, associated with only a few selected tagged text attributes~\cite{jiang2024pmapnet,luo2023augmentingSMERF, zeng2024unifiedvectorpriorencoding}.
While these selective, manual SD map features already show great improvements, OpenStreetMap also contains point-level \textit{nodes}, abstract \textit{relations}, and a huge amount of additional textual information annotated to its map elements.
To the best of our knowledge, this majority of SD map data has not yet been used to boost online HD map construction performance.
\paragraph{Contributions}
We present SDTagNet, an SD map prior encoding module that can fully utilize \textit{all} information in SD maps, including text annotations, without manual feature engineering.
Specifically:
\begin{itemize}
\item We increase the SD map element encoder query resolution from polyline-level to point-level, allowing for greater expressiveness by additional integration of point map elements.
\item We complement it with explicit orthogonal random feature element identifiers used in graph transformers~\cite{tokengt2022nips}, effectively encoding points, polylines and relations in a joint fashion.
\item We propose to use a BERT~\cite{devlin-etal-2019-bert} natural language processing (NLP) encoder and contrastive pretraining to create NLP tag embeddings and hence utilize the entirety of textual annotations in addition to geometric element features in an end-to-end trainable manner.
\item Evaluation on Argoverse~2 and nuScenes shows that SDTagNet outperforms existing SD map prior encoding modules by up to 20\% and 35\%, respectively, especially at far range.
% Jan: Dass wir keine geosplits nehmen und centerlines evaluieren ist ein Detail das ich erst in die EVal bringen würde. Hier hat m.E. keiner ein Verständnis dafür.
\end{itemize}
% \begin{itemize}
% \color{Mulberry} % draft notes
% \item maybe a cool introductory image here would be one like from the lunch club presentation with a one way road that SDTagNet can detect correctly, contrary to SMERF
% \item Standard stuff about HD maps and online map perception, lead up to navigation maps as priors
% \item Variety of existing approaches for using SD map prior information, but they have shortcomings:
% \item SD/OSM maps contain a lot of information in the form of natural language annotations and nodes + relations that is completely unused
% \item Manual feature engineering for SD map element classes
% \item SD map encoder architectures not aligned with map perception transformer decoder
% \item therefore we present SDTagNet, a SD map prior encoding module that can fully utilize all information in SD maps,
% including text annotations for elements without task-specific manual feature engineering.
% \item SDTagNet also introduces architectural improvements like a point-level query design better aligned with vectorized map perception transformers and explicit node/element identifiers from graph transformers
% \item SDTagNet outperforms existing SD map prior encoding modules, especially in far range settings
% \item Random other thing: SDTagNet also first method to do proper geo split evaluation for standard vectorized map perception (PMapNet no geo split and others only on Openlanev2)
% \item generally most SD map prior stuff was on openlanev2, which due to centerlines only task offers less insight (this can also be seen in our evaluation results)
% \end{itemize}
% \color{black} % draft notes
\section{Related Work}
\label{sec:related_work}
%Our approach relates both to the general task of online HD map construction and to recent methods that incorporate map priors such as SD maps to enhance perception.
\paragraph{Online HD Map Construction}
\label{subsec:online_hd_map_construction}
HDMapNet~\cite{HDMapNet} pioneered in defining the task of online HD map construction, \ie to predict a set of vectorized map instances represented as polygons and polylines in a 2D BEV grid, and proposed to solve it by inferring from intermediate semantic segmentation outputs in a heuristic postprocessing step.
%
Subsequent works, including VectorMapNet~\cite{vectormapnet} and MapTR~\cite{maptr}, transitioned from this multi-stage pipeline to an end-to-end formulation using DETR-style transformers \cite{DETR_2020ECCV} for direct vectorized map instance prediction.
While VectorMapNet adopts an autoregressive decoding strategy, MapTR accelerates inference through a hierarchical bipartite matching mechanism with a fixed number of points per instance.
%
MapTRv2~\cite{maptrv2} further advances the architecture by introducing auxiliary supervision, reformulating the point-to-point matching process, and integrating a one-to-many query design to improve both detection performance and convergence.
%
It has since become a baseline architecture for many follow-up research directions~\cite{chen2024maptracker, choi2024mask2map, Zhou_2024_CVPR}. % Yuan_2024_streammapnet
%{\color{Turquoise} It has since become a baseline architecture for many follow-up research directions, such as extending the single shot detection to a multiframe or tracking task \cite{chen2024maptracker, Yuan_2024_streammapnet}, as well as incorporating shape prior of map elements in the query representation \cite{choi2024mask2map, Zhou_2024_CVPR}.}
\paragraph{Priors for Online HD Map Construction}
\label{subsec:sd_map_prior_online_hd_map_construction}
% Earlier approaches \cite{HDMapNet, vectormapnet, maptr} define 30 meters in longitudinal and 15 meters in lateral direction as standard range and on-board sensors as default input for detecting map elements.
%
%However,
Recent work seeks to improve detection quality and range by integrating
% by integrating data from additional sensors \cite{dong2022SuperFusion},
information from previously recorded scenes~\cite{xiong2023neuralmapprior, zhang2024hrmapnet, shi2024globalmapnetonlineframeworkvectorized,yang2025histrackmapglobalvectorizedhighdefinition} or existing HD and SD maps~\cite{sun2024mapex,immel2025m3trgeneralistmodelrealworld,jiang2024pmapnet,luo2023augmentingSMERF,yang2024toposdtopologyenhancedlanesegment}.
%
% Information from previously visited scenes can either consist of recently recorded temporal information, e.g. MapTracker~\cite{chen2024maptracker} reformulates the task as a recursive tracking problem, or maintained and updated in a global map prior data base \cite{xiong2023neuralmapprior}.
Information from previously visited scenes can either consist of recently recorded temporal information, \eg in \cite{chen2024maptracker, Yuan_2024_streammapnet}, or maintained and updated in a global map prior data base~\cite{xiong2023neuralmapprior}.
%
%A prominent example of the latter is NeuralMapPrior \cite{xiong2023neuralmapprior}, which integrates local patches of a global neural map representation in the inference of online local maps.
%
In addition to temporal memory, many real-world autonomous systems have access to pre-built maps ranging from SD maps
%{\color{Turquoise}, usually consisting of a center-line skeleton of the road topology used for navigation,}
to HD maps for tasks such as path planning~\cite{Elghazaly2023hdmapsurvey}.
%
% Recent online map prediction approaches incorporate these as priors to complement incomplete or outdated maps \cite{sun2024mapex}, which are already in the target definition, or lift simple, sparse SD maps to the target HD map representation.
Recent online map prediction approaches incorporate these as priors to complement incomplete or outdated maps~\cite{sun2024mapex, immel2025m3trgeneralistmodelrealworld}.
%
Among early works, MapEX~\cite{sun2024mapex} introduced a mechanism to directly fuse existing HD map elements as embedded query tokens with classic learned queries and online sensor data.
%with classic learned queries to be decoded along with online sensor data yielding map instance predictions.
%
%M3TR \cite{immel2025m3trgeneralistmodelrealworld} continues this line of work by exploiting query embeddings and the training regime to produce a single generalist model able to incorporate semantically diverse priors resulting from varying degradation scenarios of outdated maps.
M3TR~\cite{immel2025m3trgeneralistmodelrealworld} continues this line of work by exploiting query embeddings and training regimes to incorporate semantically diverse priors resulting from varying map degradation scenarios.
%
Concerning SD maps, PMapNet~\cite{jiang2024pmapnet} rasterizes OpenStreetMap (OSM)~\cite{OpenStreetMap} road graphs into images and aims to predict an HD map around it with online sensor information and a pre-trained HD map prior module trained to capture the distribution and structure of the target HD map representation.
%
In contrast, SMERF~\cite{luo2023augmentingSMERF} converts OSM-based SD maps into a sequence of polyline instances representing a fixed set of seven semantic road types and encodes them with a transformer module.
%As in \cite{jiang2024pmapnet}, information that does not match the pre-defined classes is discarded.
% A sinusoidal embedding is applied to the polylines using varying frequencies to make the embeddings more sensitive to positional variations.
%
Furthermore, TopoSD~\cite{yang2024toposdtopologyenhancedlanesegment} proposes a hybrid approach, encoding existing SD maps into both 2D feature grids and a set of vectorized instance tokens. As in SMERF~\cite{luo2023augmentingSMERF}, these are fused with BEV features from sensor data using a BEVFormer-style encoder~\cite{li2022bevformer} with cross-attention.
%
Despite these advances, all of the above use only a subset of available SD map content by hand-selecting attributes.
%
%
%Long-range Mpa Perception: SuperFusion \cite{dong2022SuperFusion} archives up to 90m forward-view map perception by inc operating lithium points alongside the camera indices.
%y maintaining a global neural map prior data base, NeuralMapPrior can boost close-range and in particular far range map perception.
%MapTracker[] reformulates the task as a recursive tracking problem wehre the previous inferred map can also be seen as a prior for the map construction of the current
% \begin{itemize}
% \color{Mulberry} % draft notes
% \item Here discuss SD map prior methods
% \item Two main types: Prior as extra rendered BEV image (PMapNet \cite{jiang2024pmapnet}) or prior encoding from vectorized via transformer tokens (SMERF \cite{luo2023augmentingSMERF})
% \item Additionally TopoSD \cite{yang2024toposdtopologyenhancedlanesegment} which fuses both image and vectorized but very similar to SMERF and so far arxiv only
% \item weaknesses would be mostly repeat from introduction, maybe focus here on details of smerf like one token per polyline, not point
% \item probably should also just only discuss weaknessess in Method section like in M3TR and only describe methods here
% \end{itemize}
%notes
%incorperating map priors
%OpenStreetMpa encode it as conditioning branch
%An attention mechanism is implemented to
%Standard Definition Maps (SDMaps) have been used for navigation. Usaly provide a center-line skeleton of the road topology.
%Using OSM maps with Argoverse dta set provides weakly algined SD maps (see PMAPNET) PMAPNET laso underliens the particular usefulnes of SdMap prior for the far-seeing HDMap generation and for crossings with repetitive road patterns.
\section{Method}
\label{sec:method}
An overview of SDTagNet is shown in \Cref{fig:sdtagnet_overview}.
Beginning with an introduction of annotations in SD maps (\Cref{subsec:annotations_in_sd_maps}), we describe the two main components of SDTagNet: The NLP tag embedding module (\Cref{subsec:nlp_tag_embeddings}) and the SD map encoder (\Cref{subsec:sd_map_encoder}).
\subsection{Annotations in SD Maps}
\label{subsec:annotations_in_sd_maps}
A key challenge in leveraging standard-definition (SD) maps for online HD map construction lies in understanding the spectrum between SD map and HD map representations.
This distinction can be broken down into three main aspects.
First, SD maps are less accurate and have lower resolution compared to HD maps, usually in the range of meters compared to centimeters.
Like other works in this area \cite{jiang2024pmapnet, luo2023augmentingSMERF}, we assume that the SD map is roughly localized close to the target HD map and let remaining inaccuracies be compensated by the network during training.
Second, SD maps are often considered sparse in content, with previous approaches only considering roads, \eg by filtering for the \texttt{highway} tag in OpenStreetMap~(OSM).
However, as shown in \Cref{fig:input_comparison}, SD maps like those widely available from the OSM~\cite{OpenStreetMap} project contain many more kinds of elements.
%As illustrated in \Cref{fig:input_comparison}, existing methods neglect that SD maps, such as those made widely available by the OSM project~\cite{OpenStreetMap}, contain many more kinds of elements.
They contain points like traffic lights, bus stops, traffic signs, \etc as well as many ways beyond roads, like pedestrian paths, building borders, \etc.
Virtual elements, so-called relations, even denote semantic or topological links between two elements, \eg that no left turns are allowed.
Finally, there is a wide variety of descriptive text information annotated to many of those elements.
This valuable knowledge remains unexploited for online HD map construction.
For instance, OSM maps contain so-called \textit{tags}, \ie key-value pairs, such as \texttt{name:~Park Avenue}, \texttt{oneway:~yes}, or \texttt{lanes:~2}.
The last two examples already show that the textual information is highly informative for the task of online HD map construction.
In total, at the point of writing, the global OSM map contains around 100k different keys and 168M values.
This vast amount of tags as well as their unstructured nature obviously cannot be exploited by handcrafted methods.
Instead, we propose an NLP encoder to optimally interpret the full information contained in SD maps for the goal of HD map construction.
%\Cref{fig:input_comparison} illustrates this difference by visualizing the input information used by the existing SD map prior methods PMapNet~\cite{jiang2024pmapnet} and SMERF~\cite{luo2023augmentingSMERF}.
% A large amount of information is left unused due to the limited expressivity of the handcrafted input features.
%Instead, we propose an NLP encoder to optimally interpret the full information contained in SD maps for the goal of HD map construction.
\subsection{NLP Tag Embeddings}
\label{subsec:nlp_tag_embeddings}
Our proposed NLP encoder takes inspiration from the area of sentence embedding in natural language processing and can generate open-vocabulary embeddings for arbitrary textual annotations.
% This makes SDTagNet the first method that can exploit all information present in largely unstructured, crowd-sourced map databases such as OpenStreetMap~\cite{OpenStreetMap}.
By adopting training paradigms from sentence embedding, we require no extra labels for the encoder and pre-train it in a fully self-supervised manner.
Moreover, this makes the pre-training completely task-agnostic, meaning the pre-trained encoder can in principle be used in any application which desires embeddings of textual SD map annotations, not just the area of online HD map perception.
For the embedding model we choose the compact and well-studied BERT \cite{devlin-etal-2019-bert} architecture.
SD map annotations are of considerably less complexity than the paragraphs of prose text normally used in sentence embedding, which renders large language models or other large embedding models unnecessary.
A small model like BERT also enables us to run the encoder module in real time with the main online HD map perception model.
The embedding dimension of the encoder is 144, with the \texttt{[CLS]} token selected as the tagset embedding, and one embedding is computed per SD map element.
\begin{figure}
%\hspace*{-1cm}
\centering
\includegraphics[trim={0cm 0cm 0cm 0cm},clip,width=\linewidth]{pics/input_comparison_jp.pdf}
\caption{Visualization of the SD map prior input data utilized by existing methods.
Existing approaches are limited to rasterized images or polylines with manually defined classes.
SDTagNet is the first method that can handle open-vocabulary textual annotations and
diverse element types such as points, polylines, and relational information.}
\label{fig:input_comparison}
\end{figure}
\paragraph{Contrastive Pretraining Objective}
\label{subsubsec:contrastive_pretraining_objective}
Common practice in natural language processing relies heavily on pre-trained large models that are then optionally finetuned for different use cases.
However the data in SD map text annotation differs strongly from the text corpus for existing pre-trained sentence embedding models.
The text consists of a list of keywords rather than complete sentences and, contrary to general requirements for sentence embeddings, small changes in the text should make a big difference in the embedding.
For example, a tagset with the tag \texttt{lanes:~2} should have a substantially different embedding from \texttt{lanes:~3}, even though only one letter changed.
Since a very large dataset for the use case exists as well with OpenStreetMap~\cite{OpenStreetMap}, we decided to train our embedding model from scratch.
This also affords us more control of model hyperparameters such as embedding size and is necessary for reaching real-time performance.
For our pre-training we adapt established methods and design a self-supervised contrastive learning objective based on the multiple negatives ranking loss \cite{gao-etal-2021-scaling}.
Our customized objective is motivated by the fact that many annotation artifacts and semantically irrelevant tags exist in crowdsourced maps.
For instance, many elements in OSM contain IDs and other cataloging information of national geodetic reference systems that are not informative for a downstream task.
Our customized loss forces the model to ignore these irrelevant tags, which we identified using the main OSM tag database.
% , for the computed embeddings.
\Cref{fig:contrastive_loss_expl} shows an example of a training batch for the customized loss.
Using the dataset of all unique tagsets from the OpenStreetMap planet map, the goal of the model is to minimize the distance of two tagsets with the same semantically meaningful tags while maximizing the distance towards other tagsets.
A large batch size of negative samples is needed to keep the training stable \cite{gao-etal-2021-scaling}, 5120 in our case.
We randomly sample 20 pairs of positive samples per unique relevant tagset for the training data and choose a training time of 4 epochs to ensure convergence.
To facilitate further research in this area, the pre-trained encoder together with the extracted OSM annotation dataset used for training will be released alongside the main model.
\begin{figure}
%\hspace*{-1cm}
\centering
%\includegraphics[trim={0cm 0cm 0cm 0cm},clip,width=0.6\linewidth]{pics/contrastive_loss_expl_wide.pdf}
\includegraphics[trim={0cm 0cm 0cm 0cm},clip,width=\linewidth]{pics/contrastive_loss_expl_extra_wide.pdf}
\caption{Example of the tag embedding contrastive pretraining objective. A positive sample is selected from tagsets with the same semantically meaningful tags, but different not meaningful ones (like the street name). Negative samples are selected from all other unique tagsets. The number of negative samples in practice is much larger than depicted here to prevent unstable training. }
\label{fig:contrastive_loss_expl}
\end{figure}
\subsection{SD Map Encoder}
\label{subsec:sd_map_encoder}
Following the NLP tag embedding, the SD map encoder combines these embeddings with the associated points and the scene-level context through a transformer module.
The SD map encoder module is based on the architecture proposed by SMERF~\cite{luo2023augmentingSMERF}, however with key changes that significantly improve performance in the online HD map construction task and allow for much more flexibility in its input representation.
% The architecture of SDTagNet is furthermore much more flexible, in principle capable of representing arbitrary graphs in its input, enabling the capture of all information and element types contained in SD maps.
A detailed visualization of the SD map encoder design with all its components can be found in \Cref{fig:pt_enc_detail}.
All changes are investigated individually in \Cref{subsec:performance} and \Cref{subsec:ablation_studies} and we show that their combined application significantly increases performance.
% \begin{itemize}
% \color{Mulberry} % draft notes
% \item After NLP tag embedding module SD map encoder combines embeddings with the map feature locations and scene-level context through a transformer
% \item Base architecture is from SMERF, however with key changes that significantly improve performance in the vectorized HD map construction task
% \item Additionally, compared to SMERF SDTagNet has a highly flexible encoder architecture that can represent arbitrary graphs and capture all information contained in OSM maps
% \end{itemize}
\paragraph{Point Level Queries}
\label{subsubsec:point_level_queries}
% The first key difference lies in the query tokens.
In SMERF~\cite{luo2023augmentingSMERF}, one query token represents one polyline, which is misaligned with the detection transformer architectures in HD map construction, that use one detection query for each point instead \cite{maptr, maptrv2, chen2024maptracker, choi2024mask2map, Yuan_2024_streammapnet}. To align the token design, we choose one query token per point. This also has the benefit of an easier introduction of additional element types of points and relations.
As all polyline elements in vectorized HD map construction architectures are detected with a fixed point number, we also resample all SD map polylines to the fixed point number of 10.
%, similar to the 11 points used in SMERF~\cite{luo2023augmentingSMERF}.
Furthermore, we adopt the sin/cos positional encoding for point coordinates from SMERF~\cite{luo2023augmentingSMERF} in our encoder and concatenate the tag embedding of the respective map element to it.
%
% The sin/cos positional encoding for point coordinates from SMERF~\cite{luo2023augmentingSMERF} is also adopted in our encoder and the tag embedding of the respective map element is concatenated to it for the point query.
\begin{figure}
%\hspace*{-1cm}
\centering
\includegraphics[trim={0cm 0cm 0cm 0cm},clip,width=0.75\linewidth]{pics/pt_enc_detail_with_expl.pdf}
\caption{Detailed design of the SD map encoder and its queries. Each point query is composed of the positional sin/cos encoding of the point, the respective tag embedding and orthogonal random features (ORF)~\cite{orf2016nips} that function as element identifiers and can model graph edges.}
\label{fig:pt_enc_detail}
\end{figure}
\paragraph{ORF Element Identifiers}
\label{subsubsec:element_identifiers}
While point-level queries better align the element representations and provide additional flexibility, they introduce a problem: Without additional changes, context for the model is lost as to which element a point belongs to, \eg in the case of polyline features.
We resolve this issue by taking inspiration from the field of graph transformers, where \cite{tokengt2022nips} show orthogonal random features (ORF) to be strong identifier features in the context of graph nodes and edges.
Following \cite{tokengt2022nips} and \cite{orf2016nips}, we retrieve ORF features from the rows of the random orthogonal matrix $\mathbf{Q} \in \mathbb{R}^{n \times n}$, created from the QR decomposition of a random Gaussian matrix $\mathbf{G} \in \mathbb{R}^{n \times n}$.
Each element is then assigned one ORF feature as its identifier, also visualized in \Cref{fig:pt_enc_detail}.
As in \cite{tokengt2022nips}, graph nodes, or in our case, point features and polyline features, have the same ORF feature vector stacked twice in their query.
Points are represented as a single query of the SD map encoder with two identical ORF identifiers, a tag embedding, and positional encoding.
Polylines are represented by a list of multiple point-like queries that all share the same two identical ORF identifiers.
Relations are represented using pairs of ORF identifiers, each corresponding to one of the members of a relation edge, as done traditionally in graph-structured data with node IDs.
This simple graph representation method for the SD map encoder is therefore not only a identifier for map element context, but also vastly broadens the element types that can be used for prior information.
% \begin{itemize}
% \color{Mulberry} % draft notes
% \item with point-level queries we now need an identifier for the model to not lose the context of which element a point belongs to
% \item we chose orthogonal random features (ORF) from the field of graph transformers, which are n orthogonal vectors of dimension n obtained from decomposition of a random n x n matrix (Here include formulas from graph transformer paper)
% \item additional advantage: with orf it is now possible to represent relation edges and other graph type features in the encoder
% \item \Cref{fig:pt_enc_detail} shows sd map encoder design and detailed query composition
% \item each point query contains sin/cos encoded osm point (like smerf), the nlp tag embedding of the element and the ORF identifiers
% \item For each point / polyline feature there is one ORF vector and the points belonging to the feature have that vector stacked twice in the query (see 1, 2, 3 in \Cref{fig:pt_enc_detail})
% \item For relations, which are in essence graph edges, we have no point info (zero padding), the nlp embedding and now the ORF identifers of the two features the relation connects (e.g. 1->3, 2->3 in \Cref{fig:pt_enc_detail}). This is the same way edges are represented in the original graph transformer paper
% \end{itemize}
\paragraph{Connection with Map Decoder}
\label{subsubsec:map_decoder_connection}
There exist many possible ways to supply the encoded prior information to the main online HD map construction model, ranging from fusion with the BEV features to direct supply to the map decoder.
We follow the approach of PMapNet~\cite{jiang2024pmapnet}, which uses an additional cross-attention layer in the map decoder as the supply modality.
Compared to other approaches such as concatenation to the image BEV features, cross-attention is more expressive and can compensate spatial alignment issues better, resulting in the best performance in \cite{jiang2024pmapnet}.
% \begin{itemize}
% \color{Mulberry} % draft notes
% \item We show later in experiments that the combination of all these changes significantly increases performance compared to baseline SMERF
% \item we supply the SD map feature embeddings to the transformer decoder via cross-attention so the model can learn itself which detection query needs to focus on which prior element
% % \item original SMERF uses BEV cross attention within BEVFormer instead, however this is not possible with our chosen base architecture MapTRv2
% \end{itemize}
\section{Experiments}
\label{sec:experiments}
We evaluate our method on the Argoverse 2~\cite{Argoverse2} and nuScenes~\cite{nuscenes} datasets, viewing Argoverse 2 as the main dataset for evaluation.
We discuss our selected datasets and metric in \Cref{subsec:datasets_metric} and the implementation and baselines in \Cref{subsec:implementation}.
\Cref{subsec:performance} contains the performance results of SDTagNet in comparison with existing methods and ablation studies to assess the contributions of individual components in the SD map encoder. More detailed ablation studies regarding the optimization strategies applied to the NLP tag embedding module and fine-tuning training regimes can be found in \Cref{subsec:ablation_studies}.
% \subsection{Tag Encoder Pretraining}
% \label{subsec:tag_encoder_pretraining}
% \begin{itemize}
% \color{Mulberry} % draft notes
% \item To be honest I am not 100 \% sure what to write here, as I never did any explicit evaluation of only the pretrained encoder model
% \item only thing I have are pretraining losses and similiarity vectors for sample data like in the lunchclub slides, but I think this is something more for the supplementary material if at all
% \item This section could also just describe the general pretraining process and hyperparameters, but then it could also just be moved to the supplementary material, especially if we don't have enough space
% \end{itemize}
\subsection{Datasets and Metric}
\label{subsec:datasets_metric}
% \begin{itemize}
% \color{Mulberry} % draft notes
% \item Evaluated on Argoverse 2 and nuScenes, with Argoverse 2 being the main dataset (here also a sentence with reasoning similar to M3TR)
% \item Near (60m x 30m) and far range (120m x 60m) settings, as especially in far range visibility in camera images is much less and SD map features have more impact. Far range setting also focus of many other works like \cite{jiang2024pmapnet, Yuan_2024_streammapnet} and important for comfortable driving (I think there is one random paper from Sahin \cite{tas2018iv} about that if we want to cite something here)
% \item Standard mAP metric with thresholds 0.5 m, 1 m and 1.5 m
% \item geo split from \cite{Lilja2024CVPR} for all experiments, this is also something that \cite{jiang2024pmapnet} and \cite{luo2023augmentingSMERF} do not do.
% \item Especially with prior-using models geo-split is very important, as there is even stronger information available (the SD map prior), to overfit the model to specific locations
% \item this also mirrors findings during our training that models with SD map prior exhibit stronger overfitting on training data than the maptrv2 base
% \item SD map data extracted from OSM for relevant areas
% \end{itemize}
% We train and evaluate SDTagNet and all baselines using the geographically non-overlapping splits proposed by~\cite{Lilja2024CVPR} to show the untainted performance of our approach.
To show the untainted performance of our model, we train and evaluate SDTagNet and all baselines on the geographically non-overlapping split proposed by~\cite{Lilja2024CVPR}.
We put a focus on the more recent Argoverse~2 dataset since it is significantly larger than nuScenes (158k vs. 30k samples) and has -- to our experience -- more accurate maps.
As ground truth HD maps, we use recently published labels~\cite{immel2025m3trgeneralistmodelrealworld} that contain topologically relevant centerline paths from \cite{lanegap} as well as semantically more challenging solid and dashed dividers, and correct many consistency errors in the original labels~\cite{chen2024maptracker}.
Additionally, as SD maps, OpenStreetMap data corresponding to the frame-wise local HD map label is extracted from the planetary OSM database.
We provide this data as SD map prior in two evaluation ranges for online HD map construction: near range (\SI{60}{\meter} $\times$ \SI{30}{\meter}) and far range (\SI{120}{\meter} $\times$ \SI{60}{\meter}), making sure to include all SD map elements that intersect that area.
To the best of our knowledge, no previous method that evaluates on the increasingly important far range setting with a geographically disjoint train/val split~\cite{jiang2024pmapnet, Yuan_2024_streammapnet} combines these important evaluation settings. Comparing \Cref{tab:eval_av2_original_split} of \Cref{subsec:av2_original_split} with \Cref{tab:eval_av2} shows that SD priors aggravate the localization overfit observed by~\cite{Lilja2024CVPR} when train and evaluation data overlaps geographically.
We assume that this is due to the additional leaked information available to the network when using SD maps as prior.
%Motivated by higher speed scenarios and increased comfort~\cite{tas2018iv} the far range evaluation highlights the impact of SD map priors, due to the decreased effective camera resolution, viewing angle and higher ground surface occlusion probability.
All evaluation is carried out with the standard mean Average Precision (mAP) metric with 0.5, 1.0 and 1.5 meters thresholds for the Chamfer distance.
This matches the standard mAP metric used by our baseline architecture~\cite{maptrv2}.
% This result validates the choice of our experimental setup.
\subsection{Implementation Details and Baselines}
\label{subsec:implementation}
Our baseline SD map encoding approaches are the two recent works PMapNet~\cite{jiang2024pmapnet} and SMERF~\cite{luo2023augmentingSMERF} that represent the two general existing approaches towards SD map encoding: Rasterization into a BEV image in the case of PMapNet~\cite{jiang2024pmapnet} and encoding of the vectorized polylines via a transformer module in the case of SMERF~\cite{luo2023augmentingSMERF}.
To minimize the influence from other priors like temporal information, we select the popular single-shot architecture MapTRv2~\cite{maptrv2} as a base model.
%We additionally use the richer and improved ground truth of M3TR~\cite{immel2025m3trgeneralistmodelrealworld} that contains the centerline paths from \cite{lanegap} as well as solid and dashed dividers.
For fair comparison, all SD map encoder modules have been ported to the MapTRv2 base architecture, thus isolating any performance differences to the SD map encoder module.
All models are trained on 4 H100 Nvidia GPUs for 24 epochs on Argoverse 2 and 110 epochs for nuScenes.
Both baselines are evaluated in two settings: With their original input data settings and with all information that is available in the OSM map, to the extent that the encoding method permits its integration.
For PMapNet~\cite{jiang2024pmapnet}, we add the more detailed road label classes from SMERF to the raster image and for SMERF~\cite{luo2023augmentingSMERF} we introduce node features that are not used in the original work.
This additionally eliminates any differences between available input data and compares SDTagNet with the fairest versions of existing SD map encoding methods. A detailed discussion of baseline implementation details and hyperparameters can be found in \Cref{subsec:implementation_details_baseline}.
\subsection{Online HD Map Construction Performance}
\label{subsec:performance}
In this section we first discuss our results on Argoverse 2 and nuScenes in the near range and far range setting in comparison with previous work.
We also present ablation studies that show the effectiveness of the proposed architectural changes and NLP tag embedding module.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{table*}
\centering
\caption{Comparison of SD map prior encoding methods on Argoverse 2~\cite{Argoverse2}, with the geographical split of~\cite{Lilja2024CVPR}.
*: With the 7 classes from \cite{luo2023augmentingSMERF} in the input features, which are not used in the original work.
\textdagger: With OSM nodes in the input features, which are not used in the original work. All models are trained for 24 epochs.}
\setlength\dashlinedash{1.2pt}
\setlength\dashlinegap{2.0pt}
\setlength\arrayrulewidth{0.3pt}
\resizebox{0.93\linewidth}{!}{%
\begin{tabular}{l wr{1.0cm} wr{1.0cm} wr{1.0cm} wr{1.0cm} wr{1.0cm} wr{1.0cm} wr{1.0cm}}
\toprule
%
\small{\textit{Dataset: Argoverse 2}} &
\multicolumn{7}{c}{\textbf{Near Range} \textit{(60 m $\times$ 30 m)}} \\
\cmidrule{2-8}
\textbf{Method} & $\textbf{AP}_{\textbf{dsh}}$ & $\textbf{AP}_{\textbf{sol}}$ & $\textbf{AP}_{\textbf{bou}}$ & $\textbf{AP}_{\textbf{cen}}$ & $\textbf{AP}_{\textbf{ped}}$ & $\textbf{mAP}$ & vs. \cite{maptrv2}\\
\vspace{-0.35cm} \\ \toprule
%
MapTRv2~\cite{maptrv2} & 37.9 & 55.0 & 49.7 & 48.2 & 41.7 & 46.5 & - \\
\quad + PMapNet~\cite{jiang2024pmapnet} & 36.7 & \textbf{55.4} & 49.7 & 49.5 & 43.3 & 46.9 & \textcolor{Gray}{+0.4} \\
\quad + PMapNet*\cite{jiang2024pmapnet} (all info.) & \textbf{39.4} & 54.6 & 50.6 & 47.6 & 42.7 & 47.0 & \textcolor{Gray}{+0.5} \\
% \quad + SMERF~\cite{luo2023augmentingSMERF} & 37.0 & 55.0 & 50.5 & 48.9 & 41.6 & 46.6 & \textcolor{Gray}{+0.1} \\
\quad + SMERF~\cite{luo2023augmentingSMERF} & 39.4 & 54.9 & 49.4 & 49.0 & 39.0 & 46.3 & \textcolor{Gray}{-0.2} \\
\quad + SMERF\textsuperscript{\textdagger}~\cite{luo2023augmentingSMERF} (all info.) & 38.0 & 54.4 & 50.0 & 48.5 & 38.2 & 45.9 & \textcolor{Red}{-0.6} \\
% \quad + \textbf{SDTagNet\textsuperscript{\ddagger}} (ways only) & 36.6 & 54.7 & 49.7 & 47.4 & 39.8 & 45.6 & \textcolor{Red}{-0.9} \\
\quad + \textbf{SDTagNet} & 36.0 & 55.2 & \textbf{53.3} & \textbf{52.6} & \textbf{43.3} & \textbf{48.1} & \textcolor{Green}{\textbf{+1.6}} \\
\midrule
&
\multicolumn{7}{c}{\textbf{Far Range} \textit{(120 m $\times$ 60 m)}} \\ \midrule
MapTRv2~\cite{maptrv2} & 9.5 & 15.0 & 11.3 & 17.5 & 11.7 & 13.0 & - \\
\quad + PMapNet~\cite{jiang2024pmapnet} & 9.7 & 16.4 & 13.9 & 19.6 & 16.8 & 15.3 & \textcolor{Green}{+2.3} \\
\quad + PMapNet*\cite{jiang2024pmapnet} (all info.) & 9.3 & 15.1 & 15.0 & 20.0 & 18.9 & 15.7 & \textcolor{Green}{+2.7} \\
\quad + SMERF~\cite{luo2023augmentingSMERF} & 8.7 & 14.2 & 10.9 & 15.8 & 11.5 & 12.2 & \textcolor{Red}{-0.8} \\
% \quad + SMERF~\cite{luo2023augmentingSMERF} & 9.0 & 14.9 & 14.4 & 19.0 & 13.7 & 14.2 & \textcolor{Gray}{+1.2} \\
\quad + SMERF\textsuperscript{\textdagger}~\cite{luo2023augmentingSMERF} (all info.) & 9.1 & 15.5 & 14.0 & 19.0 & 13.5 & 14.2 & \textcolor{Gray}{+1.2} \\
% \quad + \textbf{SDTagNet\textsuperscript{\ddagger}} (ways only) & \textbf{11.7} & \textbf{20.0} & \textbf{21.9} & \textbf{23.6} & \textbf{23.2}& \textbf{20.1} & \textcolor{Green}{\textbf{+7.1}} \\
\quad + \textbf{SDTagNet} & \textbf{13.0} & \textbf{18.4} & \textbf{17.7} & \textbf{22.6} & \textbf{22.9} & \textbf{18.9} & \textcolor{Green}{\textbf{+5.9}} \\
\bottomrule
%
\end{tabular}
}
\label{tab:eval_av2}
\end{table*}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{figure}
%\hspace*{-1cm}
\centering
\includegraphics[trim={0cm 0cm 0cm 0cm},clip,width=\linewidth]{pics/qualitative_example_no_osm.pdf}
\caption{Qualitative comparison of SDTagNet with PMapNet (all info.) and SMERF (all info.) on Argoverse 2 in the far range setting. Both SMERF and PMapNet fail to identify the one-way road and hallucinate a standard two-way crossing topology instead. SDTagNet can translate the information in the SD map tags to a correct one-way topology prediction. }
\label{fig:qualitative_example}
\end{figure}
\paragraph{Results on Argoverse 2}
\Cref{tab:eval_av2} shows the results of SDTagNet on Argoverse 2~\cite{Argoverse2} in the near range and far range setting in comparison with the SD map encoding baselines PMapNet~\cite{jiang2024pmapnet} and SMERF~\cite{luo2023augmentingSMERF}, applied to the base architecture MapTRv2~\cite{maptrv2}.
In the far range, all approaches using SD prior maps improve upon the prior-less MapTRv2 baseline.
This shows the benefit of prior knowledge to drive safely and comfortably even at higher velocities, requiring farther perception range where camera resolution and road visibility diminish.
Surpassing all other approaches, SDTagNet outperforms MapTRv2 by +5.9 mAP (+45\%).
Furthermore, SDTagNet beats existing SD map prior methods by +3.2 mAP (+20\%), even when they are extended to use all available information.
Comparing the SD map baselines, PMapNet shows better performance than SMERF, suggesting that the SMERF encoder originally used in lane topology prediction is ill-adapted to perform vectorized HD map construction.
In the near range no significant performance benefit compared to the baseline can be observed for any method, even slightly reducing performance in some cases.
This can be attributed to geographic overlap between train and val split for both PMapNet and SMERF as well as weaker base architectures of HDMapNet~\cite{HDMapNet} and MapTR~\cite{maptr} in case of PMapNet.
These differences emphasize the importance of using geographically non-overlapping splits, especially for models using map priors.
% In far range, the general performance is much lower and all investigated methods improve metrics compared to no prior.
% As visibility of the road decreases with distance, features from the SD map become more important for the model.
% This also means that the performance benefits of SDTagNet become much stronger, improving performance by 45 \% compared to no prior and by 20 \% over the best baseline method.
To compare SDTagNet with recent state-of-the-art non SD map prior methods, we also evaluated it in the more limited label setting of \cite{chen2024maptracker}, the results of which are shown in \Cref{tab:eval_av2_maptracker_gt}.
SDTagNet maintains competitive performance in the near range, while significantly outperforming existing approaches in the far range, acheiving a $+6.1$ mAP gain vs. MapTracker~\cite{chen2024maptracker}.
This is despite SDTagNet being the only single-shot method in this comparison other than HIMap~\cite{Zhou_2024_CVPR}.
The results show the strengths of SDTagNet in fully exploiting all information contained in SD prior maps, significantly outperforming state-of-the-art non SD map prior methods and existing SD map encoders, even when beneficial changes are introduced to them. A qualitative comparison of SDTagNet with PMapNet and SMERF on Argoverse 2 in the far range setting is displayed in \Cref{fig:qualitative_example}.
\paragraph{Ablation Studies}
We conduct ablation studies on the Argoverse 2 dataset to assess the contributions of individual components in the SD map encoder, displayed in \Cref{tab:map_query_enc_full}.
Only the full configuration of SDTagNet, combining all proposed modifications, yields significant performance gains compared to the SMERF~\cite{luo2023augmentingSMERF} baseline.
The results further highlight the importance of ORF identifiers, without which the performance even drops when switching to point level queries.
This suggests that the provided element identifiers are essential for enabling effective point-level queries.
To investigate the viability of fusion approaches for the map decoder connection as proposed by TopoSD~\cite{yang2024toposdtopologyenhancedlanesegment}, we investigated a combination of direct cross-attention to the SD map encoder tokens and cross-attention to additional SD map BEV features, shown as \enquote{+ BEV Ft.} in \Cref{tab:map_query_enc_full}.
The SD map BEV features are rasterized similarly to PMapNet~\cite{jiang2024pmapnet}, but contain processed SD map encoder tokens instead of grayscale images.
Despite class-level differences, this combined connection showed no overall performance gain.
%Compared to \cite{yang2024toposdtopologyenhancedlanesegment}, our results indicate that, when evaluated on a geographic split and with the more diverse elements of M3TR~\cite{immel2025m3trgeneralistmodelrealworld}, regular cross-attention is sufficiently expressive on its own.
Our results indicate that, when evaluated on a geographic split with the more diverse labels of M3TR~\cite{immel2025m3trgeneralistmodelrealworld}, regular cross-attention alone is sufficiently expressive on its own.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{table*}
\centering
\caption{Comparison of SDTagNet with recent state-of-the-art non SD map prior methods on the more limited label setting of \cite{chen2024maptracker}, evaluated on the Argoverse 2 original split and the geographic split of \cite{Yuan_2024_streammapnet}. * = only total mAP reported in the original paper. \textdagger: values taken from MapTracker \cite{chen2024maptracker}.}
\resizebox{0.85\linewidth}{!}{%
\begin{tabular}{l l l l wr{1.0cm} wr{1.0cm} wr{1.0cm} wr{1.0cm} wr{1.0cm}}
\toprule
\multicolumn{2}{c}{\textit{Dataset: Argoverse 2}} &
\multicolumn{5}{c}{\textbf{Near Range} \textit{(60 m $\times$ 30 m)}} \\
\cmidrule{3-8}
\textbf{Method} & \textbf{Split} & \textbf{Epochs} & $\textbf{AP}_{\textbf{div}}$ & $\textbf{AP}_{\textbf{bou}}$ & $\textbf{AP}_{\textbf{ped}}$ & $\textbf{mAP}$ \\
\vspace{-0.35cm} \\ \toprule
HIMap \cite{Zhou_2024_CVPR} & Og. Split & \textbf{24} & 72.4 & 73.2 & 72.4 & 72.7 \\
MapUnveiler \cite{kim2024unveiling} & Og. Split & 30 & 74.2 & 71.9 & 72.5 & 72.9 \\
StreamMapNet\textsuperscript{\textdagger} \cite{Yuan_2024_streammapnet} & Og. Split & 72 & 74.2 & 66.1 & 70.5 & 70.3 \\
MapTracker \cite{chen2024maptracker} & Og. Split & 35 & 80.0 & 73.7 & 77.0 & \textbf{76.9} \\
\textbf{SDTagNet} & Og. Split & \textbf{24} & \textbf{81.7} & \textbf{76.3} & 76.1 & \textbf{78.0} \\
\midrule
StreamMapNet\textsuperscript{\textdagger} \cite{Yuan_2024_streammapnet} & \cite{Yuan_2024_streammapnet} Geo Split & 72 & 68.2 & 63.2 & 61.8 & 64.4 \\
MapTracker \cite{chen2024maptracker} & \cite{Yuan_2024_streammapnet} Geo Split & 35 & \textbf{75.1} & \textbf{68.9} & \textbf{70.0} & \textbf{71.3} \\
\textbf{SDTagNet} & \cite{Yuan_2024_streammapnet} Geo Split & \textbf{24} & 72.0 & 67.5 & 64.0 & 67.8 \\
\midrule
& &
\multicolumn{5}{c}{\textbf{Far Range} \textit{(100 m $\times$ 50 m)} from \cite{Yuan_2024_streammapnet}} \\ \midrule
MapUnveiler \cite{kim2024unveiling} & Og. Split & 30 & 67.9 & 62.6 & 71.7 & 67.4 \\
StreamMapNet\textsuperscript{\textdagger} \cite{Yuan_2024_streammapnet} & Og. Split & 30 & -* & -* & -* & 57.7 \\
\textbf{SDTagNet} & Og. Split & \textbf{24} & \textbf{80.2} & \textbf{72.9} & \textbf{81.7} & \textbf{78.3} \\
\midrule
StreamMapNet\textsuperscript{\textdagger} \cite{Yuan_2024_streammapnet} & \cite{Yuan_2024_streammapnet} Geo Split & 72 & 56.1 & 47.5 & 60.1 & 54.6 \\
MapTracker \cite{chen2024maptracker} & \cite{Yuan_2024_streammapnet} Geo Split & 35 & 64.6 & 58.5 & 71.2 & 64.8 \\
\textbf{SDTagNet} & \cite{Yuan_2024_streammapnet} Geo Split & \textbf{24} & \textbf{69.5} & \textbf{68.0} & \textbf{75.1} & \textbf{70.9} \\
\midrule
\end{tabular}
}
\label{tab:eval_av2_maptracker_gt}
\end{table*}
% Footnotes:
% ** = only total mAP reported in the original paper
% * = values taken from MapTracker [b] paper
% Following StreamMapNet \cite{Yuan_2024_streammapnet}, MapTracker [b] and MapUnveiler [i], near range mAP is calculated with thresholds of [0.5m, 1m, 1.5m] and far range mAP with thresholds of [1m, 1.5m, 2m]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{table}
\centering
\caption{Ablation study of different encoder components on the Argoverse 2 dataset. All experiments are in the near range setting
and all models are trained for 24 epochs.
\textdagger: With OSM nodes in the input features, which are not used in the original work.
+ BEV Ft.: With BEV features as an additional prior mode similar to \cite{yang2024toposdtopologyenhancedlanesegment}.}
\vspace{0.25cm}
\resizebox{0.85\linewidth}{!}{%
\begin{tabular}{wl{1.1cm} wl{1.4cm} wl{1.1cm} wl{1.1cm} wc{1.4cm} wr{0.5cm} wr{0.5cm} wr{0.5cm} wr{0.5cm} wr{0.5cm}}
\toprule
\multicolumn{4}{c}{\textit{Base Enc.: SMERF\textsuperscript{\textdagger}~\cite{luo2023augmentingSMERF} (all info.)}} & & \multicolumn{5}{c}{$\textbf{AP}$} \\
Pt. Lvl. & NLP Emb. & ORF Id. & + BEV Ft. & $\textbf{mAP}$ & dsh. & sol. & bou. & cen. & ped. \\ \toprule
- & - & - & - & 45.9 & 38.0 & 54.4 & 50.0 & 48.5 & 38.2 \\
$\checkmark$ & - & - & - & 44.3 & 34.9 & 53.0 & 49.5 & 45.5 & 38.7 \\
- & $\checkmark$ & - & - & 45.8 & 37.0 & 55.4 & 47.9 & 49.2 & 39.3 \\
$\checkmark$ & - & $\checkmark$ & - & 46.3 & 39.3 & 53.3 & 49.6 & 48.5 & 40.8 \\
$\checkmark$ & $\checkmark$ & - & - & 45.0 & 33.6 & 53.2 & 50.2 & 47.7 & 40.6 \\
$\checkmark$ & $\checkmark$ & $\checkmark$ & - & \textbf{48.1} & 36.0 & 55.2 & 53.3 & 52.6 & 43.3 \\
$\checkmark$ & $\checkmark$ & $\checkmark$ & $\checkmark$ & \textbf{48.1} & 38.2 & 56.3 & 52.6 & 50.7 & 42.3 \\
\bottomrule
\end{tabular}
}
\label{tab:map_query_enc_full}
\end{table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\paragraph{Results on nuScenes}
\Cref{tab:eval_nusc} shows the evaluation results on the nuScenes dataset.
The relative improvement of SDTagNet in the far range setting is even stronger, increasing performance compared to MapTRv2 by +4.1 mAP (+105\%) and compared to existing methods by +2.1 mAP (+35\%).
This coincides with the general drop in mAP for all methods on the nuScenes geo split \cite{Lilja2024CVPR} and shows the benefits of our approach even on smaller datasets with less generalization capability.
SMERF outperforms PMapNet here, indicating that these methods may be more susceptible to dataset differences than SDTagNet, which shows similar performance benefits in both cases.
In the near range, the results mostly mirror those on Argoverse 2, with no method able to provide a significant performance gain.
On nuScenes in particular, we observed some significant differences between the roads and structures contained in the SD map and the ground truth HD map (see \Cref{sec:limitations}).
We hypothesize this is one of the main causes of the lacking performance in the near range, where the visibility of road features is much higher and the model is less reliant on SD map features.
% \begin{itemize}
% \color{Mulberry} % draft notes
% \item I would wait with writing this section until more nuScenes experiments are done
% \end{itemize}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{table*}
\centering
\caption{Comparison of SD map prior encoding methods on nuScenes~\cite{nuscenes}, with the geographical split of~\cite{Lilja2024CVPR}.
*: With the 7 classes from \cite{luo2023augmentingSMERF} in the input features, which are not used in the original work.
\textdagger: With OSM nodes in the input features, which are not used in the original work. All models are trained for 110 epochs.}
\setlength\dashlinedash{1.2pt}
\setlength\dashlinegap{2.0pt}
\setlength\arrayrulewidth{0.3pt}
\resizebox{0.93\linewidth}{!}{%
\begin{tabular}{l wr{1.0cm} wr{1.0cm} wr{1.0cm} wr{1.0cm} wr{1.0cm} wr{1.0cm} wr{1.0cm}}
\toprule
%
\small{\textit{Dataset: nuScenes}} &
\multicolumn{7}{c}{\textbf{Near Range} \textit{(60 m $\times$ 30 m)}} \\
\cmidrule{2-8}
\textbf{Method} & $\textbf{AP}_{\textbf{dsh}}$ & $\textbf{AP}_{\textbf{sol}}$ & $\textbf{AP}_{\textbf{bou}}$ & $\textbf{AP}_{\textbf{cen}}$ & $\textbf{AP}_{\textbf{ped}}$ & $\textbf{mAP}$ & vs. \cite{maptrv2}\\
\vspace{-0.35cm} \\ \toprule
%
MapTRv2~\cite{maptrv2} & 12.5 & 19.1 & 32.4 & 29.1 & 21.6 & 22.9 & - \\
\quad + PMapNet~\cite{jiang2024pmapnet} & 13.4 & 20.9 & 32.5 & 30.2 & \textbf{22.2} & \textbf{23.9} & \textcolor{Gray}{+1.0} \\
\quad + PMapNet*\cite{jiang2024pmapnet} (all info.) & 12.6 & 19.8 & 32.6 & 28.7 & 21.1 & 23.0 & \textcolor{Gray}{+0.1} \\
% \quad + SMERF~\cite{luo2023augmentingSMERF} & 17.1 & 19.8 & 31.8 & 28.8 & 23.4 & 24.2 & \textcolor{Green}{+1.3} \\
\quad + SMERF~\cite{luo2023augmentingSMERF} & 14.6 & 19.3 & \textbf{34.2} & 28.9 & 21.6 & 23.7 & \textcolor{Gray}{+0.8} \\
\quad + SMERF\textsuperscript{\textdagger}~\cite{luo2023augmentingSMERF} (all info.) & 15.5 & \textbf{20.2} & 33.0 & 28.4 & 19.8 & 23.4 & \textcolor{Gray}{+0.5} \\
% \quad + \textbf{SDTagNet\textsuperscript{\ddagger}} (ways only) & 16.9 & 19.3 & 31.2 & 25.3 & 15.0 & 21.6 & \textcolor{Red}{-1.3} \\
\quad + \textbf{SDTagNet} & \textbf{19.3} & 19.8 & 31.3 & \textbf{30.4} & 15.6 & 23.3 & \textcolor{Gray}{+0.4} \\
\midrule
&
\multicolumn{7}{c}{\textbf{Far Range} \textit{(120 m $\times$ 60 m)}} \\ \midrule
MapTRv2~\cite{maptrv2} & 2.7 & 3.7 & 4.6 & 5.4 & 2.9 & 3.9 & - \\
\quad + PMapNet~\cite{jiang2024pmapnet} & 2.4 & 3.5 & 5.0 & 5.8 & 2.9 & 3.9 & \textcolor{Gray}{+0.0} \\
\quad + PMapNet*\cite{jiang2024pmapnet} (all info.) & 2.6 & 3.6 & 4.7 & 5.6 & 2.7 & 3.8 & \textcolor{Gray}{-0.1} \\
\quad + SMERF~\cite{luo2023augmentingSMERF} & 4.5 & 5.6 & 8.1 & 7.6 & 3.1 & 5.8 & \textcolor{Green}{+1.9} \\
\quad + SMERF\textsuperscript{\textdagger}~\cite{luo2023augmentingSMERF} (all info.) & 4.1 & \textbf{6.6} & 7.8 & 7.5 & 3.4 & 5.9 & \textcolor{Green}{+2.0} \\
% \quad + \textbf{SDTagNet\textsuperscript{\ddagger}} (ways only) & \textbf{8.6} & \textbf{6.9} & \textbf{10.4} & \textbf{10.1} & 4.6 & \textbf{8.1} & \textcolor{Green}{\textbf{+4.2}} \\
\quad + \textbf{SDTagNet} & \textbf{8.3} & \textbf{6.6} & \textbf{10.3} & \textbf{9.3} & \textbf{5.3} & \textbf{8.0} & \textcolor{Green}{\textbf{+4.1}} \\
\bottomrule
%
\end{tabular}
}
\label{tab:eval_nusc}
\end{table*}
% \paragraph{Qualitative Evaluation}
% \begin{itemize}
% \color{Mulberry} % draft notes
% \item Standard stuff about HD maps
% \end{itemize}
\section{Limitations}
\label{sec:limitations}
Despite SDTagNet's strong performance, we observe several limitations.
First, like all SD map prior methods, SDTagNet assumes congruency of SD map and HD map ground truth.
Depending on the level of detail and quality of dataset ground truth and SD map, a number of map discrepancies can be observed.
This is especially the case for crowdsourced databases like OSM, as shown for Argoverse 2 by \cite{liu2025controlmapdistributionusing} and nuScenes by \cite{jiang2024pmapnet}.
%\cite{liu2025controlmapdistributionusing} and \cite{jiang2024pmapnet} have already shown discrepancies for Argoverse 2 and nuScenes respectively.
We also noted significant differences on nuScenes, particularly concerning structures and roads that are missing from the ground truth HD map.
\Cref{fig:limitations_map_discrepancy} shows examples of a tunnel and smaller service roads that are not included in the nuScenes map, impacting model accuracy and training data quality.
% We also observed a limitation of the current model in the case of one-way roads.
Another limitation concerns the case of one-way roads.
SDTagNet is able to correctly identify one-way roads from the SD map tag information, however in some cases the driving direction is predicted wrongly.
An example of this is displayed in \Cref{fig:limitations_wrong_oneway}.
Since OSM encodes one-way direction via polyline point order, this likely stems from the lack of point order information in the element identifiers.
Adding point order identifiers for polyline features could help remedy this limitation.
% \begin{itemize}
% \color{Mulberry} % draft notes
% \item While the method shows strong performance on multiple datasets, we also observe a number of limitations
% \item First SDTagNet, like all SD map prior methods relies on the available detail and quality of SD maps, which can vary between regions, especially on a crowdsourced database like OSM
% \item Additionally, while we can see in the qualitative examples that SDTagNet can successfully detect one way roads as such and "understand" the tag information in OSM, the direction of the one way road is not always correct. The direction information is only implicitly encoded in OSM via the polyline point order and it seems this information gets lost during the encoding process.
% \end{itemize}
\begin{figure}
\centering
\begin{subfigure}[t]{0.32\linewidth}
\centering
\includegraphics[trim={0.0cm 0.0cm 0.0cm 0.05cm},clip,width=\linewidth]{pics/limitations_wrong_oneway.pdf}
\caption{Pred. false one-way direction.}
\label{fig:limitations_wrong_oneway}
\end{subfigure}
\hfill
\begin{subfigure}[t]{0.67\linewidth}
\centering
% trim={<left> <lower> <right> <upper>}
\includegraphics[trim={0cm 0.15cm 0.0cm 0.0cm},clip,width=\linewidth]{pics/limitations_nusc_sd_map_discrepancy_v_1_1.pdf}
\caption{Discrepancies between the SD map and ground truth.}
\label{fig:limitations_map_discrepancy}
\end{subfigure}
\caption{Examples for observed limitations of SDTagNet in Argoverse 2 (left) and nuScenes (right). \Cref{fig:limitations_wrong_oneway}: Even when correctly recognizing a one-way road, SDTagNet can fail to predict its correct driving direction. \Cref{fig:limitations_map_discrepancy}: Discrepancies between dataset HD maps and OSM SD maps like missing tunnels (left) or small service roads (left, right).}
\label{fig:limitations_examples}
\end{figure}
\section{Conclusion}
\label{sec:conclusion}
% \begin{itemize}
% \item \textbf{Things to mention}
% \item difference between far-range shortrange, hier vielleicht halbsatz wie wichtig für application
% \item vielleicht ein satz dass es bei Argoverse besser funktioniert weil , aber das auch representative für zukünftige ist
% \item maybe other general ablation findings which lead us to our magical encoder architecture
% \end{itemize}
We present SDTagNet, the first online HD map construction approach that fully utilizes commonly available SD maps, including all elements such as points, polylines and relations in conjunction to their descriptive textual information.
This is achieved by incorporating embeddings of the textual annotations for each point, polyline, and relation in addition to their geometric information, encoding their key-value tags with a contrastively pre-trained and fine-tuned BERT encoder.
For scene-level encoding of SD map priors with their geometric data we increase the query resolution from polyline-level to point-level using orthogonal element identifiers, allowing for greater expressiveness by integration of point and relational SD map elements in addition to the established polylines.
The combination of these encoding methods results in a 20-35\% increase in performance on Argoverse~2 and nuScenes, respectively, when evaluated on a far perception range.
This makes SDTagNet the first SD map prior based online HD map construction model free from manually selected features, with scalable self-supervised pre-training on planet-scale SD map data, improving the performance of existing methods by large margins.
%This makes SDTagNet the first scalable SD map prior based online HD map construction model, allowing for a fully self-supervised contrastive pretraining of the tagset encoder on planetary SD map data and removing all selective SD map preprocessing during inference, while improving existing methods by large margins.
% Additionally, using point level queries, we align the query granularity with that of many other HD map perception approaches, additionally allowing the integration of point and relational SD map elements via the usage of methods from the field of graph transformers.
% \begin{itemize}
% \color{Mulberry} % draft notes
% \item Standard stuff about HD maps
% \end{itemize}
\section{Acknowledgements}
\label{sec:acknowledgements}
The authors gratefully acknowledge the computing time provided on the high-performance computer HoreKa by the National High-Performance Computing Center at KIT (NHR@KIT). This center is jointly supported by the Federal Ministry of Education and Research and the Ministry of Science, Research and the Arts of Baden-Württemberg, as part of the National High-Performance Computing (NHR) joint funding program (https://www.nhr-verein.de/en/our-partners). HoreKa is partly funded by the German Research Foundation (DFG).
SD map data copyrighted OpenStreetMap contributors and available from https://www.openstreetmap.org.
\appendix
\section{Technical Appendices and Supplementary Material}
The supplementary material focuses on three key aspects:
Additional ablation studies on all individual components of SDTagNet (\cref{subsec:ablation_studies}) and additional experiments on a non-geo split (\cref{subsec:av2_original_split}), implementation details of the baselines and NLP pretraining (\cref{subsec:implementation_details_baseline} and \cref{subsubsec:implementation_details_pretraining}) as well as more qualitative examples and visualizations (\cref{subsubsec:qual_examples_supp}).
\subsection{Ablation studies}
\label{subsec:ablation_studies}
%We conduct ablation studies to assess the contributions of individual components in the SD map encoder and the optimization strategies applied to the NLP tag embedding module. All results are reported on the Argoverse 2 dataset and are summarized in \Cref{tab:map_query_enc_full}, \Cref{tab:nlp_tag_embedding}, and \Cref{tab:map_query_enc_attention} respectively.
Additional ablation studies concerning the optimization strategies applied to the NLP tag embedding module and fine-tuning training regimes, conducted on the Argoverse 2 dataset, are summarized in \Cref{tab:nlp_tag_embedding}, and \Cref{tab:map_query_enc_attention}.
%Our architectural ablation studies of the SD map encoder in \Cref{tab:map_query_enc_full} reveal that only the full configuration of SDTagNet, combining all proposed modifications, yields significant performance gains compared to the SMERF~\cite{luo2023augmentingSMERF} baseline.
%The results also highlight the importance of ORF identifiers, without which the performance even drops when switching to point level queries.
%This suggests that the provided element identifiers are essential for enabling effective point-level queries.
For the NLP tag embedding module, we observe in \Cref{tab:nlp_tag_embedding} that fine-tuning the pretrained language model with a small learning rate is crucial to align the self-supervised embeddings with the specific objectives of the downstream task. Additionally, removing our custom contrastive pretraining objective results in degraded performance. This confirms the utility of our training scheme, which guides the model to focus on semantically meaningful tag representations.
Additionally, we tested different numbers of attention heads and different values of dropout for the SD map encoder cross-attention in \Cref{tab:map_query_enc_attention}, settling on 8 attention heads and a dropout of 0.1 as the configuration with the best performance.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{table}
\centering
\caption{Ablation studies concerning the NLP tag embedding module on the Argoverse 2 dataset. All experiments are in the near range setting
and all models are trained for 24 epochs.
rel. tag CL = relevant tag contrastive learning, meaning whether our contrastive learning objective based on relevant tags is used during pretraining or not.
If not, irrelevant tags are removed in preprocessing and the positive sample is also the anchor for pretraining.}
\vspace{0.25cm}
\resizebox{0.75\linewidth}{!}{%
\begin{tabular}{wl{2.0cm} wl{1.6cm} wc{1.4cm} wr{0.5cm} wr{0.5cm} wr{0.5cm} wr{0.5cm} wr{0.5cm}}
\toprule
& & & \multicolumn{5}{c}{\textbf{AP}} \\
Fine-tuning LR & Rel. Tag CL & \textbf{mAP} & dsh. & sol. & bou. & cen. & ped. \\ \toprule
Frozen & $\checkmark$ & 45.6 & 36.5 & 54.2 & 49.8 & 48.4 & 39.2 \\
$\times$ 0.5 & $\checkmark$ & 47.1 & 35.7 & 53.5 & 52.0 & 50.0 & 44.3 \\
$\times$ 0.1 & - & 47.5 & 35.2 & 54.5 & 51.9 & 50.9 & 45.0 \\
$\times$ 0.1 & $\checkmark$ & \textbf{48.1} & 36.0 & 55.2 & 53.3 & 52.6 & 43.3 \\
\bottomrule
\end{tabular}
}
\label{tab:nlp_tag_embedding}
\end{table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{table}
\centering
\caption{Ablation studies of the SD map encoder cross attention on the Argoverse 2 dataset. All experiments are in the near range setting
and all models are trained for 24 epochs.}
\vspace{0.25cm}
\resizebox{0.72\linewidth}{!}{%
\begin{tabular}{wl{1.5cm} wl{1.3cm} wc{1.4cm} wr{0.5cm} wr{0.5cm} wr{0.5cm} wr{0.5cm} wr{0.5cm}}
\toprule
& & & \multicolumn{5}{c}{\textbf{AP}} \\
Att. Heads & Dropout & \textbf{mAP} & dsh. & sol. & bou. & cen. & ped. \\ \toprule
8 & 0.2 & 46.9 & 35.7 & 53.7 & 50.6 & 52.0 & 44.3 \\
4 & 0.1 & 47.7 & 38.6 & 54.3 & 51.9 & 51.4 & 42.3 \\
8 & 0.1 & \textbf{48.1} & 36.0 & 55.2 & 53.3 & 52.6 & 43.3 \\
\bottomrule
\end{tabular}
}
\label{tab:map_query_enc_attention}
\end{table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Implementation Details of Baseline Approaches}
\label{subsec:implementation_details_baseline}
We reproduce our baselines PMapNet~\cite{jiang2024pmapnet} and SMERF~\cite{luo2023augmentingSMERF} according to their publicly available source code, with a few changes to adapt to our different experiment setting and base architecture.
For the PMapNet base setting, we create a BEV grid with the same resolution as the main image BEV features and rasterize point and polyline features on this grid. Polyline and point features are drawn with a fixed width of 7 an 5 grid cells, respectively.
Like in the PMapNet reference implementation, each element gets assigned a descending grayscale value from 0 to 255, without any additional labels. For the enhanced version PMapNet (all info.), we additionally add the 7 classes defined in SMERF, plus an additional \texttt{other} class for elements that do not belong to the predefined classes. Follwing the original source, the feature grids of both PMapNet versions get processed by a simple 3-layer CNN before being supplied to the main map decoder.
For the SMERF base setting, we keep all hyperparameters as found in the original source code, except for also including the additional \texttt{other} class for elements that do not belong to the predefined classes.
We also select a fixed polyline point number of 10 like in the other experiments instead of 11 for easier preprocessing.
For the enhanced version SMERF (all info.), we add point features to the encoder which also get assigned the \texttt{other} class.
To fit the point features into the original polyline-level query token, we repeat the single point for 10 times.
We do not include relation features in both PMapNet and SMERF, as the encoder architectures make this not possible without major changes.
\subsection{Implementation Details Contrastive Pretraining Objective}
\label{subsubsec:implementation_details_pretraining}
In this section, we describe in more detail the selection process for the non-relevant tags used in the contrastive pretraining objective.
The selection was performed with the help of the central OSM tag database located at \texttt{https://taginfo.openstreetmap.org/} and for all tags that were used at least 100,000 times.
For comparison, as of the time of writing, the most used tag key is \texttt{building} with around 650 million uses, or around 6\% of total objects.
As a rule, the selection was performed task-agnostically and did not consider whether a tag was particularly relevant for the task of online HD map construction.
This preserves the general applicability of the proposed embedding model.
Two main categories of tags are considered not informative.
First, tags that are names and other identifying information of places like telephone numbers or website links.
Second, map annotation artifacts, primarily IDs and other data from various government geodetic databases that were the original source of the data.
As an example, most OSM elements in the United States contain IDs from the Topologically Integrated Geographic Encoding and Referencing system (TIGER) by the US Census Bureau, from which these elements were imported.
The full list contains around 110 tag keys in total and can be found in the accompanying source code.
\subsection{Argoverse 2 Original Split}
\label{subsec:av2_original_split}
To examine the differences to a non-geographic split setting, we furthermore evaluated a reduced model set of MapTRv2, SMERF (all info.), and SDTagNet on the original Argoverse 2 split with about 40\% geographic overlap \cite{Lilja2024CVPR}.
The results in \Cref{tab:eval_av2_original_split} show that SDTagNet maintains superior performance in both range settings, with a much higher absolute mAP gain in the far range of +9.1 mAP compared to SMERF.
It worth noting that the base performance is already 15 to 20 mAP higher in both settings, confirming the findings in \cite{Lilja2024CVPR} and indicating that significant geographic overfitting still takes place in the training of online HD map construction models.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{table*}
\centering
\caption{Comparison of SD map prior encoding methods on the Argoverse 2 data set, with the original geographically overlapping split.
\textdagger: With OSM nodes and relations in the input features, which are not used in the original work. All models are trained for 24 epochs.}
\setlength\dashlinedash{1.2pt}
\setlength\dashlinegap{2.0pt}
\setlength\arrayrulewidth{0.3pt}
\resizebox{\linewidth}{!}{%
\begin{tabular}{l wr{1.0cm} wr{1.0cm} wr{1.0cm} wr{1.0cm} wr{1.0cm} wr{1.0cm} wr{1.0cm}}
\toprule
%
\small{\textit{Dataset: Argoverse 2, og. split}} &
\multicolumn{7}{c}{\textbf{Near Range} \textit{(60 m $\times$ 30 m)}} \\
\cmidrule{2-8}
\textbf{Method} & $\textbf{AP}_{\textbf{dsh}}$ & $\textbf{AP}_{\textbf{sol}}$ & $\textbf{AP}_{\textbf{bou}}$ & $\textbf{AP}_{\textbf{cen}}$ & $\textbf{AP}_{\textbf{ped}}$ & $\textbf{mAP}$ & vs. \cite{maptrv2}\\
\vspace{-0.35cm} \\ \toprule
%
MapTRv2~\cite{maptrv2} & \textbf{61.1} & 66.8 & 67.9 & 61.9 & 58.6 & 63.3 & - \\
\quad + SMERF\textsuperscript{\textdagger}~\cite{luo2023augmentingSMERF} (all info.) & 60.6 & 66.6 & 67.8 & 60.1 & 60.5 & 63.1 & \textcolor{Gray}{-0.2} \\
\quad + \textbf{SDTagNet} & 59.5 & \textbf{67.7} & \textbf{70.7} & \textbf{65.5} & \textbf{62.1} & \textbf{65.1} & \textcolor{Green}{\textbf{+1.8}} \\
\midrule
&
\multicolumn{7}{c}{\textbf{Far Range} \textit{(120 m $\times$ 60 m)}} \\ \midrule
MapTRv2~\cite{maptrv2} & 26.7 & 33.4 & 22.9 & 30.7 & 30.6 & 28.9 & - \\
\quad + SMERF\textsuperscript{\textdagger}~\cite{luo2023augmentingSMERF} (all info.) & 30.7 & 37.9 & 28.9 & 33.9 & 35.3 & 33.4 & \textcolor{Green}{+4.5} \\
\quad + \textbf{SDTagNet} & \textbf{39.6} & \textbf{45.1} & \textbf{38.7} & \textbf{43.8} & \textbf{45.5} & \textbf{42.5} & \textcolor{Green}{\textbf{+13.6}} \\
\bottomrule
%
\end{tabular}
}
\label{tab:eval_av2_original_split}
\end{table*}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{SD Map Augmentation Methods}
\label{subsec:sd_map_augmentation_methods}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{table}
\centering
\caption{Comparison of different SD map prior augmentation methods on the Argoverse 2 dataset. All experiments are in the near range setting
and all models are trained for 24 epochs.
Loc. Const. = locally constant, meaning all sd map elements in one frame are augmented with the same offset and rotation.}
\vspace{0.25cm}
\resizebox{0.9\linewidth}{!}{%
\begin{tabular}{wr{1.9cm} wc{1.3cm} wr{1.1cm} wr{0.6cm} wc{1.2cm} wr{0.5cm} wr{0.5cm} wr{0.5cm} wr{0.5cm} wr{0.5cm}}
\toprule
& \multicolumn{3}{c}{\textbf{Pos. Noise}} & & \multicolumn{5}{c}{$\textbf{AP}$} \\
\cmidrule{2-4}
El. Drop Rate & Loc. Const. & $\sigma_{\mathrm{trans}}$ & $\sigma_{\mathrm{rot}}$ & $\textbf{mAP}$ & dsh. & sol. & bou. & cen. & ped. \\ \toprule
0.1 & - & 1 m & 2° & 43.8 & 40.2 & 54.6 & 47.3 & 43.6 & 33.3 \\
0.1 & $\checkmark$ & 1 m & 2° & 45.6 & 37.3 & 54.5 & 48.8 & 47.4 & 39.9 \\
- & - & - & - & \textbf{48.1} & 36.0 & 55.2 & 53.3 & 52.6 & 43.3 \\
\bottomrule
\end{tabular}
}
\label{tab:sd_prior_aug}
\end{table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{table}
\centering
\caption{Comparison of different SD map prior tag masking augmentation methods on the Argoverse 2 dataset. All experiments are in the near range setting
and all models are trained for 24 epochs.
El. Aug. Rt. = Rate of elements where tag masking is applied.
Non-Rel. Only = Tag masking is only applied to non-relevant tags.
NLP Ft. LR = Fine-tuning learning rate multiplier for the NLP encoder.}
\vspace{0.25cm}
\resizebox{\linewidth}{!}{%
\begin{tabular}{wr{1.7cm} wr{1.7cm} wc{2.0cm} wr{1.7cm} wc{1.1cm} wr{0.5cm} wr{0.5cm} wr{0.5cm} wr{0.5cm} wr{0.5cm}}
\toprule
\multicolumn{3}{c}{\textbf{Tag Masking}} & & & \multicolumn{5}{c}{$\textbf{AP}$} \\
\cmidrule{1-3}
El. Aug. Rt. & Tag Drop Rt. & Non-Rel. Only & NLP Ft. LR & $\textbf{mAP}$ & dsh. & sol. & bou. & cen. & ped. \\ \toprule
0.5 & 0.4 & - & $\times$ 0.1 & 44.7 & 37.4 & 54.2 & 47.5 & 46.7 & 37.9 \\
0.5 & 0.6 & $\checkmark$ & $\times$ 0.1 & 47.2 & 36.2 & 54.6 & 51.6 & 49.2 & 44.7 \\
0.5 & 0.6 & $\checkmark$ & $\times$ 0.5 & 47.4 & 34.7 & 55.3 & 52.1 & 51.5 & 43.2 \\
- & - & - & $\times$ 0.1 & \textbf{48.1} & 36.0 & 55.2 & 53.3 & 52.6 & 43.3 \\
\bottomrule
\end{tabular}
}
\label{tab:sd_prior_tags}
\end{table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Motivated by the findings above and a general trend of increased overfitting we observed with SD map priors, we explored augmentation methods for SD map priors that could increase the performance outside of the geographic training area.
\cite{yang2024toposdtopologyenhancedlanesegment} showed that position noise augmentation for the SD map prior input during training increases performance when noisy priors are also there during validation.
In this section however, our goal is to examine whether SD map prior augmentation can increase the \emph{general} performance of a model, similar to the common use of augmentation techniques in computer vision.
Additionally, with our direct use of the text annotations, we have an additional avenue for augmentation available in modifying the text content of these annotations.
We focused on two main augmentation modes: Position noise and element dropping, shown in \Cref{tab:sd_prior_aug}, and text annotation tag masking, shown in \cref{tab:sd_prior_tags}.
Unfortunately, in both cases, we were unable to note a performance benefit when evaluated on the validation set without any added noise.
For the element-level noise modes in \Cref{tab:sd_prior_aug}, both augmentation variants worsened performance instead, even when all SD map elements in one frame were moved with the same offset to simulate localization noise.
The tag masking augmentation in \cref{tab:sd_prior_tags} uses an element augmentation rate to randomly select what percentage of elements will be modified and a tag drop rate to select how many tags will be dropped.
An additional parameter considered whether only non-relevant tags are dropped or not.
The performance of this augmentation mode is higher than with position noise, especially when only non-relevant tags are dropped.
Nonetheless, tag masking was also not able to improve performance compared to the baseline without any augmentation.
We believe that a method to prevent geographic overfitting via augmentation techniques or in other ways would significantly increase generalization and overall performance in online HD map construction, particularly when priors are also available.
\subsection{Inference Time and Model Size}
\label{subsec:inference_time}
SDTagNet is designed with real-time capability in mind: the NLP tag encoder is based on a compact BERT model (embedding dim 144), and the SD map encoder is lightweight compared to the main perception backbone.
To evaluate the real time capability of SDTagNet, we have investigated its inference time in comparison with no prior and with other SD map encoders.
The parameter count and FPS of SDTagNet and baselines on an NVIDIA H100 GPU can be found in \Cref{tab:computational_complexity}.
The additional inference time for SDTagNet is less than 7 ms per frame, and the memory overhead is marginal relative to the base model.
We thus consider our approach suitable for real-time deployment in autonomous driving systems, with a negligible difference to other SD map encoding methods.
\begin{table}
\centering
\caption{Comparison of model parameter count, FPS, and VRAM with MapTRv2 and two SD map baseline methods. All experiments are on the Argoverse 2 dataset with the far-range setting, averaged over 10 samples and tested on a NVIDIA H100 GPU.}
\vspace{0.25cm}
\label{tab:computational_complexity}
\resizebox{0.65\linewidth}{!}{%
\begin{tabular}{lccc}
\toprule
\textbf{Model} & \textbf{Param. Count} & \textbf{FPS} &\textbf{VRAM [MB]} \\
\midrule
MapTRv2~\cite{maptrv2} (no prior) & 42.12 M & 16.0 & 3654 \\
MapTRv2 + PMapNet~\cite{jiang2024pmapnet} & 50.48 M & 13.9 & 3698 \\
MapTRv2 + SMERF~\cite{luo2023augmentingSMERF} & 44.62 M & 14.9 & 3662 \\
MapTRv2 + SDTagNet & 50.54 M & 14.5 & 3686 \\
\bottomrule
\end{tabular}
}
\end{table}
\subsection{Additional Qualitative Examples and Visualizations}
\label{subsubsec:qual_examples_supp}
\paragraph{Example of OSM Text Annotations}
%\label{subsubsec:example_osm_ann_supp}
To provide a better understanding of the format and content of text annotations in OpenStreetMap, we include a larger resolution example of the OSM elements for a frame in \cref{fig:osm_example_large}.
Every element has annotated information, this includes buildings and roads with their names, oneway information or number of lanes for roads, pedestrian ways, pedestrian crossing points, etc.
The road annotations on the lower left also contain some of the aforementioned TIGER geodetic database identifiers.
\paragraph{Additional Examples of nuScenes Map Discrepancies}
%\label{subsubsec:qual_examples_nusc_disc_supp}
\Cref{fig:nusc_sd_map_discrepancies} shows additional examples of HD and SD map discrepancies we observed in nuScenes.
These consist of inconsistent road borders that include loading and parking areas, differences in annotated crossing topology and annotation ranges that are too short and leave parts of the road unannotated.
We hypothesize that these differences play a role in the reduced performance of all SD map prior methods in the nuScenes near range setting, where information from the camera images is more plentiful.
\paragraph{Additional Qualitative Comparisons of SDTagNet}
In \cref{fig:qual_examples_supp_av2} and \cref{fig:qual_examples_supp_nusc} we present additional comparisons of SDTagNet with the baselines PMapNet~\cite{jiang2024pmapnet} and SMERF~\cite{luo2023augmentingSMERF} on Argoverse 2 and nuScenes, respectively.
\Cref{fig:qual_examples_supp_av2} contains examples that show how SDTagNet can utilize text-annotated information such as oneway roads or the number of lanes and transfer this into improved prediction results.
\Cref{fig:qual_examples_supp_nusc} displays the increased accuracy and topological consistency of SDTagNet on nuScenes compared to previous methods.
\begin{figure}
%\hspace*{-1cm}
\centering
\includegraphics[trim={0cm 0cm 0cm 0cm},clip,width=\linewidth]{pics/OSM_MAP_example.png}
\caption{Larger resolution example of the OSM SD map input data on Argoverse 2 used for SDTagNet. All text annotations are used as-is, without any preprocessing or filtering. This makes the design of SDTagNet highly scalable and adaptive.}
\label{fig:osm_example_large}
\end{figure}
\begin{figure}
\centering
\begin{subfigure}[t]{\linewidth}
\centering
\includegraphics[trim={0.0cm 0.0cm 0.0cm 0.0cm},clip,width=\linewidth]{pics/nusc_sd_map_discrepancy_qual_1_small.pdf}
\caption{Road border of the ground truth mistakenly includes loading and parking areas.}
\label{fig:nusc_sd_map_discrepancies_1}
\end{subfigure}
\hfill
\begin{subfigure}[t]{\linewidth}
\centering
% trim={<left> <lower> <right> <upper>}
\includegraphics[trim={0cm 0cm 0.0cm 0.0cm},clip,width=\linewidth]{pics/nusc_sd_map_discrepancy_qual_2_small.pdf}
\caption{Non-existent crossing arm included in the ground truth.}
\label{fig:nusc_sd_map_discrepancies_2}
\end{subfigure}
\hfill
\begin{subfigure}[t]{\linewidth}
\centering
% trim={<left> <lower> <right> <upper>}
\includegraphics[trim={0cm 0cm 0.0cm 0.0cm},clip,width=\linewidth]{pics/nusc_sd_map_discrepancy_qual_3_small.pdf}
\caption{Ground truth annotation cutoff is too short.}
\label{fig:nusc_sd_map_discrepancies_3}
\end{subfigure}
\hfill
\caption{Additional examples of discrepancies between the ground truth HD maps and OSM SD maps in the far range setting. Inconsistent road borders, wrong crossing topologies and too short of an annotation cutoff cause inconsistencies.}
\label{fig:nusc_sd_map_discrepancies}
\end{figure}
\begin{figure}
\centering
\begin{subfigure}[t]{\linewidth}
\centering
\includegraphics[trim={0.0cm 0.0cm 0.0cm 0.0cm},clip,width=\linewidth]{pics/qualitative_example_supp_av2_1_small.pdf}
%\caption{Incorrect crossing topologies for PMapNet and SMERF}
%\label{fig:qual_examples_supp_av2_1}
\end{subfigure}
\hfill
\begin{subfigure}[t]{\linewidth}
\centering
% trim={<left> <lower> <right> <upper>}
\includegraphics[trim={0cm 0cm 0.0cm 0.0cm},clip,width=\linewidth]{pics/qualitative_example_supp_av2_2_small.pdf}
%\caption{Ex 2.}
%\label{fig:qual_examples_supp_av2_2}
\end{subfigure}
\hfill
\begin{subfigure}[t]{\linewidth}
\centering
% trim={<left> <lower> <right> <upper>}
\includegraphics[trim={0cm 0cm 0.0cm 0.0cm},clip,width=\linewidth]{pics/qualitative_example_supp_av2_3_small.pdf}
%\caption{Ex 2.}
%\label{fig:qual_examples_supp_av2_3}
\end{subfigure}
\hfill
\begin{subfigure}[t]{\linewidth}
\centering
% trim={<left> <lower> <right> <upper>}
\includegraphics[trim={0cm 0cm 0.0cm 0.0cm},clip,width=\linewidth]{pics/qualitative_example_supp_av2_4_small.pdf}
%\caption{Ex 2.}
%\label{fig:qual_examples_supp_av2_4}
\end{subfigure}
\caption{Further qualitative comparison of SDTagNet with PMapNet (all info.) and SMERF (all info.) on Argoverse 2 in the far range setting. SDTagNet is able to utilize text-annotated information such as number of lanes and oneway roads to improve prediction results.}
\label{fig:qual_examples_supp_av2}
\end{figure}
\begin{figure}
\centering
\begin{subfigure}[t]{\linewidth}
\centering
\includegraphics[trim={0.0cm 0.0cm 0.0cm 0.0cm},clip,width=\linewidth]{pics/qualitative_example_supp_nusc_1_small.pdf}
%\caption{Incorrect crossing topologies for PMapNet and SMERF}
%\label{fig:qual_examples_supp_av2_1}
\end{subfigure}
\hfill
\begin{subfigure}[t]{\linewidth}
\centering
% trim={<left> <lower> <right> <upper>}
\includegraphics[trim={0cm 0cm 0.0cm 0.0cm},clip,width=\linewidth]{pics/qualitative_example_supp_nusc_2_small.pdf}
%\caption{Ex 2.}
%\label{fig:qual_examples_supp_av2_2}
\end{subfigure}
\hfill
\begin{subfigure}[t]{\linewidth}
\centering
% trim={<left> <lower> <right> <upper>}
\includegraphics[trim={0cm 0cm 0.0cm 0.0cm},clip,width=\linewidth]{pics/qualitative_example_supp_nusc_3_small.pdf}
%\caption{Ex 2.}
%\label{fig:qual_examples_supp_av2_3}
\end{subfigure}
\hfill
\begin{subfigure}[t]{\linewidth}
\centering
% trim={<left> <lower> <right> <upper>}
\includegraphics[trim={0cm 0cm 0.0cm 0.0cm},clip,width=\linewidth]{pics/qualitative_example_supp_nusc_4_small.pdf}
%\caption{Ex 2.}
%\label{fig:qual_examples_supp_av2_4}
\end{subfigure}
\caption{Qualitative comparison of SDTagNet with PMapNet (all info.) and SMERF (all info.) on nuScenes in the far range setting.
SDTagNet shows less errors and more consistent topology compared to previous methods.}
\label{fig:qual_examples_supp_nusc}
\end{figure}
%\subsection{Prior Supply Modalities}
%\label{subsec:prior_supply_modalitites}
\begin{thebibliography}{33}
\providecommand{\natexlab}[1]{#1}
\providecommand{\url}[1]{\texttt{#1}}
\expandafter\ifx\csname urlstyle\endcsname\relax
\providecommand{\doi}[1]{doi: #1}\else
\providecommand{\doi}{doi: \begingroup \urlstyle{rm}\Url}\fi
\bibitem[Caesar et~al.(2020)Caesar, Bankiti, Lang, Vora, Liong, Xu, Krishnan, Pan, Baldan, and Beijbom]{nuscenes}
Holger Caesar, Varun Bankiti, Alex~H. Lang, Sourabh Vora, Venice~Erin Liong, Qiang Xu, Anush Krishnan, Yu Pan, Giancarlo Baldan, and Oscar Beijbom.
\newblock nuscenes: A multimodal dataset for autonomous driving.
\newblock In \emph{Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR)}, 2020.
\bibitem[Carion et~al.(2020)Carion, Massa, Synnaeve, Usunier, Kirillov, and Zagoruyko]{DETR_2020ECCV}
Nicolas Carion, Francisco Massa, Gabriel Synnaeve, Nicolas Usunier, Alexander Kirillov, and Sergey Zagoruyko.
\newblock End-to-end object detection with transformers.
\newblock In \emph{European conference on computer vision}, pages 213--229. Springer, 2020.
\bibitem[Chen et~al.(2025)Chen, Wu, Tan, Ma, and Furukawa]{chen2024maptracker}
Jiacheng Chen, Yuefan Wu, Jiaqi Tan, Hang Ma, and Yasutaka Furukawa.
\newblock Maptracker: Tracking with strided memory fusion for consistent vector hd mapping.
\newblock In \emph{Computer Vision -- ECCV 2024}, pages 90--107, Cham, 2025. Springer Nature Switzerland.
\bibitem[Choi et~al.(2025)Choi, Kim, Shin, and Choi]{choi2024mask2map}
Sehwan Choi, Jungho Kim, Hongjae Shin, and Jun~Won Choi.
\newblock Mask2map: Vectorized hd map construction using bird's eye view segmentation masks.
\newblock In \emph{Computer Vision -- ECCV 2024}, pages 19--36, Cham, 2025. Springer Nature Switzerland.
\bibitem[Devlin et~al.(2019)Devlin, Chang, Lee, and Toutanova]{devlin-etal-2019-bert}
Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova.
\newblock {BERT}: Pre-training of deep bidirectional transformers for language understanding.
\newblock In \emph{Proceedings of the 2019 Conference of the North {A}merican Chapter of the Association for Computational Linguistics: Human Language Technologies, Volume 1 (Long and Short Papers)}, pages 4171--4186, Minneapolis, Minnesota, 2019. Association for Computational Linguistics.
\bibitem[Elghazaly et~al.(2023)Elghazaly, Frank, Harvey, and Safko]{Elghazaly2023hdmapsurvey}
Gamal Elghazaly, Raphaël Frank, Scott Harvey, and Stefan Safko.
\newblock High-definition maps: Comprehensive survey, challenges, and future perspectives.
\newblock \emph{IEEE Open Journal of Intelligent Transportation Systems}, 4:\penalty0 527--550, 2023.
\bibitem[Gao et~al.(2021)Gao, Zhang, Han, and Callan]{gao-etal-2021-scaling}
Luyu Gao, Yunyi Zhang, Jiawei Han, and Jamie Callan.
\newblock Scaling deep contrastive learning batch size under memory limited setup.
\newblock In \emph{Proceedings of the 6th Workshop on Representation Learning for NLP (RepL4NLP-2021)}, pages 316--321, Online, 2021. Association for Computational Linguistics.
\bibitem[Immel et~al.(2025)Immel, Fehler, Bieder, Pauls, and Stiller]{immel2025m3trgeneralistmodelrealworld}
Fabian Immel, Richard Fehler, Frank Bieder, Jan-Hendrik Pauls, and Christoph Stiller.
\newblock M3tr: A generalist model for real-world hd map completion.
\newblock \emph{IEEE Robotics and Automation Letters}, pages 1--8, 2025.
\bibitem[Jiang et~al.(2024)Jiang, Zhu, Li, Gao, Yuan, Shi, Zhao, and Zhao]{jiang2024pmapnet}
Zhou Jiang, Zhenxin Zhu, Pengfei Li, Huan-ang Gao, Tianyuan Yuan, Yongliang Shi, Hang Zhao, and Hao Zhao.
\newblock P-mapnet: Far-seeing map generator enhanced by both sdmap and hdmap priors.
\newblock \emph{IEEE Robotics and Automation Letters}, 9\penalty0 (10):\penalty0 8539--8546, 2024.
\bibitem[Kim et~al.(2022)Kim, Nguyen, Min, Cho, Lee, Lee, and Hong]{tokengt2022nips}
Jinwoo Kim, Tien~Dat Nguyen, Seonwoo Min, Sungjun Cho, Moontae Lee, Honglak Lee, and Seunghoon Hong.
\newblock Pure transformers are powerful graph learners.
\newblock In \emph{Proceedings of the 36th International Conference on Neural Information Processing Systems}, Red Hook, NY, USA, 2022. Curran Associates Inc.
\bibitem[Kim et~al.(2024)Kim, Seong, Ji, and Jang]{kim2024unveiling}
Nayeon Kim, Hongje Seong, Daehyun Ji, and Sujin Jang.
\newblock Unveiling the hidden: Online vectorized {HD} map construction with clip-level token interaction and propagation.
\newblock In \emph{The Thirty-eighth Annual Conference on Neural Information Processing Systems}, 2024.
\bibitem[Lambert and Hays(2021)]{av2_trust_but_verify}
John Lambert and James Hays.
\newblock Trust, but verify: Cross-modality fusion for hd map change detection.
\newblock In \emph{Proceedings of the Neural Information Processing Systems Track on Datasets and Benchmarks}. Curran, 2021.
\bibitem[Li et~al.(2022{\natexlab{a}})Li, Wang, Wang, and Zhao]{HDMapNet}
Qi Li, Yue Wang, Yilun Wang, and Hang Zhao.
\newblock Hdmapnet: An online hd map construction and evaluation framework.
\newblock In \emph{2022 International Conference on Robotics and Automation (ICRA)}, pages 4628--4634, 2022{\natexlab{a}}.
\bibitem[Li et~al.(2022{\natexlab{b}})Li, Wang, Li, Xie, Sima, Lu, Qiao, and Dai]{li2022bevformer}
Zhiqi Li, Wenhai Wang, Hongyang Li, Enze Xie, Chonghao Sima, Tong Lu, Yu Qiao, and Jifeng Dai.
\newblock Bevformer: Learning bird’s-eye-view representation from multi-camera images via spatiotemporal transformers.
\newblock In \emph{European conference on computer vision}, pages 1--18. Springer, 2022{\natexlab{b}}.
\bibitem[Liao et~al.(2022)Liao, Chen, Wang, Cheng, Zhang, Liu, and Huang]{maptr}
Bencheng Liao, Shaoyu Chen, Xinggang Wang, Tianheng Cheng, Qian Zhang, Wenyu Liu, and Chang Huang.
\newblock Maptr: Structured modeling and learning for online vectorized hd map construction.
\newblock In \emph{The Eleventh International Conference on Learning Representations}, 2022.
\bibitem[Liao et~al.(2024)Liao, Chen, Zhang, Jiang, Zhang, Liu, Huang, and Wang]{maptrv2}
Bencheng Liao, Shaoyu Chen, Yunchi Zhang, Bo Jiang, Qian Zhang, Wenyu Liu, Chang Huang, and Xinggang Wang.
\newblock Maptrv2: An end-to-end framework for online vectorized hd map construction.
\newblock \emph{International Journal of Computer Vision}, 2024.
\bibitem[Liao et~al.(2025)Liao, Chen, Jiang, Cheng, Zhang, Liu, Huang, and Wang]{lanegap}
Bencheng Liao, Shaoyu Chen, Bo Jiang, Tianheng Cheng, Qian Zhang, Wenyu Liu, Chang Huang, and Xinggang Wang.
\newblock Lane graph as path: Continuity-preserving path-wise modeling for online lane graph construction.
\newblock In \emph{Computer Vision -- ECCV 2024}, pages 334--351, Cham, 2025. Springer Nature Switzerland.
\bibitem[Lilja et~al.(2024)Lilja, Fu, Stenborg, and Hammarstrand]{Lilja2024CVPR}
Adam Lilja, Junsheng Fu, Erik Stenborg, and Lars Hammarstrand.
\newblock Localization is all you evaluate: Data leakage in online mapping datasets and how to fix it.
\newblock In \emph{Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR)}, pages 22150--22159, 2024.
\bibitem[Liu et~al.(2023)Liu, Yuan, Wang, Wang, and Zhao]{vectormapnet}
Yicheng Liu, Tianyuan Yuan, Yue Wang, Yilun Wang, and Hang Zhao.
\newblock {V}ector{M}ap{N}et: End-to-end vectorized {HD} map learning.
\newblock In \emph{Proceedings of the 40th International Conference on Machine Learning}, pages 22352--22369. PMLR, 2023.
\bibitem[Liu et~al.(2025)Liu, Wang, Yang, Li, Hu, Sun, and Gao]{liu2025controlmapdistributionusing}
Ziming Liu, Leichen Wang, Ge Yang, Xinrun Li, Xingtao Hu, Hao Sun, and Guangyu Gao.
\newblock Control map distribution using map query bank for online map generation, 2025.
\bibitem[Luo et~al.(2024)Luo, Weng, Wang, Wu, Li, Weinberger, Wang, and Pavone]{luo2023augmentingSMERF}
Katie~Z Luo, Xinshuo Weng, Yan Wang, Shuang Wu, Jie Li, Kilian~Q Weinberger, Yue Wang, and Marco Pavone.
\newblock Augmenting lane perception and topology understanding with standard definition navigation maps.
\newblock In \emph{2024 IEEE International Conference on Robotics and Automation (ICRA)}, pages 4029--4035, 2024.
\bibitem[{OpenStreetMap contributors}(2024)]{OpenStreetMap}
{OpenStreetMap contributors}.
\newblock {Planet dump retrieved from https://planet.osm.org }.
\newblock \url{ https://www.openstreetmap.org }, 2024.
\bibitem[Shi et~al.(2024)Shi, Cai, Chen, Pu, Fu, and Lu]{shi2024globalmapnetonlineframeworkvectorized}
Anqi Shi, Yuze Cai, Xiangyu Chen, Jian Pu, Zeyu Fu, and Hong Lu.
\newblock Globalmapnet: An online framework for vectorized global hd map construction, 2024.
\bibitem[Sun et~al.(2025)Sun, Yang, Lingrand, and Precioso]{sun2024mapex}
Remy Sun, Li Yang, Diane Lingrand, and Frédéric Precioso.
\newblock Mind the map! accounting for existing maps when estimating online hdmaps from sensors.
\newblock In \emph{2025 IEEE/CVF Winter Conference on Applications of Computer Vision (WACV)}, pages 1671--1681, 2025.
\bibitem[Wilson et~al.(2021)Wilson, Qi, Agarwal, Lambert, Singh, Khandelwal, Pan, Kumar, Hartnett, Pontes, Ramanan, Carr, and Hays]{Argoverse2}
Benjamin Wilson, William Qi, Tanmay Agarwal, John Lambert, Jagjeet Singh, Siddhesh Khandelwal, Bowen Pan, Ratnesh Kumar, Andrew Hartnett, Jhony~Kaesemodel Pontes, Deva Ramanan, Peter Carr, and James Hays.
\newblock Argoverse 2: Next generation datasets for self-driving perception and forecasting.
\newblock In \emph{Proceedings of the Neural Information Processing Systems Track on Datasets and Benchmarks (NeurIPS Datasets and Benchmarks 2021)}, 2021.
\bibitem[Xiong et~al.(2023)Xiong, Liu, Yuan, Wang, Wang, and Zhao]{xiong2023neuralmapprior}
Xuan Xiong, Yicheng Liu, Tianyuan Yuan, Yue Wang, Yilun Wang, and Hang Zhao.
\newblock Neural map prior for autonomous driving.
\newblock In \emph{2023 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR)}, pages 17535--17544, 2023.
\bibitem[Yang et~al.(2025)Yang, Yang, Tan, and Wang]{yang2025histrackmapglobalvectorizedhighdefinition}
Jing Yang, Sen Yang, Xiao Tan, and Hanli Wang.
\newblock Histrackmap: Global vectorized high-definition map construction via history map tracking, 2025.
\bibitem[Yang et~al.(2024)Yang, Jiang, Fan, Xie, Tan, Li, Ding, Wang, and Wang]{yang2024toposdtopologyenhancedlanesegment}
Sen Yang, Minyue Jiang, Ziwei Fan, Xiaolu Xie, Xiao Tan, Yingying Li, Errui Ding, Liang Wang, and Jingdong Wang.
\newblock Toposd: Topology-enhanced lane segment perception with sdmap prior, 2024.
\bibitem[Yu et~al.(2016)Yu, Suresh, Choromanski, Holtmann-Rice, and Kumar]{orf2016nips}
Felix~Xinnan Yu, Ananda~Theertha Suresh, Krzysztof Choromanski, Daniel Holtmann-Rice, and Sanjiv Kumar.
\newblock Orthogonal random features.
\newblock In \emph{Proceedings of the 30th International Conference on Neural Information Processing Systems}, page 1983–1991, Red Hook, NY, USA, 2016. Curran Associates Inc.
\bibitem[Yuan et~al.(2024)Yuan, Liu, Wang, Wang, and Zhao]{Yuan_2024_streammapnet}
Tianyuan Yuan, Yicheng Liu, Yue Wang, Yilun Wang, and Hang Zhao.
\newblock Streammapnet: Streaming mapping network for vectorized online hd map construction.
\newblock In \emph{Proceedings of the IEEE/CVF Winter Conference on Applications of Computer Vision (WACV)}, pages 7356--7365, 2024.
\bibitem[Zeng et~al.(2024)Zeng, Chang, Liu, Pan, and Wei]{zeng2024unifiedvectorpriorencoding}
Shuang Zeng, Xinyuan Chang, Xinran Liu, Zheng Pan, and Xing Wei.
\newblock Driving with prior maps: Unified vector prior encoding for autonomous vehicle mapping.
\newblock \emph{arXiv preprint arXiv:2409.05352}, 2024.
\bibitem[Zhang et~al.(2025)Zhang, Liu, Liu, Xu, Liu, and Zhao]{zhang2024hrmapnet}
Xiaoyu Zhang, Guangwei Liu, Zihao Liu, Ningyi Xu, Yunhui Liu, and Ji Zhao.
\newblock Enhancing vectorized map perception with historical rasterized maps.
\newblock In \emph{Computer Vision -- ECCV 2024}, pages 422--439, Cham, 2025. Springer Nature Switzerland.
\bibitem[Zhou et~al.(2024)Zhou, Zhang, Yu, Yang, Jung, Park, and Yoo]{Zhou_2024_CVPR}
Yi Zhou, Hui Zhang, Jiaqian Yu, Yifan Yang, Sangil Jung, Seung-In Park, and ByungIn Yoo.
\newblock Himap: Hybrid representation learning for end-to-end vectorized hd map construction.
\newblock In \emph{Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR)}, pages 15396--15406, 2024.
\end{thebibliography}