Subject: RE: GiST index on multiple columns? - msg#00032

Previous Message by Date:

Re: spatial_ref_sys for Tiger files?

4269 is what you should use. See http://www.census.gov/geo/www/cob/metadata.html for more details. (Click on the 'Descriptions and Metadata' link on the left menu, then choose your dataset to be sure.) A .prj would be nice, but at least they've documented it on the website. Cheers, Scott Davis > > Almost certainly 4269 (geographic, nad83). > That won't fix your distance problem, but at least > then you can do > local transforms to planar systems for analytical > purposes. > P > > On Sunday, January 9, 2005, at 10:32 AM, Lucas Burke > wrote: > > > Hi, does anyone know the srid I should use for > Tiger files that I load > > into PostGIS? I successfully loaded the data using > shp2pg with an srid > > of -1, but obviously the distance() function is > returning (I think?) > > useless numbers. I searched everywhere for this > srid, including trying > > to match a srtext string to the absolute lack of > technical information > > on the tiger data. Thanks in advance. Lucas. > > > > > > > Paul Ramsey > Refractions Research > Email: pramsey@xxxxxxxxxxxxxxx > Phone: (250) 885-0632 ===== Scott Davis scottdavis99@xxxxxxxxx __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

Next Message by Date:

Re: PostGIS - server side optimization

Hi, Thanks to all for your information. I must say that you helped me. - About data organization: split the data using multiple tables is not a solution. If you need to use all that information does not matter where the data is located. - About data optimization: now I use a column to recover and use information about geometry much faster. The SQL processing time gain is about 0.8 seconds working with a 30500 row set. The new query: SELECT AsText(Simplify(geom, 14)) AS geometry FROM "TERRASSA-1_TABLE" WHERE ( geom_length > 14 AND geom @ GeometryFromText('BOX3D(414758.439692 4596794.509,421338.876 4604365.807929513)', -1) ) - I realized thanks to Andreas Neumann that the Simplify() operation performs a business logic similar to the one I done on the renderer. Now I combine the PostGIS Simplify() function and the Renderer component optimization algorithm. The overall response time greatly decreased and it is now a mere 1.6 seconds. - Searching information about Simplify I found an old thread that perfectly describe my problematic: http://postgis.refractions.net/pipermail/postgis-users/2003-January/001979.html It is worth reading to "understand" the problematic root cause. I also find another interesting link about linear feature simplification: http://www.geovista.psu.edu/sites/geocomp99/Gc99/020/gc_020.htm The biggest problem is now solved. There are some issues about the Andreas Neumann post I do not understand your post at all: Issue 1: " * I use relative coordinates where applicable " Relative coordinates ? what are you doing ? Issue 2: "I use Intersection() of the data and the map bounding box" Intersection is another problem, how you draw a geometry that have points outside the image ? Do your renderer compute the point of the line that intersects the bounding box line and re-write the geometry with new points ? or do you draw a bigger image and properly set a viewport ? Issue 3: "I reduce the number of decimals using Klaus AsSVG patch" I perform the SVG creation outside the PostGIS, and I work with pixels, do you work in SVG with decimals ? how do you generate images ? you do not convert coordinates to a cartesian I/J axis based system using pixels ? Issue 4: "* I reduce the number of elements. F.e. one multipolygon in svg is preferable to several polygons if the other attributes are the same. the number of elements in the SVG DOM tree is also important for the performance." Yes, I agree. I reduced the SVG tree too using a polyline and polygon instead of little line parts. But exists the "MultiPolugon" shape on the SVG format ? I think not. Which SVG element are you using ? Thanks in advance, Best Regards, Jordi Ferran Sanchez

Previous Message by Thread:

Re: GiST index on multiple columns?

Hi, Robin, On Sat, 8 Jan 2005 01:30:11 -0500 Robin Chauhan <robin.chauhan@xxxxxxxxx> wrote: > Also, I want to improve the performance of a query which involves > conditions on both 2 spatial columns (of type 'geometry') and 3 > non-spatial columns (of type integer and float). Now GiST indexes > appear to only allow geometric columns to be indexed. So I am > considering storing/coercing numeric types into geometries, just to > allow them to be indexed along with the geometries, hopefully > improving performance. The integer types have a relatively small > number of distinct values (like 20). As far as I remember, there were GIST implementations for numeric types and others in contrib and on the GIST project site, maybe you find some helpful information there. HTH, Markus -- markus schaber | dipl. informatiker logi-track ag | rennweg 14-16 | ch 8001 zürich phone +41-43-888 62 52 | fax +41-43-888 62 53 mailto:schabios@xxxxxxxxxxxxxx | www.logi-track.com

Next Message by Thread:

PostGIS PHP Wrapper class

I have tentatively released a first pre-alpha tarball of the PostGIS PHP Wrapper class that I have been working on. It can be found at http://avoir.uwc.ac.za/projects/postgis . Please note that this is not a stable or even properly tested "release", it is merely there for feedback purposes. I will be working on it over the next while and then adding some more functionality/classes to extend the project. Thanks all for the input and encouragement! --Paul -- Linux User #348957