It should provide way to represent spatial phenomena in computer memory, allow to perform desired operation on this representation and let user see the results in form, he used to. Ideally, GIS system should hide complicated issues of internal data storage from user as well as text processor hides questions of font rendering or kerning or SQL database hides actual file layout and search technologies, providing simple, but powerful relational operations instead.
Many modern GIS systems, especially vector based, like ARC/Info, try to represent map of spatial phenomena rather than spatial phenomena itself. It leads to overcomplication of storage format and processing algorithms, and makes user worry about such technical things as polygon topology, which are completely irrelevant to his problem (say geology or soil science), as font rendering hints and kerning is irrelevant to contents of article, typesetted with some partcular font. Maps are tool for analyse spatial data, widely used, but no more than tool. GIS system should deal with them, becouse it is neccesary to use existing data, which are represented on maps, and present results to user in understandable form of maps, but while processing data we should take into account properties of actual phenomena, rather then properties of chartographic representation like polygons.
Layer values can be either real numbers or elements of some finite sets. If you want to study more complicated spatial phenomena, it is better to describe it as set of layers rather then individual layer with structured value. Obvoisly you'll not need values of all attributes in question for all desired calculations, and separating them makes your actions more clear.
Becouse layers are defined as functions it is theoretically possible to apply well develped mathematical apparatus of functional analysis to them.
(Raster is just big matrix of numeric values, stored in special format to reduce storage space. If raster is used in GIS processing, it should be known, how to find row and column numbers given real word coordinates and vice versa)
f(GIS) uses raster data format developed for EPPL7 GIS system. This format have several advantages - it is compressed and allows random access at the same time and it is able to deal with very fine resolution. For example Landscape map of exUSSR with spatial resolution (raster cell size) 500m and more than 3000 distinct kinds of landscapes occupies about 9MB of disk space. Due to such properties of data format, it is advisable to work with raster cell size significantly less then known accuracy of data. Resolution of maps can be compatible with resolution of your scanner and printer - modern processors are powerful enough to bear it, so raster doesn't mean loss of precession.
This data format is able to hold values in range 0..65535. While it is always sufficient for classification layers, it can look that for numeric layers it is better to use real numbers. But data always have finite accuracy, which is usially less than 1/65535 of total range, and even if we can take measurements with larger precession, we should take into account spatial variability within one raster cell.
For example, if we have map of relief of Russia with 500 meter cell, we need to represent range from -28 (Caspian coast) to 5642 (Elbrus) meters above sea level. Thus smallest usable unit is about 10 cm. Some points' altitude may be measured with more accuracy (for example, triangualtion points), but each raster cell represents 500x500 meters square which always would have more than 10cm of variability. Even if value of our layer should have more precession in some part of its range, we could use non-linear (for instance logarithmic) mapping of raster cell values to layer values.
But even with compression, raster files occupy significant storage space. So, we should avoid duplication of them if possible. Thus we introduce concept of reclass tables. Reclass table maps values of raster cell to another set of integer in arbitrary order. Don't mix reclass table with mapping function which is used for convert raster cell values to real units of numeric layer. For example if we have statistical data of populations by county and want to create population them as map, we can use reclass table over county map. Several counties with different names, which have distinct values in county map raster, can be mapped to same class in population density map if their population density is same.
Point layer is just list of triplets < X, Y, Value >. Typically point layer doesn't contain more than few thousands of points, so there is no need to optimize performance or storage space.
Natural storage form of one-dimensional layer is vector format. It is most questionable area in current fGIS design. There are a lot of advantages of EPPL7 vector format (compactness, speed of processing), but it have only one drawback, which overcomes them all - it can associate only one value with whole vector object (polyline). But if we are talking about the function, defined on set of lines, whe should be prepared that this function (stream depth for instance) would vary from one end of line to other.
It is also a question how intersections and joints of lines should be stored/interpreted, becouse most interesting network analysis algorithmes require ability to cross joints and intersections.
Each hierarchy level have its typical data accuracy (which is rough representation of map scale in GIS world, becouse GIS maps can be arbitrarily scaled, but only certain scale range make sense for particular data accuracy), chartographic projection (especially significant for large areas like whole country or continent). On thematic maps like soils or vegetation, different classifications can be used in different scales.
So, f(GIS) uses concept of regions. Region is set of layers, which cover almost same territory, have exactly same projection and simular spatial resolution. Regions can be nested, i.e. region of Russia can have several subregions of administrative regions, which have subregions of districts etc. In this case there should be base layer which have subregion names as values. When copiing data between regions f(GIS) authomatically performs neccessary projection and resolution conversion using base layer as reference. Classification conversion, if neccessary, should be performed by user, becouse it requires knowledge in problem area.
From users point of view, fGIS is Tcl application which allows him to operate with set of layers from GUI as well as from Tcl command line. It is essential design constraing that there should be no operation, which can be performed from GUI, but couldn't be from Tcl script. There should be way to automate everything. Other way around is enusred by very nature of Tcl. Nothing prevent user, which have direct access to Tcl interpreter from creating new button or menu item and binding any Tcl command to it.
From programmers point of view, fGIS consists of several abstraction levels, all available for extension and modification. And I think that every fGIS user can eventually become programmer, if he discoveres need to implement some, just invented, data analysis algorithm, or customize graphical user interface to his needs. Relationship between fGIS abstraction levels is shown on this figure.
Layer have following properties
Planchet also have look feature. If right mouse button is pressed on some point in planchet, it displays values of several layers in this point in pop-up window.
There can be also "friend widgets" like status line which display current coordinates if mouse is over planchet or zoom/unzoom buttons which change its state depending of current state of planchet.
Example of such procedure is interregion copy command, which tooks layer name and name of target region, determines projections and calls projection conversion program.
In some cases such procedures need to perform sufficient preprocessing of user-supplied arguments