00:22:12 *** tmcw1 has quit ("Leaving.")
00:26:07 *** ajashton has quit (Remote closed the connection)
00:58:06 *** Ldp__ has quit ()
01:27:07 *** cgs_bob has quit (Remote closed the connection)
01:30:12 *** tmcw (n=Adium@c-68-48-250-72.hsd1.dc.comcast.net) has joined #mapnik
01:36:33 *** tmcw has quit ("Leaving.")
02:04:57 *** cgs_bob (n=bobm@122.135-78-65.ftth.swbr.surewest.net) has joined #mapnik
02:35:32 *** tcb_ has quit ()
03:02:36 *** rweait has quit (Read error: 60 (Operation timed out))
03:17:32 *** rweait (n=nerd@weait.tor.istop.com) has joined #mapnik
07:46:08 *** Ldp__ (n=thid@osm.xs4all.nl) has joined #mapnik
13:53:31 *** willwhite (n=diggersf@c-68-33-227-150.hsd1.md.comcast.net) has joined #mapnik
14:45:47 *** artem (n=artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik
14:46:06 *** ajashton (n=aj@c-68-33-227-150.hsd1.md.comcast.net) has joined #mapnik
14:57:28 *** aub has quit (Read error: 60 (Operation timed out))
15:37:20 *** aub (n=aubrey@h-64-236-128-41.nat.aol.com) has joined #mapnik
15:44:34 <nikq> Mapnik Trac: Changeset [1520]: + remove mapnik2 syntax + fix compiler warnings | http://trac.mapnik.org/changeset/1520
15:44:34 <nikq> Mapnik Trac: Changeset [1521]: + revert mapnik2 syntax | http://trac.mapnik.org/changeset/1521
15:44:37 <nikq> Mapnik Trac: Changeset [1522]: + fix compiler warning | http://trac.mapnik.org/changeset/1522
15:45:59 *** myselfhimself (i=3e648dd8@gateway/web/freenode/x-zmyisifohwvjeckq) has joined #mapnik
15:46:06 <myselfhimself> hi !
15:46:18 <myselfhimself> I have a compilation problem with mapnik's latest svn
15:46:39 <myselfhimself> src/expression_string.cpp: In member function âvoid mapnik::expression_string::operator()(const mapnik::regex_match_node&) constâ: src/expression_string.cpp:79: error: âfromUTF32â is not a member of âicu_3_8::UnicodeStringâ
15:46:42 <myselfhimself> this is the idea
15:47:02 <myselfhimself> do I not need some additional library like ICU ?
15:47:16 <myselfhimself> I don't know C++ well...
15:48:30 <artem> myselfhimself:: you need latest ICU library 4.x
15:48:35 <myselfhimself> ok
15:48:43 <myselfhimself> I had installed it from ubuntu's repos
15:49:05 *** micka (n=micka@ppp-216.net-62-100-141.static.magiconline.fr) has joined #mapnik
15:49:10 <myselfhimself> ok my version is 3.8....
15:49:18 <micka> hey JOJO
15:49:24 <myselfhimself> hey micka !!!
15:49:42 <artem> you might need to build from source on ubuntu
15:50:24 <artem> milestone 0.7
15:50:26 <nikq> No Milestone for that release number
15:50:33 <artem> hm..
15:50:55 <artem> milestone 0.7.0
15:50:56 <nikq> 4 open tickets in Milestone 0.7.0: Doesn't display feature if another (possibly invalid) feature is present, Expose cairo functionality without needing pycairo, Document (and reflect in python) new symbolizer options added in r1341, Catch up on Changelog before 0.7.0 release
15:50:57 <nikq> http://trac.mapnik.org/query?status=new&status=assigned&status=reopened&milestone=0.7.0&order=priority
15:50:58 <nikq> Milestone Roadmap: http://trac.mapnik.org/milestone/0.7.0
15:51:15 <myselfhimself> ok artem thanks
15:51:24 <artem> no probs
15:55:05 <myselfhimself> artem: mapnik/scons/scons.py should have prevented me from running the compilation by checking that icu is > 4.x
15:55:05 <myselfhimself> maybe there was a warning but I skipped it and scons compiled right away
15:55:05 <artem> good point, there's no checks for >= 4.x at the moment
15:55:05 <myselfhimself> : )
15:56:24 <nikq> Mapnik Trac: Ticket #482 (Check for ICU library version >= 4.x) created | http://trac.mapnik.org/ticket/482
15:59:10 <myselfhimself> nikq: cool
15:59:13 <myselfhimself> !!!
15:59:16 <myselfhimself> thanks for everyone !!
16:06:12 <Ldp__> artem: springmeyer talked about backporting removing the need for width/height on symbols from trunk to 0.7 branch. Was that done, that you know if?
16:06:15 <Ldp__> if=of
16:13:25 <artem> Ldp__:  not sure
16:13:41 <Ldp__> because that would be great to get into 0.7, and he agreed :)
16:13:52 <Ldp__> since it's already done for trunk
16:14:22 <artem> yes, definitely
16:16:35 <artem> Ldp__:  I just pulled 0.7 and it looks like old width/height logic is still there
16:17:05 <nikq> Mapnik Trac: Ticket #60 (XML: Make 'width', 'height' and 'type' attributes optional) updated | http://trac.mapnik.org/ticket/60#comment:10
16:17:36 <nikq> Mapnik Trac: Ticket #60 (XML: Make 'width', 'height' and 'type' attributes optional) updated | http://trac.mapnik.org/ticket/60#comment:11
16:18:36 <artem> Ldp__: ok, cool
16:19:04 <Ldp__> so we won't forget. Dane said he'd backport if it hadn't been done
16:19:17 <Ldp__> that would drop quite some bytes off osm.xml :)
16:19:47 <Ldp__> artem: with path expressions in 0.8.0, what happens when it resolves to a non-existing symbol file?
16:22:09 <artem> at the moment it silently ignored per features, also image_cache will try to load non-existent image on subsequent calls. We can throw runtime error ?
16:22:38 <Ldp__> if you do, that will only force me to guard the value in sql
16:23:29 <artem> I meant to say throw and catch and print something useful
16:23:33 <cmarqu> (Optional) runtime warnings would be col for such things
16:23:52 <artem> yep, warning is the right term:)
16:24:28 <artem> things will get more interesting when we'll try access remote resources through URLs
16:24:43 <cmarqu> It shouldn't make renderd abort (as is the case right now with the newish SQL errors)
16:25:12 <artem> cmarqu: agree
16:25:28 <Ldp__> artem: cacheable="yes" and then it only does an ETAG check on the remote resource after that?
16:26:20 <Ldp__> would that make sense? else you're reloading every symbol after a renderd restart, for instance. Or even worse, for every tile in simpler rendering stacks
16:27:37 <artem> Ldp__: I see,  we need persistent cache then
16:28:22 <Ldp__> think so, but I wouldn't want to rely on remote resources anyway, unless they're on servers I control and are local
16:29:19 <Ldp__> but that's me, personally
16:29:22 <artem> Ldp__: make sense to me, but some folks asked for remote resources support ..
16:29:37 <Ldp__> exactly, not my cup of tea, but to each his own
16:29:55 <Ldp__> cascadenik already does it, iirc
16:30:57 <artem> Ldp__; I think Mike (cascadnik) is the person who asked for this :)
16:31:40 <Ldp__> figures :)
16:31:52 <artem> it's attractive to be able to publish complete mapnik style on the web, but then what's wrong with a zip?
16:32:19 <Ldp__> or rsync, or wget, etc
16:32:29 <artem> sure
16:43:34 *** j03lar50n (n=SLU_GIS@68-189-119-178.static.wscr.ca.charter.com) has joined #mapnik
16:44:09 <nikq> Mapnik Trac: Changeset [1523]: + removed empty virtual dtor - not needed | http://trac.mapnik.org/changeset/1523
16:48:23 <nikq> Mapnik Trac: Ticket #60 (XML: Make 'width', 'height' and 'type' attributes optional) updated | http://trac.mapnik.org/ticket/60#comment:12
16:50:33 <Ldp__> artem: I hope that if width/height are still on the symbolizer, that will override what the loader sees in the file? Referring to Andy's remark in the linked discussion here
16:51:47 <Ldp__> I can't wait to apply 0.8 changes to osm.xml, but it will be a while before we finally switch
16:52:39 <artem> Ldp__: I'm thinking about optional width/height and if present use them to scale up/down input image
16:53:15 <Ldp__> Andy mentions he's using a 1x1px transparent png which he scales to whatever size he needs
16:54:19 <cmarqu> preserve_aspect_ratio could be a useful parameter
16:54:27 <artem> Ldp
16:55:08 <artem> Ldp__:  1x1px transparent png - sounds like web designer hack:)
16:55:20 <artem> cmarqu: yep
16:57:34 <Ldp__> it sure does :)
16:57:48 <Ldp__> maybe he needs a builtin blank symbol? :)
16:58:16 <artem> I might see Andy in the local pub tomorrow, I'll ask him :)
16:58:46 <Ldp__> there is some merit in being able to nudge the placement logic by setting an exclusion zone :)
17:00:07 <cmarqu> Some kind of internal raster data source would be useful for the blending effects Mike wants. (ImageMagick also can synthesize e.g. a completely black image)
17:01:13 <artem> good points for mapnik2
17:01:16 <Ldp__> this would combine well with being able to render graphics primitives. Just ask for a x by y pixels transparent rectangle.
17:03:42 <artem> This is related to compositing renderer where each layer rendered into it's own image and then this image blended into main one.
17:04:29 <artem> using available blending modes ?
17:04:55 <Ldp__> yes. However advanced compositing would be able to render a number of layers into an image, before compositing that with other layers/images
17:05:08 <artem> sure
17:05:34 <Ldp__> I know Dane was working on graphics primitives last year. Or at least talked about them at some length
17:05:47 <artem> Also, we can and should have blending modes per feature in agg_renderer at least
17:06:08 <artem> Ldp__: what do you mean by primitives - drawing lines/polygions?
17:06:29 <Ldp__> circles, rectangles, stars. He wanted to be able to draw circles where the size depended on an input field
17:06:44 <artem> Ldp__: gotcha
17:07:25 <Ldp__> I was looking for a ticket, but can't find it and don't know if it was created back then
17:08:22 <Ldp__> I'm off for now...
17:08:40 <artem> good talking to you , see you later
17:10:19 *** springmeyer (n=springme@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik
17:10:30 *** jctull has quit ()
17:16:08 *** j03lar50n1 (n=SLU_GIS@68-189-119-178.static.wscr.ca.charter.com) has joined #mapnik
17:16:21 *** j03lar50n1 has quit (Remote closed the connection)
17:19:23 <springmeyer> Ldp__: hey there - do you know why the builtup_area shapefile is in standard mercator rather than spherical merc?
17:22:26 *** j03lar50n1 (n=SLU_GIS@68-189-119-178.static.wscr.ca.charter.com) has joined #mapnik
17:22:59 <artem> springmeyer: because I projected it into proper mercator
17:23:46 <artem> (before we moved to spherical )
17:23:57 <springmeyer> ah, ah
17:24:16 <artem> it's vmap0 data, we can fix it :)(
17:24:52 <springmeyer> ya, seems like it could be a small speed boost
17:25:00 <artem> springmeyer: yep
17:25:53 <artem> springmeyer: I'm away for a couple hours  but planning to be around later on. We're getting very close to 0.7.0 release :)
17:26:04 <springmeyer> great, talk to you soon
17:27:55 <springmeyer> small question to ponder on mapnik2 - do we need template-depth-200 for all the mapnik code?
17:28:22 <springmeyer> perhaps just the core library? My guess is that it is increasing compile times for boost::python
17:32:21 *** j03lar50n1 has quit ("Leaving.")
17:34:03 *** jctull (n=jctull@adsl-75-0-1-39.dsl.renocs.sbcglobal.net) has joined #mapnik
17:34:04 *** j03lar50n has quit (Read error: 110 (Connection timed out))
17:34:31 *** j03lar50n (n=SLU_GIS@68-189-119-178.static.wscr.ca.charter.com) has joined #mapnik
17:37:26 <springmeyer> hmm, odd: http://tile.openstreetmap.org/11/31/675.png
17:43:02 *** tcb_ (n=tcb@adsl-75-10-247-30.dsl.pltn13.sbcglobal.net) has joined #mapnik
17:47:45 *** jctull_ (n=jctull@75.0.1.39) has joined #mapnik
17:53:54 <myselfhimself> hi again
17:54:18 <myselfhimself> I have an issue importing mapnik after a successful compilation from trunk
17:54:45 <myselfhimself> this is it :
17:54:46 <myselfhimself>     from _mapnik import * ImportError: libicudata.so.38: cannot open shared object file: No such file or directory
17:54:57 <springmeyer> $ sudo ldconfig
17:55:00 <myselfhimself> ok
17:55:21 <myselfhimself> after sudo ldconfig
17:55:34 <myselfhimself> I do python; and then type import mapnik and still get the same error sorry
17:55:45 <springmeyer> what linux version?
17:56:05 <springmeyer> do you have /usr/local/lib in /etc/ld.so.conf ?
17:56:13 <myselfhimself> I had compiled the lib ICU from svn too and the version 4.2 (instead of older 3.8 that I had from a package and uninstalled prior to make-installing lib ICU)
17:56:19 <myselfhimself> I'm on ubuntu 8.04
17:57:26 <myselfhimself> I do have /usr/local/lib in /etc/ld.so.conf/libc.conf which is include in /etc/ld.so.conf
17:57:35 <springmeyer> good
17:57:44 <springmeyer> where did you install icu?
17:57:56 <springmeyer> have you uninstalled the packaged icu that was the wrong version?
17:57:59 <myselfhimself> it is in /usr/local/lib
17:58:00 <myselfhimself> I see it
17:58:26 <myselfhimself> ls /usr/local/lib | grep icu gives ... libicudata.so libicudata.so.42 libicudata.so.42.1 .. etc
17:58:47 <myselfhimself> and there's no libicu* file containing a 38-something number at all
17:58:57 <springmeyer> I would guess that you did not uninstall icu 3.8....
17:59:02 <springmeyer> its likely in /usr/lib ?
17:59:03 <myselfhimself> yes
17:59:09 <myselfhimself> I removed that icu 3.8
17:59:12 <springmeyer> oh
17:59:27 <springmeyer> well Mapnik linked to it, so I would recompile Mapnik again
17:59:28 <myselfhimself> instead, I compiled icu 4.2 from source and make install'ed it
17:59:33 <myselfhimself> ok
17:59:51 <springmeyer> I recommend just checking out a new, fresh svn directory
17:59:52 <myselfhimself> but Mapnik failed to compile if I had libicu 3.8 -dev
18:00:01 <myselfhimself> I have a fresh svn from today
18:00:02 <springmeyer> okay
18:00:10 <springmeyer> trunk or 0.7 branch?
18:00:20 <myselfhimself> hm
18:00:22 <myselfhimself> trunk I think
18:00:36 <springmeyer> okay
18:01:21 <myselfhimself> how do I know I have trunk or 0.7 branch ?
18:01:37 <springmeyer> svn info
18:01:55 <myselfhimself> URL: http://svn.mapnik.org/trunk
18:02:00 <myselfhimself> (from svn info)
18:02:05 <springmeyer> that would be trunk :)
18:02:12 <myselfhimself> : )
18:02:13 <springmeyer> which is fine, I was just curious
18:02:18 <myselfhimself> ok
18:02:27 <springmeyer> I think that only trunk has the icu >=1.4 dependency
18:03:12 <myselfhimself> I think that the scons compilation doesn't require icu >= 1.4 (but I realised and spoke to people here, that I need 1.4 for some piece of code (UnicodeString::fromUTF32) to work, and developers here agreed and filed a ticket even)
18:03:38 <myselfhimself> and that also the scons compilation links mapnik against icu 3.8 though
18:04:23 <springmeyer> yes, I agree with the first statement
18:04:24 <myselfhimself> scons's config should be updated to link againt icu 1.4
18:04:43 <myselfhimself> or.. I don't know actually what's in the config
18:04:48 <springmeyer> but the scons conf does not link to a specific version
18:04:52 <myselfhimself> ok
18:05:00 <springmeyer> all you need to do is reconfigure so the right version is found
18:05:06 <springmeyer> python scons/scons.py configure
18:05:08 <myselfhimself> ok
18:05:11 *** jctull__ (n=jctull@75.0.1.39) has joined #mapnik
18:05:25 *** jctull has quit (Read error: 110 (Connection timed out))
18:05:25 *** jctull__ is now known as jctull
18:06:01 <myselfhimself> well ... I had run the compilation (which runs a configure automatically first before compilation) with cd mapnik/ ; python scons/scons.py
18:06:34 <springmeyer> yes, configure runs once if you have not done so
18:06:35 <myselfhimself> ok....
18:06:44 <myselfhimself> I understand now
18:06:51 <springmeyer> so that was after installing 1.4 and uninstall 1.3 ?
18:06:52 <myselfhimself> the project was configured at first for icu 3.8
18:06:57 <springmeyer> yep
18:07:11 <myselfhimself> then the compilation stopped for the because it needed icu 1.4
18:07:18 <springmeyer> so, you're likely close!
18:07:27 <myselfhimself> but the reconfigure was not done at least for the remaining objects to compile
18:07:36 <springmeyer> oh, hm
18:07:37 <myselfhimself> sorry for the previous objects that had been compiled
18:07:43 <springmeyer> yes, perhaps
18:07:46 <myselfhimself> so ok
18:07:51 <springmeyer> to clean all targets to be sure do
18:07:52 <myselfhimself> I'll try to run the configure step only
18:07:55 <myselfhimself> yes
18:07:56 <myselfhimself> ok
18:07:58 <springmeyer> python scons/scons.py -c
18:08:01 <myselfhimself> thanks
18:08:02 <myselfhimself> ok
18:08:03 <myselfhimself> cool
18:08:25 <springmeyer> (will remove already compiled stuff that might have references to 3.8)
18:08:40 <springmeyer> (though that does not quite explain a linking error)
18:08:44 <springmeyer> but, good to do anyway
18:09:06 <Ldp__> springmeyer: that 675.png tile you pasted, what's odd?
18:09:06 <myselfhimself> ok
18:09:24 <springmeyer> Ldp__: shifted coastline boundaries?
18:09:55 <Ldp__> I think you're looking at shapefile landmass and OSM administrative boundaries
18:09:57 <springmeyer> between what looks like two different representations of the coastline
18:10:07 <springmeyer> okay
18:10:20 <Ldp__> the coastline was probably traced from shifted aerial photography
18:10:21 <Ldp__> or landsat
18:10:36 <springmeyer> gocha, okay
18:10:49 <Ldp__> needs someone to come along and fix it, sometime. Won't be me :)
18:11:14 * springmeyer will keep it in mind
18:13:38 <myselfhimself> what should I type to do python scons/scons.py "configure only please" ?
18:14:10 <myselfhimself> there is --config=MODE
18:14:40 <springmeyer> python scons/scons.py configure
18:16:35 <myselfhimself> ok thanks
18:16:48 <myselfhimself> I have realised something
18:17:34 <myselfhimself> I first svn co + compiled libboost (against old libicu 3.8), then svnco+compiled libicu (which made installed libicu=4)
18:18:12 <springmeyer> oh oh
18:18:15 <myselfhimself> so my libboost compiled libs which depend on libicu (case of the regexp's part of libboost) is out of date
18:18:31 <myselfhimself> so I'll recompile libboost but not libicu
18:18:34 <springmeyer> from the error above you did not give  enough detail to know that it was boost's problem not libmapnik
18:18:35 <myselfhimself> and then mapnik
18:18:38 <springmeyer> yes, that makes sense
18:18:56 <myselfhimself> the current configure action gives an error on libboost's regexp
18:19:02 *** jctull_ has quit (Read error: 110 (Connection timed out))
18:19:04 <springmeyer> yep
18:19:15 <springmeyer> only libboost_regex uses icu
18:19:20 <myselfhimself> and greping my mapnik folders for icu, I get an error about a libboost regexp object linked against icu 3.8 which can't be found
18:19:20 <springmeyer> and it is optional in boost
18:19:25 <myselfhimself> ok
18:19:34 <springmeyer> but I think mapnik trunk depends on boost with regex + icu
18:19:41 <springmeyer> yep
18:20:02 *** crust has quit ()
18:20:52 *** crust (n=crust@vobster.nepharia.org) has joined #mapnik
18:21:41 <myselfhimself> yes that's it
18:21:55 <myselfhimself> ok so thank you very much for your care
18:22:04 <myselfhimself> you have been so helpful making me understand what's wrong
18:22:10 <myselfhimself> !!!!
18:22:13 <myselfhimself> : ) thanks
18:23:05 <springmeyer> good good
18:23:21 <springmeyer> building trunk is currently quite rigorous
18:23:44 <springmeyer> we plan to keep the 0.7 branch as up to date as possible without requiring any source installs like this on linux
18:24:04 <springmeyer> but I think know that you are on the right track the features of trunk will be great to have
18:24:28 <Ldp__> springmeyer: experiences differ. I only had to get boost 1.41 to be able to compile trunk
18:25:20 <springmeyer> good good :)
18:26:11 <myselfhimself> Ldp__: though you had to compile boost yourself or you got a package ?
18:26:41 <Ldp__> I'm on gentoo, it's compile all the way (but it's still under portage control)
18:27:13 *** artem has quit ()
18:28:09 <myselfhimself> ok : )
18:33:35 <myselfhimself> what's the command to remove libboost on ubuntu ?
18:34:02 <myselfhimself> I tried sudo apt-get remove libboost-* or ending in just * but both don't work
18:34:56 <springmeyer> apt-cache show boost*
18:35:02 <springmeyer> should give you the names...
18:36:06 <springmeyer> hmm, no that does not work...
18:37:00 <springmeyer> maybe something like:
18:37:00 <springmeyer> apt-cache show libboost1.35-dev
18:37:17 <springmeyer> will give you the list of other pkg names,,, though there should be a better way :)
18:39:08 <myselfhimself> is't ok
18:39:14 <myselfhimself> I apologize
18:39:19 <myselfhimself> actually no package was installed
18:39:36 <myselfhimself> I could see things in /usr/local/lib due to the ./jame install of libboost
18:39:50 <myselfhimself> so I just rm'ed all the libboost libs by hand
19:05:34 <myselfhimself> in scons' configure
19:05:40 <myselfhimself> I get   for boost : *no lib naming extension found
19:05:58 <myselfhimself> I don't want to run a mapnik compilation with something impeding again
19:06:13 <myselfhimself> is that critical ?
19:06:15 <springmeyer> that is fine
19:06:19 <myselfhimself> or should I fix it somehow
19:06:19 <myselfhimself> ok
19:06:20 <myselfhimself> thanks
19:06:29 <springmeyer> just means that the symlinks are nice and short
19:06:36 <myselfhimself> I'll compile mapnik in a screen
19:06:37 <myselfhimself> ok
19:07:40 <myselfhimself> how can I both make and make install if make succeeded ?
19:08:16 *** aub has quit (Read error: 60 (Operation timed out))
19:08:20 <myselfhimself> python scons/scons.py && python scons/scons.py install ?
19:09:32 *** micka has quit ("Leaving")
19:10:19 <myselfhimself> springmeyer: : )
19:10:51 <springmeyer> just:
19:10:53 <springmeyer>  python scons/scons.py install
19:10:59 <myselfhimself> ok : )
19:11:02 <myselfhimself> you rock thanks
19:11:08 <springmeyer> shhhh, secret
19:11:24 <cmarqu> :)
19:17:41 <Ldp__> springmeyer: I told artem about #60 and he seems to have taken that up
19:17:41 <nikq> Ticket #60: "XML: Make 'width', http://trac.mapnik.org/ticket/60
19:17:51 <springmeyer> that is cool
19:18:12 <springmeyer> since he should review keeping the options at the same time
19:18:21 <Ldp__> yep
19:18:22 <springmeyer> and would be much faster as porting to 0.7 than I
19:18:32 <Ldp__> why is nikq cutting of the ticket description?
19:18:42 <springmeyer> but, the fact that I don't know C++ never stopped me! arrr arrr
19:18:54 <springmeyer> Ldp__: not sure
19:19:02 <springmeyer> #59
19:19:02 <nikq> Ticket #59: XML: Make datasource 'type' parameter an attribute of <Datasource/>, http://trac.mapnik.org/ticket/59
19:19:17 <Ldp__> it new it before, when I commented: <nikq> Mapnik Trac: Ticket #60 (XML: Make 'width', 'height' and 'type' attributes optional) updated | http://trac.mapnik.org/ticket/60#comment:10
19:19:19 <nikq> Ticket #60: "XML: Make 'width', http://trac.mapnik.org/ticket/60
19:19:35 <springmeyer> huh
19:19:56 <springmeyer> likely because I wrote nikq while drinking a beer
19:20:24 <myselfhimself> okok
19:20:26 <myselfhimself> I'm going
19:20:42 <myselfhimself> thank very much to everyone for the help I got here : )
19:20:59 <myselfhimself> mapnik is compiling in a screen on a remote server
19:21:30 <myselfhimself> I hope the compiled shared libs & executables will work this time : )
19:21:33 <myselfhimself> see you !!
19:21:46 <myselfhimself> I was amazed having so good & quick support here
19:22:06 <springmeyer> glad, thanks myselfhimself
19:22:17 <springmeyer> have fun with Mapnik!
19:22:22 <myselfhimself> : )
19:22:23 <myselfhimself> thanks
19:22:24 <myselfhimself> ++
19:22:25 *** myselfhimself has quit ()
19:23:20 *** ajturner has quit ()
19:55:03 *** aub (n=aubrey@h-64-236-128-41.nat.aol.com) has joined #mapnik
19:58:37 <springmeyer> cgs_bob: did you see that mapnik got added to OSGEO4W ?
20:26:33 *** avar has quit (Remote closed the connection)
20:26:38 *** avar (i=avar@wikipedia/avar) has joined #mapnik
20:27:23 <nikq> Mapnik Trac: Ticket #483 (Cairo support in windows binaries) created | http://trac.mapnik.org/ticket/483
20:30:53 <nikq> Mapnik Trac: Ticket #402 (Some points from PointDatasource get lost on reprojection) reopened | http://trac.mapnik.org/ticket/402#comment:15
20:31:44 <nikq> Mapnik Trac: Ticket #402 (Some points from PointDatasource get lost on reprojection) updated | http://trac.mapnik.org/ticket/402#comment:16
20:45:46 <nikq> Mapnik Trac: Ticket #484 (Scons: ability to ensure -L/usr/local/lib comes before -L/usr/lib) created | http://trac.mapnik.org/ticket/484
20:56:40 *** artem_ (n=artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik
21:07:09 *** jctull has quit ()
21:09:21 *** jctull (n=jctull@adsl-75-0-1-39.dsl.renocs.sbcglobal.net) has joined #mapnik
21:09:25 *** jctull has quit (Remote closed the connection)
21:50:05 *** artem_ has quit ()
22:07:55 <Ldp__> springmeyer: I thought you had fixed vertical_alignment to default to bottom again, on TextSymbolizer ?
22:08:16 <Ldp__> or am I misreading `TextSymbolizer ?
22:09:08 * springmeyer distracted by http://gmajna.net/svojat/lemmy/gaea-1.png
22:09:09 <Ldp__> ah, the doc needs updating. It says the default is bottom
22:09:10 <springmeyer> :)
22:09:17 <Ldp__> that's a bit whack, though
22:09:28 <springmeyer> Ldp__: the default should be middle, now
22:09:31 <springmeyer> was not before
22:09:38 <Ldp__> that has serious impact on dx/dy'd multiline labels
22:09:49 <Ldp__> eh, dy only
22:10:09 <Ldp__> what was the rationale for middle as default?
22:10:35 <springmeyer> well, is setting explicitly bottom not okay?
22:10:59 <Ldp__> I think we need more logic here. If you dy a label off a point, so when you put a label under or over a symbol, you definately do NOT want vertical_alignment="middle"
22:11:20 <springmeyer> the only rational/thinking was driven by point placement in polygons
22:11:25 <springmeyer> which may be near-sighted
22:11:26 <Ldp__> hm
22:11:56 <Ldp__> for TextSymbolizer, the default should vary. Default when no dy should be middle. bottom for +dy, top for -dy
22:12:21 <springmeyer> interesting.
22:12:28 <Ldp__> if you place a singleline label just under a symbol with dy, it would show, but would be dropped the moment you go multiline
22:12:34 <springmeyer> certainly can put that logic in load_map if you think it is needed
22:12:45 <Ldp__> well, think about it
22:13:00 *** artem_ (n=artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik
22:13:15 <springmeyer> the whole pointsymbolizer <-> textsymbolizer interaction is fragile, yes
22:13:21 <cgs_bob> springmeyer: good to hear about maonik being in osgeo4w.  I guess my ticket can be closed now
22:13:35 <springmeyer> cgs_bob: yes, I think I closed it already
22:14:13 <cgs_bob> springmeyer: thanks
22:14:13 <Ldp__> if you move a label with dy to be just under a symbol, with middle it would be okay. But the 'middle' in a 2 line label is between the lines, causing the top line to intersect the symbol, and thus be dropped
22:15:09 <springmeyer> the latter being new behavior after r1341, right?
22:15:10 <nikq> http://trac.mapnik.org/changeset/1341, at , by artem: Patch from David Eastcott :
22:15:32 <Ldp__> I'm looking at r1515
22:15:33 <nikq> http://trac.mapnik.org/changeset/1515, at , by dane: fix default values for vertical_alignment in the TextSymbolizer and ShieldSymbolizer - closes #468
22:16:35 <Ldp__> 1341 is likely the origin, yes
22:17:33 <springmeyer> yep, changed it
22:17:52 * springmeyer still has to understand many of those changes, document them, and expose in python
22:18:11 <springmeyer> whewwwww
22:18:35 * springmeyer heads back to invoicing
22:18:46 <springmeyer> sorry can't give it more attention right now Ldp__
22:19:18 <Ldp__> I'll open a ticket with an example
22:20:37 <springmeyer> __thank you__
22:49:44 *** artem_ has quit ()
22:50:49 <nikq> Mapnik Trac: Ticket #485 (TextSymbolizer vertical_align should have varying default) created | http://trac.mapnik.org/ticket/485
22:51:30 <nikq> Mapnik Trac: valign-bottom_1line_dy10.png attached to Ticket #485 | http://trac.mapnik.org/attachment/ticket/485/valign-bottom_1line_dy10.png
22:51:41 <nikq> Mapnik Trac: valign-bottom_2line_dy16.png attached to Ticket #485 | http://trac.mapnik.org/attachment/ticket/485/valign-bottom_2line_dy16.png
22:51:51 <nikq> Mapnik Trac: valign-middle_1line_dy16.png attached to Ticket #485 | http://trac.mapnik.org/attachment/ticket/485/valign-middle_1line_dy16.png
22:52:02 <nikq> Mapnik Trac: valign-middle_2line_dy16.png attached to Ticket #485 | http://trac.mapnik.org/attachment/ticket/485/valign-middle_2line_dy16.png
22:52:09 *** j03lar50n has quit (Read error: 104 (Connection reset by peer))
22:53:03 <Ldp__> there ya go
22:55:19 <nikq> Mapnik Trac: Ticket #485 (TextSymbolizer vertical_align should have varying default) updated | http://trac.mapnik.org/ticket/485#comment:1
23:07:35 *** myselfhimself (i=55ab8821@gateway/web/freenode/x-klbpidwddjafdzcs) has joined #mapnik
23:07:38 <myselfhimself> hi
23:07:52 <myselfhimself> I've just finished compiling mapnik
23:08:16 <myselfhimself> and running import mapnik inside python (after a sudo ldconfig) gives the following error :
23:08:35 <myselfhimself> Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/lib/python2.5/site-packages/mapnik/__init__.py", line 53, in <module>     from _mapnik import * ImportError: /usr/local/lib/libmapnik.so.0.8: undefined symbol: _ZN5boost11basic_regexIiNS_16icu_regex_traitsEE9do_assignEPKiS4_j
23:09:19 <Ldp__> did you consciously build trunk instead of the 0.7 branch?
23:09:29 <myselfhimself> yes
23:09:37 <springmeyer> sudo ldconfig ?
23:09:39 <myselfhimself> I've built the trunk
23:09:40 <myselfhimself> yes
23:09:44 <myselfhimself> yes sudo ldconfig
23:09:50 <springmeyer> bugger
23:10:03 <myselfhimself> I can show a dump of ldd ....libmapnik.so.0.8
23:10:12 <springmeyer> dpaste.com
23:10:15 <myselfhimself> ok
23:13:08 <myselfhimself> http://dpaste.com/142717/
23:13:09 <myselfhimself> thanks
23:14:19 *** artem_ (n=artem@i-83-67-73-6.freedom2surf.net) has joined #mapnik
23:16:37 <springmeyer> myselfhimself: when you built boost from source...
23:16:47 <myselfhimself> :)
23:16:51 <springmeyer> did you explicitly add any flags to compile against icu?
23:16:56 <myselfhimself> no
23:17:10 <springmeyer> did you get any warning about ICU/Regex support?
23:17:15 <myselfhimself> maybe
23:17:24 <myselfhimself> let me see
23:17:52 <springmeyer> you may need:
23:17:55 <springmeyer> bjam -sHAVE_ICU=1
23:18:12 <springmeyer> artem_: is icu support compiled into boost_regex mandatory now for Mapnik?
23:19:18 <artem_> yes
23:19:45 <artem_> it needed to support unicode in expressions
23:19:55 <springmeyer> right, thought so, thanks for confirming
23:20:24 <artem_> correction: to support unicode in regex
23:20:37 <springmeyer> right
23:20:53 <springmeyer> myselfhimself:  you can rebuild just the boost regex library with ICU support like this:
23:21:11 <springmeyer> sudo bjam  --with-regex \
23:21:12 <springmeyer>   toolset=gcc \
23:21:12 <springmeyer>   -sHAVE_ICU=1 -sICU_PATH=/usr/local/ \
23:21:12 <springmeyer>   -a install
23:23:11 <myselfhimself> ldd /usr/local/lib/*.so* | grep icu | grep boost gives me nothing
23:23:29 <myselfhimself> ok
23:24:24 <myselfhimself> springmeyer: in order to gain time, maybe I can just remove the .o and .so built files that are regex related and run your bjam command, is that ok ?
23:24:45 <myselfhimself> I don't mind running a full bjam clean, bjam with your options though
23:25:26 <springmeyer> myselfhimself: the -a command to bjam will force rebuilding the regex library
23:25:40 <artem_> springmeyer: thinking more about #308 - not sure what is best solution. Ideally, proj4 would return valid area for each supported projection. It can be polygon (convex hull?) not just a rectangle, it gets tricky
23:25:41 <springmeyer> and should install over the top of previously installed regex lib just fine
23:25:41 <nikq> Ticket #308: Doesn't display feature if another (possibly invalid) feature is present, http://trac.mapnik.org/ticket/308
23:26:27 *** willwhite has quit ("Leaving")
23:26:37 <springmeyer> artem_: right, but proj4 does not know bounds for projections of course
23:26:57 <artem_> how qgis deals with this?
23:27:12 <springmeyer> puts points at 0,0 and often crashes
23:27:33 <artem_> right
23:28:06 <springmeyer> mapserver and mapguide are the only that handle degenerate geometries resulting from proj_transform failure
23:29:11 <artem_> do you know the logic ? in mapserver/mapguide ?
23:29:15 * springmeyer wonders about hardcoding valid extents for certain projections (spher merc), or allowing argument to mapnik.render() that specifies them...
23:29:22 <myselfhimself> springmeyer: ok !
23:29:24 <myselfhimself> I do this
23:29:32 <myselfhimself> (that)
23:29:51 <springmeyer> I've bumped into the mapserver logic before, here one sec...
23:30:29 * artem_ thinks he needs to read mapserver/mapguide source :)
23:31:53 <springmeyer> http://trac.osgeo.org/mapserver/browser/trunk/mapserver/mapproject.c#L170
23:32:06 <artem_> cool, tnx
23:40:31 <myselfhimself> Ldp__: springmeyer : ok !!! after the compile command and an ldconfig, importing mapnik inside python works !!!
23:40:34 <myselfhimself> thanks very much !!!
23:40:45 <springmeyer> yahoo!
23:41:12 <myselfhimself> I'll move on to osm-mapnik tile rendering now...
23:41:19 <Ldp__> uh-oh
23:41:34 <myselfhimself> hey do you know if mapnik can render tiles out of just an .osm file ?
23:41:35 <artem_> springmeyer: looks over complicated
23:42:03 <myselfhimself> the current setup openstreetmap setup makes mapnik outof a postGIS database... which is a bit complicated to setup
23:42:20 <springmeyer> artem_: certainly. its kinda like geometry specify wrappers around proj meltdowns
23:42:24 <Ldp__> myselfhimself: yes, with the OSM plugin. You'll have to write your own style for that, though
23:42:35 <myselfhimself> ok thanks
23:42:50 <artem_> myselfhimself: yes and no, there is osm.input plug-in which can read  and render *.osm files
23:43:12 <myselfhimself> ok
23:43:15 <springmeyer> artem_: maybe some middle ground?
23:43:58 <artem_> possibly
23:46:57 <myselfhimself> artem_: I'm reading in some mailing list that you wrote the pgsql2sqlite tool ; is the pgsql2sqlite way faster (if I have an OSM rails port pgsql db filled with osm data) than the osm plugin method ?
23:47:51 <myselfhimself> I want to do OSM Rails port's pgsql => some steps => mapnik rendering of tiles
23:49:47 <myselfhimself> apparently as "some steps", there could be : default:pgsql=>osmosis=>.osm dump=>postGIS=>mapnik ; pgsql=>osmosis =>.osm dump=>mapnik osm plugin; and thus with your tool ... pgsql=>pgsql2sqlite=>mapnik
23:49:55 <springmeyer> myselfhimself: sorry to distract, but I thought I'd let you know a favor you could go...
23:50:01 <artem_> myselfhimself: I'm not familiar with OSM Rails port ? but you can use sqlite plugin to render OSM data, sure
23:50:17 <myselfhimself> ok
23:50:37 <springmeyer> errors you ran info and found solutions to can go here: http://trac.mapnik.org/wiki/InstallationTroubleshooting
23:50:40 <springmeyer> indexed by google and others will find answers quicker
23:50:48 <springmeyer> http://trac.mapnik.org/register
23:53:01 <myselfhimself> springmeyer: ok http://trac.mapnik.org/wiki/InstallationTroubleshooting#Boostundefinedsymbols needs to be refined
23:53:23 <myselfhimself> at least I could tell that the very error I had needed boost to be rebuilt with the compile command you gave
23:53:34 <myselfhimself> springmeyer: ok to register and edit that page
23:53:45 <springmeyer> yes!
23:53:48 <myselfhimself> I owe this goodness to your project : )
23:53:55 <springmeyer> myselfhimself: edit that one OR create a new one
23:54:04 <myselfhimself> yes ok
23:54:22 <springmeyer> shoot for putting text in that you might have typed into google
23:54:29 <springmeyer> thx
23:54:34 <myselfhimself> as to the existing error at #Boostundefinedsymbols ; there's no tip as to what bjam command to run to correct this
23:54:56 <springmeyer> good point
23:55:11 <myselfhimself> ok for the google check test
23:56:36 <myselfhimself> actually no sorry
23:56:45 <myselfhimself> I'm not native and using a dic didn't help
23:56:54 <myselfhimself> what do you mean by shoot for putting text... ?
23:57:14 <myselfhimself> like I take some errors I've had and paste them in google to see if I land on the wiki page ?