KARNATAKA GIS STANDARDS - KSRSAC...Karnataka- GIS Database Standard t which defines the design standards of KGIS database 7.3. Karnataka GIS Metadata Standard- defines Metadata information

KARNATAKA GIS STANDARDS VOLUME-I: Part- 2 Ver. 1.2

Karnataka State Remote Sensing Applications Center

KARNATAKA GIS STANDARDS

Volume-I: Part- 2: Database Design

KARNATAKA STATE REMOTE SENSING APPLICATIONS CENTRE

Dept. of Information Technology, Bio-Technology and Science & Technology Doora Samvedi Bhavana , Major Sandeep Unnikrishnan Road, Doddabettahalli, Bangalore- 560097. Ph No.: +91 80 29720557/58, Fax: +91 80 29720556

March, 2017



Contributors:

Mr. Raju Angadi

Mr. Thirthesh H. V

Ms. Shilpa R.

Mr. Rajshekar A. S.

Dr. Lingdevaru D C

Dr. Puspa Dash

Dr. Sujatha S D

Ms. Chaitra R

Mr. Anand A J

Mr. Rushya S

Ms. Priyanka Pereira

Version Controlled by:

Mr. Vilas H. Chavan

© Karnataka State Remote Sensing Applications Centre



Document Control Sheet

Document Number KSRSAC/K-GIS/STANDARDS/01/March-2017

Title KARNATAKA GIS STANDARDS VOLUME-I: Part- 2: Database Design

Type of Document Technical Report – Ver. 1.2

Number of pages KARNATAKA GIS STANDARDS Volume-I: Part- 2: Database Design – 17 Pages

Annexure – I – 121 Pages

Annexure – II – 56 Pages

Publisher Karnataka State Remote Sensing Application Centre

Prepared by K-GIS Technical Team

Reviewed by Mission Director, Chief Technical Officer & Technical Officer

Approved by K-GIS Technical Committee on

Abstract Karnataka State Remote Sensing Applications Centre is implementing

Karnataka- GIS which envisions maintaining a State-wide,

Standardized, seamless and most current GIS asset and providing GIS

based decision support services for governance, private enterprise

and citizen. In this connection Database schema design has been

created.

Distribution Unrestricted

Reproduction Rights This report and its contents are the property of KSRSAC



Contents

1. Background ............................................................................................................................................... 1

2. Karnataka GIS Standards ....................................................................................................................... 2

2.1 Elements of Karnataka GIS Standards ........................................................................................... 2

2.1.1 Karnataka GIS Content Standard .......................................................................................... 2

2.1.2 Karnataka GIS Database Standards ....................................................................................... 5

3. KGIS as Relational Database Management System (RDBMS) ............................................................... 6

3.1 KGIS DBMS Types .......................................................................................................................... 6

3.2 KGIS RDBMS .................................................................................................................................. 7

3.3 Data normalization........................................................................................................................ 7

4. KGIS Database Design ........................................................................................................................... 8

4.1 Conceptual Design of KGIS Database ............................................................................................ 8

4.2 Logical Design of KGIS Database ................................................................................................... 9

4.3 Relationships ................................................................................................................................. 9

4.4 Physical Design .............................................................................................................................. 9

5. KGIS Database Overview ..................................................................................................................... 10

6. Database Updatation Policy ................................................................................................................ 12

6.1 Possible Approach to Implementation ............................................................................................. 12

7. KGIS Database Structure ..................................................................................................................... 13

7.1 Metadata Database: ......................................................................................................................... 14

7.2 Spatial Database: .............................................................................................................................. 15

7.3 Attribute/MIS Database .................................................................................................................... 15

7.4 Portal Database ................................................................................................................................. 16

7.5 Application Database ........................................................................................................................ 16

8. Summary ............................................................................................................................................. 17

KARNATAKA GIS STANDARDS VOLUME-I: Part- 2 Ver. 1.2 Page 1 of 17


1. Background

1. Karnataka state government, realizing the importance and relevance of GIS and also to bridge

the existing gaps in GIS, approved the Karnataka-GIS programme. This is a new information

regime supporting GIS based decision support services for governance, private enterprise and

citizen and by maintaining a state-wide, standardized, seamless and most current GIS asset.

