[postgis-users] ST_Transform troubles
Hello all, I am having some problems with the output of ST_Transform. To illustrate the problem, I have a point in the EPSG:28992 SRS: POINT(253328 593188) I want to transform it to WGS84 (EPSG:4326). This is the output of ST_Transform: POINT(6.86264236062518 53.3160795502069) There are two things wrong with this result: 1) The coordinates are in the wrong order (EPSG:4326 uses latitude, longitude). 2) There are too much significant numbers in the result (the implied accuracy was increased by ST_Transform). I would have expected a result like POINT(53.31608 6.86264) Is there a way to improve the way ST_Transform works? Thanks, Frans ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] ST_Transform troubles
On 24 June 2011 01:19, Frans Knibbe frans.kni...@geodan.nl wrote: POINT(6.86264236062518 53.3160795502069) There are two things wrong with this result: 1) The coordinates are in the wrong order (EPSG:4326 uses latitude, longitude). They are in the correct order. Standards say X, Y which are long, lat. This convention is commonly confused, as lat, long is very common. 2) There are too much significant numbers in the result (the implied accuracy was increased by ST_Transform). It's precision (not accuracy) that was increased. This is generally a good thing, and is required to represent global positions within fractions of a millimeter. The significant digits method of determining precision does not work here as the actual re-projection calculations are not simple. I would have expected a result like POINT(53.31608 6.86264) You can format geometry any way you like, e.g. for reporting as 53.31608N 6.86264E. But if you are passing data for applications, keep to standard WKT and high precision if you can. The distance between the high-precision and 5-decimal precision is about 16.5 cm, which can be significant to many users. -Mike ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] ST_Transform troubles
Hello Mike, there are 2 standards PostGIS and most other software use the http://en.wikipedia.org/wiki/Right_hand_rule. In surveying only the left hand rule is the truth. Gr Ralf Am Donnerstag 23 Juni 2011, 16:05:18 schrieb Mike Toews: On 24 June 2011 01:19, Frans Knibbe frans.kni...@geodan.nl wrote: POINT(6.86264236062518 53.3160795502069) There are two things wrong with this result: 1) The coordinates are in the wrong order (EPSG:4326 uses latitude, longitude). They are in the correct order. Standards say X, Y which are long, lat. This convention is commonly confused, as lat, long is very common. 2) There are too much significant numbers in the result (the implied accuracy was increased by ST_Transform). It's precision (not accuracy) that was increased. This is generally a good thing, and is required to represent global positions within fractions of a millimeter. The significant digits method of determining precision does not work here as the actual re-projection calculations are not simple. I would have expected a result like POINT(53.31608 6.86264) You can format geometry any way you like, e.g. for reporting as 53.31608N 6.86264E. But if you are passing data for applications, keep to standard WKT and high precision if you can. The distance between the high-precision and 5-decimal precision is about 16.5 cm, which can be significant to many users. -Mike ___ 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
Re: [postgis-users] ST_Transform troubles
Hi Mike, Thanks for your response. About the order of coordinates: I see that PostGIS uses EPSG as the authority that defines coordinate reference systems. If you look up the definition of EPSG:4326 (for example at http://www.epsg-registry.org/, use 'retrieve by code'), you can see that it explicitly says that the axes are latitude, longitude. So it seems the standard that is used in PostGIS specifies (latitude, longitude), not (longitude, latitude). About accuracy/precision: The original coordinates in my example were (253328, 593188). Those values are in meters. So the measurement is accurate on the level of a meter. Now look at the number 6.86264236062518 (longitude). The unit of measurement in this case is degrees. One degree of latitude is 1852 meters. The number 6.86264236062518 implies that it has an accuracy of about 0.01 degree, which is 0.001852 meter. So suddenly, after transforming, the coordinates seem to have been measured at a submicroscopic level! I agree that a high precision is a good thing, but only if it is combined with a high accuracy. The precision in this case is clearly far too large. Another point that can be made here is that the large number of insignificant digits in this case cause bloating of data, which is a nuisance if these data are serialised. Regards, Frans On 2011-06-23 16:05, Mike Toews wrote: On 24 June 2011 01:19, Frans Knibbefrans.kni...@geodan.nl wrote: POINT(6.86264236062518 53.3160795502069) There are two things wrong with this result: 1) The coordinates are in the wrong order (EPSG:4326 uses latitude, longitude). They are in the correct order. Standards say X, Y which are long, lat. This convention is commonly confused, as lat, long is very common. 2) There are too much significant numbers in the result (the implied accuracy was increased by ST_Transform). It's precision (not accuracy) that was increased. This is generally a good thing, and is required to represent global positions within fractions of a millimeter. The significant digits method of determining precision does not work here as the actual re-projection calculations are not simple. I would have expected a result like POINT(53.31608 6.86264) You can format geometry any way you like, e.g. for reporting as 53.31608N 6.86264E. But if you are passing data for applications, keep to standard WKT and high precision if you can. The distance between the high-precision and 5-decimal precision is about 16.5 cm, which can be significant to many users. -Mike ___ 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
Re: [postgis-users] ST_Transform troubles
Frans, You think of your input coordinates as accurate to the nearest meter. Well perhaps :-) But anyway, the output of the transformation is as accurate as possible a representation of your input coordinates in the new coordinate system. That is, the transformation contains multiplication, division, perhaps iteration, and an underlying representation (IEEE floating point double precision) that causes round-off errors in floating point calculations. It is your assumption, not correct actually, that the output representation contains false precision. Think of your own example - if one degree of latitude is 1852 meters (to the nearest meter, on average around the spheroid), then to twenty digits of precision 1 meter is 0.00053995680345572354 degrees. There is no false precision here; that is just what one gets dividing 1 by 1852 and keeping the first 20 digits of the answer. If you start to throw away digits of your transformed numbers, then do calculations, then transform back, you will get a less accurate answer than if you keep it all (cumulative round-off error). That's the point of precisely representing your numbers - minimize that computational error. As to serializing, I guess it depends on how you serialize, but if it's some kind of character representation of the underlying binary floating point, you're not going to save much - you might use hexadecimal characters to represent 8 bytes for each number and generally there won't be a bunch of trailing zeros in those character representations, so you're not going to be able to shorten them up much on average. On Thu, Jun 23, 2011 at 7:56 AM, Frans Knibbe frans.kni...@geodan.nlwrote: Hi Mike, Thanks for your response. About the order of coordinates: I see that PostGIS uses EPSG as the authority that defines coordinate reference systems. If you look up the definition of EPSG:4326 (for example at http://www.epsg-registry.org/, use 'retrieve by code'), you can see that it explicitly says that the axes are latitude, longitude. So it seems the standard that is used in PostGIS specifies (latitude, longitude), not (longitude, latitude). About accuracy/precision: The original coordinates in my example were (253328, 593188). Those values are in meters. So the measurement is accurate on the level of a meter. Now look at the number 6.86264236062518 (longitude). The unit of measurement in this case is degrees. One degree of latitude is 1852 meters. The number 6.86264236062518 implies that it has an accuracy of about 0.01 degree, which is 0.001852 meter. So suddenly, after transforming, the coordinates seem to have been measured at a submicroscopic level! I agree that a high precision is a good thing, but only if it is combined with a high accuracy. The precision in this case is clearly far too large. Another point that can be made here is that the large number of insignificant digits in this case cause bloating of data, which is a nuisance if these data are serialised. Regards, Frans On 2011-06-23 16:05, Mike Toews wrote: On 24 June 2011 01:19, Frans Knibbefrans.kni...@geodan.nl wrote: POINT(6.86264236062518 53.3160795502069) There are two things wrong with this result: 1) The coordinates are in the wrong order (EPSG:4326 uses latitude, longitude). They are in the correct order. Standards say X, Y which are long, lat. This convention is commonly confused, as lat, long is very common. 2) There are too much significant numbers in the result (the implied accuracy was increased by ST_Transform). It's precision (not accuracy) that was increased. This is generally a good thing, and is required to represent global positions within fractions of a millimeter. The significant digits method of determining precision does not work here as the actual re-projection calculations are not simple. I would have expected a result like POINT(53.31608 6.86264) You can format geometry any way you like, e.g. for reporting as 53.31608N 6.86264E. But if you are passing data for applications, keep to standard WKT and high precision if you can. The distance between the high-precision and 5-decimal precision is about 16.5 cm, which can be significant to many users. -Mike __**_ postgis-users mailing list postgis-users@postgis.**refractions.netpostgis-users@postgis.refractions.net http://postgis.refractions.**net/mailman/listinfo/postgis-**usershttp://postgis.refractions.net/mailman/listinfo/postgis-users __**_ postgis-users mailing list postgis-users@postgis.**refractions.netpostgis-users@postgis.refractions.net http://postgis.refractions.**net/mailman/listinfo/postgis-**usershttp://postgis.refractions.net/mailman/listinfo/postgis-users -- Chris Hermansen *Vice President* TECO Natural Resource Group Limited 301 · 958 West 8th Avenue Vancouver BC CANADA · V5Z 1E5 Tel +1.604.714.2878 · Cel
[postgis-users] Nearest neighbor spatial join (more questions)
Hey all and Mark - Mark, thanks again for your suggestions. I am having trouble making it work, and I'm wondering if you or anyone else has any suggested fixes to any of the following scripts. These were my various failed attempts: Take One: [WARNING ] CREATE TABLE public.census_bg_near_ids_for_du_equal_zero_test_062111 as SELECT DISTINCT ON(o.ogc_id) o.ogc_id As orig_ogc_id, o.sf3_totalhu_h030001 As sf3_totalhu_h030001, o.st_pointfromtext As st_pointfromtext, n.ogc_id As near_ogc_id, n.sf3_totalhu_h030001 As near_sf3_totalhu_h030001, FROM census_bg_du_equal_zero_test_062111 As o, census_bg_du_more_than_zero_test_062111 As n WHERE o.ogc_id n.ogc_id AND ST_DWithin(o.the_geom, n.the_geom, 25000); Take Two: [WARNING ] CREATE TABLE public.census_bg_near_ids_for_du_equal_zero_test_062111 as SELECT o.ogc_id As orig_ogc_id, o.sf3_totalhu_h030001 As sf3_totalhu_h030001, o.st_pointfromtext As st_pointfromtext, n.ogc_id As near_ogc_id, n.sf3_totalhu_h030001 As near_sf3_totalhu_h030001, FROM census_bg_du_equal_zero_test_062111 As o, census_bg_du_more_than_zero_test_062111 As n WHERE o.ogc_id n.ogc_id AND ST_DWithin(o.the_geom, n.the_geom, 25000) LIMIT 1; Maybe the nn in the field names of the following model script something important? Model One: SELECT DISTINCT ON(g1.gid) g1.gid As gref_gid, g1.description As gref_description, g2.gid As gnn_gid, g2.description As gnn_description FROM sometable As g1, sometable As g2 WHERE g1.gid g2.gid AND ST_DWithin(g1.the_geom, g2.the_geom, 300) ORDER BY g1.gid, ST_Distance(g1.the_geom,g2.the_geom) Model Two: SELECT g1.gid As gref_gid, g1.description As gref_description, g2.gid As gnn_gid, g2.description As gnn_description FROM sometable As g1, sometable As g2 WHERE g1.gid = 1 and g1.gid g2.gid AND ST_DWithin(g1.the_geom, g2.the_geom, 300) ORDER BY ST_Distance(g1.the_geom,g2.the_geom) LIMIT 5 Thank you again! ~ Sheara Sheara Cohen Planner C A L T H O R P E A S S O C I A T E S 2095 ROSE STREET, SUITE 201, BERKELEY, CALIFORNIA, 94709 USA 510 809-1165 (direct) | 510-548-6800 x35 (main) | 510 548-6848 (fax) she...@calthorpe.com mailto:she...@calthorpe.com | www.calthorpe.com ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] Failed POST GIS on Re-boot.
Hi all. I am running PostgreSQL 9.1 and PostGIS2.0 under CENTOS. After install, the server worked fine and we spent about 2 weeks building databases, etc. Then after some routine hardware maintenance and re-boot, we get the following error. Top of Form SQL select * from oxbuildings2 limit 25 offset 0 failed : ERROR: could not load library /usr/pgsql-9.1/lib/postgis-1.5.so: /usr/pgsql-9.1/lib/postgis-1.5.so: undefined symbol: pj_set_searchpath Bottom of Form Anyone have an idea? I am thinking that it's a simple ENV setting. Chris Seker Vice President DQSI LLC ch...@dqsi.commailto:ch...@dqsi.com 19218 North 5th Street Covington, LA 70433 Office - 985.871.7472 x213 Cell - 301.613.6401 ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] ST_Transform troubles
Hello Chris, Actually, I was wrong in stating that one degree of latitude equals 1852 meters. That should have been a minute (on sixtieth of a degree). I agree that it is not good to start rounding coordinates or other intermediate values when performing a transformation. But it does seem funny not to round the end result to something representative of the 'real' accuracy (assuming that the starting values have the right precision). Whatever kind of transformation is done, it is impossible to improve the accuracy of the initial values. Accuracy of coordinates can only get worse. So it seems to me it is not wrong to round the end result. Of course I am assuming that the number of significant tells us something about accuracy. Maybe I should not do that. But there there is no other way to express the level of accuracy of individual coordinate values. Thinking about the subject a bit further I now realise that this is not really an issue with ST_Transform, it is probably a much more general issue with all calculations involving geometry (is the radius of a circle with a circumference of 10 meters 1.5915494309189533576888376337251 or 1.6?). So maybe I'd better withdraw my second point. Regards, Frans On 2011-06-23 17:29, Chris Hermansen wrote: Frans, You think of your input coordinates as accurate to the nearest meter. Well perhaps :-) But anyway, the output of the transformation is as accurate as possible a representation of your input coordinates in the new coordinate system. That is, the transformation contains multiplication, division, perhaps iteration, and an underlying representation (IEEE floating point double precision) that causes round-off errors in floating point calculations. It is your assumption, not correct actually, that the output representation contains false precision. Think of your own example - if one degree of latitude is 1852 meters (to the nearest meter, on average around the spheroid), then to twenty digits of precision 1 meter is 0.00053995680345572354 degrees. There is no "false precision" here; that is just what one gets dividing 1 by 1852 and keeping the first 20 digits of the answer. If you start to throw away digits of your transformed numbers, then do calculations, then transform back, you will get a less accurate answer than if you keep it all (cumulative round-off error). That's the point of precisely representing your numbers - minimize that computational error. As to serializing, I guess it depends on how you serialize, but if it's some kind of character representation of the underlying binary floating point, you're not going to save much - you might use hexadecimal characters to represent 8 bytes for each number and generally there won't be a bunch of trailing zeros in those character representations, so you're not going to be able to shorten them up much on average. On Thu, Jun 23, 2011 at 7:56 AM, Frans Knibbe frans.kni...@geodan.nl wrote: Hi Mike, Thanks for your response. About the order of coordinates: I see that PostGIS uses EPSG as the authority that defines coordinate reference systems. If you look up the definition of EPSG:4326 (for example at http://www.epsg-registry.org/, use 'retrieve by code'), you can see that it explicitly says that the axes are latitude, longitude. So it seems the standard that is used in PostGIS specifies (latitude, longitude), not (longitude, latitude). About accuracy/precision: The original coordinates in my example were (253328, 593188). Those values are in meters. So the measurement is accurate on the level of a meter. Now look at the number 6.86264236062518 (longitude). The unit of measurement in this case is degrees. One degree of latitude is 1852 meters. The number 6.86264236062518 implies that it has an accuracy of about 0.01 degree, which is 0.001852 meter. So suddenly, after transforming, the coordinates seem to have been measured at a submicroscopic level! I agree that a high precision is a good thing, but only if it is combined with a high accuracy. The precision in this case is clearly far too large. Another point that can be made here is that the large number of insignificant digits in this case cause bloating of data, which is a nuisance if these data are serialised. Regards, Frans
Re: [postgis-users] Failed POST GIS on Re-boot.
Figure out where your libproj.so file is installed (probably /usr/local/lib) and add that directory to /etc/ld.so.conf and run ldconfig. Best guess. P. On Thu, Jun 23, 2011 at 12:25 PM, Chris Seker ch...@dqsi.com wrote: Hi all. I am running PostgreSQL 9.1 and PostGIS2.0 under CENTOS. After install, the server worked fine and we spent about 2 weeks building databases, etc. Then after some routine hardware maintenance and re-boot, we get the following error. ** ** Top of Form *SQL **select * from oxbuildings2 limit 25 offset 0** failed : **ERROR: could not load library /usr/pgsql-9.1/lib/postgis-1.5.so: /usr/pgsql-9.1/lib/postgis-1.5.so: undefined symbol: pj_set_searchpath *** ** ** Bottom of Form ** ** Anyone have an idea? I am thinking that it’s a simple ENV setting. ** ** *Chris Seker* *Vice President* *DQSI LLC* *ch...@dqsi.com* *19218 North 5th Street* *Covington, LA 70433* *Office - 985.871.7472 x213* *Cell - 301.613.6401* ** ** ___ 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
Re: [postgis-users] Nearest neighbor spatial join (more questions)
I figured it all out. Thanks for your help. And Mark, your links were awesome! Sheara Cohen Planner C A L T H O R P E A S S O C I A T E S 2095 ROSE STREET, SUITE 201, BERKELEY, CALIFORNIA, 94709 USA ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Nearest neighbor spatial join (more questions)
Good news. Yeah, the folks who wrote those NN articles recently published the only PostGIS book - PostGIS in Action, which you'll want if you are just getting into it and plan to use it a lot. Mark On Thu, Jun 23, 2011 at 8:14 PM, Sheara Cohen she...@calthorpe.com wrote: I figured it all out. Thanks for your help. And Mark, your links were awesome! ** ** *Sheara Cohen* Planner *C A L T H O R P E** A S S O C I A T E S* 2095 ROSE STREET, SUITE 201, BERKELEY, CALIFORNIA, 94709 USA ** ** ___ 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
[postgis-users] Referencing two tables in CREATE TABLE AS calculation
Hi all, I'm encountering an incredibly slow run time when I attempt to create a new table (CREATE TABLE AS) with fields populated by calculations which reference two other tables. Does referencing multiple tables in a calculation like this usually result in a slower run time? Here is a portion of my script: CREATE TABLE public.sac_parcel_emp_unemp_calc_062311 AS SELECT a.id_parcel, a.vc_pop, a.pop_age16_up, CASE WHEN b.p043001 0 THEN (a.pop_age16_up * (cast(b.p043004 as float) + b.p043006 + b.p043011 + b.p043013) / b.p043001) ELSE 0 END as pop_employed FROM public.sac_parcel_age16_up as a, public.sac_parcel_block_bg_test_062011 as b; I also cast one of the variables in the calculation as a float so that the output field would be the same and not populated with zeros. Thanks for any help. Conor Henley GIS/Regional Planning Intern C A L T H O R P E A S S O C I A T E S 2095 ROSE STREET, SUITE 201, BERKELEY, CALIFORNIA, 94709 USA 510-548-6800 | 510 548-6848 (fax) co...@calthorpe.com mailto:she...@calthorpe.com | www.calthorpe.com ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Referencing two tables in CREATE TABLE AS calculation
You have no join condition between your two tables, so the resultant table is going to be the cartesian product of the two tables (nrows(table1) * nrows(table2)). If the tables are big enough, that alone can take a very long time. P. On Thu, Jun 23, 2011 at 5:36 PM, Conor Henley co...@calthorpe.com wrote: Hi all, I’m encountering an incredibly slow run time when I attempt to create a new table (CREATE TABLE AS) with fields populated by calculations which reference two other tables. Does referencing multiple tables in a calculation like this usually result in a slower run time? Here is a portion of my script: CREATE TABLE public.sac_parcel_emp_unemp_calc_062311 AS SELECT a.id_parcel, a.vc_pop, a.pop_age16_up, CASE WHEN b.p043001 0 THEN (a.pop_age16_up * (cast(b.p043004 as float) + b.p043006 + b.p043011 + b.p043013) / b.p043001) ELSE 0 END as pop_employed FROM public.sac_parcel_age16_up as a, public.sac_parcel_block_bg_test_062011 as b; I also cast one of the variables in the calculation as a float so that the output field would be the same and not populated with zeros. Thanks for any help. Conor Henley GIS/Regional Planning Intern C A L T H O R P E A S S O C I A T E S 2095 ROSE STREET, SUITE 201, BERKELEY, CALIFORNIA, 94709 USA 510-548-6800 | 510 548-6848 (fax) co...@calthorpe.com | www.calthorpe.com ___ 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
Re: [postgis-users] Interpolation problem
Thanks a million chris I had in mind a more suitable place for other questions of this type, i.e. general gis questions rather than special postgis questions Anyway, your kind help was so useful for me Best Regards. From: Chris Hermansen chris.herman...@tecogroup.ca To: PostGIS Users Discussion postgis-users@postgis.refractions.net Sent: Thu, June 23, 2011 10:10:29 AM Subject: Re: [postgis-users] Interpolation problem Hi Saka; AFAIK any transmitter that can be modelled as a point source in 3D should be inverse square, it's just electromagnetic radiation after all :-) If you have enough points in your grid of known (x, y, p1, p2, p3) then you can do a least squares fit on all of the parameters. Of course if your transmitters move around, you are stuck. Again, a poor r-squared / big residuals would indicate errors. Also, if your transmitters are relatively far away from the grid but close to each other, I would think you would start to get an ill-conditioned system. I don't mind continuing the discussion by e-mail if you like. Certainly our colleagues on this list are probably not so interested in the problem. chris dot hermansen at tecogroup dot ca On Wed, Jun 22, 2011 at 10:26 PM, Saka Royban sakaroy...@yahoo.com wrote: Thanks a lot Chris. some points: 1. Are u sure that all transmitters of this type use inverse square law? 2. If we don't know position of transmitters, can we still solve the problem in least square? maybe using dD=Di-Dj paramater or so. 3. I think we can suppose all transmitters to be from the same mark, so the fixed constant in formula. (this subject sounds a bit off topic, regarding postgis. Do u know any better place (i.e mailing list or so) for this kind of discussions?) Best Regards Saka From: Chris Hermansen chris.herman...@tecogroup.ca To: PostGIS Users Discussion postgis-users@postgis.refractions.net Sent: Wed, June 22, 2011 9:39:36 AM Subject: Re: [postgis-users] Interpolation problem Oh wait. Maybe each transmitter occupies a separate xy location so you are then able to calculate distance from each transmitter using an inverse square law and finally solve for the unknown xy location? If so you should be able to first determine your constants Ki i = 1,2,3 for each transmitter in Si = Ki / (Di * Di) by doing a least squares fit on the known signal strengths vs known distances (calculated from known xy). If the fit doesn't provide small residuals / high correlation then you will probably have a hard time with your subsequent computations... On 2011-06-21 9:57 PM, Chris Hermansen chris.herman...@tecogroup.ca wrote: Would not there be isolines of the same signal strength? In that case there is no unique x,y for a given signal strength... On 2011-06-21 9:54 PM, Saka Royban sakaroy...@yahoo.com wrote: yes, of course.there is a unique x,y for each triple measurements. This measurements are, in fact, Received Signal Strength so it means more distance less RSS value. From: Chris Hermansen chris.herman...@tecogroup.ca To: PostGIS Users Discussion postgis-users@postgis.refractions.net Sent: Wed, June 22, 2011 8:35:05 AM Subject: Re: [postgis-users] Interpolation problem What are the three measurements? Is it reasonable to assume that knowing three measurement values tells you the location ie is there a unique x,y for each triple of measurements? On 2011-06-21 8:54 PM, Saka Royban sakaroy...@yahoo.com wrote: Hi all I'm not sure whether this can be done completely via PostGIS or it needs some programming. Anyway, at this step no problem with programming if Knowing the way and algorithm. I have point shapefile (arranged like a grid) and for each point there is 3 similar measurements (obtained via 3 transmitters) and, of course, x and y coordinates. The problem is that when i have a new point with these 3 measures, How can i interpolate its coordinates and specify its location? Maybe helpful to say, this type of measurement is distance dependent but unfortunately i don't know the exact formula. Any help would be appreciated. Best Regards ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users -- Chris Hermansen Vice President TECO Natural Resource Group Limited 301 · 958 West 8th Avenue Vancouver BC CANADA · V5Z 1E5 Tel +1.604.714.2878 · Cel +1.778.840.4625 ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
