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
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It only takes a minute to sign up.Sign up to join this community
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 (
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.
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:
SELECTspatial 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).
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.