00:36:03 <springmeyer> cmarqu: just noticed your question about GeoTiffs. it depends first on whether you are reading them with the native tiff reader or gdal
00:36:15 <springmeyer> then whether they are stipped or tiled tiffs
00:36:48 <cmarqu> springmeyer: gdal - because that's what I read
00:36:55 <cmarqu> in an example
00:37:01 <springmeyer> I think that the native tiff should be able to read just the portion with an extent
00:37:11 <springmeyer> but the gdal reader will suck the whole thing into memory
00:37:45 <springmeyer> so with the gdal reader you must break the tiff up into lots 'o little ones
00:38:35 <cmarqu> But it will not hold all of them in memory?
00:38:52 <cmarqu> I'm basivcally following the procedure in http://wiki.openstreetmap.org/wiki/HikingBikingMaps#Hill_Shading
00:39:03 <springmeyer> oh, i see. I'm not sure
00:39:15 <springmeyer> #54 is what is was thinking of
00:39:16 <nikq> Ticket #54: Support for overviews in gdal input plug-in, http://trac.mapnik.org/ticket/54
00:40:44 <cmarqu> Ah, I read some mails about that on one of the mailing lists
00:42:18 <cmarqu> Well, I used several tiffs for now, and it works quite will
00:42:20 <cmarqu> well
00:43:29 <cmarqu> I was a bit surprised that I cannot use them on one layer but specify several <Datasource>
00:43:41 <cmarqu> s/but/and/
00:43:49 <nikq> Mapnik Trac: Ticket #54 (Support for overviews in gdal input plug-in) updated | http://trac.mapnik.org/ticket/54#comment:3
00:44:49 <nikq> Mapnik Trac: gdal_overviews.patch.txt attached to Ticket #54 | http://trac.mapnik.org/attachment/ticket/54/gdal_overviews.patch.txt
00:45:40 <nikq> Mapnik Trac: Ticket #54 (Support for overviews in gdal input plug-in) updated | http://trac.mapnik.org/ticket/54#comment:3
00:46:01 <nikq> Mapnik Trac: gdal_overviews.patch attached to Ticket #54 | http://trac.mapnik.org/attachment/ticket/54/gdal_overviews.patch
00:46:42 <springmeyer> cmarqu: file a ticket for that :)
00:48:34 <nikq> Mapnik Trac: Ticket #54 (Support for overviews in gdal input plug-in) updated | http://trac.mapnik.org/ticket/54#comment:4
00:48:49 <cmarqu> springmeyer: Ok :)
00:51:56 <springmeyer> A layer can only have one datasource currently, so I'm not sure how that would work
00:53:33 <springmeyer> it would be easy within the xml parsing to register a new layer for every datasource listed within a single <Layer>'s <Datasource> parameter and then associate the same <RasterSymbolizer> with each
00:54:01 <springmeyer> but that would be only a convience and probably not worth it.
00:54:12 <cmarqu> It's no big deal, it just "felt" liek it would work
00:54:33 <springmeyer> so I figure some sort of smart <TileSet> would be cool
00:54:42 <springmeyer> ya :)
00:55:25 <springmeyer> or maybe the <DataSource> could be a some kind of tileindex that pointed at each raster layer
00:56:55 * springmeyer notes: http://mapserver.org/optimization/tileindex.html#tileindex
01:08:11 *** CIA-22 has quit ("brb")
01:13:20 *** CIA-22 (n=CIA@208.69.182.149) has joined #mapnik
02:08:42 *** D3f0 has quit ("Konversation terminated!")
02:24:06 <nikq> Mapnik Trac: Changeset [824]: Update comments templates | http://trac.mapnik.org/changeset/824
02:25:37 <nikq> Mapnik Trac: Changeset [825]: mapnik.org: Add python akismet support and setup base setting file with  ... | http://trac.mapnik.org/changeset/825
02:33:37 *** D3f0 (n=defo@190.176.206.57) has joined #mapnik
02:34:05 <nikq> Mapnik Trac: Changeset [826]: mapnik.org: Add django signals on news model for moderating comments | http://trac.mapnik.org/changeset/826
02:36:15 <CIA-22> mapnik: dane * r824 /www/mapnik.org/templates/ (comments/preview.html comments/form.html notify_comment.txt): Update comments templates
02:36:15 <CIA-22> mapnik: dane * r825 /www/mapnik.org/ (settings.py news/akismet.py): mapnik.org: Add python akismet support and setup base setting file with email support and ability to import local settings
02:36:16 <CIA-22> mapnik: dane * r826 /www/mapnik.org/news/models.py: mapnik.org: Add django signals on news model for moderating comments
02:47:56 <nikq> Mapnik Trac: Changeset [827]: mapnik.org: Missing import | http://trac.mapnik.org/changeset/827
02:55:50 *** springmeyer has quit ()
03:02:47 <CIA-22> mapnik: dane * r827 /www/mapnik.org/news/models.py: mapnik.org: Missing import
03:52:00 *** springmeyer (n=dane@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik
07:28:55 *** xcacou (n=aga@68.11.86-79.rev.gaoland.net) has joined #mapnik
07:45:15 *** springmeyer has quit ()
08:07:02 *** D3f0 has quit (Read error: 104 (Connection reset by peer))
10:26:01 *** ser has quit (Remote closed the connection)
10:31:11 *** ser (n=ser@82.208.9.201) has joined #mapnik
13:19:24 *** xcacou_ (n=aga@79.86.21.95) has joined #mapnik
13:20:21 *** xcacou has quit (Read error: 110 (Connection timed out))
13:55:21 *** springmeyer (n=dane@c-24-19-50-92.hsd1.wa.comcast.net) has joined #mapnik
14:25:06 <nikq> Mapnik Trac: Changeset [828]:  + cast to unsigned int to avoid compiler warnings | http://trac.mapnik.org/changeset/828
14:42:15 <CIA-22> mapnik: artem * r828 /trunk/include/mapnik/css_color_parser.hpp: + cast to unsigned int to avoid compiler warnings
15:41:03 <springmeyer> .startrss
15:41:03 <nikq> Okay, I'll re-start rss...
15:41:35 <springmeyer> .w mapnik
15:41:50 <springmeyer> .wik mapnik
15:41:51 <nikq> "This page has been deleted." - http://en.wikipedia.org/wiki/Mapnik
15:44:27 <nikq> Mapnik Trac: Ticket #194 (Mapnik Wikipedia page) created | http://trac.mapnik.org/ticket/194
15:46:49 <nikq> Mapnik Trac: Changeset [829]: mapnik.org: Add updated tracking code | http://trac.mapnik.org/changeset/829
15:47:17 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
15:49:16 <CIA-22> mapnik: dane * r829 /www/mapnik.org/news/ (templatetags/urchin.py models.py): mapnik.org: Add updated tracking code
15:59:12 <nikq> Mapnik Trac: Changeset [830]: + normalize rgb color ranges to 0-255, + clip alpha to 0.0 - 1.0 range | http://trac.mapnik.org/changeset/830
16:02:56 <nikq> Mapnik Trac: Ticket #185 (Need to normalize rgb color ranges to 0-255) closed | http://trac.mapnik.org/ticket/185#comment:2
16:05:08 <nikq> Mapnik Trac: Ticket #185 (Need to normalize rgb color ranges to 0-255) updated | http://trac.mapnik.org/ticket/185#comment:3
16:11:04 <nikq> Mapnik Trac: Ticket #185 (Need to normalize rgb color ranges to 0-255) updated | http://trac.mapnik.org/ticket/185#comment:4
16:17:28 <CIA-22> mapnik: artem * r830 /trunk/include/mapnik/css_color_parser.hpp:
16:17:28 <CIA-22> mapnik: + normalize rgb color ranges to 0-255,
16:17:28 <CIA-22> mapnik: + clip alpha to 0.0 - 1.0 range
16:37:42 *** Ruffiano (n=ruffiano@static-70-21-119-183.res.east.verizon.net) has joined #mapnik
16:39:31 <Ruffiano> Just updated OSM2PSQL, and re-built the OSM database, but I am getting a weird water poly error on a centOS machine that I am not getting on an Unbutu one
16:39:57 <Ruffiano> same style sheets, same osm2psql version, everything seems to be the same but I amnot sure whats causing it
16:40:07 <Ruffiano> http://www.sandwichmafia.com/Pictures/maperror.jpg  is one of the more apparent areas I am dealing with
17:08:17 *** D3f0 (n=defo@190.176.206.57) has joined #mapnik
17:19:58 *** xcacou_ has quit (Read error: 113 (No route to host))
17:24:09 *** artem has quit ()
17:25:23 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
17:25:38 <artem> Ruffiano: this can be related to using -s --slim mode while importing
18:09:41 *** artem has quit ()
20:08:54 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
20:22:06 <Ruffiano> Artem: when you mentioned the --slim mode earlier in response to my crazy water, I believe I did NOT use slim to import it, should I?
20:23:39 <artem> Ruffiano: I'm not 100% sure, but I recall that only 'slim' supports relations properly.
20:24:56 <Ruffiano> ok, I am going to be re-importing hopefully the proper area with a bounding box, and I'll use slim
20:25:50 *** __d3f0__ (n=defo@190.176.206.57) has joined #mapnik
20:36:03 *** D3f0 has quit (Connection timed out)
20:51:56 *** Ruffiano has parted #mapnik ()
21:01:30 *** JeLuF (i=jf@mormo.org) has joined #mapnik
21:49:33 *** migurski (n=migurski@h-68-165-1-62.snvacaid.covad.net) has joined #mapnik
22:03:15 <springmeyer> I owe a beer to whoever can tell me what is causing the bbox shift in this image :) http://dbsgeo.com/tests_output/projected/na_albers_via_sr.org.png
22:03:57 <springmeyer> that whole folder of stuff is the tests output from nik2img, ie $ python setup.py test
22:04:01 <springmeyer> http://dbsgeo.com/tests_output/
22:05:55 <springmeyer> the code in question from the doctests is this: http://dpaste.de/d7kN/
22:07:07 <springmeyer> this is not causing any problems of importance, and it may be just a funky esri projection at play, but I'm curious nonetheless in case anyone might have a clue...
22:17:28 <cmarqu> jburgess: Any idea why the that "importance=0" update spell you gave me some days ago wouldn't work again on new data brought in via osm2pgsql -a?
22:18:54 <jburgess> nope, it should work. You'll need to run it again though to apply the same change to the new data
22:19:44 <cmarqu> Yes, I did that. It also reported some updates, alas, I still don't see the peaks rendered. Maybe it's a different problem.
22:19:55 <jburgess> and remember you may need to do it on multiple tables (point, line, polygon)
22:20:05 <cmarqu> Oh!
22:20:49 <cmarqu> Forgot that indeed.
22:23:35 <nikq> Mapnik Trac: SCons_usabilty_improvements2.patch attached to Ticket #186 | http://trac.mapnik.org/attachment/ticket/186/SCons_usabilty_improvements2.patch
22:32:38 <nikq> Mapnik Trac: Ticket #186 (Scons usability improvements) updated | http://trac.mapnik.org/ticket/186#comment:3
22:34:32 <artem> springmeyer: #186 patch sounds great, I'll give it go
22:34:33 <nikq> Ticket #186: Scons usability improvements, http://trac.mapnik.org/ticket/186
22:35:02 <springmeyer> artem: awesome, thanks
22:35:32 <artem> jburgess: am I right to think that -slim mode required to process some relations?
22:36:01 <nikq> Mapnik Trac: Ticket #186 (Scons usability improvements) updated | http://trac.mapnik.org/ticket/186#comment:4
22:36:03 <jburgess> currently yes, if you want multipolygons to work reliably
22:36:17 <artem> ok, thanks
22:37:12 <nikq> Mapnik Trac: SConstruct attached to Ticket #186 | http://trac.mapnik.org/attachment/ticket/186/SConstruct
22:37:27 <jburgess> I've had one or two complaints that the --slim mode doesn't work for some people when they try to load multiple datasets into one DB (e.g. two adjoining extracts)
22:37:46 * cmarqu looks up
22:38:12 <jburgess> It is due to some elements being present in both imports which breaks a unique key constraint
22:38:51 <cmarqu> FWIW, I also had this with a relation in the meantime.
22:39:13 <artem> cool, good to know this. I guess -slim slows thing down quite a bit ??
22:39:27 <jburgess> yes, approx half the speed
22:40:06 *** weizhuo (n=chatzill@nat/yahoo/x-38d4d841775e7d16) has joined #mapnik
22:40:20 <artem> how this translates into time? full planet import on good machine = ??
22:40:21 <jburgess> At some point I intend to 'fix' the non-slim mode but the unfortunate side-effect will be to increase memory usage, so not everyone will be happy with that either
22:40:51 <jburgess> The OSM tile server imports the full planet in approx 6 hours
22:41:10 <artem> ok, not bad
22:41:20 <springmeyer> All: regarding #186, even if you don't have the ability to rebuild with svn and test that patch right now...
22:41:21 <nikq> Ticket #186: Scons usability improvements, http://trac.mapnik.org/ticket/186
22:41:42 <springmeyer> I would be very interested if there are any challenges, quirks, issues with the mapnik build process you have had that I have not yet addressed
22:41:47 <jburgess> I'm planning to revisit the diff import some time too. Several people seem to have successful setups importing daily/hourly or even minute diffs
22:42:20 <artem> yep, that would be super cool !
22:42:38 * artem downloading patch 
22:42:57 * springmeyer its a big one :)
22:43:28 <jburgess> crschmidt has the minute diffs running on one of his servers with a special Javascript hack you can overlay the OSM tiles with up-to-the-minute ones from his server
22:43:56 <artem> yeah, I saw that. It didn't work in Safari :D
22:44:17 <springmeyer> doh. :)
22:47:21 * artem is getting "All Required dependencies found!" 
22:47:21 <springmeyer> artem: two big picture things about that patch....
22:47:27 <springmeyer> yes!
22:47:36 <artem> ??
22:48:16 <springmeyer> 1) pulling from os.environ is still default in that patch but I have noticed that SCons docs make a note that it should be used sparingly (one way to say it)
22:48:34 <artem> ok
22:48:46 <springmeyer> so I wonder, after more folks can test whether it will make sense to make that not default...
22:49:50 <springmeyer> and 2) the big idea is that you should be able to configure your build and then run 'python scons/scons.py install' without specifying any options...
22:50:08 <springmeyer> unless you want to on-the-fly reconfigure your build when installing
22:50:49 * artem likes idea #2 
22:50:50 <nikq> Ticket #2: GetFeatureInfo() Support, http://trac.mapnik.org/ticket/2
22:51:12 <springmeyer> good! I figure it is more intuitive that way
22:51:25 <springmeyer> as long as this patch works perfectly :)
22:51:30 <artem> I guess it makes sense not to pull everything from ENV
22:51:36 <artem> by default
22:52:24 <springmeyer> okay. well for testing that use USE_USER_ENV=False for now....
22:52:38 <artem> ok, cool
22:52:53 <springmeyer> (gee that hard to write, maybe it should be ENV=False :) )
22:53:53 * artem using bash script to avoid typing scons options all the time
22:54:01 <springmeyer> its pretty cool what with jburgess's postgres/gdal changes to the path options mapnik now builds without needing any options and with USE_USER_ENV=False
22:54:04 <springmeyer> lol
22:54:09 <springmeyer> I do as well...
22:54:51 <artem> done (just re-compiled everything with your patch)
22:55:11 <springmeyer> artem: or just put your options in 'config.py' as python syntax: KEY = 'value'
22:55:20 <springmeyer> er VARIABLE = 'value'
22:55:39 <artem> sure, i will
22:56:25 <artem> ok, I'll apply this patch - worksforme
22:57:15 <springmeyer> wow. good stuff
22:58:56 <nikq> Mapnik Trac: Changeset [831]: +  SCons_usabilty_improvements2.patch (springmeyer)    (see #186 ticket  ... | http://trac.mapnik.org/changeset/831
22:59:46 <springmeyer> artem: am I missing something obvious or is this really lacking? #190
22:59:56 <nikq> IOError: [Errno socket error] timed out (file "/usr/lib/python2.5/socket.py", line 372, in readline)
23:00:11 <springmeyer> # 190
23:00:48 <springmeyer> huh, trac just went down seems like...
23:01:19 <artem> hmm.. must me my commit :)
23:01:54 <springmeyer> :)
23:02:11 * springmeyer happened to be logged in, restarts apache
23:02:25 <springmeyer> nikq: #190
23:02:26 <nikq> Ticket #190: Make symbolizers available/editable via a Style object in python bindings, http://trac.mapnik.org/ticket/190
23:03:40 <springmeyer> ie. if you grab a style via map.find_style('named style')
23:04:04 <springmeyer> and then grab the `symbols` within the list of rules...
23:04:19 <artem> yep, it's not very straight forward .. symbolizers are variants
23:04:30 <springmeyer> slicing the symbols list returns a symbol object rather than...
23:04:33 <springmeyer> right, okay
23:04:41 <artem> it needs some glue code
23:04:54 * springmeyer was looking at boost variants the other day with a friend...
23:04:56 <CIA-22> mapnik: artem * r831 /trunk/ (bindings/python/SConscript SConstruct):
23:04:56 <CIA-22> mapnik: + SCons_usabilty_improvements2.patch (springmeyer)
23:04:56 <CIA-22> mapnik:  (see #186 ticket for details)
23:04:57 <nikq> Ticket #186: Scons usability improvements, http://trac.mapnik.org/ticket/186
23:05:50 <springmeyer> cool, sounds good. I figured and was looking all for a place to start but didn't get any farther than seeing the boost variant GET method looks related
23:06:38 <springmeyer> this came up because cmarqu and I were chatting about a way to globally 'tweak' styles
23:07:25 <springmeyer> so that you could say, find all line-widths in all Polygon and LineSymbolizers and multiply the values by some amount
23:07:58 <artem> yes, good idea
23:08:09 <springmeyer> it would of course be easy to do in xml but much more useful to do internally
23:08:30 <artem> the best way to query boost::variant is to use visitot pattern
23:08:37 <artem> get methods are not 'safe'
23:08:53 <nikq> Mapnik Trac: Ticket #190 (Make symbolizers available/editable via a Style object in python bindings) updated | http://trac.mapnik.org/ticket/190#comment:2
23:09:11 <springmeyer> okay.
23:09:25 <artem> wow, real time trac-ing
23:10:05 <artem> i meant to say 'visitor'
23:10:09 <springmeyer> well, I didn't set it up that way its just an accident of serving text files :)
23:10:29 <springmeyer> yes, I saw the 'vistor' function in a few places...
23:11:01 <springmeyer> I guess i figured 'get' was the missing magic because all I could see was magic to begin with! :)
23:12:54 <artem> it might be a good idea to consider implementing all symbolizers as 'property maps'
23:13:18 <artem> name=value containers or something similar
23:13:35 <springmeyer> ewwww cool, sounds pythonic!
23:15:05 <artem> keep internal impl as it is but provide user-friendly way to set/get properties .. needs some thinking
23:15:35 <springmeyer> okay. thanks for the thoughts
23:15:42 <springmeyer> I figure improvements like this to the python bindings will be key to migurski being able to write a cascadenik->direct-to->mapnik
23:16:18 <springmeyer> so maybe when he starts playing around with that we could collect ideas of the desired interface from python...
23:16:27 <artem> sounds great
23:16:39 <springmeyer> thx
23:18:02 <migurski> I'm lurking, but that's a good idea
23:19:02 <springmeyer> cool
23:19:18 <migurski> overall would be super nice for the entire rules/styles/layers/etc. tree in the python bindings to be plain old lists and dictionaries
23:19:35 <migurski> I know I've tried to treat it that way in the past and found that e.g. append() didn't always work - little stuff
23:20:02 <springmeyer> ya, dictionaries of params would be awesome
23:20:23 <springmeyer> migurski: if you can document where the append() didn't work that might be something I could look into
23:20:31 <migurski> okay, will do
23:20:36 <springmeyer> thx
23:20:58 <springmeyer> artem: a few more questions if you are not too close to sleep (feel free to answer later!)...
23:21:15 <springmeyer> 1) is #168 sane or a bad idea?
23:21:17 <nikq> Ticket #168: Ability to register fonts during load_map(), http://trac.mapnik.org/ticket/168
23:21:37 <springmeyer> 2) any reason not to apply #179 right now?
23:21:42 <nikq> Ticket #179: mapnik.Map scale() should be a property in python, http://trac.mapnik.org/ticket/179
23:22:02 <springmeyer> 3) is #163 a pony or is it possible?
23:22:03 <nikq> Ticket #163: Support for Unicode Strings as arguments, http://trac.mapnik.org/ticket/163
23:23:19 <migurski> 163 seems like py3k must-have
23:24:01 <migurski> okay re-lurking now =)
23:24:06 * migurski re-lurks
23:24:15 <springmeyer> see ya :)
23:25:11 <nikq> Mapnik Trac: Ticket #169 (Switch to libxml2 as default parser) closed | http://trac.mapnik.org/ticket/169#comment:2
23:26:07 *** artem has quit ()
23:27:32 *** artem (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
23:28:16 <artem> I'm back
23:28:29 <artem> trac seems to struggling atm
23:29:06 <springmeyer> yes, I restarted again and that fixed it.
23:29:24 <springmeyer> it seems that my mod_wsgi install must be having trouble with concurrent requests (I worry)
23:29:57 <nikq> Mapnik Trac: Ticket #142 (ICU_INCLUDE and ICU_LIBS search path is not working) closed | http://trac.mapnik.org/ticket/142#comment:4
23:31:49 <nikq> Mapnik Trac: Ticket #186 (Scons usability improvements) updated | http://trac.mapnik.org/ticket/186#comment:5
23:37:30 <artem> re: #179 - my thinking is that it is a method because it calculates scale. It can be read-only property
23:37:31 <nikq> Ticket #179: mapnik.Map scale() should be a property in python, http://trac.mapnik.org/ticket/179
23:38:22 <springmeyer> ah, good point
23:39:46 <springmeyer> let's leave it be then...
23:42:01 <springmeyer> geez trac is hurting. sorry...
23:42:53 <nikq> Mapnik Trac: Ticket #179 (mapnik.Map scale() should be a property in python) closed | http://trac.mapnik.org/ticket/179#comment:1
23:46:20 *** artem_ (n=artem@i-83-67-142-225.freedom2surf.net) has joined #mapnik
23:47:56 *** __d3f0__ has quit ("Konversation terminated!")
23:50:08 <artem_> #168 - I like the idea, I'll need to try your patches
23:50:08 <nikq> Ticket #168: Ability to register fonts during load_map(), http://trac.mapnik.org/ticket/168
23:51:36 <artem_> #163 - yes, possible . definitely 1.0.0 :)
23:51:36 <nikq> Ticket #163: Support for Unicode Strings as arguments, http://trac.mapnik.org/ticket/163
23:52:16 <springmeyer> okay, cool.
23:52:36 <springmeyer> as far as #168 feel free to comment and i can work to improve
23:52:36 <nikq> Ticket #168: Ability to register fonts during load_map(), http://trac.mapnik.org/ticket/168
23:53:06 <springmeyer> #168 kind of bring up the same issue as #190 for me...
23:53:06 <nikq> Ticket #190: Make symbolizers available/editable via a Style object in python bindings, http://trac.mapnik.org/ticket/190
23:53:28 <artem_> milestone 0.6.0
23:53:29 <nikq> 35 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, Main library gets linked against unnecessary libraries, Crashing with TextSymboli...
23:53:30 <nikq> http://trac.mapnik.org/query?status=new&status=assigned&status=reopened&milestone=0.6.0&order=priority
23:53:31 <nikq> Milestone Roadmap: http://trac.mapnik.org/milestone/0.6.0
23:53:42 <springmeyer> that being what is the overall vision for what XML or Python *should* be able to do and what they should not be able to do.....
23:55:01 * jbronn begins pulling the latest revs to check out the scons changes
23:55:15 <nikq> Mapnik Trac: MapnikInterface created | http://trac.mapnik.org/wiki/MapnikInterface?version=1
23:56:15 <springmeyer> hey jbronn: I send my best wishes for the care of your brain :)
23:57:13 <jbronn> thanks, it needs it.  i want to think about mapnik now so i don't have to about con law, evidence and real property
23:58:13 <springmeyer> nice