2

DB_REF is the official reference system for german federal railways - Deutsche Bahn (DB). For a description, see here: http://download-data.deutschebahn.com/static/datasets/aufzug/DB_REF.pdf (german)

The document mentions several EPSG codes, see below. However, trying to view any coordinates given in DB_REF (the actual EPSG code is missing very often), i come up with a position offset of 100m - 500m:

enter image description here

This is elevator dataset (http://data.deutschebahn.com/dataset/data-aufzug) in DB_REF assumed CRS is EPSG:5683, compared with OSM tiles and railway line network (http://data.deutschebahn.com/dataset/geo-strecke), provided in EPSG:4326 (map projected to EPSG:3857). Elevators should be placed on the platforms, between the lines.

Same offset issue occurs when I attempt to save my own data in DB_REF using QGIS - they get an offset to external DB_REF data.

Am I missing any DB_REF CRS? Or could the DB_REF definitions used by QGIS be wrong?

EPSG codes:

  • 1081 Deutsche Bahn Reference System
  • 5825 DB_REF geocentic
  • 5826 DB_REF to ETRS89
  • 5681 DB_REF geografic 2D
  • 5830 DB_REF geografic 3D
  • DB_REF / 3-degree Gauß-Krüger
    • 5682 zone 2 (E-N)
    • 5683 zone 3 (E-N)
    • 5684 zone 4 (E-N)
    • 5685 zone 5 (E-N)
  • DB_REF / 3-degree Gauß-Krüger+DHHN92 height
    • 5832 zone 2 (E-N)
    • 5833 zone 3 (E-N)
    • 5834 zone 4 (E-N)
    • 5835 zone 5 (E-N)
Improve this question

2 Answers 2

Reset to default
3

The DB_REF definitions in QGIS are wrong (at least in QGIS2).

They are missing any +towgs84 parameter, which is necessary for the DHDN datum.

Instead of EPSG:5683, take EPSG:31467 which has the correct datum shift values.

The linked document lists datum shift values that differ from EPSG:31467, so you might use these PROJ strings instead:

For GK2:

+proj=tmerc +lat_0=0 +lon_0=6 +k=1 +x_0=2500000 +y_0=0 +ellps=bessel +towgs84=584.9636,107.7175,413.8067,1.1155214628,0.2824339890,-3.1384490633,7.992235 +units=m +no_defs

For GK3:

+proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel +towgs84=584.9636,107.7175,413.8067,1.1155214628,0.2824339890,-3.1384490633,7.992235 +units=m +no_defs

For GK4:

+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +towgs84=584.9636,107.7175,413.8067,1.1155214628,0.2824339890,-3.1384490633,7.992235 +units=m +no_defs

Comparing with datum transformations with BETA2007 and EPSG:31466, DB_REF is about half way between them. BETA2007 is 1.2 meters away, ESPG:31466 0.5 meters.

Improve this answer
4
  • That seems to work, but how can I be sure it's truly accurate? I get no official information on DB_REF except for the document cited above. The wrong definition of DB_REF is widely spread, covering QGIS 3, epsg.io (epsg.io/5683) and other EPSG registries.
    – fuzzysolutions
    Commented Oct 24, 2018 at 9:56
  • 1
    You find the correct datum shift in the document you linked under (4).
    – AndreJ
    Commented Oct 24, 2018 at 12:26
  • So this contains alle the information I need to build my own proj4string for a custom CRS definition in QGIS? Great. I'll dig into it and try. I have to shelve the topic a little bit, but I'll come back with my results.
    – fuzzysolutions
    Commented Oct 30, 2018 at 11:17
  • 1
    Related: github.com/OSGeo/proj.4/issues/1167
    – AndreJ
    Commented Oct 31, 2018 at 16:31
1

Solved in PROJ master (https://github.com/OSGeo/proj.4/issues/1167) - correct DB_REF will be available to QGIS users after PROJ version 6.0 is rolled out on 2019/02 (- or by building PROJ-master and GDAL from source).

Thanks to AndreJ for the issue on PROJ and his remarks to my post.

Improve this answer
7
  • But only with current PROJ master, or not?
    – AndreJ
    Commented Dec 13, 2018 at 7:14
  • Yes, and PROJ master is being installed with current QGIS installations / updates, right?
    – fuzzysolutions
    Commented Dec 13, 2018 at 9:10
  • No, current builds come with the latest PROJ release version 5.2. Master is the base for the next release version 6.0. And it needs a new GDAL release version as well. Until then, you have to compile PROJ and GDAL from master sources yourself to get the changes.
    – AndreJ
    Commented Dec 13, 2018 at 9:33
  • See my edit of my answer.
    – fuzzysolutions
    Commented Dec 13, 2018 at 9:53
  • If you type gdalsrsinfo EPSG:5683 inside the OSGEO4W shell, do you get datum shift parameters?
    – AndreJ
    Commented Dec 13, 2018 at 14:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.