Scribd
Upload
15 views

4.2.3 Geography Advanced Faq: 4.3 Using Opengis Standards

This document discusses projections and geography data types in PostGIS. It explains that GEOGRAPHY is best for global or continental data that doesn't require projections, while GEOMETRY works better for smaller areas where projections can be used. It also provides background on the SPATIAL_REF_SYS table, which contains spatial reference system definitions, and the OpenGIS standards that PostGIS implements.

Uploaded by

Mathias Eder
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
15 views

4.2.3 Geography Advanced Faq: 4.3 Using Opengis Standards

This document discusses projections and geography data types in PostGIS. It explains that GEOGRAPHY is best for global or continental data that doesn't require projections, while GEOMETRY works better for smaller areas where projections can be used. It also provides background on the SPATIAL_REF_SYS table, which contains spatial reference system definitions, and the OpenGIS standards that PostGIS implements.

Uploaded by

Mathias Eder
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

PostGIS 1.5.

1 Manual
19 / 315

If your data is contained in a small area, you might find that choosing an appropriate projection and using GEOMETRY is the
best solution, in terms of performance and functionality available.
If your data is global or covers a continental region, you may find that GEOGRAPHY allows you to build a system without
having to worry about projection details. You store your data in longitude/latitude, and use the functions that have been defined
on GEOGRAPHY.
If you dont understand projections, and you dont want to learn about them, and youre prepared to accept the limitations in
functionality available in GEOGRAPHY, then it might be easier for you to use GEOGRAPHY than GEOMETRY. Simply load
your data up as longitude/latitude and go from there.
Refer to Section 8.8 for compare between what is supported for Geography vs. Geometry. For a brief listing and description of
Geography functions, refer to Section 8.3

4.2.3 Geography Advanced FAQ


1. Do you calculate on the sphere or the spheroid?
By default, all distance and area calculations are done on the spheroid. You should find that the results of calculations in
local areas match up will with local planar results in good local projections. Over larger areas, the spheroidal calculations
will be more accurate than any calculation done on a projected plane. All the geography functions have the option of
using a sphere calculation, by setting a final boolean parameter to FALSE. This will somewhat speed up calculations,
particularly for cases where the geometries are very simple.
2. What about the date-line and the poles?
All the calculations have no conception of date-line or poles, the coordinates are spherical (longitude/latitude) so a shape
that crosses the dateline is, from a calculation point of view, no different from any other shape.
3. What is the longest arc you can process?
We use great circle arcs as the "interpolation line" between two points. That means any two points are actually joined up
two ways, depending on which direction you travel along the great circle. All our code assumes that the points are joined
by the *shorter* of the two paths along the great circle. As a consequence, shapes that have arcs of more than 180 degrees
will not be correctly modelled.
4. Why is it so slow to calculate the area of Europe / Russia / insert big geographic region here ?
Because the polygon is so darned huge! Big areas are bad for two reasons: their bounds are huge, so the index tends to pull
the feature no matter what query you run; the number of vertices is huge, and tests (distance, containment) have to traverse
the vertex list at least once and sometimes N times (with N being the number of vertices in the other candidate feature).
As with GEOMETRY, we recommend that when you have very large polygons, but are doing queries in small areas, you
"denormalize" your geometric data into smaller chunks so that the index can effectively subquery parts of the object and
so queries dont have to pull out the whole object every time. Just because you *can* store all of Europe in one polygon
doesnt mean you *should*.

4.3 Using OpenGIS Standards


The OpenGIS "Simple Features Specification for SQL" defines standard GIS object types, the functions required to manipulate
them, and a set of meta-data tables. In order to ensure that meta-data remain consistent, operations such as creating and removing
a spatial column are carried out through special procedures defined by OpenGIS.
There are two OpenGIS meta-data tables: SPATIAL_REF_SYS and GEOMETRY_COLUMNS. The SPATIAL_REF_SYS table
holds the numeric IDs and textual descriptions of coordinate systems used in the spatial database.

PostGIS 1.5.1 Manual


20 / 315

4.3.1 The SPATIAL_REF_SYS Table and Spatial Reference Systems


The spatial_ref_sys table is a PostGIS included and OGC compliant database table that lists over 3000 known spatial reference
systems and details needed to transform/reproject between them.
Although the PostGIS spatial_ref_sys table contains over 3000 of the more commonly used spatial reference system definitions
that can be handled by the proj library, it does not contain all known to man and you can even define your own custom projection
if you are familiar with proj4 constructs. Keep in mind that most spatial reference systems are regional and have no meaning
when used outside of the bounds they were intended for.
An excellent resource for finding spatial reference systems not defined in the core set is http://spatialreference.org/
Some of the more commonly used spatial reference systems are: 4326 - WGS 84 Long Lat, 4269 - NAD 83 Long Lat, 3395 WGS 84 World Mercator, 2163 - US National Atlas Equal Area, Spatial reference systems for each NAD 83, WGS 84 UTM
zone - UTM zones are one of the most ideal for measurement, but only cover 6-degree regions.
Various US state plane spatial reference systems (meter or feet based) - usually one or 2 exists per US state. Most of the meter
ones are in the core set, but many of the feet based ones or ESRI created ones you will need to pull from spatialreference.org.
For details on determining which UTM zone to use for your area of interest, check out the utmzone PostGIS plpgsql helper
function.
The SPATIAL_REF_SYS table definition is as follows:
CREATE TABLE
srid
auth_name
auth_srid
srtext
proj4text
)

spatial_ref_sys (
INTEGER NOT NULL PRIMARY KEY,
VARCHAR(256),
INTEGER,
VARCHAR(2048),
VARCHAR(2048)

The SPATIAL_REF_SYS columns are as follows:


SRID An integer value that uniquely identifies the Spatial Referencing System (SRS) within the database.
AUTH_NAME The name of the standard or standards body that is being cited for this reference system. For example, "EPSG"
would be a valid AUTH_NAME.
AUTH_SRID The ID of the Spatial Reference System as defined by the Authority cited in the AUTH_NAME. In the case of
EPSG, this is where the EPSG projection code would go.
SRTEXT The Well-Known Text representation of the Spatial Reference System. An example of a WKT SRS representation is:
PROJCS["NAD83 / UTM Zone 10N",
GEOGCS["NAD83",
DATUM["North_American_Datum_1983",
SPHEROID["GRS 1980",6378137,298.257222101]
],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]
],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-123],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",0],
UNIT["metre",1]
]

For a listing of EPSG projection codes and their corresponding WKT representations, see http://www.opengeospatial.org/.
For a discussion of WKT in general, see the OpenGIS "Coordinate Transformation Services Implementation Specification"
at http://www.opengeospatial.org/standards. For information on the European Petroleum Survey Group (EPSG) and their
database of spatial reference systems, see http://www.epsg.org.

You might also like