GIS Tutorial Online

GIS Tutorial Online

[D. Cooper Stevenson]

All,

Nice GIS image here:

  http://wiki.xconqgis.org/images/grass_tutorial/kfalls.jpg

Complete tutorial (including screen images) on the Wiki here:

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

There's so much work to do! I'll answer each of your emails soon...


-Coop

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

Re: GIS Tutorial Online

[Eric McDonald]

D. Cooper Stevenson wrote:

> Complete tutorial (including screen images) on the Wiki here:
> 
>   http://wiki.xconqgis.org/index.php?UsgsMapImportHowto

Nice work.

   Thanks,
     Eric

Re: GIS Tutorial Online

[Eric McDonald]

sales@gencom.us wrote:

> Now, one way to do this is to define a unique terrain type per tile. This, I
> think (and seems to be the consensus), does not seem to be the "cleanest" way
> to go.

I think it depends a lot on what you are trying to achieve. If you are 
planning on having more than one type of data associated with each hex 
(elevation, vegetation, terrain ruggedness), then it would seem that you 
would run into a multidimensional "data boxing" problem (which can be 
solved with multidimensional boxing routines that you would have to 
write) if you were trying to use less than 1 terrain type per image. If 
you only care about elevation data, say, then you can easily just bin 
the data according to elevation ranges, and thus don't need 1 terrain 
type per hex image. The alternative to multidimensional boxing is to 
have a 1:1 correspondance between terrain type and hex image.

I'm not sure what Matthew (IIRC?) had in mind when he disagreed with the 
1 terrain type per hex image idea. Maybe we are all miscommunicating 
what we really mean....

> It would be better, I think, to specify each tile as a file name (probably x,y
> such as 0x0.gif, 0x1.gif and so on) and have these images referenced by Xconq
> individually.

I have no problem with multiple files in an intermediate processing 
step, but all the terrain images for a given terrain image set should be 
kept in one file, when all is said and done. See 'stdt44x48.gif', 
'advt44x48.gif', and 'civt44x48.gif' in the 'images' directory for 
examples of what I am talking about.

Also, see 'terrain.imf' in the 'lib' directory to see how the various 
images are indexed within the files and assigned names.

> I know that Hans created and implemented a similiar patch that permitted units
> to have more than one image.

Right. There are several places you need to look to see how this was 
handled. A good starting pointing would be the properties files.
If you look in 'utype.def' in the 'kernel' directory, you will notice 
that the 'image-name' property is a list; you can tell this because it 
is a "DEF_UPROP_L" macro (the "L" is for "list"). By contrast, if you 
look in 'ttype.def', you will notice that the 'image-name' property is a 
string; you can tell this because it is a "DEF_TPROP_S" macro (the "S" 
is for "string").

Now, if you want to find out places where the 'image-name' property for 
units is used in the Xconq code, then you can just search the C source 
files in the 'kernel' directory and the various UI directories for 
'u_image_name', as this is Xconq's internal name for the property (as is 
indicated in the definition).

