I'am trying to export mbtile file from TileMill to use it in my map server. But file is too huge, 17th level will cost 100+GB only for my country. However, i found free mbtile from openmaptiles.org with only 1GB size for the same are.
My question is: How openmaptiles.org reduced 100GB mbtile to 1GB?
I don't want to use 1gb file because they have watermarks all over the map
I found out that openmaptiles.org provides only 14 zoom levels and can be over zoomed till 18. Overall, 14 layers are >1gb size
Related
I am using windows cli version libvips. I want to generate map tiles for leaflet from image 8000px x 6000px. This image is old map of my town, and I want to display it on my website, but I am stuck on generating tiles.
How to tell libvips to generate tiles from zoom level 10 to 15. With command
dzsave input.jpg outputdir --layout google
I receive tiles from zoom level 0 to 5.
And second question.
How to set bounds of my map? Generated tiles from above command cover the whole world.
The libvips CLI lets you run any save operation (like jpegsave, tiffsave or dzsave) as part of the write step of a command. You select the saver with the filename suffix and you can pass any parameters in square brackets at the end of the filename (be careful not to use any spaces).
So these two commands do the same thing:
vips jpegsave x.jpg y.jpg --Q 90
vips copy x.jpg x.jpg[Q=90]
The copy command will run jpegsave for you (it sees the .jpg suffix) and set Q to 90.
You can select dzsave with the .dz suffix. If your image is 50,000 x 50,000 pixels, you can save just the centre 50% with:
vips crop my-huge-map.jpg x.dz[layout=google] 12500 12500 25000 25000
I'm not sure what you mean by "layers 10 to 15". Do you only want the low-res layers? Just do a shrink by eg. 16 before running dzsave.
I added 33 mb worth of sprite assets (they are large character illustrations), so I would expect the data folder to increase proportionally. However, the size actually increases by 2 GB (6000% increase!) increasing total data size by over 500% too.
Doesn't make any sense to me. Is there a mistake with my import options? I use mip maps, bilinear/trilinear filters. Truecolor/ vs compressed doesn't change anything.
Additional info: It's like 10 files with 5-8 large sprites each. Another weird thing is that when it's compressed to a zip file the size collapses to 142mb (from like 2.3 GB). Which is weird because that's too big of a difference.
It's also very slow to start.
I believe this is related to how unity handles image compression. The assets live in your project in compressed (jpg/png) form, but they get recompressed (or not) to a form thats fastest to decode on the target platform. Try playing with the compession settings with the asset import settings (available if you highlight your asset in the project window)
There are a few reasons why file sizes can get so big.
As #zambari said, PNG/JPEG are compressed forms, which compress much better than what unity will. Due to that, you have to be careful with your file sizes, since they will be much bigger in-game.
Another issue I had was that my files weren't sized properly. The compression method that I was trying to utilize requires file sizes divisible by 4 (DTX5).
Another big issue was I had large images that I did not need. I used "generate mip-maps" + trilinear filtering, and that once again doubled the file sizes. The best thing you can do is just use image sizes that reflect their use. Relying on Unity to do that for you by using max image size does not guarantee good quality (in fact it looked terrible). This was all in Unity 5
So far I load 3 Geojson files on my Mapbox map.
When I try to load a forth one it does not work.
Is 3 the limit for thos kind of files?
Thanks
Is it any fourth one or have you possibly hit your limit in the number of features?
I have read a lot about BMP file format structure but I still cannot get what is the real meaning of the fields "biXPelsPermeter" and "biYPelsPermeter". I mean in practical way, how is it used or how it can be utilized. Any example or experience? Thanks a lot
biXPelsPermeter
Specifies the horizontal print resolution, in pixels per meter, of the target device for the bitmap.
biYPelsPermeter
Specifies the vertical print resolution.
Its not very important. You can leave them on 2835 its not going to ruin the image.
(72 DPI × 39.3701 inches per meter yields 2834.6472)
Think of it this way: The image bits within the BMP structure define the shape of the image using that much data (that much information describes the image), but that information must then be translated to a target device using a measuring system to indicate its applied resolution in practical use.
For example, if the BMP is 10,000 pixels wide, and 4,000 pixels high, that explains how much raw detail exists within the image bits. However, that image information must then be applied to some target. It uses the relationship to the dpi and its target to derive the applied resolution.
If it were printed at 1000 dpi then it's only going to give you an image with 10" x 4" but one with extremely high detail to the naked eye (more pixels per square inch). By contrast, if it's printed at only 100 dpi, then you'll get an image that's 100" x 40" with low detail (fewer pixels per square inch), but both of them have the same overall number of bits within. You can actually scale an image without scaling any of its internal image data by merely changing the dpi to non-standard values.
Also, using 72 dpi is a throwback to ancient printing techniques (https://en.wikipedia.org/wiki/Twip) which are not really relevant in moving forward (except to maintain compatibility with standards) as modern hardware devices often use other values for their fundamental relationships to image data. For video screens, for example, Macs use 72 dpi as the default. Windows uses 96 dpi. Others are similar. In theory you can set it to whatever you want, but be warned that not all software honors the internal settings and will instead assume a particular size. This can affect the way images are scaled within the app, even though the actual image data within hasn't changed.
I have a bunch of diagrams created using a Java diagramming tool that I wrote - they are mostly black and white diagrams, with the blocks in aqua, and occasional other colours. They are currently being saved as JPG files, and I want to insert them into a book that I am preparing for Print On Demand.
The book is an OpenOffice ODT file, which will later be converted to a PDF.
Currently I use JPG files, but the print facility they use requires 300 DPI, so I modified my diagramming tool to set the xDensity and yDensity to 300, and resUnits to 1, using getAsTree(), and then expand the diagram by a factor of 3 (300/96). IMO the result looks pretty good!
Unfortunately, someone on another forum pointed out that line diagrams are "fuzzed" on JPG files, so suggested that I change over to PNG, or possibly BMP files, both of which ODT files allow to be inserted.
My problem is that BMPs don't seem to have a DPI, and PNGMetadata doesn't seem to support getAsTree(). Can someone point me in the right direction? Thanks.
I don't understand the getAsTree() part, but answering the question that appears in the title, setting dpi for PNG files, you could use the imagemagick convert tool:
convert -density 300 -units pixelsperinch infile.jpg outfile.png
PNG, BMP and dozens of other image formats don't compress your diagrams - compression is probably what your commentor was getting at. JPEGs are great for photos but suck at diagrams.
You might want to look into SVG and other vector formats. Or if your environment allows, exporting 0% compression JPEGs and converting them into another format for lossless reproduction at 300DPI.
Hope that helps!
I decided not to try to do this programmatically. Instead I create the original diagram in PNG, then convert to 300 DPI using Irfanview. Irfanview's batch capability lets me convert to 300 DPI, scale up to compensate, and set to grey scale, all in one operation - and on multiple files at a time. This seems to be the best solution - but thanks to everyone anyway!