GML Topology Data Storage Schema Design

GML Data Storage Schema Design Paper: GML Data Storage Schema Design Yuzhen Li, Jianming Lu, Jihong Guan, Mingying Fan, Ayman Haggag, and Takashi Yahagi Graduate School of Science and Technology, Chiba University E-mail: yuzhenli@graduate.chiba-u.jp [Received December 27, 2006; accepted March 19, 2007] Geography Markup Language (GML) was developed to standardize the representation of geographical data in extensible markup language (XML), which facilitates geographical information exchange and sharing. Increasing amounts of geographical data are being presented in GML as its use widens, raising the question of how to store GML data efficiently to facilitate its management and retrieval. We analyze topology data in GML and propose storing nonspatial and spatial data from GML documents in spatial databases (e.g, Oracle Spatial, DB2 Spatial, and Post- GIS/PostgreSQL.). We then use an example to analyze the topology relation. Keywords: GML, topological data, topology scheme, spatial query 1. Introduction With the development of the Worldwide Web s geographic information system (GIS), geographical data exchange and sharing has become possible in different applications. The lack of interoperability between different geographical databases that have been developed, however, makes data exchange and sharing difficult. GML is an XML-based OpenGIS consortium (OGC) specification for representing and exchanging geographic information, including geometry and the properties of geographic features [1]. The difference between XML and GML is that GML supports geometric elements corresponding to Point, LineString, LinearRing, Polygon, MultiPoint, MultiLineString, MultiPolygon, and GeometryCollection. The current versions, GML 3.1, was extended to represent geospatial phenomena in addition to simple 2D linear features, including features with complex, non-linear, 3D geometry, features with 2D topology, features with temporal properties, dynamic features, coverages, and observations. GML has significantly influenced the ability of organizations to share geographic information. Using GML, users deliver geographic information as distinct features and control how they are displayed. Best of all, users view resulting maps using a standard browser, without the need for proprietary client GIS software. We previously proposed storing nonspatial and spatial data from GML documents in spatial databases [2], first generating a GML schema tree in the given GML schema, then mapping the generated schema tree into corresponding relational schemas. All basic spatial objects are eventually stored as values of the mapped table fields. is a key requirement for data management and integrity, having such functions as managing shared geometry, defining and enforcing data integrity rules, supporting topological relationship queries and navigation, supporting sophisticated editing tools that enforce topological constraints of the data model, and constructing features from unstructured geometry. No such work has, to our knowledge, been done on GML topology storage and management, however. Here we propose storing topology data from GML documents in spatial databases. To do so, we first analyze topology data in GML, then design a database model to store GML topology data, using an example to analyze the topology relationship. 2. Background In the sections that follow, we present a brief overview of GML storage and propose storing GML documents in spatial databases. The GML database we are establishing, called GBase, is used to manage GML data efficiently. (Fig. 1) consists of six components: a schema extractor (SE), a schema simplifier (SS), a schema tree generator (STG), a mapping rules generator (MRG), a data loader (DL), and a query translator (QT). The SE extracts the GML schema from GML document that have no schema. The SS module simplifies the GML Schema. The STG generates GML schema trees by using a schema tree generation algorithm, whose input is GML application schemas. The MRG generates the mapping specifications based on the GML structure-mapping algorithm. The DL uses a GML document or GML topology data as inputs, stores it in the target SDBMS based on mapping specifications generated by the MRG or the topology scheme. The QT translates a GML query into a corresponding SQL query that ready to be submitted to the SDBMS. The results returned are constructed and delivered to the user via the QT [2]. Having designed an efficient way to manage GML data, we studied how to best store GML topology data. Vol.11 No.6, 2007 Journal of Advanced Computational Intelligence 701

