13 replies to this topic

[klawrence]

I have been managing a GIS group at an engineering firm, and now have recently been asked to manage some technical illustrators in our office as well. We have had issues with some maps being made in GIS and some in illustrator, specifically with consistency and accuracy. Now that I am overseeing all staff that could potentially make maps, I'm thinking of ways in which we can do this more efficiently and consistently. I understand there are some benefits to working in illustrator in terms of graphic capabilities, but there are limitations when working with large files. I do have some experience working with MAPublisher, which might be an option. Good file management is of course absolutely necessary. I'm wondering what experience others may have in determining map making workflows which might include using multiple applications and people with different skill sets. I understand this could also vary based on each job. I'd love to hear any thoughts!

[Gretchen Peterson]

If there are problems with consistency and accuracy, I'd start by enumerating those problems. If the technical illustrators are making things look nice but forgetting to update their data with the latest or if they are shirking the qa/qc part of the job then perhaps something akin to "pair programming" might work where you have one technical illustrator working next to one GISer on the same project. I'm guessing most of the problems stem from lack of communication between the two groups.

One thing you need to remember throughout, however, is that the tool isn't nearly as important as the end product. So set goals for the finished products in terms of accuracy and quality and let the workers choose the tools that will get them there. If the GISers need training in graphic software then provide it (this will at least allow them to know what can be done) and if the designers need training in GIS workflow then provide it to them so they understand how often data are updated, issues with accuracy, etc.

[David Medeiros]

With the right hardware Illustrator should be able to handle some very large, complex map files. So that shouldn't be too much of a concern. More important is that fact that Illy sometimes doesn't like vector files straight from a GIS or CAD environment. I have had issues in the past with smallish PDF or AI conversions from Arc or AutoCAD acting very slow in Illy. My preference for this workflow is to use MAPublisher and export .shp files to the graphic work space for final production. The advantage with MAPub being that data updates on the map end can be easily brought back into the GIS warehouse.

My approach to combining both types of map creation would be to set a production hierarchy. All work starts from the same base GIS data, and is processed as needed via Arc. If the project calls for advanced map design or production send that information to Illustrator via MAPub after all data changes have been. Any changes to the mapped dataset made in Illustrator that effect the base data should be meticulously recorded and immediately sent back to the original data set if needed. But hopefully will be able to avoid this by doing only graphic work in Illy.

If the job does not require Illustrator go straight to map layout in Arc but bring your other illustrators on board to help keep design, styles and symbology consistent.

I want to add as a note to Gretchen's comments on consistency and accuracy (which seem to lean a little towards the illustrators as the culprits). After 10 years as a purely digital cartographer and 3 as a GIS tech, it has been my experience with little to no exception that the cartographers I haver worked with took consistency and accuracy far more seriously than most GIS professional I have met or worked with did. This is my experience and your mileage may vary as they say, but be wary of assuming that because a GIS users work is tied to "data" that it is being treated appropriately or that the digital data is necessarily more accurate than analog methods of map compilation and production.

[cartdeco]

I'd agree with all the above comments, which is pretty much how we do things. Only exception would be that to maintain data consistency, work with geodatabases rather than shapefiles. MAPublisher handles these with ease now, and if you are working with ArcGIS and ArcSDE to maintain and manipulate data, then MAPublisher's Spatial Database function talks directly to ArcSDE to import data.

The benefit of this approach over working with shapefiles, is that upon exporting shapefiles filenames and feature class names get truncated and won't match your master database.

Good luck.

Craig

[David Medeiros]

I'd agree with all the above comments, which is pretty much how we do things. Only exception would be that to maintain data consistency, work with geodatabases rather than shapefiles. MAPublisher handles these with ease now, and if you are working with ArcGIS and ArcSDE to maintain and manipulate data, then MAPublisher's Spatial Database function talks directly to ArcSDE to import data.

