[postgis-tickets] r15990 - More cleanup. Get rid of word "new" in reference to geography type, it's not so new anymore
Regina Obe
lr at pcorp.us
Mon Oct 16 02:32:37 PDT 2017
Author: robe
Date: 2017-10-16 02:32:37 -0700 (Mon, 16 Oct 2017)
New Revision: 15990
Modified:
trunk/doc/using_postgis_dataman.xml
Log:
More cleanup. Get rid of word "new" in reference to geography type, it's not so new anymore
Minor grammar and formatting corrections.
References #3902 for PostGIS 2.5.0
Modified: trunk/doc/using_postgis_dataman.xml
===================================================================
--- trunk/doc/using_postgis_dataman.xml 2017-10-16 09:00:02 UTC (rev 15989)
+++ trunk/doc/using_postgis_dataman.xml 2017-10-16 09:32:37 UTC (rev 15990)
@@ -276,23 +276,22 @@
<para>Because the underlying mathematics is much more complicated, there are fewer functions defined for the geography type than for the geometry type. Over time, as new algorithms are added, the capabilities of the geography type will expand.</para>
- <para>It uses a new data type called
- geography. None of the GEOS functions support this new
+ <para>It uses a data type called <varname>geography</varname>. None of the GEOS functions support the <varname>geography</varname>
type. As a workaround one can convert back and forth between geometry and geography types.</para>
<para>Prior to PostGIS 2.2, the geography type only supported WGS 84 long lat (SRID:4326).
For PostGIS 2.2 and above, any long/lat based spatial reference system defined in the <varname>spatial_ref_sys</varname> table can be used.
- You can even add your own custom spheroidal spatial refence system as described in <ulink url="http://www.bostongis.com/blog/index.php?/archives/266-geography-type-is-not-limited-to-earth.html">geography type is not limited to earth</ulink></para>
+ You can even add your own custom spheroidal spatial refence system as described in <ulink url="http://www.bostongis.com/blog/index.php?/archives/266-geography-type-is-not-limited-to-earth.html">geography type is not limited to earth</ulink>.</para>
- <para>Regardless which spatial reference system you use, the units returned by the measurement (<xref linkend="ST_Distance" />, <xref linkend="ST_Length" />, <xref linkend="ST_Perimeter" />, <xref linkend="ST_Area" />) and for input of for input of <xref linkend="ST_DWithin" /> are in meters.</para>
+ <para>Regardless which spatial reference system you use, the units returned by the measurement (<xref linkend="ST_Distance" />, <xref linkend="ST_Length" />, <xref linkend="ST_Perimeter" />, <xref linkend="ST_Area" />) and for input of <xref linkend="ST_DWithin" /> are in meters.</para>
- <para>The new geography type uses the PostgreSQL 8.3+ typmod definition format so that a table with a geography field
+ <para>The geography type uses the PostgreSQL 8.3+ typmod definition format so that a table with a geography field
can be added in a single step. All the standard OGC formats except for curves are supported.</para>
<sect2 id="Geography_Basics">
<title>Geography Basics</title>
- <para>The geography type only supports the simplest of simple features. Standard geometry type data will autocast to geography if it is of SRID 4326. You can also use the EWKT and EWKB
+ <para>The geography type does not support curves, TINS, or POLYHEDRALSURFACEs, but other geometry types are supported. Standard geometry type data will autocast to geography if it is of SRID 4326. You can also use the EWKT and EWKB
conventions to insert data.</para>
<itemizedlist>
@@ -327,7 +326,7 @@
</listitem>
<!-- TODO: Add other examples -->
</itemizedlist>
- <para>The new geography fields don't get registered in the <varname>geometry_columns</varname>. They get registered in a new view called
+ <para>The geography fields don't get registered in the <varname>geometry_columns</varname>. They get registered in a view called
<varname>geography_columns</varname> which is a view against the system catalogs so is always automatically kept up to date without need
for an AddGeom... like function.</para>
@@ -372,7 +371,7 @@
SELECT name FROM global_points WHERE ST_DWithin(location, ST_GeogFromText('SRID=4326;POINT(-110 29)'), 1000000);</programlisting>
</para>
-<para>You can see the power of GEOGRAPHY in action by calculating the how close a plane flying from Seattle to London (LINESTRING(-122.33 47.606, 0.0 51.5)) comes to Reykjavik (POINT(-21.96 64.15)).</para>
+<para>You can see the power of GEOGRAPHY in action by calculating how close a plane flying from Seattle to London (LINESTRING(-122.33 47.606, 0.0 51.5)) comes to Reykjavik (POINT(-21.96 64.15)).</para>
<para><programlisting>-- Distance calculation using GEOGRAPHY (122.2km)
SELECT ST_Distance('LINESTRING(-122.33 47.606, 0.0 51.5)'::geography, 'POINT(-21.96 64.15)':: geography);</programlisting>
@@ -382,28 +381,28 @@
SELECT ST_Distance('LINESTRING(-122.33 47.606, 0.0 51.5)'::geometry, 'POINT(-21.96 64.15)':: geometry);</programlisting>
</para>
-<para>-- Testing different lon/lat projects, requires PostGIS 2.2+.
--- Any long lat spatial reference system in spatial_ref_sys table is allowed.
+<para>Testing different lon/lat projects, requires PostGIS 2.2+.
+Any long lat spatial reference system listed in <varname>spatial_ref_sys</varname> table is allowed.</para>
<programlisting>-- NAD 83 lon/lat
-SELECT 'SRID=4269;POINT(-123 34)'::geography;</programlisting>
-<screen> geography
+SELECT 'SRID=4269;POINT(-123 34)'::geography;
+ geography
----------------------------------------------------
0101000020AD1000000000000000C05EC00000000000004140
-(1 row)</screen>
+(1 row)</programlisting>
<programlisting>-- NAD27 lon/lat
-SELECT 'SRID=4267;POINT(-123 34)'::geography;</programlisting>
+SELECT 'SRID=4267;POINT(-123 34)'::geography;
-<screen> geography
+ geography
----------------------------------------------------
0101000020AB1000000000000000C05EC00000000000004140
-(1 row)</screen>
+(1 row)</programlisting>
<programlisting>-- NAD83 UTM zone meters, yields error since its a meter based projection
-SELECT 'SRID=26910;POINT(-123 34)'::geography;</programlisting>
+SELECT 'SRID=26910;POINT(-123 34)'::geography;
-<screen>ERROR: Only lon/lat coordinate systems are supported in geography.
-LINE 1: SELECT 'SRID=26910;POINT(-123 34)'::geography;</screen>
+ERROR: Only lon/lat coordinate systems are supported in geography.
+LINE 1: SELECT 'SRID=26910;POINT(-123 34)'::geography;</programlisting>
</para>
<para>The GEOGRAPHY type calculates the true shortest distance over the sphere between Reykjavik and the great circle flight path between Seattle and London.</para>
@@ -413,7 +412,7 @@
</sect2>
<sect2 id="PostGIS_GeographyVSGeometry">
<title>When to use Geography Data type over Geometry data type</title>
- <para>The new GEOGRAPHY type allows you to store data in longitude/latitude coordinates, but at a cost: there are fewer functions defined on GEOGRAPHY than there are on GEOMETRY; those functions that are defined take more CPU time to execute.</para>
+ <para>The geography type allows you to store data in longitude/latitude coordinates, but at a cost: there are fewer functions defined on GEOGRAPHY than there are on GEOMETRY; those functions that are defined take more CPU time to execute.</para>
<para>The type you choose should be conditioned on the expected working area of the application you are building. Will your data span the globe or a large continental area, or is it local to a state, county or municipality? </para>
<itemizedlist>
<listitem><para>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.</para></listitem>
More information about the postgis-tickets
mailing list