Karnataka State Remote Sensing and Application Center is implementing Karnataka- GIS.

2. Standards are necessary

2.1. To prevent proliferation of too many small systems that may be different and

incompatible with one another.

2.2. To avoid duplication of efforts in application development, because software developed

on one computer may not be portable to other.

2.3. To improve the ability to share and integrate the database and services. Adoption of

data standards will create favorable conditions for the development of interoperable or

open GIS and help in making data more accessible and available to user and facilitate

better use of GIS.

3. The first meeting was held on October, where presentation was given on the overview of the

standards. Technical Committee made following suggestion

3.1. KGIS standards can adapt from various standards. National GIS, NNRMS, NSDI, ISO, OGC

are good source of information. It is suggested to prepare KGIS document from referring

these standards.

3.2. Content definition must be exhaustive with details of the various layers, a brief technical

description, granularity or details of information content (scale could be used just for

common understanding/ reference purposes), owner / generating agency, update cycle,

etc. Those which are to be generated by KSRSAC using satellite images / surveys and

those which are ownership of various departments must be clearly brought out.

3.3 Database design & quality and metadata standards should have conformity to ISO

standards so that at a National level, the KGIS adopted standards would be compatible.

4. The KGIS standards are categorized into: de facto (industry standards), de jure (prescribed by

empowered body) and regulatory (by legislation). In developing the standards for KGIS, we have

taken note of the N-GIS and NNRMS Standards and cognizance of National Remote Sensing Data

Policy (2012) issued by ISRO and National Map User Policy (2010) issued by Survey of India.



2. Karnataka GIS Standards

5. Karnataka GIS implementation fundamentally require Karnataka GIS Standards – a suite of

technical standards and protocols for KGIS that will allow easy GIS Asset organization

/maintenance, GIS services of Data and Applications on a standards-based Karnataka GIS Portal

1. Based on the KGIS Vision document and Stakeholder consultation and User needs, in the

ensuring section, we propose a set of Karnataka GIS standards that address GIS content, GIS

database, quality standards and also some basic maintenance parameters.

2.1 Elements of Karnataka GIS Standards

2. KGIS has identified 5 different kinds of standards. Volume- I: Part - 1 contains KGIS Content,

Metadata and Quality standards. Volume- I: Part- 2 contains Content Schema & Volume – II

contains Data Service Standards.

7.1. Karnataka GIS Content Standard – includes categorized KGIS content.

7.2. Karnataka- GIS Database Standard – which defines the design standards of KGIS database

7.3. Karnataka GIS Metadata Standard- defines Metadata information generated.

7.4. Karnataka GIS Quality Standard – defines the quality parameters for KGIS content.

7.5. Karnataka GIS Data Services Standard – defines GIS Data services

2.1.1 Karnataka GIS Content Standard

3. Karnataka GIS has to be authoritative – thus, content is most important and core to the wide

usage of the KGIS across wide spectrum of users. The KGIS content (called Karnataka GIS Asset)

is proposed in a seamless manner to include:

3.1 State-wide GIS content at best possible content-detail as available (for easier

comprehension, it could be 1:50000 or 1:10000 scale). (KGIS agrees with the Karnataka GIS

Visio do u e t that i a digital GIS do ai , s ale is a is o e AND WHAT IS RELEVANT is information content or depth/granularity of GIS content; BUT one has to recognize that

scale is the most common form of reference made by GIS users). KGIS will have common

database pertaining to 1:10000 scale data, however data coarser and finer than this will

adhere to 1:10000 standards.



4. KGIS has consulted a range of users to determine their GIS data requirement and also what they

expect from Karnataka GIS

5. The features of KGIS Asset content could be categorized/grouped into following 15 categories –

categorization and groupings are important to stack similar/related datasets into particular

group and to un-clutter the content list:

i. Boundary – includes all the spatial boundary data.

ii. Cultural features – includes a variety of cultural features.

iii. Hydrology – includes all the features related to hydrology.

iv. Urban and Settlement – includes Habitation & settlements.

v. Industrial content – Industry related information.

vi. Forest Environment & Ecology – forest and environmental data.

vii. Geological– includes data related to geology and minerals.

