## Support #6409

### Use of geo reference and planView geometry

90%

**Description**

The OpenDRIVE 1.4 specification, in section 5.3.4.1 "Road Geometry Header Record," provides for only 2 coordinates for world coordinates of the start position, and the documentation states that these are the xy coordinates in the inertial system. Section 2.3.2 says that in the inertial system, the convention in x-east, y-north, and z-up.

Now in section 5.2.1, Geo Reference, there is a provision for including a proj4 string to describe...well, here's the problem. Normally, as I understand it, coordinate data from some source can have a proj4 string describing **the coordinate system the data is in**, and then that can be used with another projection description to convert the coordinates to the other projection. However, if the road geometry record must have only xy coordinates representing east and north, then the proj4 string in the OpenDRIVE file must be an ortho projection with lat_0 and lon_0 as the only parameters available to locate the OpenDRIVE origin on the earth. (Or possibly utm could be used, but the northing and easting offsets seem to be fixed for that projection.) Thus the geo reference is not very general, and it would not be possible to use, say, lat-lon (or worse, geocentric) as the coordinates in the geometry record.

Is this a correct understanding?

Thanks

**Related issues**

### History

#### #1 Updated by Douglas Reece 5 months ago

**Tracker**changed from*Bug*to*Support*

#### #2 Updated by Marius Dupuis 5 months ago

**Category**set to*general***Status**changed from*New*to*Feedback***Assignee**set to*Marius Dupuis***% Done**changed from*0*to*90*

I think the bottom line is:

In the geometry record of OpenDRIVE you may only use Cartesian coordinates for x/y/h. There is no way of putting lat/long directly into the geometry records.

The projection definition in proj4 format may be used only to convert from this Cartesian system to a geo-referenced system as per the actual projection string and vice versa.

My colleague, Andreas Richter, member of the OpenDRIVE core team, is added as watcher to this ticket. He might be able to explain this more professionally than I do.

#### #3 Updated by Douglas Reece 5 months ago

Marius Dupuis wrote:

I think the bottom line is:

In the geometry record of OpenDRIVE you may only use Cartesian coordinates for x/y/h. There is no way of putting lat/long directly into the geometry records.

The projection definition in proj4 format may be used only to convert from this Cartesian system to a geo-referenced system as per the actual projection string and vice versa.

My colleague, Andreas Richter, member of the OpenDRIVE core team, is added as watcher to this ticket. He might be able to explain this more professionally than I do.

So would it be fair to add, as a clarification in this section of the spec, that the proj string is a description of the Cartesian coordinate system that is used in OpenDRIVE, and thus should start with +proj=ortho, and it should be geo located to a place on the earth with +lat_0= and +lon_0= ?

Also, this means that a single OpenDRIVE file can only represent "accurate" geo referenced data over a "small" area, since due to curvature of the earth the surface of the spherical earth is already about 1m below this xy plane about 3.5km from the origin, I think? And by my calculations, at an xy about 64km from the origin, there is a 1m difference in the distance around the surface of the earth to the point under that xy.

I'm curious what various OpenDRIVE users with geo referenced data use for the proj string.

#### #4 Updated by Michael Scholz 5 months ago

# Projection type¶

Douglas Reece wrote:

[..] that the proj string is a description of the Cartesian coordinate system that is used in OpenDRIVE, and thus should start with +proj=ortho [..]

It has not necessarily to start with `+proj=ortho`

because this would restrict the projection to be an orthographic one. It can be any kind of a 2-dimensional projection defined in a Cartesian coordinate system. Fairly common is Universal Transverse Mercator (`+proj=utm`

), as stated in the example of the OpenDRIVE Specification 1.4H. But it could also be a Lambert Conformal Conic one (`+proj=lcc`

), which is widely used in countries of higher/lower latitude to cope with distortion problems when plotting onto 2D-surfaces.

It really depends on how the OpenDRIVE `<planView>`

geometries have been surveyed/derived/generated/transformed. Anyway, because all `<geometry>`

element descriptions (arcs, polynomials, spirals, whatever) are only valid in 2D Cartesian coordinate systems (on the flat plane), the given proj.4-string makes only sense when specifying such a 2D projection. The projection also defines the used distance unit which usually is "metres" but could also be "feet".

You should *not* specify "raw" 3D geographic/geodetic coordinate systems (like WGS 84) because this would require three-dimensional curve definitions for your geometries, which is not supported by OpenDRIVE. Specifying `x`

and `y`

of a geometry as pair of latitude and longitude in decimal degrees would simply be erroneous in such a case.

[..] Also, this means that a single OpenDRIVE file can only represent "accurate" geo referenced data over a "small" area [..]

I would say that a more or less accurate representation is always possible as far as you stick to the certain geographic extent for which a projection is valid. See "Example: UTM" below. Each projection has its specific latitudes and longitudes of origin and thus introduces one or more scale factors which indeed can lead to errors when "running out of the coordinate bounds" of a projection. Another case would be if you wanted to describe locations in Japan in EPSG:25832, which is valid only here in Europe.

