#POSTGIS IRC Log - 2008-07-23

For logs after Feb 3, 2007, all times are GMT-8. Prior logs are GMT-9.
Back to Logs
02:57:00 CIA-6: robe * r2877 /trunk/doc/reference.xml:
04:03:31 CIA-6: robe * r2878 /trunk/doc/ ( reference.xml reference_new.xml ): move of ST_AsBinary,ST_AsEWKB - add examples, various minor fixes to ST_As function descriptions
06:44:15 jlivni: zanberdo: i may have misunderstood what you wanted as output, but if buffer doesn't do it, i think i mentioned using geomunion instead
06:48:00 Devastatr: good morning, is there a desktop util like uDig that will properly display circularstring ?
06:49:46 brough: not sure if I'm reading this right -- by interleaving lat & lng into a string, it's possible to actually replace a bounding box query ( only needs to be accurate within a mile or two )? described on the list here ( for clustering points, which is a little different ): http://tinyurl.com/5l4sw6
06:49:52 sigq: Title: [postgis-users] 'clustering' of points ( at tinyurl.com )
06:50:18 jlivni: brough: yes
06:50:46 jlivni: well .. it's hard to say if it will be accurate to within a mile or two -- it probably wont be when zoomed far out
06:52:13 brough: jlivni: thanks. wasn't certain I had it right. radius will be 2..20 miles, so should be ok.
06:53:04 jlivni: well again - it depends on your projection, and what you significant digit is. if you're using decimal degrees, and you're whacking digits off before the decimal place, you're gonna be changing the bbox by huge amounts
06:53:49 jlivni: but if you're using postgis, why not just use the geometries and rtree indexes? or are you in another db that doesnt support this?
06:54:54 brough: projection is wgs84. my regular spatial queries are running fast enough, but I could do with speeding some of the rougher estimates up ( quite a lot of queries ).
06:55:00 brough: wgs
06:56:09 jlivni: then you should store your data as geometries, and use standard postgis geoms -- be easier to write your queries. but you can do a hack approach by using interleaving if you really want ...
06:56:20 jlivni: er use std. postgis queries
06:56:26 : * jlivni runs out for 20 mins
06:56:36 brough: k ta.
07:02:02 zanberdo: jlivni: it's all good now. st_buffer has done the trick and st_union ( geomunion ) isn't necessary
07:19:16 jlivni: zanberdo: ok cool - glad to hear. there was some discussion above that implied it might not do what you need, but i wasnt quite sure why
07:27:17 zanberdo: wow, quite a lengthy discussion. I hadn't read the buffer until now. darkblue_B seems to make a compelling arguement that my polygon might not be complete. However, as I'm using the results to plot points of interest within the mutlipolygon I can verify visually that all the points of all the polygons ( intersecting or otherwise ) appear to render
07:28:24 zanberdo: darkblue_B: when is your speaking engagement in the bay area? Or has that already past? I live/work in the east bay and would be very interested in sitting in if it hasn't happened yet.
07:28:59 zanberdo: is there someway for me to share a screen shot? I suppose I'd need a flicker account, or some such means, yes?
07:29:13 zanberdo: I'd like to post some of the images I'm rendering as a result of my queries, etc.
07:34:27 Devastatr: is there a desktop util like uDig that will properly display circularstring ?
07:34:31 Devastatr: I cant seem to find one online
07:46:11 darkblue_B: zanberdo: I live near Berkeley.. I am in Portland for OSCon this week
07:47:45 zanberdo: darkblue_B: are you planning on being at LinuxWorld at the Moscone Center next month?
07:48:00 darkblue_B: yes.. I'll be there with the Postgres Guys
07:48:18 darkblue_B: Pg Day I think?
07:48:35 darkblue_B: Aug 5th maybe?
07:48:41 : * zanberdo checking schedule
07:51:32 zanberdo: I beleive the folks in my office are planning on going for Ubucon which is Thursday. I wouldn't mind going Tuesday though. I'd certainly like to meet others who are doing the kind of work I find myself doing
07:55:30 darkblue_B: zanberdo: there arent very many PostgIS people.. but, I met quite a handfull when I did the Intro to PostGIS talk at the Pg Users Group
07:55:46 darkblue_B: I can call som eand see if they can come at all
07:55:58 darkblue_B: .. at any rate, yes good to talk
07:56:05 zanberdo: darkblue_B: I was reading your comments from last night concerning the st_buffer( 0 ) output, btw. This is a new function to me, introduced to me by jlivni as a possible solution to the problem of intersecting polygon's in a multipolygon object. You stated that the results should not include all polygon's however, it appears that the results I'm getting do include all poly's. Since I have no real idea what st_buffer does,
07:56:06 zanberdo: maybe you can send me a link to someplace where I can find more info. I'd be curious to know why I'm getting the results I'm getting which appear to differ from your.
07:56:45 darkblue_B: well, I saw it directly in Postgres/PostGIS
07:57:15 darkblue_B: I would try a few different test cases
07:57:16 zanberdo: hmm... all I found was the chapter 6 reference to the function, which is thin ( at best ) at describing what it does...
07:57:25 zanberdo: I will do that
07:57:25 darkblue_B: yes, thin at best
07:58:14 zanberdo: the only way I can confirm I've getting all results is that I'm using the within clause to render points on a map and when I use it in conjunction with st_buffer, the resulting rendering does indeed include all points within the individual as well as overlapping polygons...
07:58:28 zanberdo: might just be the way I'm handing the multipolygon... I don't know
07:58:32 zanberdo: I'm still very new to this
07:58:41 darkblue_B: yeah
07:59:36 darkblue_B: I think the real solution is to a ) unpack some of the dense statements !! and b ) really *union* the polys given by the user
07:59:54 darkblue_B: then do you qury with the result
08:00:10 darkblue_B: I think this multipoly stuff is not what it appears to be
08:00:38 darkblue_B: bitner is one master at this
08:00:53 darkblue_B: multi, geom collection, arrays.. he knows them all well
08:01:10 darkblue_B: I dont have much good foundation with those
08:02:10 zanberdo: right, I was doing that actually via a server-side php script. I am collection the polygon's drawn as vectors on my map and then I'd compare them to see if they intersected. If so, I'd create a union. I'd iterate through all poly's and the results of unionized poly's in order to generate a subset of poly's. This works, but was creating some lag plus required additional server-side calls. I found that if I send a single
08:02:10 zanberdo: multipoly with all poly's, intersecting or otherwise, the rendered results appear to be all points within the selected poly's... at least, visually this is the case.
08:02:33 zanberdo: s/collection/sollecting/
08:02:35 zanberdo: bah
08:02:40 zanberdo: need another cup of coffee
08:02:42 darkblue_B: hmm I am suspicious
08:02:52 darkblue_B: zanberdo: I have to go now
08:02:57 zanberdo: understood
08:03:02 zanberdo: thanks for taking the time to chat
08:03:13 zanberdo: I will post any updates I discover back to the channel
08:03:16 darkblue_B: yes.. I am keen on this.. you're welcome
08:03:20 darkblue_B: good
08:20:47 jlivni: zanberdo, darkblue_B, springmeyer -- i just took a quick sec to test in pgsql, and i see no problems with buffer working the way i would expect
08:20:53 jlivni: i cant replicate any problems as discussed above
08:21:00 jlivni: example: select astext( st_buffer( GeomFromText( 'MULTIPOLYGON( ( ( -63.98 24.26 , -66.09 32.70 , -65.39 8.09 , -48.52 7.38 , -36.56 27.07 , -46.41 42.54 , -63.98 24.26 ) ) ,( ( -98.44 49.57 , -114.61 39.73 , -95.63 26.37 , -83.67 32.70 , -82.27 43.24 , -98.44 49.57 ) ) ,( ( -121.64 45.35 , -125.86 34.10 , -111.80 29.18 , -104.06 39.02 , -115.31 51.68 , -121.64 45.35 ) ) )' ,4269 ) ,0 ) );
08:21:34 jlivni: as springmeyer noted, try paste each of these individual polys into http://openlayers.org/dev/examples/vector-formats.html and then paste the result of the above query.
08:21:35 sigq: Title: Vector Formats ( at openlayers.org )
08:22:26 jlivni: ( those polys were made by drawing vectors in that ol map )
08:25:06 springmeyer: jlivni: right, darkblue_B's example WKT from JTS I think was a special case and not what zanberdo is likely to be experiencing
08:25:15 zanberdo: jlivni: I can confirm your results
08:25:57 zanberdo: springmeyer: right.
08:25:57 springmeyer: zanberdo: you are just accepting multiple polygons digitized via an OL map just like jlivni's example,right?
08:26:06 zanberdo: springmeyer: yep
08:26:45 springmeyer: when you pull them from OL using you php script are you reading them in WKT?
08:27:08 zanberdo: springmeyer: I'm creating an array of polygon's the user draws on the vector layer and use the array to create a single multiploygon ( as jlivni has done here ) and passing that to my map file ( which has the within and buffer functions ) as well as my php script.
08:27:28 zanberdo: I am returning into my array the WKT yes.
08:27:44 zanberdo: I'm using the feature.geometry property from OL, which is the WKT
08:27:59 jlivni: you should have no problems then. from what i could conclude above, the only example that failed wasn't a valid multipoly
08:28:04 springmeyer: exactly, sounds good
08:28:45 grobda24: Hello. Should I have the ST_X function ? See http://postgis.refractions.net/documentation/manual-1.3/ch06.html#id3019650 ... psql refuses to see it.
08:28:49 zanberdo: right. as of yesterday it all looks good.
08:29:51 jlivni: grobda24: st_whatever functions were added in recent versions of postgis - what version are you running?
08:29:53 zanberdo: grobda24: yes. there is a second sql file you need to process when you added lwpostgis.sql to your database
08:30:10 zanberdo: grobda24: sorry, spoke too soon. should have asked what version you are running first.
08:30:35 zanberdo: however, look for lwpostgis_update.sql ( I beleive that is the file ) in the same path that lwpostgis.sql is located
08:31:09 jlivni: and read upgrade docs before upgrading from an old version
08:31:20 zanberdo: I had the same issue ( missing st_x function ) after installing postgis from repo on ubuntu and only adding lwpostgis.sql
08:31:34 zanberdo: caveat: mine was a fresh install : )
08:32:19 grobda24: jlivni, & zanberdo ... SELECT postgis_version( ); .... gives .... 1.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1.
08:32:48 jlivni: try just x( the_geom ) instead of st_x( the_geom )
08:33:10 zanberdo: grobda24: "1.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1" is what I'm running. Look for lwpostgis_update.sql ( or _upgrade, I will check exact name ) and add it as you did lwpostgis.sql
08:33:10 grobda24: zanberdo, ... I am also running an Ubuntu version.
08:33:45 grobda24: zanberdo ...I'll try it. Thanks :D
08:33:54 zanberdo: grobda24: /usr/share/postgresql-8.3-postgis/lwpostgis_upgrade.sql
08:34:02 zanberdo: grobda24: is where you should find it then
08:34:10 zanberdo: grobda24: if you installed from repo
08:34:45 zanberdo: grobda24: simply use: psql -d my_dv -f /usr/share/postgresql-8.3-postgis/lwpostgis_upgrade.sql as you did with lwpostgis.sql
08:35:03 zanberdo: grobda24: obviously my_db is your db... ( pointless disclaimer )
08:35:26 grobda24: k
08:36:06 zanberdo: grobda24: you should wind up with something like 658 functions in total for your db
08:37:45 springmeyer: jlivni: so this is what you are getting at, right? http://dpaste.com/66957/
08:37:47 sigq: Title: dpaste: #66957: by springmeyer ( at dpaste.com )
08:40:35 CIA-6: kneufeld * r2879 /trunk/doc/ ( installation.xml postgis.xml ): changed @@LAST_RELEASE_VERSION@@ with a DocBook variable so the correct version number gets substituted in all included files, not just postgis.xml
08:41:01 jlivni: springmeyer: exactly
08:41:32 jlivni: make sense?
08:41:35 springmeyer: jlivni: the geos ninja
08:41:57 jlivni: jlivni: the "i've got a total hack for that problem" lazy guy
08:42:03 springmeyer: honesty, I'm surprised it works
08:42:10 springmeyer: : )
08:42:30 jlivni: well, the issue with the st_within is the intersecting polys. buffer returns no intersecting polys. problem solved.
08:42:40 grobda24: zanberdo ... functions created.
08:43:47 springmeyer: jlivni: ah, I gocha. I missed the dropping of the intersection zone.
08:43:52 springmeyer: makes perfect sense
08:43:54 jlivni: yeah - thats the key
08:44:50 zanberdo: springmeyer: yes, that is essentially what I was getting. The log file speaks of "TopologyException: side location conflict", but the net result is the same without the st_buffer
08:44:58 zanberdo: grobda24: excellent
08:45:13 jlivni: http://www.postgis.org/pipermail/postgis-users/2007-November/017673.html
08:45:14 sigq: Title: [postgis-users] geomunion revisited.... ( at www.postgis.org )
08:45:33 jlivni: i usually use buffer to get rid of my intersections
08:46:37 : * springmeyer diggs it
08:49:00 jlivni: springmeyer: if you didnt already read the interleaving/clustering thread above, i bet you'd find that interesting too
08:49:25 springmeyer: no, missed it
08:49:31 springmeyer: are their postgis logs?
08:49:34 springmeyer: there
08:49:59 jlivni: brough> not sure if I'm reading this right -- by interleaving lat & lng into a string, it's possible to actually replace a bounding
08:50:02 jlivni: box query ( only needs to be accurate within a mile or two )? described on the list here ( for clustering points, which is a
08:50:05 jlivni: little different ): http://tinyurl.com/5l4sw6
08:50:06 sigq: Title: [postgis-users] 'clustering' of points ( at tinyurl.com )
08:50:08 jlivni: oops
08:50:26 jlivni: there are logs somewhere - cuz i sometimes find these discussions on google - but i dont know where
08:52:14 jlivni: i think were chatting about clustering for the ospi project at some point -- that's how I would probably do it if there were one day enough points to matter
08:52:15 springmeyer: cool, thx
08:52:43 springmeyer: ya, good idea.
08:53:46 : * springmeyer notes that darkblue_B's 'point was valid' given his invalid multipolygon
08:53:52 springmeyer: pun intended
08:54:57 : * springmeyer thinks having a simple and available sample dataset for postgis would be useful to help dispell possibilities for confusion
08:55:56 : * springmeyer is happiest to have fully grasped the buffer trick though
09:00:49 jlivni: yeah - some geos operations fail on invalid geoms, where other operations might succeed
09:01:39 jlivni: for example, st_simplify( some_invalid_linestrings,0 ) often produces a valid linestring you can then use to do other stuff with that would have failed earlier
09:02:05 jlivni: same with buffer,0. its a nice first-pass ( hack ) on junky geoms.
09:02:28 jlivni: ( all that is slightly separate from the original point, tho, which was using buffer to get rid if intersection )
09:03:39 jlivni: so a serious analysis would require being sure about why your geoms are bad. but for a good bit of the stuff I need to do, these hacks suffice
09:04:57 springmeyer: well, getting rid of intersecting polys without an aggregate query is pretty darn useful.
09:13:35 CIA-6: kneufeld * r2880 /trunk/doc/ ( reference.xml reference_new.xml ): added some xreferences so the autobuild process does not throw errors.
09:55:28 sigq: geosfeed: PSC edited by sgillies <http://trac.osgeo.org/geos/wiki/PSC>
10:18:56 grobda24: Hello. My DB can't see this function ... "SET postgis_point = PointFromText( 'POINT( ' || ST_X( point ) |..." ... and yet if I run the same command on my postgistemplate DB it DOES see the function ( it goes onto an error with "point" ) ... eh ?
10:19:55 grobda24: zanberdo ... your command worked but a DB I created from template just cannot see the function even though I ran the update on it.
10:21:56 zanberdo: grobda24: hmmm... not sure why that might be. permissions perhaps?
10:24:19 springmeyer: grobda24: what do you get if you run this query within you database?
10:24:21 springmeyer: select proname from pg_proc where proname ilike '%PointFromText%';
10:27:06 grobda24: springmeyer ... it lists .... " pointfromtext st_pointfromtext pointfromtext st_pointfromtext mpointfromtext st_mpointfromtext mpointfromtext st_mpointfromtext multipointfromtext multipointfromtext st_multipointfromtext( 11 rows )"
10:30:14 springmeyer: oh, sorry. so then $ select proname from pg_proc where proname ilike '%ST_X%'; returns what?
10:31:51 grobda24: springmeyer ... "st_xmin st_xmax st_x astext st_astext( 5 rows )".
10:34:32 springmeyer: grobda24: so you must have it installed then. paste your full query in dpaste.com ( maybe there is a syntax error? )
10:34:56 springmeyer: confusing of course why it would work in one database and not another...
10:35:10 springmeyer: did you created you working database from the template like:
10:35:31 springmeyer: $ createdb -T template_database newdatabase
10:35:32 springmeyer: ?
10:36:20 grobda24: k ... ang on
10:41:09 grobda24: springmeyer ... here ... http://dpaste.com/66989/
10:41:10 sigq: Title: dpaste: #66989 ( at dpaste.com )
10:45:41 springmeyer: grobda24: ST_X( ) operates on a postgis 'geometry' type
10:46:10 springmeyer: your goal seems to be to get point data into that standard type, so that function won't work *yet*
10:46:10 grobda24: ah
10:46:42 springmeyer: what does on line of your table look like, ie what type are the original point columns?
10:47:35 grobda24: simple postgresql point type.
10:48:05 grobda24: I think I have to import my data to seperate X/Y, long/lat columns and then I can do it.
10:48:21 grobda24: Unless there's another way to split a point column ?
10:49:14 grobda24: Thanks for pointing the above out ! :D
10:51:05 springmeyer: what does this give you:
10:51:07 springmeyer: SELECT point[0], point[1] from hirise;
10:54:41 grobda24: springmeyer.. 0 rows. That's what I thought, but it's not strictly an array. each entry in the array is filled with 2 number entries.
10:59:31 springmeyer: then perhaps you have a line type?
11:00:02 springmeyer: it would help if you would paste the result of:
11:00:04 springmeyer: $ select * from hirise limit 1;
11:04:49 grobda24: oh, ok. I forgot the table has no data in it now ... lol. So that might be it. Too tired to check and have to eat. Thanks for help so far. Later.
11:06:38 springmeyer: no data. ya : ) that would help
11:06:53 springmeyer: well when you get back from food, try running this: http://dpaste.com/66998/
11:06:54 sigq: Title: dpaste: #66998: by springmeyer ( at dpaste.com )
11:07:23 springmeyer: should be an example of what you need to do ( if you are working with the postgres point type )
14:12:25 darkblue_B: well.. I can confirm jlivni's counter example
14:12:54 darkblue_B: the JTS environment returns IsValid( ) -> false on the MultiPoly suppleed
14:13:08 darkblue_B: but Buffer( 0 ) doesnt do the thing I saw
14:13:44 darkblue_B: in my defense, all I did was draw two inteersecting Polys in this JTS environment, as a MultiPoly
14:14:05 darkblue_B: and try the Buffer( 0 )
14:14:36 darkblue_B: all self-intersecting multipolys return isValid( ) -> False
14:45:10 jlivni: darkblue_B: i dont know anything about the JTS stuff ... i'll take a look at your multipoly example later - interesting to see why buffer flails on it
17:47:27 landonf: If I want a comprehensive treatment of countries, dependent areas, and principal subdivisions, for import, is my best bet paying ISO for access to the 3166-1 and 3166-2 databases?
17:58:21 landonf: UN/LOCODE might work out too, although I really want localized place names too :/
21:56:11 CIA-6: kneufeld * r2881 /trunk/doc/ ( Makefile.in reference.xml reference_new.xml ): Moved several version functions to the new PostGIS reference.