Re: [postgis-users] Can't Find liblwgeom for WKT Raster Installation
On Fri, Nov 26, 2010 at 5:12 PM, fueldistributa wrote: > > > > fueldistributa wrote: >> >> Hi >> >> I'm currently working on setting-up a spatial database on Ubuntu (10.04 >> LTS lycid lynx). I've installed postgresql 8.4 / postgis 1.5.2 using the >> synaptic manager command line method in the terminal. I've verified that I >> have all the necessary requirements, but cannot seem to get pass the >> ./configure to try and install WKT Raster. >> >> This is the following error message that I get, after running the >> configure line in the wktraster0.1.6d folder; >> "sudo ./configure >> --with-postgis-sources=/usr/share/postgresql/8.4/contrib/postgis-1.5" >> >> I've pasted the entire ./configure output in case there is something else >> I'm missing, but the error is at the bottom. >> >> error: >> checking build system type... x86_64-unknown-linux-gnu >> checking host system type... x86_64-unknown-linux-gnu >> checking for gcc... gcc >> checking for C compiler default output file name... a.out >> checking whether the C compiler works... yes >> checking whether we are cross compiling... no >> checking for suffix of executables... >> checking for suffix of object files... o >> checking whether we are using the GNU C compiler... yes >> checking whether gcc accepts -g... yes >> checking for gcc option to accept ANSI C... none needed >> checking for a sed that does not truncate output... /bin/sed >> checking for egrep... grep -E >> checking for ld used by gcc... /usr/bin/ld >> checking if the linker (/usr/bin/ld) is GNU ld... yes >> checking for /usr/bin/ld option to reload object files... -r >> checking for BSD-compatible nm... /usr/bin/nm -B >> checking whether ln -s works... yes >> checking how to recognise dependent libraries... pass_all >> checking how to run the C preprocessor... gcc -E >> checking for ANSI C header files... yes >> checking for sys/types.h... yes >> checking for sys/stat.h... yes >> checking for stdlib.h... yes >> checking for string.h... yes >> checking for memory.h... yes >> checking for strings.h... yes >> checking for inttypes.h... yes >> checking for stdint.h... yes >> checking for unistd.h... yes >> checking dlfcn.h usability... yes >> checking dlfcn.h presence... yes >> checking for dlfcn.h... yes >> checking for g++... g++ >> checking whether we are using the GNU C++ compiler... yes >> checking whether g++ accepts -g... yes >> checking how to run the C++ preprocessor... g++ -E >> checking for g77... no >> checking for f77... no >> checking for xlf... no >> checking for frt... no >> checking for pgf77... no >> checking for fort77... no >> checking for fl32... no >> checking for af77... no >> checking for f90... no >> checking for xlf90... no >> checking for pgf90... no >> checking for epcf90... no >> checking for f95... f95 >> checking whether we are using the GNU Fortran 77 compiler... yes >> checking whether f95 accepts -g... yes >> checking the maximum length of command line arguments... 32768 >> checking command to parse /usr/bin/nm -B output from gcc object... ok >> checking for objdir... .libs >> checking for ar... ar >> checking for ranlib... ranlib >> checking for strip... strip >> checking if gcc supports -fno-rtti -fno-exceptions... no >> checking for gcc option to produce PIC... -fPIC >> checking if gcc PIC flag -fPIC works... yes >> checking if gcc static flag -static works... yes >> checking if gcc supports -c -o file.o... yes >> checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports >> shared libraries... yes >> checking whether -lc should be explicitly linked in... no >> checking dynamic linker characteristics... GNU/Linux ld.so >> checking how to hardcode library paths into programs... immediate >> checking whether stripping libraries is possible... yes >> checking if libtool supports shared libraries... yes >> checking whether to build shared libraries... yes >> checking whether to build static libraries... yes >> configure: creating libtool >> appending configuration tag "CXX" to libtool >> checking for ld used by g++... /usr/bin/ld -m elf_x86_64 >> checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes >> checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports >> shared libraries... yes >> checking for g++ option to produce PIC... -fPIC >> checking if g++ PIC flag -fPIC works... yes >> checking if g++ static flag -static works... yes >> checking if g++ supports -c -o file.o... yes >> checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports >> shared libraries... yes >> checking dynamic linker characteristics... GNU/Linux ld.so >> checking how to hardcode library paths into programs... immediate >> appending configuration tag "F77" to libtool >> checking if libtool supports shared libraries... yes >> checking whether to build shared libraries... yes >> checking whether to build static libraries... yes >> checking for f95 option to produce PIC... -fPIC >> checking if f95 PIC flag -fPIC works... yes >> checking if f95
Re: [postgis-users] Can't Find liblwgeom for WKT Raster Installation
fueldistributa wrote: > > Hi > > I'm currently working on setting-up a spatial database on Ubuntu (10.04 > LTS lycid lynx). I've installed postgresql 8.4 / postgis 1.5.2 using the > synaptic manager command line method in the terminal. I've verified that I > have all the necessary requirements, but cannot seem to get pass the > ./configure to try and install WKT Raster. > > This is the following error message that I get, after running the > configure line in the wktraster0.1.6d folder; > "sudo ./configure > --with-postgis-sources=/usr/share/postgresql/8.4/contrib/postgis-1.5" > > I've pasted the entire ./configure output in case there is something else > I'm missing, but the error is at the bottom. > > error: > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for a sed that does not truncate output... /bin/sed > checking for egrep... grep -E > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for g77... no > checking for f77... no > checking for xlf... no > checking for frt... no > checking for pgf77... no > checking for fort77... no > checking for fl32... no > checking for af77... no > checking for f90... no > checking for xlf90... no > checking for pgf90... no > checking for epcf90... no > checking for f95... f95 > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether f95 accepts -g... yes > checking the maximum length of command line arguments... 32768 > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if gcc supports -fno-rtti -fno-exceptions... no > checking for gcc option to produce PIC... -fPIC > checking if gcc PIC flag -fPIC works... yes > checking if gcc static flag -static works... yes > checking if gcc supports -c -o file.o... yes > checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports > shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... yes > configure: creating libtool > appending configuration tag "CXX" to libtool > checking for ld used by g++... /usr/bin/ld -m elf_x86_64 > checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes > checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports > shared libraries... yes > checking for g++ option to produce PIC... -fPIC > checking if g++ PIC flag -fPIC works... yes > checking if g++ static flag -static works... yes > checking if g++ supports -c -o file.o... yes > checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports > shared libraries... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... yes > checking for f95 option to produce PIC... -fPIC > checking if f95 PIC flag -fPIC works... yes > checking if f95 static flag -static works... yes > checking if f95 supports -c -o file.o... yes > checking whether the f95 linker (/usr/bin/ld -m elf_x86_64) supports > shared lib
Re: [postgis-users] Queries and (helper) functions for viewing and analysing PostGIS Raster data?
On Fri, Nov 26, 2010 at 11:08 AM, Stefan Keller wrote: >> the result of a ST_Intersection(raster, geom) call is a set of geomval >> results. > > Ok; geomval seems to be a predefined struct which contains first the > geometry, second the associated value. > And ST_Intersection() currently polygonizes the raster to vector. > But how is the query specified (if yet) in order to get a raster as > the result of calling ST_Intersection(), i.e. rasterizing first the > vector geom component before doing the overlay with raster? > > Yours, S. > Currently, there's no such function. We now are able to intersect a raster and a vector, and obtain a vector as output. We do it by polygonizing the raster first, and the intersecting the polygonized raster with the vector. The intersection of a raster and a vector to get a raster as output is planned, but not implemented yet. Best regards, > > 2010/11/25 Jorge Arévalo : >> Hello Stefan, >> >> On Thu, Nov 25, 2010 at 6:25 PM, Stefan Keller wrote: >>> I'm still trying to understand PostGIS Raster especially regarding >>> analysis and viewing PostGIS raster data. Let's begin with the latter. >>> >>> Viewing: >>> => What are the pros & cons to do this (and which is preferred?): >>> ST_DumpAsPolygons or ST_PixelAsPolygons? >>> >>> Here is an example for viewing PostGIS Raster e.g. in OpenJUMP I found >>> in the Tutorial >>> (http://trac.osgeo.org/postgis/wiki/WKTRasterTutorial01 ) >>> >>> SELECT >>> ST_AsBinary((ST_DumpAsPolygons(rast)).geom), >>> (ST_DumpAsPolygons(rast)).val >>> FROM srtm_tiled >>> WHERE rid=3278; >>> >>> This seems to polygonize raster to vector. Unfortunately it's not >>> explained in the tutorial what the constraint clause "rid=3278" means: >>> it's obviously a single, distinct tile(?). From the book "PostGIS in >>> Action": "ST_DumpAsPolygons returns a set of single polygon, pixvalue >>> pairs for a given raster band and relies on the GDAL library. In many >>> cases this function will be easier and faster to use than going down >>> to the level of the pixel using ST_Value.". A solution for doing this >>> I found here as a pl/pgsql function called ST_PixelAsPolygons >>> (http://trac.osgeo.org/postgis/wiki/WKTRasterUsefulFunctions). >>> >> >> On the origins, we simply wanted a function to polygonize a raster, as >> a base for a seamless vector-raster intersection. For doing this >> purpose, we implemented a C function that uses the GDAL Polygonize >> algorithm (http://trac.osgeo.org/gdal/browser/trunk/gdal/alg/polygonize.cpp). >> This core function is the one called by ST_DumpAsPolygons. >> >> The ST_PixelAsPolygons function is a function that polygonizes a >> raster too, but it has 2 differences with ST_DumpAsPolygons: >> - ST_PixelAsPolygons is a pure PL/pgSQL implementation, and >> ST_DumpAsPolygons relies on a core C function. >> - The algorithm is different in both functions. ST_DumpAsPolygons try >> to collect all neighboring pixels with the same value in one polygon. >> ST_PixelAsPolygons transforms each pixel in a geometry. >> >> So, ST_PixelAsPolygons was a "temporary" function, until having a >> working and more efficient implementation of raster polygonization: >> ST_DumpAsPolygons. I'll use ST_DumpAsPolygons (I'd like to add it some >> improvements, but I don't know when) >> >> About the clause "rid=3278", it was only for practical reasons: It >> takes a long time to polygonize big raster coverages, and can generate >> a big amount of polygons. So, Pierre polygonized only one raster tile, >> to show the result in the tutorial. One raster tile, in PostGIS Raster >> context, means "1 raster table row". And remember there's no real >> difference between "raster" and "tile" in PostGIS Raster. Each row of >> a raster table can be treated as a single raster object, because it >> has its own georeference information, even when this row belongs to a >> bigger raster coverage (a raster table). >> >> >>> >>> Analysis: Regarding analysis I'd like to begin with the observation, >>> that all examples I've found so far are polygonizing rasters to >>> vector. From the tutorial doing overlay: >>> >>> CREATE TABLE caribou_srtm_inter AS >>> SELECT id, >>> (ST_Intersection(rast, the_geom)).geom AS the_geom, >>> (ST_Intersection(rast, the_geom)).val >>> FROM cariboupoint_buffers_wgs, >>> srtm_tiled >>> WHERE ST_Intersects(rast, the_geom); >>> >>> => What is the intended exact result type of this overlay operation >>> query (ST_Intersects)? POINT? >>> => Which query would generate another raster layer (instead of a point >>> vector like in the above example)? >>> >> >> The intersection function is based on ST_DumpAsPolygons function. So, >> the result of a ST_Intersection(raster, geom) call is a set of geomval >> results. Each geometry represents all the neighboring pixels with the >> same value. The ST_Intersects function simply returns TRUE/FALSE >> >> About generating new raster layers, we're working on it. Just now on >> ST_MapAlgebra function. To outp
Re: [postgis-users] Benshmark postgis
On Fri, Nov 26, 2010 at 09:38:09AM +0100, Arnaud Vandecasteele wrote: > I understand better the interest of the Gis Index ! Thank you for your > answer. > I do not want to evaluate the postgis vs other database, just the time > the queries will take for 1000 10 000 or more objects. > The use case will be this one : > We have several thousands of vessels and every 5 seconds I must do a > query to check if they are or not in a dangerous area? How do dangerous areas look ? Do their bounding boxes overlap much or not at all ? Ho many areas ? Do areas move often or could you "prepare" them to take the most out of the index ? --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Queries and (helper) functions for viewing and analysing PostGIS Raster data?
> the result of a ST_Intersection(raster, geom) call is a set of geomval > results. Ok; geomval seems to be a predefined struct which contains first the geometry, second the associated value. And ST_Intersection() currently polygonizes the raster to vector. But how is the query specified (if yet) in order to get a raster as the result of calling ST_Intersection(), i.e. rasterizing first the vector geom component before doing the overlay with raster? Yours, S. 2010/11/25 Jorge Arévalo : > Hello Stefan, > > On Thu, Nov 25, 2010 at 6:25 PM, Stefan Keller wrote: >> I'm still trying to understand PostGIS Raster especially regarding >> analysis and viewing PostGIS raster data. Let's begin with the latter. >> >> Viewing: >> => What are the pros & cons to do this (and which is preferred?): >> ST_DumpAsPolygons or ST_PixelAsPolygons? >> >> Here is an example for viewing PostGIS Raster e.g. in OpenJUMP I found >> in the Tutorial >> (http://trac.osgeo.org/postgis/wiki/WKTRasterTutorial01 ) >> >> SELECT >> ST_AsBinary((ST_DumpAsPolygons(rast)).geom), >> (ST_DumpAsPolygons(rast)).val >> FROM srtm_tiled >> WHERE rid=3278; >> >> This seems to polygonize raster to vector. Unfortunately it's not >> explained in the tutorial what the constraint clause "rid=3278" means: >> it's obviously a single, distinct tile(?). From the book "PostGIS in >> Action": "ST_DumpAsPolygons returns a set of single polygon, pixvalue >> pairs for a given raster band and relies on the GDAL library. In many >> cases this function will be easier and faster to use than going down >> to the level of the pixel using ST_Value.". A solution for doing this >> I found here as a pl/pgsql function called ST_PixelAsPolygons >> (http://trac.osgeo.org/postgis/wiki/WKTRasterUsefulFunctions). >> > > On the origins, we simply wanted a function to polygonize a raster, as > a base for a seamless vector-raster intersection. For doing this > purpose, we implemented a C function that uses the GDAL Polygonize > algorithm (http://trac.osgeo.org/gdal/browser/trunk/gdal/alg/polygonize.cpp). > This core function is the one called by ST_DumpAsPolygons. > > The ST_PixelAsPolygons function is a function that polygonizes a > raster too, but it has 2 differences with ST_DumpAsPolygons: > - ST_PixelAsPolygons is a pure PL/pgSQL implementation, and > ST_DumpAsPolygons relies on a core C function. > - The algorithm is different in both functions. ST_DumpAsPolygons try > to collect all neighboring pixels with the same value in one polygon. > ST_PixelAsPolygons transforms each pixel in a geometry. > > So, ST_PixelAsPolygons was a "temporary" function, until having a > working and more efficient implementation of raster polygonization: > ST_DumpAsPolygons. I'll use ST_DumpAsPolygons (I'd like to add it some > improvements, but I don't know when) > > About the clause "rid=3278", it was only for practical reasons: It > takes a long time to polygonize big raster coverages, and can generate > a big amount of polygons. So, Pierre polygonized only one raster tile, > to show the result in the tutorial. One raster tile, in PostGIS Raster > context, means "1 raster table row". And remember there's no real > difference between "raster" and "tile" in PostGIS Raster. Each row of > a raster table can be treated as a single raster object, because it > has its own georeference information, even when this row belongs to a > bigger raster coverage (a raster table). > > >> >> Analysis: Regarding analysis I'd like to begin with the observation, >> that all examples I've found so far are polygonizing rasters to >> vector. From the tutorial doing overlay: >> >> CREATE TABLE caribou_srtm_inter AS >> SELECT id, >> (ST_Intersection(rast, the_geom)).geom AS the_geom, >> (ST_Intersection(rast, the_geom)).val >> FROM cariboupoint_buffers_wgs, >> srtm_tiled >> WHERE ST_Intersects(rast, the_geom); >> >> => What is the intended exact result type of this overlay operation >> query (ST_Intersects)? POINT? >> => Which query would generate another raster layer (instead of a point >> vector like in the above example)? >> > > The intersection function is based on ST_DumpAsPolygons function. So, > the result of a ST_Intersection(raster, geom) call is a set of geomval > results. Each geometry represents all the neighboring pixels with the > same value. The ST_Intersects function simply returns TRUE/FALSE > > About generating new raster layers, we're working on it. Just now on > ST_MapAlgebra function. To output a PostGIS Raster as a different type > of raster, you can use GDAL PostGIS Raster driver, available on GDAL > 1.8.0SVN (http://trac.osgeo.org/gdal/wiki/frmts_wtkraster.html) > > Actually, you have a version of the driver since GDAL 1.7.x, but I > committed a new version some weeks ago, with memory leaks and bugs > fixed. I know some people are testing the driver, and finding bugs, > and I'd like to fix them all, but I don't have enough time :-( for > everything. > > >> Yours, S. >> ___
[postgis-users] PostGIS training courses @ PGDay EU 2010
Hi everyone, For those of you interested in learning more about PostgreSQL/PostGIS, I'm pleased to announce that I'll be running two training courses as part of PGDay EU (http://2010.pgday.eu/training). The first course is aimed at people new to PostGIS, while the second is aimed at power users with more advanced requirements. Each of these courses costs 150EU and registration in advance is essential. Introduction to PostGIS: an open-source spatial database http://www.postgresql.eu/events/schedule/pgday2010/session/39-introduction-to-postgis-an-open-source-spatial-database-registration-required/ Advanced PostGIS: tips and techniques for power users http://www.postgresql.eu/events/schedule/pgday2010/session/40-advanced-postgis-tips-and-techniques-for-power-users-registration-required/ For those people based in Europe, it's an ideal opportunity not only to learn more in-depth about PostgreSQL/PostGIS but also to meet other users developing their own applications. Looking forward to seeing you in Stuttgart, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Benshmark postgis
I understand better the interest of the Gis Index ! Thank you for your answer. I do not want to evaluate the postgis vs other database, just the time the queries will take for 1000 10 000 or more objects. The use case will be this one : We have several thousands of vessels and every 5 seconds I must do a query to check if they are or not in a dangerous area? regards Arnaud On Fri, Nov 26, 2010 at 9:26 AM, strk wrote: > On Fri, Nov 26, 2010 at 09:15:27AM +0100, Arnaud Vandecasteele wrote: >> Thanks you for your answers. >> I can understand your objections but how can I make this process better ? >> >> Also, my tests gave me some strange results. >> For the first set, I did the process explain before without a gis index >> (gist). >> And for the seconde one I built a gis index. >> I was expected better result for the second set, but it hasn't been >> the case. Even sometimes it took me more times than without an index. >> >> Do you know what could explain this behaviour ? > > Show the numbers! > When you have an index the planner has to take a decision as to > whether or not to use the index. This decision may explain an overhead > you're seeing. If it chooses to NOT use the index the additional time > spent in deciding will be clear. If it chooses to use the index then > the speed difference can be due to other things. > First, having just a few geoms (world countries) doesn't really show > much advantage of the index. > Second, having countries spannign the whole world (have bounding boxes > shown on a map to see) doesn't make the index very efective (still finds > many candidates). > > Your procedure is fine to check how good postgis is vs. others > _given_the_exactly_same_input_ > I suggest making the points predictable too rather than rendom, if > you're aiming at this kind of comparison. > > If you want to evaluate something else make it clear what the goal is. > > --strk; > > () Free GIS & Flash consultant/developer > /\ http://strk.keybit.net/services.html > ___ > postgis-users mailing list > postgis-users@postgis.refractions.net > http://postgis.refractions.net/mailman/listinfo/postgis-users > -- Van De Casteele Arnaud Mines Paris Tech - CRC Sophia-Antipolis 0698 24 25 29 SIG - WebMapping - SOLAP - BI - GeoCollaboration Web Site http://geotribu.net/ http://www.sismaris.org/ ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Benshmark postgis
On Fri, Nov 26, 2010 at 09:15:27AM +0100, Arnaud Vandecasteele wrote: > Thanks you for your answers. > I can understand your objections but how can I make this process better ? > > Also, my tests gave me some strange results. > For the first set, I did the process explain before without a gis index > (gist). > And for the seconde one I built a gis index. > I was expected better result for the second set, but it hasn't been > the case. Even sometimes it took me more times than without an index. > > Do you know what could explain this behaviour ? Show the numbers! When you have an index the planner has to take a decision as to whether or not to use the index. This decision may explain an overhead you're seeing. If it chooses to NOT use the index the additional time spent in deciding will be clear. If it chooses to use the index then the speed difference can be due to other things. First, having just a few geoms (world countries) doesn't really show much advantage of the index. Second, having countries spannign the whole world (have bounding boxes shown on a map to see) doesn't make the index very efective (still finds many candidates). Your procedure is fine to check how good postgis is vs. others _given_the_exactly_same_input_ I suggest making the points predictable too rather than rendom, if you're aiming at this kind of comparison. If you want to evaluate something else make it clear what the goal is. --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Benshmark postgis
Thanks you for your answers.
I can understand your objections but how can I make this process better ?
Also, my tests gave me some strange results.
For the first set, I did the process explain before without a gis index (gist).
And for the seconde one I built a gis index.
I was expected better result for the second set, but it hasn't been
the case. Even sometimes it took me more times than without an index.
Do you know what could explain this behaviour ?
Best regards
Arnaud
PS : In attached file you will find the results of the test
On Thu, Nov 25, 2010 at 8:01 PM, Paul Ramsey wrote:
> Oh, no, the results will still be biased by the particular polygon
> data. You'll have a "how postgis performs doing p-i-p against a world
> countries file" result. Which isn't a generic "how postgis performs
> doing p-i-p" result by any stretch of the imagination.
>
> P.
>
> On Thu, Nov 25, 2010 at 10:30 AM, George Silva
> wrote:
>> To eliminate the problemas presented by Paul, create a regular grid of 1x1
>> degrees and populate it randomly with points. Then make your test. All
>> square polygons will have 4 vertexes and the test is "less biased".
>>
>> George
>>
>> On Thu, Nov 25, 2010 at 3:22 PM, Paul Ramsey wrote:
>>>
>>> Depends on who you think the results will be valid for. The
>>> countries-of-the-world is a somewhat non-standard GIS collection given
>>> the wide variation in polygon sizes, the large numbers of vertices in
>>> the larger polygons, and the extreme coverage of the overall area that
>>> the bounding boxes of the larger polygons command. In many ways your
>>> test of "against the whole world" will be largely a test of "against
>>> Russia, Canada, Brazil, and the USA"
>>>
>>> Data matters,
>>>
>>> P
>>>
>>>
>>> On Thu, Nov 25, 2010 at 9:16 AM, Arnaud Vandecasteele
>>> wrote:
>>> Hi all,
>>> >
>>> > I've to do a quick benchmark of postgis. The case is to check if a
>>> > point is inside (or not) a polygon.
>>> > To do so, I've uploaded in my database a big shapefile which contains
>>> > all the world's countries.
>>> > After that I've made a simple stored function [1]. This one, take two
>>> > arguments :
>>> > 1 - The number of points to check
>>> > 2 - The number of polygon to check
>>> >
>>> > Then I run the query and i change the number of iterations or the
>>> > number of feature.
>>> >
>>> > Do you think it's a good way to have some pertinents results ?
>>> >
>>> >
>>> > Best regards
>>> >
>>> > Arnaud
>>> >
>>> >
>>> > [1]
>>> > -- Function: random_poi(integer, integer)
>>> >
>>> > -- DROP FUNCTION random_poi(integer, integer);
>>> >
>>> > CREATE OR REPLACE FUNCTION random_poi(integer, integer)
>>> > RETURNS void AS
>>> > $BODY$
>>> > DECLARE
>>> > iteration alias for $1;
>>> > nb_feat alias for $2;
>>> > pt_x numeric;
>>> > pt_y numeric;
>>> > geom_poi geometry;
>>> > i int := 0;
>>> > BEGIN
>>> > WHILE i < iteration LOOP
>>> > i := i + 1;
>>> > -- CREATE RANDOM POSITION
>>> > pt_x := random()*100;
>>> > pt_y := random()*100;
>>> > -- CREATE RANDOM GEOM POI
>>> > geom_poi := ST_GeometryFromText(text 'POINT('||pt_x||'
>>> > '||pt_y||')');
>>> > PERFORM ST_CONTAINS(geom_poi, the_geom) FROM world_poly
>>> > LIMIT nb_feat;
>>> > END LOOP;
>>> > return;
>>> > END;
>>> > $BODY$
>>> > LANGUAGE 'plpgsql' IMMUTABLE STRICT
>>> > COST 100;
>>> > ALTER FUNCTION random_poi(integer, integer) OWNER TO postgres;
>>> > ___
>>> > postgis-users mailing list
>>> > postgis-users@postgis.refractions.net
>>> > http://postgis.refractions.net/mailman/listinfo/postgis-users
>>> >
>>> ___
>>> postgis-users mailing list
>>> postgis-users@postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>
>>
>> --
>> George R. C. Silva
>>
>> Desenvolvimento em GIS
>> http://blog.geoprocessamento.net
>>
>> ___
>> postgis-users mailing list
>> postgis-users@postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
--
Van De Casteele Arnaud
Mines Paris Tech - CRC
Sophia-Antipolis
0698 24 25 29
SIG - WebMapping - SOLAP - BI - GeoCollaboration
Web Site
http://geotribu.net/
http://www.sismaris.org/
result_postgis.pdf
Description: Adobe PDF document
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