Li, Y. et al. Schema Extractor Schema Simplifior GML Schema schema tree generation algorithm GML schema Schema Tree Generator GML structure GML schema tree mapping algorithm Mapping Rules Generator Mapping specification GML query GML results GML document Data Loader Query Translator GML topology data tuples SQL Query /results e3 f1 e1 n2 n1 e2 n3 f2 e4 f3 e5 n4 e6 Fig. 2. Simple topology manifold. SDBMS Fig. 1. GML storage architecture. 3. GML Data Analysis and Storage Model Design The sections that follow discuss how to store GML topology data in a database and use such for spatial analysis and operation. 3.1. Concept is the branch of mathematics describing the properties of objects that are invariant under continuous deformation. A circle, for example, is topologically equivalent to an ellipse because one can be transformed into the other by stretching. In geographic modeling, topology is mainly used in accelerating computational geometry. In a graph, the number of intersecting points, line segments, polygons, and their mutual relationships, are constant because the plane on which they are is stretched or distorted. In GIS applications, topology is used to explicitly describe, manage, and retrieve these relationships without resorting to time-consuming spatial comparison. The principles of topology are used to implement a system that enables rapid spatial data retrieval, enhanced spatial data analysis, spatial data editing and clean unimproved data consistency, management of shared geometry, and definition and enforcement of data integrity rules [3]. Some GIS applications use persistent topology, i.e., to structure data based on topological principles so that topological relationships are stored and continuously available in the database. The persistent topology approach also stores spatial data more efficiently, reduces or eliminates spatial redundancy data, implements certain spatial business rules more easily in the database, improves the management of hierarchical geographic relationships [4], and addresses coordinate precision and tolerance issues that may lead to gaps or slivers more straight forwardly [5]. 3.2. Data Analysis in GML The GML3 conceptual model for topology describes the correspondence of topological and geometric relationships up to 3 dimensions. In GML, spatial topology is modeled using basic building blocks nodes, edges, faces, and solids called topology primitives, together with a description of their mutual connective relationships [6]. The GML topology primitive types Node, Edge, Face, and TopoSolid are often used to describe geometry primitives, Point, Curve, Surface, and Solid. is concerned with such connective primitive relationships as the connectedness of nodes, the coincidence of edges, and the adjacency of faces and solids. Unlike GML geometry, topology does not encode coordinates and the topology model is not associated with the positioning of nodes, the direction of edges, or the shape of faces and solids. To introduce an example for interpreting a concrete concept of GML topology primitives and their relationships, Fig. 2 shows a manifold of nodes, edges, and faces abstracted from real-world objects, and gives the adjacency and containment relationships between them. Just as edges are formed from a pair of directed nodes, faces are formed from a set of directed edges that are traversed to determine face boundaries. This example has four nodes n1, n2, n3, and n4; six edges e1, e2, e3, e4, e5, and e6; and three faces f1, f2, and f3. In GML 3.1, nodes need only be identified uniquely using the gml:id attribute, so nodes in the example are encoded as follows: <gml:node gml:id="n1"/> <gml:node gml:id="n2"/> <gml:node gml:id="n3"/> <gml:node gml:id="n4"/> Edges are encoded as follows: <gml:edge gml:id="e1"> xlink:href="#n1"/> xlink:href="#n2"/> <gml:edge gml:id="e1"/> <gml:edge gml:id="e2"> xlink:href="#n2"/> xlink:href="#n3"/> <gml:edge gml:id="e2"/> 702 Journal of Advanced Computational Intelligence Vol.11 No.6, 2007