viii. Land Information–includes LULC, wasteland and other land related information.

ix. Land ownership information – cadastral and Urban Property information.

x. Terrain information – has DEM, contour.

xi. Soil information – at Series level.

xii. Weather – Rainfall & temperature collection station

xiii. Public Assets/Amenities – all govt public assets and amenities.

xiv. Points Of Interest (POI) – details of points of interest.

xv. Graticules – contains different Lat/long graticules

xvi. Raster – includes satellite images.

6. The detailed listing of the proposed Karnataka GIS Asset content is given in Annexure-II. This

table contains unique list of contents. Layers derivable from these contents are not duplicated.

This Asset content will be further added/ modified during the further interactions and actual

implementation of application requirements for various interactions government departments.



7. For each content listed in the Annexure-I & II has description of the content, source of the data,

Validating agency for ingest of the data, update cycle its granularity details, Key linking attribute

– which is a unique code for linking with any MIS data, year of generation and quality tag.

8. In our assessment, almost 50% of the Content of KGIS would be derivable using satellite images.

This shows the importance of high-quality and high-resolution satellite images for KGIS

programme. KGIS is planning to publish the content layers in 2 phases. Version -1 Asset is the

List of layers already available with organization and Version - 2 would contain complete list of

layers updated/generated. Annexure-I & II contains Ver- 1 Assets (105), which will be generated

in the current year with the existing framework.

9. Coding schema for Karnataka GIS content follows the source coding schemes (say, Village codes

as per original Census village codes; Ward codes as per original ward numbers; Landuse codes as

per national level agency manual and so on)2. The coding standard is adopted from Census, NIC

GIS and NNRMS Standards and further modified for KGIS Content Coding Standard. Some

guidelines for coding are:

i) Codi g eeds to e o iously u i ue a d this has to e de eloped hile i ple e tatio .

ii) Codi g s he es ust e aki to o igi al att i ute say La duse ode Ag i ultu e o Slope ode % alue a d so o a d a oid usi g ode t a slatio ethods say ode u e s to

names or names to code numbers).

iii) Codes should be easily understandable by any user – especially when content is exchanged.

iv) Codes must form a part of Exchange Dataset and for Portal Access Services.

10. Schema for all the layers are generated which also include some of the available MIS data for

few departments. Schema is published as Annexure – I & II as a part of this document.

11. The KGIS Content Standards, KGIS Coding scheme will be public domain documents available in

real-time access to anyone who wishes to access it.

12. It is also understood that a code when generated using administrative boundaries needs to be

changed whenever there is a change / divisions in the administrative hierarchy. Ex.one Districts

split into 2 or more for administrative reasons. Hence, to maintain the uniqueness of all objects

/ entities in GIS environment and the transactions done on any spatial features, GIS based

unique ID is proposed.

13. In case of changes in administrative hierarchy (creation of more districts etc), the coding

patterns gets changed automatically based on the administrative hierarchy, as appropriate.



14. Every point / dept assets shall have the unique KGIS ID (based on the geographic objects created

by KGIS) and the unique KGIS Code (created for every department assets) apart from any other

unique code which is available with department. The schema of unique number for KGIS code

for individual department assets are explained in the Asset design document version 1.0

2.1.2 Karnataka GIS Database Standards

15. The te GIS data ase a e used to describe many different parts of the spatial data

elements of an overall GIS system – coordinates, spatial features, attributes, accuracies and

limits etc. Database design and standardizing can be thought of as the logical design of the base

data used for storage, access and rendering/serving. In the relational model, these could be the

tables, views, stored procedures, triggers. In an object database, the entities and relationships

map directly to object classes and named relationships. In a GIS, it is a combination of both that

is linked to the spatial referencing system and characterizes points, lines and polygons to user-

defined features.

16. As mentioned earlier, the KGIS database includes images, survey data, thematic maps, geo-

tagged data, crowd-sourced data etc. The KGIS Database Standards – consisting of about 16

categories have been identified. The standards parameters correspond to image, thematic

mapping and crowd source data.

17. A good GIS Database Standards – detailing the design process of producing a data model of the

GIS Content is essential. A logical data model can define all the needed logical and physical

