|DBMS||Binary size||Brief description|
|It claims to be "The world's most advanced open source database",
and that's simply the truth.
Not very user friendly (may cause you some headache when you'll try to install and configure it at first time), but surely a very complete and impressive full ACID DBMS.
The PostGIS add-on on its own implements a full set of Spatial features (OGC certified); whatever kind of GIS operation you need, PostGIS can support you in an useful way and without dimensional limits.
If you are seriously looking for a complete and unrestricted GIS support, and you aren't frightened at all about managing and caring a very sophisticated DBMS, as powerful as complex, PostgreSQL + PostGis is just what you need.
|MySQL Spatial||42 MB||It claims to be "The world's most popular open source database",
and this too is simply the truth.
Reasonably easy to use, very fast, decently simple to manage; not surprisingly it's the preferred choice for so many WEB developers.
Often criticized for not being completely conformant to SQL standards, supports a wide set (sometimes puzzling too wide) of data engines.
MySql's Spatials enable you to manage in a very effective way GIS data; it's a pity that you can create a spatial index only if you are using MyISAM tables, that aren't neither transactional nor ACIDs. You can use Spatial data in InnoDB tables as well (full ACIDs), but in this case you cannot have spatial indexes.
Anyway, if you are looking for a DMBS able to effectively support WEB publishing of very large amounts of GIS data, and aren't worried to use a non-ACID DBMS (e.g. because you are publishing cold data, i.e. replicated data coming out from some other source), you can be very satisfied with MySQL Spatial.
|A very light weighted DBMS; it doesn't pretends to be,
but perhaps it is "The world's smallest and simplest database".
As the aforementioned two tends to be vast and complex, as SQLite tends to be simple.
But simplicity does not always means incompleteness; not in this case, at least.
SpatiaLite offers you the option to enable the SQLite DBMS to support a decent and standard-conformant environment for Spatial data as well.
It doesn't pretends at all to be better, or fastest, or most powerful than others; most humbly, it just pretends to be simple, light weighted and reasonably useful.
SpatiaLite does not implements any kind of spatial index, mainly because SQLite in its own does not supports R-trees, but only B-trees. Please note well that this one may be a severe limitation, if you need to fastly access a very large data set by using some spatial selection criterion; but if yours data sets are not too large [less than 10.000 rows, just to fix an arbitrary limit] lacking of any kind of spatial index may be practically unnoticed.
If you are looking for an elementary simple-to-manage GIS environment, without frills and undue complexity, and if your have to manage only small- or medium-sized GIS data, SQLite and SpatiaLite can make you feel very happy [I hope so, at least ...]
|0||START [hex 00]||a GEOMETRY encoded BLOB value must always start with a 0x00 byte|
[hex 00 or hex 01]
|if this GEOMETRY is BIG_ENDIAN ordered must contain a 0x00 byte value
otherwise, if this GEOMETRY is LITTLE_ENDIAN ordered must contain a 0x01 byte value
Any other value [neither 0x00 nor 0x01], means that this BLOB cannot be a valid GEOMETRY
|2 - 5||SRID||a 32-bits integer value [little-
big-endian ordered, accordingly with the precedent one]
corresponding to the SRID for this GEOMETRY
|6 - 13||MBR_MIN_X||a double value [little-
big-endian ordered, accordingly with the precedent one]
corresponding to the MBR minimum X coordinate for this GEOMETRY
|14 - 21||MBR_MIN_Y||a double value corresponding to the MBR minimum Y coordinate|
|22 - 29||MBR_MAX_X||a double value corresponding to the MBR maximum X coordinate|
|30 - 37||MBR_MAX_Y||a double value corresponding to the MBR maximum Y coordinate|
|38||MBR_END [hex 7C]||a GEOMETRY encoded BLOB value must always have an 0x7C byte in this position|
|39 - 42||CLASS TYPE||a 32-bits integer; must identify a valid WKB class, i.e.
|43 - ...||geometry class specific||length and content depends on geometry class [POINT, LINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION etc]|
|LAST||END [hex FE]||a GEOMETRY encoded BLOB value must always end with a 0xFE byte|
|0||ENTITY [hex 69]||a GEOMETRY encoded BLOB value must always have an 0x69 byte in this position|
|1 - 4||CLASS TYPE||a 32-bits integer; must identify a valid WKB class that can be included within a collection, i.e.
|5 - ...||geometry class specific||Length and content depends on geometry class [POINT, LINESTRING or POLYGON]|
|The shapefile format is defined by ESRI and is very widely used in GIS, mainly because it is defined as an open and publicly documented format. You can find a copy of the ESRI specification at http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf. If you are interested in this argument, you can usefuly read this article: http://en.wikipedia.org/wiki/Shapefile|
|Basically, as a short reference, shapefile consists of three individual files
in the same directory:
Always remember that a shapefile is valid (i.e. can be accessed) only if all three components are accessible. As an addition precaution you should be very careful when handling upper- and lower-case paths.
Too often, a shapefile that mysteriously refuses to open under Linux but works on Windows has components path as the following ones:
|Each coordinate value, to be fully qualified, needs to be explicitly assigned to some SRID,
or Spatial Reference Identifier.
This value identifies the geometry's associated Spatial Reference System that describes the coordinate space in which the geometry object is defined.
As a general rule, different geometries can interoperate in a meaningful way only if their coordinates are expressed in the same Coordinate Reference System.
GIS data coming from different sources can easily use different Coordinate Reference Systems, so very often some kind of coordinate reprojection is required in order to transform them in an unique, homogeneous, Coordinate Reference System and thus allowing interoperation and integration.
The PROJ.4 library supports a large set of methods to compute coordinate reprojection between different Coordinate Reference Systems.
The PROJ.4 library are the de facto standard for this kind of task, widely used by the vast majority of GIS software.
The EPSG [European Petroleum Survey Group] on its own maintains and distributes a large dataset of geodetic parameters describing quite any Coordinate Reference System and Coordinate Transformation used worldwide for GIS data.
Putting all together, we can assume that:
To enable this option you need as a prerequisite that the SQLite database file you intend to work with contains an epsg table
So you have to:
sqlite> .read epsg-sqlite.sql