GML Data Storage Schema Design <gml:edge gml:id="e3"> xlink:href="#n3"/> xlink:href="#n1"/> <gml:edge gml:id="e3"/> <gml:edge gml:id="e4"> xlink:href="#n2"/> xlink:href="#n4"/> <gml:edge gml:id="e4"/> <gml:edge gml:id="e5"> xlink:href="#n1"/> xlink:href="#n4"/> <gml:edge gml:id="e5"/> <gml:edge gml:id="e6"> xlink:href="#n4"/> xlink:href="#n3"/> <gml:edge gml:id="e6"/> In this example, the xlink:href attribute is used to reference previously defined nodes. The orientation attribute is used to represent a positive orientation "+" for some of the nodes, signifying that these nodes are at the end of the corresponding edge, and negative orientation "-" signifying that these nodes are at the start of the edge. Note that each edge is directed by its start node and end node and is traversed either negatively or positively. The directed edge "+e1", for example, corresponds to traversing the path along "e1" from n1 to n2 and "-e1" traverses the path from n2 to n1. The directed edge "+e1" is encoded in GML 3.1 using the directededge property that uses the orientation attribute "+" as follows. xlink:href="#e1"/> One possible route from n1 to n4 is expressed as a TopoCurve in GML, which contains a list of directed edges +e1, and +e4 forming a connected path. The following example shows how this path from n1 to n4 is encoded as a TopoCurve: <gml:topocurve> xlink:href="#e1"/> xlink:href="#e4"/> </gml:topocurve> In the GML topology model, each face is defined by its boundary, which consists of a list of directed edges. Directed edges on the boundary of each face are traversed counter clockwise as indicated by the arrow enclosing f1 in Fig. 2. The orientation of each directed edge on the boundary of a face is either "+" or "-", depending on whether the inherent direction of the edge agrees or disagrees with the counter clockwise orientation of the face. The boundary of the face labeled f1, for example, when traversed counter clockwise, corresponds to directed edges in the set +e1, +e2, and +e3. Faces are encoded in GML 3.1 as follows: <gml:face gml:id="f1"> xlink:href="#e1"/> xlink:href="#e2"/> xlink:href="#e3"/> </gml:face> In Fig. 2, e1 and e2 are edges having a face on either side. Using e1 as an example, both faces f1 and f2 contain the directededge e1 with either a positive or negative orientation in their boundary lists. Faces f1 and f2 are said to be on the coboundary of e1. In GML3, the edge primitive has an optional property called directedface, whose value is a face that is on the coboundary of the edge. To distinguish between faces on the left and right of e1, each of the coboundary faces is assigned an orientation. A positive orientation corresponds to face f2 and a negative orientation to face f1. Note that if the orientation of a directedface on the coboundary of an edge is "+", the face must contain the directededge with the same orientation "+" in its boundary list of directed edges. Encoding of the edge e1 that describes its coboundary information in addition to its boundary information is as follows: <gml:edge gml:id="e1"> xlink:href="#n1"/> xlink:href="#n2"/> <gml:directedface orientation="-" xlink:href="#f2"/> <gml:directedface orientation="+" xlink:href="#f1"/> </gml:edge> Similarly, each node is encoded with a coboundary list of directededges to represent edges incident upon the node. A positive orientation on directed- Edge corresponds to an edge that points toward the node and a negative orientation to an edge emanating Vol.11 No.6, 2007 Journal of Advanced Computational Intelligence 703

