STORAGE OF UNDERGROUND UTILITIES DATA IN THREE-DIMENSIONAL GEOINFORMATION SYSTEM SHRANJEVANJE PODATKOV O PODZEMNI INFRASTRUKTURI V TRIRAZSEŽNOSTNEM GEOINFORMACIJSKEM SISTEMU Kestutis Cypas, Eimuntas Parseliunas, Ceslovas Aksamitauskas UDK: 528.92 ABSTRACT The article presents a research on data of underground utilities like electrical power distribution grid, water, gas, heating distribution systems, sewer, and telecommunication systems storage in three-dimensional geoinformation system for municipality purposes. Besides topography, municipalities store underground and aboveground utilities data collected by surveyors. Collected geodata are treated as legal data and they are used for urban planning, designing purposes and permissions issue for constructing or reconstructing purposes. It is shown, how the existing data could be transferred to the 3rd dimension. An algorithm has been created for calculation of the heights of underground utilities. Requirements for data capture in three-dimensional geoinformation system are discussed and presented. KEY WORDS underground utility, 3D geoinformation system Klasifikacija prispevka po COBISS-u: 1.04 IZVLEČEK V članku je predstavljena raziskava o shranjevanju podatkov podzemne infrastrukture v trirazsežnostnem geoinformacijskem sistemu, ki vključuje podatke o električnih vodih, vodovodnem, plinovodnem, toplovodnem sistemu, kanalizacijskih vodih in telekomunikacijskih sistemih. Poleg topografskih podatkov geodeti za potrebe občin zbirajo tudi podatke o podzemni in nadzemni infrastrukturi. Zbrani geopodatki so zavezujoči pri prostorskem planiranju, načrtovanju in izdaji dovoljenj za gradnjo ali obnovo. V prispevku je prikazano, kako lahko obstoječe podatke prenesemo v tretjo razsežnost. Za izračun višin podzemne infrastrukture smo razvili poseben algoritem. Obravnavane in predstavljene so tudi zahteve za zajem podatkov v triraszežnostnem geoinformacijskem sistemu. KLJUČNE BESEDE podzemna infrastruktura, trirazsežnostni geoinformacijski sistem 1 INTRODUCTION There is a constantly growing need for precise underground utilities data for design, construction or reconstruction purposes in urban areas. Utilities map data have been stored in analogous large-scale (1 : 500) plane-tables for a long time. During last few years municipalities began to collect data digitally and to store utilities data in geoinformation systems. The main data sources for geoinformation systems are vectorised old large-scale maps at a scale 1:500, stereodigitized aerial photos and new surveying data. Those methods have been applied for above ground (surface) 481 82 objects, while underground data have been vectorised from old large-scale maps mainly. Utilities data have been collected and stored in 2 or 2.5 dimensions mainly, with height data points in certain places. Using modern technologies it is possible to collect position and height information for utilities quite easily. By applying the 3rd dimension it is possible to store all utilities distribution grids with heights for each vertex (with z-values). Planners and designers could benefit from more precise information while planning and designing new constructions or reconstructions. One of the advantages is the possibility to calculate real length (not projection of lines) of networks by estimating slopes in geoinformation systems. For example, the Vilnius municipality underground utilities data have been transferred to the 3rd dimension by calculating the missing heights. An algorithm has been created for heights calculation using interpolation. For experiment purposes a module operating in ArcGISTM 9.0 environment has been created using Visual BasicTM programming language. A three-dimensional data model for storage of underground utilities data in municipality geoinformation system has been designed and created using UML CASE tools. 2 UNDERGROUND UTILITIES DATA IN THREE-DIMENSIONAL GEOINFORMATION SYSTEM MODEL Today, utility heights are stored in a separate data layer as points attributes mainly. Usually height points are not connected topologically with utility lines or related in another way. If every vertex of object were supplemented with the z value, object dimension would be extended to the simple 3rd dimension. During transformation to the 3D space objects could be presented by different geometrical primitives, f.ex.: if an object like pole in 2D space is represented as point, in 3D space pole would be represented as perpendicular to the ground surface line. In some cases geometrical primitives representing real objects would not change, f.ex.: top of manhole in 3D space still would be represented as a point. There is only new z parameter, which tells about location of an object not only in plane but also in vertical attitude. Line objects would be still lines, but every vertex would get its own height. In such case the height would be always associated with a utility line (Pubellier, 2003). Polygons would keep the same geometry in some cases, but in most cases it would be transformed to volumetric (body) object. Volumetric objects would consist of surfaces that limit a body. In 3D spaces objects would have one z value (a top of manhole), or a set of values in perpendicular attitude (a pole), or set of values in horizontal position (pipe lines with z values for each vertex). Moving to the 3rd dimension it is important to identify, how real objects would be treated in the new dimension. Each real object group would be treated differently with a unique geometrical representation (Stoter et al., 2003). Common transformation cases of underground utilities are presented in Table 1 (Cypas, 2005). Geometric element in 2D space Geometric element in 3D space Explanation Utility point (x,y) Point (x,y,z) Objects that could be considered without height f.ex.: manhole tops, valves Perpendicular line (two z’s for one x,y coordinate pair: x1,y1,z1...x1,y1,z2) Objects that could be considered with height, f.ex.: grounding bore Utility line (x1,y1...xn,yn) Line (x1,y,z1..xn,yn,zn) Objects that have length and could be considered with length parameter, f.ex.: cables, pipes, conduits Utility polygon (x1,y1...xn,yn, x1 ,y1) Polygon (x1,y,z1,...xn,yn,zn, x1,y,z1) Flat closed objects Simple volume (body) (x1,y,z1,z1h...xn,yn,zn,znh, x1,y,z1,z1h) Objects that have length, width, height and could be considered as volumetric object, f.ex.: underground reservoirs Table 1. Transformation cases for geometrical primitives of underground utilities. The design of three-dimensional underground utilities geoinformational data model has been performed according to large-scale geoobjects specification of geoinformational system of the Vilnius municipality, according to requirements set further and information flow analysis. Themes of underground utilities geoobjects stored in the Vilnius municipality geoinformation system are presented in Table 2 (Stankevicius, 2000). No Utility theme Objects in theme 1. Electrical power distribution grid Transmission lines, poles, transformers, switches, fuses, substations, streetlights 2. Water distribution grid Water pipes, valves, hydrants, service lines 3. Gas distribution grid Gas pipe segments, valves, service taps, service lines, cathodic protection devices 4. Oil network Oil pipe segments, reservoirs, pump stations 5. Heating distribution grid Heating lines, reservoirs, valves 6. Sewer system Sewer pipe segments, manholes, valves, service taps, lateral lines 7. Telecommunication system Telecommunication cables, conductors, switching centers, poles, service lines Table 2. Utility layers in the Vilnius municipality geoinformation system. Data model has been designed using the UML and CASE tools and created using ArcInfoTM software. Geodatabase has been loaded to central database storage ArcSDETM dedicated to geographical data central storage, which ensures multi-user data handling environment. ArcSDETM 483 84 lets to store geodata in popular commercial relational database management systems like ORACLETM, Microsoft SQL ServerTM, IBM DB2, so a data model is independent. The created data model might be transferred using XML for both data and structure. Municipality subdivision is responsible for cartographic data storage and for update of large-scale maps. According to existing regulations, the surveying company has to apply for data extraction from municipality central database for a particular territory. After the field survey, the surveying company updates the data and delivers them to the municipality cartographic subdivision. Using the designed model, the data can be easily extracted from the central database and transferred to the surveying company. Then the surveying company can use data in the delivered structure or it can export the data to their CAD software format. After surveying the data can be updated using the same data structure and delivered to municipality cartographic division. The municipality subdivision is responsible for loading new or updated data to the central database. All changed objects would be deleted and new objects would be imported to the central database within the same data model. A standardized data model would serve as infrastructure for data export, update and import procedures and would warrant data objects conformity with specification. When a required data structure is known, it is possible to check data consistency in a more automated way. The following geometrical primitives have been used in the data model: PointZ, PolylineZ, PoligonZ, MultiPatch. These types (except MultiPatch) are standard well-known primitive types extended with additional z values. The MultiPatch data type lets to store volumetric objects, but for data load special procedures using ArcGISTM components called ArcObjectsTM should be used (Ford, 2004). An alternative for data load is to use specialized software for 3D modeling with interfaces for data load to GIS software. 3 CREATION OF THREE-DIMENSIONAL GEOINFORMATIONAL SYSTEM MODEL An experiment has been performed for transferring of utilities surveying measurements to three-dimensional geoinformational system model. The main idea of an experiment is to transfer measured height values to vertexes data of corresponding utility lines. The overall algorithm is presented in Figure 1. In the first block data layers are processed: SQL queries are applied if any. In the second block every line and every vertex of each line are analyzed and height for each vertex is being searched within 0.1 meter distance. Actually measured height point has to be on a line and a point has to be associated with a line (most common approach by using “snap”). The condition for closest distance is actually a closest allowable distance between vertexes. The closest distance between vertexes in primary data has been defined as 0.1 meter. A search for closest height is performed in step “Find a closest height within 0.1 m from vertex”. A search for a closest height is described in separate algorithm. A result of algorithm is only one closest height of a point within 0.1 m distance from vertex. The experiment was performed for a territory in Vilnius covered by 68 km2. The results of an experiment are presented in Table 3. No Utility theme Objects in theme 1. Electrical power distribution grid Transmission lines, poles, transformers, switches, fuses, substations, streetlights 2. Water distribution grid Water pipes, valves, hydrants, service lines 3. Gas distribution grid Gas pipe segments, valves, service taps, service lines, cathodic protection devices 4. Oil network Oil pipe segments, reservoirs, pump stations 5. Heating distribution grid Heating lines, reservoirs, valves 6. Sewer system Sewer pipe segments, manholes, valves, service taps, lateral lines 7. Telecommunication system Telecommunication cables, conductors, switching centers, poles, service lines Table 3. Results of heights calculation of utilities lines vertexes. k - number of objects, kv - number of vertexes per all objects, kHs - number of assigned (transferred) heights, kH - original number of heights, is -percentage of assigned heights per primary number of heights, i - percentage of assigned heights per all vertexes. Results after initial height transfer experiment were quite pure due to small number of measured heights of underground utilities. Only some of the measured heights were used for utility lines transformation to 3D lines. The lowest rate of transferred heights is detected for sewer system, electricity and telecommunications. There is no any requirement for collecting heights for electricity and telecommunication cables, but sewer system have to have heights because of slopes. A low rate of transferred heights for sewer system tells about lack of requirements for storing sewer network heights. A high rate is detected for heating and water distribution systems, it tells about precise location of heights points for those systems, but still the low rate of heights per vertexes (2.2%-3.1%) tells about lack of requirements for data storing. Gas distribution system has a rate over 100%, it means that the same height was given to more than one vertex. The reason could be a wrong smallest distance in data (0.1 m). Oil network has to be excluded from results as it was too less data for an experiment. In order to improve results interpolation procedures were developed and applied. Interpolation algorithm was supplemented to main algorithm as step “Interpolate heights of line vertexes” (Figure 2). Interpolation was performed for each line having vertexes with z = 0 values. Interpolation algorithm has those constraints: 1) interpolation cannot be performed if there is none or only one vertex with height, 2) interpolation cannot be performed if there are two adjacent vertexes with heights. Interpolation may be performed only for vertexes that are between vertexes with known heights. Results of interpolation are presented in Table 4. 485 486 Start i. [ 1. Read altitude point data layer, attribute field "Height". J C No V Is there any SQL query? Yes Apply SQL query and get geoobjects : | 2. Read underground utility line data layer J Y No Is there any SQL query? Yes Apply SQL query and get geoobjects C i. Read first line j X Read the first vertex of a line K J Find closest height w ith in 0,1 m from vertex $ Is there any point with known height within 0,1m distance? . Yes Write height value to ve rte x ) Read next line Yes No Are all vertexes read? Yes Does a line have any vertex with z=0 value? No Yes Interpolate heights of line vertexes < 3 Are all lines read? End (?) Fig 1. Algorithm for calculation of vertexes heights. Start: Interpolate heights of vertexes C Take first vertex j JL Check z value Do all vertexes have z = 0 ? Yes > No No ^JWrite to memory Is there any next vertex ? Yes Is a value z = 0 of an height before? No -SH <- No Yes Interpolate - calculate height value proportional to distance Check the value of a next vertex height i Is a value of a next vertex z = 0 ? Is there any vertex left ? Yes Go to the last interpolated vertex Is there any vertex left ? No I End Yes No End If there is only one vertex with height z <> 0 or a couple of adjoining vertexes with height z <> 0, interpolation cannot be performed Take next vertex If all heights of vertexes are equal to 0, interpolation cannot be performed Fig 2. Algorithm for interpolation of vertexes heights. Utility theme kobjint kvint ipint (difference, A) Electrical power distribution grid 2 (0%) 45 0% (0%) Water distribution grid 200 (0.5%) 1644 4.1% (+1.0%) Gas distribution grid 1848 (6.3%) 5021 15.8% (+4.5%) Oil network 0 0 0.5% (+0.0%) Heating distribution grid 144 (0.6%) 1110 3.0% (+0.8%) Sewer system 1 (0.0%) 3 0.0% (+0.0%) Telecommunication system 2 (0.0%) 5 0.0% (+0.0%) Table 4. Results of interpolation of vertexes heights. k t - number of objects with interpolated vertexes, k - number of interpolated vertexes per objects with interpolated vertexes (k,), i - percentage of both vint objint pint transferred and interpolated heights per all vertexes. After interpolation number of vertexes with known heights increased narrowly (up till 4.5%). The main reason is too few objects suitable for interpolation, more heights have to be stored in database. Heights have to be measured in points where slope of underground utility changes. In 487 88 cases when slopes of underground utilities are known, interpolation accuracy improvement may be achieved by applying slope value. Reliable results by interpolation can be achieved between vertexes with a known slope. 4 REQUIREMENTS FOR UTILITIES DATA CAPTURE AND STORAGE IN THREE-DIMENSIONAL GEOINFORMATION SYSTEM MODEL Nowadays underground utilities are measured using electronic total stations in most cases. Using total station it is possible to measure both horizontal and vertical positions. In those cases measured heights can be stored as z values of vertexes. When moving to three-dimensional geoinformation system it is important to set rules for capture of objects with 3rd dimension. One of issues is standardization of objects’ coding as well (Stankevicius, et al., 2005). It is important to improve the underground and aboveground utilities objects coding in the three-dimensional geoinformation system. Strict data capturing rules can benefit for surveyors while working in a field and processing data later (Koistinen et al, 1999). According to technical requirements for underground utilities surveying requirements are as follows: 1) heights of all devices tops (covers, etc.) have to be collected and stored; 2) heights of pipes and conduits have to be collected and stored (incoming to manhole and outgoing from manhole, for sewerage, drainage - heights of conduit duct, for all other conduits - height of conduit top); 3) telephone cables: heights of conduit duct have to be collected and stored, if there is a beam of conduits - heights of both a top and a bottom of conduit have to be collected and stored; 4) heights have to be collected and stored at a distance not less than each 50 meters if there is a segment with a same slope. Existing technical requirements it is recommended to supplement with additional rules: 1) heights have to be measured for both incoming and outgoing underground cables in manhole; 2) heights have to be measured in turning points, connections for underground cables; 3) heights have to be measured at clear slope change points for underground cables; 4) heights have to be measured not less than each 50 meters in straight segments for underground cables. Generally it is recommended to measure heights in those points where there is requirement to measure position of underground cables. In these cases height would be related to a position of typical points. According to requirements stated above following requirements have been formulated for storing underground utilities data in three-dimensional geoinformation data model: 1. Collecting line geoobjects of underground utilities: a) line geometry has to be collected with heights of vertexes using polylineZ geometry type. An alternative could be capture of heights in a separate layer as points. Then a procedure of heights transferring to line vertexes could be performed; b) according to regulation of technical requirements for underground utilities surveying all tech-nical characteristics should be collected in attribute fields. Each type of underground utilities has it’s own code (gcode) and is stored in different data layers. For manifolds and pipelines a diameter and material have to be indicated. In addition a flow direction is indicated for sewerage lines (a recommendation to use azimuth, then a flow direction could be placed in a map automatically). Slope could be calculated automatically, if slope calculated by using other methods it could be entered manually. For gas pipes a pressure have be indicated, for electricity cables a voltage have to be indicated. If there are protective pipes, a diameter and material for those should be indicated as well. 2. Collecting point geoobjects of underground utilities: a) Point objects (manhole tops, valves, etc.) have to be collected with heights using pointZ geometry type. If heights of utilities have been measured separately, those are stored in sepa-rate layer for utilities heights and height is stored as attribute. Those heights will be trans-ferred to utility lines during heights transferring to line vertexes procedure. In that case points should be on lines - have to be topologically connected with lines (using snap mode); b) any technical characteristic of point object should be collected in attribute fields. Each type of underground point object has it’s own code (gcode). Manhole data is collected using field inventory cards. Following attribute information of manhole have to be stored: city name, street name, nomenclature of large-scale map (scale 1 : 500), type, diameter and material of manifold top, ground height, material of walls and bottom, number of incoming and outgoing pipes, diameter and type of each pipe, ladder type, quantity of stairs. Each inventory card has a name and surname of a man who performed inventory and date of inventory. Reading of top or bottom of pipe, conduit and depth is stored in layer of utility heights. Height could be calculated automatically according to distance to top of manifold. Other point objects are stored with a city name, street name, nomenclature of large-scale map and type as well. It should be possible to store scanned manifold inventory card. 3. Collecting volumetric geoobjects of underground utilities: a) volumetric geoobjects (reservoirs, etc.) have to be stored using MultiPatch geometry type. For data collecting a PolygonZ geometry data type could be used as temporary layer. In that case each vertex should have height of object bottom; b) any technical characteristic of volumetric geoobject has to be collected in attribute fields. Each type of underground volumetric object has it’s own code (gcode). As attribute a height of object could be stored as well. All objects should have information about data collecting method, accuracy and date (metadata). 5 CONCLUSIONS 1. Additional requirements for underground utilities geodata collecting in three-dimensional geoinformation model have been set. 2. According to additional requirements 3D data model has been designed using UML and CASE tools. 489 90 3. An algorithm for height data transferring to underground utilities lines has been created. For experiment a module operating in ArcGISTM environment has been developed. Initial data has been transformed to 3D space using an algorithm for height data transferring to underground utilities lines. The lowest rate of transferred heights is detected for sewer system, electricity and telecommunications. A low rate of transferred heights for sewer system tells about lack of requirements for storing sewer network heights. A high rate is detected for heating and water distribution systems, it tells about precise location of heights points for those systems, but still the low rate of heights per vertexes (2.2%-3.1%) tells about lack of requirements for data storing. Gas distribution system has a rate over 100%, it means that the same height was given to more than one vertex. The reason could be a wrong smallest dis-tance in data (0.1 m). Oil network has to be excluded from results as it was too less data for an experiment. 4. In order to improve results experimental interpolation procedures were created and applied. After interpolation number of vertexes with known heights increased narrowly (up till 4.5%). The main reason is too few objects suitable for interpolation; more heights have to be stored in database. Heights have to be measured in points where slope of underground utility changes. In cases when slopes of underground utilities are known, interpolation accuracy improve-ment may be achieved by applying slope value. Reliable results by interpolation can be achieved between vertexes with a known slope. References: Stankevicius, Z. (2000). Investigation of city geographic information system optimality. PhD dissertation, p. 1-164. Stoter, E., Ploeger, H. D. (2003). Property in 3D - registration of multiple use of space: current practice in Holland and the need for a 3D cadastre. Computers, Environment and Urban Systems, Vol.27, 2003, p. 553-570. Cypas, K. (2005). Construction peculiarities of topological 3D model for underground infrastructure. In Proceedings of 6th International Conference on Environmental Engineering, May 26-27, 2005, Vilnius, Vol. 2, p. 847-851. Ford, A. (2004). The visualisation of integrated 3D petroleum datasets in ArcGIS. In Proceedings of 24th ESRI user conference, 2004, San Diego, p. 1-11. Stankevicius, Z., Parseliunas, E. (2005). Standartisation of large scale geo-data sets. In Proceedings of 6th International Conference on Environmental Engineering, May 26-27, 2005, Vilnius, Vol. 2, p. 1008-1013. Koistinen, K., Latikka, J., Mononen, J., Pöntinen, P., and Haggrén, H. (1999). On the Development of 3D Documentation for Archaeology during Finnish Jabal Haroun Project. International Archives of Photogrammetry and Remote Sensing, Vol. XXXII, Part 5W11, Thessaloniki, Greece, p. 63-68. Pubellier, C A GIS for 3D Pipeline Management. In Proceedings of 23th ESRI user conference, 2003, San Diego, p. 1-11. National Service of Geodesy and Cartography (1999). Underground network and implementation procedure of geodesy communication survey, Regulation GKTR 2.01.01:1999, p. 1-14. National Service of Geodesy and Cartography (2000). Geodetic engineering investigations, Regulation GKTR 2.08.01:2000, p. 1-32. mag. Kestutis Cypas Vilnius Gediminas Technical University, Department of Geodesy and Cadastre, Sauletekio al. 11, LT-10223 Vilnius, Lithuania E-mail: kestutis.cypas@ap.vtu.lt, Assoc. prof. dr. Eimuntas Parseliunas Vilnius Gediminas Technical University, Department of Geodesy and Cadastre, Sauletekio al. 11, LT-10223 Vilnius, Lithuania E-mail: eimis@ap.vtu.lt Assoc. prof. dr. Ceslovas Aksamitauskas Vilnius Gediminas Technical University, Department of Geodesy and Cadastre, Sauletekio al. 11, LT-10223 Vilnius, Lithuania E-mail: gkk@ap.vtu.lt Prispelo v objavo: 10. 3. 2006 Sprejeto: 28. 8. 2006 491