Batch Plotting – Part 2
Posted by jeffhobbs on August 6, 2007
To continue on from last week. Overall I’ve been very pleased with batch plotting. It does have its quirks, but overall, it works very, very well.
In the past, with Intergraph, I’ve developed a couple of mapbooks for different customers. In these past cases, the mapbooks have all had a large number of layers, but have all been referencing an Oracle database. This makes it nice because you can build a lot of the logic into the Oracle database. Furthermore, you don’t need to hunt and peck to try and find the right data.
With my most recent mapbook for San Jose Water Company, I needed to use data from a number of different sources including MGE, SmartStore, CAD, Access, and Oracle Locator. Additionally, I probably have over 100 different feature classes in the legend. Now, although the mapbook design is relatively straightforward, there are still 672 maps that make up the mapbook. Before this mapbook, the most sheets I had ever created was approximately 300.
Here are some of my findings from getting this kind of output from the Batch Plotting Utility:
- Depending on the volume of the data, you may need to look at working with multiple geoworkspaces with different spatial filters. GeoMedia is known for being a bit of a RAM hog. Typically I find that if my geoworkspace gets over 1gb, then things start to get a bit volatile. With the shear volume of data, whenever I’d try and batch plot all 672 maps at once (sequentially), GeoMedia’s RAM usage would get to about 1.2gb and then GeoMedia would crash. As a result, I eventually needed to break my data (most of Santa Clara County) into three geoworkspaces and create five batch plotting files. With this breakdown, I’m able to keep the RAM usage below 1gb and this seems to keep GeoMedia happier. It should be noted (and I have experienced it personally) that Intergraph has really reduced the amount of RAM GeoMedia 6.1 uses for many things. As a result, I hope to be able to reduce the number of .gws when I move my mapbook to 6.1 later this year.
- PDF Output can be tricky. In one of my previous mapbooks, all of maps printed out fine except for one page where I was getting about 99% of the map, but the PDF would come up with an error before drawing the marginalia. Worse yet, when printing to TIFF or another raster format…no errors! When working on the SJWC mapbook, many of the maps would print fine but there were a handful that did not. And, when they didn’t, it was the same problem of an invalid PDF. Again – all printed out fine when printing to a TIFF.
In case number one, the error was resolved by trial and error. Once the offending graphic was identified, it was redrawn and all was fixed. In the case with my current mapbook, it wasn’t that easy. I found the offending layer (it was more than one map), but even after redrawing the graphics, nothing was fixed. It wasn’t until I started playing with the symbology that I finally found the problem. Basically, I was using a dashed line style. When the dashes had a flat cap,
I was getting the error. As soon as I changed the cap to triangle,
the error went away. How’s that for debugging! Believe me, that took some time to figure out!
- There are a few bugs in both GeoMedia Pro 5.2 and 6.0 that prevent you from reliably scheduling the utility to run at night. I say reliably because I’ve heard that some people have had success. In fact, when Intergraph tested my issue, they reported it working fine for them. The basic problem I’ve encountered is that when you set the printer with the default settings (in printing preferences) like a landscape layout, 24×36 size sheet of paper, best output, etc.; the page will still print portrait. Now, this is NOT a problem when printing manually – ONLY when using the task scheduler. I have filed a worksheet against this problem and I’m told it will be resolved before GeoMedia Pro 6.1 is released.
- When a column that is being used for variable text string substitution is empty (null), the variable (the column name enclosed in brackets) will print instead of nothing. In other words, if I wanted the name of a zone to print when the map fell in a zone, I would use the variable [zone_name]. Now, if that zone_name column were populated (not null), I’d get the respective zone name. However if the zone_name column is null, then the utility is giving me back the variable "[zone_name]" where it should really be null. I’ve filed this worksheet and believe this bug should also be fixed before the release of 6.1.
Tomorrow I’ll get into creating PDFs from the batch plotting utility.
3 Responses to “Batch Plotting – Part 2”
Sorry, the comment form is closed at this time.