Li, Y. et al. Table 1. Node table schema. Table 3. Face table schema. NodeID NGtype EdgeID1 EdgeOrientation1 EdgeID2 EdgeOrientation2... FaceID FGtype DirEdgeID1 DirEdgeOri1 DirEdgeID2 DirEdgeOri2... Table 2. Edge table schema. equal disjoint overlap cross EdgeID EGtype BNodeID TNodeID LPolygonID RPolygonID within contain touch intersection from the node. Node n2 from Fig. 2 can, for example, be encoded as follows: <gml:node gml:id="n2"> xlink:href="#e1"/> <gml:directededge orientation="-" xlink:href="#e2"/> <gml:directededge orientation="-" xlink:href="#e4"/> </gml:node> 3.3. Data Storage Based on topology data analysis in GML, a database storage schema is designed to store GML topology data. 3.3.1. Node Table Schema Design The node table schema (Table 1) is designed so that NodeID represents the gml:id attribute, e.g., the id number of node n4 is n4; NGtype describes the spatial location of node n4; EdgeID1and EdgeID2 are the ID numbers of edges associated with this node; and EdgeOrientation1and EdgeOrientation2 are orientations a positive orientation on directededge corresponding to an edge that points toward the node and a negative orientation corresponding to an edge emanating from the node. The number of edges associated with a node may be uncertain, and this uncertainty can not be resolved in relational database. Because the spatial database is objectoriented, however, it supports user-defined data types and solves the uncertainty problem. 3.3.2. Edge Table Schema Design The edge table schema (Table 2) is designed so that EdgeID is the unique ID number for this edge, e.g., the ID of edge e1 is e1; EGtype is the location representing edge e1; BNodeID is the ID number of the start node for this edge; TNodeID is the ID number of the end node for this edge; LPolygonID is the ID number of the left face for this edge; and RPolygonID is the ID number of the right face. 3.3.3. Face Table Schema Design The face table schema (Table 3) is designed so that FaceID is the unique ID number for this face; FGtype is Fig. 3. Few faces topology operation. the location of the face; DirEdgeID1, and DirEdgeID2 are the ID of the directed edge on its boundary; and DirEdge- Ori1 and DirEdgeOri2 represent orientations of each directed edge on the boundary of a face. As in node table design, the number of directed edges consisting of the face is uncertain, so we use this objectoriented technique to define the data type. 3.4. Relationship After GML topology data is stored in a spatial database, topology data is put to such uses as spatial analysis and operation. data is very useful because many spatial modeling operations require only topological information not coordinate locations. Finding an optimal path between two points, for example, requires a list of mutually connected arcs or lines and the cost required to traverse them in each direction. It is operated using stored topology. A road feature may consist of many edges, an area feature such as a park may consist of many faces, and some nodes may not be associated with point features. The Open GIS Consortium has specified eight topological and set predicates, i.e., equal, disjoint, intersect, touch, cross, within, contain, and overlap. We express the relationship between them are shown in the example in Fig. 3. If the interior and boundary of two geometries are spatially equal, they are topologically equal. If the boundaries and interior do not intersect, they are topologically disjoint. If geometries are not disjoint, they intersect. If boundaries of two surfaces intersect but interiors do not, they touch. If the interior of a surface intersects a curve, they topologically cross. If the interior of the given geometry does not intersect the exterior of another geometry, they are topologically within. If the given geometry contains another given geometry, they topologically contain; If the interiors of two geometries have a nonempty intersection, they topologically overlap. A feature with topology and geometry properties is represented one of two ways in a GML application schema as a feature with a two-dimensional spatial extent having both geometry and topology valued properties, and as a feature with a two-dimensional spatial extent having topology valued properties with embedded geometry valued properties (Fig. 4). 704 Journal of Advanced Computational Intelligence Vol.11 No.6, 2007

