M. Tech,
Manager Cartography & RS
RK Gupta*
Ph.D.
Manager Geo System
Brig MC Dhamija (Rtd.)*
former DDSG, SOI & GM (Co-ord)
*Pan India Consultants Pvt. Ltd.
India
[email protected]
With the advancement of technology and service of mapping and advent of printing, multicopies of maps was made feasible. The art of cartography and map printing kept pace with the advancement. Now a days, most map data is archived in vector digital form which is used for printing multicolour maps on paper.
Hither to for cartography and map printing had been in sole domain of the National Mapping Agency, the Survey of India (SOI). SOI now, has with them a huge collection of vector digital mapping data in polyconic projection. Publishing of its huge quantum of maps has stretched the inhouse resources of SOI. SOI has decided to get this work done from commercial agencies. As part of qualifying criteria to participate in this out sourcing by SOI, all interested bidders were required to produce print ready colour separates. Pan India being an in house R&D agency accredited by DSIR, Ministry of Science and Technology, under took a pilot project to produce the color separates ready for print. This exposition briefly describes the methodology for this task.
Offset printing solves the practical limitation. Success of print run depends on the production of printing plates which are produced by photographically exposing the image on to them. To do an accurate work in optimum registration of detail and colour, this is currently achieved by the stateof- art image setters. Where an inkjet printer sprays ink droplets, the image setter builds up its output, dot by dot with absolute pin point accuracy of resolution better than 2500 dpi. The image setter accepts post script. This post script output is a programme that has to be designed. Commercially available software need to be supplemented with user's symbol library. It is a general understanding of all computer users that any thing that appears on their screens can be printed out by simply processing the print command. However our understanding for unknown to computer users, is that there are built in software in printer and its driver. The image appearing on screen undergoes to a processing not obvious to the user which briefly is an image processing assembly that combines a first input of copied image data and a second input of electronic data to a storage device. A control device compares the resolution and orientation of the two types of data with each other. Where the resolution does not match or the orientation does not match, one type of data is rotated to match the orientation of the other type of data. The properly converted and oriented data are combined as well as half toned and then printed out as CYMK colour separated files.
There is a growing demand for GIS map products to be mass-produced. When it is not cost-efficient or practical to make multiple copies of a digital product on a plotting device or colour output device such as a colour laser printer, it is then necessary to combine the technology of digital mapping and offset printing.
There are a variety of means to this end, depending on the user's software/hardware capabilities, and also on the capabilities of the printing vendors in one's area to accept and utilize electronic data, or to use mechanical separations to accomplish the finished, four color CYMK product.
SCREEN MAPS V/S PAPER MAPS
It is important to realise that printed maps are very different from screen maps. The major distinction is that screen maps usually have some degree of dynamism, whereas paper maps lack this characteristic completely.
The producers of printed maps have to make sure that their maps are as clear and legible as possible. Traditionally in map printing, special techniques and methods are used to achieve this aim.
Software that is used to prepare maps for printing must make it possible to use cartographic techniques, whereas GIS software usually does not, at least not in an efficient way. GIS software was developed to collect, structure, manage and analyse geospatial data and to display the resulting maps on a screen, not on paper.
GIS providers added modules to convert their screen maps to a format that is printable. Most often they used PostScript, sometimes TIFF, more and more PDF now (the new standard in the printing industry). As was already pointed out above, a straight copy of a screen map is not readily usable as a paper map, because of the higher demands on clarity and legibility of the letters. There are other reasons as well, such as the fact that GIS operators usually work on a small section of the map by zooming in. This means that there is never a need to visualise the whole map in detail on the screen and that shortcomings in the symbolization of the data remain undetected.
Another reason that makes converted GIS maps less suitable as printed products originates from the fact that they usually have a temporary character. Therefore, producers of these maps do not (want to) spend a lot of time on designing the symbology (the "looks") of the map. And therefore, in their turn, the developers of GIS software have not spent a lot of attention to providing the design tools needed for the symbology of printed maps. As a consequence of all this, high-quality publishers usually need to spend a considerable amount of time and effort to turn the converted GIS maps into paper maps that comply with their standards. Modifications may include but are not restricted to the:
Correction of inks and colors (as the RGB to CMYK conversion may run astray) Replacement of fonts Removal of hairlines Addition of high-quality symbol definitions Re-arrangement of layers
The production of readyfor- publishing documents can be automated completely by means of a number of commercial software. These modules combine the strength of a professional workflow management software and a purpose-built cartographic layer.
We distinguish 6 major steps in the first-time production of a map or chart:
- Importing the geospatial data
- Designing the symbology
- Defining the map layout
- Adding production features
- Performing a final check
- Generating the output
Converting incoming data to a single format has a number of definite advantages. First of all, we can use a number of standard operations to filter and correct the data. Secondly, it is easy to combine data coming from different sources into a single map.
The imported sample data are used to define the symbology for the areas, lines, points, text and images that will appear on the map. As the data are kept in vector format throughout the whole workflow, we immediately see the result of our work on the screen.
More importantly still is the fact that the maps will come out on paper exactly as we see them on the screen. Thanks to our WYSIWYG technology (What-You-See- Is-What-You-Get). This is possible because Mercator does not work in RGB but with representations and compositions of the actual printing inks (CMYK and Pantone).
The symbology definitions are stored in a socalled Map Style File. This MSF also contains the information on the printing priorities of the objects with relation to each other. The Map Style File is stored independently of the data, so that we only have to create it once and can then apply it to all maps in the same series. Extra map elements such as the legend, scalebar and text boxes can all be created and added to the map to create a complete cartographic document.
Images (TIFF primarily) can also be included. Elements that are used in more than one map can be generated and stored once and are then linked to all the documents in which they are used. If an element has to be modified later, this only needs to be done once for all the documents in which the element is used.
As, said before, everything we do should immediately be visualisable on the screen in WYSIWYG (at an unsurpassed speed). This allows to check designs immediately.
If necessary, we can switch off and on layers to make the checking process easier still. As the imported GIS data remain in vector format, we can correct them till the last minute before the final output. It is also possible to check the final map ink per ink, so that we can look at the printing separations on the screen and correct any mistakes in the masking without wasting consumables.
For high-volume producers that make use of different external printing houses, the TIFF Group 4 output option seems the best possible option for consistency in printing results.
All production parameters should be possible to be saved independently of the map. They can then be re-applied to other maps in the same series, with no or only with minor adaptations.
PROJECTION & DATUM ISSUES
SOI has, interalia, laid down some procedural guide lines for layout orientation, symbology & others which briefly are as under:
The open series map are to be published in UTM projection on WGS84 datum. The central meridian of UTM projection lies at the centre of 6 degree longitudinal belt zone. Dimension and orientation of each UTM projected sheets differ among themselves in 'East West' as well as in 'North South directions. It also differs from existing sheets which are projected on polyconic projection. The latitude lines of UTM projected sheets are not parallel to X-axis (horizontal).
Tilt towards east or west increases as we go away from the central meridian of UTM Zone. Maximum deviations will be in the Western and Eastern edges of a UTM zone. Dimension & Orientation of sheet also varies as per latitude.
Maximum tilt is up to 2 degree. Therefore designing a standard layout for the map for OSM (UTM projected) is much more complicated than the polyconic maps. Besides there are guidelines on designing the lay-out.
The guidelines also give the details of layout and symbology along with levels (layers) in which the data has been organized. SOI has vectorised the data in 63 levels. Each level contain a specified item such as building, Hydrology, land cover, boundaries & so on. Each feature in any level has a unique four digit feature code and level code. With this kind of specification, it becomes imperative to carry out a thorough examination to eliminate all possible inconsistencies. As has already been stated that if any discrepancy remain unnoticed the entire work may have to be re-done, which involves lot of time and expense. We followed the procedure set by SOI and are able to get our sample safely from our system on to printer service provider's. It is now ready for direct outputting.
For colour work, however, there's a whole other stage involving CYMK colour separates and digital half toning that has to be gone through to ensure that the results come out as we would like. That stage is prepress and beyond the scope of this exposition, since it is more of print technology than cartographic technquie.
Now the sample data provided by SOI was patterned as per the data structure. Printout of the map was taken on colour laser printer as per standards laid down for hard copy examination. Corrections were carried out accordingly, after the examination. Now the digital data was ready to generate final output of patterned map without hill shades.
Yellow and green tint was extracted now from the final data as a separate file and imported to a new file in ARC-GIS 9.1. This file was overlaid on Hill shade file (.eps/.tiff) provided by SOI. 50% transparency was applied to yellow and green tint, vector data and saved the output as another .eps file. After this, inkjet plots of patterned output with hill shading and with / without contours were generated.
CYMK films were generated from the above data now. Data scrutiny in 63 levels is a huge task in itself. Manual checking involves opening each level and visually examining and correcting discrepancy. We therefore have undertaken development of software for auto detection of discrepancies in level assignment and these are displayed in single file. By this a lot of optimisation and time saving has been achieved. This software is currently in beta version and work is in progress to refine and optimise it.
SOME SOLUTIONS
While there are a variety of answers to any production problem, some experimentation is required to discover the most straightforward approach to a solution, tailored to the hardware and software available to the user. In the case of SOI maps the straight forward line was for us to produce .EPS files using shadesets based on the four color process colors of Cyan, Magenta, Yellow and Black, and to deliver them in digital .EPS format to a commercial printer who had the capacity to create color separation. .EPS files and output them directly to their image setter device to produce half toned CYMK color separated films. In the process, for the future reference, we also experienced that mechanical separations originating from these same digital .EPS files, separated with Adobe Separator, and output on our high resolution laser printer result in very satisfactory final printed maps, in cases when we are proofing without using traditional offset printing methods.
This indirect method of outputting PostScript files undoubtedly works and it allows budget programs like Microsoft Publisher to claim that they can produce commercial print. However, in the real world the problems soon mount up. The first is the far more problematic is the whole question of control. By its very nature, the PostScript file process is inflexible. Once the Post- Script file has been created that's it. It will either output as you wanted it to or it won't; there is no room for manoeuvre. If we notice a last minute typo the only option is to change it on the original, recreate the file and transfer it again. More importantly, for advanced work there are the whole host of settings-halftone screens, trapping, crop marks and so on – that must be set exactly to ensure correct output. If any of these is wrong- and without a Post- Script printer you won't be able to proof your design to check them- you have just wasted a lot of time and money.
Ultimately then the indirect PostScript print file route is a non-starter for most serious work. It's like trying to operate on a patient in another roomand with your eyes shut. For the level of control necessary for regular successful output the only viable option is to output your publication files directly. That means finding an image setting bureau happy to accept PC work. Not only that, they must also use the same software as we ormore realistically – we must use the same software as them.
Cartographers face the daunting task of compiling and maintaining huge amounts of data in order to create digital map files. The problem often faced is that the existing applications cannot produce a map, acceptable for final output and publication, either on paper or electronically. Maps, created in a GIS often look pixelised and on paper contain various colours and textures that do not match with what was initially present on the computer screen. As well, problem with text is common.
In order to avoid such problems, several cartographic solutions are available. These were examined by us. Some of these are Mercator carto editor, used in SOI, Intergraph Map Finisher, Map Publisher lay Adobe illustrates and Macromedia and Cartographic Software package by ACE the complete description of these is out of scope for this exposition.
Acknowledgement
The authors are grateful to the management of Pan India Consultants Pvt. Ltd. for their permission to publish this exposition. Moreover the authors are grateful to Mr. Darshan Singh, CEO Pan India for his valuable advice and unstinted support for writing this exposition.
