Re: GIS Update

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

One other thing, complete documentation here:

  http://wiki.xconqgis.org/index.php?TranslatingToXconq


-Coop

On Wednesday 27 October 2004 17:21, D. Cooper Stevenson wrote:
> 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