| 00:23:43 | beatpanic: | hi, it is possible to use SLD inside a .map file? |
| 00:24:15 | beatpanic: | or to make an sld with a desktop gis software and then style it with mapserver? |
| 00:24:26 | beatpanic: | thanks : ) |
| 00:33:04 | lucadelu: | beatpanic: you can make a sld with wgis |
| 00:33:07 | lucadelu: | qgis |
| 00:33:24 | lucadelu: | there is a python plugin for export the sld |
| 00:33:57 | beatpanic: | lucadelu, yep, and then how could run it inside mapserver? I'm looking at the SLD url parameter but I'm not sure |
| 00:35:00 | lucadelu: | beatpanic: i think you can use sld with wms |
| 00:35:09 | lucadelu: | http://mapserver.org/ogc/sld.html |
| 00:35:10 | sigabrt: | Title: SLD MapServer 5.4.2 documentation ( at mapserver.org ) |
| 00:36:03 | beatpanic: | lucadelu, exactly, I'm wondering if it is sufficient to use the SLD=URL parameter to add a layer via wms ( which I'm using ) |
| 00:41:16 | beatpanic: | lucadelu, do you mind to pass me the link of the qgis python script to export in sld? thanks |
| 00:41:38 | beatpanic: | lucadelu, or the python plugin name |
| 00:49:45 | lucadelu: | beatpanic: the name si SLD export |
| 05:14:01 | aboudreault: | FrankW: around? I did a few tests with your rfc 52 changes for OGR ( also tested the autostyling you fixed ), but I'm wondering if this really should to be backported in 5.6. |
| 06:53:15 | aboudreault: | jmckenna: what about branching 5.6 doc? We'll make the "images" folder shared for all languages in the future. |
| 06:55:10 | jmckenna: | i have a couple of questions about this. will respond right after #osgeo fundraising meeting now |
| 06:55:26 | aboudreault: | ah, all right |
| 06:56:48 | gislars: | aboudreault: if I look at http://mapserver.org/dev/en/ the link to the german version contains /trunk/ in the url |
| 06:56:49 | sigabrt: | Title: Welcome to MapServer MapServer 5.4.2 documentation ( at mapserver.org ) |
| 06:57:08 | gislars: | is it because of the some redirects? |
| 06:57:18 | gislars: | or are there two version now online? |
| 06:59:51 | aboudreault: | It's only the link the in the sphinx doc. I'm going to move /dev to /trunk right now. |
| 07:00:28 | gislars: | ok |
| 08:08:29 | CIA-9: | jmckenna * r9689 /branches/branch-5-6/docs/: attempting to create a 5-6 docs branch |
| 08:24:05 | jmckenna: | aboudreault: it seems some things have changed in /osgeo/mapserver/ on xblade14 since last night? meaning: i could have sworn that a 'mapserver-web-directory' existed there, containing trunk docs in html format, and it was what was shown live at http://mapserver.org/dev/ Maybe i am missing something here??? |
| 08:24:43 | jmckenna: | directory missing is 'mapserver-web-new' containing trunk html docs. ? |
| 08:27:25 | jmckenna: | ping me so we can work together on making some sense of it all |
| 08:50:42 | aboudreault: | jmckenna: i deleted -new |
| 08:50:56 | jmckenna: | um ok. |
| 08:50:57 | aboudreault: | use /trunk only |
| 08:51:08 | jmckenna: | i'm looking at it now |
| 08:51:25 | aboudreault: | the /dev was only to do my test when I began to look at the doc. |
| 08:51:56 | jmckenna: | i checked out 'docs.54' and 'docs.56' there |
| 08:52:26 | jmckenna: | i imagine 'docs.56' should be renamed to 'docs' ( as this is the live directory ) |
| 08:52:50 | aboudreault: | hobu is supposed to ask the sphinx folks on the google group about the link problem ( that you can see on /trunk/de/documentation.html ) |
| 08:53:42 | jmckenna: | and i believe we can use the 'docs.54' dir to point to the mapserver_54.pdf ( that we can generate ) |
| 08:54:14 | jmckenna: | err that we can rename ( since i exists in 5.4 ) yikes i hate versions, grrrrrrrrrr |
| 08:54:27 | jmckenna: | this is like pulling teeth lol |
| 08:54:48 | aboudreault: | docs is already the branch 5.4, so we can just rename it |
| 08:55:01 | jmckenna: | yup ( said that ) : ) |
| 08:55:13 | jmckenna: | oh i see what u mean..true true |
| 08:55:32 | aboudreault: | we have to copy/add the redirection folder of that branch in the 5.6 branch |
| 08:56:57 | aboudreault: | I can do it if you want. |
| 08:57:14 | aboudreault: | I can put in place the 5.6 doc online |
| 08:57:21 | jmckenna: | ok |
| 08:57:45 | jmckenna: | i will remove the unnecessary 'docs.54' folder |
| 08:58:00 | aboudreault: | ok, will do the change right now. |
| 09:08:39 | CIA-9: | aboudreault * r9690 /branches/branch-5-4/docs/redirection/ ( mapserver-redirect-trunk.conf mapserver-redirect.conf ): Added redirect-trunk apache config |
| 09:09:40 | CIA-9: | aboudreault * r9691 /branches/branch-5-6/docs/redirection/ ( 4 files ): Added redirection files in 5.6 |
| 09:10:25 | : | * aboudreault starts the doc generation |
| 09:14:48 | jmckenna: | i tried to generate 'docs.56' on xblade14 and got a fatal error. is that what u are doing? |
| 09:16:01 | aboudreault: | yes, I tought you said me "ok" to do it |
| 09:16:19 | aboudreault: | to put in place the 5.6. doc |
| 09:16:37 | jmckenna: | oh i did not understand what that meant. ok sorry, carry on : ) |
| 10:06:58 | aboudreault: | the link of the de/usa flag is not good...... trying to find how this is generated |
| 10:14:40 | hobu: | aboudreault: no, you were supposed to ask the sphinx folks because you have a better understanding of the problem than I do : ) |
| 10:19:02 | aboudreault: | <hobu> I would craft an email to [...], you are right, probably read a "will" rather than "would" |
| 10:19:20 | aboudreault: | will do. |
| 10:22:02 | aboudreault: | hobu: perhaps you know ( on www.mapserver.org ) why the link of the different languages ( the flags ) are not ok? but they are ok in www.mapserver.org/trunk/ |
| 10:23:10 | hobu: | the link generated appears to be http://www.mapserver.org/html/de/index.html |
| 10:23:11 | sigabrt: | Title: Now Hosted on www.mapserver.org ( at www.mapserver.org ) |
| 10:23:16 | hobu: | but you want http://www.mapserver.org/de/index.html |
| 10:23:17 | sigabrt: | Title: Willkommen zum MapServer MapServer 5.6.1 documentation ( at www.mapserver.org ) |
| 10:23:25 | aboudreault: | yes, I don't know where this is generated |
| 10:28:54 | : | * hobu looks |
| 10:29:08 | hobu: | are we branched now? |
| 10:29:20 | hobu: | and the website is running off the branch? |
| 10:30:28 | aboudreault: | 5.6 is branched yes. the website is the branch |
| 10:35:42 | hobu: | aboudreault: check out layout.html in _templates for the problem with the flag |
| 10:35:56 | hobu: | I don't understand the logic or the relative paths in there though. We should ask lars |
| 10:41:36 | aboudreault: | ok, will take a look |
| 11:03:59 | CIA-9: | hobu * r9692 /branches/branch-5-6/docs/_templates/layout.html: don't point to html directory for language flags |
| 11:05:03 | aboudreault: | ha... you can revert this change hobu. I found where to set the target |
| 11:05:17 | hobu: | oh, ok |
| 11:05:22 | aboudreault: | I just uncommentted the line in the Makefile, rebuildind now |
| 11:05:41 | CIA-9: | hobu * r9693 /branches/branch-5-6/docs/_templates/layout.html: revert r9692 |
| 11:09:11 | hobu: | make sure to tweak the crontab if necessary |
| 11:11:00 | hobu: | oh, a locally modified makefile. I don't know that I like that, but best of the worse I suppose |
| 12:12:54 | aboudreault: | hobu: Is it you who updated svn on osgeo server? |
| 12:34:20 | rbranson: | anyone think there would be an interest in LZO compressed shapefiles? |
| 12:35:26 | FrankW: | rbranson: do you mean the ability to automatically utilize them in mapserver? |
| 12:35:40 | FrankW: | I'm not familiar with LZO compression. |
| 12:35:41 | rbranson: | yes, and also include a shp compression tool |
| 12:35:55 | rbranson: | LZO compression is designed for "real-time" decompression performance |
| 12:36:12 | rbranson: | it's not as good as gzip or bzip2, but it's much faster for decompression |
| 12:36:45 | FrankW: | you are aware that this would almost certainly defeat .qix spatial indexing, right? |
| 12:36:54 | rbranson: | why so? |
| 12:37:04 | FrankW: | it only works well when we can effectively seek to a particular part of the file quickly. |
| 12:37:13 | FrankW: | I presume a compressed file will need to be decompressed from the start. |
| 12:37:26 | rbranson: | i'm just now thinking about it honestly |
| 12:37:41 | rbranson: | afaik, the qix file would have to be rebuilt to support the compressed shapefile |
| 12:37:48 | rbranson: | as the offsets would change |
| 12:38:23 | FrankW: | If LZO is anything like gzip or other common compression methods, it is very hard to start decompressing in the middle of the file. |
| 12:38:34 | rbranson: | you wouldn't compress the entire file |
| 12:38:43 | rbranson: | just the geometry data |
| 12:38:59 | rbranson: | it wouldn't be effective on point data obviously |
| 12:39:04 | FrankW: | Are you suggesting that each geometry would be independently compressed? |
| 12:39:08 | rbranson: | yes |
| 12:39:36 | FrankW: | Does the algorithm would well on relatively small chunks? |
| 12:39:49 | FrankW: | I know many of the algorithms don't get much benefit over short segments. |
| 12:40:06 | rbranson: | yeah, i am looking at that now |
| 12:40:11 | rbranson: | it probably won't be good for very short pieces of data |
| 12:40:22 | rbranson: | but it will work well for polygons with a few hundred or so points |
| 12:41:07 | FrankW: | I think this would be a relatively complicated implementation. |
| 12:41:09 | rbranson: | we constantly deal with >50MB shapefiles with large polygons |
| 12:41:33 | rbranson: | once the shapefile drops out of RAM, performance obviously plummets |
| 12:41:59 | rbranson: | our largest poly file is ~1GB |
| 12:42:29 | FrankW: | With spatial indexing, it should not be necessary for the whole file to be in ram cache for good performance. |
| 12:42:37 | FrankW: | But clearly compressing big geometries could be helpful. |
| 12:43:21 | FrankW: | For what it's worth, others with a similar issue have developed formats that first change the geometries so each point is stored as a difference from the last point. |
| 12:43:34 | FrankW: | And that used some reduction in precision to get good compression. |
| 12:43:42 | rbranson: | hmm, that's interesting |
| 12:44:00 | rbranson: | so you'd go from doubles to single-precision floats? |
| 12:44:31 | FrankW: | Likely to integers based on some "compression defined precision" provided by the user. |
| 12:44:48 | rbranson: | yeah, hmm |
| 12:45:09 | rbranson: | best case you're probably only looking at half the size though |
| 12:45:22 | FrankW: | Anyways, if you wanted to try an LZO "per geometry" compression effort with mapserver, I'd be interested in hearing how it goes. |
| 12:45:37 | rbranson: | well then if I get going on this I'll keep you posted |
| 12:45:56 | rbranson: | we haven't hit any walls yet, but it's looking like we're about to |
| 12:49:33 | rbranson: | bah, LZO is GPL |
| 12:49:55 | FrankW: | Is that a barrier to you? Are you linking mapserver into something proprietary? |
| 12:50:12 | rbranson: | not really, but I was hoping for BSD |
| 12:50:18 | rbranson: | so it'd be compatible with the MapServer license |
| 12:50:40 | FrankW: | It's ok for MapServer to optionally depend on GPL libraries. |