artik: is the GlobCover data really just one huge TIF file covering the entire Earth (GLOBCOVER_L4_200901_200912_V2 .3.tif)? How do you read that? My PhotoShop elements chokes on it. Or is GeoTiff a different thing from .tif?
Shorelines are a pain. As you point out the various formats don't give you really good / exact shoreline detail.
Basically you have two manual ways to deal with this at the moment.
I hadn't done any gradients yet, it is all 0 or 255, but it is work in progress.
I would say I am to lazy to but its more a case of not having a program to do it for me.
Oh quick question so does this program only handle a scale of 1:1 (1 game mile equals 1 real mile) or can handle differing scales say 1:1.5 (1 game mile equals 1.5 real miles) and so on? Some times for game play reasons designers you differing scales from 0.75:1 to 2:1.
What set of SRTM did you use? SRTM3 or SRTM30?
Color really plays a big part on how we interpret things. On your screen shot looks like buildings off to the side but on your build there is water there. I check google maps and it shows water but when I go to satellite view looks like grassy to me until I zoom in and see it is very, very, very green water.
Artificial surfaces and associated areas
1) For the waterc.bmp file your are writing the land area to the file (white pixels). This is unnecessary the only thing that should be in this file is the different colors for water. So if you do not change any of the water colors the whole file should be black. If you change just say one lake to a different color then everything should be black but that lake.
2) On the scaling of the maps. Not sure if I am doing something wrong (or missed reading something) but I picked a central point, set map size to 512, and set the scale to 0.75, 1.0, and 2.0 but the output was the same each scale setting (changing the scale from 1.0 to something else didn't seem to do anything). At least for my test of centering a map on Tokyo.
lat 35.6895
lon 139.6917
scale 1.0
I can get it to scale if instead of using a central point I set lat1, lat2, long1, long2 ... basically know before hand what a 1.5 scale would be and pick the correct points for them. Just the central point method doesn't seem to only do a scale of 1.0.
I don't know if what affect it will have. Will have to test it out. Normally the waterc.bmp is pure black when you start a fresh terrain. Your right it shouldn't make a difference since the area is land but I have never see what effect if any have the land in the waterc.bmp (white) does or doesn't do.
However, when I do my test using the coordinates for Rabaul in New Britain and Tokyo it crashes when it comes to elevation.
Are you affiliated with MIT?
This is the default path right now, however the spaces in the path name are not readable by the program.
I particularly like what you've done with the ground types.
Yes, the ground clutter showing along the shore in the TE is distracting but it won't show in the final terrain in-game.
To me, seeing deep ocean anywhere on land is the sign of an unfinished terrain. This is particularly important along the rivers.
QuoteTo me, seeing deep ocean anywhere on land is the sign of an unfinished terrain. This is particularly important along the rivers.
Note, you can change a color of lakes and rivers - so your rivers would look more natural. In any case I wanted to add
some water depth reduction but hadn't time to implement it yet.
river_correction_limit eliminate river that require too deep canyons. i.e. if during the elevation slope correction the river needs an altitude drop above X feet, it wouldn't be rendered - allowing user to prefer having more rivers or having deeper canyons.
Quick question on the river_correction_limit does it eliminate the whole river or does it eliminate the just the sections of the river that don't fit the correction limit you picked?
If it removes the whole river then I definitely like that you supply a removed_rivers.bmp that lists all of the rivers that had been removed. That way as a designer can go back and restore parts of the river on more flat terrain if I like (do a partial restore).
I suspect that you initiate the gndtype.bmp to 00 00 00 everywhere. Instead, initiate it to 11 11 11 grass and continue unchanged.
... than I would set it to grass or beach, but only on boundary not in general.
When you set the gndtype.bmp color for land along a water edge to 00 00 00, that is an error. Use the globcover value if you can. HTC solves this problem by setting the underlying ground type at all water = grass. It's not perfect but it's not as annoying as making it deep ocean and it also works at rivers reasonably well.
For river pixels that have too steep a slope to be legal why not just change that pixel to ground and set the corresponding ground type to rock to make it look like non-navigable rapids or cascades or a dam, while allowing the upstream river pixels to stay if they don't violate the slope limit? In other words, after rasterizing the vector water data post process the pixel data to fix the too steep water. Of course that would mean PT boats would be limited to traveling upstream only to the first such obstacle, but I doubt that would be an important limit, and the real river might not be navigable at that point anyway.
Personally I think carving a narrow deep canyon for the river would look really odd.
Also, do you have an answer yet about the registration problems with shorelines. If you read the info file about how the water vectors were generated they were purposely correlated with the SRTM elevation data to insure shorelines had at least a 1 m elevation change to "contain" the water and this analysis is what lead to the water vector data. (It would have made it so much easier for us if they had just saved the water as pixel data of the same resolution as the SRTM elevation at that point, but they didn't.)
I should think that anyone who appreciates Artik's work, and would like him to finish his tool, would not want to distract him with anything that might get in his way
Now if I look on the first row - I actually like the way water looks in the left column much more - no unnatural gradient seen (square edges in the water) - but this is a matter of taste. The only case that I think having the ground type for water when you have detailed water but non-detailed terrain.
Can you please give me the reference so I can read about it as well?
Also note - there is no correlation problems with shorelines (i.e. sea, lakes, isles) the problem with the rivers that is a separate dataset in the same collection (GSHHS)
So far as for 715's idea, I haven't come up with visually pleasing way (ntt0011.bmp) for land area connecting river segments via land textures that look rapids. Also as pointed out earlier the pixel resolution for waterd is different than for gndtype (165 feet per pixel in waterd and 660 feet per pixel for gndtype) which results in fuzzy edges. Which might not be to bad if you are thinking of the area as swampy or rapids or something with an ill defined water edge. Personally I haven't come up with anything I like.
I am able to see what the rivers would have been like and it makes it very easy for me to reconstruct just the bits I want that don't cause problems.
One thing I haven't gotten around to testing yet is the water width variable. If I set say the width to 3 pixels is it this width for the whole river? Or will it taper down to 1 pixel near the head waters of the river?
Doing a Halloween party tonight, so I will post up my testing results of the new program tomorrow.
So far as for 715's idea, I haven't come up with visually pleasing way (ntt0011.bmp) for land area connecting river segments via land textures that look rapids. Also as pointed out earlier the pixel resolution for waterd is different than for gndtype (165 feet per pixel in waterd and 660 feet per pixel for gndtype) which results in fuzzy edges. Which might not be to bad if you are thinking of the area as swampy or rapids or something with an ill defined water edge. Personally I haven't come up with anything I like (others might be fine with it, will post screen shots later).
1. Detailed water & Detailed terrain
2. Detailed water & NOT detailed terrain
3. Neither water nor terrain are detailed.
There is a document file (Product Specific Guidance v2.0 12 Mar 03jas.doc) added to every single SRTM water body data zip file (the vector data in shape file format). There is also a much more detailed explanation in another file included with every shape file zip (SRTM Edit Rules v2.0 12 Mar 03.doc). These both mention rivers as having 1 m "banks" as well as the DEM data being guaranteed to be monotonic for rivers (i.e. guarantees water flows continuously downhill). (This second doc file is ridiculously large and it, rather than the actual shape file data itself, is what sets the size of the zip download.)
There is yet another option you might check first.
4. Detailed water OFF & Detailed terrain ON.
This is my preference and it accomplishes the same thing
Basically Artik I just do an abbreviated river. I just reconstruct the river up to the point I just start to run into to many elevation issues that I think are to extreme (creating grand canyons). So basically I am able to reconstruct rivers that start at the foot hills of mountains and then run down a plain to the shore. I just do without the river part in the mountains.
// Width Type CountIgnore the counted segments. I don't think they're accurate since I've rebuilt the database for my personal use and if I remember correctly, I took the counts in the middle of that project.
// 5 0 (-55) x Unknown INVALID Type, there are no river type zero anymore.
// 5 1 2381 x Permanant Major River
// 4 2 4438 x Major River
// 3 3 7553 x Additional River
// 2 4 8985 x Minor River
// 1 5 (+55) x River Lake
// 2 6 246 x Double line river
// 4 7 877 x Intermittent River - major
// 3 8 977 x Intermittent River - additional
// 2 9 0 x Intermittent River - minor
// 2 10 107 x Major canal
// 2 11 93 x Lessor canal
// 0 12 0 x not used
// 2 13 242 x Irragation canal
// 0 14 0 x Users Local Stream
Also the whole river was the same width. I did expect this but would probably go in after your program creates the waterd.bmp file and manually taper the river at its header waters down to one pixel to give it a better aesthetic look.
I set it to river_width 4 which resulted in all rivers being 9 pixels wide on waterd.bmp. I was expecting it to be 4 pixels but what seems to have happened is that it took the original river (1 pixel wide) and then added 4 pixels to each side resulting in 9 pixels. Not sure if that is the proper behaviour / functionality but it wasn't what I expected.
You might choose to use the same river width system I developed. The width is in pixels.
When you say fully automatic downloads does this also include the srtm3, srtm30, etc. elevation files? Or just the other files used to figure out land versus water, coastlines, rivers, etc.?
I can tell you that about every year or two, the USGS has changed the address for downloading these data files. I strongly recommend that all the paths be placed in the config file instead of in the code so that they can be changed by the user in the future.
I hadn't noticed that but there is a problem with it, the download_sources.txt file.
When opened with Notepad, unlike your other txt files which open fine, the download_sources.txt file's endOfLine value doesn't seem to be quite right.
...
Very nice.
Once you have the grid numbers for the sectors though you might need to do some tweaking on those to make sure they are legible against the terrain (differing colors and such). Grid lines are fine while you might need a slightly darker color for the sector numbers once you have them.
A possible future enhancement would add variables to the config file or to a csv (like you did for gndtype) that allows the designer to set color values for various parts of the clipboard map. What you have is great and is really all most need. Just for the people who like to tweak it would be a thought.
I will say that comparing the different elevation files that srtm3 is now the way to go. Much, much, much better detail and resolution (you easily see the difference in the elevation file and the CBM map created)
Artik -- what language is this written in? Can you possibly put the code on GitHub (http://www.github.com) so that other people can contribute? I can help if it's in C/C++/C# or compiled Python. :salute
very interesting, are you considering updating this tool for the new terrains when they come out?
Well, you do know the altitude resolution will probably go to 4K but that's an easy change as the SRTM3 files are already about 8K.
You should put this on Github so that others can see source and fork it
edcftp.cr.usgs.gov/data/gtopo30/global/
Artik,
I found an alternate source for the GTOPO30 resource that was taken offline at
Try this URL:
http://www.webgis.com/terr_world.html (http://www.webgis.com/terr_world.html)
The global cover link needs to be updated to:
due.esrin.esa.int/files/GLOBCOVER_L4_200901_200912_V2.3.color.tif (http://due.esrin.esa.int/files/GLOBCOVER_L4_200901_200912_V2.3.color.tif)
Just experimenting and get this error:These files get moved every year or two. Look in the "download_sources.txt" file for the the sources list. You will need to do a web search for "gshhg-bin-2.3.6.zip" Once you find the new link-location, fix the line in the text file.
https://www.ngdc.noaa.gov/mgg/shorelines/data/gshhg/latest/gshhg-bin-2.3.6.zip
The file doesn't exist on the noaa site. Is there a fix?