# SOME DESCRIPTIVE TITLE.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2012-09-14 17:50+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <kde-i18n-doc@kde.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Tag: title
#: faq.xml:3
#, no-c-format
msgid "PostGIS Frequently Asked Questions"
msgstr ""

#. Tag: para
#: faq.xml:8
#, no-c-format
msgid "My applications and desktop tools worked with PostGIS 1.5,but they don't work with PostGIS 2.0. How do I fix this?"
msgstr ""

#. Tag: para
#: faq.xml:12
#, no-c-format
msgid "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. and as a last resort, install the whole of <varname>legacy.sql</varname> or just the portions of <varname>legacy.sql</varname> you need."
msgstr ""

#. Tag: para
#: faq.xml:18
#, no-c-format
msgid "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 to get back all the 200 some-odd old functions we removed."
msgstr ""

#. Tag: para
#: faq.xml:24
#, no-c-format
msgid "I'm running PostgreSQL 9.0 and I can no longer read/view geometries in OpenJump, Safe FME, and some other tools?"
msgstr ""

#. Tag: para
#: faq.xml:28
#, no-c-format
msgid "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 such as Java applications using older JDBC drivers or .NET applications that use the older npgsql driver that expect the old behavior of ST_AsBinary. There are two approaches to getting this to work again."
msgstr ""

#. Tag: para
#: faq.xml:32
#, no-c-format
msgid "You can upgrade your JDBC driver to the latest PostgreSQL 9.0 version which you can get from <ulink url=\"http://jdbc.postgresql.org/download.html\">http://jdbc.postgresql.org/download.html</ulink>"
msgstr ""

#. Tag: para
#: faq.xml:34
#, no-c-format
msgid "If you are running a .NET app, you can use Npgsql 2.0.11 or higher which you can download from <ulink url=\"http://pgfoundry.org/frs/?group_id=1000140\">http://pgfoundry.org/frs/?group_id=1000140</ulink> and as described on <ulink url=\"http://fxjr.blogspot.com/2010/11/npgsql-2011-released.html\">Francisco Figueiredo's NpgSQL 2.0.11 released blog entry</ulink>"
msgstr ""

#. Tag: para
#: faq.xml:38
#, no-c-format
msgid "If upgrading your PostgreSQL driver is not an option, then you can set the default back to the old behavior with the following change:"
msgstr ""

#. Tag: programlisting
#: faq.xml:39
#, no-c-format
msgid "ALTER DATABASE mypostgisdb SET bytea_output='escape';"
msgstr ""

#. Tag: para
#: faq.xml:46
#, no-c-format
msgid "I tried to use PgAdmin to view my geometry column and it is blank, what gives?"
msgstr ""

#. Tag: para
#: faq.xml:50
#, no-c-format
msgid "PgAdmin doesn't show anything for large geometries. The best ways to verify you do have data in your geometry columns are?"
msgstr ""

#. Tag: programlisting
#: faq.xml:53
#, no-c-format
msgid ""
      "-- this should return no records if all your geom fields are filled in        \n"
      "SELECT somefield FROM mytable WHERE geom IS NULL;"
msgstr ""

#. Tag: programlisting
#: faq.xml:55
#, no-c-format
msgid ""
      "-- To tell just how large your geometry is do a query of the form\n"
      "--which will tell you the most number of points you have in any of your geometry columns\n"
      "SELECT MAX(ST_NPoints(geom)) FROM sometable;"
msgstr ""

#. Tag: para
#: faq.xml:61
#, no-c-format
msgid "What kind of geometric objects can I store?"
msgstr ""

#. Tag: para
#: faq.xml:65
#, no-c-format
msgid "You can store point, line, polygon, multipoint, multiline, 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 <xref linkend=\"RT_FAQ\"/> and <xref linkend=\"RT_reference\"/> for more details."
msgstr ""

#. Tag: para
#: faq.xml:78
#, no-c-format
msgid "I'm all confused. Which data store should I use geometry or geography?"
msgstr ""