The other thing to do is search for 'image-name' in 'keyword.def'. This 
file enumerates all of the internal constants associated with GDL 
(Xconq's game design language) keywords. You will find that the name of 
the constant associated with 'image-name' is 'K_IMAGE_NAME'; you can 
search Xconq's sources for this to find out where and how it is being 
used. You most likely encounter it in 'read.c' and 'write.c', which are 
related to the reading in of Xconq games and the writing out of Xconq 
saved games.

A final note: IIRC, there are arrays that store the unit images (or at 
least their name lists/strings), so that they can be looked up and 
utilized quickly. One would probably want to do the same if one chooses 
this route for terrain images.

Of course, if one chooses to not bother with mutliple images per terrain 
type, then writing new Xconq code should not be necessary....

   Hope that helps,
     Eric

Re: GIS Tutorial Online

[mskala]

On Fri, 24 Sep 2004, Eric McDonald wrote:
> I'm not sure what Matthew (IIRC?) had in mind when he disagreed with the 
> 1 terrain type per hex image idea. Maybe we are all miscommunicating 
> what we really mean....

Just that it seems like it'll multiply terrain types unnecessarily, and
terrain types are somewhat expensive.  If I have two chunks of almost
identical desert, but they have different images, then I have to duplicate
the definition of "desert" throughout my game definition.  Even if I
define a list variable for "all desert hexes", that's only a syntactic
convenience - the actual game definition still has two separate complete
copies of the definition.  It's especially a problem because "two" in this
case is probably more like "hundreds".  I don't want to look at the help
menu that will result from having hundreds, or thousands, of defined
terrain types...  I'd much rather be able to define images per-hex instead
of per-terrain-type; that seems like it would serve the same goal and be
much nicer.

On multidimensional "binning", that's a well-studied problem and relevant
to my research, so I'd be happy to expound on the different standard
algorithms for it if people would like.  I did some of that (with just two
dimensions) in defining terrain types on the Antarctica map, as described
in the document about that which I posted on the Wiki; there, I wasn't
doing it in an automated way but just by hand, manually examining the
scatter plot and tweaking classification rules to get results I liked.

By the way, has anyone tried playing the "standard game adapted for
Antartica" module I posted?  I'd be interested to hear how people liked it
if they tried it.

> I have no problem with multiple files in an intermediate processing 
> step, but all the terrain images for a given terrain image set should be 
> kept in one file, when all is said and done. See 'stdt44x48.gif', 

It would be really nice, too, if that one file could be just the direct
image (possibly scaled to size), and then XConq smart enough to clip out
hexagonal chunks in the right places.  That would mean changing the
read-from-image code to use a hex grid corresponding to the map instead of
the current square grid, but it would mean eliminating an especially nasty
cut-and-rearrange step in creating the file.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: GIS Tutorial Online

[Eric McDonald]

mskala@ansuz.sooke.bc.ca wrote:

> Just that it seems like it'll multiply terrain types unnecessarily, and
> terrain types are somewhat expensive.  If I have two chunks of almost
> identical desert, but they have different images, then I have to duplicate
> the definition of "desert" throughout my game definition.  Even if I
> define a list variable for "all desert hexes", that's only a syntactic
> convenience - the actual game definition still has two separate complete
> copies of the definition.  It's especially a problem because "two" in this
> case is probably more like "hundreds".  I don't want to look at the help
> menu that will result from having hundreds, or thousands, of defined
> terrain types...  I'd much rather be able to define images per-hex instead
> of per-terrain-type; that seems like it would serve the same goal and be
> much nicer.

In principle, I agree with you. I think that it comes down to the 
question of whether you or Coop are up to hacking on Xconq to add the 
necessary support, either more than one image per terrain type or 
pulling an hex image directly from a map image (as you suggest below). I 
have enough other things I plan on doing that I doubt I would 
participate in such an endeavor, except to merge and test patches, and 
provide feedback and guidance where I am able. I am certainly not going 
to discourage either of you from working on the kernel and UI code.

> On multidimensional "binning", that's a well-studied problem 

Sure, I know. And I only called it "boxing" because I thought people 
might be tired of seeing me write "bin" or participles thereof over the 
course of the last few days....

>and relevant
> to my research, so I'd be happy to expound on the different standard
> algorithms for it if people would like.  

Good.

> By the way, has anyone tried playing the "standard game adapted for
> Antartica" module I posted?  I'd be interested to hear how people liked it
> if they tried it.

I tried your original when you posted it to the list. I haven't tried 
any updates that you may have made to it. I've been pretty busy just 
trying to keep up with Elijah lately. :-)

>>I have no problem with multiple files in an intermediate processing 
>>step, but all the terrain images for a given terrain image set should be 
>>kept in one file, when all is said and done. See 'stdt44x48.gif', 
> 
> It would be really nice, too, if that one file could be just the direct
> image (possibly scaled to size), and then XConq smart enough to clip out
> hexagonal chunks in the right places.  That would mean changing the
> read-from-image code to use a hex grid corresponding to the map instead of
> the current square grid, but it would mean eliminating an especially nasty
> cut-and-rearrange step in creating the file.

This would be a useful feature. One could then envision ye olde time map 
with a fancy compass rose, spouting whales, and sea monsters as part of 
the background artwork. I would certainly be supportive of anyone who 
wished to add such a feature.

Eric

Re: GIS Tutorial Online

[Eric McDonald]

sales@gencom.us wrote:

> Quoting mskala@ansuz.sooke.bc.ca:

