Re: [Rails-devel] Tile Database API & route calculation

[Erik V. <eri...@hc...>]

> 
> Comments?

This looks good enough for 1830 and the like. 
My only quick remark is that hopsleft is not checked for becoming zero.

A more general algorithm should take into account the possibility
that certain junctions would not count against maxhops 
(e.g. villages and ports in 18EU). In that case searching should
continue until hopsleft would become -1.
 
> If this is agreeable, what is the best way to represent the 
> connectivity 
> graph and the API to get the connectivity information from the tile 
> object?  You really have a tree -- a tile contains 0 or more 
> junctions, 
> each of those contains 0 or more exits (so map hexes with no 
> track are 
> covered), and each of those exits connects to an arbitrary number of 
> edges and other junction exits on the same tile.  The two 
> obvious ways 
> are a graph of nodes and a 2-d bit vector showing 
> connectivity between 
> everything.  The latter would need to be built ourselves using longs 
> since arrays of booleans aren't packed.

I'm wary of bitmaps and would go for objects pointing to each other.
But that is more intuition than anything else.
Objects take more memory, but are we running short?

In the below I will use the terminology I have used 
so far in this project; I use "Station" for Junction
and will use "Junction" for the superclass of "Edge" and "Exit";
and what people often call Station or Token or Garrison or Railhead
I call a "BaseToken", which will (in the future) be one 
of the many subclasses of "Token".

The tree will then, in my opinion, look like:

Tile
|
+-- Station (value)
|   |        
|   +-- Slot (location)  <--> BaseToken <--> PublicCompany
|   |
|   +-- Exit   ------
|                    > Junction (superclass or interface)
+-- Edge (sidenr.) --    ^ ^  
|                        | |
+-- Track (gauge) <------+ |
                  <--------+

A Track connects two Junctions, either of which can be an Edge or an Exit.
Tiles obviously connect to each other via Edges.

> How would you like to see the interface to the connectivity 
> data in the 
> tile?

The <Tile> XML should specify all of the above 
(except of course BaseToken & Company)

Comparing this with the current Tiles.xml contents,
Slots and Exits would be added, and the location would
move from Station to Slot (where we need it for token placement).

(BTW the current location values are my encoding of the longer
location descriptions as used in TileDesigner. I suppose we will
need some sort of polar coordinates instead).

The structure per tile will be created when the XML is parsed,
and we will need to clone tiles of which the quantity is >1
(this is not done yet for tiles; it is done for certificates).

At least, this is how I tend to look at it....

Erik.