Spatial database data representation vs. spatial programistic libraries representation [closed]

Question

Can anyone tell me what is the difference between spatial database data representation and spatial programistic libraries representation?

It is not clear to me. I have tried to google it and I can not figure it out

Answer 1

If I understand your question correctly, you are asking about the differences between the representation of spatial data in a spatial database (e.g. PostGIS) versus the representation of spatial data in an abstraction layer or application programming interface (e.g. GeoAlchemy, GeoDjango)? The answer depends on the kinds of spatial database and abstraction that are used.

Commonly, spatial databases are relational databases that have been extended to store geospatial data. The nature of this extension in a database like PostGIS is the provision of new datatypes (geometry and geography types), a library of spatial accessor, constructor, and management functions, and spatial indexes. Spatial data are stored in a binary format as just another column in a table, with the attributes on those data stored in additional columns. Unlike the attribute tables in a GIS, it's possible for a table in a spatial database to have more than one column with spatial data.

The nature of the spatial programming library (abstraction layer) depends on the language used and the underlying paradigm of that language (e.g. object-oriented, declarative, imperative...). Many modern, high-level programming languages are object-oriented (e.g. Python, Ruby, JavaScript) and these are commonly used in spatial programming. In an object-oriented framework, spatial data are stored as attributes of objects. These objects therefore also have methods for acting on spatial and non-spatial data, sometimes changing the spatial data stored by that object (changing its state). These objects also have class relationships; defined behavior and interfaces for interaction with objects of different classes.

In the case of a relational spatial database and an object-oriented spatial programming library, one of the biggest differences that arises is described by object-relational impedance mismatch. A helpful, but not spatially-oriented introduction can be found here. As you'll read, there are important differences between how data are represented and accessed in a relational context versus an object-oriented context. Some programming libraries (like SQLAlchemy/GeoAlchemy) define the approach to resolve this mismatch as an Object-Relational Mapper (ORM). Some examples of these differences in a spatial application are:

• Many-to-many relationships are not natively supported in a relational context (a correspondence table is required) so spatial relationships like containment, mutual intersection are best calculated on the fly using spatial relationship functions.
• In a relational context, we SELECT spatial data and get back rows according to a rigid schema but these rows have no behavior on their own and no state, unlike objects. In spatial programming, libraries endow these "rows" with behavior by mapping them to a data model (class) and return them as objects (class instances).
• In an object context there are class attributes and there are instance attributes. Instance attributes (typically) contain the spatial data; would correspond to rows in the table. In a relational context, data either belong to the schema or they do not; there is no analogue of class attributes.

These considerations, of course, don't apply in all cases. You might use a completely different architecture for storing and accessing spatial data. Here is an article on choosing a spatial database that highlights some alternatives.