design and physical storage parameters - which can then be used to create the GIS Database.

18. The TABLE – 2.3 from KGIS Standard Document contains the KGIS Database Standard

parameters and their values. Much of these parameters have been adapted from NNRMS

Standards, National - GIS Standards, ISO Standards has been tuned to KGIS needs. The values for

these parameters have been further refined based on the GIS experience of KGIS team and the

simulation exercises carried out to determine limits of precision required.



3. KGIS as Relational Database Management System (RDBMS)

19. A KGIS database is a collection of related data, organized to allow a computer to efficiently reply

to any query about data. A database management system (DBMS) is the software used to store,

manage, and retrieve the data in a KGIS database. The relational DBMS is most important

among available DBMS which helps to store data as a set of carefully structured tables. Storing

geospatial data KGIS database in relational DBMS is not only task, structure and storing of

database should fulfill performance and stability of data retrieval. As database size and

accessibility increases, more in-depth examination of database type, relational DBMS and would

be discussed the implementation of GIS Database.

20. The KGIS database would be store in software to store, manage, and retrieve the data in these

databases is a DBMS. All DBMS, regardless of the application for which they are used, share a

number of common features.

21. An important feature of a KGIS database is that it is computationally efficient. Efficiency requires

that a DBMS be able to operate at high performance, storing and retrieving information very

rapidly.

22. KGIS DBMS is data independence, is that users should be able to access data independently of

the technical details of how data are actually stored in the DBMS.

23. KGIS DBMS should be able to enforce logical constraints and relationships between data items

stored in the database.

24. KGIS DBMS should be able to describe the structure of the data in its database.

25. Also KGIS DBMSs will provide concurrency, whereby multiple users can access the same

database at the same time, and security, whereby the database prevents unauthorized access to

and updating of data.

3.1 KGIS DBMS Types

26. KGIS databases would be combination of four different types of database: hierarchical, network,

object, and relational.

27. A hierarchical DBMS organizes data into a strict hierarchy, where each data item may have at

most one parent data item. Spatial data of Administrative Boundaries would maintain

hierarchical structure in each layer with their parent layer.



28. A network DBMS extends the hierarchical model by allowing nonhierarchical relationships

between data items. KGIS database would reside on different machine and those databases

would communicate through network. Thus distributed database structure would be

implemented to minimize the load on single machine.

29. KGIS object oriented databases comprise data plus the procedures and behaviors necessary to

process and manipulate that data. By combining data and behavior, object DBMS can simplify

the task of modeling complex entities, including spatial entities like geographic regions.

30. KGIS s elatio al DBMS RDBMS , hich models data as a set of tables, is most common practice

and successful type of DBMS. The simple tabular structure helps RDBMS achieve extremely high-

performance storage and retrieval of data. Consequently, the RDBMS has been used in the vast

majority of database applications, including GIS.

3.2 KGIS RDBMS

31. The central component of KGIS RDBMS is the spatial layer, also referred to as a relation. Every

relation has one or more named columns, called attributes. A relation also has zero or more

rows, called tuples. Each cell in a tuple contains data about the attributes of a particular entity.

Each cell in a column contains data about the corresponding attribute. One item of data appears

in each box, or cell, at each intersection of a row and column.

3.3 Data normalization

32. Each spatial has been normalized by arranging data into logical groupings such that each group

describes a small part of the whole

33. Minimizing the amount of duplicate data stored in a database

34. Organizing the data such that, changes are done at one place which gets reflected in all its

associated cells / places.

35. Building a database in which you can access and manipulate the data quickly and efficiently

without compromising the integrity of the data in storage.



4. KGIS Database Design

36. KGIS Database design is a high-level, conceptual process of analysis that proceeds through three

general phases:

I. Requirements analysis: U de sta di g the use s e ui e e t y eadi g depa t e tal policies as most of users are various Department of State Government of Karnataka.

II. Logical design: This part would be mainly concentrating on KGIS Portal and integrated

Dashboards within portal.

III. Physical design: The actual structure of data (Spatial layers/MIS/Attribute) in database

37. It results in a database design diagram, which is also referred to as the data model or schema.

The schema is pillar of KGIS database. Schema is available for all the data, their relationships to

