[postgis-devel] Clarifying support of standards and specs
mateusz at loskot.net
Tue Dec 10 13:43:01 PST 2013
Recently, I have been reading through the recent OGC and SQL/MM,
sad me, and PostGIS docs, trying to understand things.
Apart from numerous confusing disjoint'ness between OGC and SQL/MM,
which I'm hopeless about getting clarified, I wonder if the PostGIS manual
could be updated to sound clearer on the standards the software supports.
For example, there are four parts which are unclear to me:
1) What does the superset mean in:
4.1. GIS Objects
The GIS objects supported by PostGIS are a superset
2) Which version of OGC SFS does this "only support 2d" refer to?
1.2. PostGIS EWKB, EWKT and Canonical Forms
OGC formats only support 2d geometries,
3) What does this sentence actually mean?
4.1.3. SQL-MM Part 3
The well-known text extensions are not yet fully supported.
4) Doesn't the Q&A below stay in contradiction with the "only support
2d" in case 2) above?
Or, what are the "extensions"?
FAQ 3.5. What kind of geometric objects can I store?
You can store point, line, polygon, multipoint, multiline,
multipolygon, and geometrycollections (...) These are specified in the
Open GIS Well Known Text Format (with XYZ,XYM,XYZM extensions).
Yet another example
4.1.2. PostGIS EWKB, EWKT and Canonical Forms
OGC formats only support 2d geometries (...)
PostGIS extended formats are currently superset of OGC (...)
MULTICURVE( (0 0, 5 5), CIRCULARSTRING(4 0, 4 4, 8 4) )
Now, given that the OGC SF 1.2+ specifies MultiCurve as an abstract type,
and SQL/MM makes it concrete, whichof the standards PostGIS EWKB/EWKT
actually extend here?
Basically, my question is, shouldn't the manual be more specific about
standard and version per feature?
If the answer is "No." and PostGIS stores/serves 'whatever' it is asked to,
leaving decisions such as about MultiCurve object is valid or not as
application-defined (PostGIS client decides) then please forget all my
I just would like to understand PostGIS position and strategy about it,
is that a documentation inaccuracy/lacking/error or a concious decision to
not to be too strict about that stuff.
Mateusz Łoskot, http://mateusz.loskot.net
More information about the postgis-devel