Suggested Approach for Evolving NSDI Standards at Domain Servers


R. K. Goel
Head, Informatics Aplications Division
Space Application Center, Ahemdabad
rkgoel@jpdpg.gov.in

Introduction
Realisation of National Spatial Data Infrastructure (NSDI) is the current national focus. NSDI is proposed as a single window mechanism for providing access to the spatial data being generated and managed by various agencies in the country. It is visualised as a network of databases consisting of the domain specific databases created and managed by various agencies like Survey of India, Geological Survey of India etc. and a central database having metadata to be managed by NSDI secretariat. Towards this, a national task force has been set up by Department of Science and technology which is looking at all the related issues including evolution of spatial database standards at various domain servers as well as the metadata standards for providing single window access to the domain databases.

This paper presents a framework for evolving the spatial data standards at the various NSDI domain servers. The framework has been proposed to a sub-group assigned with the task of defining standards under NSDI taskforce. The suggested framework addresses the following:

• Database Spatial Framework
• Database Contents along with Naming conventions
• Feature Codification for each Database element
• Database Schema defining linkages between Spatial & Non-spatial elements
• Database Quality Standards
• Strategy for implementation of the standards by Respective Domain Organisations
• Development of National Spatial Data Exchange Mechanism
• Formulation of National Spatial Data Exchange format (NSDE)
• Development of to-and-fro data converters by individual domain server for supply of data to users and for accepting data from other domain servers.

While suggesting this approach, references have been drawn from the two separate national efforts in this direction. These are

