#mapnik log: Friday 30, January 2009

2009 | 01

previous | next
00:29:42 *** rcoup (n=rcoup@ip-58-28-159-166.static-xdsl.xnet.co.nz) has joined #mapnik
00:35:41 *** springmeyer has quit ()
01:14:46 *** dodobas has quit (kubrick.freenode.net irc.freenode.net)
01:14:46 *** Berteun has quit (kubrick.freenode.net irc.freenode.net)
01:14:52 *** dodobas (n=dodobas@open.geof.hr) has joined #mapnik
01:14:52 *** Berteun (i=berteun@berteun.nl) has joined #mapnik
01:17:15 *** dodobas has quit (Remote closed the connection)
01:25:28 *** dodobas (n=dodobas@open.geof.hr) has joined #mapnik
01:40:03 *** kunitoki (n=4f0731d2@67.159.35.76) has joined #mapnik
01:43:57 *** springmeyer (n=dane@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik
01:59:09 *** migurski has quit ()
02:24:48 *** D3f0 (n=defo@190.176.201.163) has joined #mapnik
02:58:24 *** kunitoki has quit ("CGI:IRC (EOF)")
04:01:30 *** rcoup has quit ()
04:25:55 *** dodobas has quit (kubrick.freenode.net irc.freenode.net)
04:25:55 *** Berteun has quit (kubrick.freenode.net irc.freenode.net)
04:26:15 *** dodobas (n=dodobas@open.geof.hr) has joined #mapnik
04:26:15 *** Berteun (i=berteun@berteun.nl) has joined #mapnik
04:30:22 <CIA-23> mapnik-utils: dane.springmeyer * r517 /sandbox/ogr_plugin/maps/world_population_ogr.png: removed
06:20:11 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
07:33:08 *** D3f0 has quit (Remote closed the connection)
07:34:19 *** xcacou (n=aga@112.66.86-79.rev.gaoland.net) has joined #mapnik
08:05:39 *** ninja_ (n=pankur@nat/yahoo/x-8c854b4c0b44c639) has joined #mapnik
08:05:42 *** ninja_ has quit (Remote closed the connection)
08:17:33 *** xcacou has quit (Remote closed the connection)
08:19:44 *** xcacou (n=aga@112.66.86-79.rev.gaoland.net) has joined #mapnik
08:31:58 <CIA-23> mapnik-utils: dane.springmeyer * r518 /sandbox/ (pickling/test_pickling.py pickling): a few tests of pickling
08:44:47 *** migurski has quit ()
08:58:10 <nikq> Mapnik Trac: test_close_page.py attached to Ticket #201 | http://trac.mapnik.org/attachment/ticket/201/test_close_page.py
09:02:37 <nikq> Mapnik Trac: Ticket #201 (Leaving Cairo surfaces open for post-map drawing.) updated | http://trac.mapnik.org/ticket/201#comment:2
10:21:45 *** edbond1 (n=edbond@130.alcatel-2.customers.itsinternet.net) has joined #mapnik
10:22:47 <edbond1> How can I draw street direction arrows?
10:30:18 <Berteun> edbond1: How do you mean? If you tag the road, use oneway=yes (or oneway=-1 of the oneway is opposite to the direction of the road) or do you mean how to configure mapnik to do that?
10:32:07 <edbond1> Berteun: how to configure mapnik. I use LinePatternSymbolizer but it cut arrows.
10:33:41 <Berteun> I don't know, did you look at the osm.xml style how they do it?
10:41:40 <edbond1> The same way. And they have cutted arrows too. Obviously mapnik flaw.
10:43:26 <Berteun> Well, I don't know enough about that, sorry.
11:01:05 *** edbond1 has parted #mapnik ()
11:07:39 *** kunitoki (n=4f0731d2@67.159.35.76) has joined #mapnik
11:38:09 *** kunitoki has quit ("CGI:IRC (EOF)")
11:40:06 *** kunitoki (n=4f0731d2@67.159.35.76) has joined #mapnik
11:45:14 *** kunitoki has quit ("CGI:IRC (EOF)")
11:45:45 *** kunitoki (n=4f0731d2@67.159.35.76) has joined #mapnik
11:47:59 *** kunitoki has quit (Client Quit)
15:57:19 *** migurski (n=migurski@dsl081-049-227.sfo1.dsl.speakeasy.net) has joined #mapnik
16:00:49 *** migurski has quit (Client Quit)
17:18:09 *** xcacou has quit (Remote closed the connection)
17:49:16 <CIA-23> mapnik: dane * r843 /www/mapnik.org/news/models.py: mapnik.org: No more notification of spam - Akismet is excellent
18:58:48 *** D3f0 (n=defo@190.176.201.163) has joined #mapnik
19:17:27 *** scruggs has quit (Remote closed the connection)
19:21:36 *** scruggs (n=chris@75-121-83-226.dyn.centurytel.net) has joined #mapnik
19:53:33 *** D3f0 has quit (Remote closed the connection)
19:55:38 <springmeyer> FYI: http://blog.geoserver.org/2009/01/30/geoserver-and-openstreetmap/
20:03:13 <springmeyer> http://dpaste.com/114817 <-- that would be the xml used by geoserver linked off that blog
20:05:01 <springmeyer> the filter syntax being quite different than mapnik among other things...
20:07:42 <Berteun> The verbosity is killing.
20:33:40 *** loumf (n=Miranda@208.251.184.194) has joined #mapnik
20:34:10 <loumf> Two quick questions about mapnik and iPhone
20:34:15 <loumf> 1. Has anyone tried it?
20:34:49 <loumf> 2. since iphone doesn't allow dynamic linking -- does that mean LGPL means that the app needs to be open source?
20:36:10 <loumf> I'm willing to contribute back a port if necessary, but it won't be able to be a dynlib for iPhone -- it will have to be a lib or source and in both cases, LGPL won't allow closed source apps
20:36:23 <loumf> (at least in my understanding)
20:38:03 <springmeyer> loumf: If no one comments here I would post to mapnik-dev list too
20:38:44 <loumf> springmeyer: thanks
21:32:22 *** JuergenL (n=jl@HSI-KBW-082-212-029-116.hsi.kabelbw.de) has joined #mapnik
22:03:25 *** rcoup (n=rcoup@ip-118-90-54-112.xdsl.xnet.co.nz) has joined #mapnik
22:06:52 *** ser has quit (kubrick.freenode.net irc.freenode.net)
22:06:52 *** crschmidt has quit (kubrick.freenode.net irc.freenode.net)
22:06:55 *** ser (n=ser@sergiusz.pawlowicz.name) has joined #mapnik
22:06:55 *** crschmidt (i=crschmid@helios.crschmidt.net) has joined #mapnik
22:10:08 <Berteun> So, I read something on the Wiki about not changing the geometry type in selects...
22:30:42 <springmeyer> ya, that was me
22:31:09 *** forrestv` (n=forrestv@c-75-74-80-105.hsd1.fl.comcast.net) has joined #mapnik
22:31:13 <springmeyer> you can do it, just have to hack the geometry_columns info...
22:31:18 *** forrestv has quit (Read error: 113 (No route to host))
22:31:24 <Berteun> I did it, and it appeared to work.
22:31:27 <springmeyer> since mapnik looks to the geometry_columns to figure out what type it is
22:31:32 <Berteun> Well, change the geometry and do nothing else.
22:31:39 <springmeyer> okay, great
22:31:53 <Berteun> I select from planet_osm_line and build a polygon.
22:31:54 <springmeyer> perhaps rcoup's recent patches have fixed that
22:32:10 <springmeyer> I've yet to test since they landed in trunk
22:32:26 <springmeyer> okay...
22:32:28 <rcoup> wha ha?
22:32:40 <rcoup> ah
22:32:45 *** forrestv` is now known as forrestv
22:33:05 <springmeyer> rcoup: either my usage of the PostGIS subselect is wrong or your patches are awesome
22:33:10 <Berteun> I had thought of sneaking in a useless comparison to fool mapnik.
22:33:15 <springmeyer> (likely both) :)
22:33:21 <rcoup> my patches are awesome :P
22:33:31 <rcoup> but they don't allow changing a geometry type
22:33:42 <rcoup> unless you add a 2nd record into geometry_columns
22:33:47 <Berteun> Hmm.
22:33:56 <rcoup> all they allow is multiple geom columns in a table
22:34:08 <rcoup> (whether its a synthetic column or not is irrelevant)
22:34:19 <springmeyer> okay, cool
22:34:22 <springmeyer> Berteun must been using 'mapnik magic'! :)
22:34:23 <rcoup> do geometry_field="myOtherField" and mapnik won't just take the 1st one
22:34:34 <rcoup> or its just a coincidence
22:34:43 <rcoup> presumably mapnik defaults to something though
22:34:59 <rcoup> actually, what happens for a true "GEOMETRY" column?
22:35:05 <Berteun> Well, I read the source, and it tries to detect what it is working with by looking at the query.
22:35:14 <rcoup> where one can mix linestrings/polys/etc
22:35:22 <rcoup> Berteun: ah, that rings a bell
22:35:25 <springmeyer> ah.
22:35:51 <rcoup> springmeyer: yeah, you can do "SELECT blah AS polygon" or something....
22:36:20 <springmeyer> Berteun: cool, then have at that wiki as you see fit.
22:36:37 <springmeyer> ah, so the as  'polygon' as relevance?
22:36:37 <rcoup> more explictly table="(SELECT blah FROM foo) AS polygon"
22:37:12 <rcoup> springmeyer: it's some hack for the way mapnik uses geometry_columns and builds its queries
22:37:14 <Berteun> It tries to find where 'from' is in the query (if I understand it correctly)
22:37:15 <rcoup> iirc
22:37:34 <Berteun> And then what the table name of the word following from is, and looks up its geometry type.
22:37:51 * rcoup spouts away without looking at any code
22:37:55 <springmeyer> ah ha.
22:38:28 <Berteun> It looks for the right most appearance of from also.
22:38:57 <Berteun> So if that analysis correct, and you have (like me :)) only read access to the database), sneaking in a useless condition like: or 'from planet_osm_polygon ' < 'a' ; could help.
22:39:04 <jburgess> I remember that Mapnik reads the column to find the name, I don't remember it caring what the type is. It has a wkb reader which will cope with any common things it receives
22:39:27 <Berteun> But also without this 'hack' it worked.
22:39:32 <Berteun> So then I was confused.
22:40:28 <Berteun> jburgess: So anything like polygon, point or linestring should work anyway?
22:41:22 <jburgess> I think so yes, but I've not checked the code to be sure
22:42:00 <jburgess> for all other columns, mapnik does care what the type is, since it needs to know how to interpret the data it gtes back
22:42:31 <jburgess> but for geometry columns I think it gets them all back as WKB and the reader takes care of working out what type is encoded in the binary
22:44:20 <jburgess> I think it also reads the SRID of the geometry column, but only so that it can put a matching SRID in the bbox queries it generates.
22:45:06 <Berteun> Those are all the same, so that doesn't confuse.
22:45:16 <rcoup> jburgess: so in that case, my geometry_field= patch should allow use of views,etc without nasty hacks
22:45:38 <rcoup> since it'll just use whatever column its told to, and not need to find it in geometry_columns...
22:47:46 <jburgess> in plugins/input/postgis/postgis.cpp, the code queries the 'type' for the column and stores in postgisType=rs->getValue("type"), but this looks like it is never used
23:08:25 <nikq> Mapnik Trac: Changeset [844]: Make true boolean whether we save and read from user 'config.py' file, and  ... | http://trac.mapnik.org/changeset/844
23:12:22 <jburgess> I didn't realise it updated the config.py automatically when you set options on the command line. I did wonder how it magically managed to get the right GDAL settings when I ran scons for a second time without the option on the command line!
23:17:53 <CIA-23> mapnik: dane * r844 /trunk/SConstruct: Make true boolean whether we save and read from user 'config.py' file, and clean up messages
23:40:38 *** rcoup has quit ()
23:50:00 *** ajturner (n=ajturner@209.155.228.129) has joined #mapnik
23:54:19 *** ajturner has quit ()