#. Tag: para
#: faq.xml:82
#, no-c-format
msgid "Short Answer: geography is a new data type that supports long range distances measurements, but most computations on it are currently slower than they are on geometry. If you use geography -- you don't need to learn much about planar coordinate systems. Geography is generally best if all you care about is measuring distances and lengths and you have data from all over the world. Geometry data type is an older data type that has many more functions supporting it, enjoys greater support from third party tools, and operations on it are generally faster -- sometimes as much as 10 fold faster for larger geometries. Geometry is best if you are pretty comfortable with spatial reference systems or you are dealing with localized data where all your data fits in a single <link linkend=\"spatial_ref_sys\">spatial reference system (SRID)</link>, or you need to do a lot of spatial processing. Note: It is fairly easy to do one-off conversions between the two types to gain the benefits of each. Refer to <xref linkend=\"PostGIS_TypeFunctionMatrix\"/> to see what is currently supported and what is not."
msgstr ""

#. Tag: para
#: faq.xml:93
#, no-c-format
msgid "Long Answer: Refer to our more lengthy discussion in the <xref linkend=\"PostGIS_GeographyVSGeometry\"/> and <link linkend=\"PostGIS_TypeFunctionMatrix\">function type matrix</link>."
msgstr ""

#. Tag: para
#: faq.xml:101
#, no-c-format
msgid "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?"
msgstr ""

#. Tag: para
#: faq.xml:105
#, no-c-format
msgid "Your questions are too deep and complex to be adequately answered in this section. Please refer to our <xref linkend=\"PostGIS_Geography_AdvancedFAQ\"/>."
msgstr ""

#. Tag: para
#: faq.xml:112
#, no-c-format
msgid "How do I insert a GIS object into the database?"
msgstr ""

#. Tag: para
#: faq.xml:116
#, no-c-format
msgid "First, you need to create a table with a column of type \"geometry\" or \"geography\" to hold your GIS data. Storing geography type data is a little different than storing geometry. Refer to <xref linkend=\"Geography_Basics\"/> for details on storing geography."
msgstr ""

#. Tag: para
#: faq.xml:120
#, no-c-format
msgid "For geometry: Connect to your database with <filename>psql</filename> and try the following SQL:"
msgstr ""

#. Tag: programlisting
#: faq.xml:124
#, no-c-format
msgid ""
      "CREATE TABLE gtest ( ID int4, NAME varchar(20) );\n"
      "SELECT AddGeometryColumn('', 'gtest','geom',-1,'LINESTRING',2);"
msgstr ""

#. Tag: para
#: faq.xml:126
#, no-c-format
msgid "If the geometry column addition fails, you probably have not loaded the PostGIS functions and objects into this database. See the <xref linkend=\"PGInstall\"/>."
msgstr ""

#. Tag: para
#: faq.xml:130
#, no-c-format
msgid "Then, you can insert a geometry into the table using a SQL insert statement. The GIS object itself is formatted using the OpenGIS Consortium \"well-known text\" format:"
msgstr ""

#. Tag: programlisting
#: faq.xml:134
#, no-c-format
msgid ""
      "INSERT INTO gtest (ID, NAME, GEOM) \n"
      "VALUES (\n"
      "  1, \n"
      "  'First Geometry', \n"
      "  ST_GeomFromText('LINESTRING(2 3,4 5,6 5,7 8)', -1)\n"
      ");"
msgstr ""

#. Tag: para
#: faq.xml:136
#, no-c-format
msgid "For more information about other GIS objects, see the <link linkend=\"RefObject\">object reference</link>."
msgstr ""

#. Tag: para
#: faq.xml:139
#, no-c-format
msgid "To view your GIS data in the table:"
msgstr ""

#. Tag: programlisting
#: faq.xml:141
#, no-c-format
msgid "SELECT id, name, ST_AsText(geom) AS geom FROM gtest;"
msgstr ""

#. Tag: para
#: faq.xml:143
#, no-c-format
msgid "The return value should look something like this:"
msgstr ""

#. Tag: programlisting
#: faq.xml:145
#, no-c-format
msgid ""
      "id | name           | geom\n"
      "----+----------------+-----------------------------\n"
      "  1 | First Geometry | LINESTRING(2 3,4 5,6 5,7 8) \n"
      "(1 row)"
msgstr ""

#. Tag: para
#: faq.xml:151
#, no-c-format
msgid "How do I construct a spatial query?"
msgstr ""

#. Tag: para
#: faq.xml:155
#, no-c-format
msgid "The same way you construct any other database query, as an SQL combination of return values, functions, and boolean tests."
msgstr ""

#. Tag: para
#: faq.xml:158
#, no-c-format
msgid "For spatial queries, there are two issues that are important to keep in mind while constructing your query: is there a spatial index you can make use of; and, are you doing expensive calculations on a large number of geometries."
msgstr ""