GML Data Storage Schema Design Node Edge Face TopoSolid property Feature Sub type Sub type property Feature (a) Node Edge Face TopoSolid (b) Geometry property Geometry Sub type PointProperty CurveProperty SurfaceProperty SolidProperty Point Curve Surface Solid Point Curve Surface Solid Fig. 4. Feature representation. (a) Feature with twodimensional spatial extent, having both geometry and topology valued properties. (b) Feature with two-dimensional spatial extent, having topology valued properties with embedded geometry valued properties. W. Chesterton Ward Milton Ward A14 F. Chesterton Ward Fig. 5. Administrative districts. The feature with a two-dimensional spatial extent and having both geometry and topology valued properties is used to produce a map from geometric data captured in the spatial model, so it would be easier for an application to extract the geometric data. The feature with a two-dimensional spatial extent and having topology valued properties with embedded geometry valued properties is used for a query that may involve both topology and geometry, such as an optimal route query. We use the second feature for our application. Fig. 4 shows a realworld example of point, line, and area features associated with the topology in Fig. 2. The smallest administrative district in our example is the ward. The manifold corresponds to three wards (Fig. 5) or administrative districts. Each face is used by a ward, e.g., Milton Ward at f1, W. Chesterton Ward at f2, and F. Chesterton Ward at f3, and A14 Road at edges e1 and e2. These administrative districts is encoded as follows:... <gml:featurecollection> <gml:boundedby> <gml:box> <gml:coordinates> 0,0 </gml:coordinates> <gml:coordinates> 100,100 </gml:coordinates> </gml:box> </gml:boundedby> <gml:featuremember> <Ward fid="w1"> <gml:name>milton</gml:name> <gml:directedtoposurface orientation="+"> <gml:toposurface> <gml:directedface orientation="+" xlink:href="simplemanifold.xml#f1"/> </gml:toposurface> </gml:directedtoposurface> </Ward> </gml:featuremember> <gml:featuremember> <Ward fid="w2"> <gml:name>w. Chesterton</gml:name> <gml:directedtoposurface orientation="+"> <gml:toposurface> <gml:directedface orientation="+" xlink:href="simplemanifold.xml#f2"/> </gml:toposurface> </gml:directedtoposurface> </Ward> </gml:featuremember> <gml:featuremember> <Ward fid="w3"> <gml:name>f. Chesterton</gml:name> <gml:directedtoposurface orientation="+"> <gml:toposurface> <gml:directedface orientation="+" xlink:href="simplemanifold.xml#f3"/> </gml:toposurface> </gml:directedtoposurface> </Ward> </gml:featuremember> <gml:featuremember> <Road fid="r11"> <gml:name>a14</gml:name> <gml:directedtopocurve orientation="+"> <gml:topocurve> xlink:href="simplemanifold.xml#e1"/> xlink:href="simplemanifold.xml#e2"/> </gml:topocurve> Vol.11 No.6, 2007 Journal of Advanced Computational Intelligence 705

Li, Y. et al. GML application document Data Loader data storage rules GML topology query Query Translator SQL query/ results Query results Table 4. Different types of topology queries. Q1 Equal (Milton, W.Chesterton)? Q2 Disjoint (Milton, W.Chesterton)? Q3 Touch (Milton, W.Chesterton)? Features w1...... w2...... w3...... Reference n1...... n2...... n3............... e1...... e2...... e3............... f1...... f2...... f3...... Node Edge Face Q4 Q5 Q6 Contain (Milton, W.Chesterton)? Within (Milton, W.Chesterton)? Overlap (Milton, W.Chesterton)? topology queries spatial comparation Fig. 6. GML application document with topology data. </gml:directedtopocurve> </Road> </gml:featuremember> </gml:featurecollection> We stored this GML application document in the database using our system (Fig. 6). If we want to know the spatial relationship between Milton Ward and W. Chesterton Ward, e.g., whether they are mutually adjacent, we need only to know whether they have a mutual coboundary. Milton Ward references previously defined topology face f1. W. Chesterton Ward references topology face f2, so, we get edge ID from the edge table. f1 has the edges e1, e2, and e3. f2 has the edges e5, e4, and e1. They have coboundary e1, so they are adjacent, i.e., they touch in a spatial relationship. To identify all Wards passed by Road A14, we must find the edge sequence consisting of Road A14, i.e., e1, e2, then find unions f1, f2, and f3 of the left and right faces of the edge sequence, Milton Ward references topology face f1, W. Chesterton Ward references topology face f2, and F. Chesterton Ward references topology face f3, identifying wards as Milton, W. Chesterton, and F. Chesterton. data makes spatial analysis more efficient. A spatial query requires a spatial index to be traversed and a number of compute-intensive geometric comparisons. Relationships such as overlap (share face) and touch (share edge) are held as references within the topology model. These may be traversed very quickly by table joins to identify other features that use the same node, edge, or face. Using topology improves performance by more than one order of magnitude, reducing execution time for a complex query from over a minute to just a few seconds. Topological operations also prevent the choice of coordinates for the database from affecting results of topological operations. Time cost 160 140 120 100 80 60 40 20 0 Q1 Q2 Q3 Q4 Q5 Q6 Different queries Fig. 7. Cost time for different queries. We compared time consumed between a query using topology data and one using spatial comparison. A set of queries is first used to study the efficiency of topology approaches involving a spatial relationship query: equal, disjoint, and touch contain within and overlap (Table 4). Elapsed query times are shown in Fig. 7. In conclusion, using topology data speeded up retrieval and decreased time cost. Spatial queries relying on topological references alone are thus expected to perform much better in the topological model than in the geometrical model. 4. Conclusion We have analyzed GML topology data and designed the GML topology data storage schema based on earlier work, using a concrete example for comparing spatial queries. The structure added to data enables many spatial queries to be answered more quickly by examining topology. In projected work, we plan to provide topology analysis to make GML query processing more efficient. 706 Journal of Advanced Computational Intelligence Vol.11 No.6, 2007