Yes, but only if you are on a PC, no Mac support for GDBs at the moment (I'm on a Mac so I keep forgetting about this feature).

[Hans van der Maarel]

I'd agree with all the above comments, which is pretty much how we do things. Only exception would be that to maintain data consistency, work with geodatabases rather than shapefiles. MAPublisher handles these with ease now, and if you are working with ArcGIS and ArcSDE to maintain and manipulate data, then MAPublisher's Spatial Database function talks directly to ArcSDE to import data.

Yes, but only if you are on a PC, no Mac support for GDBs at the moment (I'm on a Mac so I keep forgetting about this feature).

Actually... The upcoming MAPublisher 8.4 release ("real soon now") will offer Personal Geodatabase support on Mac.

[David Medeiros]

I'd agree with all the above comments, which is pretty much how we do things. Only exception would be that to maintain data consistency, work with geodatabases rather than shapefiles. MAPublisher handles these with ease now, and if you are working with ArcGIS and ArcSDE to maintain and manipulate data, then MAPublisher's Spatial Database function talks directly to ArcSDE to import data.

Yes, but only if you are on a PC, no Mac support for GDBs at the moment (I'm on a Mac so I keep forgetting about this feature).

Actually... The upcoming MAPublisher 8.4 release ("real soon now") will offer Personal Geodatabase support on Mac.

Yay!! I've been hoping for this.

Is my reading of the Avenza info on this correct though, that you also need to have ArcGIS installed on the same machine for this to work? MAPub does not have the standalone ability to read the geodatabase like it does a shape-file?

[Hans van der Maarel]

Is my reading of the Avenza info on this correct though, that you also need to have ArcGIS installed on the same machine for this to work? MAPub does not have the standalone ability to read the geodatabase like it does a shape-file?

Not on the Mac version obviously As far as I know it's still a requirement on the Windows version, but note my use of bold text there, you'd better check with Avenza for a definitive answer.

[Dennis McClendon]

To amplify (or perhaps pervert) David's comments, there can be a tendency on the GIS side to say "if it's in the dataset, it must be right." Or, almost as bad, "it doesn't look right, but I don't have the authority to change the dataset." On the illustration side, you have the eternal problem of human fallibility, but there's the offsetting value of having a human say "that doesn't look right. I better check."

[Hans van der Maarel]

"if it's in the dataset, it must be right."

Data quality and reliability is a vital thing (and a subject I keep getting more opiniated about), especially in emergency cases. To illustrate this point: you may have heard something about a chemical fire in Moerdijk, The Netherlands, well... that's a few miles from here. In fact, my dad is working right across the street from that blaze. Fortunately for him and me, the wind was blowing in the right direction.

Our local ESRI office kindly put a map online showing the location of the fire and the direction the smoke was drifting. But they geocoded the address of the company going up in flames, rather than manually placing the marker on the correct spot.

[François Goulet]

To amplify (or perhaps pervert) David's comments, there can be a tendency on the GIS side to say "if it's in the dataset, it must be right." Or, almost as bad, "it doesn't look right, but I don't have the authority to change the dataset." On the illustration side, you have the eternal problem of human fallibility, but there's the offsetting value of having a human say "that doesn't look right. I better check."

That's so true (in my experience)... although, in the illustrator side, they had the tendency to say "it doesn't look right... I'm gonna change that" (even though it was right).

Now I work on both side so when it looks wrong in Illustrator, I go back checking myself is GIS... So each side should ideally have an idea of what the job of the other is...

[oldtoby]

Our local ESRI office kindly put a map online showing the location of the fire and the direction the smoke was drifting. But they geocoded the address of the company going up in flames, rather than manually placing the marker on the correct spot.

One thing to watch out for when using Google Maps/Earth.... they do the same thing. I was looking for a Fire station yesterday, using the address off the fire station put the point right in the middle of a highway cloverleaf interchange.

[David Medeiros]

Our local ESRI office kindly put a map online showing the location of the fire and the direction the smoke was drifting. But they geocoded the address of the company going up in flames, rather than manually placing the marker on the correct spot.

One thing to watch out for when using Google Maps/Earth.... they do the same thing. I was looking for a Fire station yesterday, using the address off the fire station put the point right in the middle of a highway cloverleaf interchange.

Yeah, pretty much every online map and direction service uses geocoding. For systems that cover entire nations or the globe itself and must find user input addresses, it's relatively expedient and typically accurate to at least the correct block in most cases. But to use geocoding when you are mapping specific known points for a one off map as Hans described is just silly (or lazy I guess).

[Gert-Jan van der Weijden]

Is my reading of the Avenza info on this correct though, that you also need to have ArcGIS installed on the same machine for this to work? MAPub does not have the standalone ability to read the geodatabase like it does a shape-file?

Not on the Mac version obviously As far as I know it's still a requirement on the Windows version, but note my use of bold text there, you'd better check with Avenza for a definitive answer.

I can imagine that mapub8.4/mac will contain support for personal geodatabases. These databases are msaccess-based, so easily portable to the mac platform.
Support for Esri file geodatabases (fgdb) in mappub/mac however is unlikely: the Open API is still to be released by Esri (should be any moment, but already announced for 2 years or so). According to the latest Esri announcements this first API release will be Windows-only. mappub8.4/win will support arcgis10 fgdbs
http://www.avenza.co...ility-arcgis-10

Support for enterprise geodatabases (arcsde-based) relies on the arcgis binaries, thus windows-only I guess. Instead of arcgis an (free) arcreader installation is sufficient for these binaries