Skip to content

netconvert: Improve --heightmap.geotiff#17473

Merged
behrisch merged 3 commits intoeclipse-sumo:mainfrom
opatut:improve-heightmap-geotiff
Mar 15, 2026
Merged

netconvert: Improve --heightmap.geotiff#17473
behrisch merged 3 commits intoeclipse-sumo:mainfrom
opatut:improve-heightmap-geotiff

Conversation

@opatut
Copy link
Copy Markdown
Contributor

@opatut opatut commented Dec 29, 2025

This pull request adds a few improvements for people who want to use the heightmap feature to generated 3D coordinates:

  • add --offset.z to the value read from the heightmap input (otherwise it is unused, so this way you can offset the input data properly)
  • use float instead of integers when reading a heightmap (gdal converts this for us)
  • read the spatial reference from the geotiff file and use it for projection, so you don't have to manually (and lossily) convert the file first by reprojection (e.g. gdal raster warp)

I've also thrown in a change that uses bilinear interpolation instead of the previous triangle logic for interpolation of the raster data. It seems to produce the same results (rounded to centimeters) on my data and is probably faster to execute, and simpler to understand :) You can skip that commit if you like, it is refactoring only and adds no user benefit, but I prefer the cleaner logic and simpler math.

…coordinates for lookup

This adds support for geotiff input data in UTM projection, among
others, and avoids an additional step to reproject the geotiff data to
WGS84 (by using `gdalwarp`, for example), which adds a resampling step
that introduces inaccuracy.
@namdre
Copy link
Copy Markdown
Contributor

namdre commented Jan 2, 2026

Thanks! Can you check whether your ECA is in order? (https://sumo.dlr.de/docs/FAQ.html#how_do_code_contributions_work)

@opatut
Copy link
Copy Markdown
Contributor Author

opatut commented Jan 5, 2026

There was an issue while filling out the ECA, I've contacted the licensing team to resolve it. Will post here once it's done.

@opatut opatut force-pushed the improve-heightmap-geotiff branch from 0e2ca7b to 04f2ef2 Compare January 7, 2026 10:40
@opatut
Copy link
Copy Markdown
Contributor Author

opatut commented Jan 7, 2026

It seems like I didn't test it well, and there is an issue with my bilinear interpolation change, producing incorrect heights. I've removed that commit from this PR and will work on it some more, independently. The rest still works fine.

@behrisch behrisch self-assigned this Jan 15, 2026
@behrisch behrisch merged commit ea146fa into eclipse-sumo:main Mar 15, 2026
25 of 75 checks passed
@behrisch
Copy link
Copy Markdown
Contributor

behrisch commented Mar 15, 2026

Thanks! @opatut If you have an example we can add to our tests, it would be more than welcome.

@opatut
Copy link
Copy Markdown
Contributor Author

opatut commented Mar 16, 2026

I've been using heightmap files from the German state of Baden-Wurttemberg's state office of geo information, which are licenced rather openly, so you might be able to integrate them:

https://opengeodata.lgl-bw.de/#/(sidenav:product/dgm1)

They come in EPSG:25832 (UTM zone 32N) by default, so projection is necessary.

Combine this with an OpenStreetMap excerpt, and you got your test dataset. This is from my Makefile:

netconvert \
  --verbose \
  --sidewalks.guess \
  --crossings.guess \
  --heightmap.geotiff $(HEIGHTMAP) \
  --offset.x -$(ORIGIN_X) \
  --offset.y -$(ORIGIN_Y) \
  --offset.z -$(ORIGIN_Z) \
  --proj.utm=true \
  --geometry.max-segment-length=4 \
  --ptstop-output=$(OUTPUT)/osm_stops.add.xml \
  --ptline-clean-up \
  --ptline-output=$(OUTPUT)/osm_ptlines.xml \
  --railway.topology.repair \
  --output-file $(NET_FILE) \
  --osm-files $(OSM_FILE) \
  --keep-edges.in-geo-boundary $(BOUNDS)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants