GeoMedia GIS Blog

"A picture is only worth a thousand words. A map may be worth a thousand numbers. But a GIS is worth a thousand tables."

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:

  1. 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.
  2. 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!
  3. 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.
  4. 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.
  5. Tomorrow I’ll get into creating PDFs from the batch plotting utility.

Advertisements

3 Responses to “Batch Plotting – Part 2”

  1. Phil Hughes said

    Jeff

    great blog – I had the same problem with pdf printing. 364 sheets and 5 of them would not plot properly. This is in 6.0. How on earth did you find the problem ? I can’t find anything different in the sheets that are not plotting but at least there’s hope now of finding something.
    cheers
    Phil Hughes
    Mornington Peninsula Shire Council
    Victoria, Australia

  2. […] working in the past…more or less. HOWEVER, due to the bug mentioned in my previous post (Batch Plotting – Part 2) concerning the landscape vs. portrait issue, I have not been able to test the overall procedure. […]

  3. Jeff Hobbs said

    Phil – thanks for the kind words! It was just trial by error. I started removing layers and seeing which ones caused the error. Once I had figured that out, I started looking at the geometry more closely. I redrew the geometry for one plot shape and that didn’t fix the problem. I then started trying to reduce the number of vertices – still didn’t fix the problem. So instead I removed the symbology for the line and just used the default line color. This fixed the problem! So, I knew it was a problem with symbology…but what?? Then I started playing with the symbolgoy and…interesting enough, finally figured out that the caps were causing the problem.
    I’m going to be sending Intergraph my symbology and a couple of my data sets. They’ll see if they can reproduce the problem. If they can – perhaps they can figure out what’s causing it. Since TIFFs print fine, I’m not too sure it’s a problem on the Intergraph side. I’m wondering if it could be an issue with the PDF and the standard somewhere. It will be interesting to see what comes from Intergraph after they do some investigation.

Sorry, the comment form is closed at this time.

 
%d bloggers like this: