This was a tough one:
I tried hard to do something similar to "Delta", but even if I did try for days to work with actual stellite images they looked nice as hudmap, but didn't work as heightmap-material or even as colormap. (Maybe I'll manage to find a solution later on.)
I think what I finally did is even more callenging than "Delta" but quite similar concerning the difficulty of a tight curvy road with a rough terrain around it. My new map therefore lies somewhere between "Delta" and "Mountain Pass". It's still possible to get back to the road if you lost the way, but often it isn't easy.
The vegetation hopefully isn't too much. I tried to lighten it up as far as possible while keeping the feeling of a tropic island.
Liviu, I hope you like it. I wanted to design a map fitting to at least some aspects of your wishlist...
Thanks! Excellent off-road track. It somewhat recalls me Ghats (road bumpiness), Volcano island (narrow road + easiness to fall off), Tobago (atmosphere), and Mountain Pass (difficulty to get back on track). In all, nice combination for a tricky track. :)
As for satellite images, this is an old idea of mine that I never brought to completion. Could we use some OSM-based services ( http://wiki.openstreetmap.org/wiki/List_of_OSM_based_Services ) to obtain height/altitude maps of real earth places? Specifically, the following two seem promising:
- inViu routes ( https://sso.enaikoon.de/SSOServer/?locale=en&demo=1 ), provides "altitude graph"
- OSM-3D ( http://www.osm-3d.org/ ), provides "Virtual Globe with SRTM terrain data"
Do any of those services provide terrain images (height maps) that we could directly use in track creation?
Another OSM page of interest for us is: http://wiki.openstreetmap.org/wiki/Relief_maps
So far I didn't find any satellite images with heightmaps. All of them are made with hill shading or contour lines to look good to us. Therefore they are useless for determining proper height levels.
The inViu link doesn't lead me to any map data.
The OSM-3D link doesn't open on any of my browsers at all...
Right, I see what you mean. What about http://www.osm-wms.de/ ? It loads fine here. Is it useful for us? I guess not, though..
Iwan, are we using some specific height-map data/protocol? Do we adhere to a standard of sorts?
What about Maperitive: http://maperitive.net/ . In addition to hill shading or contour lines, they provide Elevation Coloring. Is that useful for us?
Yes, the new link loads, but there seems to be no simple elevation map as well.
Maperitive seems to be free in the monetary sense only since the author prohibits the distribution of altered software versions: http://maperitive.net/docs/FAQ.html#Commercial%20use
Of course this wouldn't limit our use, but I didn't try the software yet.
An other issue with real data is the fact, that we would need to seriously change it if we want to get data we could use in a tiled layout for avoiding unrealistic gaps in our maps. As well real data include buildings and other stuff Trigger Rally can't handle well. Of course we could go for completely wild areas (without huge trees) only, but I guess that leaves us with very limited map material out of the large earth surface.
Thinking about these limitations I'm not so sure any more if it would be very promising to use real satellite data.
Agreed, satellite data would be difficult. But I was thinking that as far as our maps are concerned, we're only interested in raw terrain elevation data. And I think those can be obtained, only if we new what to look for in OSM-derived products.
Our reference manual includes: "greyscale png file for setting the elevation levels of the map. Dark areas are lower than bright ones. " Are these using a specific format/standard?
Related question. I saw that we can use Geomorph to generate terrain data. What exactly does it export to?
I'm asking because I'd like to ask on the OSM lists whether we can obtain data for our tracks, but I'm not sure how it should be worded.
I didn't check this, but how gets map data without objects into existance? I assume the elevation data is collected automatically. How does the software know what data should be ignored or replaced by some (or what?) other value? A skyscraper for instance.
I red Iwan's map tutorial and observed how our height maps are formatted. From that information I wrote the xml tutorial. Therefore I don't know if the Trigger Rally height map definition relates to any standard.
Where did you read something about Geomorph? I didn't see any reference to that so far. This could be an important thing to mention in the map tutorial...
The Tutorial mentions Geomorph: http://trigger-rally.sourceforge.net/tutorial/
Oh, ok - sorry. I didn't remember this program Iwan mentioned because I saw no reason to use an other program if I could just use the render function in GIMP.
As far as I can see Geomorph just exports 16 bit grey scale png files only. (GIMP is limited to export 8 bit png files.)
Could we mention the "8/16 bit grey scale png files" for height-maps in the Reference manual?
Iwan Gabovitch (qubodup)
"8/16 bit grey scale png files"
I don't understand. Why is this relevant? Does one of the two not work?
I mean that there are various ways to display height information (shading, contours, etc.). It would be useful if the reference manual indicated that for our purposes the height information can be encoded in "8/16 bit grey scale png files".
At least in the map guide this information is present already:
If it's 8/16 bit isn't really relevant in normal cases. At least this detail would need some further explanation if we mention it...