| 02:31:00 | sigq: | geosfeed: Ticket #249 ( defect updated ): GEOS, Shapely, DLLs, and memory <http://trac.osgeo.org/geos/ticket/249#comment:4> |
| 03:22:45 | CIA-34: | warmerdam * r2507 /trunk/capi/ ( geos_c.cpp geos_ts_c.cpp ): forward GEOSFree to GEOSFree_r, use std:: prefix on free( ) ( #249 ) |
| 03:25:51 | CIA-34: | warmerdam * r2508 /trunk/capi/geos_c.h.in: refer to GEOSFree( ) instead of free( ) |
| 03:27:16 | sigq: | geosfeed: Ticket #249 ( defect updated ): GEOS, Shapely, DLLs, and memory <http://trac.osgeo.org/geos/ticket/249#comment:5> |
| 03:30:57 | sigq: | geosfeed: Ticket #244 ( defect updated ): Buffer fails to buffer elements of multpolygon <http://trac.osgeo.org/geos/ticket/244#comment:13> |
| 04:30:57 | CIA-34: | warmerdam * r2509 /branches/3.1/ ( 4 files in 2 dirs ): added GEOSFree( ) and GEOSFree_r( ) ( #249 ) |
| 04:32:41 | sigq: | geosfeed: Ticket #249 ( defect closed ): GEOS, Shapely, DLLs, and memory <http://trac.osgeo.org/geos/ticket/249#comment:6> |
| 07:43:08 | CIA-34: | mloskot * r4080 /spike/wktraster/scripts/gdal2wktraster.py: |
| 07:43:08 | CIA-34: | [wktraster] Added new command line option -O, --overviews for overview tables |
| 07:43:08 | CIA-34: | creation and population being under development. Reorganized utility functions. |
| 07:43:08 | CIA-34: | Eventually, code of the script should be modularised into a couple of classes. |
| 10:30:13 | sjzzalx: | hello all. I'm having a problem building postgis on Ubuntu ... this seems to be a common problem, but thing doesn't find the postgres header files, though they seem to exist in the right location. Any known fix for this? |
| 11:57:50 | jlivni: | sjzzalx: can you be more specific with what you're up to? works fine for me |
| 11:58:13 | jlivni: | following http://os.umbrellaconsulting.com/wiki/UbuntuBaseStackSource for example works |
| 11:58:14 | sigq: | Title: UbuntuBaseStackSource - trac_os - Trac ( at os.umbrellaconsulting.com ) |
| 13:47:28 | nhv: | anyone ever try to have multiple level of detail of line objects in a table ? |
| 13:52:26 | pramsey: | nhv: in one table? no |
| 13:53:22 | pramsey: | the google encoding of lines has some odd thoughts along those lines which are going to make writing a serializer for that format tricky http://code.google.com/apis/maps/documentation/polylineutility.html |
| 13:53:23 | sigq: | Title: Interactive Polyline Encoder Utility - Google Maps API - Google Code ( at code.google.com ) |
| 13:53:40 | nhv: | I guess having a separate table for each LOD makes more sense |
| 13:55:23 | nhv: | another newbie question is it absurd to be building tables with 100s of lines where at full detail each line has 100s of K points ? |
| 13:57:52 | nhv: | ya LOD lines are a tricky concept |
| 13:58:16 | pramsey: | yes, absurd |
| 13:58:35 | pramsey: | very expensive to pull each one out, and probably you only want a small portion of it for each calculation |
| 13:58:50 | pramsey: | better to chop them into < 200 vertices |
| 13:59:05 | pramsey: | so that each sub-component fits in a page |
| 13:59:21 | nhv: | hmm ... |
| 14:00:27 | nhv: | that is sort of what I do with the raw data except I have 10 minutes of data approx 2500 points per segment |
| 14:00:30 | pramsey: | the actual length you can fit will vary depending on how much other stuff you have in your tuple and how many dimensions are in your line |
| 14:00:59 | nhv: | that works relatively well in my ascii flat file db |
| 14:02:15 | nhv: | maybe I can add a segment ID to each record an build an index on those and accomplish sort of the same |
| 14:02:56 | pramsey: | track_id + sequence_id |
| 14:03:05 | pramsey: | or somesuch : ) |
| 14:03:12 | nhv: | track_id + track_sement_id |
| 14:03:17 | pramsey: | aye |
| 14:04:01 | nhv: | can I expect this to scale to many millions of points |
| 14:04:36 | nhv: | I am storing scientific data that is being collected at 5 times a second |
| 14:05:35 | nhv: | and trying to improve on a custom ascii heirarchial db |
| 14:05:50 | nhv: | I really just need better spatial partitioning |
| 14:07:12 | nhv: | actual data is measured in TBs but metadata which I want DB access to is in 10s of GBs |
| 14:07:19 | nhv: | think image database |
| 14:08:58 | nhv: | anyway thanks |
| 14:09:19 | nhv: | I am going to try adding a second key to the tracks |
| 14:36:54 | pramsey: | nhv: if you cut things up under the page size, you should find things scale quite well. spatial partitioning is something I need to investigate... |