GIS Data Organisation for Non-Computer Experts Abdulla Gareeb and Steven Byrne, Town Planning Department, Al-Ain, UAE. | Abstract Of The Paper & The Profile of The Speaker | Speaker Index | Paper Title Index | In the Qatar conference of 1993, four years ago, my colleague, Mr Tarig Al Jabry presented a brief overview of the decisions leading to and the current state of the municipal GIS implementation within the Al Ain Town Planning Department (AATPD) of the Abu Dhahi Emirate of the United Arab Emirates. That was four years ago. Those involved in that implementation are now a little grayer and a lot wiser! Some of the problems encountered by AATPD will be the same for other Govemment offices in the Gulf region. A simple example is the case of manpower resources. In the current economic climate, new Government posts are difficult to create and often hard to fill with suitably skilled staff especially when competing with the private sector. It is common for Government clerical and technical drafting duties to be carried out by expatriate workers who may not he the highest paid or the best motivated. Typically there is not a clear career development path for non-nationals due to training restrictions and administrative difficulties in rewarding effort and motivation. For the AATPD Computerized Data Management System (CDMS) implementation, the usual implementation strategies were not going to work and a different motivational strategy was required. We needed to take some of the pain out of the CDMS GIS implementation! As we progressed through the implementation, several guiding principles emerged which best summarised what we were trying to achieve, these are Engineers are engineers not computer gurus The operating system is a GIS tool, use it! Information thrives in daylight but mutates in the dark The network is the REAL computer In this paper I would like to explain in a little more detail, how the first three of the above were applied in AATPD. ENGINEERS ARE ENGINEERS NOT COMPUTER GURUS .... Basically the decision we faced was whether to develop a large GIS support section which would provide engineering application support as well as computer application support or to have the users section provide the engineering application support and the GIS support section provide the computer application support. To make the statement Engineers should not be computer gurus seems such a simple thing but it is so fundamental to key implementation issues such as organisation structure training support & technical information exchange application workflow development establishing & maintaining standards For us the choice was simple, we are a Town Planning Department, the direct income we generate is insignificant compared to our operating costs. We have to keep our overhead costs down. We cannot support a large Information Technology support staff therefore we have to maximize the potential of our existing staff. I know this seems contradictory, on the one hand, reduce the user technical expertise requirement to a minimum, and at the same time maintain a small computer support team. To achieve these objectives, we introduced a "CORE GROUP" (or coordinator) system. Typically we identify and develop one of the CDMS Engineers in each section to be the prime point of contact for technical exchange between that section and the CDMS team. This person is developed into the core group member for that section. This means that the CDMS team does not require its own Architects, Surveyors, Utility Engineers or Civil Engineers but remains a small specialised team. For training, a distinction is made between formal courses and familiarisation or on-the-job training. Typically all formal courses are conducted in our offices, and attended by the relevant core group members and CDMS team members. For familiarisation or on-the-job training, the distinction is, The CDMS team provides CDMS familiarisation training on the data, standards, procedures and resources provided by CDMS. The core group members provides the on-the-job training on how the section utilises and incorporates the CDMS information into their section's workflow. For support issues and information exchange, the core group members provide the "front- line" support to the section. They also provide the technical interface between the CDMS support team and the section for data requirements, technical resource requirements, application development and bug reporting. Similarly, all CDMS documentation, updates, system notices, advance maintenance notices etc. are channeled through the CDMS team to the core group members. Application workflow development or application computerisation is undertaken as a joint activity between the CDMS team and the section. Either by forming a project team or by prototyping. A project team will usually be formed using resources from several sections, The use of the core group member system ensures that the CDMS team remains small in numbers, and maximises the use of existing manpower resources. However it is only in combination with good data organisation practices and support that the section Engineers can achieve their work objectives. The policy objective is to enable CDMS users to focus on the use of the CDMS data as a tool rather than the mechanism of the tool. THE OPERATING SYSTEM IS A GIS TOOL, USE IT! For CDMS we try to build flexibility into the most accessible level of technology. This affords us a measure of Vendor independence as well as providing cost and efficiency benefits. It also helps the user by empowerment. The most important example of this for AATPD is the file organisation or "TILING". AATPD is a mapping-based GIS user with a historic hardcopy dependency. This dependency includes the requirement for compiled map sheets at differing scales. One of the objectives of implementing GIS was to have a single source of updating with other scales derived from the updated source. The approach taken to achieve these objectives was to develop a tile naming system that is easily converted at operating system level, to the tile lower left co-ordinate without the assistance of a higher level gazetteer. The power of this approach is the ability to easily convert between UTM co ordinates and map name. This exploits the scripting capabilities of the operating system to makes more efficient use of our resources. For tile naming it was important to us that the same system supported a wide range of resolutions from 2M x lM for the land ownership and plot addressing centroids through to 100KM x 500Km for the administrative area covered by Al Ain municipality. The derived mapping requirement is a good example. During the day, updates are made to the most accurate source. In the case of the base information this is a 1KM x 1 KM tile. In the case of planning updates, this would be a 5KM x 5KM tile. In the case of electric, water, storm, sewer, irrigation and telephone it is tile independent. Overnight, every night, all updates are compiled automatically by batch jobs taking advantage of the tile naming system to provide updated derived mapping. This means our users can use whatever scale suits their work and still have the advantage of single source updating (refer to diagrams "CDMS Data Types"). A similar process is used with our automated plotting system. A concern was the amount of human and equipment resources being used to generate customised plots. By studying user needs, it was clear that a large percentage of the plotting requests could be resolved by four mapping scales, 1/1000 .. for detailed works 1/2000 .. for planning and conceptual work 1/5000 .. for reconnaissance and conceptual work 1/50,000. for overview, network analysis and administrative boundaries A series of operating system scripts automatically determines which adjoining maps or extractions are required to make a composite plot. Using look-up tables, the script determines the physical location of the CDMS data directories on the network and calculates the sheet index details. The whole process is menu driven so there is no requirement for a highly trained operator or expensive workstation and the information is completely up-to-date to the previous days working copy updates. In the case of utilities where the updates are tile independent, the preference is still for operating system mechanisms. For example, for the Utility section, when a utility route approval request is received by the Utility section (preferably digitally but not always unfortunately) and loaded on the system, the request is given a file name derived from the date, a sequential count and with the extension req. Overnight all files with the .req extension are compiled by the operating system into a single 10KM x 10KM graphics file called the request super file using the CDMS tile naming system (refer to chart "Utility Approvals Workflow"). As part of the utility approval workflow, a utility engineer will create a drawing referencing the route approval request with the request super file (so he can see all other requests), the approvals super file (so he can check what has previously been approved) and the base, plan, land with any other area of interest from the CDMS public directories. If the request is approved then the request filename extension is simply changed from req. to app. Overnight the request super file is automatically rebuilt and that new approval will no longer be compiled into the request super file but into the approvals super file along with all other files with the extension app. A similar event "moves" the information to the as-built super file. These simple examples of operating system level processes significantly help reduce complex tasks to simple procedures. INFORMATION NEEDS THE LIGHT OF DAY, IN THE DARK IT MUTATES. When you have worked hard, struggling to get a single source data compilation from often diverse and contradictory sources at your organisation's cost ... then the last thing you want to do is just give it away. But that is what has to done to ensure the good health of your information! If we don't ensure the quality, accuracy and currency of the information and share that information then other agencies will create their own sources of the information. This in itself is not a bad thing, as long as the data integration issues can be resolved. Ideally, each organisation should be responsible for the maintaining and updating of their own information with a part of that information being made available as a "read-only" copy for other interested agencies. Of course, each agency wants to protect their investment in collecting this information and control how and by whom the information is used. In Al Ain we are trying to introduce the concept of "INFORMATION BANKING" to other Government departments and infrastructure development agencies. In short we will maintain their data on our server, network and systems to help support their users during the start-up phase. We ensure that they retain full ownership, control and access to their information as well as access to our public external information The only condition is that they establish, maintain and update public external directories for their information that are needed to satisfy the AATPD workflow and the digital information requirements of the other Government agencies. A similar approach is taken to private agencies engaged on Government projects. We want consultants and contractors to use the most accurate, most up-to-date and best quality information available in their designs and implementations. We prefer agencies to adopt digital workflows so we offer consultants and some contractors free copies of our digital data for their project areas. This is on the condition that they enter a license agreement with us and provide us in return digital copies of any final designs, updates or as-built information in a compatible format to our system. Even for those consultants and contractors who do not use digital systems we still want to give them access to our information to improve the q.uality of their work. Through our Map Library we offer a range of mapping scales 1/1000, 1/2000, 1/5000 for all our working and archive copy datasets as well as selected special plots at 1/50,000 for political and administrative information. The maps are created on-line at time of request to the content requirement of the user (refer to Table 1.0 "PLOT_OP Screen Menu"). The charge is small and on a per sheet basis irrespective of the number of map composites or content required to create the sheet as the intent is to cover overheads only. One of the great advantages of being open with information is the feedback we receive. Very quickly if information is missing or incorrect we learn about it. Similarly, by encouraging digital exchange we have the benefit of updating the currency of our data without the high overhead of collecting the information ourselves. However we do have to do quality control on the data before deciding whether to integrate it into our working copy updated tiles, or to maintain it in a lower accuracy planning overlay. The final point on this issue is the subject of single source updating. One major hurdle we had to overcome and are still struggling to overcome is the "hidden" data or "copies". Internally within AATPD we have established a security model based on the concepts of Public / Private directories and working copy / archive copy datasets. We use the public directory structure to ensure there is a common single source of information and that single source is only updated by the data owner. This means that an update is only made once and all information derived from that source are automatically updated. I'ublic directories are of two forms, Public Internal and Public External. Public Internal directories are internal only to the members of a section, named sections or a project team. Public External directories are shared between sections. Public External directories can be either Archive which means that they have been q.uality controlled and any updating halted at some time in the past, or Working Copy which means they are in a process of continuous update. For the above I have used the term "sections" loosely as it includes not only those sections directly under TPD management but also sections from the Al Ain Municipality who are currently sharing the data. We actively encourage other Government users to adopt digital mapping technologies as it is our belief that each agency should maintain and update their own public/private directories. In conclusion, I hope I have given you some food for thought on some of the above issues. AATPD definitely do not have all the answers and we are still very much on the learning curve but we have enjoyed some small gains from the points raised in this paper. It is my strong personal belief that this region has a unique opportunity to fully realize the potential of GIS benefits. Of course there are also unique problems to be addressed as well as the usual set of problems associated with enterprise GIS implementations. But these problems are not insurmountable. The "guiding principles" outlined in this paper will not be suitable to everyone but do highlight some of the key issues that have to be addressed during the GIS project life-cycle. | Abstract Of The Paper & The Profile of The Speaker | Speaker Index | Paper Title Index | CGIS HOME PAGE CONTENTS