#. Tag: para
#: faq.xml:163
#, no-c-format
msgid "In general, you will want to use the \"intersects operator\" (&amp;&amp;) which tests whether the bounding boxes of features intersect. The reason the &amp;&amp; operator is useful is because if a spatial index is available to speed up the test, the &amp;&amp; operator will make use of this. This can make queries much much faster."
msgstr ""

#. Tag: para
#: faq.xml:170
#, no-c-format
msgid "You will also make use of spatial functions, such as Distance(), ST_Intersects(), ST_Contains() and ST_Within(), among others, to narrow down the results of your search. Most spatial queries include both an indexed test and a spatial function test. The index test serves to limit the number of return tuples to only tuples that <emphasis>might</emphasis> meet the condition of interest. The spatial functions are then use to test the condition exactly."
msgstr ""

#. Tag: programlisting
#: faq.xml:178
#, no-c-format
msgid ""
      "SELECT id, the_geom \n"
      "FROM thetable \n"
      "WHERE \n"
      "  ST_Contains(the_geom,'POLYGON((0 0, 0 10, 10 10, 10 0, 0 0))');"
msgstr ""

#. Tag: para
#: faq.xml:184
#, no-c-format
msgid "How do I speed up spatial queries on large tables?"
msgstr ""

#. Tag: para
#: faq.xml:188
#, no-c-format
msgid "Fast queries on large tables is the <emphasis>raison d'etre</emphasis> of spatial databases (along with transaction support) so having a good index is important."
msgstr ""

#. Tag: para
#: faq.xml:192
#, no-c-format
msgid "To build a spatial index on a table with a <varname>geometry</varname> column, use the \"CREATE INDEX\" function as follows:"
msgstr ""

#. Tag: programlisting
#: faq.xml:196
#, no-c-format
msgid "CREATE INDEX [indexname] ON [tablename] USING GIST ( [geometrycolumn] );"
msgstr ""

#. Tag: para
#: faq.xml:198
#, no-c-format
msgid "The \"USING GIST\" option tells the server to use a GiST (Generalized Search Tree) index."
msgstr ""

#. Tag: para
#: faq.xml:202
#, no-c-format
msgid "GiST indexes are assumed to be lossy. Lossy indexes uses a proxy object (in the spatial case, a bounding box) for building the index."
msgstr ""

#. Tag: para
#: faq.xml:207
#, no-c-format
msgid "You should also ensure that the PostgreSQL query planner has enough information about your index to make rational decisions about when to use it. To do this, you have to \"gather statistics\" on your geometry tables."
msgstr ""

#. Tag: para
#: faq.xml:212
#, no-c-format
msgid "For PostgreSQL 8.0.x and greater, just run the <command>VACUUM ANALYZE</command> command."
msgstr ""

#. Tag: para
#: faq.xml:215
#, no-c-format
msgid "For PostgreSQL 7.4.x and below, run the <command>SELECT UPDATE_GEOMETRY_STATS()</command> command."
msgstr ""

#. Tag: para
#: faq.xml:222
#, no-c-format
msgid "Why aren't PostgreSQL R-Tree indexes supported?"
msgstr ""

#. Tag: para
#: faq.xml:226
#, no-c-format
msgid "Early versions of PostGIS used the PostgreSQL R-Tree indexes. However, PostgreSQL R-Trees have been completely discarded since version 0.6, and spatial indexing is provided with an R-Tree-over-GiST scheme."
msgstr ""

#. Tag: para
#: faq.xml:231
#, no-c-format
msgid "Our tests have shown search speed for native R-Tree and GiST to be comparable. Native PostgreSQL R-Trees have two limitations which make them undesirable for use with GIS features (note that these limitations are due to the current PostgreSQL native R-Tree implementation, not the R-Tree concept in general):"
msgstr ""

#. Tag: para
#: faq.xml:239
#, no-c-format
msgid "R-Tree indexes in PostgreSQL cannot handle features which are larger than 8K in size. GiST indexes can, using the \"lossy\" trick of substituting the bounding box for the feature itself."
msgstr ""

#. Tag: para
#: faq.xml:246
#, no-c-format
msgid "R-Tree indexes in PostgreSQL are not \"null safe\", so building an index on a geometry column which contains null geometries will fail."
msgstr ""

