Frank te ha dejado un mensaje...
El mensaje y la persona que lo envió solo te será mostrado a ti y borrarlo en
cualquier momento. Puedes responder a través del sistema de intercambio de
mensajes. Para descubrir quién te escribió, sigue el siguiente link:
http://us1.badoo.com/01143997419/in/APy1r
Hi,
Le 08/02/2011 19:21, Paragon Corporation a écrit :
John,
We like using OpenJump
for that -- here is a quick tutorial we wrote up on doing Ad
hoc queries with it.
http://www.postgresonline.com/journal/inde
Thanks for the responses. What you describe in your write up with OpenJump
is exactly what I'm trying to do. Also, in addition to the QGIS plugins
strk mentions, I just found two more possibilities: PgQuery for QGIS and
Postgis SQL Editor. Looks like there are some good options available.
Thanks
If you are looking for a Web-based solution, MapServer should do this as well.
David.
On Tue, Feb 8, 2011 at 12:21 PM, Paragon Corporation wrote:
> John,
> We like using OpenJump for that -- here is a quick tutorial we wrote up on
> doing Ad hoc queries with it.
>
> http://www.postgresonline.com
John,
We like using OpenJump for that -- here is a quick tutorial we wrote up on
doing Ad hoc queries with it.
http://www.postgresonline.com/journal/index.php?/archives/72-OpenJump-for-Po
stGIS-Spatial-Ad-Hoc-Queries.html
It works fine with PostgreSQL 9.0, but if you are using 9.0 -- you need
Hi
>> I thought hash indexes were discouraged over btree. Anyway, I'll test it.
>
> Absolutely. You do not want to be using Hash Indexes these days - stick with
> B-Tree. The hash refers to the method by which the executor matches the two
> column fields and is not related to the underlying index
On Tue, Feb 08, 2011 at 06:31:23PM +0100, strk wrote:
> I see pg_parser_errhint is calling lwmessage_truncate and passing
> it (lwg_parser_result->errlocation-1) w/out first checking
> errlocation begin <= 0 (checked shortly after).
I've committed a fix for the problem of my guess in r6789.
--s
On Tue, Feb 08, 2011 at 12:25:12PM -0500, John Callahan wrote:
> I haven't seen a place where QGIS supports ad hoc queries.
See RT Sql Layer [1][2] from faunalia plugins repository [3]
[1] http://www.faunalia.it/qgis/rt_sql_layer.zip
[2] http://www.faunalia.it/qgis/rt_sql_layer.experimental.zip
On Tue, Feb 08, 2011 at 08:54:12AM +0100, Peter Hopfgartner wrote:
> >> Program terminated with signal 11, Segmentation fault.
> >> #0 0x0035eee79c00 in strncat () from /lib64/libc.so.6
> >> (gdb) bt
> >> #0 0x0035eee79c00 in strncat () from /lib64/libc.so.6
> >> #1 0x2b9176d04282 i
I'm sure this has been asked many times but haven't found a definitive or
consensus answer...
Is there a postgis client that supports spatial, ad hoc queries and returns
those results to a map? This would include simple (and more complex) SELECT
statements but also other queries with spatial resu
Hallo
The overall performance will be better if you use ST_Dwithin instead of
buffer and intersects. But if the buffer is done once and will never
happen again maybe there is not much gain from that.
The bounding boxes is very important here. The index works by first
finding overlapping bounding
Hallo Marcel
i have not been playing that much myself with geography type but since
you already have your data in srid 4326 I guess you could just do
something like:
ALTER TABLE zip_polygon add column geog geography;
UPDATE zip_polygon set geog=geom::geography;
create index idx_zpoly_geog
on zi
Hi,
I have a large set of oceanic point data that I need to test to identify
all points that are within a certain distance of land. I initially
tried doing the most obvious thing I could think of - buffer land
polygons and test points for intersection, but this is taking too long
for the full dat
Hi Nicklas,
your example works - thank you.
How can i store it in geograpgy type?
thx
Marcel
- Ursprüngliche Mail -
Von: "Nicklas Avén"
An: "PostGIS Users Discussion"
Gesendet: Dienstag, 8. Februar 2011 12:46:14
Betreff: Re: [postgis-users] multipolygom
To get the distance in meters you
Hello Stephan,
and which number is for lat/lng?
- Ursprüngliche Mail -
Von: "Stephan Holl"
An: postgis-users@postgis.refractions.net
Gesendet: Dienstag, 8. Februar 2011 12:34:41
Betreff: Re: [postgis-users] multipolygom
Hello Marcel,
Marcel Kroschel , [20110208 - 12:29:18]
On Tue, Feb 8, 2011 at 12:42 PM, Mark Cave-Ayland
wrote:
> On 08/02/11 11:05, Jorge Arévalo wrote:
>
>> 2011/2/8 Stefan Keller:
>>>
>>> " Hash Cond: (TABLE_C.STR_FIELD = TABLE_B.STR_FIELD)"
>>> tells me that these two longish strings are compared first.
>>> Did you already try to index TABLE_C.ST
To get the distance in meters you can use the geography type instead.
something like:
SELECT *
FROM zip_polygon
WHERE ST_DWithin(geom::geography, ST_GeogFromText('4326;POINT(13.171982
52.52646)'), 2);
But to get it working fast you should store in geograpgy type and build
your spatial index n
On 08/02/11 11:05, Jorge Arévalo wrote:
2011/2/8 Stefan Keller:
" Hash Cond: (TABLE_C.STR_FIELD = TABLE_B.STR_FIELD)"
tells me that these two longish strings are compared first.
Did you already try to index TABLE_C.STR_FIELD and TABLE_B.STR_FIELD
as hash instead btree?
I thought hash indexes
Hello Marcel,
Marcel Kroschel , [20110208 - 12:29:18]
> hi @all.
> Hope someone can help me ;)
> I uses postgis 1.5.2., create a table with with multipolygon and
> lng/lat coordinates called zip_polygon
>
> SELECT AddGeometryColumn ( 'zip_polygon', 'geom',
hi @all.
Hope someone can help me ;)
I uses postgis 1.5.2., create a table with with multipolygon and lng/lat
coordinates called zip_polygon
SELECT AddGeometryColumn ( 'zip_polygon', 'geom', 4326, 'MULTIPOLYGON', 2 );
When ich want all polygons in distance i use this query:
SELECT *
FROM zip_pol
Hi,
2011/2/8 Stefan Keller :
> " Hash Cond: (TABLE_C.STR_FIELD = TABLE_B.STR_FIELD)"
> tells me that these two longish strings are compared first.
> Did you already try to index TABLE_C.STR_FIELD and TABLE_B.STR_FIELD
> as hash instead btree?
I thought hash indexes were discouraged over btree. A
More possibilities (just ideas) before update:
* VACUUM FULL and reindex after that. If not, your indexes became bloated.
* If you've got the RAM, just use more of it, 1 or 2 GB. You can do
this at runtime: SET maintenance_work_mem="180MB". If you can fit
whole tables into memory, reindexing shoul
22 matches
Mail list logo
