I believe this is a known issue with the MapnikRasterizer and we have an existing problem report - PR#54204 - documenting it. Apparently the determining factor is the amount of virtual memory the process can use and so a potential workaround would be to rasterize the image in tiles and mosaic them for output, instead of making one large image directly. I have added this thread to the problem report in case there is any followup.
Regards,
Robyn Rennie
After @RobynAtSafe escalated this at Safe, the team brainstormed a few ideas as workarounds until we can figure out a better long term solution.
We're guessing that you must be using a Group on your MapnikRasterizer to gather features for each tile. And since it is coming from MasterMap, we're guessing there are lots of features and lots of XML-birthed attributes on each one. So we'd recommend putting an AttributeKeeper before the MapnikRasterizer on each input port and keeping only the attributes you reference in the MapNikRasterizer. That will greatly reduce the memory overhead and should free up a bunch. Additionally, we feel this may be a great place to engage the Parallel Processing. If you were using a Group, then each group would get processed in its own process and as such have a much roomier memory situation.
Give those a spin and let us know if it helps.
Thank you both, your assumptions are spot-on Dale so I will try the suggestions and report back!
Thank you both, your assumptions are spot-on Dale so I will try the suggestions and report back!
@bhawk Hope you are well. It's been a while since this topic was created... but thought I'd see about an update. The PR on this that Robyn reported is still open. Did you happen to resolve your issue with Dale's recommendations?