one another, and how they will be stored in a physical database within a computer system. The

physical database will be constructed using the schema as a blueprint. The KGIS schema helps

the database designer communicate effectively both with data producers and end users about

their data requirements.

38. KGIS database holds huge amount of data with various themes, phenomenal, entities and

objects with their respective granularity. It considers how to structure and store the location

and characteristic components of past observations, current status, future expectations, and,

possibly, imaginary arrangements of these subjects. Resulting geographic information databases

often store and provide data to work in concert with query, analysis, mapping, reporting, and

other visualization applications that can operate over an enormous range of geographic scales

and thereby serve many different goals and purposes. As these purposes are defined by users,

only use s a dete i e he a data ase s desig is o plete. Co se ue tly, data ase desig is an iterative process that may need to be repeated several times, until all required information

is represented.

4.1 Conceptual Design of KGIS Database

39. Building conceptual design of KGIS database is huge task for database analyzer/designer as

much interaction has taken place or would be taken in future to understand the precise

requirement of user and technical procedure of data producers. KGIS database designer need

to know asked about the subject they (Departments of GOK) are interested in, attributes of the

subjects they care about, and relationships among subjects that they need to visualize and

understand to support their thinking, understanding, decision making, and work. The analyst

ascertains how the data will fit into the users governance processes, how they will actually be

used, who will access them, and how the data are to be validated and protected. The analyst

analyzes, distills, and edits the interview notes (and data source specifications) and develops a



requirements specification. The specification identifies required data; describes natural data

relationships; and details performance, integrity, and security constraints of the database. It also

describes the kinds of query, analysis, and visualization GIS applications and tools the database

is intended to support and defines any operational characteristics pertaining to the hardware

and software platforms that will be used to implement the database.

4.2 Logical Design of KGIS Database

40. The database designer analyses the requirements of user as well as procedures of data

producers and come up with Object-Oriented Database Design in form of Entity, Class and

relationship between them, will be represented in ER diagram. During logical design phase,

database designer would name convention of each layer/table and table structure (Schema) for

it.

4.3 Relationships

41. Once the classes are defined, the database designer organizes and structures them within the

schema by using relationship line symbols to establish semantic, functional, and spatial

associations connecting them. In object-oriented database designs, relationships are assumed to

be bidirectional and can be reversed in both directions.

42. In KGIS database, the count of GIS layers/tables is huge and will increase in future, also more

than one person, group and organisation is involved to as user, it is essential make this layers

available in ER diagram with established relationship with connecting arrows with specified

color lines for better understanding.

4.4 Physical Design

43. During the physical design phase, database shall be drafted with available information during

requirement gathering and on the basis of logical design.

44. Database design diagrams are the basis of the interactive database design that is used to

implement the schema within an actual physical database. In addition to supporting database

modeling translate the database design models into computer programs, written in standard

database definition languages, such as Structured Query Language (SQL). Such programs can

subsequently be run by database designers or database administrators to automatically

implement, or update the prior implementation of, a physical geographic database within a

computer system.



5. KGIS Database Overview

47. KGIS database model is derived on the basis of its functional requirement. Data resides at

database falls in various categories such as admin boundaries, transportation, thematic,

departmental etc. KSRASC is nodal agency which mainly concentrates on data creation and it is

very important maintain data with high standard. KSRSAC has data created data at state level,

village level along with different scale level. KSRSAC had used different resolution satellite

images to produce such data.

46. KGIS require all these data to be in single container in order to make accessible in KGIS portal

with relevant application. Decision makers will use these applications to generate statistical

reports, analysis and so on. In nearest future citizen would be accessing this portal for various

reasons and would be allow question/query in form of text or directly putting bookmark on

po tal s ap. KGIS as a portal is going to accessible from decision makers to end user, it is very

essential to make/design/store database in robust format.

47. Designing the architecture of database should reflect in performance of KGIS portal while

accessing the application. Certainly, many users would be accessing same portal or same

application or same boundaries with relevant MIS data; in this case, database should be strong

and stable with better accessible performance.

48. Based on above mentioned facts, a database design has been developed. KGISID has been

developed for each layer which holds information of spatial entity. It is very possible database

