Improving interoperability between OpenDRIVE HD map data and GIS using GDAL
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 156 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/68483 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
FOSS4G Europe 2024 Tartu65 / 156
6
33
35
53
55
59
61
67
70
87
97
99
102
103
104
105
107
111
121
122
123
124
125
126
127
128
134
144
150
151
155
00:00
System programmingTransportation theory (mathematics)Online helpLatent heatBranch (computer science)Computer simulationPublic domainNetzwerkdatenbanksystemComputer animation
00:42
Twin primeDigital signalSimulationPublic domainCartesian coordinate systemOpen setSimulationDivisorOrder (biology)Computer animationLecture/Conference
01:01
Twin primeDigital signalSimulationSpacetimeSoftware developerDigitizingCASE <Informatik>Computer simulationTwin primeFile formatSimulationCore dumpSoftware frameworkOrder (biology)Mobile WebLatent heatComputer animation
01:41
Cycle (graph theory)Error messageLine (geometry)Parametrische ErregungSpiralCurvatureAbstractionLibrary (computing)Raster graphicsVector spaceFile formatLevel (video gaming)Software developerMappingGroup actionSimulationPublic domainData modelCartesian coordinate systemLatent heatJunction (traffic)Validity (statistics)Open sourceGeometryProcess (computing)CASE <Informatik>Open setLine (geometry)Link (knot theory)Element (mathematics)Mobile WebAnalytic continuationTexture mappingObject-oriented programmingAutonomic computingProfil (magazine)MultilaterationAuthorizationHierarchySheaf (mathematics)GeometryFile formatVector spaceIntegrated development environmentSoftwareLibrary (computing)Computer simulationBitBridging (networking)PolygonString (computer science)Point (geometry)Focus (optics)Context awarenessSign (mathematics)SphereDifferent (Kate Ryan album)Semantics (computer science)Machine learningMultiplication signBelegleserOrder (biology)Self-organizationStandard deviationFront and back endsFunction (mathematics)Core dumpComputer fileParameter (computer programming)CausalityCurveInformationLengthConsistencyComplex (psychology)Parametrische ErregungTheory of relativityDistanceFunctional (mathematics)Clique-widthLinearizationArc (geometry)SpiralDescriptive statisticsLipschitz-StetigkeitInclusion mapMetrePolynomialRaster graphicsCubic functionConstraint (mathematics)Computer animationDiagram
10:15
Sampling (music)Library (computing)Discrete groupGeometryAnalytic continuationSampling (statistics)Open setRule of inferenceLipschitz-StetigkeitComputer animation
10:36
Computer simulationGeometryCurvatureIntegrated development environmentOpen setLine (geometry)Element (mathematics)InformationComputer simulationDifferent (Kate Ryan album)Computer fileString (computer science)GeometryPoint (geometry)Lipschitz-StetigkeitPolygonMedical imagingCurveRandomizationDiscrete groupSystem dynamicsMappingProjective planeOnline helpRepresentation (politics)Computer animation
12:53
Standard deviationVector spacePersonal digital assistantMathematicsSharewareComputer animation
13:15
SharewareExecution unitSoftwareOpen sourceAttribute grammarRule of inferenceFile formatCategory of beingSoftwareDifferent (Kate Ryan album)Open setWeb 2.0PrototypePresentation of a groupOrder (biology)Computer fileDrop (liquid)Overlay-NetzGeometryService (economics)Medical imagingFile viewerLevel (video gaming)Link (knot theory)Standard deviationLipschitz-StetigkeitComputer animationPanel painting
15:32
Data conversionLinear subspaceAsynchronous Transfer ModeSpacetimeArithmetic progressionVisualization (computer graphics)Open setValidity (statistics)Lipschitz-StetigkeitTransportation theory (mathematics)Source codeBitAreaSelf-organizationMedical imagingPerspective (visual)View (database)Order (biology)Computer simulationModule (mathematics)CollaborationismFile viewerFile formatStructural loadWebsitePublic domainAttribute grammarComputer fileLatent heatSoftware developerSoftwareContext awarenessImplementationDescriptive statisticsProjective planeGroup actionUniverse (mathematics)Physical systemMobile WebPlug-in (computing)Computer animation
18:59
Order (biology)Projective planeComputer simulationString (computer science)Data modelBitDemosceneDecimalCurveStreaming mediaSoftwareLevel (video gaming)AuthorizationData conversionDatabaseNumberOpen setResultantMereologyMappingMobile WebText editorPosition operatorFitness functionAutonomic computingGeometryObject (grammar)Module (mathematics)Descriptive statisticsLine (geometry)File formatEmailUnified threat managementUniverse (mathematics)Lecture/Conference
23:43
Computer-assisted translationLeast squaresComputer animation
Transcript: English(auto-generated)
00:00
I'm happy to be here. Hello everybody. So I will be presenting my experience of writing a GDAL driver together with the help of my colleagues Oliver and Gülschen. And yeah I'm from German Aerospace Center but from the Institute of Transportation Systems in Braunschweig and we have a nice set of playground research infrastructure to develop things and to do
00:24
actually hands-on research. And I will be talking about a very specific road network modeling format. It's OpenDrive and first of all I will give you some introduction of where OpenDrive is used and then the steps involved in getting it into the GIS domain.
00:43
So yeah let's take a look on the applications. So for example OpenDrive is very often used in different simulation aspects. This is a snapshot from a driving simulation like cooperative simulation with traffic participants like cyclists and pedestrians and we do a lot of
01:00
human resources, human factors research in order to see how people and humans behave in traffic and mobility. So this is for urban digital twin creation of the road space you need specific automotive engineering formats and one of it could be OpenDrive. Another example would be
01:23
traffic simulation. Probably some of you are involved in that and there are various traffic simulation software frameworks. One of them is Sumo which is also developed by DLR. And another core use case would be all the development involved around automated driving.
01:42
So you for sure need sensors in cars but also in the development stage cars very often require HD maps and so here very often there is a transition from the simulation domain into the automated driving where also OpenDrive plays a key role and very often OpenDrive
02:00
data is used also in automated driving. So what is then in the end OpenDrive? So it's a format to describe highly detailed road networks and HD basically there are many different definitions but basically it consists of a lane detailed model of the road environment.
02:20
So you have all the lanes, cycleways and also information about the traffic infrastructure, the markings, the signals and signs and whatever you're interested in depending on the application in the end. And the core, the most important thing probably is not that you have only geometric elements but you have also like semantics included. So you have links between
02:42
a traffic signal to a certain lane or a stop line and the colleagues from University of Tartu, they gave a nice introduction to this whole complex thing from the autonomous driving lab earlier this day. So there's a nice talk you can also watch.
03:03
It gives you a nice introduction and yeah when it comes then to the HD topic what is HD like high definition. There are also very different application definitions so very often it's something around the global referencing of the whole HD map sphere between 10 and 20 centimeters
03:23
globally and that's mostly sufficient at least for autonomous driving. But yeah in order to get this data you probably will not find it publicly available in such a detail so you very often have to subcontract mobile mapping companies which then go out with mobile mapping devices, cars with
03:44
lighter scanners and collect all the necessary data for you. So this is expensive and slow because in most times all the annotation of the features you require is not done with AI or machine learning. It's mostly manual annotation and it then takes like up to three months to
04:02
get a strip of 10 kilometers of road and then it's outdated already. So it's a very yeah stupid situation very often and recently I've been involved in many initiatives with public authorities, various cities Hamburg and Munich in Germany where there is a transition
04:20
of between this automotive domain, automotive engineering domain and the yeah public authorities and public authorities very often use GIS workflows and this specific open drive format which is it's an open format standardized by an ASAM organization in Germany but it's still very sophisticated and it does not fit well into GIS workflows and very often you either have
04:45
open drive want to get it into the GIS or you have cadastral data which you want to be able to export to open drive and both is not very trivial and yeah this is some kind of gap and we tried to at least bridge these domains a little bit by providing a g.driver for this
05:03
ASAM open drive format and I will show you how this open drive looks like. So basically let's focus on the main important topic. So it's the geometry. So usually in GIS context you deal with discrete coordinates so you have simple feature points line strings and polygons so you
05:22
have a discrete coordinate my traffic sign is located at latitude longitude whatever and an open drive it's a little bit different so everything it originated in the driving simulation domain so everything is bound to road reference line which is basically modeled in the middle so it can have a very sophisticated geometric course and everything else is basically
05:43
attached in relation to it so if you had a traffic sign it would not be at latitude longitude whatever but it would be at a distance linear reference along the reference line with an offset to the side of I don't know four meters whatever and these are the local coordinates the s and the t offset and so also this applies for the lanes so the lane is not modeled as a
06:05
polygon it just described by the width from this reference line and all this can be described in parametric polynomial functions mathematical functions basically and you have various kinds of geometric elements you can have line strings and spirals and arcs
06:25
and polynomials and in the end it all originated from the idea of having like a smooth road to follow if I send an automated traffic on this road so that it really turns smoothly and not has any sharp gaps in turning and if we look in detail in some kind of geometry
06:47
definition so this open drive data model is very complex and it's yeah mainly transferred in xml files and here you basically have if you have a geometry description of a
07:01
parametric polynomial so you have the parameters of the cubic polynomial and then you have x and y discrete coordinates where this starts and then you have a parameter this could be the length of this whole curve which is then described together with the parameters it's describing the course of a reference line and this makes it a little bit complex to get it
07:23
into the gis domain natively and it superimposes some weird like modeling constraints so if you want to have a consistent road network without any problems during your simulation if you compute any traffic simulation on that you have to make sure that you don't have any gaps and
07:42
that you don't have oops that was the wrong button that you don't have any overlaps because for the simulation this would not be a problem but in the end you want to visualize it so you want to have a nice 3d export of your road network and then it will mess up with the textures so in the end you will have something like this so you need to make sure that you have
08:03
a continuous geometry definition and in the end it's a hierarchical data model so the main core is always a road and then you have all the elements below so this would be the geometry tag where the geometry is happening but you have elevation profiles you have lateral elevation profiles you have cross fall and all this included in the data format and the most complex
08:25
thing will be then messing with all the lanes and lane sections and then the lanes again have some links to predecessors and so it's all about this semantic linking between all the elements so you have links on the road level you have links on the lane level then you have validity
08:45
of signals and then you come to junction and elements where then you again experience linkage from incoming to outgoing lanes and that's pretty yeah interesting so this is all required for the specific application use cases and we just wanted to make it easier at least to be able
09:05
to load data into the gis for example if i'm a public authority and i get such data formats from my automotive companies which for example want to send an autonomously driving shuttle through my very city so they should at least cooperate with me and then i get this data and i cannot
09:24
do anything with it so for that we tried to extend gdol and it went pretty well gdol most of you probably know i do not have to talk very much about it so it's a fancy processing library for yeah converting through and forth between raster and vector data formats and i would suggest
09:47
that yeah most of open and proper tools rely on gdol in the back end and it has a big community and the core thing of gdol is the of the vector format is the simple feature
10:00
vector format and the idea is to transform all the complex open drive geometries into ogc simple features and in yeah for doing that we did not reinvent the wheel we tried to reuse already available open source software and for that there exists a library called lip open drive it's developed it was or it is developed near karth rule karth rule in germany and it's
10:26
openly available on the apache 2.0 license and this basically does all this yeah discretization or sampling of the continuous geometries into simple features and this looks like that then so here would be a snippet of some random geometry elements in open drive not necessarily describing
10:45
this very nice curve here but what we want to achieve is like simple feature points forming a line string in simple features so lip open drive is now doing this already for us it exposes all these discrete coordinates for us and with that we are basically done so we just need
11:03
to grab the data from lip open drive and put it into gdol where the fancy simple feature model is populated and then we get something what we can work with like everybody should know the way known text representation of line strings and with that we can progress further and put the
11:21
data into our gis and it would look like this for example so this would be a lane border layer directly read from an open drive xml file and yeah there are different mapping types so this is what is currently supported by lip open drive and our gdol driver so you have point elements representing signals you
11:43
have line strings for reference lines and these lane borders here and we have polygonal aerial image data for the actual polygons of lanes and for example the road mark the white markings are also represented as polygons so it took us some while to get this driver working
12:05
but we got a superb help from evan from the gdol project and he assisted us and me very much in getting the driver at least where it's now it will be included soon in the next release
12:21
and first of all many attempts did not really result in our open drive being successfully detected as available driver but then finally we managed to do it and we had this open drive thing and here you it's a very important thing that when you talk about as an open drive to capitalize the drive because it's an actually acronym for open dynamic road
12:44
information for vehicle environment and most people don't know that but it's then very misleading if you don't do it so it looked like that this is very recent uh we created a pull request to merge our changes and it was a hot discussion around that
13:01
i learned so many things about gdol and how to yeah work with it how it works internally and thank you again for that for all the assistance and the guidance um and yeah i think it will be hopefully included in gdol 3.10 release and here i have a small demo how it looks like so in the end the dream would be to be able to drag and drop open drive files
13:23
into qjs so here we have an aerial image in uh waltzburg in germany and i previously created a geo package with gdol with our driver from the open drive and if i drag and drop it here you will see that these are all the different layers available from the driver and we are
13:40
interested in lanes and road marks and signals so you can just simply load it as you yeah would probably do with any other data source and then apply basic styling rules in order to get it to look like a road network and so probably i do not have to tell you how this works best
14:02
but this would be like a quick and easy going approach of the usage of the driver and so you can do various stylings you can also publish this as open web map later on as web feature service to expose the geometries you have all the attributes from the original open
14:23
drive included and whatever is missing can still be extended by extending lip open drive so we have the lanes with the properties and that's basically it so you can get started very easily to prototype the data set you've got and to overlay it with your aerial images and
14:43
that's basically what was our goal and i think we are nearly achieving it step by step so for sure there are also other tools for open drive data mostly there exists proprietary software there are many different proprietary tools we heard about mathworks roadrunner before in the
15:04
previous presentation this morning but there's also the three and three three and three d builder and they are very often very expensive and have limited interoperability with gis workflows but what i can highly recommend to you if you're working with open drive and the
15:20
data formats around that visit this link there you have a nice collection of tools and data and everything around open drive and open scenario and all the other formats standardized by azzam consortium and one of it is a pretty well known open drive viewer it's a website where you can drag and drop your open drive files and get a basic rudimentary
15:42
3d visualization also with access to all the attributes and this one is like using the lip open drive back end which we are using too so it's developed by the same guy who developed open drive and whenever we now want we extended actually we extended lip open drive in order to pass the signals which have not been included previously and we contributed that and he included
16:05
into his lip in his open drive viewer directly so that was already nice collaboration and there is a lot of work going on and technical university of munich they a few years ago released a very sophisticated transportation module to ogc ct gml 3.0 and there is a
16:24
nice tool it's called eartron which takes open drive and loads it into ct gml into this very new transportation area model a transportation model and it comes with a very sophisticated validation on open drive data so it's really powerful and this feature for example is not
16:42
offered by lip open drive so yeah that was basically it our experience we made it into some progress getting the driver into gda and the next steps would be so what is still missing so this driver is a plugin based driver so you need as a user you
17:04
need to supply a release of lip open drive you can find the source code on github but you basically have to compile it yourself or use one of the docker images provided by by gda right now and we would like to create some binary releases ready for it for the user
17:21
for the users soon and there's a new initiative going on so this azzam organization is uh yeah now we will have in july a ideation workshop on this transportation area concept where we want to bring open drive and ct gml 3.0 a little bit further together this is open
17:42
to the public you can register and we are open for new stakeholders and views and perspectives on onto the whole topic and we try to make a proposal to start a new research or like an implementation project in order to uh yeah i don't know create some kind of an open drive 2.0
18:00
whatever something which is better bound to gis context and gis workflows and city gml is a very fruitful way i would say where to go also there is an ogc there will be spawned probably a new transportation mobility domain working group it's just in the making i would say and all this topic will also be included there hopefully and uh yeah so in my
18:27
research area of transportation systems there is not only autonomous driving there are also rail network description formats we already heard in my colleagues talk today something about rail ml and there are some more formats and with this plug-in ability of gda we could
18:44
provide very nice and neat uh yeah ways of bridging these very domain specific narrow-minded formats and communities with the gis domain and this little bit the playground i'm working on and that's basically it thank you very much questions is there any um effort looking into
19:18
maybe going the other way to writing at least some of the base parts of open drive from osm
19:24
or some of the other formats like that um very good question this is a very frequent demand i had a talk with the university of tattoo the guys from the autonomous driving lab they are able to export open drive from something open stream map like data it's called yeah they have
19:42
their own data model but there are converters from there's a format called lane let very simple description of hd road network data sets which is based on the open stream data model so there are some community modules for exporting but it's a very complex topic because you have to
20:01
provide all this data model with the referencing the the internal relationships between all the objects then you if you really want to get continuous geometries like i described in open drive you have to implement like mathematical curve fitting of the lane borders of the reference lines of the elevation model and this is not trivial so i would dream of a qgs plugin to do
20:25
that so maybe we are not so far from that that'd be cool people are burnt out i expected more questions who has worked with open drive before two people great okay joe then feel free
20:57
to contact me later maybe yeah we talked earlier and yes i had the same demand or
21:02
or wish that is there an opposite way driver that we have some kind of database and to convert it to yeah but as it is that the open drive is quite complicated and uh and yeah the initial data can be in very different formats so you need to agree what is the initial start position
21:21
to convert it to open drive and it's but things are moving yeah and i try to connect the different initiatives so in germany there are also an university base many things going on and the public authorities are now uh yeah seeing getting or realizing the demand of somehow
21:41
yeah being able to work with such data because the automotive industry is pushing and also requesting so the automotive companies go to the city municipalities and tell them hey you have nice cadastral data can you export it as open drive no so you have to manually model
22:01
it in one of those proprietary editors and um yeah but then they very often these editors they are focusing on american road networks so the layout of the exported open drive will not be how you expect it to be in germany so yeah you see the problem and maybe the demand of a
22:23
new community around that is it always in projected coordinates very good question i didn't say anything about that um yes open drive is only valid in cartesian two-dimensional coordinates and the open drive has a header the xml where you can include a projection like
22:43
approach for string pretty old-fashioned but at least you can specify your custom utm projections also with false easting false northing which is very often used in order to get this hd map scene into your city wherever you want to have it and then it
23:00
works well yeah you might need a bit more to get that really high 20 centimeter you know accuracy uh we should not talk too much about accuracy because this is always the automotive companies they are demanding like one centimeter of accuracy and then uh the mobile mapping companies
23:20
they say yeah we can provide that but nobody's really double checking if the result is really as accurate they just get data they are happy and in the end it's 20 centimeters they can drive they can simulate it's all fine they just increase the number of decimal places yeah probably yeah any further questions okay thank you very much thanks