00:10:09 *** IceCreamMan (n=MasterNa@203.176.96.250) has joined #mapnik
00:16:43 *** D3f0 (n=defo@190.176.237.183) has joined #mapnik
00:26:02 <springmeyer> dukeku: you were asking about activity and I just thought - 'there's gotta be a trac plugin for that'...
00:26:20 <springmeyer> install took 2 minutes and now we've got: http://trac.mapnik.org/stractistics
00:27:48 <springmeyer> yikes, 49 new tickets in the last 30 days
00:27:57 <dukeku> nice!
00:28:28 <dukeku> heh, not too busy around the holidays :)
00:28:43 <springmeyer> good!
00:29:09 <springmeyer> dukeku: working towards the next release, jump on anything you are interested in...
00:29:16 <springmeyer> milestone 0.6.0
00:29:17 <nikq> 31 open tickets in Milestone 0.6.0: Names on areas don't seem to be correctly centered in the vertical axis, Stroke border, Support for OSX Leopard and Solaris (using Sun Studio compiler), Ability to set label value manually in TextSymbolizer (rather than have them read from datasource field), Support MAPNIK_VERSION, Crashing with TextSymbolizer and line placement., Update Install Document on Mapn...
00:29:18 <nikq> http://trac.mapnik.org/query?status=new&status=assigned&status=reopened&milestone=0.6.0&order=priority
00:29:19 <nikq> Milestone Roadmap: http://trac.mapnik.org/milestone/0.6.0
00:29:46 <springmeyer> (nikq is the new bot)
00:31:11 <crschmidt> nshttp://trac.openlayers.org/stractistics
00:31:13 <crschmidt> er
00:31:13 <crschmidt> http://trac.openlayers.org/stractistics
00:33:27 <cmarqu> crschmidt: "STRACTISTICS_VIEW privileges are required to perform this operation"
00:33:43 <crschmidt> oh, right
00:33:44 <cmarqu> (not logged in)
00:34:06 <crschmidt> fixed
00:34:22 <cmarqu> Thanks
00:34:51 <springmeyer> crschmidt: I thought I just made it viewable with login.. I'l check again, thx
00:35:34 <crschmidt> springmeyer: no, i was sharing openlayers
00:35:57 <springmeyer> oh, duh... was not paying attention (obviously) :)
00:37:02 <springmeyer> hey crschmidt: up upgraded the phenny code to the `def trac(phenny,input)` syntax...
00:37:26 <springmeyer> its here if that would be helpful at all: http://mapnik-utils.googlecode.com/svn/sandbox/irc_tools/
00:44:30 *** GarethAdams is now known as GarethAdams|Bed
00:55:32 *** D3f0 has quit (Remote closed the connection)
02:05:12 *** weizhuo (n=chatzill@nat/yahoo/x-dd1a2870c9e2f0e8) has joined #mapnik
02:37:32 *** springmeyer has quit ()
04:22:08 *** D3f0 (n=defo@190.176.198.62) has joined #mapnik
05:42:13 *** springmeyer (n=dane@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik
05:48:39 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
07:46:51 *** xcacou (n=aga@AToulouse-157-1-48-149.w86-201.abo.wanadoo.fr) has joined #mapnik
07:46:58 *** scruggs has quit (Read error: 110 (Connection timed out))
07:50:12 *** D3f0 has quit (Read error: 54 (Connection reset by peer))
07:53:30 *** GarethAdams|Bed has quit ()
08:03:46 *** kunitoki (n=55121f9a@67.159.35.76) has joined #mapnik
08:05:09 *** weizhuo has quit (Read error: 110 (Connection timed out))
08:21:55 *** kunitoki has quit ("CGI:IRC")
08:29:44 *** migurski has quit ()
08:39:36 *** GarethAdams (n=GarethAd@pdpc/supporter/active/GarethAdams) has joined #mapnik
08:48:45 *** kunitoki (n=55121f9a@67.159.35.76) has joined #mapnik
08:52:59 *** scruggs (n=chris@72-161-116-136.dyn.centurytel.net) has joined #mapnik
09:22:47 *** migurski_ (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
09:29:38 *** GarethAdams has quit ()
09:30:28 <kunitoki> hi i have a question
09:30:47 <kunitoki> if  lyr.set_datasource(datasource_cache::instance()->create(p));
09:31:17 <kunitoki> complains it "Could not create datasource. No plugin found for type 'ogr'"
09:31:36 <kunitoki> what is searching actually ?
09:32:01 <kunitoki> a shared library named ogr in the dataset cache directory ? or named ogr.input ?
09:33:52 <kunitoki> in every case i setup datasource_cache::instance()->register_datasources() it never find anything
09:43:48 *** migurski_ has quit (Read error: 110 (Connection timed out))
09:45:31 <kunitoki> i think i got it
09:46:06 <kunitoki> anyway would be cool if someone can register a datasource plugin provided with a class (in a standalone app) and not only with a shared library.
09:46:40 <kunitoki> so i can compile my input datasource directly inside the program (and not having to package external libs with the app)
09:46:51 <kunitoki> need to open a ticket  about it
09:50:41 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
10:00:25 *** migurski_ (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
10:11:43 *** migurski has quit (Read error: 110 (Connection timed out))
10:16:42 *** migurski_ has quit (Read error: 110 (Connection timed out))
10:30:05 *** migurski_ (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
10:38:07 *** migurski__ (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
10:43:48 *** ser has quit (Remote closed the connection)
10:44:12 *** migurski__ has quit (Read error: 60 (Operation timed out))
10:46:07 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
10:48:47 *** ser (n=ser@sergiusz.pawlowicz.name) has joined #mapnik
10:49:08 *** migurski_ has quit (Read error: 110 (Connection timed out))
10:53:51 *** migurski_ (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
11:04:53 *** migurski has quit (Read error: 110 (Connection timed out))
11:13:09 *** migurski_ has quit (Read error: 110 (Connection timed out))
11:22:24 *** migurski_ (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
11:23:42 <kunitoki> finally i got it working !
11:24:20 <kunitoki> it can be improved a lot, conversion from ogr-feature to mapnik-feature still is not optimized
11:26:52 <kunitoki> but i've been able to rundemo.cpp and render the maps provided in the demo/data
11:26:55 <kunitoki> wicked !!!
11:28:48 *** migurski__ (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
11:35:27 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
11:40:21 *** migurski_ has quit (Read error: 110 (Connection timed out))
11:43:08 *** migurski_ (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
11:43:58 <nikq> Mapnik Trac: Ticket #170 (Add OGR.input plugin to read all OGR supported vector formats) updated | http://trac.mapnik.org/ticket/170#comment:3
11:47:12 <kunitoki> mmm
11:47:22 <kunitoki> i cannot add another attachment
11:47:43 <kunitoki>  Trac detected an internal error:Exception: Failed to create unique name: /home/artem/mapnik_trac/attachments/ticket/170/ogr_input_plugin_final.100.patch
11:49:04 *** migurski_ has quit (Read error: 60 (Operation timed out))
11:49:09 <crschmidt> change the name of your file on disk, and try again?
11:49:53 *** migurski__ has quit (Read error: 110 (Connection timed out))
11:50:33 *** migurski_ (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
11:50:34 <nikq> Mapnik Trac: Ticket #170 (Add OGR.input plugin to read all OGR supported vector formats) updated | http://trac.mapnik.org/ticket/170#comment:4
11:50:58 <kunitoki> i tried several times
11:51:47 <kunitoki> it always die
11:51:57 <kunitoki> so i posted a link in the ticket,
11:55:04 *** migurski has quit (Read error: 110 (Connection timed out))
11:58:18 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
12:05:20 *** kunitoki has quit ("CGI:IRC")
12:05:45 *** migurski__ (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
12:07:01 *** migurski_ has quit (Read error: 110 (Connection timed out))
12:13:29 *** migurski_ (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
12:18:25 *** migurski has quit (Read error: 110 (Connection timed out))
12:20:55 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
12:22:56 *** migurski__ has quit (Read error: 110 (Connection timed out))
12:28:22 *** migurski__ (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
12:34:44 *** migurski_ has quit (Read error: 110 (Connection timed out))
12:36:22 *** migurski_ (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
12:39:09 *** migurski has quit (Read error: 110 (Connection timed out))
12:43:47 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
12:50:20 *** migurski__ has quit (Read error: 110 (Connection timed out))
12:55:04 *** migurski_ has quit (Read error: 110 (Connection timed out))
13:03:01 *** migurski has quit (Read error: 110 (Connection timed out))
13:03:18 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
13:16:05 *** migurski_ (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
13:19:03 *** migurski has quit (Read error: 110 (Connection timed out))
13:21:52 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
13:29:13 *** migurski__ (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
13:30:45 *** migurski has quit (Read error: 60 (Operation timed out))
13:36:40 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
13:37:13 *** migurski_ has quit (Read error: 110 (Connection timed out))
13:48:30 *** migurski__ has quit (Read error: 110 (Connection timed out))
13:53:24 *** migurski has quit (Read error: 110 (Connection timed out))
14:13:07 *** Ruffiano (n=ruffiano@static-70-21-119-183.res.east.verizon.net) has joined #mapnik
14:13:59 <Ruffiano> Still having a water poly location problem even after a slim import of the database: http://www.sandwichmafia.com/Pictures/maperror.jpg
14:14:03 <Ruffiano> any ideas?
14:17:08 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
14:37:52 *** migurski has quit (Read error: 110 (Connection timed out))
14:51:16 <nikq> Mapnik Trac: InstallationTroubleshooting edited | http://trac.mapnik.org/wiki/InstallationTroubleshooting?version=24
15:41:23 *** xcacou has quit (Remote closed the connection)
16:21:38 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
16:39:02 <Berteun> I don't understand how to interpret Mapniks values for scale and scale_denominator, could anybody explain this?
16:50:57 *** migurski has quit ()
17:08:51 *** D3f0 (n=defo@190.176.198.62) has joined #mapnik
17:13:07 *** __d3f0__ (n=defo@190.176.226.70) has joined #mapnik
17:20:56 <nikq> Mapnik Trac: InstallationTroubleshooting edited | http://trac.mapnik.org/wiki/InstallationTroubleshooting?version=25
17:25:12 *** kredik has quit ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]")
17:29:55 *** D3f0 has quit (Connection timed out)
18:48:02 *** ser has quit (Read error: 104 (Connection reset by peer))
18:48:12 *** ser (n=ser@sergiusz.pawlowicz.name) has joined #mapnik
18:53:35 *** migurski (n=migurski@h-68-165-1-62.snvacaid.covad.net) has joined #mapnik
19:34:20 <Berteun> If I understand it correctly: if you have a map object m, then m.scale() will give you a number which expresses the number of 'projection units' per pixel in your map.
19:34:54 <Berteun> And, the m.scale_denominator is usually the same number, but divided by 0.00028 which is based on the number dots per inch when viewing the map.
19:35:02 <Berteun> And this is also the number you use in your style files.
19:35:32 <Berteun> For MaxScaleDenominator and such.
19:36:23 <Berteun> But, if you change your projection and projection roughly the same area on the same sized image, the number of 'projection units' per pixel might change too.
19:36:54 <Berteun> Thus triggering different rules in your style sheet; hence, you need to fix all your minscale and maxscale parameters if you switch projections?
19:40:10 <CIA-23> mapnik-utils: dane.springmeyer * r510 /sandbox/ (84 files in 3 dirs): Tests for new ogr plugin written by kunitoki
20:16:11 <crschmidt> Berteun: Probably not.
20:16:26 <crschmidt> The idea behind scales is that they're the same across projections
20:16:36 <nikq> Mapnik Trac: Changeset [837]: + First implementation of OGR(vector) input plugin. Patch from kunitoki.  ... | http://trac.mapnik.org/changeset/837
20:16:55 <crschmidt> They map to a paper maps 'this many $unit in the map : this many $unit in the output'
20:17:51 <crschmidt> They are based around a fixed idea of dpi (~90-something in Mapnik)
20:18:06 <crschmidt> and require accurate information about the units in use (which are typically provided by the proection)
20:20:31 <CIA-23> mapnik-utils: dane.springmeyer * r511 /sandbox/ogr_plugin/ogr_tests.py: turn off auto delete and opening
20:20:31 <CIA-23> mapnik-utils: dane.springmeyer * r512 /sandbox/ogr_plugin/ogr_tests.py: don't bomb out of tests if ogr failure
20:22:22 <nikq> Mapnik Trac: Ticket #170 (Add OGR.input plugin to read all OGR supported vector formats) updated | http://trac.mapnik.org/ticket/170#comment:5
20:23:23 <Berteun> crschmidt: That's what I would have expected, yet this seems not to be the case.
20:23:24 *** artem_ (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
20:23:49 * springmeyer seems to recall that mapnik's scale denominator needs to be a bit more tied in with proj
20:24:03 <springmeyer> it only support projections in degress or meters
20:24:29 <springmeyer> is what I recall from looking at the code, but we'd have to ask artem that
20:24:35 <Berteun> But how would this work with mercator projection?
20:24:49 <springmeyer> fine (mercator should be in meters)
20:25:50 <Berteun> Hmm, I don't understand that then...
20:26:03 <Berteun> Mercator distorts near the poles if it is correct around the equator.
20:26:29 <springmeyer> all: looking for testers of kunitoki's OGR plugin patch that just landed in trunk...
20:26:44 <crschmidt> Berteun: Once you project a map, the scale is 'fixed'
20:26:53 <crschmidt> the scale is cartesian based, not geodesic
20:27:02 <springmeyer> I've set up a basic python script. see the readme here (script is in folder): http://mapnik-utils.googlecode.com/svn/sandbox/ogr_plugin/README.txt
20:28:02 <Berteun> crschmidt: So, a line of 100 units near the pole could be like 10m 'in the real world' but a line of 100 units at the equator could be 100 m 'in the real world'?
20:28:39 <crschmidt> yes
20:28:47 <nikq> Mapnik Trac: Ticket #170 (Add OGR.input plugin to read all OGR supported vector formats) updated | http://trac.mapnik.org/ticket/170#comment:6
20:31:43 <cmarqu> migurski: Apparently, I cannot check stuff like [admin_level=3] in Cascadenik when the admin_level is a string in the DB. Writing [admin_level="3"] lets the parser fail.
20:33:09 <migurski> so I need to pay attention to quotes correctly
20:33:25 <Berteun> crschmidt: But the hard part then is to find out how the 'map units' correspond to real-world units.
20:33:34 <Berteun> At different longitudes.
20:34:05 <springmeyer> jburgess: are you around?
20:34:12 <jburgess> yes
20:34:42 <springmeyer> CAIRO_HAS_IMAGE_SURFACE seems to have only been added in 1.8
20:35:14 <jburgess> ok, so if older versions had the feature without the #define then maybe we need to remove that wrapper
20:35:18 <Berteun> I guess I don't fully understand the +units=m parameter in projections then.
20:35:30 <springmeyer> ok.
20:35:54 <springmeyer> jburgess: I'll attach the patch from kunitoki to #170, maybe you could review?
20:35:55 <nikq> Ticket #170: Add OGR.input plugin to read all OGR supported vector formats, http://trac.mapnik.org/ticket/170
20:36:21 <jburgess> it was meant to avoid problems if someone had built a version of cairo without support for imageSurface... which does seem very unlikely
20:36:36 <springmeyer> okay.
20:36:39 <jburgess> perhaps more likely for things like SVG, PDF etc
20:38:05 <migurski> cmarqu can you add a ticket to http://code.google.com/p/mapnik-utils/issues/list ?
20:39:09 <cmarqu> migurski: Will do
20:39:27 <springmeyer> jburgess: hmm (trac seems to be having problems)... http://dpaste.com/114012/
20:40:10 <springmeyer> that is the remainder of the patch. for kunitoki to test he's just trying to get the rundemo with cairo to build...
20:41:14 <springmeyer> artem_: can we get svn ci for jburgess :)
20:41:37 <artem_> hey springmeyer, sure
20:41:46 <jburgess> the mapnik_install_directory is misleading, what works is if you provide the top level of the _source_ directory
20:43:38 <springmeyer> jburgess: I'm not following... are you talking about my patch root directory in that dpaste ?
20:44:36 <jburgess> in the dpaste there seem to be lots of adjustments to paths to get things to load, it should all work without modification provided you specify the source directory instead of the install path
20:44:37 <springmeyer> oh, nm you are looking at the patch contents (which I have not in detail!)
20:44:57 <springmeyer> right, trust you there.
20:45:17 <jburgess> springmeyer: since the patch was quite long it took a while to find the bit that you wanted me to look at.
20:45:34 <springmeyer> though I'm only ask you to think through the /src and /include portions
20:45:37 <springmeyer> ya, sorry!
20:47:15 <jburgess> swapping CAIRO_HAS_IMAGE_SURFACE for HAVE_CAIRO should be fine. I don't really see many people building Cairo without ImageSurface support.The change is good if it makes it work with older versions (provided everything else works fine)
20:47:49 <artem_> jburgess: I have couple q's  , where to get 'unifont' font ?
20:47:55 <jburgess> When I first wrote the code I used HAVE_CAIRO but later I noticed the more fine-grained defines in some of the headers files
20:48:05 <nikq> Mapnik Trac: Ticket #195 (Support reading Projection information within OGR/GDAL input plugins) created | http://trac.mapnik.org/ticket/195
20:48:47 <jburgess> artem_: http://unifoundry.com/unifont.html
20:48:58 <artem_> ah thx:)
20:53:09 <nikq> Mapnik Trac: PluginArchitecture edited | http://trac.mapnik.org/wiki/PluginArchitecture?version=7
20:58:50 <springmeyer> http://mapnik.org/faq/#data <-- updated
21:02:39 <artem_> springmeyer: I had a very brief look at ogr plug-in. It needs some optimisations, atm  it converts OGR geom to WKB and then reads them using mapnik's wkb reader.
21:03:21 *** rcoup_ (n=rcoup@ip-118-90-60-67.xdsl.xnet.co.nz) has joined #mapnik
21:04:06 <springmeyer> artem: yes lucia noted that in his email I think - so he's looking for feedback on the WKB thing
21:04:49 *** __d3f0__ has quit (Read error: 110 (Connection timed out))
21:05:09 <artem_> springmeyer: ah cool
21:06:48 <springmeyer> from this morning...
21:06:48 <springmeyer> kunitoki
21:06:49 <springmeyer> finally i got it working !
21:06:49 <springmeyer> 03:24
21:06:49 <springmeyer> kunitoki
21:06:49 <springmeyer> it can be improved a lot, conversion from ogr-feature to mapnik-feature still is not optimized
21:06:51 <springmeyer> 03:26
21:06:53 <springmeyer> kunitoki
21:06:55 <springmeyer> but i've been able to rundemo.cpp and render the maps provided in the demo/data
21:06:57 <springmeyer> 03:26
21:06:59 <springmeyer> kunitoki
21:07:01 <springmeyer> wicked !!!
21:07:16 * springmeyer upps didn't see those line breaks!
21:07:22 <artem_> :)
21:10:43 <cmarqu> migurski: Alright, I filed 5 tickets now, sorry :) I cannot give them the right owners myself though?
21:11:15 <nikq> Mapnik Trac: Changeset [838]: Remove reference to CAIRO_HAS_IMAGE_SURFACE macro since this is not  ... | http://trac.mapnik.org/changeset/838
21:12:06 <springmeyer> jburgess: I okay removed the HAS_CAIRO_IMAGE_SURFACE in r838
21:12:07 <nikq> http://trac.mapnik.org/changeset/838, at , by dane: Remove reference to CAIRO_HAS_IMAGE_SURFACE macro since this is not supported until cairo 1.8 release
21:13:09 <jburgess> springmeyer: I noticed that the patch you pasted before also commented out the SVG support, do you know if that work on older Cairo releases?
21:14:07 <migurski> cmarqu - I'll have a look in a little bit
21:14:49 <springmeyer> jburgess: I assume SVG support has been in cairo since older releases but I don't know
21:15:18 <springmeyer> we'll have to ask kunitoki when he is back around why that was commented
21:15:22 <jburgess> ok, I was wondering if it was commented out of rundemo because it didn't compile or work with his version
21:15:58 <springmeyer> nikq: tell kunitoki: why was the cairo svg support commented out of rundemo? did it not compile with your version?
21:15:58 <nikq> springmeyer: I'll pass that on when kunitoki is around.
21:18:42 <jburgess> looking at the Cairo release notes suggests that SVG support was added back in 1.2.0 (1st Jul 2006): "the 1.2 release doubles the number of supported backends, adding PDF, PostScript, and SVG backends"
21:31:29 <springmeyer> okay, cool jburgess
21:32:57 <Ruffiano>  so, I've done both a slim and non-slim import of the osm data, and I am still getting out of place polys with either one, see: http://www.sandwichmafia.com/Pictures/maperror.jpg
21:36:39 <springmeyer> cmarqu: nice ... http://code.google.com/p/mapnik-utils/issues/detail?id=10#c1
21:37:39 <springmeyer> Berteun: sorry your questions got clobber there...
21:38:14 <springmeyer> I'm very interested in the same questions because I too find it a bit perplexity to fully understand projection systems <-> scale
21:38:32 <artem_> Ruffiano: OK, I see your problem
21:38:38 <springmeyer> hopefully you can post a summary when you get it all figured out :)
21:39:04 <artem_> Ruffiano: it is a projection/datum issue
21:39:09 <cmarqu> springmeyer: But OTOH, we are not supposed to look into the compiled output at all, since it would work perfectly
21:39:10 <Ruffiano> That "water" that's misplaced is really just the background, but it's positioning all the roads and such correctly
21:40:21 <springmeyer> cmarqu: well, its still nice to be able to edit a bit after processing :)
21:40:55 <springmeyer> cmarqu: I'd be curious to hear more about your workflow...
21:41:38 <cmarqu> springmeyer: On the Mapnik side, it's basically following http://wiki.openstreetmap.org/wiki/HikingBikingMaps
21:42:11 <Berteun> springmeyer: I can give an example, I have a map of the Netherlands and if I do a Dutch projection (units=m in the projection string) I get a scale of 200, if I use Google projection (mercator, also units=m) I get a scale of about 326 if I project the same area on the same sized canvas (Google projection deforms slightly).
21:42:24 <cmarqu> On the Cascadenik side, I copied Mike's openstreetmap style and edited around
21:42:29 <artem_> Ruffiano: it looks like OSM data and boundary shapefiles are not overlapping properly.
21:43:14 <artem_> jburgess: are you using 8x8 metatiles for OSM ?
21:43:23 <jburgess> yes
21:43:25 <Berteun> I can understand this partly, both on the otherhand I'd like to be able to have some way to more or less reconcile those.
21:43:43 <Berteun> I can send a message to the mailing list, perhaps that some people have a good idea. :)
21:43:47 <crschmidt> Berteun: When you say "same area"
21:43:57 <crschmidt> Berteun: do you mean "same area in lon/lat bbox"?
21:44:02 <Berteun> Yes.
21:44:03 <springmeyer> so Berteun: you are getting those different scales after zoomin to what bbox?
21:44:09 <springmeyer> ah.
21:44:10 <Berteun> Yes.
21:44:45 <crschmidt> Berteun: The reprojection changes the number of meters covered by the map output
21:45:13 <crschmidt> Berteun: If you keep your image the same size, to fit more meters into it, the scale has to change
21:45:18 <artem_> jburgess: I'm getting 'classic' text labels 'cut off' while rendering planet, but it looks good on OSM site. Are you using latest Mapnik or do you modify osm.xml ??
21:45:46 <Ruffiano> artem_: Would this not be defined in the stylesheet for the coastline layer (that should be the coastline or prosessed_p layer)
21:46:19 <Berteun> crschmidt: But I don't really fit more meters on it.
21:46:26 <crschmidt> Yes, you do.
21:46:26 <jburgess> the current code used to render the site sets the Map() size to 9x9 tiles and then slices off the 0.5 of tile at each edge. It does not use the buffer() method available in the latest code
21:46:31 <Berteun> crschmidt: In what sense.
21:46:41 <Berteun> Slightly perhaps, but not 1.5 times.
21:46:42 <crschmidt> Berteun: Print out the post-transformation bbox
21:46:53 <crschmidt> Look at the number of meters you get out of it
21:47:06 <crschmidt> I'd be willing to bet that in one direction, or another, you're getting 50% more meters
21:47:16 <crschmidt> Probably the y/lat direction
21:47:24 <crschmidt> Beacuse Mercator stretches significantly at high latitudes
21:47:53 <artem_> Ruffiano : yes, check srs values for processed_p . It should be spherocal mercastor -> a==b
21:48:17 <springmeyer> so maybe comparing this local dutch projections with another european projection would be a good test?
21:48:22 <jburgess> if the projection is off by a few km to the Noth then you may be missing the  nadgrids=@nullparameter on the proj line
21:48:26 <artem_> <!ENTITY spherical_mercator "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs +over">
21:48:58 <crschmidt> jburgess: or the grid shift files
21:49:48 <Berteun> crschmidt: http://tile.openstreetmap.nl/~berteun/dutch_map.png (dutch projections, every square is 10x10km) http://tile.openstreetmap.nl/~berteun/google_map.png (google projection, grid shows deformation)
21:49:57 <jburgess> artem_: the latest mod_tile code has moved to using an 8x8 Map() and set a buffer of 128.
21:50:01 <Ruffiano> artem_L <Layer name="coast-poly" status="on" srs="+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +no_defs +over">  is what I am using
21:50:07 <crschmidt> ah
21:50:12 <crschmidt> no +nadgrids=@null
21:50:20 <Berteun> This is roughly the same area, same image size, yet the dutch has scale 200, google has 326
21:50:24 * springmeyer has always wondered why ogr output the '+wktext': http://spatialreference.org/ref/sr-org/6/mapnik/
21:50:46 <artem_> jburgess: ok, I'll need to check.
21:50:52 <crschmidt> springmeyer: +wktext is a code to OGR to say "Serialize the proj4 as a WKT parameter"
21:51:01 <crschmidt> springmeyer: it's the only way that you can round trip that string through WKT and back
21:51:01 <springmeyer> ah, cool thanks
21:51:21 <springmeyer> nice
21:51:53 <jburgess> artem_: I think I have (rarely) noticed some shield symbols cut between metatiles but not any text labels.. Of course there is no guarantee of cut text, if you make the font larger then you'll need a bigger buffer.
21:52:52 <artem_> jburgess: I'm using latest osm.xml from trac.openstreetmap.org - no changes to fonts etc
21:53:28 <Ruffiano> artem_, crschmidt: Thank you! That was the culprit
21:53:59 <Ruffiano> it's odd though, I am using the exact same style sheet on 2 machines, and only one was doing this
21:53:59 <artem_> Ruffiano: you're welcome . glad it works for you now
21:54:37 <artem_> Ruffiano: I call it 'user error' ;)
21:55:22 <Berteun> crschmidt: I do get more 'meters' for the google projection, and I understand that these are, in a sense, 'map meters', but my problem is that I'd like to work with a scale that has some 'real world' correspondence.
21:55:41 <Ruffiano> artem_: =) No doubt!
21:55:43 <crschmidt> Berteun: There's no such thing
21:55:57 <crschmidt> Berteun: Scale is ratio of "map units to output units"
21:56:44 <Berteun> Yeah, but since the max- and min-scale denominators work with this kind of scale, I have to change these if I switch projections.
21:57:13 <Berteun> If I want the same level of detail on both my images such as I just showed.
21:57:41 <Berteun> I hope you see what I'm getting at...
21:58:13 <springmeyer> Berteun: I defintely see what you are getting at
21:58:32 <springmeyer> and am glad crschmidt is here to tell us the truth
21:58:49 <crschmidt> Berteun: I think that the problem here is that you're mistakenly thinking that one of these is 'more real world' than the other. When you choose a projection, you choose a particular mapping of a real world into a flat space. The fact that Meractor distorts wildly at high latitudes is a downside of such a projection
21:58:50 <springmeyer> Berteun: scale_denominators also assume a static pixel size
21:59:18 <artem_> springmeyer : wow, it would be cool to have dynamic pixels :)
21:59:35 <springmeyer> yes, artem - can't wait! :)
22:00:12 <springmeyer> Berteun: keep in mind: (m.envelope().width()/m.width)/0.00028
22:00:19 <springmeyer> via: http://trac.mapnik.org/browser/trunk/src/scale_denominator.cpp#L37
22:00:37 <Berteun> springmeyer: Yes, that I have deduced from the source. :)
22:00:47 <Berteun> As you have done.
22:01:08 * springmeyer does not claim to understand this stuff, but is invested it trying to 'get at' the variables...
22:01:13 <springmeyer> Berteun: fyi: http://mapnik-utils.googlecode.com/svn/sandbox/print2pixel/
22:01:41 <artem_> jburgess: mod_tiles looks good : #define RENDER_SIZE (256 * (METATILE + 1)) Image32 buf(RENDER_SIZE, RENDER_SIZE);
22:01:42 <springmeyer> description='Printing optimization utility for pixel to print, paper size, and unit conversions'
22:01:59 <crschmidt> Berteun: So, I think the answer to your question is "Don't use projections which are widely known to cause large distortions"
22:02:15 <crschmidt> Berteun: if you only render in local projections, then the scale denominators should be approximately the same for all of them
22:02:21 <Berteun> Yes.
22:02:43 <crschmidt> And the fact that you also have to deal with the Google projection is a shame, brought down on us by the fact that people really don't care about cartography anymore
22:02:48 <Berteun> I don't know a good solution either.
22:02:58 <crschmidt> Ban Google :)
22:04:00 *** weizhuo (n=chatzill@nat/yahoo/x-1337405c2b8d355e) has joined #mapnik
22:04:30 <Berteun> I'll just make a Dutch stylesheet and introduce a (326/200) scale-scalefactor if I reproject in mercator so the same amount of detail shows up. ;)
22:04:35 <jburgess> artem_: I know RENDER_SIZE is still in the code but it actually resizes the map object to just the 8x8 noe when it does: m.resize(render_size, render_size);
22:05:41 <artem_> jburgess:  ok, I see
22:05:46 <Berteun> And, then there is this other thing, I have some railroads with a classical dashed pattern on my map, but if a railroad consists of two segments (because of a bridge for example) the joins screw up the dashing, because it starts over.
22:06:04 <jburgess> I should probably rip out the RENDER_SIZE definition but you can't create a Map() without specifying a size
22:07:04 <Berteun> springmeyer: Thanks for the URL btw.
22:07:17 <springmeyer> np
22:07:19 <nikq> Mapnik Trac: Ticket #196 (Support dynamic pixels) created | http://trac.mapnik.org/ticket/196
22:07:20 <artem_> jburgess: you can create zero sized map, though m = mapnik::Map(0,0)
22:07:36 <jburgess> that would probably be ok
22:07:59 <Berteun> That trac ticket would already solve it a bit.
22:08:07 <jburgess> I'd also like to remove the non-metatile code paths but I'm sure I'll get some complaints
22:08:11 <Berteun> Because you could 'cheat' using that one.
22:08:15 <springmeyer> ha!
22:08:34 <springmeyer> what would cheating be called to cover up distortion?
22:09:14 <springmeyer> no monkey-patching maybe but monkey-mapping :)
22:09:16 <artem_> jburgess: I think it is good to be able to handle different schemas  for tile storage, can be optional ?
22:10:42 <jburgess> the issue is that the concept of how meta tiles behave is hooked into so many pieces of the code, having one set of code which works with METATILE=1 would be OK, but now several bits of code are duplicated
22:11:12 * springmeyer cool, sqlite polygons rendered via mapnik from ogr: http://dbsgeo.com/tmp/mapnik_ogr_plugin_tests/testpoly_type-db.png
22:11:24 <jburgess> I know that I don't uses the non-metatile mode so it might get broken without me noticing
22:11:56 <jburgess> the python variant of renderd only does metatiles
22:12:45 <artem_> jburgess: I think metatiles work great for most cases.
22:13:07 <artem_> jburgess: have you tried xfs ? or similar for storing tiles?
22:13:32 <springmeyer> off the charts: http://www.ohloh.net/p/mapnik/analyses/latest/commits_spark.png
22:13:54 <artem_> springmeyer : cool map :)
22:14:25 <jburgess> I did some tests on different filesystems in different circumstances a few years ago so I've got a reasonable grasp of how they work and their limitations
22:14:36 <springmeyer> I call it 'abstract' :)
22:15:28 <jburgess> The underlying problem is that no generic filesystem is really optimised for storing many millions of objects of ~2kB average size
22:17:06 <artem_> jburgess: yep, it make sense . I just wonder 'cause some filesystems claim to support things like that e.g reiserfs
22:17:09 <CIA-23> mapnik: dane * r837 /trunk/ (12 files in 4 dirs): + First implementation of OGR(vector) input plugin. Patch from kunitoki. Thanks! Closes #170
22:17:10 <nikq> Ticket #170: Add OGR.input plugin to read all OGR supported vector formats, http://trac.mapnik.org/ticket/170
22:17:10 <CIA-23> mapnik: dane * r838 /trunk/ (3 files in 3 dirs): Remove reference to CAIRO_HAS_IMAGE_SURFACE macro since this is not supported until cairo 1.8 release
22:18:09 <artem_> jburgess: but if you did some tests I'll trust you judgement . Lets just use metatiles
22:18:54 <jburgess> artem_: With non-metatiles there are almost certainly important differences between FS's and I've not thoroughly investigated them
22:19:23 <artem_> jburgess: I'm just curious
22:19:35 <jburgess> I figured it was easier to implement metatiles since the rendering and storage using 8x8 metatiles fitted together so neatly
22:19:52 <artem_> jburgess: absolutely
22:20:43 <crschmidt> jburgess: Presumably you could tell people who still want non-metatiles to use a metatile size of 1x1 instead of 8x8?
22:21:21 <jburgess> crschmidt: yes, but it would probably need to special-case the saving of these single sized metatiles as a plain PNG file
22:21:50 <jburgess> right now I've got 2 parallel code paths for meta and non-meta case which makes the code harder to maintain
22:21:58 <crschmidt> yaeh
22:22:01 <artem_> 1x1 metatile  = plain PNG
22:22:11 <nikq> Mapnik Trac: Ticket #197 (Fix compilation of C++ rundemo) created | http://trac.mapnik.org/ticket/197
22:22:27 <artem_> jburgess: btw. it would be great to have jpegs as well as png
22:23:02 <jburgess> it originates from the time I first implemented the code. First I did the non meta case, then added ifdefs while I worked on a meta variant. I never went back to clean things up
22:23:42 <jburgess> I've begun making some very small steps towards making more things like the file format configurable
22:23:53 <nikq> Mapnik Trac: Ticket #170 (Add OGR.input plugin to read all OGR supported vector formats) updated | http://trac.mapnik.org/ticket/170#comment:7
22:24:03 <jburgess> I'm thinking about moving most or all parameters into the renderd.conf file
22:24:35 <jburgess> already I've removed the hard coded projection string. It now reads it from the Map() projection as configured from the xml style
22:25:07 <jburgess> I've now got two different implementations though to keep in step. The C one and the new python one
22:25:14 <nikq> Mapnik Trac: Ticket #170 (Add OGR.input plugin to read all OGR supported vector formats) updated | http://trac.mapnik.org/ticket/170#comment:8
22:25:35 <jburgess> The Python could probably get some of these features before the C one
22:25:59 <artem_> jburgess: great stuff
22:26:48 <jburgess> right now, if you wanted to switch png for jpg you could probably do it with 2 lines of code change: one in the renderd code and another for the mimetype in mod_tile
22:27:34 <jburgess> as always, it takes a bit more code to do it generically
22:28:07 * springmeyer speaking of jpeg...
22:28:16 <nikq> Mapnik Trac: Ticket #198 (Allow configuration of JPEG quality) created | http://trac.mapnik.org/ticket/198
22:28:19 <artem_> jburgess: sure, I'm thinking about multiple maps in renderd.conf with different image types etc etc
22:28:44 <artem_> springmeyer : yes, good one
22:28:45 *** Ruffiano has quit ("Leaving.")
22:33:51 <nikq> Mapnik Trac: Ticket #198 (Allow configuration of JPEG quality) updated | http://trac.mapnik.org/ticket/198#comment:1
22:42:30 <artem_> springmeyer: re: dynamic pixels . we shouldn't assume that pixels are square , sometimes they're not. We should probably  have pixel_size_x /pixel_size_y .
22:42:49 <artem_> a tuple
22:45:41 <springmeyer> oh yes - that would be awesome
22:46:36 *** D3f0 (n=defo@190.176.226.70) has joined #mapnik
22:52:08 <cmarqu> Would the second problem here: http://trac.mapnik.org/ticket/187 be solved by the new buffer feature?
22:57:08 *** D3f0 has quit ("Konversation terminated!")
23:20:47 *** kunitoki_ (n=4f0731d2@67.159.35.76) has joined #mapnik
23:23:31 <rcoup_> artem_: what's a use-case for non square pixels?
23:24:19 <cmarqu> Some strange displays on e.g. mobile phones I would guess
23:24:20 <artem_> rcoup_: :) projectors ??
23:26:17 <rcoup_> in real-life they may be non-square, but the OS/hardware surely handles interfacing the screenbuffer with that?
23:26:23 <rcoup_> maybe i'm under/over thinking
23:26:34 <rcoup_> which means it must be lunchtime :)
23:26:58 <crschmidt> rcoup_: Non-square pixels are needed to satisfy rendering requests where the bbox and map width/height are not in the same ratio
23:27:11 <crschmidt> (As opposed to adjusting the bbox, like I believe mapnik does now)
23:27:53 <artem_> http://en.wikipedia.org/wiki/Pixel_aspect_ratio
23:28:04 <rcoup_> ok, so DPI in X is different from Y.
23:28:07 <rcoup_> makes sense
23:30:17 <artem_> ccrschmidt: but then you end up with distorted map :)
23:30:32 <crschmidt> artem_: I'm aware
23:31:07 <crschmidt> rcoup_: a common use case in the OpenLayers world at one point was to take a 'lonlat' projected tile and 'stretch' it vertically
23:31:20 <crschmidt> rcoup_: which is stupid, beacuse then it doesn't acutally lien up
23:31:23 <crschmidt> but lots of people still do it
23:31:39 <rcoup_> heh
23:31:42 <nikq> Mapnik Trac: Ticket #170 (Add OGR.input plugin to read all OGR supported vector formats) updated | http://trac.mapnik.org/ticket/170#comment:9
23:32:34 * rcoup_ is gonna need to get all my geo tickets bubbling again this weekend... mapnik, openlayers, geodjango... they're stacking up :(
23:32:42 <rcoup_> which mostly means writings tests
23:32:52 <crschmidt> rcoup_: you have openlayers patches awaiting review?
23:33:04 <rcoup_> crschmidt: vector text stuff
23:33:20 <crschmidt> hm
23:33:22 <crschmidt> got a #?
23:33:25 <rcoup_> yup, 1 sex
23:33:28 <rcoup_> sec even
23:33:44 <rcoup_> http://trac.openlayers.org/ticket/1895
23:34:35 <crschmidt> ah, 'labels'
23:34:48 * crschmidt was searching for 'text'
23:35:07 <rcoup_> i'm still not overly happy with some of the changes to renderer method args in that either.
23:42:01 <nikq> Mapnik Trac: Ticket #170 (Add OGR.input plugin to read all OGR supported vector formats) updated | http://trac.mapnik.org/ticket/170#comment:10
23:48:16 <nikq> Mapnik Trac: Ticket #170 (Add OGR.input plugin to read all OGR supported vector formats) updated | http://trac.mapnik.org/ticket/170#comment:11
23:58:14 * springmeyer wonders whether the OGR layer should be invoked as Ogr(file="data.shp",layer="data") or OGR(file="data.shp",layer="data") ?
23:58:38 <springmeyer> same goes for GDAL layers which are currently Gdal() via the python api...
23:58:58 <rcoup_> springmeyer: surely it should be "source" rather than "file"?
23:59:06 <rcoup_> since OGR can connect to my postgis db too...