SAIF supports the notion of object sharing. If for example an arc serves as part of the boundary of two polygons, it may be specified once and given an identifier value, and then referenced by the identifer when the polygons are defined. In this way the arc is shared by the two polygons. Other objects in SAIF may be shared in a similar fashion. By itself however, SAIF does not enforce sharing. The common arc need not be identified explicitly; instead, the values constituting the arc can be embedded directly in the data description for each polygon. Other major options related to data structuring and representation must also be considered. SAIF for example can represent forest cover in a polygonal form, or alternatively in a raster form. In the latter case, SAIF supports quadtree and run length encoding indexing schemes. Thus similar kinds of data could be placed in SAIF in quite different ways.
Similarly, features may be defined in ways which conflict semantically: one user may define lakes, bogs, fens, and swamps, while another user may define water bodies and wetlands, without any clear correspondence between the two sets of definitions. One user may include slope as an attribute, based on a given formula and transformed into a categorical value; another user may treat slope as a continuous value derived from another formula.
A decision to use SAIF will help identify the specific nature of such inconsistencies and facilitate their resolution. Additionally, procedures can be defined to ensure adherence to very strict ways of using SAIF, such as limiting the types of geometry which may be used.
If a central authority wishes to enforce a particular way of handling certain types of data, this may be done through the development of a schema, as described earlier. Two or more schemas may form a federated schema if the class definitions are harmonized so as to eliminate unwarranted or undesirable differences in meaning and structure. SAIF can be used effectively to help support the development of such federations.