GIS Update

GIS Update

[D. Cooper Stevenson]

Dear All,

I have worked on diligently on the GIS side of things. Here's a few
quick points:

  1) We are not after satellite photos, we are after "Digital Elevation
Models."

  1a) The entire globe is freely available as a DEM

  2) Because the data is in a raster format (as apposed to a regular
image file),  I believe it is quite possible to automate the creation of
new maps and smaller scale views of those maps

  3) If you don't have GRASS to manipulate the images (and don't want to
fuss with compiling it), don't worry about it: there are live GRASS
CD's; just pop on in and boot to GRASS on Linux: 
  http://grass.baylor.edu//demo.html

  4) The next Xconq game may take place on Mars. Yes, DEM data available
for Mars.

  5) If you want to read a good overview article on this, you may find
an interesting article entitled, "Global dataset of bathymetry and
topography" (PDF) (Not as nerdy as it sounds):

  http://grass.baylor.edu//newsletter/GRASSNews_vol1.pdf

To sum up, I've been like a bull in a china shop, trying anything and
everything. I believe I've honed my technique significantly. I hope to
have a tutorial and preliminary output soon.


Best,


Coop

-- 
--------------------------------------------------------------
| Cooper Stevenson        | Em:  cooper@gencom.us            |
| GenCom                  | Ph:  541.924.9434                |
| "Working For IT"        | Www: http://www.gencom.us        |
--------------------------------------------------------------

Re: GIS Update

[Eric McDonald]

D. Cooper Stevenson wrote:

>   4) The next Xconq game may take place on Mars. Yes, DEM data available
> for Mars.

Cool. We could take battlebots and make them play King of Olympus Mons 
or something like that....

> To sum up, I've been like a bull in a china shop, trying anything and
> everything. I believe I've honed my technique significantly. I hope to
> have a tutorial and preliminary output soon.

Excellent. As Edison said, IIRC, "Genius is 99% perspiration, and 1% 
inspiration."

Eric

Re: GIS Update

[mskala]

On Tue, 21 Sep 2004, D. Cooper Stevenson wrote:
>   1) We are not after satellite photos, we are after "Digital Elevation
> Models."

Well, depending on what you want to do with it.

A DEM is a height field.  It specifies the elevation at a bunch of points.  
If you are building a map that cares about elevation, then you want that
for sure, but you might want other kinds of data too.  For my Antarctic
map I also used the DEM to infer the surface type, because that seemed the
most useful thing to do, but that was something of a kludge adapted
specifically for the Antarctic map.  On other maps there are probably
other kinds of data that can provide better guidance as to the final "bin"
to put the hex in.

For instance, if we had multispectral data (like from a LANDSAT TM image)
we could use that to classify hexes by type of surface terrain - forest,
cropland, water, etc.  That could be useful.  LANDSAT TM is like an image
file with five or six channels of colour information (corresponding to
colour bands from visible into infrared, with some subtleties and
complications) at a resolution where each pixel is 15 to 25 metres.  I
don't know that we could get that for free, but I'm pretty sure we can get
AVHRR data (similar kind of thing, pixels are kilometres in size) for
free.  If we had "line coverages" of vector data for things like rivers,
it might be fun to try to convert those into border or connection terrain,
although the complexity of the algorithms to do that might get pretty
high.  Part of the fun is that there are lots of different kinds of GIS
data out there.

>   2) Because the data is in a raster format (as apposed to a regular
> image file),  I believe it is quite possible to automate the creation of
> new maps and smaller scale views of those maps

One thing to watch out for is that not all DEMs are really rasters.  Some
are just lists of points; others are complicated data structures called
Triangulated Irregular Networks or TINs, and even if they are rasters,
they may not be on the grid or projection you want.  GRASS has some pretty
sophisticated tools for manipulating the data into whatever grid you want,
so that shouldn't be a problem, but it'll be something to keep in mind.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: GIS Update

[Christopher Wood]

I've been trying to do this a couple times over the last
couple weeks. I would like to be unsubscribed from
this mailing list.

Thanks,
Chris Wood

Re: GIS Update

[D. Cooper Stevenson]