GML Data Storage Schema Design Acknowledgements This work was supported by the National Natural Science Foundation of China under grants 60573183 and 90612007 and the Program for New Century Excellent Talents of the University of China under grant NCET-06-0376. References: [1] OpenGIS Consortium, GML Specifications, available at http://www.opengis.org/. [2] Y. Li, J. Li, and S. Zhou, GML Storage, A Spatial Database Approach, ER (Workshops), pp. 55-66, 2004. [3] E. Hoel, S. Menon, and S. Morehouse, Building Robust Topologies, In Advances in Spatial and Temporal Databases, Proceedings of the 8th International Symposium on Spatial and Temporal Databases, SSTD, Santorini Island, Greece, Springer-Verlag Lecture Notes in Computer Science 2750, 2003. [4] S. Ramage and P. Woodsford, The Benefits of in the Database, 2002, available at http://spatialnews.geocomm.com/features/laserscan2/. [5] M. Egenhofer, A. Frank, and J. Jackson, A Topological Data Model for Spatial Databases, Design and Implementation of Large Spatial Databases, Lecture Notes in Computer Science, 409, pp. 271-286, 1989. [6] Galdos System Inc., Developing and Managing GML Application Schemas, 2003, available at http://www.geoconnections.org/developerscorner /devcouner devnetwork/componects/gml bpv1.3 E.pdf. [7] J. E. Corcoles and P. Gonzalez, A Specification of a Spatial Query Language over GML, pp. 112-117, 2001. [8] W. Chung and H.-Y. Bae, A Specification of a Moving Objects Query Language over GML for Location-Based Services, In Advanced Web Technologies and Applications: 6th Asia-Pacific Web Conference, APWeb, pp. 788-793, 2004. [9] J. Guan, S. Zhou, J. Chen, X. Chen, Y. An, W. Yu, R. Wang, and X. Liu, Ontology-based GML schema matching for information integration, In: Proceedings of 2nd IEEE International Conference on Machine Learning and Cybernetics, Vol.4, pp. 2240-2245, IEEE CS, Xian, China, November 2003. [10] Z. Guo, S. Zhou, Z. Xu, and A. Zhou, G2ST: A Novel Method to Transform GML to SVG, In: Proceedings of ACM-GIS 2003, ACM Press, November 2003. Yuzhen Li Ph.D. candidate, Graduate School of Science and Technology, Chiba University 2003 Received the B.C. degree from Wuhan University, P.R.China 2005 Received the M.S. degree from Wuhan University, P.R.China 2006- Ph.D. student of the Graduate School of Science and Technology, Chiba University, Chiba, Japan theory and application of spatial database and computer vision, etc. Jianming Lu Associate Professor, Graduate School of Science and Technology, Chiba University 1990 Received the M.S. degree from Chiba University, Japan 1993 Received the Ph.D. degree from Chiba University, Japan 1993- Associate in the Department of Information and Computer Sciences, Chiba University, Chiba, Japan 1994- Graduate School of Science and Technology, Chiba University 1998- Associate Professor in the Graduate School of Science and Technology, Chiba University theory and applications of digital signal processing and control theory Jihong Guan Professor, Department of Computer Science and Technology, Tongji University Shanghai 200092, China 1991- Received B.S. in Computer Science from Central China Normal University 1996-2000 Lecturer in Wuhan University 1998- Received M.S. in Computer Applications from Wuhan Technical University of Surveying and Mapping (WTUSM) 2000-2003 Associate professor in Wuhan University 2002- Received Ph.D. in Photogrammetry and Remote Sensing from Wuhan University 2003-2005 Professor in Wuhan University spatial database, text database, GIS, data mining and information retrieval Up to date, she has published more than 60 articles in international and domestic journals and conferences. Membership in Academic Societies: Senior member of China Computer Federation Vol.11 No.6, 2007 Journal of Advanced Computational Intelligence 707

