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/ti...@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 want... Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