On Thursday 28 October 2004 00:35, Lincoln Peters wrote:
>
> I've already modified my "omniterr.g" module so that it is entirely
> based on vegetation (I kept the original, of course).  I'll see if I can
> modify it to handle the different classes of land cover described in the
> USGS page.

Oh, outstanding! That would save me a good chunk  of script writing time. 
Besides, it's no secret that my C is wanting. Not lazyness, just a simple 
fact.

> Actually, there is one other thing I remember that elevation affects:
> line-of-sight. 

That rings a bell.

> I think that it lacks the ability to affect unit speed 
> or engagement advantage; the best you can do is create a bunch of
> additional terrain types to represent different altitudes (way too much
> work, if you ask me!).

Yep.


-Coop

Re: GIS Update

[Lincoln Peters]

On Wed, 2004-10-27 at 10:21, D. Cooper Stevenson wrote:
> On Wednesday 27 October 2004 05:46, Lincoln Peters wrote:
> > 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've already modified my "omniterr.g" module so that it is entirely
based on vegetation (I kept the original, of course).  I'll see if I can
modify it to handle the different classes of land cover described in the
USGS page.

> Here is the specific landcover specification:
> 
>   http://landcover.usgs.gov/classes.asp

Looks like a total of 22 terrain types, unless I'm misunderstanding how
it's supposed to work.

> >
> > 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."

Actually, there is one other thing I remember that elevation affects:
line-of-sight.  I think that it lacks the ability to affect unit speed
or engagement advantage; the best you can do is create a bunch of
additional terrain types to represent different altitudes (way too much
work, if you ask me!).

---
Lincoln Peters
<sampln@sbcglobal.net>

If your happiness depends on what somebody else does, I guess you do
have a problem.
		-- Richard Bach, "Illusions"

Re: GIS Update

[D. Cooper Stevenson]

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

Re: GIS Update

[D. Cooper Stevenson]

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

Re: GIS Update

[Lincoln Peters]

On Tue, 2004-10-26 at 21:01, D. Cooper Stevenson wrote:
> All,
> 
> Quick Take:
> 
> During the game, you might see something like this (review):
> 
>   http://wiki.xconqgis.org/index.php?WhatGisImageMightLookLike
> 
> The world size is the same as Normandy's, 186x159. I've recalibrated the 
> image's resolution to match. The computer "sees" this:
> 
>   http://wiki.xconqgis.org/images/grass2xconq/seattle_lowres_large.jpg
> 
> How about that?

Quite impressive.

> 
> Now, this is really important. Note that these are images not of _elevation_ 
> data; it's actual _landcover_ data! The landcover data translates directly 
> into terrain types. Note too that exporting GIS elevation data is trivial. 
> Very nice!

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).

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 did a spot check and found that the ascii export and the low res image seem 
> to coincide. I'll know for sure when I'm finished with the conversion script.
> 
> The best news is that the entire process is capable of automation. This has 
> the potential for real-time rendering wherever the tacticians wish to fight 
> (or run).

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 hope to have 3D renderings soon. Just for fun, here's an image created with 
> GIS data similar to the elevation data I'm using:
> 
>   http://photojournal.jpl.nasa.gov/jpegMod/PIA06668_modest.jpg

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.

---
Lincoln Peters
<sampln@sbcglobal.net>

BOFH excuse #13:

we're waiting for [the phone company] to fix that line

GIS Update

[D. Cooper Stevenson]

All,

Quick Take:

During the game, you might see something like this (review):

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

The world size is the same as Normandy's, 186x159. I've recalibrated the 
image's resolution to match. The computer "sees" this:

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

How about that?

Now, this is really important. Note that these are images not of _elevation_ 
data; it's actual _landcover_ data! The landcover data translates directly 
into terrain types. Note too that exporting GIS elevation data is trivial. 
Very nice!

I did a spot check and found that the ascii export and the low res image seem 
to coincide. I'll know for sure when I'm finished with the conversion script.

The best news is that the entire process is capable of automation. This has 
the potential for real-time rendering wherever the tacticians wish to fight 
(or run).

I hope to have 3D renderings soon. Just for fun, here's an image created with 
GIS data similar to the elevation data I'm using:

  http://photojournal.jpl.nasa.gov/jpegMod/PIA06668_modest.jpg

What are your orders, commander?


-Coop