Re: GIS Update

["D. Cooper Stevenson" <cstevens@gencom.us>]

On Wednesday 27 October 2004 05:46, Lincoln Peters wrote:

> > How about that?
>
> Quite impressive.
>

Thank you!


> Do you think that this data map nicely to the terrain types in an
> existing terrain module (plains, forest, desert, mountains, swamp,
> shallows, sea), or does this call for a new terrain module to be of any
> real interest?  If at this point you're just dealing with landcover, I
> could create a simplified spin-off of my proposed omniterr.g terrain
> module toward that end (no coatings would be needed).

Why didn't I think of that?!!?

I think you've hit the nail right on the head. It would certainly be ideal to 
simply have a GIS terrain module that couples seemlessly with the NLCD 92 
data. This would deprecate the need for a conversion script.

I may be making this sound harder than it is. Again, here's a link to the 
"Xconqified" GIS landcover map:

   http://wiki.xconqgis.org/images/grass2xconq/seattle_lowres.jpg

Now, compare this with the ASCII GIS text file export linked here:

  http://wiki.xconqgis.org/map_files/landcover_export.txt

The file format is simple. The file reads from top left to lower right; one 
row per line.
  
Here is the specific landcover specification:

  http://landcover.usgs.gov/classes.asp

When you compare the ASCII export with the map, you can see how they coincide. 
For example, starting from the top left, there are:

   11 squares of Evergreen forest followed by...
     1 square of mixed forest
     5 squares of Transitional
    ...

I always have to caveat that I've not actually performed a detailed comparison 
between the map and the ASCII output but my holistic analysis (spot checking 
and some "tea leaf" reading) tells me that it's accurate. 

>
> Elevation data, of course, is a fairly simple matter to import.
> Although as far as I can tell, it only affects the isometric view code
> and (sometimes) the fractal percentile terrain generator.
>

I think you're right. I can see that it will be increasingly important to use 
elevation as a determinate of such factors such as unit speed, engagement 
advantage and "who can see whom."

This is known. The good news is that I think Xconq's engine can be extended to 
use elevation in these ways. I may be out in left field here; Eric or others 
may say, "Xconq already does read elevation."

>
> What kind of CPU and memory does the process require?  It probably
> wouldn't be an issue on newer computers (especially those built
> specifically for playing games), but somewhere out there, someone is
> probably still playing Xconq through an ASCII terminal with the Ncurses
> interface, and you can guess how much power that thing would have...

I'm with you. The good news is that we can sandwich the Seattle (or any other) 
GIS based map in Xconq and it would run on curses based terminals because 
we're staying within the parameters of the Xconq game engine. To put it 
another way, we're currently just making maps that happen to be accurate 
within roughly 100 meters :) .

The bad news is that if we do real time rendering of the Earth, the 
"ncurser's" will be kind of out of luck. This is because the rendering 
process will require GRASS GIS on the system. 

Now, don't worry, I compiled it in 20 minutes. It's a good thing (tm).

There may be a compromise. What would happen if we had a centralized GIS 
server that 486's could connect to through their 

If you'll let my imagination run wild for a moment, what would happen if real 
people (playing paintball? field operations?) had GIS transponders that would 
be connected to the server via satellite? The GIS unit itself would need 
simply be a small, single-board Linux computer with an LCD screen and GIS 
transponder. These units probably use an ncurses interface because bandwidth 
in the field is at a premium. 

To put it another way, you don't want to be attacked while waiting for a ton 
of graphical data. A simple 'X' where the enemy is will do, thank you ;)

The long and short of it is that the server would do the heavy lifting while 
the client simply passes ncurses data sent from the server.

Oh, yeah. The server could be a super cluster. Yes, I know how to build them 
and I think we could do it.

Ponder this.

> Looks like we might be able to dramatically improve the isometric view
> code (at least for some games) without having to make any major changes
> to the actual view code!  Of course, since I've never messed with the UI
> code, I'm guessing there.

I hope so!  I think that by using GIS data, it should be possible to click on 
a unit and have a 360 deg. view of what that unit can see. That includes 
airplanes.

I can just see Eric rubbing his temples as his mind calculates what needs to 
be coded :)


-Coop