>>I'd much rather be able to define images per-hex instead
>>of per-terrain-type; that seems like it would serve the same goal and be
>>much nicer.
> 
> To me this makes sense. This would mean that map attributes are defined in a
> uniform array per tile. The _tile_ is the object. It then carries with it a
> number of attributes such as terrain type, elevation, climate, etc. 

An individual hex only has certain attributes that can be associated 
with. Among them, terrain type and elevation. As it stands now, images 
are only associated with terrain types, and not directly with hexes. An 
hex acquires an image via its terrain type. As far as other attributes 
such as climate, terrain ruggedness, vegetation, etc... go, you must 
find some way of artificially simulating those attributes. I suggested 
one way (creating defined groupings in the game definition file), and 
Lincoln suggested another (using coatings as sort of customizable 
"attribute layers").

It should be noted that Xconq has the concept of layers, which were 
mentioned in a references I sent you a while back ago. Layers track 
things such as terrain, winds, coatings, connectors, borders, land or 
sea, etc.... One can argue about what a Xconq map hex is, but one way to 
look at it is something that has a coordinate position and has "depth" 
into one or more layers. All hexes have depth into the terrain layer, as 
this tracks terrain type and how is an hex is able to "know" what it 
looks like.

> Does this mean major changes to the Xconq code, Eric? Would we have to change
> the Xconq kernel or could we get away with doing this on the module side?

I have made no attempt to quantify how much work will be involved. In 
the reply I sent you last night (to your "cstevens" address and not the 
"sales" address), I outlined some of the areas you will probably want to 
look at. I think it is reasonable to assume that you will have at least 
some coding that needs to be done in the kernel and the user interfaces.

>>It would be really nice, too, if that one file could be just the direct
>>image (possibly scaled to size), and then XConq smart enough to clip out
>>hexagonal chunks in the right places.  That would mean changing the
>>read-from-image code to use a hex grid corresponding to the map instead of
>>the current square grid, but it would mean eliminating an especially nasty
>>cut-and-rearrange step in creating the file.
> 
> I agree. This way if Eligah wanted to create his "Lord of the Rings" map, he
> could simply do so starting with a Middle Earth map

If people want to try doing things this way, it could probably be done 
by creating two new layers (x-pixel-coords and y-pixel-coords), which 
would contain the pixel coords within the map image that are associated 
with each hex. Then, instead of indirectly accessing an hex image 
through terrain type, it would be pulled from this layer instead. I 
haven't thought through the details; _just throwing out an idea....

Eric

Re: GIS Tutorial Online

[D. Cooper Stevenson]

On Sat, 2004-09-25 at 10:32, Eric McDonald wrote:
> 
> If people want to try doing things this way, it could probably be done 
> by creating two new layers (x-pixel-coords and y-pixel-coords), which 
> would contain the pixel coords within the map image that are associated 
> with each hex. Then, instead of indirectly accessing an hex image 
> through terrain type, it would be pulled from this layer instead. I 
> haven't thought through the details; _just throwing out an idea....
> 

This would save a _ton_ of work. Do you think you could still give
others the flexibility of assigning other tile attributes (vegetation,
climate, rainfall, etc) using this method?


-Coop

Re: GIS Tutorial Online

[Eric McDonald]

D. Cooper Stevenson wrote:

> On Sat, 2004-09-25 at 10:32, Eric McDonald wrote:
> 
>>If people want to try doing things this way, it could probably be done 
>>by creating two new layers (x-pixel-coords and y-pixel-coords), which 
>>would contain the pixel coords within the map image that are associated 
>>with each hex. Then, instead of indirectly accessing an hex image 
>>through terrain type, it would be pulled from this layer instead. I 
>>haven't thought through the details; _just throwing out an idea....
>>
> This would save a _ton_ of work. Do you think you could still give
> others the flexibility of assigning other tile attributes (vegetation,
> climate, rainfall, etc) using this method?

Xconq does not inherently know anything about the attributes you listed, 
and so it would currently be meaningless to associate portions of an 
image created from such GIS data with them. To handle such things, you 
would need to determine how they were relevant to your game, and then 
use the appropriate GDL tables and properties to emulate them with 
respect to their repesentation as coatings, say.

Eric