• The database design standards evolved and implemented as a part of National (Natural Resources Information System (NRIS) by Department of Space
• The Digital Vector Data format evolved for exchange of topographic data by Survey of India

Table 1. Example list of Database Contents (spatial) & naming contventions
(source : Illustrative list from NRIS Standards document)

S.N	Element	Type	Feat- Code	Attrib- table(s)
1	LUSEnnnnnn	Poly	LU-Code	LUSE.LUT	Landuse / cover map for different dates. nnnn indicates year of map preparation
2	GEOM	Poly	GU-Code	GEOM.LUT	Geomarphic units & Landforms captured from source map
3	LITHO	Poly	LITH-Code	LITHO.LUT	Rock Group/ Lithologic units
4	STRU	Line	STRU-code	STRU.LUT	Geological structures like lineament, fault, fracture etc.
5	SOIL	Poly	SOIL-Code	SOIL.LUT	Soil type, depth, texture etc., for associations / series/family etc.,
6	DRAIN	Line	DRN-Code	DRAIN.LUT	Drainage
7	CANAL	Line	CAN-Code	CANAL.LUT
8	WSHED	Poly	WS-Code	WSHED.LUT	Watershed hierarchy polygons
9	WELLS	Point	Wlcode	WELL.LUT	Location of Wells, nature of Wells, yield particulars, water quality etc.
10	SETTLE	Point	Scode	Census tables	Settlement Locations
11	ROADS	Line	Rdcode	ROAD.LUT	Road network

Spatial Framework
Almost every domain server will cover spatial database on nation-wide scale. It is therefore very important to devise a common spatial framework for all the domain servers. The components of spatial framework would be the following:

Multi-layer Registration Scheme
The requirement is for selection of scheme, which facilitates unique identification number for every tie point all across Indian Territory. The suggested approach is on the basis of Latitude/ Longitude co-ordinates. The scheme proposes selection of multi-layer registration points as the Latitude-Longitude intersections as well as permanently identifiable points like load intersection as follows:

• Lat/Long intersections up to 1 Minute interval, depending upon the level of details, as the Registration/ Tic points
• Permanent features like road intersections as additional points ; to cover map sources not having Latitude/Longitude graticule.
• Unique assignment of ID for each point all over India. There will be ten digit identification number for each registration point so as to make it unique.
  Identification scheme for points on Latitude-Longitude intersections.
  DDMMDDMMOO
  ——====**
  ——Latitude value in Degrees and Minutes
  ==== Longitude value in degrees and minutes
  **Unused - Could be used for Cadastral level points
  
  
  Identification Scheme for Permanent features
  9—==xxxxx
  9 Fixed value to save clash with Lat-Long number
  —Two digit State code (Census /NIC)
  == Two digit District code (Census/NIC)
  xxxxx Five digit Identification code for Registration point

Co-ordinate/Projection System
Adoption of Projection & co-ordinate system for each of the databases at domain servers will be another crucial aspect. While a broad consensus has to evolve at national level, as an interim measure individual servers as per the specific requirements could adopt the system of its choice. Alternatives could be Lambert conformal conic projection (LCC), Universal Transverse Mercator (UTM), Projection neutral co-ordinate system (Spherical Co-ordinate system in terms of latitude-longitudes). Initial studies indicate that for large size databases such encompassing the nation-wide coverage, it is best to adopt projection neutral co-ordinate system. However, The system adopted should be based, as far as possible, on evolution of national consensus under (NSDI) and its implementation should be transparent enough for facilitating shift to new system as and when required.

Table 2. Example Attribute code table for landuse/ landcover : luse.lut
(Source : Illustrative codes from NRIS Standards document)

Code	Description
	Level 1	Level 2	Level 3	Level 4
01-00-00-00	Built-up
01-01-00-00		Towns/cities (Urban)
01-01-01-00			Residential
01-01-02-00			Industrial
01-01-02-01				Salt pans
01-01-03-00			Commercial
01-01-03-01				Bus Stands
01-01-03-02				Rly Yards
01-02-00-00		Villages (Rural)
02-00-00-00	Agriculture
02-01-00-00		Crop land
02-01-01-00			Kharif
02-01-02-00			Rabi
02-02-00-00		Fallow
02-02-01-00			Current Fallow
02-02-02-00			Permanent Fallow
03-00-00-00	Forest
03-01-00-00		Evergreen/ Semi evergreen
03-01-01-00			Dense/ Closed
03-01-02-00			Open
03-02-00-00		Deciduous (Moist/Dry)
03-02-01-00			Dense/ Closed
03-02-02-00			Open
03-05-00-00		Shifting cultivation
03-05-01-00			Old Shifting Cultivation
03-05-02-00			Abandon Shifting Cultivation
03-05-03-00			Current Shifting Cultivation
03-06-00-00		Crop Land in Forest
04-00-00-00	Wastelands
04-01-00-00		Salt Affected Land
04-02-00-00		Gullied/ Ravenous Land
05-00-00-00	Water bodies
05-01-00-00		River
05-01-01-00			Water channel area
05-01-02-00			Sandy area
05-02-00-00		Canal
05-08-01-00			Back waters
05-08-02-00			Estuary/ Kayal
05-09-00-00		Cut-off Meander
07-00-00-00	Grass land / Grazing land
07-01-00-00		Dense
07-02-00-00		Degraded
STRUCTURE OF THE TABLE
Field –Name	Field Type	Key field(Y/N)
LU-Code	8,8,C	Y
Discr-L1	30,30,C	N
Discr-L2	30,30,C	N
Discr-L3	30,30,C	N
Discr-L4	30,30,C	N

Database Contents & Naming Conventions
A typical domain database would consist of both spatial and non-spatial data elements. A comprehensive list of data elements both spatial as well as non-spatial form is to be made. While making this list, care has to be taken to minimise the redundancy in the database by identifying the each input element to be a mutually exclusive item. Each of the listed elements has to be associated with specific system names for reference while accessing the database. Furthermore each element will have associated with it an attribute code table (name to be fixed) and a key field (fixed name) linking the spatial element with attribute table. An illustrative list of data elements has been provided in Table-1.

Feature Codification for individual Database Element
Each of the database elements has to follow pre-defined codification scheme. It is suggested to follow hierarchical codification as follows:

• Harmonise Various Mapping Legends prevailing in a particular theme ( e.g. Landuse- Coastal, wastelands, Forest …)
• Encompass Natural & Administrative hierarchy e.g. Landuse (Level-1,2,3,4), Admn (District, Taluk, Village) Watershed, Sub-watershed … Advantages of hierarchical codification approach
• Flexible extension of codes - Inclusion of occurrences at any level
• Reduced redundancy & improved integrity by entry of spatial features only at lowest level e.g Villages -> taluk, districts; Micro-watersheds -> mini, sub, ..
• Scope for tie-up with various collateral data sources.
  
  A typical codification for Landuse/ Landcover theme adopted under NRIS is given in Table 2 as an example.

Table 3. Example database quality standards (source : NRIS Standards document)

S.N		District Node	State Node	Centre Node
A. Input Specifications
1.	Scale	1:50,000	1:250,000	1:1,000,000
2	Thematic Accuracy
2.1	MSU (2mm)	10000 sq mtrs	250000 sq mtrs	4000000 sq mtrs
		0.01 sq kms	0.25 sq kms	4 sq kms
2.2	Mapping	90/90	90/90	90/90
		Sample checks in field
3	Control Accuracy ( w r t control points on SOI Toposheets)
3.1	Planimetric (RMS)	50 mtr	250 mtrs	1000 mtrs
B. Digital Database Specifications
1	Element Registration into system (RMS)	12.5 meters	62.5 meters	250 meters
		Location check against permanent features
2	Area	0.3%	0.3%	0.3%
3	Weed tolerance	12.5 meters	62.5 meters	250 meters
		Inspection of log file
4	Co-ordinate Movement Tolerance (CMT)	12.5 meters	62.5 meters	250 meters
2.5	Sliver Polygon Tolerance	2500 sq m	62500 sq m	1000000 sq m
		0.025 sq km	0.625 sq km	1 sq km
		Digital MSU- 1mmx1mm map equivalent
2.6	Grid size (For Raster GIS)	25x25 m	125x125m	500x500 m

Database Quality Standards
The need for controlling the quality of database elements needs no special emphasis. Considering the fact that spatial databases carry errors in a variety of forms starting from the in-accuracy in the source documents to the data conversion process, laying down of database quality control parameters is of utmost importance. The parameters (as illustrated in table-3 & 4) to be specified should include

• Accuracy thresholds categorised into thematic and control accuracy for analog inputs
• Accuracy thresholds for digitised elements categorised into multi-layer registration accuracy (RMS), tolerable area errors in terms of percentages, co-ordinate weed tolerances, co-ordinate movement tolerances and tolerances for removal of sliver polygons.
• Acceptable age and update frequency for each data element.

Implementation of the standards
Apart from specifying the thresholds for data quality, mechanism for enforcing the data quality standards at each domain server should be established which should include:

• Dedicated team and procedures for checking, verification and quantitative assessment of the accuracy of each of the analogue inputs prior to its conversion into digital format.
• Automated procedures for checking, verification and acceptance of digitised inputs covering the digital quality thresholds, the naming conventions and the structural aspects of database design.

Table 4. Database element specific references for acceptance of inputs
(Source : NRIS Standards Document)

S.N	Element	Level of Details			Acceptable Age
		1:50000	1:250000	1:1M	Update cycle
1	LUSE	Level-III	Level-II	Level-I	2 yr.
2	GEOM	Landforms	Geomorphic Units	Physiographic Units	10 Yr.
3	SOIL	Soil series Association	Family Association	Sub-group Association	10 yr.
4	DRAIN				20 Yr., Area Specific
5	ROADS	Villages roads/Cart roads	District Road	As per CIM	As and when required

National Spatial Data Exchange Mechanism
Ultimate success of NSDI concept would depend upon the ability of individual domain servers to serve the data to user community in a format, which is understood by one and all. While the individual domain servers could adopt the database design and implementation approaches based on their specific requirements of S/W and H/W tools, the exchange mechanism has to be open and neutral to specific platform. In this context it is very essential to evolve National Spatial Data Exchange format (NSDE). This format, once evolved has to be supplemented by individual domain servers by development of to-and-fro data converters for supply of data to users and for accepting data from other domain servers.

Acknowledgements
The author wishes to thank Mr A K S Gopalan, Director, Space Applications Centre (SAC-ISRO) and Shri A R Dasgupta, Dy. Director, SAC-ISRO for their guidance and encouragement. Thanks are also due to my colleagues and co-workers who have contributed to the evolution of various ideas presented in this paper.

References

• Dasgupta A.R., 2000, The National Natural Resources Information System, in Proceedings, GEOMATICS-2000, Conference on Geomatics in Electronics Governance, Organised by Indian Society of Geomatics & Centre for Development of Advanced Computing (C-DAC), Pune, India.
• Dasgupta A.R. & Goel R.K., 2002, National (Natural) Resources Information System (NRIS) - Design Concepts, in Map India ‘2002’ organised by CSDMS, A-13, Sector 22, Noida, UP, India.
• Indian Space Research Organisation (ISRO), 2000, National (Natural) Resources Information System - NRIS Node design and Standards, A publication from National Natural Resources Management System, ISRO, Bangalore, India.
• Shah S.A., Yadav P.D. & Goel R.K., 2002, National Spatial Data Exchange (NSDE) format under NSDI, in Map India ‘2002’ organised by CSDMS, A-13, Sector 22, Noida, UP, India.
• Udani P.M., Yadav P.D. & Goel R.K., 1999, Design of Large Area Spatial Framework for NRIS, Proceedings, Map India ’99, published by CSDMS, A-13, Sector 22, Noida, UP, India.
• Vaishnav Bharat, Kharod Ketki, Yadav P.D. & Goel R.K., 1999, Ensuring the Integrity and validity of NRIS databases, Proceedings, Map India ’99, published by CSDMS, A-13, Sector 22, Noida, UP, India.
• Vaishnav Bharat, Shah S. A. & Yadav P.D., 2002, Data Exchange Between NRIS and Proposed NSDI- Spatial Data Exchange Format,in Map India ‘2002’ organised by CSDMS, A-13, Sector 22, Noida, UP, India.