[Xconq-general] GIS mapping revisited: are we getting close?

[Lincoln P. <sa...@sb...>]

I was re-examining the message archives on the xconq.org website, and
realized that, now that terrain coatings work the way I expect them to
(at least for materials), it might now be possible to use omniterr.g to
handle the GIS data.

Granted, there are several things I'd like it to be able to do that it
can't do yet (e.g. make coatings consume materials), but all of the code
needed to handle the GIS data should be there (we just won't be able to
do everything with it that we might want).

I've re-examined the discussions that we've had on the mailing list, and
I thought I should ask a few questions before I pressure anyone into
using this thing:


1. I can still re-work omniterr.g so that it uses terrain types that
correspond directly to those of the NCLD system (it should be very easy
to do so), although as I look at the NLCD system, I'm actually a bit
disappointed in how little data it tracks (at least in comparison to how
much data *I* planned to track).  Ultimately, I think it boils down to
the following question:

Is it worth the extra development time to translate the data in the NCLD
format to a format that can handle much more complexity, thus possibly
allowing us to use that data in conjunction with other data sources to
produce even more stunning maps?  Or is it more trouble than it's worth?


2. If we stick with omniterr.g as it is now, I don't think that the
extra (insofar unused) terrain coating definitions will present any
major problems, but there are a few cases where the omniterr.g module
uses multiple coating types that are all subsets of the landcover data
in the NLCD system (e.g. in the category of "herbaceous plant/
cultivated" areas, wheat and rice both fall under "small grains", and
none of the NLCD types cover potatoes).  Any thoughts?  Should I
simplify the agriculture coatings so that they more closely match the
NLCD system?


3. It occurred to me that the whole rivers issue might not be as
difficult as I had originally thought.  I remembered that, when I wrote
bolodd2.g, I used the "advterr" module for terrain (with a few
modifications to the percentiles), and I used the line "(add river
subtype connection)" to transform all of the rivers from borders into
connections.  It worked just fine; I was easily able to make naval units
sail up and down rivers, although I couldn't get them to adversely
affect the MP needed by land units to cross them (hmmm...I smell another
feature request brewing...).

Therefore, I could set omniterr.g to make rivers default to being used
as borders, but allow the game designer to re-define them as connections
(or maybe even coatings) if desired.  Although if a game designer wants
to use multiple types of rivers (e.g. allowing big ships to sail along
big rivers such as the Mississippi but not small rivers such as the
Petaluma), they would be stuck because of this method; the only solution
I could see here would be to make rivers coatings of variable depth (or
allow connections to have depth) and then require a minimum depth for
the unit to be able to traverse it.  That would certainly require some
amount of coding!

Border slides seem like a really weird concept (let alone a solution),
so I'd prefer to avoid using them.


4. As Matthew pointed out when I started writing this module, I'm
planning to make it handle far more data than a typical game would ever
want to deal with.  I might be able to deal with this by using a series
of "(if)...(endif)" declarations to allow the game designer to control
the level of detail, although depending on how the module is used, this
may or may not work (if it's used as a base module, it wouldn't be
possible to make Xconq run the necessary "(define)" statements before
reading the omniterr.g module).  Any thoughts on this?

By the way, I do have an idea for a game that could actually benefit
from using the GIS data in its full glory, but it's still in the
planning stage.


5. Having attempted to download data from the USGS website (a rather
slow process, due to the amount of server-side processing involved with
every job), it seems like it might be useful if we could find a way to
automatically fetch several batches of data from the website with a
minimum of manual effort.  I'm not sure that the USGS webmaster(s) would
appreciate it, though.  Maybe if the automated process delayed for a few
minutes between downloads, and if we could then mirror the GIS data on
our own server... (I know, it is very unlikely that we'd be able to
mirror the *entire* GIS database, but I can still dream!)


6. I have not yet tried to do any sort of data-processing on the GIS
data yet (I guess I should), so I'd like to ask those who have if they
see any reason that the whole process could not be automated using one
or more scripts (I would consider it automated even if the script(s) has
to ask lots of questions prior to processing the data).


For now, I'm not worried about synthesis methods, spontaneously
generating coatings, populating areas with units and/or roads, or
weather simulations, as none of those issues will prevent anyone from
CREATING maps using this module.  I think we'd all agree that we can
worry about those later.

By the way, I've calculated the total number of permutations of the data
that omniterr.g can handle, and assuming my calculations are correct, it
comes out to 3,264,000 permutations (not counting those that could be
created if coating depths >1 could have cumulative effects).  While some
of these combinations are patently absurd (tropical rain forest in a hot
arid desert, or xerophytes in a tropical rain forest), I still wouldn't
want to try to give each permutation its own distinct cell terrain type,
even if I did omit the impossible combinations!

---
Lincoln Peters
<sa...@sb...>

UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things.
		-- Doug Gwyn