| 01:39:19 | CIA-34: | strk * r2320 /trunk/ ( 8 files in 3 dirs ): Port SegmentNode to JTS-1.9 |
| 01:48:32 | sanova: | hi all |
| 01:50:48 | sanova: | i have to reinstall postgresql and postgis but i have the following error fot spatial refernce. when i try to run: "spql db_name -U user -f /path/to/lwpostgis.sql" i get this error: " |
| 01:50:52 | sanova: | psql:/usr/share/postgresql-8.3-postgis/lwpostgis.sql:6460: ERROR: current transaction is aborted, commands ignored until end of transaction block |
| 01:51:11 | sanova: | i had to* |
| 02:03:20 | CIA-34: | strk * r2321 /trunk/tests/unit/noding/SegmentNodeTest.cpp: Add a couple more tests to SegmentNode unit test |
| 02:49:34 | CIA-34: | strk * r2322 /trunk/source/noding/snapround/HotPixel.cpp: Fix typo |
| 02:53:57 | mloskot: | strk: knock knock |
| 02:57:31 | mloskot: | strk: knock knock |
| 03:48:04 | strk: | what's the difference between Contains and ContainsProperly ? |
| 03:49:38 | mloskot: | The latter one contains things properly, while the former is like a school boy and does not care much about writing letters so they fit well between lines |
| 03:49:48 | mloskot: | : ) |
| 03:55:21 | strk: | looking at the bug you filed |
| 03:55:40 | strk: | interestingly, if you "explode" the query to take each ContainsProperly separately it works |
| 03:55:51 | strk: | so looks pretty much like a memory error |
| 03:56:00 | strk: | dunno if it succeeded by luck before my changes |
| 03:56:11 | strk: | worth a valgrind run, which is hard trought pgsql |
| 03:57:23 | strk: | so I'm adding a testcase in unit/capi for geos |
| 03:57:41 | strk: | any idea why the GEOSPreparedGeom returned by ..Prepare is const* ? |
| 03:59:37 | strk: | uhm, another thing I notice is that Prepare( ) doesn't take ownership of parameter, as stated in the doc |
| 03:59:56 | strk: | * Argument ownership is taken by prepared geometry |
| 03:59:56 | strk: | */ |
| 03:59:56 | strk: | extern const GEOSPreparedGeometry GEOS_DLL *GEOSPrepare( const GEOSGeometry* g ); |
| 04:00:05 | strk: | doesn't seem like i tis |
| 04:03:19 | mloskot: | prepared geometries are constant |
| 04:03:23 | mloskot: | This is my understanding |
| 04:03:34 | mloskot: | whatever it means |
| 04:03:52 | strk: | who worked on the prep geom iface ? |
| 04:04:13 | mloskot: | strk: Trac should answer you, but AFAIK it was Ben ( core ) and Paul ( C API ) |
| 04:16:35 | strk: | Aren't containsproperly200 and containsproperly201 the same test in regress_ogc_prep.sql ? |
| 04:18:36 | strk: | ok, valgrind shows memory errors |
| 04:25:56 | mloskot: | strk: welcome to the club of random bugs hunters |
| 04:25:57 | mloskot: | : ) |
| 04:25:57 | strk: | uhm, I'm wrong, looks indeed related to my changes |
| 04:26:04 | strk: | as it involves SegmentString |
| 04:26:05 | strk: | ouch |
| 04:27:48 | strk: | memory management for the noding package is going to be hard to figure out |
| 04:29:13 | mloskot: | Seems like it's easy to find more stars in geos code thatn you can see in the dark night sky :- ) |
| 04:30:24 | strk: | I think I found it btw |
| 04:30:31 | strk: | SegmentStringUtil::extractSegmentStrings |
| 04:30:35 | strk: | * @param segStr a List of SegmentStrings ( output parameter ). |
| 04:30:35 | strk: | * Ownership of elements pushed to the vector |
| 04:30:36 | strk: | * is transferred to caller. |
| 04:30:45 | strk: | the comment is not completely corect |
| 04:30:58 | strk: | * @param geom the geometry to extract from |
| 04:31:16 | strk: | or, it is, but the SegmentString don't own their coordinates |
| 04:31:24 | strk: | and in this case the coordinates come from the geom you pass in |
| 04:31:30 | strk: | so you should just not delete them |
| 04:31:40 | strk: | problem will be if any COordinateSequence is created internally |
| 04:31:52 | strk: | in which case it'll take a tracker to figure |
| 04:32:13 | : | * mloskot is out for lunch |
| 04:34:11 | strk: | uhm, indeed not deleting those lines results in leaks |
| 04:49:49 | strk: | oh dear |
| 04:49:52 | strk: | was simpler then it looked |
| 04:50:02 | strk: | delete lineSegStr[ i ]; |
| 04:50:03 | strk: | delete lineSegStr[ i ]->getCoordinates( ); |
| 04:51:22 | CIA-34: | strk * r2323 /trunk/source/geom/prep/PreparedPolygonContainsProperly.cpp: Don't access deleted memory. Fixes issue 147. |
| 04:52:06 | strk: | wasn't my fault : ) |
| 04:54:54 | CIA-34: | strk * r2324 /trunk/tests/unit/ ( Makefile.am capi/GEOSPreparedGeometryTest.cpp ): Stub initial unit tests for C-API's GEOSPreparedGeometry operations. Helped fixing issue 147 of postgis |
| 04:58:28 | CIA-34: | strk * r2325 /trunk/source/headers/geos/noding/SegmentStringUtil.h: Improve documentation about memory usage for SegmentStringUtil class |
| 05:13:00 | CIA-34: | strk * r2326 /trunk/source/ ( 2 files in 2 dirs ): Complete porting of SimpleSnapRounder ( refactoring for adding snapped nodes ) |
| 05:20:11 | : | * mloskot is back |
| 06:05:37 | mloskot: | strk: fixed |
| 06:05:48 | mloskot: | strk: I mean, I confirm the bug has been fixed in postgis/geos |
| 06:08:31 | strk: | mloskot: I haven't checked but I suspect that bug is in latest GEOS release... |
| 06:09:06 | mloskot: | possible |
| 06:38:21 | CIA-34: | strk * r2327 /trunk/source/ ( 2 files in 2 dirs ): Add increasingDirection static method, from JTS's CoordinateArray ( GEOS puts all of them in CoordinateSequence for historical reasons ) |
| 06:44:07 | danb1: | what is the difference between R-tree index and GIST index? |
| 06:45:38 | rs: | Hi, I have a problem with the OGC 05-134 ( Simple feature acces part2 ) Normalized Conformance test... I have created the tables and inserted the data as supplied by OGC 05-134.. When I run the SELECT statements, I however do not get the data that I'm supposed to according to table B.2... When looking deeper into the SQL statements, it seems like my query is behaving as it should and that the OGC specification is wrong, I find this unlikely though and thus w |
| 06:46:23 | strk: | have you considered email ? :P |
| 06:46:57 | rs: | I thought I'd try the mighty irc before emailing ; ) |
| 06:49:23 | mloskot: | danb1: http://gist.cs.berkeley.edu/ |
| 06:49:24 | sigq: | Title: GiST: Generalized Search Tree ( at gist.cs.berkeley.edu ) |
| 06:51:22 | CIA-34: | strk * r2328 /trunk/source/ ( 4 files in 2 dirs ): OrientedCoordinateArray ported from JTS |
| 06:55:42 | danb1: | mloskot: thanks |
| 07:06:34 | strk: | boy those java people |
| 07:06:39 | strk: | how lightly they take allocating stuff |
| 07:06:48 | strk: | new this new that, for any stupid thing :/ |
| 07:08:01 | mloskot: | strk: you judge it wrong I think, simply there is no other way to get some memory in java than by new |
| 07:08:19 | mloskot: | strk: its' like C++ with no stack :- ) |
| 07:35:00 | CIA-34: | strk * r2329 /trunk/capi/geos_c.h.in: Fix documentation for GEOSPrepare, GEOSPrepare_r |
| 07:48:03 | strk: | pramsey: I think that bugfix calls for a geos 3.1.1 ... aren't prepared geoms the big thing there ? |
| 07:48:32 | pramsey: | yes |
| 07:48:41 | pramsey: | I just ran down that bug, it was me. |
| 07:48:55 | strk: | is there a 3.1 branch ? |
| 07:48:55 | pramsey: | so it's been there since ( ironically ) i did the prepgeom hookup |
| 07:48:59 | pramsey: | there isn't |
| 07:49:03 | pramsey: | looks like we need one |
| 07:49:12 | strk: | yeah |
| 07:49:13 | pramsey: | question: I saw a lot of changes in my last svn up |
| 07:49:24 | pramsey: | anything important in that? |
| 07:49:31 | pramsey: | or is it safe to branch trunk? |
| 07:49:39 | strk: | I wouldn't |
| 07:49:43 | pramsey: | or I could branch at the 3.0.0 revision and then apply your bug fix |
| 07:49:49 | strk: | I would branch from 3.1.0 release revision |
| 07:49:53 | pramsey: | er, 3.1.0 |
| 07:50:02 | strk: | yeah, the bugfix is really simple |
| 07:50:36 | strk: | oh, maybe you want to also port the unit test and expand it ( if you think you'll enjoy that : ) |
| 07:50:47 | strk: | just in case there are others pending |
| 07:50:54 | : | * pramsey still doesn't feel safe enough w/ C++ to touch anything. |
| 07:51:12 | pramsey: | anything non-trivial, that is |
| 07:52:23 | strk: | don't learn ; ) |
| 07:55:55 | CIA-34: | pramsey * r2330 /branches/3.1/: Branch 3.1 |
| 07:56:02 | strk: | uhm, now this is interesting |
| 07:56:27 | strk: | time make check |
| 07:56:47 | strk: | 3.1.0: ~ 37s |
| 07:56:58 | strk: | trunk: ~ 13s |
| 07:58:02 | pramsey: | are you saying you sped everything up |
| 07:58:03 | pramsey: | or something is wrong |
| 07:58:36 | strk: | lol, that's what I'm trying to figure : ) |
| 07:59:19 | strk: | oh look, that's mostly fme.xml |
| 07:59:36 | strk: | 33 secs vs. 10 secs |
| 08:00:54 | strk: | I'll look at what the test really does, don't really feel like I can trust it 100% |
| 08:00:59 | CIA-34: | pramsey * r2331 /branches/3.1/source/geom/prep/ ( 2 files ): Memory fix for PostGIS bug #147 |
| 08:01:18 | strk: | does postgis have tests for buffer operations too ? |
| 08:01:42 | pramsey: | not many probably, because of the difficulty in comparing results |
| 08:01:42 | strk: | just to see if I get some more proof of non-obvious bug |
| 08:02:59 | strk: | uhm, XMLTester performs a Difference with the given 'expected' result |
| 08:03:05 | strk: | and computes area of that difference |
| 08:03:35 | strk: | Area of difference between obtained and expected: 4.98462e-05 |
| 08:04:47 | strk: | Area of difference between obtained and expected: 4.98287e-05 |
| 08:05:00 | strk: | second is 3.1.0, first is trunk ( with local changes ) |
| 08:08:49 | strk: | a-ha! ./XMLTester --sql-output : ) |
| 08:12:56 | strk: | under qgis lamp it seems fine |
| 08:13:11 | strk: | 3 times as fast for pretty much same result |
| 08:14:08 | CIA-34: | strk * r2332 /trunk/source/noding/OrientedCoordinateArray.cpp: const correctness |
| 08:19:43 | CIA-34: | mloskot * r3987 /spike/wktraster/rt_core/rt_api.c: ( log message trimmed ) |
| 08:19:44 | CIA-34: | Fixed bug that caused mysterious truncation of every Nth band during raster |
| 08:19:44 | CIA-34: | deserialization on 32-bit arch, under Unix. There is no guarantee that memory |
| 08:19:44 | CIA-34: | allocated and obtained from PostgreSQL pool/heap/whatever is aligned to 8-bytes |
| 08:19:44 | CIA-34: | boundary. It is unsafe to assume ( especially in deserializer ) that: |
| 08:19:46 | CIA-34: | ptr = ( uint8_t* )serialized + sizeof( struct rt_raster_serialized_t ); |
| 08:19:48 | CIA-34: | assert( 0 == ( ( ( uint64_t )ptr ) % 8 ) ); |
| 08:21:43 | strk: | uhm... no guarantee that memory obtained from PostgreSQL is 8-bytes aligned... |
| 08:22:05 | strk: | is there a quick web-interface to see the patch ? |
| 08:22:07 | mloskot: | strk: check yourself |
| 08:22:16 | strk: | lol |
| 08:24:08 | mloskot: | strk: here you have a summary of tests |
| 08:24:09 | mloskot: | http://osgeo.pastebin.com/m514cfe64 |
| 08:24:10 | sigq: | Title: osgeo private pastebin - collaborative debugging tool ( at osgeo.pastebin.com ) |
| 08:24:35 | mloskot: | See message in line 15 |
| 08:24:47 | mloskot: | then see XXX: align: 1 |
| 08:25:00 | mloskot: | where it should say 5 for this data |
| 08:25:21 | mloskot: | it says 5 for band 2 and 3, but the whole calculation is fucked up so it doesn't matter |
| 08:25:41 | mloskot: | just play for 64 hours with line 4 and you will see |
| 08:25:42 | mloskot: | :- ) |
| 08:26:07 | strk: | nah, I didn't really want the details : ) |
| 08:26:18 | strk: | just a look at the actual patch |
| 08:26:30 | strk: | I can imagine palloc( ) doesn't guarantee 8-byte aligment |
| 08:26:50 | mloskot: | strk: palloc does play with word = 4 |
| 08:26:55 | strk: | but I tought ( think ) DETOAST would, as aligmnent is specified in type definition |
| 08:27:17 | mloskot: | but even that, I really can not figure how you can expect that it will give 0 for mod 8 |
| 08:27:19 | strk: | any code relying on palloc( ) result being 8-byte aligned is surely bogus |
| 08:27:21 | mloskot: | 12 % 8 |
| 08:27:23 | mloskot: | for instance |
| 08:27:44 | mloskot: | You know, you say it's a structure, but you play with it through aliasing, ptr is not ptr to structure but ptr to stream of uint8_t |
| 08:28:10 | mloskot: | anyway, I belive you are hardly interested so I'm not going to continue this discussion |
| 08:28:19 | CIA-34: | pramsey * r2333 /branches/3.1/ ( 5 files in 3 dirs ): SetSRID_r consistency fix |
| 08:29:54 | CIA-34: | pramsey * r2334 /branches/3.1/autogen.sh: Patched up autogen script |
| 08:31:34 | strk: | pramsey: can you confirm autogen.sh is not being distributed in the geos tarball ? |
| 08:32:40 | pramsey: | confirmed |
| 08:34:26 | strk: | I think it should, don't you ? |
| 08:35:05 | pramsey: | no... |
| 08:35:18 | pramsey: | ./configure should be distributed |
| 08:36:06 | pramsey: | if people want to *develop* on geotools, they should start from the svn checkout, not hte tarball |
| 08:36:12 | pramsey: | tarball is for people who want to *compile* geos |
| 08:36:18 | pramsey: | s/geotools/geos/ |
| 08:36:49 | strk: | mloskot: ok, seen the patch, good work |
| 08:37:16 | strk: | pramsey: Makefile.am are there |
| 08:37:34 | CIA-34: | pramsey * r2335 /branches/3.1/ ( 2 files in 2 dirs ): DistanceOp fix for #236 from trunk. |
| 08:37:39 | pramsey: | fair enough, can remove those : ) |
| 08:37:45 | strk: | I think there's some reccomandation about that, probably the rationale is that anyone that wants to build can find a bug and might help fixing it |
| 08:38:01 | pramsey: | they can build and debug |
| 08:38:03 | pramsey: | they just can't change the build system easily |
| 08:38:50 | pramsey: | what do you think mloskot |
| 08:38:56 | pramsey: | autogen in tarball or no |
| 08:40:31 | mloskot: | does it hurt to include autogen.sh ? |
| 08:41:02 | pramsey: | nothing hurts, but philosophically the idea of "what should be in a tarball" differs |
| 08:41:31 | pramsey: | like, I think PostGIS deliberately does not include the HOWTOREALEASE file |
| 08:43:19 | mloskot: | philosophycally, I don't even got my master yet so looks like I'm unable to step on level of philosophy |
| 08:43:41 | strk: | ptr += ( 8 - ( ( ptr - beg ) % 8 ) ); // <-- this is the fix basically, right ? |
| 08:43:46 | strk: | - ptr += ( 8 - ( ( uint64_t )ptr % 8 ) ); |
| 08:43:49 | strk: | + ptr += ( 8 - ( ( ptr - beg ) % 8 ) ); |
| 08:44:12 | strk: | wrong assumption was about the allocated thing originating on 8-bytes boundaries |
| 08:44:26 | mloskot: | strk: nice |
| 08:45:03 | mloskot: | I prefer while loop as it allows me to dump binary context around padding |
| 08:45:58 | mloskot: | strk: so, the point is.. ? |
| 08:46:04 | pramsey: | mloskot: should I pull your VC build work into the geos 3.1 branch? |
| 08:46:22 | strk: | was just making sure I got it ( yes, I am interested, just couldn't go hunting myself ) |
| 08:47:09 | mloskot: | pramsey: perhaps, if anybody is gonna to use it |
| 08:48:11 | CIA-34: | pramsey * r2336 /branches/3.1/ ( 9 files in 8 dirs ): VC build updates from trunk |
| 08:48:13 | mloskot: | pramsey: but keep it in mind, svn logs won't tell you, that files added to SVN recently are missing from the project configs |
| 08:48:30 | pramsey: | that's good, I don't want the recent stuff |
| 08:48:35 | mloskot: | ok |
| 08:48:48 | : | * pramsey declares himself done back-porting. |
| 08:48:50 | CIA-34: | strk * r2337 /trunk/source/ ( 3 files in 3 dirs ): Improve duplicate edge detection performance ( JTS-1.9 sync ) - fme.xml runs 3 times as fast now. |
| 08:53:13 | mloskot: | strk: I didn't expected you to get hunting, I'm just worried of what else is implicitly assumed in the code and nowhere explained why it is assumed that way and not the other one. |
| 08:54:16 | mloskot: | There are a few more variations in the world of compilers than C99 and __GNUC__ |
| 08:54:23 | drewby: | how can I detect if a line crosses itself? |
| 08:54:43 | pramsey: | ask it if it's catholic |
| 08:54:59 | : | * drewby fizzles. |
| 08:55:11 | pramsey: | bu dum bum |
| 08:55:15 | pramsey: | st_issimple( ) |
| 08:55:20 | pramsey: | should do the trick |
| 08:56:28 | mloskot: | Anyways, I clearly forgot to read the small but important letters in the agreement of using FOSS - no warranty! |
| 08:58:29 | drewby: | pramsey: thanks, I have a linestring that's generated from an offset algorithm, and if the source line has too acute of an angle, the offset line ends up crossing itself |
| 08:58:40 | bitner: | pramsey: that was *bad* |
| 08:58:54 | pramsey: | i'm here all week! try the veal1 |
| 08:59:13 | strk: | bitner: have you read the one about touching rings ? |
| 08:59:21 | : | * bitner runs and hides |
| 08:59:36 | strk: | *that's* the sign of spring being arrived, let alone vultures and trees |
| 08:59:37 | pramsey: | there's no humor better than computational geometry humor. |
| 08:59:50 | : | * bitner needs some booze if this is going to continue |
| 09:00:22 | bitner: | my street is lined with cherry blossom trees -- they are still a ways from blooming |
| 09:00:54 | bitner: | no spring yet for MN |
| 09:04:47 | drewby: | okay I just figured out how to start solving my problem, thanks guys |
| 09:09:43 | : | * drewby should have written this algorithm in C instead of plpgsql. |
| 09:56:18 | CGI572: | ^__^ |
| 09:56:26 | Amber23: | ^__^ |
| 09:56:33 | strk: | mloskot: I'll try to find the time to explain some goals of the serialized format |
| 09:56:37 | strk: | this week |
| 09:57:18 | mloskot: | strk: as you like |
| 09:57:24 | strk: | the final goal is to make sure the memory returned by PG_DETOAST_DATUm will contain band data in locations where you can just reference ints of pixeltype size |
| 09:57:50 | strk: | anyway, pizza time |
| 09:58:09 | mloskot: | strk: malloc guarantees that intrinsic data types and user's types are aligned in predictable way, but for each type alignment is different |
| 09:58:32 | mloskot: | I had had hard time to figure out why you assumed 8 bytes alignment for everyone |
| 09:58:48 | mloskot: | OK, you can assume it when you "create the stream, serialize" |
| 09:59:30 | drewby: | what prompted you guys to mix 0-based and 1-based offsetting? |
| 09:59:30 | mloskot: | but not if you play with memory given by external entities, postgresql |
| 10:01:05 | mloskot: | drewby: and you expect that guys have an idea what you are talking about, don't you? |
| 10:02:24 | drewby: | oops I meant indexing instead of offsetting |
| 10:02:42 | mloskot: | drewby: indexing of *what* ?> |
| 10:03:09 | drewby: | well points in linestrings for one |
| 10:03:42 | pramsey: | I'm not sure they are mixed. |
| 10:03:53 | pramsey: | the 1-based indexes are from the specifications |
| 10:04:08 | drewby: | removing a point using 0-based indexing |
| 10:04:10 | pramsey: | what are examples of 0-based indexing? |
| 10:04:11 | drewby: | uses* |
| 10:04:21 | mloskot: | drewby: where? |
| 10:04:29 | drewby: | setpoint is also 0-based |
| 10:04:37 | pramsey: | great |
| 10:04:46 | drewby: | ST_RemovePoint and ST_SetPoint in the postgis documentation |
| 10:04:49 | pramsey: | they aren't in the specs, so I guess they got implemented with programmer semantics |
| 10:05:04 | pramsey: | ticket the issue, would you? |
| 10:05:04 | mloskot: | drewby: I agree, looks like lack of consistency |
| 10:05:30 | drewby: | sorry for my lack of clarity in explaining the issue |
| 10:14:19 | tazle: | *changing* the API because of inconsistencies in indexing is certainly a bad idea, though |
| 10:14:32 | tazle: | considering it breaks all existing code using those functions |
| 10:15:54 | pramsey: | bah! |
| 10:15:58 | mloskot: | tazle: yes, you are right, unless 1.3 -> 1.4 transition promises API preservation |
| 10:16:15 | mloskot: | not promises |
| 10:16:17 | pramsey: | I've got a stink-pile of breaking changes I'm saving up for the 2.0 release. |
| 10:16:26 | pramsey: | perhaps this will be one of them |
| 10:18:22 | tazle: | mloskot: API changes that change function signature ( in non-widening way ) are stil bad, especially if they may result in semi-silent breakage of old code |
| 10:19:50 | pramsey: | fortunately, if we change the 0-based indexes to 1-based, we can have noise breakage : ) |
| 10:19:55 | : | * pramsey votes for core dump. |
| 10:21:37 | mloskot: | tazle: it's not-so-good, but still it doesn't mean you can not do it |
| 10:21:53 | mloskot: | thinking like that software would never move from 16 to 32 bits, etc |
| 10:22:02 | mloskot: | life is brutal |
| 10:22:25 | tazle: | mloskot: moving from 16 to 32 bits is a widening change, unless developers were silly and assumed things such as overflow in C |
| 10:23:02 | mloskot: | but the deal is to not to do such changes too freely, but to announce them far earlier and introduce them with major milestones |
| 10:23:37 | mloskot: | tazle: it's not my software and I'm not a release maintainer anyways, so don't worry :- ) |
| 10:29:31 | drewby: | what does st_intersection return if the two geometries do not intersect? |
| 10:30:22 | drewby: | An empty geometry I suppose, but my first guess what null. |
| 10:31:42 | mloskot: | drewby: there is no need to guess, there is manual :- ) |
| 10:31:42 | mloskot: | http://postgis.refractions.net/documentation/manual-svn/ST_Intersection.html |
| 10:31:44 | sigq: | Title: ST_Intersection ( at postgis.refractions.net ) |
| 10:32:07 | drewby: | oh wow, this is different from the pdf |
| 10:49:36 | mloskot_dogwalk: | drewby: notice that there are at least 3 manuals referenced from the postgis documentation page |
| 11:17:55 | mloskot: | pramsey: any news about Trac for postgis? |
| 11:18:30 | pramsey: | hobu, hobu, hobu |
| 11:18:59 | pramsey: | hobu or his delegate are now our rate limiting step |
| 11:19:13 | pramsey: | we can extract and convert the issues from Google into a trac sqlite database, ready to run |
| 11:19:30 | pramsey: | we need a SAC member to receive said database and do the rest |
| 11:19:48 | mloskot: | looks like hobu is busy playing with Tommy :- ) |
| 11:20:03 | : | * drewby yawns as open jump sloooowly renders his data. |
| 11:24:48 | : | * mloskot has just realised geos frontpage lacks of licensing information |
| 11:27:51 | sigq: | geosfeed: WikiStart edited by mloskot <http://trac.osgeo.org/geos/wiki/WikiStart> |
| 11:30:21 | danb: | I've been watching the talk of the EveryBlock guy on teir PostGis use: http://blip.tv/file/1957362 |
| 11:30:22 | sigq: | Title: Behind the scenes of EveryBlock.com ( at blip.tv ) |
| 11:30:56 | danb: | they ended up using an attributes table instead of having one table for each type of object |
| 11:31:22 | danb: | has anyone familiar with this concept? |
| 11:32:11 | mloskot: | danb: what is "one table for each type" ? |
| 11:32:12 | mloskot: | What type? |
| 11:32:16 | mloskot: | What attributes? |
| 11:32:41 | mloskot: | Isn't it the basic concept of DBMS to store objects ( rows ) with their attributes ( fields/columns ) in the same table? |
| 11:34:57 | danb: | mloskot: let's say I has: I've several types of object: banks, resturants, hotels... |
| 11:35:13 | mloskot: | 3 tables |
| 11:35:19 | mloskot: | at least |
| 11:35:36 | danb: | each object require different number fields |
| 11:35:54 | mloskot: | yes |
| 11:36:15 | danb: | if you want to get all the banks, resturants and hotels in 5km radius from a specific point you have to query against each db table |
| 11:36:33 | danb: | so it might be alot of queries |
| 11:36:52 | mloskot: | danb: build a parent-child or type-subtype -like structure of tables |
| 11:37:09 | danb: | mloskot: what do you mean? |
| 11:37:31 | mloskot: | feature - tb with geometry of b, r and h |
| 11:37:49 | danb: | mloskot: to have 1 table for spatial coordinates and other tables for extra fields? |
| 11:37:58 | mloskot: | then band, rst, htls tables wher eyou store other data, specific per type |
| 11:38:19 | danb: | ? |
| 11:38:33 | mloskot: | danb: more or less |
| 11:38:44 | danb: | mloskot: wouldn't I still need to join several tables to do the quarie? |
| 11:39:00 | mloskot: | danb: depends on queries |
| 11:39:28 | danb: | mloskot: I want to have all the objects in a radius of 3KM from a lat,lon point |
| 11:40:11 | mloskot: | danb: isn't it better to model the data, at least a brute-force modeling like finding common elements and moving them to common table etc |
| 11:40:22 | mloskot: | i.e. |
| 11:40:40 | mloskot: | if all of them are represented as points, then move all geometry data to one table |
| 11:40:56 | mloskot: | then geometry-wise query is executed against one table |
| 11:41:00 | mloskot: | single index |
| 11:42:10 | danb: | mloskot: but to get the other fields I'll have to perform a query against each object type |
| 11:42:35 | mloskot: | danb: yes, but you won't query all of them at once, will you? |
| 11:42:39 | danb: | maybe it won't be too expensive when I know the points indexes |
| 11:42:54 | mloskot: | simplest case is that you will query attributes per object |
| 11:43:29 | mloskot: | user clicks, you finds on what feature he clicked, you determine id + type ( hotel, rest, etc. ) of feature and you know in what table to look for the rest |
| 11:44:16 | danb: | mloskot: unless I want to show the user an area with relevant selected objects from each type: 3 hotels, 4 resturants... |
| 11:44:28 | mloskot: | danb: it's not possible to make a clear design of database that will be efficient for all possible mixtures of queries |
| 11:45:05 | danb: | mloskot: EveryBlock shows you all objects on your block |
| 11:45:18 | mloskot: | you can show, you have all of them in "feature" table |
| 11:45:32 | mloskot: | IOW, you can show all pinpoints in requested extend |
| 11:45:56 | danb: | mloskot: right. in if a user click on the object you query and give him further info. thanks |
| 11:46:10 | mloskot: | but if you want to show all pinpoints with their all descriptive attributes, you have to send more complex query |
| 11:46:11 | danb: | mloskot: I wonder why they didn't do it this way : ) |
| 11:46:50 | mloskot: | danb: what we have discussed here, isn't it what they call separation of object ( feature table ) and attributes table ? |
| 11:47:22 | danb: | mloskot: I think so and that's why the video onfused me |
| 11:47:30 | mloskot: | danb: I've not watched it |
| 11:48:00 | mloskot: | danb: as I said, try to mimic object-oriented approach, substract common properties like |
| 11:48:02 | mloskot: | feature |
| 11:48:03 | mloskot: | ------- |
| 11:48:04 | danb: | mloskot: I didn't understnad why they don't use this approach |
| 11:48:05 | mloskot: | geometry |
| 11:48:05 | mloskot: | name |
| 11:48:07 | mloskot: | address |
| 11:48:14 | mloskot: | hotels |
| 11:48:16 | mloskot: | ----- |
| 11:48:19 | mloskot: | number of rooms |
| 11:48:23 | mloskot: | number of stars |
| 11:48:26 | mloskot: | then |
| 11:48:30 | mloskot: | restaurants |
| 11:48:31 | mloskot: | ----- |
| 11:48:33 | mloskot: | number of tables |
| 11:48:34 | mloskot: | etc. |
| 11:48:50 | danb: | mloskot: thanks. I'll do that |
| 11:49:15 | mloskot: | or just think of something more appropriate for your app/data |
| 11:56:34 | Amber23: | :( |
| 11:57:55 | mloskot: | : ) |
| 12:25:04 | Amber23: | elo, does somebody know if there is a web based irc undernet chat |
| 12:25:44 | mloskot: | http://www.google.co.uk/search?q=web+irc |
| 12:25:45 | sigq: | Title: web irc - Google Search ( at www.google.co.uk ) |
| 12:34:04 | pramsey: | hobu, hobu, hobu |
| 12:36:24 | Amber23: | thanks mloskot |
| 12:36:35 | mloskot: | wlcm |
| 12:36:36 | Amber23: | but the website is blocked :( |
| 12:44:37 | mloskot: | Amber23: I meant, google and try a couple of web-based irc clients and see which works for you |
| 12:49:05 | drewby: | I don't believe in geometry. |
| 13:00:47 | pramsey: | what do you believe in, drewby |
| 13:01:37 | bitner: | I believe it's time for a beer. |
| 13:01:50 | bitner: | too bad it's not quittin' time yet :-( |
| 13:02:17 | : | * pramsey things bitner needs a more progressive work environment |
| 13:02:30 | bitner: | !@#@! government job |
| 13:02:52 | drewby: | is !@#@! anger-speak for cushy |
| 13:02:57 | drewby: | cushy government job! |
| 13:03:10 | bitner: | :- ) |
| 13:03:15 | drewby: | pramsey: I believe that computational geometry is hard. |
| 13:03:22 | pramsey: | drewby: you are right |
| 13:03:28 | pramsey: | that's why you shouldn't be doing this work by hand |
| 13:03:36 | pramsey: | you should be binding to the offset curve builder in GEOS |
| 13:03:46 | pramsey: | which I pointed out to you last week |
| 13:07:33 | drewby: | hrmmmm |
| 13:07:49 | drewby: | okay it'll be interesting to see how much better theirs works. |
| 13:11:33 | drewby: | mines working pretty well, I've almost got it joining up with previous road segments\ |
| 13:11:53 | drewby: | and I removed a large portion of the self intersections which they seemed to leave in |
| 13:14:14 | drewby: | bye all |
| 13:30:21 | pramsey: | are you getting sucked into the Boost Geometry Library, mloskot ? |
| 13:30:46 | mloskot: | pramsey: sucked? you mean a contract? |
| 13:30:57 | pramsey: | I mean, doing something with it : ) |
| 13:31:11 | mloskot: | yes, i'm going to see what these guys did |
| 13:31:29 | mloskot: | and if it works for me, I'm going to contribute |
| 13:31:51 | mloskot: | some of algorithms if I find it possible |
| 13:34:42 | mloskot: | hobu: ping |
| 13:35:29 | pramsey: | there is no hobu . there is only hobu-ness. |
| 13:35:36 | : | * pramsey preaches the Zen of hobu |
| 13:35:57 | mloskot: | :- ) |
| 13:52:12 | strk_off: | http://lwn.net/Articles/260832/ |
| 13:52:13 | sigq: | Title: Memory access and alignment [LWN.net] ( at lwn.net ) |
| 13:56:59 | strk: | http://www.delorie.com/gnu/docs/glibc/libc_31.html |
| 13:57:00 | sigq: | Title: The GNU C Library ( at www.delorie.com ) |
| 13:57:07 | strk: | "The address of a block returned by malloc or realloc in the GNU system is always a multiple of eight" |
| 13:58:42 | mloskot: | strk: first, but we don't malloc, we palloc what means that we get memory from postgresql pool |
| 13:58:58 | mloskot: | postgresql pool is aligned to 4, as I found in palloc.h code |
| 13:59:41 | mloskot: | second, you have documented that wktraster code is GNU-specific, haven't you? |
| 14:00:09 | strk: | that's interesting |
| 14:00:17 | mloskot: | now, let me to bring some more portable documents |
| 14:00:21 | mloskot: | http://www.monkeyspeak.com/alignment/ |
| 14:00:23 | sigq: | Title: Computing Memory Alignment Restrictions of Data Types in C and C++ ( at www.monkeyspeak.com ) |
| 14:00:28 | mloskot: | This restriction is often called memory alignment: the multi-byte value may only appear at memory locations which are integer multiples of some number. |
| 14:00:32 | strk: | I konw there's a MAXALIGN macro in postgresql, it's weird that it alignes to 4 |
| 14:00:34 | mloskot: | *some number* |
| 14:00:48 | mloskot: | I don't care about all the stuff that has GNU in its name |
| 14:00:52 | mloskot: | but I care about portable stuff |
| 14:00:57 | mloskot: | portable stuff says "some number" |
| 14:01:09 | mloskot: | so why you've chosen 8 as the "some number" |
| 14:01:53 | strk: | I picked 8 as that's the max size of primitive values we need ( doubles ) |
| 14:01:54 | mloskot: | strk: this way, we will never found common language |
| 14:02:12 | mloskot: | strk: yes, I understand it |
| 14:02:22 | mloskot: | but it's invalid because every type has different alignment |
| 14:03:14 | strk: | band data is what we care about, and every pixel type is aligned at 8-byte boundary ( 8, 4, 2 or 1 byte ) |
| 14:03:38 | strk: | 8 is the catch-all boudary |
| 14:04:04 | mloskot: | deserializer gets memory allocated by postgresql, this memory - as tests show - is not guaranteed to be aligned to 8 |
| 14:04:13 | mloskot: | I mean, ptr % 8 == 0 |
| 14:04:42 | strk: | supposedly, the deserializer should get memory associated with a data type, for which alignment is specified by CREATE TYPE definition |
| 14:05:19 | strk: | CREATE TYPE raster ( alignment = double, ... |
| 14:05:27 | mloskot: | The stride may vary between different data types on one platform, and between the same type on different platforms. |
| 14:05:30 | mloskot: | The stride may vary between different data types on one platform, and between the same type on different platforms. |
| 14:05:36 | mloskot: | http://www.monkeyspeak.com/alignment/ |
| 14:05:38 | sigq: | Title: Computing Memory Alignment Restrictions of Data Types in C and C++ ( at www.monkeyspeak.com ) |
| 14:05:44 | strk: | http://www.postgresql.org/docs/8.2/static/sql-createtype.html |
| 14:05:45 | sigq: | Title: PostgreSQL: Documentation: Manuals: PostgreSQL 8.2: CREATE TYPE ( at www.postgresql.org ) |
| 14:05:58 | strk: | "The alignment parameter specifies the storage alignment required for the data type." |
| 14:08:53 | mloskot: | strk: get your original code |
| 14:09:12 | mloskot: | in *deserialize* function, find |
| 14:09:13 | mloskot: | ptr = ( const uint8_t* )serialized + sizeof( struct rt_raster_serialized_t ); |
| 14:09:20 | mloskot: | put there |
| 14:09:20 | mloskot: | ctx->info( "XXX: First is aligned to 8-bytes: %d", ( 0 == ( ( ( uint64_t )ptr ) % 8 ) ) ); |
| 14:09:26 | mloskot: | in following line |
| 14:09:34 | mloskot: | Then run this simple session |
| 14:09:35 | mloskot: | http://osgeo.pastebin.com/m33d216aa |
| 14:09:36 | sigq: | Title: osgeo private pastebin - collaborative debugging tool ( at osgeo.pastebin.com ) |
| 14:09:42 | strk: | that's rt_core's "deserialize" function ? |
| 14:09:47 | mloskot: | yes |
| 14:09:55 | mloskot: | and find what the XXX message says for the second select, rid = 2 |
| 14:10:21 | mloskot: | execute INSERT then SELECT with where == latest rid |
| 14:10:31 | mloskot: | and observe what you WKB output get |
| 14:10:36 | mloskot: | + what XXX message says |
| 14:10:40 | strk: | and the 'serialized' comes from PG_DETOAST_DATUM ? |
| 14:11:20 | mloskot: | it comes from |
| 14:11:21 | mloskot: | rt_raster_deserialize( rt_context ctx, void* serialized ) |
| 14:11:27 | mloskot: | which is called by RASTER_out |
| 14:11:29 | mloskot: | so, yes |
| 14:12:25 | mloskot: | Here is the original report |
| 14:12:25 | mloskot: | http://postgis.refractions.net/pipermail/postgis-devel/2009-April/005364.html |
| 14:12:26 | sigq: | Title: [postgis-devel] [WKT Raster] Random bands truncation ( at postgis.refractions.net ) |
| 14:13:03 | mloskot: | strk: if you will make 3 or 5 or more insertions of the same raster, the one I gave you above |
| 14:13:05 | mloskot: | you will see this: |
| 14:13:07 | mloskot: | http://osgeo.pastebin.com/d73695eb |
| 14:13:08 | sigq: | Title: osgeo private pastebin - collaborative debugging tool ( at osgeo.pastebin.com ) |
| 14:13:17 | strk: | I'm asking on #postgresql about that |
| 14:13:29 | strk: | one thing worth researching on is the VAR_DATA( ) macro |
| 14:13:41 | mloskot: | deserialization leaves 4 bytes of zeros at the end of some bands |
| 14:13:54 | strk: | but I dubt that's the issue or you'd get very bogus results right from the start if we weren't starting at the correct "data" ( ie: past the size ) |
| 14:13:56 | mloskot: | Not to talk to much abou tthis |
| 14:14:17 | mloskot: | Simply, validating pointer to raster header only, which is statically 64 bytes long |
| 14:14:39 | mloskot: | gives false result, I mean, says that address is not evenly dividable by 8 |
| 14:15:00 | mloskot: | it false randomly, sometimes it is % 8 sometimes it is not |
| 14:15:10 | mloskot: | Just for the ptr to header |
| 14:15:17 | mloskot: | no bands, no other data |
| 14:15:47 | strk: | the whole castle drops here |
| 14:15:49 | mloskot: | Isn't it enough to assume the % 8 assumption on memory obtained from postgresql is an unstable assumption? |
| 14:16:10 | strk: | not really |
| 14:16:21 | mloskot: | how could it be |
| 14:16:26 | strk: | but we may add very early padding |
| 14:16:41 | strk: | to ensure start of header is there ( on 8-byte boundary ) |
| 14:16:45 | mloskot: | but the structure is *statically* sized to 64 bytes |
| 14:16:49 | mloskot: | no "dynamic" padding |
| 14:16:50 | mloskot: | you cad |
| 14:16:52 | mloskot: | you get |
| 14:16:54 | mloskot: | like |
| 14:17:05 | mloskot: | ptr = alloc( mystruct ); //mystruct is always 64 bytes |
| 14:17:12 | mloskot: | ptr % == 0 // fails |
| 14:17:51 | mloskot: | If this simple case is unstable, why to assume it will be stable for straams glued from different memory chunks |
| 14:17:53 | strk: | yes, got it |
| 14:18:29 | strk: | can't hard-code that 8 value ... mmm |
| 14:18:46 | mloskot: | you can, if you rely on pointers arithmetic |
| 14:19:09 | mloskot: | Here is my simple test that shows the unstability of this assumption above |
| 14:19:10 | mloskot: | http://osgeo.pastebin.com/m514cfe64 |
| 14:19:11 | sigq: | Title: osgeo private pastebin - collaborative debugging tool ( at osgeo.pastebin.com ) |
| 14:19:12 | strk: | the whole point is work fine on different platforms |
| 14:19:22 | strk: | the padding thing is only meant to be used internally, in the same host |
| 14:19:22 | mloskot: | Sometimes you see |
| 14:19:24 | mloskot: | XXX: First is aligned to 8-bytes: 1 |
| 14:19:26 | mloskot: | but sometimes |
| 14:19:27 | mloskot: | XXX: First is aligned to 8-bytes: 0 |
| 14:19:30 | strk: | from serialized to in-memory and used |
| 14:19:58 | mloskot: | yes, it's OK |
| 14:19:59 | strk: | the RFC is wrong at this point |
| 14:20:07 | mloskot: | strk: back to pudding |
| 14:20:10 | mloskot: | read the doc I linked above |
| 14:20:26 | mloskot: | it's much better than GNU'ish one, as it explains the problem in portable way |
| 14:20:37 | mloskot: | Simply |
| 14:20:46 | mloskot: | struct { char c; }; |
| 14:20:59 | mloskot: | struct T { char int; }; |
| 14:21:05 | mloskot: | p = alloc( T ) |
| 14:21:11 | mloskot: | what is ptr % ??? |
| 14:21:13 | mloskot: | 8 oir 4 |
| 14:21:18 | mloskot: | it is 4 |
| 14:21:22 | mloskot: | but |
| 14:21:24 | danb: | I've read that PostGIS uses R-Tree over GIST. Is there a reason why it doesn't use B-Tree over space-filling-curves( z-order )? z-order feels simpler |
| 14:21:31 | mloskot: | struct T { double x; }; |
| 14:21:34 | mloskot: | p = alloc( T ) |
| 14:21:43 | mloskot: | p % 8 == ? or 4 ? |
| 14:21:56 | strk: | was a poor way to emulate postgresql ALIGNOF in the corelib |
| 14:22:19 | strk: | it turns out that ALIGNOF_DOUBLE( ) would likely use 4 on 32bit syste and 8 on 64bit one |
| 14:22:27 | strk: | or, MAXALIGN for that matter |
| 14:22:46 | strk: | postgres guys suggest checking pg_config.h about that ( should be platform specific ) |
| 14:22:56 | mloskot: | it also looks that it would be good to have some functions/macros for all these operations |
| 14:23:12 | mloskot: | I mean, all this logic in single place |
| 14:23:13 | strk: | all we want to guarantee is that we can read doubles from double-typed bands w/out memcopying more then needed |
| 14:23:31 | mloskot: | y |
| 14:23:52 | strk: | separation of pg/core stroke back |
| 14:24:36 | mloskot: | strk: I added a bunch of dirty funcs starting with d_ |
| 14:24:51 | mloskot: | I'm going to move them to dbgutils.h|.c or sth like this |
| 14:25:05 | strk: | this discussion would best be in the postgis-devel list |
| 14:25:20 | strk: | alignment was one of the research fields for a new postgis internal format too |
| 14:25:26 | mloskot: | probably, if you think you have time for this, do it |
| 14:25:38 | strk: | I don't, unfortunately |
| 14:25:48 | mloskot: | I've fixed it what means that all data I have work well on 32 and 64 bit platforms |
| 14:26:01 | mloskot: | but as I indicated in the svn log, big bang is expected |
| 14:26:13 | strk: | eh... |
| 14:26:43 | strk: | would take some ARM to test maybe |
| 14:27:32 | mloskot: | ARM will be fun |
| 14:30:33 | mloskot: | ARM may want to flood us with misalignment exceptions or may not like the way we calculate addresses and access memory |
| 14:30:54 | mloskot: | That's why regular pointers arithmetic is the key of portability |
| 14:31:00 | strk: | I've a qemu arm system setup |
| 14:31:41 | strk: | oh well, we'll see |
| 14:31:49 | strk: | at worst, we'll fold back to memcpy as postgis does |
| 14:32:01 | strk: | after all WKTRaster is supposed to be "seamless integrated" :P |
| 14:32:23 | mloskot: | strk: also, is there reason why all alloc'ed memory is not zeroed ? |
| 14:32:34 | strk: | good night |
| 14:32:37 | mloskot: | I memset it with 0x2D byte as marker |
| 14:32:40 | mloskot: | night |
| 15:47:42 | nan8: | why returns that one true? select ( select count( * ) from ( select geomfromtext( 'POINT( 499502.455032845 5371995.29454909 )' ) as g union select geomfromtext( 'POINT( ↵ |
| 15:47:43 | nan8: | 499502.4500000 5371995.300000 )' ) ) as a )=1; |
| 15:48:04 | nan8: | ah bad wrap-wound sorry |
| 15:48:18 | nan8: | select ( select count( * ) from ( select geomfromtext( 'POINT( 499502.455032845 5371995.29454909 )' ) as g union select geomfromtext( 'POINT( 499502.4500000 5371995.300000 )' ) ) as a )=1; |
| 15:48:53 | nan8: | ( at least it does on debian/lenny, postgis 1.3.3-3 ) |
| 15:49:39 | nan8: | ( the question behind that one is - what exactly does union mean in that context ) |
| 16:03:58 | pramsey: | your union is across heterogenous types |
| 16:04:01 | pramsey: | int and bool |
| 16:04:17 | pramsey: | I think it's just returning hte last one |
| 16:11:10 | nan8: | select '010100000000000000B07C1E414E6210C0167E5441'::geometry union select '010100000000000000B07C1E41CEFBFFDF167E5441'::geometry; |
| 16:11:17 | nan8: | returns 1 row |
| 16:11:33 | nan8: | select astext( '010100000000000000B07C1E414E6210C0167E5441'::geometry ) union select astext( '010100000000000000B07C1E41CEFBFFDF167E5441'::geometry ); returns: |
| 16:11:38 | nan8: | POINT( 499500 5371995.001 ) |
| 16:11:42 | nan8: | POINT( 499500 5371995.499999 ) |
| 16:23:14 | nan8: | i guess the real question is why: select '010100000000000000B07C1E414E6210C0167E5441'::geometry='010100000000000000B07C1E41CEFBFFDF167E5441'::geometry; returns true |
| 16:32:36 | nan8: | select ST_geometry_eq( '010100000000000000B07C1E414E6210C0167E5441'::geometry,'010100000000000000B07C1E41CEFBFFDF167E5441'::geometry ) returns true but select ST_equals( '010100000000000000B07C1E414E6210C0167E5441'::geometry,'010100000000000000B07C1E41CEFBFFDF167E5441'::geometry ); returns false ( as expected ) |
| 16:43:38 | nan8: | ok - it seems operator '=' means ST_geometry_eq => lwgeom_eq gets called which first constructs a bbox |
| 16:44:17 | nan8: | => the reason above call returns true is closely related to: |
| 16:44:36 | nan8: | select astext( expand( '010100000000000000B07C1E414E6210C0167E5441'::geometry,0.0 ) )=astext( expand( '010100000000000000B07C1E41CEFBFFDF167E5441'::geometry,0.0 ) ); returning true, too |
| 16:58:28 | nan8: | strange: |
| 16:58:56 | nan8: | select ymin( g ),ymax( g ) from ( select box3d( '010100000000000000B07C1E414E6210C0167E5441'::geometry ) as g ) as a; works as expected but: select ymin( g ),ymax( g ) from ( select box2d( '010100000000000000B07C1E414E6210C0167E5441'::geometry ) as g ) as a; does not |
| 17:15:07 | nan8: | after all it is just a floating point precision issue :-( |
| 22:41:23 | dcohen: | hey everyone. i gots me a question. |
| 22:42:00 | dcohen: | im trying to make a spatial query that looks something like this: |
| 22:42:01 | dcohen: | SELECT * FROM "layer_vt_counties" WHERE ( ST_Contains( the_geom, 'GEOMETRYCOLLECTION( ...A BUNCH OF GEOMETRIES... )' ) ) |
| 22:42:32 | dcohen: | and I am getting a big fat error that looks like this: |
| 22:42:33 | dcohen: | Relate Operation called with a LWGEOMCOLLECTION type. This is unsupported |
| 22:43:02 | dcohen: | i understand what its suggesting |
| 22:43:15 | dcohen: | but are there any workarounds here? |
| 22:43:27 | dcohen: | i imagine that this is a common issue. |
| 22:43:48 | dcohen: | any help would be greatly appreciated. |