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

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

Looks good to me generally.
See some comments below.
 
> Ok, after looking at Iain's code, I propose the following:
> 
> Extend the tile XML file to show additional exclusive track 
> use and add 
> necessary drawing data:
> 
> <Tile id="62" colour="green" category="NY">
>     # position/rotation can be defaulted
>     <Station id="1" type="City" slots="2" value="80" 
> position="90,.4" rotation="0" />
>     <Station id="2" type="City" slots="2" value="80" 
> position="270,.4" rotation="0" />
>     # gauge and level are defaulted, use shorter labels for 
> size and parsing speed
>     <Track from="1" to="A" />
>     <Track from="1" to="F" />
>     <Track from="2" to "E" />
>     <Track from="2" to "D" />
> </Tile>

I presume that, in case a city has more than one slot,
slot center locations will be calculated from
the Station position and the tile orientation.
Can't we better specify these explicitly?

> <Tile id="Map-1841-Milano" colour="yellow" category="M">
>     <Annotation text="Milano" size="12pt" position="270,.7" 
> justify="b" rotation="0" />
>     <Station id="1" type="City" slots="1" value="60" 
> position="210,.6" />
>     <Track from="1" to "A">
>         <Excludes from="1" to "B" />
>     </Track>
>     <Track from="1" to "B">
>         <Excludes from="1" to="A" />
>     </Track>
> </Tile>
> <Tile id="23" colour="green">
>     <Track from="A" to="D" />
>     <Track from="D" to="B" />
> </Tile>
> <Tile id=16 colour="green">
>     <Track from="A" to "C" level="0"/>
>     <Track from="B" to "D" level="2"/>
> </Tile>
> <Tile id="Map-1830-Altoona" colour="fixed">
>     <Station id="1" type="City" slots="1" value="10" 
> reservedtoken="PRR" />
>     <Track from="E" to="1" />
>     <Track from="B" to="1" />
>     <Track from="B" to="E">
> 	 <Draw from="E" to="[210,.25]" radius="-.25" />
> 	 <Draw from="[210,.25]" to="[300,.25]" radius=".25" />
> 	 <Draw from="[300,.25]" to="B" radius="-.25" />
>     </Track>
> </Tile> 

This tile happens to be the only one with drawing instructions.
I presume, that in all other cases the drawing instructions are
derived automatically. 

For instance tile #65 (OO city with a sharp and a wide bend):
would the tracks be curved by default (as they should, IMO), 
or are special drawing instructions needed to achieve that?
(TileDesigner derives such things from the specified off-center city
location).

> Tile code defaults to the id if it is numeric, otherwise it 
> defaults to 
> "", can be overriden with code="603" etc.

What is the purpose of the tile code?

In Tiles.xml I had made a distinction between "id" and "name",
where id must be unique. "name" was intended to be the tile number 
as printed on the tile (not by TileDesigner, though), 
and is displayed on the screen and in the logs where applicable.
So the two different tiles 69 have ids 69 and 1069, but both have
name="69". Is this perhaps what you intend to use code for?

And what is the use of "Category"? Just a simple way to create annotation?

> Note that for the #23 tile the excludes are automatically picked up 
> since the edges overlap.  Since 90% of the gauge will be normal, it 
> makes sense to default that attribute (as well as level, 
> which is only 
> needed for tiles with overpasses).  The Milano tile shows how extra 
> excludes that wouldn't be known just from looking at the connectivity 
> information are specified.  The last tile shows how you can 
> specify how 
> to draw a particular piece of track if the default choices 
> won't work (a 
> negative radius means curving away from the center of the 
> tile, positive 
> means curve towards the center; leaving radius out means a straight 
> line).  

Wouldn't preprinted Milano then also need drawing specifications
to show the tracks joining?

If you are worried about intialization time (and 
> automatically 
> positioning elements that don't have a position specified is not a 
> trivial task), this file could be built from a master file 
> that contains 
> all the tile definitions and filling in all the drawing and other 
> defaulted information.  Once you do that, this needs to be 
> considered a 
> generated file, but that is a good thing since otherwise you 
> will have 
> multiple copies of the same tile data that have to be updated and we 
> know that means they won't be exactly the same.
> 
> In addition to text annotations, we need to support other 
> annotations as 
> well, which would be used to show additional building costs 
> or graphics 
> added to the tile.  In my perl code, I just supply arbitrary 
> postscript 
> code for them, but that won't work here.  I suggest having something 
> like <Annotation shape="xxx" position="a,r" scale="s"/> which 
> references 
> shape xxx defined elsewhere, either SVG to draw it or perhaps even 
> custom code.
> 
> It will be a lot less work to add the excludes that can't be deduced 
> automatically than to do all the splitting of junctions into junction 
> exits, and the resulting datastructure will be simpler as well.

Yes, this is much simpler. 

How about scaling?
The main problem we have with the tiles generated by TileDesigner is,
that these do not scale down very well. 
Revenue value and tile number get unreadable on the map.
Do you have a fix for that?

Erik.