#. Tag: para
#: faq.xml:256
#, no-c-format
msgid "Why should I use the <varname>AddGeometryColumn()</varname> function and all the other OpenGIS stuff?"
msgstr ""

#. Tag: para
#: faq.xml:261
#, no-c-format
msgid "If you do not want to use the OpenGIS support functions, you do not have to. Simply create tables as in older versions, defining your geometry columns in the CREATE statement. All your geometries will have SRIDs of -1, and the OpenGIS meta-data tables will <emphasis>not</emphasis> be filled in properly. However, this will cause most applications based on PostGIS to fail, and it is generally suggested that you do use <varname>AddGeometryColumn()</varname> to create geometry tables."
msgstr ""

#. Tag: para
#: faq.xml:270
#, no-c-format
msgid "MapServer is one application which makes use of the <varname>geometry_columns</varname> meta-data. Specifically, MapServer can use the SRID of the geometry column to do on-the-fly reprojection of features into the correct map projection."
msgstr ""

#. Tag: para
#: faq.xml:279
#, no-c-format
msgid "What is the best way to find all objects within a radius of another object?"
msgstr ""

#. Tag: para
#: faq.xml:284
#, no-c-format
msgid "To use the database most efficiently, it is best to do radius queries which combine the radius test with a bounding box test: the bounding box test uses the spatial index, giving fast access to a subset of data which the radius test is then applied to."
msgstr ""

#. Tag: para
#: faq.xml:289
#, no-c-format
msgid "The <varname>ST_DWithin(geometry, geometry, distance)</varname> function is a handy way of performing an indexed distance search. It works by creating a search rectangle large enough to enclose the distance radius, then performing an exact distance search on the indexed subset of results."
msgstr ""

#. Tag: para
#: faq.xml:295
#, no-c-format
msgid "For example, to find all objects with 100 meters of POINT(1000 1000) the following query would work well:"
msgstr ""

#. Tag: programlisting
#: faq.xml:298
#, no-c-format
msgid ""
      "SELECT * FROM geotable \n"
      "WHERE ST_DWithin(geocolumn, 'POINT(1000 1000)', 100.0);"
msgstr ""

#. Tag: para
#: faq.xml:304
#, no-c-format
msgid "How do I perform a coordinate reprojection as part of a query?"
msgstr ""

#. Tag: para
#: faq.xml:309
#, no-c-format
msgid "To perform a reprojection, both the source and destination coordinate systems must be defined in the SPATIAL_REF_SYS table, and the geometries being reprojected must already have an SRID set on them. Once that is done, a reprojection is as simple as referring to the desired destination SRID. The below projects a geometry to NAD 83 long lat. The below will only work if the srid of the_geom is not -1 (not undefined spatial ref)"
msgstr ""

#. Tag: programlisting
#: faq.xml:316
#, no-c-format
msgid "SELECT ST_Transform(the_geom,4269) FROM geotable;"
msgstr ""

#. Tag: para
#: faq.xml:322
#, no-c-format
msgid "I did an ST_AsEWKT and ST_AsText on my rather large geometry and it returned blank field. What gives?"
msgstr ""

#. Tag: para
#: faq.xml:326
#, no-c-format
msgid "You are probably using PgAdmin or some other tool that doesn't output large text. If your geometry is big enough, it will appear blank in these tools. Use PSQL if you really need to see it or output it in WKT."
msgstr ""

#. Tag: programlisting
#: faq.xml:329
#, no-c-format
msgid ""
      "--To check number of geometries are really blank\n"
      "                                SELECT count(gid) FROM geotable WHERE the_geom IS NULL;"
msgstr ""

#. Tag: para
#: faq.xml:335
#, no-c-format
msgid "When I do an ST_Intersects, it says my two geometries don't intersect when I KNOW THEY DO. What gives?"
msgstr ""

#. Tag: para
#: faq.xml:339
#, no-c-format
msgid "This generally happens in two common cases. Your geometry is invalid -- check <xref linkend=\"ST_IsValid\"/> or you are assuming they intersect because ST_AsText truncates the numbers and you have lots of decimals after it is not showing you."
msgstr ""

#. Tag: para
#: faq.xml:347
#, no-c-format
msgid "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?"
msgstr ""

#. Tag: para
#: faq.xml:351
#, no-c-format
msgid "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."
msgstr ""

#. Tag: para
#: faq.xml:352
#, no-c-format
msgid "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."
msgstr ""