| 03:31:10 | sigq: | geosfeed: Ticket #250 ( defect closed ): geos_contains( multipolygon, polygon ) returns false when it should return true <http://trac.osgeo.org/geos/ticket/250#comment:3> |
| 09:52:16 | CIA-34: | pramsey * r4063 /branches/1.3/ ( ChangeLog NEWS doc/postgis.xml ): Changes in advance of 1.3.6 |
| 09:53:53 | dassouki: | http://www.neatorama.com/2009/04/27/the-geography-of-the-seven-deadly-sins/ |
| 09:53:54 | sigq: | Title: The Geography of the Seven Deadly Sins - Neatorama ( at www.neatorama.com ) |
| 09:56:08 | CIA-34: | robe * r4064 /trunk/ ( 3 files in 2 dirs ): more doxygen comment cleanup |
| 09:56:59 | CIA-34: | pramsey * r4065 /tags/1.3.6/: tag 1.3.6 |
| 09:58:10 | CIA-34: | pramsey * r4066 /tags/1.3.6/Version.config: Alter version in tag, per our silly procedure. |
| 11:04:00 | CIA-34: | kneufeld * r4067 /branches/1.3/Version.config: bumped branch svn to 1.3.7SVN |
| 11:38:50 | zanberdo: | I seek guidance. I have two tables, one with a point geometry and another with a multi polygon geometry. I want to update a field for each of the records in the table with the points with a field from the table with the multi polygon. I what to qualify the update where the point in table 1 is within the multi polygon of table two. ( more ) |
| 11:40:36 | zanberdo: | I know I can query records from table 1 that are within the polygon of table 2 using ST_WITHIN as: select t1.field from table1 as t1, table2 as t2 where ST_WITHIN( t1.the_geom, t2.the_geom ) |
| 11:41:18 | zanberdo: | but I'm not clear how to structure the update statement. I want to update table1.city with table2.name where table1.the_geom within table2.the_geom... |
| 11:41:20 | zanberdo: | and suggestions? |
| 11:44:52 | strk: | geos svn hung |
| 11:45:13 | strk: | confirmations / refusals ? |
| 11:45:51 | : | * strk expects a refusal from CIA |
| 11:48:05 | CIA-34: | strk * r2459 /trunk/source/ ( 2 files in 2 dirs ): Extend to accept a vector of const Coordinate pointers for snap pointers, fix typo making it clone snap points rather than source points on snapping... |
| 11:51:04 | CIA-34: | strk * r2460 /trunk/source/ ( 4 files in 4 dirs ): Port overlay.snap.GeometrySnapper |
| 12:58:21 | CIA-34: | strk * r2461 /trunk/source/ ( 6 files in 4 dirs ): Port overlay.snap.SnapOverlayOp, update GeometrySnapper to be more useful |
| 13:24:29 | CIA-34: | strk * r2462 /trunk/ ( 25 files in 7 dirs ): Move overlay.validate package files where they belong |
| 13:59:15 | CIA-34: | strk * r2463 /trunk/source/ ( 5 files in 4 dirs ): Port SnapIfNeededOverlayOp |
| 14:17:23 | strk: | uhm |
| 14:17:29 | strk: | and now that the whole system is setup... |
| 14:17:50 | strk: | I don't feel like sacrifying the fantastic BinaryOp : ) |
| 14:50:00 | strk: | pramsey: BinaryOp was our answer to the robustness issues. At that time it was JTS following GEOS IIRC |
| 14:50:22 | strk: | more or less. or at least it was a joint effort. |
| 14:50:39 | pramsey: | OK... and now? |
| 14:52:01 | strk: | now I ported the JTS-proper way of doing that thing |
| 14:52:15 | strk: | only, neither the CAPI nor the XMLTester code use that |
| 14:52:32 | strk: | the JTS-proper way is in Geometry::{overlayOperationHere}( xxx ) |
| 14:52:44 | strk: | while both XMLTester and CAPI use the BinaryOp( ) construct instead |
| 14:53:03 | strk: | could switch both back to the original |
| 14:53:07 | strk: | in XMLTester is still commented out |
| 14:53:16 | strk: | ie: |
| 14:53:16 | strk: | //GeomAutoPtr gRealRes( gA->Union( gB ) ); |
| 14:53:16 | strk: | GeomAutoPtr gRealRes = BinaryOp( gA, gB, overlayOp( OverlayOp::opUNION ) ); |
| 14:53:30 | pramsey: | right, and what's the *difference* ? |
| 14:53:32 | strk: | gA->Union( gB ) <--- would automatically use the snapping heuristic now |
| 14:53:35 | pramsey: | ( this is the part I dno't get ) |
| 14:53:40 | strk: | that's a good question : ) |
| 14:54:05 | strk: | probably not much difference |
| 14:54:09 | strk: | but evil is in details |
| 14:54:14 | pramsey: | no kiddlinh |
| 14:54:28 | strk: | BinaryOp is full of compile-time options |
| 14:54:34 | strk: | what to use and in which order... |
| 14:54:41 | strk: | some steps are enabled, some disabled |
| 14:54:52 | strk: | was a real-world-case driven configuration |
| 14:54:59 | strk: | and fine-tuned for performance IIRC |
| 14:55:15 | strk: | so my feeling is that out-of-the-box the JTS_proper way would be slightly slower |
| 14:55:40 | pramsey: | well, my problem is I'm clueless |
| 14:55:57 | strk: | ic |
| 14:56:02 | pramsey: | so I can't help with useful advice other than to see if the list has any more wisdom |
| 14:56:06 | strk: | well, I was just mentioning for the other thing you asked me : ) |
| 14:56:20 | pramsey: | and to write up a .txt file talking about what we're doing and why w're doing it |
| 14:56:26 | strk: | as if you want to skip JTS it'll create this same situation later : ) |
| 14:56:26 | pramsey: | and committing it to the repo |
| 14:56:34 | pramsey: | ah. |
| 14:57:08 | pramsey: | well, since the splitting problem can be done w/o alterations for the line/line case that opportunity is currently on hold |
| 14:57:36 | strk: | yeah, can probably take lines out of polys, split and then rebuild the polis |
| 15:00:16 | CIA-34: | strk * r2464 /trunk/source/ ( 3 files in 2 dirs ): |
| 15:00:16 | CIA-34: | Bring Geometry port up a revision by having it use SnapIfNeededOp for overlay |
| 15:00:16 | CIA-34: | operations. Note that currently this doesn't affect the C-API nor the XMLTester |
| 15:00:16 | CIA-34: | codes, both using the BinaryOp original class ( not JTS-ported ) doing about the |
| 15:00:16 | CIA-34: | same thing as the SnapIfNeededOp class. |
| 15:19:12 | CIA-34: | strk * r2465 /trunk/source/ ( 3 files in 2 dirs ): Geometry up to 1.112 with a minor bugfix and performance improvement in Geometry::covers |
| 15:39:28 | CIA-34: | strk * r2466 /trunk/source/operation/IsSimpleOp.cpp: Fix memory bug |
| 15:44:41 | strk: | ok, I've a response now to the question: "what's the difference between BinaryOp and SnapIfNeededOp" |
| 15:44:51 | strk: | the latter fails like hell our testsuite |
| 15:45:02 | strk: | better sleep over it |
| 16:00:36 | CIA-34: | strk * r2467 /trunk/source/geom/util/GeometryTransformer.cpp: Fix memory leak on exception |
| 16:09:07 | dassouki: | has anyone used pgrouting here? |
| 20:25:24 | CIA-34: | robe * r4068 /trunk/postgis/ ( 7 files ): doxygen friendly comments |
| 20:40:34 | CIA-34: | robe * r4069 /trunk/postgis/lwgeom_functions_basic.c: doxygen friendly comments |