Karaganda city digitalization was done by request of the DATA+ joint ventures. The goal was to form the topological basement of the GIS created for the Center of Operational Information at the city police service. For more detailed description of this GIS see the article published in ARCREVIEW N2 (2003) by Genadiy Radionov, key expert of DATA+.

The project was remarkable for its terms and process layout. We delivered material to the customer in parts as it was divided in five fragments, and every delivered fragment was immediately added to the GIS being created. So, returns and revisions were out of the question. Besides these draconian terms, the order of data transmission caused some additional mess.

We started with a trial project that is a compulsory part of any work. As thematic presentation of objects on the base of their attributes’ values was not provided in Easy Trace yet (V 7.7), we decided to form five polygonal layers – roads, pavements, water, plants, and others – plus two layers for buildings specified by the customer.

This thematic division of the coverage promoted good data presentation directly in course of digitalization. Errors of road net forming, isolated paved areas, and a lot of other “delights” were apparent at first sight. Another advantage consisted in acceleration of attributive data input, as operators had to select only among the attributes specified for this particular “areal” layer. Artificially separated layers were united into a single coverage of course before material handing-over to the customer. It took not more than a minute and maybe ten clicks of mouse buttons.

But planning of the optimal layer set is only the above-water part of the iceberg at trial project fulfillment. Ideology of the Easy Trace package allows one to make clones of any project, i.e. ALL features of the project-prototype will be inherited at further work. Thus, we had to specify a lot of settings in the first project.

First of all, these are tracing strategies – named sets of tracing tools’ parameters optimal for this particular source material, resolution, and raster quality. Strategies are the basement of custom tools. The last words sound darkly, but custom tools in Easy Trace are simply buttons that allow quick selection of a tracing tool, its strategy, and the layer of created vector objects. It seems to be a trifle, but saves 10-15% of time.

It is also very important to prepare in advance topology verification strategies, i.e. sets of layers to be checked and sets of verification criteria to be applied to these layers. There may be a lot of verification strategies in the project, but they are much quicker than tests of polygonal coverage. So, it’s not reasonable to save time at the expense of this operation.

The last thing to do is color specifying for raster and vector layers. One must not neglect it – uniform settings help operators from the QC group, and in addition fireworks-like colors of the screen can drive you mad in a day. Muted gray-green tints are preferable for raster layers, and contrast colors hinting at the corresponding layers’ themes – for vector ones.

The trial project (or rather a couple of sheets processed after it) allows one to determine operator job prices. The estimation is simple - we divide time of work in number of objects for every layer. It is convenient to use Easy Trace integrated statistic means for the estimation.

After we have known the average time per object and the number of objects on every layer, we can estimate the time of the entire project digitalization. And the cost of one minute of operator’s work is general knowledge. This is our usual approach, although poor quality of rasters forces us sometimes to apply a step-up factor.

The next step is assembling of the whole raster coverage of the project. Simultaneously we prepare its chart and specify projects. It is convenient to use an Exel table as a chart. Different colors of its cells show project status and the rate of fulfillment. At last, we have a project (created on the base of our carefully adjusted prototype) with full raster coverage. A specialized Easy Trace utility cuts projects out of it that will be distributed among operators for further processing.

The next turn is worthy of applauding. The customer unexpectedly asked information on ALL buildings and constructions of the city. These fragments of the future map were given to district police officers and they FULFILLED ACTUALIZATION of data without a break in their main job. This meant for us some additional feverish activity, but what a beautiful approach!

As it was already mentioned above, we delivered material to the customer in five fragments, starting with the most laden one, i.e. city center. It would have been much easier for us to deliver it as a whole of course – we wouldn’t have to coordinate the rate of processing of different projects and their “buffer zones”.

Some words about terminology by the way: we mark out five levels of data division by the area. The first level (that is clear without explanations) is the map sheet. The second level is the project – several adjacent map sheets to be processed by one operator. Next is the block – several united projects, then the fragment (that we delivered to the customer), and then the whole city.

What is it for? First of all, we try to avoid processing of map sheets one by one as it is does not pay. Easy Trace is a resource-saving package able to process several black-and-white sheets at once even at Pentium 233 MHz, 64 Mb. (Actually, the operator never processes one map sheet only, usually there are at the least nine of them in the project – the central sheet that is being vectorized and eight sheet fragments forming a kind of frame.)

Gain in efficiency is caused by joining of map sheets just while their processing, decrease of number of units to be accepted and checked, acceleration of attributive data input, data verification and correction.

Besides, the operator needn't reorganize the work so often at processing of several map sheets as a whole. For example, it’s rather difficult to start digitalization of the city industrial zone after you have been tracing contours of garden-plots (that are really numerous in our towns!) for a long time. What is more, one begins understand the map better at processing of a big region, and it is very useful considering extremely poor quality of source rasters that require sometimes decoding rather than tracing.

Raster quality is a special item at large project fulfillment. One often face with unwillingness to spend time for selection of scanning parameters or with resolution decrease for the purpose of data volume reduction (even now, when it is difficult to find a disk less than 40 Gb!). If you have to process a map that is good enough but scanned at 150 dpi resolution and full of thick mergedlines (“just to make them clear!”) you may multiply working time in two at the least...

Let us return to the question of data division by the area. The next level is the block. It is assembled of several projects with line joining at their boundaries and compulsory repeated verification of the polygonal coverage. It is not reasonable to postpone verification till the block grows up.

Unfortunately, the time required for polygonal coverage verification increases nonlinearly depending on the number of vector objects in the block. That’s why it is better to assemble several blocks rather than a big one. It is also desirable to avoid long and twisting boundaries at assembling of blocks and fragments.

At last, we unite several blocks into a fragment that will be delivered to the customer. It goes without saying that new verification of the polygonal coverage will be fulfilled after merging of the blocks. One should remember that once delivered, the fragment becomes inaccessible for alternations. That’s why it is necessary to “dub” its edges beforehand. In other words, the “buffer zone” along its boundaries should be also processed by the time of delivery.

Topology verification is a repeated operation that should be done at every stage of data assembling. But there is another kind of information – attributive data - that also needs a check-up. This operation has some ruses too.

First of all, the package provides a special view mode to simplify search of objects that have no links to the database. When in this mode, such objects are glittering with yellow on the gray background, and their nodes are highlighted. It’s simply impossible to overlook them. The task is to input attributive data for these objects and thus to quench them. It is convenient to use the Group Editor for it, as this tool enables simultaneous input of attributive data for a group of uniform objects.

Besides, there is a special utility in the package that shows object attributes as inscriptions above the object. It remains only to compare them with data in the raster. Applying the utility, we used a “know-how” of course. If we have generated inscriptions out of meanings of attributes’ codes they would have covered the entire screen hiding everything. That’s why we used abbreviated “pseudonyms” of attributive data values (prepared beforehand, while the trial project processing).

As a matter of fact, that’s all about vectorizing of Karaganda. Some notes below are rather of methodical character. Operators are just people – it is better for them to see something once than to here about many times. That’s why it is reasonable to show the trial project to all of them – it solves a lot of questions at once. Besides, it would not be out of place to charge the best expert in vectorizing with preparing of a brief comics-like manual explaining the most non-obvious situations. This illustrated folder should be at the working place of every operator. Try – it will be repaid.

P.S. The 7.8 version of the package provides new additional means of vector and attributive data control. First of all, these are transparent filling of polygons and thematic presentation of vector data depending on attributive data values.