#POSTGIS IRC Log - 2009-06-11

For logs after Feb 3, 2007, all times are GMT-8. Prior logs are GMT-9.
Back to Logs
05:18:44 strk: good morning
05:19:12 strk: does CurveToLine take a parameter to specify interpolation quality ?
05:21:21 pramsey: yes
05:21:21 pramsey: no
05:21:28 pramsey: actually I don't know, but I feel like it does
05:23:52 strk: : )
05:24:13 CIA-34: mcayland * r4165 /trunk/liblwgeom/lwgunparse.c: Further fix for #156, and also #167 it seems. Looks like I forgot to apply the fix to the WKB routines aswell.
05:28:19 strk: oh, LineToCurve ! wonders !
07:48:04 CIA-34: pramsey * r4166 /trunk/postgis/ ( 4 files ): Clean up old compatibility code. ( #196 )
08:03:29 strk: ST_X( ) is a fun example of why I'm against the ST_ overuse
08:03:58 strk: it makes typing a query involving that function taking x4 keystrokes !
08:04:51 strk: and it's SO innatural
08:05:04 strk: SQL is meant to be a kind of natural language
08:05:27 strk: select numpoints( geom ) ...
08:05:36 strk: select intersection( a, b )
08:05:56 strk: the ST_ tie is really just for the weaks ; )
08:06:15 strk: it's even against OGC standards, isn't it ?
08:06:44 : * strk thinking loud
08:09:00 pramsey: strk: I know, it's hard, but it's more compliant.
08:09:07 pramsey: I have run postgis code unchanged on other databases.
08:09:16 pramsey: it's nice to be able to do that
08:09:49 pramsey: I certainly find myself dropping those three characters while typing, it's true.
08:10:04 pramsey: but in the end, following ISO SQL/MM is it's own reward : )
08:16:21 smartnude: : )
08:19:15 strk: I'm not against ST_ prefix, Im against dropping the non-prefixed
08:19:44 strk: in my idea the prefix should only be where specified in a starndard
08:19:52 strk: and be *in addition* to the internal name
08:20:16 strk: eventually could even be an add-on : ) [ but it's too early for that, given upgrade issues : )
08:20:32 strk: postgis_isomm.sql
08:20:35 strk: postgis_ogc.sql
08:26:42 CIA-34: pramsey * r4167 /trunk/postgis/test.c: remove file that should never have been added
08:39:39 CIA-34: pramsey * r4168 /trunk/ ( 77 files in 8 dirs ): astyle --style=ansi --indent=tab ( #133 )
08:43:47 pramsey: gah, ogr2ogr is slow
11:03:10 darkblue_B: hello- sql question.. http://dpaste.com/54287/
11:03:11 sigq: Title: dpaste: #54287 ( at dpaste.com )
11:03:43 darkblue_B: I have 133 blanks in a table of 3200 entries, I made a 2nd table with default values for each 'region', a text field
11:03:55 darkblue_B: this is what I guessed for the update
11:04:18 darkblue_B: but.. how do I communicate between the update and the sub-select?
11:21:51 bitner: update ips3 t1 set t1.lat=t2.lat_default from rgn_defaults t2 where t2.region=t1.region and the_geom is null;
11:28:08 darkblue_B: hi bitner
11:29:05 darkblue_B: I dont think it let me use that very first part there
11:29:15 darkblue_B: update ips3 t1 set...
11:29:23 darkblue_B: but, other than that.. that is it
11:29:38 darkblue_B: the postgres guys gave a hint
11:29:52 darkblue_B: so I had to do lat and lng as seperate statments
11:29:57 darkblue_B: but.. basically
11:30:24 darkblue_B: update ips3 set lat = t2.lat_default from rgn_defaults t2
11:30:48 darkblue_B: where ips3.the_geom is null and ips3.region = t2.region;
11:34:35 darkblue_B: I'm also getting the hang of making a backup of the table before I work on it, using create table as select * from tbl1;
11:34:47 darkblue_B: it doesnt bring over the primary key constraint?
11:34:52 darkblue_B: but the data is there
11:51:29 darkblue_B: ah and save history as log from pgAdmin
11:51:31 darkblue_B: thats handy
11:51:35 jlivni: back up your table using pg_dump
11:51:53 darkblue_B: yes, ok
11:52:19 darkblue_B: this thing I just did was kind of practical
11:52:30 darkblue_B: default values..
11:53:03 darkblue_B: I'm going to wrap this up and then off to the Brower bldg in berkeley
11:53:10 darkblue_B: go do a walk through there
11:55:48 darkblue_B: loading up featureserver with the new data, via json
11:56:08 darkblue_B: postgis to fs sqlite
11:58:30 darkblue_B: oh dang.. my method hit a wall
11:58:41 darkblue_B: cant curl with too long a data set
11:59:16 darkblue_B: well at any rate can always use Postgis directly as a layer right now
11:59:29 darkblue_B: more tricky things with FS later
13:09:09 jlivni: is postgis.refractions.net down?
13:47:21 rudenstam: seems so
13:52:33 pramsey: being migrated
13:52:49 pramsey: i'd point you to the archived notice but that's on the server too
22:29:18 StormTide: is there a generalize function for polygons to reduce their complexity?
22:31:42 racicot: StormTide: ST_Simplify( geometry, tolerance )
22:33:41 StormTide: thx
22:39:27 StormTide: one more q, when using AsKML is there any way to aggregate multiple rows... like an aggregating function?
23:17:46 simplexio: StormTide: if i understand question right you can do asKML( st_union( collect( the_geom ) ) from ....
23:19:26 StormTide: union and collect dont stack... union works... but doesnt quite do what i want... and collect produces geometry_to_kml: 'GeometryCollection' geometry type not supported by Google Earth
23:21:53 simplexio: i dont see why need to make on geometry from it
23:23:09 simplexio: does it support multi ?
23:24:12 simplexio: how about using st_multi, but you can collect only one type geometries into it
23:24:58 StormTide: hrm
23:25:01 StormTide: this might be right
23:25:11 StormTide: i'll play with this thx
23:25:36 simplexio: and you can cast collection to multiline if have only lines in collection, etc
23:25:45 StormTide: its polygons
23:26:02 StormTide: i'm trying to join a buncha polygons into a set for use on a google maps kml
23:26:42 StormTide: the output im looking for is multi><poly ... /><poly.... /></multi....
23:27:02 StormTide: but this doesnt quite do that
23:28:04 StormTide: st_union is the closest to correct i think
23:55:34 tazle: StormTide: st_collect on a column of polygons should produce a GeometryCollection of polygons or a MultiPolygon