Extras | Grid | Count

Top  Previous  Next

Job of this process is to indicate a rectangular cutting from one or to several, also to overlapping grid tiles.

For this some conditions must be fulfilled:

As grid data TIFF files with 2, 16 or 256 colours Colour depth must be given.

For every grid file a configuration file must be given (Extras|Raster|Einmessen or. MakeRasterConfigFile).

Every grid file stands together with her configuration file in own subdirectory. (Exception: If the colour planes of a tile are given as separate TIFF files, they must be written in each case in a list.)

All subdirectories stand in a common grid list.

At least one plan must exist or be put in whose plan borders define the later cutting of the grid tiles.

These for the regulation of the cutting decisive plan or these plans are searched later by the programme in a suit-level sheet type, therefore, they must stand in a list intended for it in the upper list GDS$DBB.

There is an other sheet type which can take up the aim tiles. This sheet type also exists as a list in the upper list GDS$DBB. The list name must be numerically with at least 3 places.

About the menu point Extras|Raster|Rechnen if becomes the function TiffMakeRasterDB called.

1. Authoritative plans load.

2. Call from Extras|Raster|Rechnen or. TiffMakeRasterDB.

3. Give sheet type for the new data, he must exist as a list.

4. Give sheet type of the authoritative data. The plans must be already loaded (see 1.). The function generates for every plan a TIFF file as well as in the aim list in each case a new plan which contains this TIFF file.

5. An object key is questioned for the new objects.

6. Several times it is questioned in which list eingemessene grids stand. Besides, the subdirectory (in which only the TIFF file itself stand and the configuration file) is left out. Thus all grids are inserted in all subdirectories. As a format it is given as a rule always SELF. For the end this query sequence is closed once with Return.

7. To calculate the resolution for the new TIFFs, is difficult a little bit. The graduation of the scanned maps (in the original) and the resolution is required while scanning. Then the number of the pixels calculates itself as a rule after the formula x <= dpi*4//Maßstabszahl.

8. Because the following calculation process can be more protracted every now and then a little, the possibility for the demolition is given before real generating of the data once again.

9. As an end the new TIFF files are generated under use of the configuration files. Besides, all given grid data are so spliced that the tiles falling in the given plan are used. Frames are cut off.

10. After this procedure the plans must be protected. If necessary are able about identifying a grid and „Daten|Eigenschaften element...“ the colours of the grid elements are changed. Moreover, the generated TIFF files with every TIFF editor can be changed. Moskito includes the changes. This encloses changes of the resolution.

Order eingeben:TiffMakeRasterDB

Which sheet level should contain the grid?:

200

Which sheet level contains the plans, to those

the grids should be generated?:

910

Which object key should the new objects receive?:

199

Where do the Tiffdaten stand?:

H:\projects\moskito\rahmen\Raster

Please, give data spring:

LVA_BW_TK25 or

LVA_BW_TK50 or

LVA_BW_TK100 or

LVA_NRW

LVA_NIEDERSACHSEN

SELF

SELF

Where do the Tiffdaten stand?:

 

Resolution of the aim data.

Number of the pixels metre: (<=dpi*4 / / graduation)

0.3

Everything OK? [Ja|Nein] (N) j

Jump over plan BAM845702, no grid data in the area

Jump over plan BAM830672, no grid data in the area

Order give:

Example: