Magic Numbers Bad

I’ve been trying to make some maps of my local area using OpenStreetMap data. I got Osmarender to render the OSM data to SVG, and then tried to use the SVG editor Inkscape‘s command-line mode to render that to a PNG. However, I kept getting an error:

** (inkscape:1085): WARNING **: 108374760 bytes requested for pixel buffer, I won’t try to allocate that.

I Googled the error message, and found the code which throws the error online. Here it is:

if (size > 100000000) { // Don't even try to allocate more than 100Mb (5000x5000 RGBA
// pixels). It'll just bog the system down even if successful. FIXME:
// Can anyone suggest something better than the magic number?
g_warning ("%lu bytes requested for pixel buffer, I won't try to allocate that.", (long unsigned) size);

Er, a command-line option?

6 thoughts on “Magic Numbers Bad

  1. I always hate that idea too, say the author of the application doesn’t update the software for a while – the 100MB issue will not be a issue forever – with more powerful computers being inevitable – yet so much software like this posing illogical restrictions – its like the Y2K shortsightedness all over again.

    p.s. Its cool to see a science/technology guy not afraid to openly reveal what he believes. I really enjoyed reading your ‘Why “Hacking for Christ”?’ post, especially – “I see it simply as sensible code reuse”

  2. mmm, OpenStreetMap is so much fun, especially when you can correct the map of your area. I’m glad I don’t have a gps device, or I probably would be addicted. Have you gotten into the mapping yet?

    The obvious technical response to the code is that it should subdivide the rendering into smaller chunks, and stitch them back together later. In fact, the stitching is really easy if you divide the area not with a grid, but into horizontal slices, since you have to write the rows of image data into the image file in the same order that they exist in your buffer. Just figure out how many rows will fit in the buffer, partition the vector data by the same amount and just render each partition in turn, writing the buffer to the file and recreating it after each one.

  3. In the end I recompiled it from the source package and changed the number to 1Gb. But it was dog slow, although it did complete eventually. Now I just need an image viewer that can open a 1.3GB file; the GIMP, again, is very slow although it does manage it eventually.


  4. stelt: it can, but (at least in Firefox 2 on Linux) it’s both ugly and slow. Also, I want a nice high-res map for printing; Firefox scales the SVG to fit the window.

Leave a Reply

Your email address will not be published. Required fields are marked *