<para>OpenGeo has a step by step tutorial guide workshop <ulinkurl="http://workshops.boundlessgeo.com/postgis-intro/">Introduction to PostGIS</ulink>. It includes packaged data as well as intro to working with OpenGeo Suite. It is probably the best tutorial on PostGIS.</para>
<para>BostonGIS also has a <ulinkurl="http://www.bostongis.com/PrinterFriendly.aspx?content_name=postgis_tut01">PostGIS almost idiot's guide on getting started</ulink>. That one is more focused on the windows user.</para>
<para>My applications and desktop tools worked with PostGIS 1.5,but they don't work with PostGIS 2.0. How do I fix this?</para>
</question>
<answer>
<para>A lot of deprecated functions were removed from the PostGIS code base in PostGIS 2.0. This has affected applications in addition to third-party tools such as
Geoserver, MapServer, QuantumGIS, and OpenJump to name a few. There are a couple of ways to resolve this. For the third-party apps, you can try to upgrade to the latest versions
of these which have many of these issues fixed. For your own code, you can change your code to not use the functions removed. Most of these functions are non ST_ aliases of ST_Union, ST_Length etc.
<para>The <varname>legacy.sql</varname> file is located in the same folder as postgis.sql. You can install this file after you have installed postgis.sql and spatial_ref_sys.sql
<para>In PostGIS 2, the default geometry operator class gist_geometry_ops was changed to gist_geometry_ops_2d and the gist_geometry_ops was completely removed. This was done because PostGIS 2 also introduced Nd spatial indexes for 3D support and the old name was deemed confusing and a misnomer.</para>
<para>Some older applications that as part of the process create tables and indexes, explicitly referenced the operator class name. This was unnecessary if you want the default 2D index. So if you manage said good, change index creation from:</para>
<para>BAD:</para>
<programlisting>CREATE INDEX idx_my_table_geom ON my_table USING gist(geom gist_geometry_ops);</programlisting>
<para>To GOOD:</para>
<programlisting>CREATE INDEX idx_my_table_geom ON my_table USING gist(geom);</programlisting>
<para>The only case where you WILL need to specify the operator class is if you want a 3D spatial index as follows:</para>
<programlisting>CREATE INDEX idx_my_super3d_geom ON my_super3d USING gist(geom gist_geometry_ops_nd);</programlisting>
<para>If you are unfortunate to be stuck with compiled code you can't change that has the old gist_geometry_ops hard-coded, then you can create the old class using the <filename>legacy_gist.sql</filename> packaged in PostGIS 2.0.2+. However if you use this fix, you are advised to at a later point drop the index and recreate it without the operator class. This will save you grief in the future when you need to upgrade again.</para>
<para>In PostgreSQL 9.0+, the default encoding for bytea data has been changed to hex and older JDBC drivers still assume escape format. This has affected some applications
<para>If you are running a .NET app, you can use Npgsql 2.0.11 or higher which you can download from
<ulinkurl="http://pgfoundry.org/frs/?group_id=1000140">http://pgfoundry.org/frs/?group_id=1000140</ulink> and
as described on <ulinkurl="http://fxjr.blogspot.com/2010/11/npgsql-2011-released.html">Francisco Figueiredo's NpgSQL 2.0.11 released blog entry</ulink></para>
<para>If upgrading your PostgreSQL driver is not an option, then you can set the default back to the old behavior with the following change:</para>
multipolygon, and geometrycollections. In PostGIS 2.0 and above you can also store TINS and Polyhedral Surfaces in the basic geometry type.
These are specified in the Open
GIS Well Known Text Format (with XYZ,XYM,XYZM extensions). There are three data types currently supported.
The standard OGC geometry data type which uses a planar coordinate system for measurement, the
geography data type which uses a geodetic coordinate system (not OGC, but you'll find a similar type in Microsoft SQL Server 2008+). Only WGS 84 long lat (SRID:4326) is supported
by the geography data type. The newest family member of the PostGIS spatial type family is raster for storing and analyzing raster data. Raster has its very own FAQ. Refer to <xreflinkend="RT_FAQ"/>
and <xreflinkend="RT_reference"/> for more details.</para>
where all your data fits in a single <linklinkend="spatial_ref_sys">spatial reference system (SRID)</link>, or you need to do a lot of spatial processing.
Long Answer: Refer to our more lengthy discussion in the <xreflinkend="PostGIS_GeographyVSGeometry"/> and <linklinkend="PostGIS_TypeFunctionMatrix">function type matrix</link>.
<para>I have more intense questions about geography, such as how big of a geographic region can I stuff in a geography column and
still get reasonable answers. Are there limitations such as poles, everything in the field must fit in a hemisphere (like SQL Server 2008 has), speed etc?</para>
</question>
<answer>
<para>Your questions are too deep and complex to be adequately answered in this section. Please refer to our
<para>I am releasing software that uses PostGIS, does that mean my software has to be licensed using the GPL like PostGIS? Will I have to publish all my code if I use PostGIS?</para>
</question>
<answer>
<para>Almost certainly not. As an example, consider Oracle database running on Linux. Linux is GPL, Oracle is not, does Oracle running on Linux have to be distributed using the GPL? No. So your software can use a PostgreSQL/PostGIS database as much as it wants and be under any license you like.</para>
<para>The only exception would be if you made changes to the PostGIS source code, and distributed your changed version of PostGIS. In that case you would have to share the code of your changed PostGIS (but not the code of applications running on top of it). Even in this limited case, you would still only have to distribute source code to people you distributed binaries to. The GPL does not require that you <emphasis>publish</emphasis> your source code, only that you share it with people you give binaries to.</para>