Closed zwkcoding closed 3 years ago
I searched on google "utm vs enu", then I got the answer from this reference
The advantage to using Scene ENU for scene construction is that the entire scene can be quickly relocated by simply changing the geographic location corresponding to the Scene ENU origin. If an absolute geographic coordinate is used to position every object, then every object needs to be modified to relocate the scene.
So, Is it the reason ? btw, ENU could express more large scope than UTM, another consideration ?
Hi, the main coordinate system within ad-map-access is a global one: ECEF. That was chosen to have a global coordinate system that is Cartesian to easily calculate distances (i.e. required for map-matching). Geo coordinates are another form to describe the global coordinates, but is mainly used to provide input/output, not much for actual calculations. Therefore, these coordinates were applied to import the OpenDrive description of a road, because an OpenDrive map also often refers to real global map data (not necessarily artificial maps like the ones provided from CARLA).
But neither ECEF nor Geo coordinates are suited to actually work with when focusing on local driving. There, the "round" (or not so round) earth surface is put into a plane Cartesian coordinate system, because the curvature of the earth is neglectable in local regions. For this, the ENU coordiante frames are used. While driving though the world, you might come closer to the borders of this local coordinate system in the sense that the error would increase. Therefore, on a ride between Berlin and Madrid you would every now an then moving the GeoReference point of your coordinate system, so that your ENU coordinates never exceed e.g. 50km. By doing this in ad-map-access, the map in the background with ECEF coordinates stays the same. Only the ENU cooridinates you get reported by CoordinateTransform change. For fast access to ENU coordinates of the map data, the lane points have cached ENU coordinates. If the Geo-Reference for the ENU coordinate frame changes, the caches are recalculated. And the usual transformations taking place while using the data are ECEF->ENU and ENU->ECEF.
That's in short the design decisions of the coordinate frames in ad-map-access.
And you have to rather compare the UTM to Geo coordinate system, because UTM is global, but not Cartesian. And like this also not very much usable for simple distance calculations. And you don't want to use sin/cos or the like if you just can perform vector arithmetic's in a Cartesian system. Therefore: ECEF for global coordinates to store and perform internal calculations, ENU for coordinates on a local plane to actually work in the local environment and you plan a path along a road in front...
Bernd.
because UTM is global, but not Cartesian.
@berndgassmann I'm confused about this sentence. As i searched on google, many sites said that "UTM coordinates are already the best approximation of a cartesian X,Y plane you will achieve."
ref 0:
This is just like the X Y Cartesian coordinate system you learned high school math class. Simple Cartesian coordinate mathematics can be used.
ref 1:
Universal Transverse Mercator (UTM) is a map projection-based global coordinate system that provides location information using pairs of Cartesian coordinates in metric units (metres). UTM offers location information in a coordinate system (2-D cartesian) that offer a simpler calculation environment than its most popular 3-D polar counterpart (Latitude and Longitude).
what's more, Apollo Auto use UTM , ref to this link.
Therefore, what is the reason chosen ENU rathen than UTM from your perspective ?
You are in general right. UTM is global and within a zone Cartesian. When you see it from high level it could replace ECEF and ENU at the same time, which would make it easier internally. The question would be how to handle traversal between the zones. When reading in your first link, there is also talked on:
However, the UTM projections suffer from ambiguities at the meeting of two grids zones and general distortions for large areas and distances. Although UTM could be used to position a plane or satellite, as it moved from one grid zone to another, the relative position will be prone to errors
And we want to be able to drive with cars also across the zone borders. For sure, with ENU you even have to change the GeoReference of you ENU coordinate frame more often while driving, than you would probably have to using UTM. Maybe I overlook here something, and the zone borders are also easy to handle within UTM. But when using ENU you can select the GeoReference dynamically and drive always within the inner area of you coordinate system and never have to reach the "border".
I have to admit, that I was not involved in the initial design of core heart of ad-map-access with the core map-database structures, including the three Coordinate Systems used. I was for sure heavily involved in building all the access parts around (intersection, route, opendrive import, ...) and reshaping the core heart implementation, but I never did question the core design. The core design had also an idea on tiling to be able to load/unload map tiles (PartitionID in the Factory can be used for this) , but we never required it to that extend.
But Apollo Auto is also defining an ENU system if looking here. And if UTM is actually 2D (the hight seems to be defined as the elipsoid height, when reading in the Apollo doc), how you then handle different hights of roads (bride, tunnel, etc.). So maybe these are hints why the design of ad-map-access is like it is.
Interesting discussion though :-)
True, these are just two options. I asked my friends on different autonomous vehicle companies in China, there exist both options. I learnt a lot from your long and sincerely reply, nice man , Bernd @berndgassmann
I will close this issue at now.
@berndgassmann Hi :smile: As mentioned in the title, from the doc link or code repo where there is
CoordinateTransform
class exist., I know carla map chosen Coordinate Reference Systems (CRSs).But, why not choose UTM ? it's easier to convert opendrive data coordinate to UTM in just one step using PROJ lib than here method which convert to WGS84 lat/lon from opendrive data first, then convert to ECEF, then convert to ENU.