00:41:28 *** ivangarcia has quit ("Leaving") 03:31:44 *** d3f0 (n=defo@190.176.206.94) has joined #mapnik 03:46:19 *** __d3f0__ has quit (Read error: 110 (Connection timed out)) 04:52:39 *** d3f0 has quit (Read error: 104 (Connection reset by peer)) 07:48:07 *** vosson_ has quit (Read error: 110 (Connection timed out)) 07:49:26 *** vosson (n=chatzill@126.80-202-247.nextgentel.com) has joined #mapnik 09:50:09 *** vosson has quit (Read error: 110 (Connection timed out)) 10:52:52 *** vosson (n=chatzill@126.80-202-247.nextgentel.com) has joined #mapnik 11:20:56 *** paulwagener (n=chatzill@41-177-ftth.onsbrabantnet.nl) has joined #mapnik 14:27:09 *** paulwagener has quit (Remote closed the connection) 16:28:59 *** Davedan (n=me@89-138-20-119.bb.netvision.net.il) has joined #mapnik 16:59:52 *** D3f0 (n=defo@190.176.206.94) has joined #mapnik 19:17:36 *** milovanderlinden (n=milo@cable-198-150.zeelandnet.nl) has joined #mapnik 19:18:35 <milovanderlinden> Hi there 19:19:57 <milovanderlinden> Question. I am using mapnik with the dutch Rijksdriehoekstelsel (cartesian, stereographic) and I am trying to set up the default osm.xml for our netherlands server tile.openstreetmap.nl. I have on strange issue; all the scale definitions seem to be broken. 19:20:29 <milovanderlinden> Now, I came across http://trac.mapnik.org/browser/trunk/src/scale_denominator.cpp and it seems scale is calculated in relation to pi 19:21:38 <milovanderlinden> Anyone been on this road before? Because I do not want to do wild guesses but stick to the default osm rendering scheme as possible 20:01:48 <Berteun> milovanderlinden: I have not seen yet that geographic was true. 20:02:09 <Berteun> Not with default Dutch projection at least. :) 20:02:20 <Berteun> That's just /0.00028 for the scale denominator. 20:08:04 *** rcoup (n=rcoup@ip-118-90-116-120.xdsl.xnet.co.nz) has joined #mapnik 20:14:49 <milovanderlinden> This I noticed to Berteun. I set up a little scheme: It tells what scaledenom is at what dutch zoomlevel; and approx. with what osm 900913 level it corresponds 20:14:54 <milovanderlinden> to = too 20:15:13 <milovanderlinden> Could you take a look at it? http://dogomaps.net/tileconf.html 20:18:29 <milovanderlinden> It is not, I misunderstood 20:19:19 <milovanderlinden> 340000 (tile_width in meters at level 0) / 0.00028 = 1214285714 20:19:37 <milovanderlinden> that is one h*ll of a denom 20:19:52 <milovanderlinden> 1214 million 20:19:54 <milovanderlinden> lol 20:20:56 <milovanderlinden> maybe I am wrong, maybe scales are different. Perhaps it would be good to create a small script that will print scale at all levels 21:34:29 <springmeyer> milovanderlinden: so have you changed the srs records in the osm.xml to the proj4 of RD? 21:34:52 <springmeyer> and is your database in mercator still? 21:35:04 <milovanderlinden> yes 21:35:18 <milovanderlinden> the layer defs are still in merc 21:35:24 <milovanderlinden> I only changed the map srs 21:35:40 <milovanderlinden> scaledenom is under control now 21:35:43 <milovanderlinden> But no rendering 21:36:00 <springmeyer> oh? 21:36:02 <milovanderlinden> Only two layers that are in RD get rendered 21:36:18 <milovanderlinden> http://dogomaps.net/rd_test.html 21:36:21 <springmeyer> hmmm... 21:37:01 <Berteun> milovanderlinden: Are your extents alright? :) 21:37:54 <milovanderlinden> extents are in google, the default osm extents (whole world) of course they exceed the map extents, but is that a problem? 21:38:00 <Berteun> Yes. 21:38:02 <Berteun> It is. 21:38:10 <milovanderlinden> <Parameter name="extent">-20037508,-19929239,20037508,19929239</Parameter> 21:38:13 <Berteun> Don't use it. 21:38:16 <Berteun> Use: 21:38:16 <Berteun> <Parameter name="extent">680139.824849,6909752.01219,790669.637438,7022662.05671</Parameter> 21:38:23 <milovanderlinden> aargh.. 21:38:43 <springmeyer> Berteun: should 21:38:43 <Berteun> If you have data outside of the area valid for RD it won't reproject. 21:38:49 <springmeyer> ups... 21:38:56 <Berteun> I don't know why. 21:39:03 <Berteun> I just know this works for me (TM) :) 21:39:10 <springmeyer> Berteun: so those are extents in RD? 21:39:12 <Berteun> No. 21:39:21 <springmeyer> oh 21:39:36 <Berteun> Those extents are in 900913 but are inside the area for which RD is defined. 21:39:49 <springmeyer> interesting 21:39:50 <springmeyer> okay 21:39:54 <Berteun> So, it won't select data that is not reprojectable. 21:40:02 <springmeyer> milovanderlinden: and you are using the mapnik WMS server? 21:40:30 <springmeyer> the +over parameter in the proj4 srs is also * I think* a way to handle that 21:40:39 <springmeyer> but it seems unreliable 21:40:42 <Berteun> Ah. 21:40:53 <Berteun> If your provide your own extent the postgis query is modified isn't it? 21:41:14 <milovanderlinden> no, we are not using the wms server 21:41:19 <springmeyer> yes, should be 21:41:33 <milovanderlinden> we are calculating tile dimensions and addressing mapnik through python 21:42:54 <milovanderlinden> springmeyer: wouldn't it be sufficient to give the map an extent? And let all the underlying layers extents be matched against the maps? 21:43:01 <springmeyer> gocha, so you are translating scales/zoom levels to bbox query to mapnik? 21:43:32 <milovanderlinden> yes 21:44:06 <springmeyer> milovanderlinden: yes, in the osm stylesheet extents are manually specified for speed 21:44:27 <Berteun> Yeah, a good extent is a speed increase too. 21:44:31 <Berteun> You'll notice that. :) 21:44:39 <springmeyer> otherwise you can set estimate_extents=true and let postgis try to handle it 21:44:42 <Berteun> But as an added bonus you'll also see something. :) 21:52:10 <milovanderlinden> speed is no issue 21:52:25 <milovanderlinden> so I guess I will go for estimated extents 21:52:32 <Berteun> Won't work either. 21:52:39 <milovanderlinden> Why not? 21:53:01 <Berteun> Because you will try to, say, render the roads. 21:53:06 <Berteun> And there are roads in Russia too. 21:53:13 <Berteun> So Postgis will estimate a /huge/ extent. 21:53:17 <Berteun> Adn then reprojection will fail. 21:53:22 <Berteun> And you won't see anything. 21:53:39 *** audifahrer (n=andreas@p57AF497B.dip.t-dialin.net) has joined #mapnik 21:53:40 <milovanderlinden> Berteun; the extent parameter you gave me, is it for the exact bbox we set up: -23500,289000,316500,629000? 21:53:42 <Berteun> You really have to tell mapnik that it should use those extents, so it will tell Postgis not to select stuff outside of it. 21:53:51 <Berteun> No, I can convert that though. 21:53:53 <Berteun> Hang on. 21:53:56 <milovanderlinden> ok 21:55:59 <Berteun> Coord(319258.074943,6544599.62792) 21:55:59 <Berteun> Coord(871511.551193,7099152.81004) 21:56:19 <Berteun> The ones I gave were for Drenthe only actually. :P 21:59:54 <Berteun> Fingers crossed! 22:06:45 <milovanderlinden> works like a charm! 22:14:57 <Berteun> Yeah. 22:15:11 <Berteun> Rejoice! 22:15:20 <Berteun> \\o o// \\o o// \\o o// 22:16:30 <audifahrer> Hello 22:16:38 <audifahrer> Any ideas to get the map or layer srs from within a plugin? 22:18:44 <Berteun> An input plugin? 22:19:26 <audifahrer> yes 22:19:35 <audifahrer> are there other plugins? 22:20:33 <Berteun> You have a point there... :) 22:21:28 <jburgess> I guess the question is why you need to know the map/layer SRS. The plugin should just provide data... In an ideal world it should be able to declare the SRS of the data, avoiding the need for an SRS on the layer, but that can not be done today 22:22:50 <jburgess> for example, postgis probably knows the SRS of the data it is returning, in theory it should not need to be specified again in the layer 22:24:18 <audifahrer> the reason is that my plugin reads data in WGS84 format. But if I like to place a feature on the map I need to convert coordinates to the map format (here e.g. mercator) 22:25:15 <jburgess> I'd be tempted to say that the correct layer definition for the plugin is latlon/wgs84 and the plugin should not try to reproject the data 22:25:26 <Berteun> Doesn't mapnik do that? 22:25:31 <jburgess> yes it will 22:25:37 <Berteun> I mean, milovanderlinden and I just talked about that. 22:26:02 <Berteun> We have a database in 900913 format, but our map is in Dutch (Amersfoort new) coordinates. 22:26:19 <Berteun> So we say on the map: srs=<dutch> and on the layer: srs=<google> 22:26:22 <Berteun> And it works. 22:26:42 <nikq> Mapnik Trac: Changeset [1016]: - added new et input plugin - add missing files to plugins Makefile.am - ... | http://trac.mapnik.org/changeset/1016 22:26:44 <jburgess> right, mapnik will reproject the data between the layer & map SRS automatically 22:26:52 <Berteun> Yes. 22:26:58 <Berteun> What does it use for that? 22:27:12 <jburgess> the "proj" library 22:27:40 <Berteun> I thought so... 22:27:49 <Berteun> What we had, that it sometimes fails rather silently. 22:28:09 <Berteun> For example, the Dutch system has only a limited area where it is valid. 22:28:17 <jburgess> I was going to mention that the data reprojection does have its own problems 22:28:24 <Berteun> So if you try to plot something outside it, it won't work (proj probably refuses) 22:28:33 <Berteun> But the result is that you simply don't see your data. 22:28:39 <Berteun> No error, no indication. 22:28:55 <jburgess> yep, not ideal 22:30:53 <Berteun> But otherwise it works fine. :) 22:30:53 <jburgess> there are several problems like this where either the co-ordinates are invalid or they wrap so that the projected min/max bounding box is nothing like the bounding box of the projected data 22:31:11 <audifahrer> as you noticed above I just commited the kismet plugin to SVN 22:31:42 <milovanderlinden> mapserver fixes that by not allowing a wrap :D not exactly what I call afix 22:32:55 <jburgess> It is a hard problem though. There seems to be no way to ask proj what the maximum bounds of a given projection are. 22:33:40 <milovanderlinden> because a projection has no bounds 22:33:58 <jburgess> If you project between wildly different systems then there are no guarantees that your nice rectangular bounding box is anything like a nice rectangle in another projection. 22:34:08 <audifahrer> jburgess: For sure I tried to set the layer to WGS84 and set simply used WGS84 coordinated. But that didn't work. If I use the geometry2d::move_to() call than it seems to always use the map srs, not the layer srs. 22:34:36 <milovanderlinden> Exact, jburgess. But that is an issue we have to do with. In the GIS world, this is long solved. 22:34:46 <jburgess> audifahrer: that just sounds wrong. The data is always in the layers SRS, unless you don't have an SRS defined on the layer 22:36:02 <jburgess> without a layer SRS, I think it defaults to the map SRS 22:37:04 <jburgess> http://trac.mapnik.org/wiki/XMLConfigReference#Layer 22:38:52 <audifahrer> http://codepad.org/GzCiTviY 22:38:56 <audifahrer> was he wrong? 22:41:41 <jburgess> maybe we are talking about different things. I believe the WKB reader happily uses line_to & move_to with whatever co-ordinates come in from Postgis. It does not try to reproject them 22:42:36 <audifahrer> hm, I'll try it again. 22:42:57 <audifahrer> <- go off, becaus I could scan or use WLAN, not both :-) 22:44:20 <milovanderlinden> In some cases we get FATAL: connection limit exceeded for non-superusers in layer 'leisure' 22:44:36 <milovanderlinden> Anyone knows what that can be? Is it mapnik related? 22:44:47 <jburgess> as we were discussing a few minutes ago, there are times that the reprojection from the layer -> map breaks down. Then you'll probably get the data coming through without being reprojected 22:45:09 <jburgess> milovanderlinden: that sounds like you're hitting the max DB connection limit in postgresql 22:45:46 <milovanderlinden> Maybe because mapnik leaves connections open? http://code.djangoproject.com/ticket/2770 22:46:02 <jburgess> if you're using something which has no limit on the number of concurrent spawned rendering processes then you can max out your DB connections 22:46:14 <jburgess> it does, it has a pool of 10 connections I think 22:46:42 <milovanderlinden> ok, so we should limit the ammount of concurrent renders, hence maybe even prerender in a single process? 22:47:02 <jburgess> right, or raise the connection limit in postgres 22:47:56 *** vosson_ (n=chatzill@126.80-202-247.nextgentel.com) has joined #mapnik 22:52:36 *** D3f0 has quit (Connection reset by peer) 22:53:30 *** D3f0 (n=defo@190.176.255.232) has joined #mapnik 22:56:00 *** vosson has quit (Read error: 110 (Connection timed out)) 23:02:38 *** audifahrer has quit (Read error: 113 (No route to host)) 23:11:58 *** audifahrer (n=andreas@p57AF497B.dip.t-dialin.net) has joined #mapnik 23:12:47 <audifahrer> hm, does still not work 23:13:37 <audifahrer> in the xml file I use <Parameter name="extent">-20037508,-19929239,20037508,19929239</Parameter> 23:14:08 <audifahrer> maybe I need to recalculate tgat to WGS84 to get it working? 23:14:20 <jburgess> that should be in degrees, try something like -179,-85,179,85 23:15:15 <jburgess> those co-ordinate should avoid issue when they are reprojected to the mercator map 23:15:46 <jburgess> if you pick the obvious onces -180,-90,180,90, then you might run into problems 23:18:08 <jburgess> can you paste your xml file somewhere? 23:18:50 <audifahrer> jburgess: now with the new extent it works :-) 23:18:59 <jburgess> good :) 23:22:58 <nikq> Mapnik Trac: Changeset [1017]: no longer conversation to mercator needed | http://trac.mapnik.org/changeset/1017 23:29:54 <audifahrer> thanks :-) 23:31:05 <audifahrer> I've send an E-Mail to the devel list with more information about the plugin. I hope people will try it and give me feedback... 23:31:11 <audifahrer> bye, good night 23:37:31 *** audifahrer has quit ("Verlassend") 23:51:01 *** vosson_ has quit (Read error: 110 (Connection timed out))