From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16126 invoked by alias); 28 Oct 2004 00:54:45 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 16009 invoked from network); 28 Oct 2004 00:54:44 -0000 Received: from unknown (HELO smtp811.mail.sc5.yahoo.com) (66.163.170.81) by sourceware.org with SMTP; 28 Oct 2004 00:54:44 -0000 Received: from unknown (HELO ?192.168.1.101?) (sampln@sbcglobal.net@64.175.251.169 with plain) by smtp811.mail.sc5.yahoo.com with SMTP; 28 Oct 2004 00:30:52 -0000 Subject: Re: GIS Update From: Lincoln Peters To: cstevens@gencom.us Cc: Xconq list In-Reply-To: <200410271721.59236.cstevens@gencom.us> References: <200410270401.09702.cstevens@gencom.us> <1098855994.26829.38.camel@localhost> <200410271721.59236.cstevens@gencom.us> Content-Type: text/plain Message-Id: <1098923706.26829.53.camel@localhost> Mime-Version: 1.0 Date: Thu, 28 Oct 2004 04:54:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01364.txt.bz2 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 If your happiness depends on what somebody else does, I guess you do have a problem. -- Richard Bach, "Illusions"