[..] since due to curvature of the earth [..]

In general, this is basically one reason why such "complex" projections are used at all. You should always be able to perform a lossless reverse projection back into the underlying, three-dimensional geographic/geodetic coordinate reference system and apply a different projection if desired. This is where proj.4 reveals its power. It handles the "curvature" (through a combination of scale factors, e.g.) for you and all the other obstacles. But of course each projection introduces small coordinate errors. To be very-very-super-mega-ultra-monster-sure you can dive deep into literature to find the accuracy restrictions of projection methods and, if desired, you can define your own projection with all its mathematical overhead yourself. Most projections we talk about introduce *absolute* positioning errors in the magnitude of centimetres and decimetres. But, from my point of view, the more important point is the *relative* positioning of features which should have a lower magnitude of error.

# Latitude/longitude of origin¶

[..] and it should be geo located to a place on the earth with +lat_0= and +lon_0= ? [..]

Yes. The latitude of origin (`+lat_0`

) and longitude of origin (`+lon_0`

) actually *define* the certain projection you are using and can of course vary.

## Example: UTM¶

With the current version of proj.4 you can define a projection "UTM zone 32N" based on "WGS 84" (EPSG:32632) with

`+proj=utm +zone=32 +datum=WGS84 +units=m +no_defs`

which is a simplified version of saying

`+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=500000 +y_0=0 +datum=WGS84 +units=m +no_defs`

.

This "zone 32N" is valid for the western and central part of Germany. Mapping data from Berlin you would need "zone 33N" with a longitude of origin of 15° (`+lon_0=15`

):

`+proj=utm +zone=33 +datum=WGS84 +units=m +no_defs`

or`+proj=tmerc +lat_0=0 +lon_0=15 +k=0.9996 +x_0=500000 +y_0=0 +datum=WGS84 +units=m +no_defs`

respectively.

## Example: LCC¶

The latitude of origin is not always fixed to `+lat_0=0`

as shown by a common Lambert Conformal Conic projection for a beautiful representation of Sweden:

`+proj=lcc +lon_0=15 +lat_0=62.5 +lat_1=55 +lat_2=70 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs`

# False easting/northing¶

Imagine your application running on `float`

and not (yet) supporting `double precision`

. Quickly you run into trouble with coordinate values as used in UTM which likely have `y`

-values with already 7 digits left of the decimal separator. In proj.4 you could cope with that by introducing a custom coordinate offset which in the GIS domain is often called "false easting" (`+x_0`

) in case of an `x`

-offset and "false northing" (`+y_0`

) in case of a `y`

-offset. We can reduce coordinate magnitude of our abovely specified EPSG:32632 by shifting x -= 604763 and y -= 5792795, for example, as follows:

`+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=-104763 +y_0=-5792795 +datum=WGS84 +units=m +no_defs`

# Further reading¶

I highly recommend 'Datums and Map Projections' by Jonathan Iliffe and Roger Lott for compact and detailed insight into everything regarding spatial reference systems.

#### #5 Updated by Douglas Reece 5 months ago

Thank you for the detailed reply.

Re the projection string used in OpenDRIVE: "It can be any kind of a 2-dimensional projection defined in a Cartesian coordinate system." Agreed, "ortho" was too restrictive. Still, "Cartesian coordinate system" is required.

Re coordinate accuracy: "This is where proj.4 reveals its power. " and "You should always be able to perform a lossless reverse projection back into the underlying, three-dimensional geographic/geodetic coordinate reference system " Yes, I have to agree this is true, so if your simulation does its kinematic calculations based on local positions... what I mean, for example, is that a delta of one meter in x between points in a UTM OpenDRIVE file far from the origin doesn't represent 1 meter on the surface of the earth, but the simulation can know the correct delta when it projects the points onto the earth's surface.

With this thought in mind, here's a thought-- maybe the start points defined in the geometry elements could be anything that can be projected to the earth's surface, and then the curves are treated as being in a plane that is locally tangent to the geometry start point.

The background for my questions is that I am importing roads from various sources where locations are typically specified in geodetic coordinates, and I would like to export to an OpenDRIVE file; in the simulation, geocentric coordinates are typically used because operations over the whole earth are supported. The OpenDRIVE data will therefore be converted to something else for use by the simulation anyway. It would be convenient to store simulation coordinates in the OpenDRIVE file to avoid the conversion on import.

However, each road data set should be limited in extent, so it should be possible to pick a lat-lon for an origin and then generate Cartesian coordinates for an OpenDRIVE file, with a separate file for each data set.

#### #6 Updated by Andreas Richter 5 months ago

**Related to***Feature #5412: Global offset definition*added

#### #7 Updated by Marius Dupuis 5 months ago

**Category**changed from*general*to*specification 1.5*

To be handled in a clarification within the specification.