Import terrain heights (contour lines) from XML

[magomar]

Nowadays we have at our disposal very precise digital elevation models. I think it would be really useful for scenario developers to have a way to import this information automatically into the Command Ops maps editor. Perhaps the easiest approach for Panther Games would be to allow importing the contour lines from an external XML file. This would save a lot of time and would increase the accuracy of the maps. Given the vectorial nature of the information handled by Command Ops, I guess such XML might have a format similar to this:

<Map>
<AltitudeLayers>
<Layer altitude="80">
<Polygon .... />
</Layer>
</AltitudeLayers>
</Map>

Allowing such a representation would make it very easy for the community to create external tools to export digital elevation models into that XML format. I would for example create a tool to transform data from GeoJSON format into the given XML format in a matter of days. I would also be pleased to share my knowledge about how to generate contour lines with the community around Command Ops in the form of a tutorial.

¿What do you think?

 

[Daz]

Awesome

 

[john connor]

Absolutely!

 

[Dave 'Arjuna' O'Connor]

Re the tutorial. Go for it.

Re implementing this feature. It's a great idea and one we have had on our wish list for some time. It's all a question of priority. It won't make this initial release of CO2. But I do like it and so will aim to get it implemented sooner than later. That's all I can commit to for now.

 

[magomar]

OK Dave
I would be pleased to write such a tutorial once the feature is added.
Regards,

 

[Dave 'Arjuna' O'Connor]

Just a question about the polygon. In the MapMaker the layer is in fact a series of polygons and each poly is a series of points. Initially these were just what we call control points (ie simple X.Y number pair) but these tended to provide a fairly stepped look. So we added Bezier points to enable the user to make the line curvy. It's been a while since I last ventured into the GIS standards. Do you know if they support Bezier points?

 

[magomar]

I'm not an expert, but as far as I know bezier curves are not supported by common GIS vector formats. Usual geometry features supported are points, lines, polylines and derivatives.
I have done googling to find out more on the subject and it seems some GIS accept curves as geographic objects, but typically they only support linear interpolation, and only a few formats support specifying real curves (WKT, PostGIS).

However, in my opinion not having bezier curves when generating contour lines using a GIS should not be a problem. On the one hand, nowadays there are digital elevation models (DEM) available with very good resolution (a few meters), so linear interpolation would be enough to produce smooth contour lines. On the other hand, some GIS can apply smoother algorithms to generate contour lines.

 

[GoodGuy]

On the one hand, nowadays there are digital elevation models (DEM) available with very good resolution (a few meters), so linear interpolation would be enough to produce smooth contour lines. On the other hand, some GIS can apply smoother algorithms to generate contour lines.

Yes, a 30-meter Level 2 USGS DEM has a vertical accuracy of 1-3 meters in NON-mountainous terrain, which makes displaying/analyzing of slopes very accurate/easy, but the 10-meter DEMs are really outstanding (not sure if the 10- meter Level 2 DEMS are widely available, 10-meter DEMS covering the terrain of the USA were made in 2005, and I remember seeing a news report in German TV that during the last 5 years the ISS has produced a lot of DEMs based on radar scans of the earth, where they used some German equipment to some extent, but I think focus was on scanning unknown or badly mapped areas (bottom of the Pafific ocean for example), but I remember seeing some DEMs covering Europe, too.
For relatively flat areas (cities, basins/valleys), DEMs based on 1-meter LIDAR data are to be preferred, not sure if they're publicly available.

Conclusion by PR Blackwell (Information Scientist, Forest Resources Institute, Arthur Temple College of Forestry, Stephen F. Austin State University) and Gordon Wells (Texas Strategic Mapping Program, Texas Natural Resources Information System):

Digital elevation models are available in a variety of horizontal and vertical resolutions. The 100-meter DTED1 data have been replaced by more accurate and useful 30-meter Level 2 DEMs available from the USGS. The 30-meter profile DEMs provide a generalized rendering of landforms appropriate only for regional studies at the scale of several thousand square kilometers. For hydrologic modeling, these surfaces perform poorly in areas of moderate topographic variation and not at all in flatter areas. 10-meter profile DEMs capture considerably more geomorphological detail and are appropriate for areal studies at 1:24,000 scale. Drainage enforcement improves the performance of 10-meter DEMs in many cases by more clearly delineating stream courses. The surfaces of low-lying and extremely flat areas may not be adequately represented using DEMs created using hypsography data extracted from 1:24,000 scale USGS topographic maps. LIDAR technology offers a method to collect more accurate and detailed elevation data, but the datasets are large, need to be carefully filtered and may present problems for current software applications.

http://proceedings.esri.com/library/userconf/proc99/proceed/papers/pap629/p629.htm
http://proceedings.esri.com/library/userconf/proc99/proceed/papers/pap592/p592.htm

 

[magomar]

An an example, now I am working in a project using a 5m resolution DEM (LIDAR). The generated curves are pretty smooth, as you can see in the picture below. In this case the altitude values belongs in [474m..778m], so the range is 302m. Since the game allows only 16 altitude levels, then we need to generate contour lines every 20 meters to cover the entire range

By the way, it would be very nice to be able to have more than 16 levels. This restriction means it would be impossible to accurately model scenarios with wide altitude ranges, especially the areas of craggy or steep terrain. So I would also ask to increase the number of altitude levels if that is possible. I think that 16 levels of color is enough to give players a visual hint, but it doesn't imply the engine should be restricted to that number.

 

[Dave 'Arjuna' O'Connor]

The reason why there is the restriction on the number of layers is that is the max we could fit into the data size we originally set. It's historical. Back in 1996 when we implemented the map structures computers were no where as powerful as they are today. We had to design the game so it could run with minimal RAM and processing speed. Hence why we used every 'bit' of the data and I hate 'bit' arithmetic functions. So I did not do this lightly. To get more we need to change the data structures. It's that simple. It's a big job because it will change a lot of things in the code. If we do go ahead with this change we will probably opt for something like 255 layers, rather than the current 31. I would prefer to ditch the 'bit' and use a standard integer type. That will blow out the memory requirements though, probably by a factor of 62 or 128 times the current memory we use to store the maps. But that should be OK.