will consist multi-GIS layer which would act as single layer. KGISID plays vital role here, this layer

may have common Code/ID which hold them together but to operate each layer of it separately,

KGISID has developed. This KGISID is sequential order but would individual digit each of layer

without considering common code for multi-layer.

49. GIS layer, State (Karnataka) visually is single layer but there are 11 objects in single entity/layer.

This single layer has common census code 29 hi h holds it togethe but there is no code for

each object. In possible scenario, this layer may get divided or amalgamated in future due to any

cause. At this moment KGISID comes into picture, in any operation layer census code may get

change but KGISID would remain unchanged. KGISID would hold original information about layer

and could be helpful retrieve relevant information in future.

50. As move further the requirement of database design changes. Since hydrology, transportation,

thematic boundaries does not have same hierarchy. In those themes, department code may not

exist or not defined by department at all. Here KGISID is helpful to communicate layer with

other layers. Mostly departmental code would be used to connect with departmental MIS data.

Thematic layer would be having KGISID and Department Code in respective layer rest other

information would connect to layer through LUT table. This will make layer lighter and fast and

accessible in portal.



51 KGISCode has been generated especially for departmental data (Asset) which is nothing but

combination of census code of state to village (16) with integration of department and

directorate code and ends with count of asset (21) in particular location. KGISCode is 37 digits

code. This auto completely generated code useful for data creation for asset since it is ongoing

process.

52. KGIS mainly focuses on data creation for assets (departmental data) which would be connecting

MIS data through department code. This MIS data would not be resides at KGIS database or not

holding property of KSRSAC. This data can be accessible through web services. Certainly MIS

data and the schema would be studied in order to create report and analysis.



6. Database Updatation Policy

53. Keeping track of database is not an easy task. Database schemas tend to mismatch in different

environments, data in one of the databases may miss some crucial piece of data. Increasingly,

researchers are required to cite and identify the exact dataset used as a research input in order

to support research reproducibility and trustworthiness. This means the researcher needs to be

able to accurately indicate exactly which version of a dataset underpins their research

findings. This e o es pa ti ula ly halle gi g he e the data to e ited a e dy a i - for

example, a subset of a large dataset accessed via a web service.

54. Perhaps available datasets may change over time. Some datasets are updated on a scheduled

basis, and other datasets are changed as improvements in collecting the data make updates

worthwhile. In order to deal with these changes, new versions of a dataset may be created.

Here, versioning supports specificity and verifiability and enables a particular version of a data

collection to be uniquely referenced.

55. Version information makes a revision of a dataset uniquely identifiable. Uniqueness can be used

by data consumers to determine whether and how data has changed over time and to

determine specifically which version of a dataset they are working with. Good data versioning

enables consumers to understand if a newer version of a dataset is available. Explicit versioning

allows for repeatability in research, enables comparisons, and prevents confusion. Using unique

version numbers that follow a standardized approach can also set consumer expectations about

how the versions differ. Intended outcome: Humans and software agents will easily be able to

determine which version of a dataset they are working with.

6.1 Possible Approach to Implementation

56. The best method for providing versioning information will vary according to the context;

however, there are some basic guidelines that can be followed

Track whether a collection has changed and if a new version is available

Determine specifically which version has been used before and which version is in use

Set expectations about how each version would differ.

57. KGIS database version is defined with simple versioning number e.g. KGISV3. Database version

does not change till any new layer(s) has been added. Major or minor change in existing layers

can be considered as same would not change version of database. Although, in future

maintaining database versioning style may change if it is necessary at all.



7. KGIS Database Structure

Spatial

Database

Attribute

Database

Metadata

Database

Application

Database

Portal

Database



7.1 Metadata Database:

58. Metadata is simply data about data, or data that describes other data. Metadata is ubiquitous.

Indeed data has no values if it does not describe metadata. And because metadata is also data,

metadata should explain what metadata means.

59. Metadata is so present in a documentation system that it is very easy to be talking about

different types of metadata, serving different functions, and thus talking at cross purposes.

Today, metadata is formed in various formats as system requires. It is mandatory to study

database/application in order to develop metadata format.

60. As above mentioned figure, different databases are maintained, depending upon the properties

