|
Mature Data Model
◆ Full support of various kinds of spatial object model
SuperMap SDX+ fully supports various spatial object types, including simple spatial objects such as point, line, polygon and complex spatial data model, for example, text, composite object, network, route, TIN, DEM, GRID and image etc.
◆ Sequence data model
SuperMap SDX+ supports storage of historical data, and it can retrospect data at any time slice, what’s more, it can rewind the change of the historical data just like rewinding the movie.
It is easy to use sequence data. When saving the target data, set the Option of the dataset to scoSequence, thus, any modification made to the data will be recorded. When retrospecting the data, set the display filter (the DisplayFilterEx property) of the layer (the soLayer object) to the desired historical time, then data status at specified time can be reviewed after refreshing.
Management of sequence data is further enhanced for the latest SuperMap SDX+, and the function of managing data at different historical time is added. Users can set different time, take the snap-shot of the data at every time, when needed to retrospect data, the desired time can be fast located, and you can perform deleting, joining and retrospection to any particular time.
◆ Topological relationship storage
Topological model is further enhanced, implementing a complete topology model and topology validation rules.
The SDX+ of SuperMap GIS 2008 redefines topological model. Point, line, region and other types of data can be integrated and managed in a unified model, and you can set the topology rules between datasets, then the topology validation will be performed based on the defined rules, for example, checking whether the points in one point dataset are covered by the endpoints of the arcs in another line dataset, whether the lines in one line dataset be covered by the boundaries in another line dataset, whether the lines in two line datasets overlap and so on. The violations of the rules found during topology validation will be stored in system table, so that the user can edit to maintain the correct topology relationships. The topology errors generated during topology validation will be fixed by the user when performing editing. After editing, you can perform topology validation in the “dirty areas” where edits have been performed or the specified areas. Some common topological rules are listed below:
Topological Rules |
Dataset Type |
Description |
| (Must Not Overlap) |
Region |
The interior of regions should not overlap. |
| (Must Not Have Gaps) |
Region |
There are no voids within a region or between adjacent regions. |
| (Must Not Overlap With) |
Region |
The interior of regions in one region dataset must not overlap with the interior of regions in anther region dataset. |
| (Must Be Covered By Dataset Of) |
Region |
A region in one region dataset must share all of its area with regions in another region dataset. |
| (Must Cover Each Other) |
Region |
Regions in one region dataset must be contained within regions of another region dataset. |
| (Must Be Covered By) |
Region |
Regions in one region dataset must be contained within regions of another region datasets. |
| (Boundary Must Be Covered By) |
Region
Line |
The boundaries of the regions in a region dataset must be covered by the line objects from a line dataset. |
| (Area Boundary Must Be Covered By Boundary Of) |
Region
Region |
The boundaries of regions in one region dataset must be covered by boundaries of regions in another region dataset. |
| (Contains Point) |
Region
Point |
A polygon in one region dataset must contain at least one point from another point dataset, while points from that point dataset must be within the polygon of the polygon dataset. |
| (Must Not Overlap) |
Line |
The lines must not overlap in one line dataset. |
| (Must Not Intersect) |
Line |
Lines in the same line dataset must not cross or intersect each other. |
| (Must Not Have Dangles) |
Line |
Lines must touch lines from the same line dataset at both ends, namely there must be no dangles in the line dataset. |
| (Must Not Have Pseudo-nodes) |
Line |
A line must not have pseudo-nodes, that is to say, a line connect to more than one line at each endpoint. |
| (Must Not Intersect Or Touch Interior) |
Line |
Lines must only touch other lines from the same dataset at endpoints. |
| (Must Not Overlap With) |
Line
Line |
The line from one dataset must not overlap with the line in another dataset. |
| (Must Be Covered By Feature Class Of) |
Line
Line |
Lines in the first dataset must be covered by the lines in the second dataset. |
| (Must Be Covered By Boundary Of) |
Line
Polygon |
Lines must be covered by the boundaries of regions. |
| (Endpoint Must Be Covered By) |
Line
Point |
The endpoints of lines must be covered by points in point dataset. |
| (Must Not Self Overlap) |
Line |
Lines must not self-overlap. |
| (Must Not Self Intersect) |
Line |
Lines must not intersect or overlap themselves. |
| (Must Be Single Part) |
Line |
The lines must only have one part. |
| (Must Covered By Boundary Of) |
Point
Region |
Points must fall on the boundary of the regions. |
| (Must Be Properly Inside Polygons) |
Point
Region |
Points must be properly inside polygons |
| (Must Be Covered By Endpoint Of) |
Point
Line |
Points must be covered by endpoint of the lines in anther dataset. |
| (Must Be Covered By Line) |
Point
Line |
Points must be covered by lines in another dataset. |
| (Must be larger than cluster tolerance) |
Line
Region |
Distance between nodes of Line or polygon must be larger than cluster tolerance. |
Version Management and Long Transaction
Version Management
Data editing like adding, deleting or modification should be given more careful attention in GIS applications. It is better to save every version of data after each step of editing so that rollback or restoration can be performed; in another case, the size of the data in a dataset is sometimes very large, if only one personnel is assigned to do this job, it will take much time, so a number of personnel are required to simultaneously operate the data, while it is necessary that their respective edit will not interfere with each other. This requires that the spatial data engine provides the versioning functionality.
To cater to centralized data management and asynchronous maintenance, version management model is introduced in SuperMap SDX+, where one or more versions of the target dataset can be created. Once the version is created, all editing operations on the data will be incrementally recorded in a new version branch, and version branches are independent of the original data as well as each other, therefore, on one hand, every editor can access and lock the data, on the other hand, multiple editors can perform editing to the same dataset at the same time while their versions will not interfere with each other.
It is prone to version conflict when the target is edited by different users simultaneously; a convenient solution is available in SuperMap SDX+. When branch versions are merged into the main version, modified data will be checked to see if it has been modified by other users and committed, if it is the case, which means the conflict exists, a warning message will appear and different modifications done to the same data will be compared visually, so that it will be easy for users to decide which branch version to save as the final result.
Long Transaction
A transaction in database management systems is defined as a series of operations executed by a single logical working unit; it refers to one or more database access operations (i.e. insertion, deletion, modification or retrieval of data). A single logical working unit should have the following properties: Atomicity, Consistency, Isolation and Durability, also known as ACID properties. Only with these properties, is it able to be a transaction.
Of the four properties of transaction, consistency and atomicity are mostly concerned about. Atomicity ensures every procedure is finished in a group. If one step fails, other steps will not start. This transaction mechanism is provided by DBMS, SuperMap supports this transaction mode, namely, short transaction mode. This mode has a wide application in ordinary DBMS, but GIS applications are different from ordinary DBMS applications in many aspects, for example, data size in a edit could be very large, usually the data of a region; duration for an editing process is long, may be a couple of days, months or even long time; other users are allowed to browse the data while one is editing and so on.
These features require GIS applications with specialized long transaction mechanism, SuperMap delivers this mechanism to GIS applications by taking advantage of merits of short transaction (ACID) while avoiding its limitations, and it has following characteristics:
◆ Some data from a layer can be locked for editing, other uses can only browse the previous data without editing the locked data;
◆ Long transaction can last for several days, months or even longer even if there encounters a power failure, system crash or other unforeseen accidents, the edited data will not be lost or damaged;
◆ Roll back all changes to original status if not satisfied with the modifications at any time;
◆ Once changes being committed, other users will get them updated immediately;
◆ Other users can only modify the data block which was locked before once it is committed or rolled back.
The Development of SuperMap SDX+
Spatial database engine is the core component of GIS platform software. SuperMap SDX+ previously focused on the implementation of a database engine while when it comes to SuperMap GIS 2008, the latest version of SDX+ has more functional extensions, adding brand new web service data engine and spatial engine in addition to existing database engine and file engine.
The database engine is based on relational database, such as Oracle, SQL Server, Sybase, DB2 and Kingbase etc.; file database refers to SDB and SIT; web service engine is able to get direct access to the data provided by standard web service protocol such as WFS, WMS etc., this kind of engine is to process all kinds of web service as SuperMap’s datasource, through which maps and data published by the web can be matched with the ones from SuperMap. SDX+ supports data formats of Oracle Spatial, ESRI ArcSDE and so on. If a spatial database is built based on other format standard, these formats can be directly accessed by SuperMap SDX+.
Through these engine extensions, industry-leading spatial information storage solutions can integrate with SuperMap to simplify end users’ operations as well as increase integrity and flexibility of GIS applications.
Figure 3 Datasource supported by SuperMap SDX+
Within SuperMap GIS 2008 products, new SuperMap SDX+ has been able to support WMS and WFS and Oracle Spatial. More OGC standard datasource and ESRI ArcSDE engine will be provided in later releases. Moreover, as an open source database, MySQL, has won a wide support from an increasing number of users. SuperMap will further support MySQL in future releases, too.
Through severe competition and continuous development, SuperMap SDX+ has become a key technology in SuperMap product family with many key technologies breakthroughs. However, it should be noted that SDX+ needs improving consistently with the rapid pace of IT development. It is expected that Version Management will be enhanced to improve implementation of long transaction and realize the unity of two lock modes of long transaction and version management. We are also committed to tracking popular database technologies in offline editing and distributed update functions, etc. |