I have changed the title of the blog as I am moving the focus away from CFS3. I still have a long term project in mind for CFS3. However as I have mentioned in previous blogs, water body data matching coastlines is a bit of a problem with higher resolution terrain mesh. Presently the only solution is hand editing water body data. As to CFS3 it may be best to use lower resolution mesh. That will be determined by experimentation. MAW looks as if it used SRTM 30 or early SRTM 90M interpolated with GTOPO30 dem data. The islands are much smoother than SRTM 90M v3, as are the coasts. Thus mesh at a lower resolution may work a little better.
Anyway I have started a Europe2 project for CFS3 with a rough timetable of approximately one year. I have already created a mesh sans water bodies, land class and vector data. It is slightly larger, about the same size as MAW, and a little bit further north of the current ETO theatre and will accommodate mainland Britain and Denmark, plus little bits of Norway & Sweden (no Orkney Islands unfortunately). Any water body editing that I do will be useful in other projects in the world of GIS.... not necessarily flight simulations. A couple of hours every other day is planned for coastline editing.
I have other simulations in mind in addition to or instead of CFS3. In the meantime personal circumstances take precedence. When I discover something of note or have something to show I will post. But I anticipate posts will be somewhat haphazard. I am in quite a bit of pain with cancer which is affecting my ability to sit at a computer at present.
Until then....
cheers
Rob
Sunday, July 6, 2008
Wednesday, July 2, 2008
CFS3 Terrain Mesh - Myths, Misconceptions & Problems: Part 1
One thing about being virtually the only person presently 'dabbling' in CFS3 terrain creation is the frustration I experience in getting others to apprehend exactly how the terrain system works.
Firstly having participated in the ETO expansion project there was a misconception that the mesh is incorrect or problematic. Actually the SRTM terrain mesh was probably the only geographically correct data in the project. SRTM 90m version 3 finished data, was downloaded from CGIAR. This data was derived the Shuttle Radar Topography Mission, an 11 day shuttle mission in 2000.
The only problems that can occur with this data are voids or the occasional spike. However as CGIAR's data is version 3, these problems have been largely corrected. Global mapper was used to compile the relevant SRTM files into one large DEM file for the ETO geographic area. Global Mapper is limited in it's terrain editing abilities. One can flatten certain areas by creating a vector polygon and assigning an altitude to it. This is useful for getting rid of features such as breakwaters etc., that may not have existed during WW2 or perhaps creating ones that did. There were a number of negative elevations in the SRTM data for the ETO area, for below sea level areas. I did change minimum elevation to 0 metres in the master DEM as the CFS3 SDK tools calculate all mesh elevations in the final CFS3 mesh between 0 and the maximum elevation specified on the command line input. Apart from that there was little adjustment to carry out. I did carry out a number of experiments in scaling the elevations in the mesh slightly and also experimented by flattening the terrain mesh under the water bodies to make the terrain match the mesh in certain area. However the result was very artificial looking and not proceeded with.
The DEM meshes were exported from Global Mapper as a large *.bil file. When exporting a series of SRTM dem tiles into a single large DEM in GM I find it is best to leave interpolate unchecked in the export options. Leaving this checked causes seams and ridges in CFS3. This is about the only thing that could possibly go wrong.
The the end result was virtually an un modified SRTM V3 90M mesh, processed in accordance with CFS3 terrain SDK guidelines. Once decisions have been made it takes my computer approximately 6 hours to compile a terrain mesh, apart from experiments there is very little else to do. Apart from experimentation, and computer time compiling a very easy task. Water on the other hand is a very different story.
In previous posts I explained the problems in using the newer and more complex SRTM V3 data with old data in CFS3. Essentially an ETO terrain mesh revision was doomed from the start, without changing all other data ie roads, railways, rivers, water bodies. Nothing will line up. These were not terrain mesh problems. For everything to work correctly everything would have to be redone. Also GSL facilities of various types placed close to the coast distorted the mesh and warped the water polygons. Airfields with incorrect altitudes on the gsl caused mounds, dips and spikes in the terrain. Invariably the 'nasty' mesh (LOL) was blamed for this. GSL problems could possibly have been easily fixed using Global Mapper to import CSV data from the GSL worksheet and re-exporting as text csv files and back into Excel. I'll be using GM to map the GSL on my own projects (if I get around to them LOL).
I did create new water body mesh which was still WIP at decision time. I've described problems in doing so elsewhere. The linked PDF verifies what I have found http://www.scenerysolutions.com/doc/SRTMData.pdf Essentially any water bodies have to be hand modified or created. I was in the process of doing so. Unfortunately the shorelines had yet to be created leaving a jaggy water mesh interfacing with the terrain. There was also misconception that the rivers and water bodies were not correctly placed. The same goes for them as the SRTM data. The data on top of them were incorrect rather then the WB's themselves.
I do think at the end of the day the ETO team were correct not to go ahead in using the SRTM3 mesh given all the problems and time available. I fully agree with that decision and am glad to be relieved of the pressure in my current circumstances. A revised terrain project requires that everything be built from the ground up i.e. terrain mesh, water mesh, river, road, railway vectors, terrain textures, landclass, vector data for ai vehicles and terrain exclusions, and the global scenery layer on top of everything else. Realistically speaking an effort exceeding a year and more than one person. If I were to go through all that I would probably choose a new area. Hopefully if I do involve myself in a future project the guys I work with will have a clearer understanding of the CFS3 terrain system and how everything intermeshes.
Now that the ETO team have decided not to use my mesh, whether and how I'll tackle water is a decision for the future and I will be concentrating on my own projects if do proceed ie different areas from the CFS3 ETO. The number one problem is to find a cure for water spikes in headlands etc, which are caused by lower terrain lods poping in and out as one approaches them. I have a few experiments in mind. Also smoothed matching coastline data is worth big $ - another consideration. One could earn a bit of money if one were to do this for other markets. If I were to spend time and do that, should I do that for CFS3 or some other product(s)? Payware is unlikely to be viable for CFS3 and this a lot of time for a freeware project - when I should be focussing on aircraft, where at least I have had some offers from publishers in the past. I tend to think that CFS3 will have problems with complex coastlines and high resolution meshs regardless - however I'll experiment further.
Sadly Ed Wilson the only other person that I know of, apart from Microsoft and myself, to work with terrain mesh in CFS3, recently passed away after a long battle with cancer. Ed created the terrain for the MAW project (a massive task), Korean Skies and more recently the Solomons PTO. I'll be having a look at how Ed tackled the shoreline issue in these projects, especially in complex areas. I'll have a look at bridges and rivers in the projects too to see how they were tackled. I do know that he encountered the same problems I have with water mesh spiking, in the PTO project though I can recall reading that he solved it. It will be nice to spend a bit of time flying in these addons.
Rob
Links:
CGIAR SRTM details and links http://srtm.csi.cgiar.org/
NASA SRTM home - http://www2.jpl.nasa.gov/srtm/
Firstly having participated in the ETO expansion project there was a misconception that the mesh is incorrect or problematic. Actually the SRTM terrain mesh was probably the only geographically correct data in the project. SRTM 90m version 3 finished data, was downloaded from CGIAR. This data was derived the Shuttle Radar Topography Mission, an 11 day shuttle mission in 2000.
The only problems that can occur with this data are voids or the occasional spike. However as CGIAR's data is version 3, these problems have been largely corrected. Global mapper was used to compile the relevant SRTM files into one large DEM file for the ETO geographic area. Global Mapper is limited in it's terrain editing abilities. One can flatten certain areas by creating a vector polygon and assigning an altitude to it. This is useful for getting rid of features such as breakwaters etc., that may not have existed during WW2 or perhaps creating ones that did. There were a number of negative elevations in the SRTM data for the ETO area, for below sea level areas. I did change minimum elevation to 0 metres in the master DEM as the CFS3 SDK tools calculate all mesh elevations in the final CFS3 mesh between 0 and the maximum elevation specified on the command line input. Apart from that there was little adjustment to carry out. I did carry out a number of experiments in scaling the elevations in the mesh slightly and also experimented by flattening the terrain mesh under the water bodies to make the terrain match the mesh in certain area. However the result was very artificial looking and not proceeded with.
The DEM meshes were exported from Global Mapper as a large *.bil file. When exporting a series of SRTM dem tiles into a single large DEM in GM I find it is best to leave interpolate unchecked in the export options. Leaving this checked causes seams and ridges in CFS3. This is about the only thing that could possibly go wrong.
The the end result was virtually an un modified SRTM V3 90M mesh, processed in accordance with CFS3 terrain SDK guidelines. Once decisions have been made it takes my computer approximately 6 hours to compile a terrain mesh, apart from experiments there is very little else to do. Apart from experimentation, and computer time compiling a very easy task. Water on the other hand is a very different story.
In previous posts I explained the problems in using the newer and more complex SRTM V3 data with old data in CFS3. Essentially an ETO terrain mesh revision was doomed from the start, without changing all other data ie roads, railways, rivers, water bodies. Nothing will line up. These were not terrain mesh problems. For everything to work correctly everything would have to be redone. Also GSL facilities of various types placed close to the coast distorted the mesh and warped the water polygons. Airfields with incorrect altitudes on the gsl caused mounds, dips and spikes in the terrain. Invariably the 'nasty' mesh (LOL) was blamed for this. GSL problems could possibly have been easily fixed using Global Mapper to import CSV data from the GSL worksheet and re-exporting as text csv files and back into Excel. I'll be using GM to map the GSL on my own projects (if I get around to them LOL).
I did create new water body mesh which was still WIP at decision time. I've described problems in doing so elsewhere. The linked PDF verifies what I have found http://www.scenerysolutions.com/doc/SRTMData.pdf Essentially any water bodies have to be hand modified or created. I was in the process of doing so. Unfortunately the shorelines had yet to be created leaving a jaggy water mesh interfacing with the terrain. There was also misconception that the rivers and water bodies were not correctly placed. The same goes for them as the SRTM data. The data on top of them were incorrect rather then the WB's themselves.
I do think at the end of the day the ETO team were correct not to go ahead in using the SRTM3 mesh given all the problems and time available. I fully agree with that decision and am glad to be relieved of the pressure in my current circumstances. A revised terrain project requires that everything be built from the ground up i.e. terrain mesh, water mesh, river, road, railway vectors, terrain textures, landclass, vector data for ai vehicles and terrain exclusions, and the global scenery layer on top of everything else. Realistically speaking an effort exceeding a year and more than one person. If I were to go through all that I would probably choose a new area. Hopefully if I do involve myself in a future project the guys I work with will have a clearer understanding of the CFS3 terrain system and how everything intermeshes.
Now that the ETO team have decided not to use my mesh, whether and how I'll tackle water is a decision for the future and I will be concentrating on my own projects if do proceed ie different areas from the CFS3 ETO. The number one problem is to find a cure for water spikes in headlands etc, which are caused by lower terrain lods poping in and out as one approaches them. I have a few experiments in mind. Also smoothed matching coastline data is worth big $ - another consideration. One could earn a bit of money if one were to do this for other markets. If I were to spend time and do that, should I do that for CFS3 or some other product(s)? Payware is unlikely to be viable for CFS3 and this a lot of time for a freeware project - when I should be focussing on aircraft, where at least I have had some offers from publishers in the past. I tend to think that CFS3 will have problems with complex coastlines and high resolution meshs regardless - however I'll experiment further.
Sadly Ed Wilson the only other person that I know of, apart from Microsoft and myself, to work with terrain mesh in CFS3, recently passed away after a long battle with cancer. Ed created the terrain for the MAW project (a massive task), Korean Skies and more recently the Solomons PTO. I'll be having a look at how Ed tackled the shoreline issue in these projects, especially in complex areas. I'll have a look at bridges and rivers in the projects too to see how they were tackled. I do know that he encountered the same problems I have with water mesh spiking, in the PTO project though I can recall reading that he solved it. It will be nice to spend a bit of time flying in these addons.
Rob
Links:
CGIAR SRTM details and links http://srtm.csi.cgiar.org/
NASA SRTM home - http://www2.jpl.nasa.gov/srtm/
Tuesday, July 1, 2008
Water Body post script
Looking around the web I have come to the conclusion that using hand edited SWBD data for water mesh is the best way to go. That's what I have done already. The other alternative was NGA's Global Shoreline data which is currently WIP. The NGA data is pretty good, though unfinished in places. I did find that it overlapped the coast on the SRTM data. There is very little that does not, though in CFS3 that may cause spiking. The CFS3 terrain engine was designed with much lower res data in mind.
In tonight's 2 hours, I re-edited NE England. I find it easier to delete the vertices and re-do, tracing along the caostline. The quest for software to simplify and smooth the vector shorelines continues. Map Shaper either over does or under does the smoothing though it is a good start. Unfortunately at times, it chooses not to work and does not work on my Vista 64 PC. Tomorrow I resume the texture work on the Sopwith Snipe for FSX. On the terrain front I'll experiment with CSV exchange between Global Mapper and Excel.
Rob
PS - Just found a PDF that illustrates what I am finding with SWBD data. http://www.scenerysolutions.com/doc/SRTMData.pdf
In tonight's 2 hours, I re-edited NE England. I find it easier to delete the vertices and re-do, tracing along the caostline. The quest for software to simplify and smooth the vector shorelines continues. Map Shaper either over does or under does the smoothing though it is a good start. Unfortunately at times, it chooses not to work and does not work on my Vista 64 PC. Tomorrow I resume the texture work on the Sopwith Snipe for FSX. On the terrain front I'll experiment with CSV exchange between Global Mapper and Excel.
Rob
PS - Just found a PDF that illustrates what I am finding with SWBD data. http://www.scenerysolutions.com/doc/SRTMData.pdf
Monday, June 30, 2008
Yet another update ;D
Endless updates eh? Anyway the medical news last week is not good. This activity will certainly continue albeit in a haphazard way for the time being. I have the same round of radio therapy and surgery ahead in the coming months as I had the last time. So I anticipate some therapuetic time dabbling in the CFS3 scenery SDK in the coming months.
In the meantime I've spent time over the last 3 weeks working on completing water and terrain meshes for the ETO. The verdict's out on whether they'll use it at the time of writing. The problem is that the existing data in CFS3 is quite old and out of alignment with the SRTM terrain mesh. The terrain mesh is the bottom layer upon which all other data, water, vector and gsl sits. There's no way in a 1000 years that any new terrain would line up with any existing CFS3 data including water. The new water generally appears ok in the areas I've checked. The lower level lods of the terrain push out under the water mesh causing spikes which disappear as one moves closer.
I've been checking some of NIMA's vmap0 vector data against the SRTM terrain in Global Mapper, and in the UK, at least, most of the vector data is slightly north west of where it should be. The roads appear very similar to those in CFS3, thus MS probably used that or similar data. The only way one could create a new theatre without these problems is to create one from scratch.... a massive undertaking, and probably beyond the scope of the ETO enhancement project.
I'll be experimenting in global mapper with CSV files. There could possibly be a way to display CFS3 facility locations in GM. It's hopefully just a matter of changing CFS3 data to the appropriate format.
Aircraft building continues and no doubt some of my earlier terrain dabbles, such as Spanish rivers and water bodies will also continue. I've overused my sitting allowance for this morning. Back to my bunker...... ;)
Cheers
Rob
In the meantime I've spent time over the last 3 weeks working on completing water and terrain meshes for the ETO. The verdict's out on whether they'll use it at the time of writing. The problem is that the existing data in CFS3 is quite old and out of alignment with the SRTM terrain mesh. The terrain mesh is the bottom layer upon which all other data, water, vector and gsl sits. There's no way in a 1000 years that any new terrain would line up with any existing CFS3 data including water. The new water generally appears ok in the areas I've checked. The lower level lods of the terrain push out under the water mesh causing spikes which disappear as one moves closer.
I've been checking some of NIMA's vmap0 vector data against the SRTM terrain in Global Mapper, and in the UK, at least, most of the vector data is slightly north west of where it should be. The roads appear very similar to those in CFS3, thus MS probably used that or similar data. The only way one could create a new theatre without these problems is to create one from scratch.... a massive undertaking, and probably beyond the scope of the ETO enhancement project.
I'll be experimenting in global mapper with CSV files. There could possibly be a way to display CFS3 facility locations in GM. It's hopefully just a matter of changing CFS3 data to the appropriate format.
Aircraft building continues and no doubt some of my earlier terrain dabbles, such as Spanish rivers and water bodies will also continue. I've overused my sitting allowance for this morning. Back to my bunker...... ;)
Cheers
Rob
Thursday, June 12, 2008
Another update
I seem to post nothing but updates here. Anyway the bottom line is that cancer is most likely back in my life again. New discomforting, and now painful symptoms came to my attention in April. They are gradually worsening and the doctors tell me it is most likely a re-occurrence and spread of liposarcoma. (I'm still hoping it's infection rather than sarcoma). Anyway with the likelihood that it's cancer which will involve some sort of treatment/surgery which may sideline me for a while, most of my efforts are presently devoted to surviving.
Creative efforts are focusing on getting my Sopwith Snipe ready for FSX before medical treatment begins. I probably won't have it complete by then but I'll give it a go anyway. Thus terrain for CFS3 will again have to take a back seat, with only a few minutes here and there to pursue. I'd like to post some pics and maybe more info on terrain creation, but no promises.
So if I disappear for a while... y'all know why. Hopefully I'll be back.
Cheers
Rob
Creative efforts are focusing on getting my Sopwith Snipe ready for FSX before medical treatment begins. I probably won't have it complete by then but I'll give it a go anyway. Thus terrain for CFS3 will again have to take a back seat, with only a few minutes here and there to pursue. I'd like to post some pics and maybe more info on terrain creation, but no promises.
So if I disappear for a while... y'all know why. Hopefully I'll be back.
Cheers
Rob
Friday, May 23, 2008
Quick Update
I will be updating the blog hopefully this coming weekend. I will further clarify and update my previous post and post some pics of my experiments.
To date I've only focussed on terrain and water and just touched on the landclass system. The test theatres look a bit boring with only one landclass, though there are some spectacular mountains in parts of the world. I've still attempt to use the CFS3 SDK vector data tools. The Terrain SDK is more than cryptic in places.
I have created a number of test theatres which appear to function, at least as far terrain mesh goes. I have chosen Spain as a theatre to develop right through, from terrain, water, vector data, land class etc., mainly as a learning exercise for myself. Right now I'm finding that the freely available vmap0 vector data is not all that accurate, with rivers running over the tops of mountains etc. In the instance of Spain I've chosen to create the river vector data by hand in Global Mapper. It's a slow task which I've only about 4+ hours a week to spare. I'll need to set aside some time to experiment and learn the landclass system. I have resumed aircraft modeling for FSX also... at long last after a 2 month break.
Anyway hopefully more on the weekend.
cheers
Rob
To date I've only focussed on terrain and water and just touched on the landclass system. The test theatres look a bit boring with only one landclass, though there are some spectacular mountains in parts of the world. I've still attempt to use the CFS3 SDK vector data tools. The Terrain SDK is more than cryptic in places.
I have created a number of test theatres which appear to function, at least as far terrain mesh goes. I have chosen Spain as a theatre to develop right through, from terrain, water, vector data, land class etc., mainly as a learning exercise for myself. Right now I'm finding that the freely available vmap0 vector data is not all that accurate, with rivers running over the tops of mountains etc. In the instance of Spain I've chosen to create the river vector data by hand in Global Mapper. It's a slow task which I've only about 4+ hours a week to spare. I'll need to set aside some time to experiment and learn the landclass system. I have resumed aircraft modeling for FSX also... at long last after a 2 month break.
Anyway hopefully more on the weekend.
cheers
Rob
Monday, April 7, 2008
Pushing the Boundaries - Slight Return :)
I can't stay away can I.....LOL? I've literally been pushing and testing the boundaries of the CFS3 terrain engine this past week. I've also been working on and off, in between times, these last couple of months on new terrain and water polygons for the new CFS3 ETO project. In the last week, with initiatives in the CFS3 forums at Sim-Outhouse, to create an Eastern Front add-on for CFS3 I decided experiment with a mesh for that. As the Eastern front covered a large geographic area I decided to test for myself just what could be achieved as to terrain size.
First up I created a dummy theatre the same size as CFS3 ETO, only moved east, using the paramaters in the terrain SDK examples. Using some test airbases in a simple gsl file, the theatre worked. Ok next up I decided to test a mega terrain. The terrain map stretched from S.E UK in the west, to Iraq in the east, southern Scandinavia in the north and the northern part of North Africa in the south. I fully expected CFS3 to croak, or rather not start. However CFS3 started as normal and I was able to fly from a couple of my test airfields. However optimism and satisfaction were short lived when I created further test airfields in the global scenery layer and attempted to fly from them, the game seemed to clip the theatre size by itself. However at that stage I did not create a new lcf (landclass) file for the appropriate theatre size and in my earlier experiments had made an error with the image and landclass stride parameters. I will redo the experiment later to make sure. I had been in the process of creating a large map of another geographical region before the Eastern Front project came up.
I would also emphasize that for test purposes, to speed things up, I was only compiling 1km resolution mesh down to a 1km stride. It only takes a few minutes to compile terrain at this resolution. Full resolution terrains can take hours (or days) of computer number crunching to compile.
On to my findings - firstly I would say that either that some of the terrain SDK examples are incorrect or there is a bug in the ers2tiff.exe tool. Creating a terrain mesh for CFS3 is relatively easy once you have source dem data. I use a spreadsheet to calculate the approximate bounds of the terrain data. The only numbers that ers2tiff.exe requires is the theatre origin, image pixel dim, image stride, max height, outX1, outY1 (terrain extents) and the number of images in the X and Y axes. The ers2tiff tool calculates the actual extents and theatre boundary from this information. This tool will automatically clip the supplied terrain to the appropriate size given the theatre minimum extent and the theatre origin.
In CFS3 geographical co-ordinates are relative to the theatre origin i.e. the theatre centre. The terrain SDK provides example parameters of minimum co-ordinate extents of the output data, in meters relative to the origin. The SDK further states that extent of the default ETO theatre is the rectangle (-786432,-786432) to (786432, 786432). However the output parameters that ers2tiff produces using appropriate dem data are (-786432,-786432) to (785408, 785408). (785408, 785408) is the north east co-ordinate of the terrain boundary in meters relative to the theatre origin. 785408 is 1024 meters less than 786432. In other words it truncates the data by approximately 1km in the North East. Further tests reveal that regardless of minimum terrain extent or theatre origin, the tool always outputs terrain extent parameters with the the NE parameters being 1024 meters less than the SW. I don't know whether this is a bug or by design. I do vaguely recall reading posts of a 1km srtm terrain bug in FS2004 & maybe FS2002, in forums in the past - maybe it's the SRTM data (or maybe it's my imaginative memory - someone may be able to clarify)?
This may be pertinent to one problem I have discovered. If we move the theatre origin north, or create a theatre larger than the default theatre, and fly into, or create an airfield in the NE corner of the theatre and fly from it, CFS3 crashes. Everything else appears to work correctly. One can only really test the bounds of CFS3 by flying in the game until one encounters the theatre boundary. The sim will soon let you know when you're leaving the theatre.
I cannot see any input in any of the xml files that tells cfs3 how large the theatre is apart from the files in the campaign's folder and mapdat.xml. CFS3 appears to ignore these as one can use any old numbers and the theatre will function ok in quick combat. The lcf file seems to have a bearing on theatre functionality in the sim and that may set boundaries, or CFS3 may determine theatre size from the terrain archives in the mesh zips.
Anyway after exploring boundaries by flying in the simulation, CFS3 appears to calculate its boundaries based on distances calculated from it's centre origin. As we know, the earth is round thus the distance per degree of longitude or latitude differs wherever we are on the planet. A degree of longitude (E/W) is 111.32km at the equator but 55.8km at a latitude of 60°N. CFS3 calculates its longitude boundaries using 1/2 the theatre dimension size east or west along the latitude at its origin, e.g. origin latitude of 50°N (approx 71.7km per °), 30°E gives 15°19′46″E in the west 44° 40' 14"E in the east. CFS3 calculates north and south from the centre in a similar manner (distance for degree of latitude varies from 110.57km to 111.69km). Having created these boundaries CFS3 then uses a rectangle based on these geographic co-ordinates as its theatre boundary, which is ok as long as it's primary reference is geographic latitude and longitude. It's paradoxical to a certain extent given that many of the SDK calculations are based on meters usually based to the power of 2 or divisible by numbers which are to the power of 2.
Anyway the exploration continues. I will continue some tests with ers2tiff to see if it can produce output whose extent boundaries line up with the SDK documentation. Perhaps using a geotiff dem will produce different results...maybe dted0 dems will produce different results? I'll also experiment again with a mega theatre. If the NE corner bug is the only problem then maybe we can put up with that and caution users to stay clear....maybe a giant smiley...danger Will Robinson...danger Lol? I also hope to explore CFS3's landclass system....more on that later.
All this is very addictive...I keep trying to escape CFS3. There's nothing like a puzzle to maintain one's interest.
cheers
Rob
First up I created a dummy theatre the same size as CFS3 ETO, only moved east, using the paramaters in the terrain SDK examples. Using some test airbases in a simple gsl file, the theatre worked. Ok next up I decided to test a mega terrain. The terrain map stretched from S.E UK in the west, to Iraq in the east, southern Scandinavia in the north and the northern part of North Africa in the south. I fully expected CFS3 to croak, or rather not start. However CFS3 started as normal and I was able to fly from a couple of my test airfields. However optimism and satisfaction were short lived when I created further test airfields in the global scenery layer and attempted to fly from them, the game seemed to clip the theatre size by itself. However at that stage I did not create a new lcf (landclass) file for the appropriate theatre size and in my earlier experiments had made an error with the image and landclass stride parameters. I will redo the experiment later to make sure. I had been in the process of creating a large map of another geographical region before the Eastern Front project came up.
I would also emphasize that for test purposes, to speed things up, I was only compiling 1km resolution mesh down to a 1km stride. It only takes a few minutes to compile terrain at this resolution. Full resolution terrains can take hours (or days) of computer number crunching to compile.
On to my findings - firstly I would say that either that some of the terrain SDK examples are incorrect or there is a bug in the ers2tiff.exe tool. Creating a terrain mesh for CFS3 is relatively easy once you have source dem data. I use a spreadsheet to calculate the approximate bounds of the terrain data. The only numbers that ers2tiff.exe requires is the theatre origin, image pixel dim, image stride, max height, outX1, outY1 (terrain extents) and the number of images in the X and Y axes. The ers2tiff tool calculates the actual extents and theatre boundary from this information. This tool will automatically clip the supplied terrain to the appropriate size given the theatre minimum extent and the theatre origin.
In CFS3 geographical co-ordinates are relative to the theatre origin i.e. the theatre centre. The terrain SDK provides example parameters of minimum co-ordinate extents of the output data, in meters relative to the origin. The SDK further states that extent of the default ETO theatre is the rectangle (-786432,-786432) to (786432, 786432). However the output parameters that ers2tiff produces using appropriate dem data are (-786432,-786432) to (785408, 785408). (785408, 785408) is the north east co-ordinate of the terrain boundary in meters relative to the theatre origin. 785408 is 1024 meters less than 786432. In other words it truncates the data by approximately 1km in the North East. Further tests reveal that regardless of minimum terrain extent or theatre origin, the tool always outputs terrain extent parameters with the the NE parameters being 1024 meters less than the SW. I don't know whether this is a bug or by design. I do vaguely recall reading posts of a 1km srtm terrain bug in FS2004 & maybe FS2002, in forums in the past - maybe it's the SRTM data (or maybe it's my imaginative memory - someone may be able to clarify)?
This may be pertinent to one problem I have discovered. If we move the theatre origin north, or create a theatre larger than the default theatre, and fly into, or create an airfield in the NE corner of the theatre and fly from it, CFS3 crashes. Everything else appears to work correctly. One can only really test the bounds of CFS3 by flying in the game until one encounters the theatre boundary. The sim will soon let you know when you're leaving the theatre.
I cannot see any input in any of the xml files that tells cfs3 how large the theatre is apart from the files in the campaign's folder and mapdat.xml. CFS3 appears to ignore these as one can use any old numbers and the theatre will function ok in quick combat. The lcf file seems to have a bearing on theatre functionality in the sim and that may set boundaries, or CFS3 may determine theatre size from the terrain archives in the mesh zips.
Anyway after exploring boundaries by flying in the simulation, CFS3 appears to calculate its boundaries based on distances calculated from it's centre origin. As we know, the earth is round thus the distance per degree of longitude or latitude differs wherever we are on the planet. A degree of longitude (E/W) is 111.32km at the equator but 55.8km at a latitude of 60°N. CFS3 calculates its longitude boundaries using 1/2 the theatre dimension size east or west along the latitude at its origin, e.g. origin latitude of 50°N (approx 71.7km per °), 30°E gives 15°19′46″E in the west 44° 40' 14"E in the east. CFS3 calculates north and south from the centre in a similar manner (distance for degree of latitude varies from 110.57km to 111.69km). Having created these boundaries CFS3 then uses a rectangle based on these geographic co-ordinates as its theatre boundary, which is ok as long as it's primary reference is geographic latitude and longitude. It's paradoxical to a certain extent given that many of the SDK calculations are based on meters usually based to the power of 2 or divisible by numbers which are to the power of 2.
Anyway the exploration continues. I will continue some tests with ers2tiff to see if it can produce output whose extent boundaries line up with the SDK documentation. Perhaps using a geotiff dem will produce different results...maybe dted0 dems will produce different results? I'll also experiment again with a mega theatre. If the NE corner bug is the only problem then maybe we can put up with that and caution users to stay clear....maybe a giant smiley...danger Will Robinson...danger Lol? I also hope to explore CFS3's landclass system....more on that later.
All this is very addictive...I keep trying to escape CFS3. There's nothing like a puzzle to maintain one's interest.
cheers
Rob
Wednesday, January 23, 2008
Last post on this blog for a while.
I'm rationalizing my blog activities somewhat. This blog was established to blog some of my activities in exploring CFS3 scenery creation, largely as a from of recreational activity while waiting for cancer treatment and surgery. Hopefully I am now on the recovery trail and I can now again focus on my core hobby activities such as virtual aircraft creation, and of course real life and ongoing cancer treatment.
I ended up creating a semi-functional Mariana Islands theatre (Guam, Saipan etc) but did not get time to create new land class or scenery objects. However I do hope to return to this someday. I'll be monitoring CFS3 PTO threads on the forums. I'm also looking for time to resume a F6F-3 model I started on last year along with a Helldiver. Hopefully I will have time to create versions for both FSX & CFS3...... sometime in 2008..... though don't hold your breath.
I will not close or delete this blog at this time for reasons mentioned in the previous paragraph. I may (probably will) dabble in FSX scenery creation.
Anyway for the time being.... all the best to my very few readers.
Rob
I ended up creating a semi-functional Mariana Islands theatre (Guam, Saipan etc) but did not get time to create new land class or scenery objects. However I do hope to return to this someday. I'll be monitoring CFS3 PTO threads on the forums. I'm also looking for time to resume a F6F-3 model I started on last year along with a Helldiver. Hopefully I will have time to create versions for both FSX & CFS3...... sometime in 2008..... though don't hold your breath.
I will not close or delete this blog at this time for reasons mentioned in the previous paragraph. I may (probably will) dabble in FSX scenery creation.
Anyway for the time being.... all the best to my very few readers.
Rob
Sunday, October 21, 2007
Tuesday, October 2, 2007
October update
I posted an update on my activities in the Biff Diaries. I'm mainly working on 3D projects for relaxation at the moment. I'll return to scenery dabbling in coming weeks/months ;)
In the meantime there are some nice pics of CFS3 scenery work by others, being posted around the web.
http://offaerodrome.com/OFFweb/gallery.htm
and
http://www.sim-outhouse.com/sohforums/showthread.php?t=52790
http://www.sim-outhouse.com/sohforums/showthread.php?t=51783
cheers
Rob
In the meantime there are some nice pics of CFS3 scenery work by others, being posted around the web.
http://offaerodrome.com/OFFweb/gallery.htm
and
http://www.sim-outhouse.com/sohforums/showthread.php?t=52790
http://www.sim-outhouse.com/sohforums/showthread.php?t=51783
cheers
Rob
Saturday, September 15, 2007
Change of activity
I have eased up on scenery creation for a few weeks, mainly given radiotherapy & its effects. I have also switched over to mainly focusing on aircraft modeling for a few weeks. I will be switching between activities until I recover next year. I'm in a wee bit of pain at the moment.
I still intend to work on my scenery with new trees & textures. As for trees it's a matter of motivating myself to take a few photographs of trees (I'm surrounded by them) for the textures & I will composite ground textures from a variety of free sources including hand painting some of my own. For copyright reasons it is best NOT to use and mod FSX textures. It would be illegal to distribute such to others as not every CFS3 user owns FSX.
I will also be continuing work on my landclass system and integrating the above into it.
The problem with lines on water looks as if it will be difficult to get rid of. The CFS3 terrain SDK tools and CFS3 scenery engine was not designed with SRTM & SWBD data in mind. The terrain features a LOD system, unfortunately the water system doesn't. The lo-res terrain lods intersecting with the high-res SWBD data causes the water polys to bend where they intersect with with the terrain causing lines to appear. This can be seen occasionally in the CFS3 PTO Solomons theatre. I think the only way they can be reduced (not eliminated) is to use hand drawn coast line vectors, a massive task. If one takes a look at the coast lines in FSX they are all fairly lo-res coastlines.
I did start to create a terrain map for the Philippines, however creating the coastline vectors is a massive task.
In the meantime I hope to post a bit more on aircraft creation in the Biff Diaries in the next couple of weeks.
Rob
I still intend to work on my scenery with new trees & textures. As for trees it's a matter of motivating myself to take a few photographs of trees (I'm surrounded by them) for the textures & I will composite ground textures from a variety of free sources including hand painting some of my own. For copyright reasons it is best NOT to use and mod FSX textures. It would be illegal to distribute such to others as not every CFS3 user owns FSX.
I will also be continuing work on my landclass system and integrating the above into it.
The problem with lines on water looks as if it will be difficult to get rid of. The CFS3 terrain SDK tools and CFS3 scenery engine was not designed with SRTM & SWBD data in mind. The terrain features a LOD system, unfortunately the water system doesn't. The lo-res terrain lods intersecting with the high-res SWBD data causes the water polys to bend where they intersect with with the terrain causing lines to appear. This can be seen occasionally in the CFS3 PTO Solomons theatre. I think the only way they can be reduced (not eliminated) is to use hand drawn coast line vectors, a massive task. If one takes a look at the coast lines in FSX they are all fairly lo-res coastlines.
I did start to create a terrain map for the Philippines, however creating the coastline vectors is a massive task.
In the meantime I hope to post a bit more on aircraft creation in the Biff Diaries in the next couple of weeks.
Rob
Tuesday, August 28, 2007
CFS3 Marianas
I can now reveal the primary area that I am working on (there are two more) - The Mariana Islands. To date I have the terrain mesh, ocean polygons, & shorelines working. There are minor issues such as airfield facilities distorting terrain mesh near coastlines - just a matter of playing around with airfield altitude in the global layer. As I mentioned in the previous post I have found that hand editing or hand creating coastlines works best.
Next I move on to landclass & scenery objects, that will take me a couple of weeks. Presently the terrain only has one woodland landclass just to get the terrain & ocean into CFS3.
Here are a couple of pics - one of a rather bare Apra harbour and the other two of Pagan Island, which Japan held until late in the war and used to raid Saipan.
Rob
Next I move on to landclass & scenery objects, that will take me a couple of weeks. Presently the terrain only has one woodland landclass just to get the terrain & ocean into CFS3.
Here are a couple of pics - one of a rather bare Apra harbour and the other two of Pagan Island, which Japan held until late in the war and used to raid Saipan.
Rob
Sunday, August 26, 2007
Update Sunday
My CFS3 terrain experiments still continue. I managed to create a group of islands at an image stride & LOD of 64 meters which gave me a buzz this morning. What amazed me was that frame rates were barely affected. The verdict is out as to whether mesh at this resolution is worthwhile. The 64m LOD took all night to compile and takes about 600mb space. A 128m LOD (at 64m stride) only takes a couple of hours to compile and is about 140mb in size.
As to coastline data, I find that hand digitising of coastlines worked best in my current theatre. Of course such is a bit unweildy in areas with hundreds of islands. The problem with the CFS3 terrain engine & tools is that if a shoreline lines up with terrain at an altitude of more than a couple of meters it produces a sliver like spike radiating from the shoreline across the ocean, like a mini tsunami if you get down close and have a look at it. I notice a few in the Solomons theatre as well as my own experiments.
Anyway on to tidy up my coastlines - there are still a few glitches. The next step will be landclass & scenery, it's all very generic at this stage. This will keep me going maybe a couple of weeks.
As to coastline data, I find that hand digitising of coastlines worked best in my current theatre. Of course such is a bit unweildy in areas with hundreds of islands. The problem with the CFS3 terrain engine & tools is that if a shoreline lines up with terrain at an altitude of more than a couple of meters it produces a sliver like spike radiating from the shoreline across the ocean, like a mini tsunami if you get down close and have a look at it. I notice a few in the Solomons theatre as well as my own experiments.
Anyway on to tidy up my coastlines - there are still a few glitches. The next step will be landclass & scenery, it's all very generic at this stage. This will keep me going maybe a couple of weeks.
Monday, August 20, 2007
Partial Success
I now have a couple of CFS3 theatres partially up & running. At this stage I have only completed the basics to get a map area operational.
Currently I have to commute daily to hospital for radiotherapy, which can take up to five hours out of my day if I have lunch & do a bit of shopping. Transport from my home on the island, to the hospital only takes just over an hour, but the return trip can take 3 hours given timetable gaps in the public transport system. Thus my experiments in terrain creation are somewhat punctuated. I also hope to resume aircraft creation once I am sure I have the main issues in terrain/scenery creation under control. All this is for relaxation LOL.
I have experimented with mixed results. So far I have yet to see any benefit using the CFS3 SDK with hires mesh, though I have more experiments to carry out this week The tiff2msh tool is where things currently fall down as to resolution. I also experienced interesting results with the landclass system which I will fully explore, once I have a nice terrain mesh working.
Also problems with water occur around some of the coastlines causing spikes in the water polys. I am trying to determine whether it is a DEM problem or a problem with some of the SWBD vector data, or whether it is a CFS3 terrain SDK issue or a Global Mapper issue.
I am being a bit circumspect in writing this. I'd like to disclose a bit more, especially some of my explorations as I go along. However with rivalry situations that exist from time to time in various CFS & FS communities I'll keep quiet until I have something to show. I am doing this for relaxation and don't want to be stampeded into competitive situations, which I can see happening.
The other person creating terrains & theatres for CFS3, Ed Wilson, is quietly getting on with his creations just like me, and I have no problems with that and I admire his achievements. After all MAW did inspire me somewhat to experiment with terrain/scenery creation. There are others however, who are prone to creating competitive situations.
One thing I will say though, is that those who liked what I acheived with the CFS3 & FSX Bristol Fighter, can look forward to the same approach in the world of scenery.
However one thing at a time.
cheers
Rob
Currently I have to commute daily to hospital for radiotherapy, which can take up to five hours out of my day if I have lunch & do a bit of shopping. Transport from my home on the island, to the hospital only takes just over an hour, but the return trip can take 3 hours given timetable gaps in the public transport system. Thus my experiments in terrain creation are somewhat punctuated. I also hope to resume aircraft creation once I am sure I have the main issues in terrain/scenery creation under control. All this is for relaxation LOL.
I have experimented with mixed results. So far I have yet to see any benefit using the CFS3 SDK with hires mesh, though I have more experiments to carry out this week The tiff2msh tool is where things currently fall down as to resolution. I also experienced interesting results with the landclass system which I will fully explore, once I have a nice terrain mesh working.
Also problems with water occur around some of the coastlines causing spikes in the water polys. I am trying to determine whether it is a DEM problem or a problem with some of the SWBD vector data, or whether it is a CFS3 terrain SDK issue or a Global Mapper issue.
I am being a bit circumspect in writing this. I'd like to disclose a bit more, especially some of my explorations as I go along. However with rivalry situations that exist from time to time in various CFS & FS communities I'll keep quiet until I have something to show. I am doing this for relaxation and don't want to be stampeded into competitive situations, which I can see happening.
The other person creating terrains & theatres for CFS3, Ed Wilson, is quietly getting on with his creations just like me, and I have no problems with that and I admire his achievements. After all MAW did inspire me somewhat to experiment with terrain/scenery creation. There are others however, who are prone to creating competitive situations.
One thing I will say though, is that those who liked what I acheived with the CFS3 & FSX Bristol Fighter, can look forward to the same approach in the world of scenery.
However one thing at a time.
cheers
Rob
Sunday, August 12, 2007
Update
Following on my last post it appears that I am not the only person working on a Solomons theatre for CFS3 as witness the current news on the Korean Skies page.
In many ways that is good news and I am generally pleased. I don't object to anyone else making terrain for the Solomons or elsewhere. There are heaps of areas I want to create & experiment with and I could have possibly chosen an other area to start with. Anyway I wish Ed well with it.
I have learned a great deal in the last week. The CFS3 SDK tools to convert DEM files to mesh appear to work ok. They even allow the creation of rectangular as opposed to square maps. Unfortunately this is not the case with tool that converts landclass maps to lcf files. It only accepts square maps. Why the rest of the SDK allows for rectangular maps and the landclass tool does not is beyond me... you should have heard me cursing.
I am currently working on water polygons derived from SWBD data. Unfortunately the data contains shapes for many of the islands instead of empty space. I have to convert many small islands to holes in the water by hand....painstaking & I still don't know how the CFS3 water tools will cope with such hi-resolution data......more cussing on the way perhaps? LOL
Anyway back to square one. I will still persevere with the Solomons area as my learning & test area given that I have come so far and carried out much research. I will at least get it into the sim. It will be interesting to see how it compares to the Korean Skies version. Whether I will ever release it..... who knows? I have a great many theatres large & small in many parts of the world from 1914 to 1960's that I would like to attempt. Of course given the contrary way the world operates MS might surprise us all and announce a new CFS.... that would be a long time coming if they did... plenty of time to create for CFS3 ;)
cheers
Rob
In many ways that is good news and I am generally pleased. I don't object to anyone else making terrain for the Solomons or elsewhere. There are heaps of areas I want to create & experiment with and I could have possibly chosen an other area to start with. Anyway I wish Ed well with it.
I have learned a great deal in the last week. The CFS3 SDK tools to convert DEM files to mesh appear to work ok. They even allow the creation of rectangular as opposed to square maps. Unfortunately this is not the case with tool that converts landclass maps to lcf files. It only accepts square maps. Why the rest of the SDK allows for rectangular maps and the landclass tool does not is beyond me... you should have heard me cursing.
I am currently working on water polygons derived from SWBD data. Unfortunately the data contains shapes for many of the islands instead of empty space. I have to convert many small islands to holes in the water by hand....painstaking & I still don't know how the CFS3 water tools will cope with such hi-resolution data......more cussing on the way perhaps? LOL
Anyway back to square one. I will still persevere with the Solomons area as my learning & test area given that I have come so far and carried out much research. I will at least get it into the sim. It will be interesting to see how it compares to the Korean Skies version. Whether I will ever release it..... who knows? I have a great many theatres large & small in many parts of the world from 1914 to 1960's that I would like to attempt. Of course given the contrary way the world operates MS might surprise us all and announce a new CFS.... that would be a long time coming if they did... plenty of time to create for CFS3 ;)
cheers
Rob
Monday, August 6, 2007
Ready to start Solomon Islands theatre
This week I am ready to start moving things into CFS3. My main goal is to get things working using as much of the original CFS3 installation as possible. Later on I can experiment with higher resolution data. However the CFS3 scenery system is difficult enough as it is without trying to improve things from the outset.
The region I am working on is centered at S7.5 , E152.5 and is planned to cover a similar area to CFS3 Europe.
I have been obtaining the appropriate data and checking it out and assembling in my primary GIS application Global Mapper. The CFS3 terrain SDK is certainly making sense now. However I still have to check out all the SDK tools. There's much work in all this & I don't want to overdo things. I also had a nasty flu virus last week which delayed matters. Hopefully I am on the mend now. Radiotherapy begins this week so I'll have less time for creative endeavours.
The data is split into 3 main types -
As to DEM data, I had originally intended to use the most recent available 3 arc second data. As this is 10 times higher resolution than the data used for CFS3, I am not sure that the CFS3 engine could cope with it over a region as large as the CFS3 European theatre. One has a number of choices : -
Vector data was a big chore last week, especially coastline data. Rivers & roads are fairly easy. For this exercise I am using vmap0 data, available from NGA via their rasterroam site. It is easy to extract this data using Global Mapper (the Swiss Knife of GIS applications.). Water body vector data is easy too. I am using SWBD data derived from SRTM data. It is good resolution, though perhaps stepped along the coast lines. I'll have to see how it looks or whether it is noticeable in the theatre.
Even though we have this data we still need vectors for the coastline, this is where the ordeal began (along with the flu), involving many hours of trial and error. I found the vmap0 & NOAA coastline data to be too lo-res & didn't line up with some of the smaller islands. The SWBD data is in area format. The coastline data has to be in lines. Global mapper's convert area to lines function caused some of the smaller islands to disappear, probably due to flaws in the data and we are still left with the problem of deleting the lines comprising the tile borders, which also deletes parts of the coastline in Global Mapper. I needed to find some other way of editing the vector data and extracting and converting to line shape data. The solution - export the vector data to dxf format & import & edit in 3DS Max (this may work too in gmax, though I haven't tried). This was somewhat unwieldy, time consuming and involved much trial & error. Eventually I got there, imported the edited DXF into Global Mapper and then re-exported as a line vector shapefile, now ready for the CFS3 sdk tools. The SDK shoreline tool is reputedly finicky & again much experimentation will be required to find the correct resolution.
A few links
DEM data is obtainable from a number of sources :-
Rob
The region I am working on is centered at S7.5 , E152.5 and is planned to cover a similar area to CFS3 Europe.
I have been obtaining the appropriate data and checking it out and assembling in my primary GIS application Global Mapper. The CFS3 terrain SDK is certainly making sense now. However I still have to check out all the SDK tools. There's much work in all this & I don't want to overdo things. I also had a nasty flu virus last week which delayed matters. Hopefully I am on the mend now. Radiotherapy begins this week so I'll have less time for creative endeavours.
The data is split into 3 main types -
- topological DEM data - to produce terrain mesh.
- vector data - for coastlines, waterbodies, roads & rivers.
- land coverage data - for the landclass system.
As to DEM data, I had originally intended to use the most recent available 3 arc second data. As this is 10 times higher resolution than the data used for CFS3, I am not sure that the CFS3 engine could cope with it over a region as large as the CFS3 European theatre. One has a number of choices : -
- use that data and then use the numbers as in CFS3 & SDK examples. This will leave any resampling downwards to the CFS3 tools. The results of such would not be known. A lot of work just to experiment.
- use SRTM30 data. This is 1km data similar to the resolution used in CFS3. However this data is more recent and accurate than the data used in CFS3.
- use the 3 arc second data & down sample the DEM data in Global Mapper. This is what I have decided on as I will be using the most recent data available.
Vector data was a big chore last week, especially coastline data. Rivers & roads are fairly easy. For this exercise I am using vmap0 data, available from NGA via their rasterroam site. It is easy to extract this data using Global Mapper (the Swiss Knife of GIS applications.). Water body vector data is easy too. I am using SWBD data derived from SRTM data. It is good resolution, though perhaps stepped along the coast lines. I'll have to see how it looks or whether it is noticeable in the theatre.
Even though we have this data we still need vectors for the coastline, this is where the ordeal began (along with the flu), involving many hours of trial and error. I found the vmap0 & NOAA coastline data to be too lo-res & didn't line up with some of the smaller islands. The SWBD data is in area format. The coastline data has to be in lines. Global mapper's convert area to lines function caused some of the smaller islands to disappear, probably due to flaws in the data and we are still left with the problem of deleting the lines comprising the tile borders, which also deletes parts of the coastline in Global Mapper. I needed to find some other way of editing the vector data and extracting and converting to line shape data. The solution - export the vector data to dxf format & import & edit in 3DS Max (this may work too in gmax, though I haven't tried). This was somewhat unwieldy, time consuming and involved much trial & error. Eventually I got there, imported the edited DXF into Global Mapper and then re-exported as a line vector shapefile, now ready for the CFS3 sdk tools. The SDK shoreline tool is reputedly finicky & again much experimentation will be required to find the correct resolution.
A few links
DEM data is obtainable from a number of sources :-
- http://seamless.usgs.gov/ This is not the most recent data, however one can select a region for download from a seamless map intereface.
- http://srtm.csi.cgiar.org/ This is the most recent 3 arc second SRTM data available. The site also provides a link to a Google Earth interface where one can zoom in to download links. http://www.ambiotek.com/topoview (requires GE on your computer). This is the data that I used.
- ftp://e0srp01u.ecs.nasa.gov/srtm/version2/SRTM30 - global DEM data at 1km resolution.
- ftp://e0srp01u.ecs.nasa.gov/srtm/version2/SRTM3 - SRTM 3arc second if you know the tiles you want to download.
- http://geoengine.nga.mil/ NGA's raster roam site - both dem & vector data including vmap0 vector data
- http://www.ngdc.noaa.gov/mgg/shorelines/shorelines.html - National Geophysical Data Center (NGDC) - coastline data.
- ftp://e0srp01u.ecs.nasa.gov/srtm/version2/SWBD/ - SWBD water body data derived from SRTM data.
- http://landcover.usgs.gov/glcc/index.php - Global Landcover data.
- http://www-gvm.jrc.it/glc2000/ - CGLC2000 - EU global land cover data.
- http://glcf.umiacs.umd.edu/data/landcover/ - GLCF - AVHRR Global Landcover Classification.
Rob
Subscribe to:
Posts (Atom)