of data content. Currently, in metadata database the data of data would be stored in table

format which will be displayed through web/portal to user.

The information of data holds in Metadata database in table format which is as follows

Metadata Reference

Metadata Date

Metadata Standard Version

Identification Information

Abstract

Access (Public/ Restricted)

Usage advisory

Date of Generation

Data Type

Contact person in source Agency

Publisher

Publication Date

Publisher Contact Person

Publisher Contact Telephone

Publisher Contact Fax Number

Publisher Contact Email Address

Publisher Contact Address

Completion Status

Update Frequency

Theme Keyword & Thesaurus



Data Quality Information

Logical Consistency Report

Completeness Report

Entity/Attribute Information

Entity Definition

Attribute Definition

7.2 Spatial Database:

61. A spatial database is a database that is enhanced to store and access spatial data or data that

defines a geometric space. These data are often associated with geographic locations and

features. Data on spatial databases are stored as coordinates, points, lines, polygons and

topology.

62. KGIS spatial data is divided in 16 categories which would represent in point, line and polygon

format with various granularities. There are few layer/spatial data which is seamless statewide

available and those layer do not change or get modified/updated often such as Admin

Boundaries (State, District, Taluk, Village so on), transportation (Road, Railways) Forest

Boundaries and etc. Data contain in Amenities/Departmental category holds different

granularity than rest of the 15 categories. This data mainly concentrates on geographical

location of departmental asset and mostly this data would keep on updating/modifying in terms

of geographical location or with attributes or with both in some cases. Also there are two more

categories which are POI and Graticule which has 4 and 3 layers respectively.

63. Currently there are total 249 layers have been identified to be in spatial database out of those

158 are departmental data. This count is extending as more departments are getting integrate

with KGIS DSS Portal.

7.3 Attribute/MIS Database

64. Data contains in database is nothing but attribute or MIS format. Since K-GIS is operates on

GIS/Spatial format data so Attribute/MIS data has been decided to maintain dedicatedly. In

database terminology database holds any data is always in form of tables with their attribute.

These tables could be maintaining for different joins/relationships purposes such one-to-one or

one-to-many or many-to-many.

65. This database would hold numerous tables which could be lookup or MIS table of respective GIS

layer from spatial database. Objective of separating Attribute/MIS database from spatial is to

accelerate the data retrieval activity.



7.4 Portal Database

66. This database design document concenrtrate on seamless spatial layers and MIS/attribute

tables resides in K-GIS Spatial Database as mentioned above. But there would be one more

dedicated database for portal which will contain application related information which would

come along with application architecture design.

7.5 Application Database

67. K-GIS Portal would have various application/dashboards which would be created for respective

department with their specific requirements. This document would hold information about

department and its governance procedures and application would be developed based on this

governance procedure.

68. This dedicated application would have their own databases where spatial data/MIS data and

application related data would be stored separately. Brief about database information would

come along with application design document.



8. Summary

69. Designing database architecture structure would be important job in order to energize K-GIS

portal performance. Portal would be accessed by large amount of user and to make available

portal at its best is a task. Database design and storage structure will definitely enhance the

performance of portal and other database related activities.

70. Today, database has been designed keeping futuristic vision in mind. Certainly in future, demand

and counts of users will increase; count of GIS layers/MIS data may cross the decided count,

application/dashboards integrated in portal would get modified/integrated/improvised,

upg aded ha d a e/soft a e ay o e take today s i f ast u tu e a d o side i g si ila challenges database has been designed.

72. Database design is not independent assignment. Various aspects are involved while considering

the design of database. Also, once database is up and running, it is crucial to maintain its

performance or not being shut at all. There are periodic technical activities would run as a part

of database maintenance.

73. This document has two more part which is available as a part of Annexure. These annexure

would have information about the list of layer and their schema. Annexure-I would have state

wise data like Admin boundaries, Transportation, NR layers and so on and Annexure-II would

have Public Asset which is also known as departmental asset.

*E-R diagram is also available for spatial database which would be part of this document.

KARNATAKA GIS STANDARDS - KSRSAC...Karnataka- GIS Database Standard t which defines the design standards of KGIS database 7.3. Karnataka GIS Metadata Standard- defines Metadata information

Documents