Li, Y. et al. Mingying Fan Ph.D. candidate, Graduate School of Science and Technology, Chiba University Takashi Yahagi Professor, Graduate School of Science and Technology, Chiba University 2001 Received B.C. degree from Daqing petroleum Institute and Harbin Engineering University, P.R.China 2004 Received M.S. degree from Daqing petroleum Institute and Harbin Engineering University, P.R.China 2007- Ph.D. student, Graduate School of Science and Technology, Chiba University, Chiba, Japan computer vision and image processing, etc. Ayman Haggag Ph.D. candidate, Graduate School of Science and Technology, Chiba University 1994 Received B.Sc. degree from Ain Shams University, Egypt 1997 Received M.Sc. degree from Eindhoven University of Technology, The Netherlands 1998-2004 Industrial Education College, Helwan University, Egypt 2004- Ph.D. student, Graduate School of Science and Technology, Chiba University, Japan image coding and security of data and images over networks and communication channels 1966 Received B.S. degree in electronics from the Tokyo Institute of Technology, Tokyo, Japan 1968 Received M.S. degree in electronics from the Tokyo Institute of Technology, Tokyo, Japan 1971 Received Ph.D. degree in electronics from the Tokyo Institute of Technology, Tokyo, Japan 1971- Lecturer in the Department of Electronics at Chiba University, Chiba, Japan 1974-1984 Associate Professor in the Department of Electronics at Chiba University, Chiba, Japan 1984- Professor in the Department of Electrical Engineering at Chiba University, Chiba, Japan 1989-1998 Department of Information and Computer Sciences 1998- Graduate School of Science and Technology, Chiba University theory and applications of digital signal processing and other related areas Theory of Digital Signal Processing, Vols.1 3, 1985, 1985, 1986 Digital Signal Processing and Basic Theory, 1996 Digital Filters and Signal Processing, 2001 Kalman Filter and Adaptive Signal Processing, 2005 co-author of the Digital Signal Processing of Speech and Images, 1996 VLSI and Digital Signal Processing, 1997 Multimedia and Digital Signal Processing, 1997 Neural Network and Fuzzy Signal Processing, 1998 Communications and Digital Signal Processing, 1999 Fast Algorithms and Parallel Signal Processing, Corona Pub., Tokyo, Japan, 2000 Editor of the Library of Digital Signal Processing, Corona Pub., Tokyo, Japan Membership in Academic Societies: President of the Research Institute of Signal Processing, Japan, and also the Editor-in-Chief of the Journal of Signal Processing (1997-) The Institute of Electrical and Electronics Engineers, Inc. (IEEE), USA The Institute of Electronics, Information and Communication Engineers (IEICE), Japan The Research Institute of Signal Processing (RISP), Japan 708 Journal of Advanced Computational Intelligence Vol.11 No.6, 2007