[OSM-talk] Export too big
tom at compton.nu
Thu Jan 22 10:49:24 GMT 2009
Raymond Bruman wrote:
> On Jan 22, 2009, at 2:05 AM, Tom Hughes wrote:
>> All I need to know is what options you are selecting on the export tab
>> and exactly what the error message says (though I can probably find
>> that myself given the options).
> Yes, because I may be in the wrong place choosing the wrong options
> in the first place, and you could steer me correctly.
>> The critical point that I don't think you've mentioned is which layer
>> you are trying to export (mapnik or osmarender/tiles at home) and what
>> format you are trying to export it in.
> I chose mapnik because somebody at the meeting mentioned
> it, but I don't know enough about either one. I am eager
> to learn more by reading about both layers, somewhere.
Mapnik is good, and I think I now know where the error came from, but
you shouldn't have been able to get it as the web frontend is supposed
to limit you.
Basically for that area the web site limits you to a scale of 1:5750 and
the backend is happy to produce that. Did you take the URL that it uses
and change the scale to try and get a larger map or something? That
would let to you getting a "Map too large" error when the backend
validates the requested scale.
To get 36 inches at 300dpi you need a scale of about 1:1125 by my
calculations - that gives you a 9575 by 10789 pixel image, which is
about 32 inches by 36 inches at 300dpi.
> I chose JPEG because the counter girl at the service
> bureau only knew about PDF, JPEG, and PowerPoint files.
JPEG is a bad choice as it is lossy - probably PDF is the best choice
from that set of options as it is scalable. The only thing is that the
PDF files are pretty complicated so it's possible whatever equipment
they're using might not like it.
>> I'm also not planning to change any limits, which seems to be what
>> you're suggesting, just to understand why you are getting an error
>> that I can't see anywhere in the source. The limits are there for good
>> reasons related to both server resources and ensuring that we don't
>> produce files that are unmanageable.
> I'm in complete sympathy with the reasons.
> Like someone who buys a drill but really just
> wants some holes, I am interested in a map, not
> files per se. If I have to stitch together a set of
> files, or even (shudder) physical images, so be
> it, but I will be surprised.
When it comes to bitmap images (JPEG, PNG, etc) the main issue is server
resource - at a scale of 1:1125 the render process is about 400Mb in
size because that is the uncompressed size of the resulting bitmap. The
resulting image is about 5Mb for JPEG or 11Mb for PNG but it renders on
the client quite happily so long as you have 400Mb or so spare for
whatever program you're viewing it in.
For PDF images the issue is more one of what clients can render - at a
scale of 1:1125 that area produces a 2.3Mb PDF file that takes a good
few seconds to render on a quad core machine with 8Gb of memory...
It's better than it used to be I think though, so my PDF viewer may have
improved. It might be we could lift the limits on PDF files at least to
something a bit bigger.
Anyway, as a result of my experimenting I do have 1:1125 versions here
in three formats (PDF, PNG and JPEG) that I could let you have if you
Tom Hughes (tom at compton.nu)
More information about the talk