Welcomes back to the second and final part of Nathan Heazelwoods:
'GIS vs IT. The ultimate battle?'
This post contains the next 5 insights and tips for building productive relationships between IT and GIS teams - (first post here).
Back over to Nathan.
(6) GIS data is generally at least slightly out-of-date, and often data that is years out of date is still useful
• Aerial photographs begin to go out of date as soon as they are taken. If there are subsequent changes on the ground then these will not be visible. • Other GIS data, particularly base data, often has a lag following activities occurring ‘in the real world’- for example if land parcel data is only being reloaded into a system every 3 months then even when first loaded parts of the data may be at least 3 months out of date. • Ensure users understand timeliness issues • For most purposes slight time-lags are not critical, however if for a certain activity does require absolutely current information then consider more frequent data updates, or use of web-services for getting the authoritative source of data. Also 'real time' use of location aware transponders and sensors is becoming more common within GIS.
(7) Desktop GIS is more akin to Excel than an ERP
• Some organisations expect ‘all activities’ to follow defined processes • Some organisations want all processes to be documented before implementing GIS. • GIS desktop software (at least) can be used to either carry out repetitive tasks or to carry out ad-hoc tasks that are difficult to define beforehand- this conflicts with some organisations expectations • Ensure that users understand that GIS has many functions that can be used in a wide variety of ways- and that not all processes can be planned in advance • Ensure that users are adequately trained • Determine which processes (if any) can be pre-defined, and consider whether these can be scripted or automated using Model Builder or Workflow Manager GIS modules or similar. • Explain to management and IT that GIS is often more of an enabling tool or decision support tool like Excel rather than a defined process tool. Some decision makers want the processes and data models etc to all be defined before approving business cases, however did they require all of the processes and data that will be used for using Excel to be detailed before they approved the business case for implementing Microsoft Office?
(8) Modularity and Scalability
• Products such as the Esri suite (and 3rd party add-ons) are very scalable and modular. Many organisations get started with a single Desktop licence running on a single PC, but then extending this in a wide variety of ways to servers and services, web interfaces, mobile and the cloud etc, once the fundamentals are established with the most basic 'core' software. Taking this approach reduces initial expenditure and risks. Some other types of software require larger up-front commitments for many core components and multiple user licences. • Unfortunately some organisations that are not familiar with GIS want to plan long term and can fall victim to 'paralysis by analysis' spending a lot of time and effort on trying to work out their mid-long term requirements (when they don't even understand the capabilities of GIS) rather than for starting small (and cheap), learning more in small steps and adding capabilities (and costs) incrementally.
(9) GIS Data is BIG
• Imagery and large vector datasets can be different to what is typical in text based databases etc • With geoprocessing, cache preparation or transferring base data the timeframes can be greater than is typical with many systems • Ensure IT departments are aware of the filesizes that can be expected • Ensure users understand that processing large datasets can take a long time (I have often run processes that I have kicked off when leaving the office on a Friday and they still haven't completed on Monday morning- this is quite normal for GIS). • Consider couriering large datasets on hard-drives rather than attempting to transfer via email/http or FTP.
(10) Map displays and cartography are part science, part art and partly a compromise
• Different people have different opinions of art, and different opinions of what looks good as a map or GUI interface. • Maps and map displays often cannot display all information at all scales and may require layer ordering, cartographic abstraction and label prioritisation etc- some users make bad decisions with designing these features • Some users are confused when certain data is not displayed, for example because of scale dependency or because of display prioritisation. • Encourage users to design their own cartography/symbolisation • Explain scale dependency and cartographic abstraction/display priorities to users.