| 06:43:24 | mloskot: | Anyone using wktraster here? |
| 06:43:57 | mloskot: | or anyone using postgis from svn built with geos from svn |
| 07:42:51 | ribo: | running psql -d <dbname> -f lwpostgis.sql; gives me an error: psql:/usr/share/doc/postgis-1.3.2/lwpostgis.sql:44: NOTICE: type "histogram2d" is not yet defined DETAIL: Creating a shell type definition. psql:/usr/share/doc/postgis-1.3.2/lwpostgis.sql:44: ERROR: incompatible library "/usr/lib64/pgsql/liblwgeom.so": missing magic block HINT: Extension libraries are required to use the PG_MODULE_MAGIC macro. |
| 07:42:57 | ribo: | thoughts? |
| 07:44:09 | ribo: | er crap |
| 07:44:29 | ribo: | I bet 1.3.2 doesn't have magic blocks now required by postgresql |
| 07:46:40 | mloskot: | if you use lwpostgis.sql that comes together with the liblwgeom library, then this is not postgis fault |
| 07:46:42 | simplexio: | ribo: that would be my best quess.. update postgis to latest stable |
| 07:46:58 | mloskot: | if you mix postgis sql script with diff library, then you are shoting yourself in the foot |
| 07:47:22 | mloskot: | if the former is true, then the error is related to your OS environment/conifg |
| 07:51:03 | ribo: | magic blocks apparently are required for pgsql 8.2+ |
| 07:51:27 | ribo: | RHEL rpms are only at postgis 1.3.2 :/ |
| 07:51:57 | ribo: | guess I have to build some more RPMs |
| 07:51:59 | ribo: | oh joy |
| 07:52:34 | ribo: | mloskot: I'm using the one that came with postgis |
| 07:52:52 | ribo: | I have no idea where liblwgeom is coming in |
| 07:53:03 | mloskot: | it's postgis lib |
| 07:54:05 | ribo: | hmmmmmmm |
| 07:54:45 | mloskot: | ribo: if you've discovered that postgis 1.3.x does not work with your version of pgsql but this version is supposed to be supported, it is likely a bug |
| 07:54:55 | mloskot: | ribo: so would be nice if you could report |
| 07:55:22 | ribo: | I'm going to see if I get the same behavior with the latest |
| 07:55:53 | mloskot: | see 1.3 manual for required version of pgsql |
| 09:07:53 | strk: | hello geospatial crowd |
| 13:17:03 | drewby: | Hi, I have an algorithm in php that I'm having trouble rewriting in sql. |
| 13:18:08 | strk: | i bet |
| 13:18:10 | strk: | try plpgsql ? |
| 13:19:20 | drewby: | I'll look into it. It's just frustrating cause I have a coworker who knows enough sql to get this done but lacks the mathematical understanding, and I'm the reverse. |
| 13:19:32 | drewby: | And I'm having trouble communicating what I want to do. |
| 13:21:54 | mloskot: | drewby: I'm pretty sure it'll be easier for you to grasp plpgsql , than explaining him the maths you want to implement |
| 13:22:40 | drewby: | maybe, but it's not hard math, I just suck at speaking >< |
| 13:24:29 | mloskot: | perhaps you can find #oratory channel helpful :- ) |
| 13:25:11 | drewby: | haha |
| 13:30:18 | drewby: | how can I get the number of points on a linestring and/or where is the documentation that would teach me such things |
| 13:31:17 | strk: | postgis manual, should be online too ( postgis.org ) |
| 13:31:24 | mloskot: | drewby: surprise surprise :- ) |
| 13:31:51 | mloskot: | drewby: tell me as a user, is it truly hard to find the manual? |
| 13:31:52 | drewby: | in this? http://www.postgis.org/documentation/manual-1.3/ |
| 13:31:53 | sigq: | Title: PostGIS 1.3.5 Manual ( at www.postgis.org ) |
| 13:32:09 | drewby: | mloskot, sometimes it can be hard to find a given topic in the manual |
| 13:32:37 | mloskot: | so, you have tried and you've found it hard, right? |
| 13:33:01 | mloskot: | tell me, perhaps the manual is bad indeed |
| 13:33:09 | drewby: | ST_NumPoints |
| 13:33:11 | drewby: | ^^ |
| 13:33:15 | mloskot: | then I won't waste time and run to report a bug :- ) |
| 13:34:05 | strk: | does it mention NumPoints too ? |
| 13:34:15 | strk: | w/out the ST_ prefix ? |
| 13:34:39 | drewby: | not really |
| 13:34:50 | drewby: | it's used in 1 example but never discussed |
| 13:36:01 | : | * strk takes a point in the bug finding race : ) |
| 13:36:12 | mloskot: | : ) |
| 13:44:28 | : | * drewby is trying to offset points by the normals of lines made by the points. |
| 13:45:21 | strk: | how do you deal with shared vertices ? |
| 13:46:24 | drewby: | well this is a table of just linestrings |
| 13:46:39 | drewby: | so currently, not at all |
| 13:47:04 | strk: | a linestring is not limited to 2 vertices |
| 13:47:09 | drewby: | oh okay |
| 13:47:13 | drewby: | I see what you're saying |
| 13:47:36 | drewby: | I take the unit vector of the sum of the unit vectors of the normals of each line surrounding the point. |
| 13:48:26 | drewby: | and then multiply that by the desired offset and add it to the coordinates of the central point |
| 13:48:56 | strk: | and construct a new line using WKT ? |
| 13:49:24 | drewby: | well, currently the algorithm is only in php and operates on a hard-coded array |
| 13:49:46 | drewby: | and seems to be working fine with that, despite my best attempts to feed it screwy points |
| 13:50:04 | drewby: | I am, however, still working on translating said algorithm into sql. |
| 13:50:39 | strk: | I think a C stored procedure would be preferrable |
| 13:50:50 | strk: | if you need speed... |
| 13:51:25 | strk: | or may consider pl/perl which is supported by postgresql ( more easily maps to php ) |
| 13:52:22 | drewby: | speed would probably be good, I know enough c to write out this algorithm, but I know nothing stored procedures ( or postrgres ) for that matter. |
| 13:52:45 | : | * drewby is just a wee code monkey for the maryland traffic system. |
| 13:52:47 | strk: | postgis has a nice api for stored procs |
| 13:53:06 | strk: | just not very friendly to extensions yet |
| 13:53:28 | strk: | ie: it's somewhat hackish to do that in a reliable way ( no public headers installd ) |
| 13:54:36 | strk: | what would this offsetting be used for ? |
| 13:54:39 | strk: | if I may ask |
| 13:56:11 | drewby: | well we've got a bunch of roads, and we want to increase the distance between the roads at higher zoom levels so that they don't look like a single line |
| 13:58:32 | strk: | they run in parallel ? |
| 13:59:19 | drewby: | for the most part |
| 14:02:05 | strk: | and you only want to offset that portion ? |
| 14:02:24 | drewby: | how do you mean? |
| 14:03:09 | strk: | I'm trying to think about the SQL interface you'll need : ) |
| 14:04:27 | drewby: | http://pastebin.ca/1377332 |
| 14:04:28 | sigq: | Title: pastebin - line offset algorithm - post number 1377332 ( at pastebin.ca ) |
| 14:06:43 | strk: | too much code : ) |
| 14:06:50 | drewby: | fair enough |
| 14:08:18 | drewby: | http://zenwarfare.com/myshape.png <-- the output |
| 14:08:54 | strk: | those ones run in parallel for the whole run |
| 14:09:21 | drewby: | well both the blue and the green were created from the red |
| 14:09:44 | drewby: | which is not exactly what we're doing with our map data, but really it's close enough I'd think |
| 14:10:53 | strk: | it lacks the part of the algorithm when you find out *when* you need to offset, and to *which* direction ( based on what else is around ) |
| 14:12:45 | drewby: | well the when is basically a WHERE clause when direction='NORTHBOUND' or direction='EASTBOUND' etc... |
| 14:15:07 | pramsey: | I was thinking about this problem... |
| 14:15:24 | drewby: | pramsey: yeah? how far did you get? |
| 14:15:26 | : | * pramsey tries to find if he wrote down anything about it. |
| 14:15:27 | strk: | GEOS has code for that btw ( just the offset part, not the rest ) |
| 14:15:57 | pramsey: | Oh, I didn't actually *do* anything, it just struck me as asomething that should necessarily be part of our LRS suite, which is a bit... messy right now. |
| 14:16:13 | pramsey: | one side of LRS is "given a point and line tell me the measure" |
| 14:16:27 | pramsey: | the other is "given a line and measure, tell me the point" |
| 14:16:43 | pramsey: | and the second one should have some optional parameterizations that also allow you to set the offset. |
| 14:17:46 | strk: | uhm |
| 14:18:51 | pramsey: | ( or did I misunderstand, and this is full line offsets? ) |
| 14:19:41 | pramsey: | ah, I see |
| 14:19:48 | drewby: | pramsey: http://zenwarfare.com/myshape.png <- making blue and green from the vertices in red |
| 14:20:39 | strk: | I didn't understand yet if it's full line or not |
| 14:20:50 | strk: | from drewby description I think it isn't |
| 14:21:13 | strk: | so the "drunk pedestrian" function might be for him |
| 14:21:42 | pramsey: | fun. That's non-trivial in generality, so good work getting what you have already! There's single-sided buffering in GEOS, so you could get a C-bound version of the capability with relatively little work |
| 14:23:16 | drewby: | does full line offset mean you offset every point in the line by the same amount? |
| 14:24:16 | strk: | pretty much what you're doing drawby |
| 14:24:22 | strk: | in that drawing |
| 14:24:32 | drewby: | oh okay |
| 14:24:34 | : | * pramsey finally reads the actual problem description. |
| 14:24:54 | strk: | pramsey: what I don't get is how he decides when to offset and when not |
| 14:24:56 | pramsey: | aren't you going to get some unpleasant artefacts where your offset lines have to join back up to your normal lines, no matter how you do this? |
| 14:25:06 | strk: | even in the drawing, there's an intersection introduced by offsetting |
| 14:25:19 | strk: | so, to fix an unpleasant rendering, it introduces others |
| 14:26:03 | strk: | it seems to me he should be doing some sort of collision detection |
| 14:26:33 | : | * pramsey thinks |
| 14:26:44 | drewby: | I'll get to the fancy stuff once I have this in a form that our map guys can use |
| 14:27:31 | strk: | drewby: that's why I was trying to figure the interface, as I guess that's what the map guys will use |
| 14:27:54 | strk: | doesn't matter if it's sql, pl/pgsql, pl/perl or C |
| 14:28:05 | strk: | for them it's an SQL function |
| 14:28:18 | drewby: | i'm just frustrated, I feel like I should pass this off to somebody who knows more about postgre |
| 14:28:29 | strk: | here it is |
| 14:29:29 | strk: | I'm available for postgis development work atm |
| 14:36:45 | drewby: | thanks all |
| 14:36:46 | drewby: | bye bye |
| 14:38:16 | strk: | short budget for the drunk pedestrian project .... oh well |
| 15:39:08 | mloskot: | pramsey: ping |
| 15:39:17 | pramsey: | mloskot: |
| 15:39:55 | mloskot: | pramsey: we ( geos ) are released, right? |
| 15:39:59 | pramsey: | yes |
| 15:40:32 | mloskot: | so, can I play a game with trunk that may break nmake makefiles for a while |
| 15:41:08 | mloskot: | I'd like to submit some improvements to nmake makefiles, but chances are I break something for a day or two |
| 15:41:23 | mloskot: | I mean, building geos with nmake/msvc |
| 15:41:25 | pramsey: | if you aren't breaking API and think it's suitable for 3.1.1? |
| 15:41:29 | pramsey: | then yes |
| 15:41:48 | mloskot: | no changes in code, only makefiles or nmake |
| 15:42:04 | pramsey: | do you think it's suitable : ) |
| 15:42:16 | mloskot: | what you mean? |
| 15:43:03 | mloskot: | ah, it's not Q :- ) |
| 15:43:04 | mloskot: | ok |
| 15:44:18 | pramsey: | no, it's a question, it's one for you. |
| 15:44:38 | pramsey: | I'm asking you to exercise your judgement as a project person on whether putting it into 3.1.x is a good idea |
| 15:44:58 | pramsey: | if it's not, then we should initiate a branch |
| 15:45:23 | mloskot: | 3.1.0 is releasd |
| 15:45:25 | mloskot: | released |
| 15:45:42 | mloskot: | So, I consider trunk as dev branch which targets 3.2 |
| 15:45:45 | mloskot: | am I correct? |
| 15:45:51 | : | * mloskot thinks in gdal model |
| 15:48:22 | pramsey: | no |
| 15:48:30 | pramsey: | the GDAL model has actual active development : ) |
| 15:48:49 | mloskot: | I'll submit my news as ticket + patch to avoid problems, then folks will judge |
| 15:48:53 | pramsey: | because things move so slowly in GEOS world, I have been keeping the trunk as the stable development branch until a branch needs to occur |
| 15:49:17 | pramsey: | that way people don't have to patch twice for fixes when the only thing really happening is maintenance |
| 15:49:32 | pramsey: | if we're beyond maintenance, then, hey presto, let's branch |
| 15:50:12 | mloskot: | I understand, but this model has disadvantages, for instance to introduce new functions ( ie. I've been thinking about porting affine stuff from JTS ) I'll need to wait untill new stable 3.2 |
| 15:50:15 | mloskot: | to not to break 3.1.x |
| 15:50:44 | pramsey: | we can branch any time |
| 15:50:55 | mloskot: | I don't think we are beyond maintenance, but occasionally we may want to introduce new stuff |
| 15:50:59 | pramsey: | but in terms of breaking API, yes, I agree, it has disadvantages |
| 15:51:04 | mloskot: | like the building config I've been working on |
| 15:51:28 | pramsey: | I'm not sure how we get around that, as a library we have to offer some predicability, and adding new functions to the API in minor releases seems ungood |
| 15:51:57 | mloskot: | yes. looks like we'll fall back to branching |
| 15:52:10 | mloskot: | s/we'll/we may need/gc |
