Steve,
Is your pgsql2shp not exporting .prj files? It should be if you are
exporting an sql query or table/view with a known srid and all records have
the same srid. It should be doing this from version PostGIS 1.3.6 on. I
wrote that logic because I had similar issues with users using ArcMap not
On 7/21/2011 3:23 AM, Ben Madin wrote:
G'dat all,
We have a client (potential client) who wants some mapping done and
the maps returned in shapefile format. In the contract they insist on
specifying that the shapefiles are compatible with "ESRI's ArcView
version 9" (their words, not mine).
I do
On Jul 25, 2011, at 4:16 PM, Mr. Puneet Kishor wrote:
>
> On Jul 25, 2011, at 3:44 PM, Sandro Santilli wrote:
>
>> On Mon, Jul 25, 2011 at 03:40:34PM -0500, Mr. Puneet Kishor wrote:
>>> Please help me understand the following
>>>
>>>
>>> SELECT
>>> ST_Nrings(the_geom) nr,
>>> ST_Num
On Jul 25, 2011, at 3:44 PM, Sandro Santilli wrote:
> On Mon, Jul 25, 2011 at 03:40:34PM -0500, Mr. Puneet Kishor wrote:
>> Please help me understand the following
>>
>>
>> SELECT
>>ST_Nrings(the_geom) nr,
>>ST_NumInteriorRings(the_geom) nir,
>>ST_AsText(the_geom) WKT
>> FRO
On Mon, Jul 25, 2011 at 03:40:34PM -0500, Mr. Puneet Kishor wrote:
> Please help me understand the following
>
>
> SELECT
> ST_Nrings(the_geom) nr,
> ST_NumInteriorRings(the_geom) nir,
> ST_AsText(the_geom) WKT
> FROM table
> WHERE objectid = 280;
>
> nr nir WKT
> -- ---
Please help me understand the following
SELECT
ST_Nrings(the_geom) nr,
ST_NumInteriorRings(the_geom) nir,
ST_AsText(the_geom) WKT
FROM table
WHERE objectid = 280;
nr nir WKT
-- ---
43 "MULTIPOLYGON(((
Will PostGIS have a release that supports Postgres 9.1 and the new GIST
index when 9.1 comes out?
Aren
On Mon, Jul 25, 2011 at 2:34 PM, forkandwait wrote:
> Ragi Burhum gmail.com> writes:
>
> > Brent and Sean are correct. Nevertheless, it is worth noting that if you
> are
> trying to do k near
Ragi Burhum gmail.com> writes:
> Brent and Sean are correct. Nevertheless, it is worth noting that if you are
trying to do k nearest neighbor queries, PostgreSQL 9.1 has much better (as in
orders of magnitude) indexing support for this particular scenario.
See http://www.depesz.com/index.php/201
Brent and Sean are correct. Nevertheless, it is worth noting that if you are
trying to do k nearest neighbor queries, PostgreSQL 9.1 has much better (as
in orders of magnitude) indexing support for this particular scenario. See
http://www.depesz.com/index.php/2010/12/11/waiting-for-9-1-knngist/
O
I think this i because the constraints from the existing table (geom type and
srid) are not copied over with the data. You need to recreate these (copy
them from the CREATE TABLE sql from the "old" table). probe_geometry_columns()
will then do what it is supposed to do.
Phil
>
Em segunda-feira, 25 de julho de 2011 05:51:16, Jan Hartmann escreveu:
Hi,
When I create a table "like" another table with geometry columns, the
the public.geometry_columns table is not updated. The
"probe_geometry_columns()" and "populate_geometry_columns" functions
don't work on the new tab
On Mon, Jul 25, 2011 at 01:15:08AM -0700, Scholle wrote:
> How to get n largest (multi-)polygons
> contained in parent (multi-)polygon?
WITH dump AS ( SELECT (ST_Dump(parent)).* )
SELECT * FROM dump
ORDER BY ST_Area(geom)
LIMIT n;
You can play with st_collect/group by if you want to limit
t
Hi,
When I create a table "like" another table with geometry columns, the
the public.geometry_columns table is not updated. The
"probe_geometry_columns()" and "populate_geometry_columns" functions
don't work on the new table, because they cannot determine the srid of
the geometry column in t
Please, can anybody help?
--
View this message in context:
http://old.nabble.com/How-to-get-n-largest-%28multi-%29polygons-contained-in-parent-%28multi-%29polygon--tp32105569p32129762.html
Sent from the PostGIS - User mailing list archive at Nabble.com.
_
14 matches
Mail list logo
