#MAPSERVER IRC Log - 2010-01-18

For logs after Feb 3, 2007, all times are GMT-8. Prior logs are GMT-9.
Back to Logs
04:51:08 aboudreault: hi FrankW , around?
04:52:59 FrankW: aboudreault: I am now.
04:55:29 aboudreault: About your "one-query implementation for OGR", I did some tests last week ( including the autustyling you fixed ) and everything was "OK", but I wonder if this is really needed to be backported to 5.6 ? Isn't it only a "enhancement" for performance?
04:56:30 aboudreault: Though I don't know If I tested ALL possible test case... there are a lot.
04:57:24 FrankW: It is effectively just a performance improvement.
04:57:48 FrankW: But where applicable it can turn an operation that is O( n^2 ) in the number of features into an operation that is O( n ).
04:57:59 FrankW: so the improvement can be very dramatic.
04:58:08 FrankW: the difference between usable and unusable.
04:58:38 FrankW: I'm a bit queasy about backporting it myself.
04:58:47 aboudreault: right, I see.
04:59:44 aboudreault: I'm am a bit too... just don't want to break anything in 5.6.2 :/
05:29:15 CIA-48: hobu * r9702 /trunk/docs/Makefile: add pdf builder target ( not working yet )
05:30:42 aboudreault: hobu: still no answer from the part of the sphinx-dev about the link problem. maybe my post wasn't clear :/
05:33:53 CIA-48: hobu * r9703 /trunk/docs/labels.py: import tweak to support building with Sphinx 1.0
05:35:00 CIA-48: hobu * r9704 /branches/branch-5-6/docs/labels.py: backport r9703
05:37:07 CIA-48: hobu * r9705 /trunk/docs/de/images/copyright-image.png: deinterlace image for rst2pdf ( PIL ) support someday
05:43:59 aboudreault: FrankW: since 6.0 is still far away, I'm going to backport the ogr change in 5.6, and hope everything will be ok. But I think it should be ok.
05:44:17 FrankW: ok, thanks.
05:44:31 hobu: aboudreault: might not have been clear enough. I am investigating right now to see if I can do it
05:44:55 FrankW: aboudreault: You know there are two commits for it, right? The main fix, and then a fix for the fix?
05:45:06 aboudreault: hobu: thanks, let me know if you need anything else.
05:45:16 aboudreault: FrankW: yep the initial one + the autostyling fix.
06:26:40 rbranson: FrankW: btw, I hacked out a quick tool to compress the shapefile with LZO... not so great, 10-15% compression
06:27:53 FrankW: rbranson: that is somewhat underwhelming.
06:28:55 rbranson: FrankW: quite, so I'm thinking that I might pursue converting shapefiles to single-precision
06:30:03 rbranson: I looked at differential coding as you suggested, which would probably give the best case, but it would be pretty complex to implement and probably prone to bugs
06:30:11 FrankW: It would be an interesting activity to develop a feature format that is compact but preserving fast random reading.
06:30:50 rbranson: i have been reading edu papers on it, material is scant to be honest
06:30:58 rbranson: most of it focuses on mesh compression
06:32:08 rbranson: single-precision would work well for us, because we have large shapefiles used for display and they're all in a meter-based projection, single-precision accuracy gets it down to 1/4 meter, which at the most zoomed in point is hundredths of a pixel
07:17:31 mdev: hi, does anyone know how to set whether shadow or outline falls behind the other in a label?
07:17:45 mdev: order doesn't seem to do it
07:26:46 aboudreault: not sure to get your point..... "falls behing the other" ?
07:28:01 mdev: whether the shadow overlaps outline or outline overlaps shadow
07:30:14 aboudreault: I think outline can only be applied on the label. not the shadow
07:31:28 aboudreault: not sure if I've ever seen a "shadow" with an outline
07:31:48 mdev: why not?
07:31:54 mdev: why can't I have a label with an outline
07:31:59 mdev: and then shadow that blob
07:32:00 mdev: or
07:32:15 mdev: have a label with a shadow and outline that blob of label+shadow
07:32:41 nhv: draw the label twice slightly offset in shadow and foreground color
07:32:43 mdev: is there any mechanism for determining if shadow/outline covers the other if they overlap
07:32:50 mdev: oh
07:33:28 mdev: cause I had sucess with some of my labels with shadow/outline but not others
07:33:38 mdev: so I'm not really sure what is determining the order they are displayed in
07:34:04 mdev: swapping order of declaration didn't change anything
07:35:07 aboudreault: the declaration order has no effect
07:35:41 aboudreault: the only thing that determine the order they are displayed is the c code
07:39:22 hobu: gislars: ping
08:06:27 gislars: peng
08:07:43 hobu: gislars: the reason we aren't able to generate any links to en docs is because we run the de as a "separate" sphinx tree, and sphinx has no way to resolve the references
08:09:21 gislars: ok... that was the setup to get the translation in place
08:09:40 gislars: I had no other idea
08:10:00 hobu: It is going to be rather difficult to have sphinx generate links for references that don't exist, because the *kind* of reference ( ie, file vs h1, etc ) matters in our case, and we don't know which kind it is
08:10:06 gislars: sphinx doesn't support multilingual docs AFAIK
08:11:17 hobu: I will reply to aboudreault's email on the list with some more detail and see if Georg has some other ideas
08:12:20 gislars: it sounds thats not getting easier
08:13:12 hobu: I have an idea, but it would complicate things a little bit. What we could do is have all of the translation languages use the reference tree of the en tree *after* their own. But I don't know how to accomplish this, so I will ask
08:15:52 gislars: sorry that I'm not much help on this topic... but if there is anything to help, just ping me
08:16:05 hobu: will do
08:38:15 CIA-48: hobu * r9706 /trunk/docs/ ( Makefile conf.py ): ePub support
08:39:31 CIA-48: hobu * r9707 /branches/branch-5-6/docs/ ( Makefile conf.py ): backport r9706
09:15:07 CIA-48: aboudreault * r9708 /trunk/mapserver/ ( HISTORY.TXT configure configure.in maphttp.c ): Fixed curl proxy auth support for http connections ( #571 )
09:48:00 CIA-48: aboudreault * r9709 /branches/branch-5-6/mapserver/ ( HISTORY.TXT mapogr.cpp ): Backporting implementation of RFC 52 LayerResultsGetShape support for OGR connection type in branch 5-6. ( #3069 )
10:08:02 aboudreault: pramsey: Are you working on #3259 ? Would you like I take a look at it?
10:09:07 pramsey: aboudreault: I have not started on it, so feel free.
10:09:19 aboudreault: ok
11:59:45 mdev: is it possible to make the symbol associated with the same point as a particular label vanish if the respective label cannot be displayed due to collisions?