I was able to catch the output from the Debug build for the problem tile. It
hangs in the middle of a layer rendering. Here's the last lines from the
log:
start layer processing : rails_air
datasource = 0x1997f60
borrow 0x18d56e0
return 0x18d56e0
borrow 0x18d56e0
return 0x18d56e0
borrow 0x18d56e
This is great, thanks Steve!
I've got just a few comments mostly having to do with in-mapnik vs.
not-in-mapnik scope. Going down the list,
1) layer tag: I usually solve this issue in pgsql queries, which I've been
happy with. I think that the layer tag should influence the order in which
geome
Okay, all services are back up, so we're again committing directly to svn:
http://trac.mapnik.org/timeline
- Dane
On Sep 25, 2010, at 10:38 AM, Dane Springmeyer wrote:
> With all the action on trac/svn yesterday on the first day of the sprint we
> filled up the disk on the mapnik.org machine
Dane Springmeyer wrote:
>
> So, to debug I would run:
> ldd /path/to/tirex.so (to see which libmapnik tirex is linked to)
>
> ldd /path/to/libmapnik.so (to check whether you see libagg_pic linking)
>
> If nothing jumps out please post back the output of the 'ldd' commands
> above so I can pick
Hi All,
Steve's great slides which he presented to us yesterday in London to inspire
coding plans are now both available...
on slideshare:
http://www.slideshare.net/steve8/mapnik-code-sprint-what-id-like-to-do-with-mapnik
and as a PDF (with notes) here:
http://dbsgeo.com/mapnik/ms01/chilton_c
With all the action on trac/svn yesterday on the first day of the sprint we
filled up the disk on the mapnik.org machine :).
We don't have a fix currently, so mapnik.org and trac.mapnik.org are down.
While svn.mapnik.org is up this is *read only*, so we've quickly imported
latest trunk into git
6 matches
Mail list logo
