Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cs.utexas.edu!milano!cleo!peterson From: peterson@cleo.SW.MCC.COM (James Peterson) Newsgroups: comp.graphics Subject: Re: North America (5 of 5) Message-ID: <1214@cleo.SW.MCC.COM> Date: 15 Sep 88 22:27:50 GMT References: <1202@cleo.SW.MCC.COM> <4064@umd5.umd.edu> Organization: MCC, Austin, TX Lines: 77 In article <4064@umd5.umd.edu>, jonnyg@umd5.umd.edu (Jon Greenblatt) writes: > > I took these billions of ascii encoded points and converted them > into a postscript form and previewed it successfully. I was VERY DISAPPOINTED > This ended up being a very low detail picture where most of the data is > used to make thick lines by drawing thousands of thin ones. > > Please don't ask me for the code I wrote, I threw it out. I'm sorry that you found it so useless. I realize that it was a large amount of data, but it seemed like useful data with the programs that I have to display it. Unfortunately the programs only put maps on the screen for the original Andrew window manager, so they would not be of much use to anyone else. Still I was puzzled by your characterization of the data ("very low detail picture where most of the data is used to make thick lines by drawing thousands of thin ones"), so I added code to my display program to allow me to zoom in on a section of the map. Using the last file only (5 of 5, which it seems is most of Alaska) directly from the newsgroup (maybe something went wrong with the posting?), I still did not find what you had suggested. However, I had never tried using it as input for PostScript before, and that seemed like a really smart thing to do. I took the posted file (5 of 5), stripped the header and trailer off, and added a D2 command to the end of each line. Then I defined the following D2 command in PostScript: /D2 { moveto lineto stroke} def Using NeWS as a PostScript display engine, I added the following to take care of the use of lat/long units and to clear the root canvas before drawing: %! This file goes from -168 to -128 in x and 50 to 74 in y clipcanvaspath 1.0 setgray fill % clear canvas 0.0 setgray 8 72 mul -128 -168 sub div 8 72 mul 74 50 sub div scale 168 -50 translate /D2 { moveto lineto stroke} def -128.778 53.889 -128.794 53.893 D2 -128.783 69.865 -128.762 69.796 D2 ... Running the resulting file through psh for NeWS, everything looked fine on the screen, so I still did not understand the problem you were having with the data. As a final check, I deleted the "clear canvas" code, added a showpage at the end, and sent it to a laser writer. NOW I understood your comments! The laser writer output looked terrible! One of my co-workers said "Trying to print a prehistoric bear, huh?". The whole PostScript file (just of Alaska) was 2516 lines long, so I cut it down to just 5 line segments -- problem was still there so it wasn't because the file was too big or a clipping problem or something. But looking at the five line segments, I saw the problem. The line WIDTH was wrong. Checking the Red book, we find (on page 59), line width ... "The thickness (in user coordinate units)... (Initial value: 1.)". So since user coordinates had been transformed to latitude/longitude (near Alaska) the line segment widths were 1 degree of arc. To check this, I added the following line to the PostScript code: 0 setlinewidth and now it comes out fine. I assume that your PostScript code was similar to this and had the same problem. Apparently NeWS does not yet do thick lines, so the linewidth problem did not show up in my NeWS test. I think if you try code like this you will find the maps look more reasonable. You will need to adjust the scaling and translation for a different part of the world -- I was only trying to see if the data was as bad as you suggested. jim -- James Peterson james.peterson@mcc.com or ...sally!im4u!milano!peterson