Geometry
Top Level Geometry
Simple geometries are not dicussed in this section
Top level geometry (TLG), such as point, chain and area, is stored in references to underlying topology data. Each top level geometry defined in data model with a manifold. With that manifold information underlying topology data (links and nodes) are created when you insert a TLG. The TLG simply points to that underlying topology data. So for example you create a simple 3 vertex chain in the middle of nowhere. What happens is a link is created using those 3 vertices. The end vertices are also created as nodes. Then, the chain is created referencing that new link. So in essence 4 objects are created in the database, 2 nodes, 1 link and 1 chain.
Things get more complicated when you have topological interactions when inserting new features. A chain could point to more than one link based upon the manifold interaction definitions (rules). What is cool about this geometry model is the fact the actual TLG is not stored but referenced, so you don't have duplicate information in the database. Also this allows you to manipulate the link itself and all referenced TLGs are automatically updated. This makes editing shared geometries much simpler. FCSI [http://www.field-csi.com] has developed topology editing tools that takes advantage of this. Other companies may have similar products.
More info can be seen in the Core HTML Help Documentation under Geometry->Working with Geometry
Geometry Priority
Geometry fields have a priority field on the CASE field. This priority allows you to more efficiently retrieve geometries out of the database. They are typically an 8 bit value (defaulting to 0). You will want to organize your geometries to be evenly distributed. This is especially for point and text geometries. Since the bounding boxes of points and geometries are small, the priority is really the best way organize them for fast database scans.
Here is how you determine your current priority information. More information can be found in swcdbase.chm Database: Database->Creation and Restructuring->7.1 Analysing and updating geometry priorities
sw_module_manager.load_module(:priority_analyser)
$
pa << priority_analyser.new()
$
pa.analyse_ace_and_report("C:\temp\priorities.txt")
Z values
As with most GIS systems, Smallworld does not store true 3D coordinates. They are actually attributed deep inside database. The 3D coordinate appears to be actually constructed when you query the geometry's sectors.
The tables (collections) that are used are "bucket" tables in the view. Some examples are :sw_gis!simple_area_float_bucket and :sw_gis!link_float_bucket. An interesting thing to note is that Points really don't store 3D directory. They are referenced from the underlying link data. Another interesting thing to note is the fact there are 4 floats stored on the bucket tables. Why??? I wonder if we could use it for some additional dimensions….
What is a Consistency Root?
Mike Cousins had a good example of an object that would be a consistency root. A transformer that hasn't been installed could be considered as consistency root. Where an installed transformer may not be and the consistency root would be the another object that the transformer is connected to thru topology or join.
What is a Consistency Root used for?
<needs info>
Raster Compressions
From my experience, the byte_plane_rle is the best all around compression option I use. I use it for full color imagery and DEMs. Here are some compression results. DEM gets about 2.45, and full color imagery gets about 1.25. With current computer technology, I don't find any performance hits using this compression… Anny thoughts?
