Make the map`s white margins transparent
That was annoying from the same beginning. It can be seen especially when Map auto-load is turned on. Maps are curtaining each other. Ok, they will always do that, but the white margins are making this very unpleasent and chaotic to look at.
These margins are unnecessary. It would be great to make them disappear somehow. Unfortunately, when Im creating the slitedb atlas,
I can only cut off the whole tiles, so the margins are always there. Aren`t there any way to use transparency in the sqlitedb format, or GEMF? I would like to create the atlas with transparent margins, and then let the Locus to respect this transparency and just don`t show it. Or maybe Locus would be able to search/scan for the white margins automatically and just don`t show it?
Here is the link to this issue on forum: http://forum.locusmap.eu/viewtopic.ph...
I like this idea 
Agree that this is unwanted. Some "cutting" white edges in map files should be best from view of performance and also easier for me - no work :). Unfortunately for me, this should be only partial solution because everyone will have to "do something with maps before usage".
May you create and send me some small map for test. Best should be one visible on last image, with very small map part in one tile. I`ll try to do some automatic algorithm for this ...
PS: I have to finally obtain some software for such task to stop asking for testing map everytime ...
Agree that this is unwanted. Some "cutting" white edges in map files should be best from view of performance and also easier for me - no work :). Unfortunately for me, this should be only partial solution because everyone will have to "do something with maps before usage".
May you create and send me some small map for test. Best should be one visible on last image, with very small map part in one tile. I`ll try to do some automatic algorithm for this ...
PS: I have to finally obtain some software for such task to stop asking for testing map everytime ...
Those borders are called "collars" and removing them is harder than it seems. They come in many different shapes and colors. Even the professional GIS tool "GlobalMapper" has problems removing some of them. Pure white and rectangular is really the exception and might only be true in case of maps from Mobac. Even then, as soon as a lossy compression format is used, a white pixel is no longer pure white.
I have my doubts that Locus is the correct place to deal with those collars. It will be like opening a huge can of worms as soon as you start implementing something in this direction.
Those borders are called "collars" and removing them is harder than it seems. They come in many different shapes and colors. Even the professional GIS tool "GlobalMapper" has problems removing some of them. Pure white and rectangular is really the exception and might only be true in case of maps from Mobac. Even then, as soon as a lossy compression format is used, a white pixel is no longer pure white.
I have my doubts that Locus is the correct place to deal with those collars. It will be like opening a huge can of worms as soon as you start implementing something in this direction.
Like I said, I`m always preparing my maps in PNG and I`m making the collars transparent (in GlobalMapper). But then, during the conversion to sqlitedb ( in Mapc2Mapc), the transparent pixels are just transforming into white. So I think there is a problem in SQLitedb format or in the Mapc2Mapc, and then in Locus, which is not taking care of the collars.
Anyway, MY collars are always pure white ( because mapc2mapc is turining them white).
The best idea would be to:
1. make sure if sqlitedb contain transparent pixels
2. talk to the author of Mapc2Mapc (I can do that) to leave transparent pixels ( and not change them into white)
3. make sure that Locus will respect the transparency of the transparent pixels ( it can respect only pure transparent ones ( probably to make less computation then with semi-transparent ones))
or just scan the whiteness or any other solid colour ( if in PNG)
OR give the user a possilibity to manually define the frame for each map . it would be one-time operation which results would be saved permanently. And only the inside-frame map part would be displayed.
Like I said, I`m always preparing my maps in PNG and I`m making the collars transparent (in GlobalMapper). But then, during the conversion to sqlitedb ( in Mapc2Mapc), the transparent pixels are just transforming into white. So I think there is a problem in SQLitedb format or in the Mapc2Mapc, and then in Locus, which is not taking care of the collars.
Anyway, MY collars are always pure white ( because mapc2mapc is turining them white).
The best idea would be to:
1. make sure if sqlitedb contain transparent pixels
2. talk to the author of Mapc2Mapc (I can do that) to leave transparent pixels ( and not change them into white)
3. make sure that Locus will respect the transparency of the transparent pixels ( it can respect only pure transparent ones ( probably to make less computation then with semi-transparent ones))
or just scan the whiteness or any other solid colour ( if in PNG)
OR give the user a possilibity to manually define the frame for each map . it would be one-time operation which results would be saved permanently. And only the inside-frame map part would be displayed.
long time ago...
http://forum.locusmap.eu/viewtopic.ph...
long time ago...
http://forum.locusmap.eu/viewtopic.ph...
Menion`s words: "Hi,
I don`t think that transparency change something here. Tiles are precisely defined areas (256x256) pixels, and I`m loading them one next to other. No overlays aren`t allowed. So even if transparency will be working, there will still be white space below transparent pixels. This can only change if some overlay will be working in Locus (which was already requested here on forum but denied due to memory limitations of android devices ... but I`m not saying it`s not solvable)"
And now the transparency and overlays are supported:)
Menion`s words: "Hi,
I don`t think that transparency change something here. Tiles are precisely defined areas (256x256) pixels, and I`m loading them one next to other. No overlays aren`t allowed. So even if transparency will be working, there will still be white space below transparent pixels. This can only change if some overlay will be working in Locus (which was already requested here on forum but denied due to memory limitations of android devices ... but I`m not saying it`s not solvable)"
And now the transparency and overlays are supported:)
Menion, sorry that it took so long, here it is:
https://dl.dropbox.com/u/4747589/Test...
And I think you should INDEPENDENTLY introduce transparency support. So the power user woulld be able to save the transparency inside the sqlitedb file. Remember that you have very many power-users who know how to make usage of such a professional possibilities. But the mapc2mapc introduced jpegs inside sqlitedb, and these will not have the transparency in them, so in these variants, the white collars should be scanned and identified as white and hidden.
Menion, sorry that it took so long, here it is:
https://dl.dropbox.com/u/4747589/Test...
And I think you should INDEPENDENTLY introduce transparency support. So the power user woulld be able to save the transparency inside the sqlitedb file. Remember that you have very many power-users who know how to make usage of such a professional possibilities. But the mapc2mapc introduced jpegs inside sqlitedb, and these will not have the transparency in them, so in these variants, the white collars should be scanned and identified as white and hidden.
I want to discuss it a little bit ...
1) what is main usage of this? Map layer is first layer that is drown, so even if not transparent, it do not cover anything valuable. Only case is if you use your map as overlays, right?
2. Thanks for map. Seems to be more complicated just from start. Map images you send me are stored in JPG, so white is no usually white. Here is what you may see. First image is tile from your SQLite map. Second image is separated on white and black, where white are transparent (white 255/255/255 RGB color) pixels, black are others. Main part is black because pixels are 253/253/253, so not exactly white ... hard work
EDIT: even more interesting on your map is this image -
seems like program that created this map already draw map tiles on some 253/253/253 colored background? I have partially algorithm in mind how to do this task, but I`m still not sure if it will be useful in the end. No matter that it will consume quite a lot of CPU usage for every image (only once after load of course)
I want to discuss it a little bit ...
1) what is main usage of this? Map layer is first layer that is drown, so even if not transparent, it do not cover anything valuable. Only case is if you use your map as overlays, right?
2. Thanks for map. Seems to be more complicated just from start. Map images you send me are stored in JPG, so white is no usually white. Here is what you may see. First image is tile from your SQLite map. Second image is separated on white and black, where white are transparent (white 255/255/255 RGB color) pixels, black are others. Main part is black because pixels are 253/253/253, so not exactly white ... hard work
EDIT: even more interesting on your map is this image -
seems like program that created this map already draw map tiles on some 253/253/253 colored background? I have partially algorithm in mind how to do this task, but I`m still not sure if it will be useful in the end. No matter that it will consume quite a lot of CPU usage for every image (only once after load of course)
1. Original reason was to turn on "Automatic map loading" to see many maps, next to each other. When there are white collars, this is pointless, because there are white holes between maps. See my picture no.1 .
2. I made it with Mapc2mapc. Yes, I voted for introducing automatic cutting off of the whole-white tiles. And there in and option to scan for the white tiles, and you can set the "white" value
I do belive that you are the right person to make it right. And I know it is also hard to do that, because on some maps you have white colours as a part of the map itself. Remember also that in the future I will try to ask mapc2mapc author to introduce real transparency in png sqlite. but this will be independent feature/request.
1. Original reason was to turn on "Automatic map loading" to see many maps, next to each other. When there are white collars, this is pointless, because there are white holes between maps. See my picture no.1 .
2. I made it with Mapc2mapc. Yes, I voted for introducing automatic cutting off of the whole-white tiles. And there in and option to scan for the white tiles, and you can set the "white" value
I do belive that you are the right person to make it right. And I know it is also hard to do that, because on some maps you have white colours as a part of the map itself. Remember also that in the future I will try to ask mapc2mapc author to introduce real transparency in png sqlite. but this will be independent feature/request.
Hi elmuSSo and Menion,
I`m also using Mapc2Mapc and Locus and I have run into the same problem with white collars/borders. I am taking png screenshots of topographic maps in quite large scale, where the screenshots cover adjacent areas, i.e. they fit together perfectly side by side without any overlap. Then I use Mapc2Mapc to calibrate them and write to sqlitedb format. And obviously I want Locus to "stitch" together all the sqlitedb files into one large continuous map.
The problem is that the maps are in EPSG:3006 so they have to be reprojected in Mapc2Mapc, creating a rotation of the map image and tiles with white borders on all four sides of the map, just like elmuSSos last image.
If the the maps were allowed to overlap in the intersections and the white collars were transparent in Locus, each sqlitedb map would line up perfectly with the next one (I`ve checked this using the Map Overlay feature with Multiply and Darken). However, the way it stands right now my approach doesn`t work, it simply looks awful with white squares in each intersection between adjacent maps.
One obvious solution would be to merge the screenshots into one giant png (e.g. 50k X 50k pixels) before calibration, but my computer cannot handle images of that size. This means I am forced to create separate sqlite files and put them in a common subfolder under Locus/maps.
I`ve thought of different strategies to overcome the problem, but to no avail:
- I let the screenshots consist of a certain number of 256x256 pixel tiles, but due to the reprojection/warping the white borders cannot be avoided.
- Merging the sqlitedb files into one gemf file doesn`t make any difference either.
- I even edited two sqlitedb files manually, replacing the 8 bit png tiles with 24/32 bit png tiles with transparent collars, but the only change in Locus is that the white areas become grey.
It would be great if Locus could handle this in some way, allowing overlap between adjacent maps and transparent collars. I could ask the Mapc2Mapc developer to add support for 24 bit pngs with transparency in sqlitedb, but at present it wouldn`t change anything for the better in Locus.
Hi elmuSSo and Menion,
I`m also using Mapc2Mapc and Locus and I have run into the same problem with white collars/borders. I am taking png screenshots of topographic maps in quite large scale, where the screenshots cover adjacent areas, i.e. they fit together perfectly side by side without any overlap. Then I use Mapc2Mapc to calibrate them and write to sqlitedb format. And obviously I want Locus to "stitch" together all the sqlitedb files into one large continuous map.
The problem is that the maps are in EPSG:3006 so they have to be reprojected in Mapc2Mapc, creating a rotation of the map image and tiles with white borders on all four sides of the map, just like elmuSSos last image.
If the the maps were allowed to overlap in the intersections and the white collars were transparent in Locus, each sqlitedb map would line up perfectly with the next one (I`ve checked this using the Map Overlay feature with Multiply and Darken). However, the way it stands right now my approach doesn`t work, it simply looks awful with white squares in each intersection between adjacent maps.
One obvious solution would be to merge the screenshots into one giant png (e.g. 50k X 50k pixels) before calibration, but my computer cannot handle images of that size. This means I am forced to create separate sqlite files and put them in a common subfolder under Locus/maps.
I`ve thought of different strategies to overcome the problem, but to no avail:
- I let the screenshots consist of a certain number of 256x256 pixel tiles, but due to the reprojection/warping the white borders cannot be avoided.
- Merging the sqlitedb files into one gemf file doesn`t make any difference either.
- I even edited two sqlitedb files manually, replacing the 8 bit png tiles with 24/32 bit png tiles with transparent collars, but the only change in Locus is that the white areas become grey.
It would be great if Locus could handle this in some way, allowing overlap between adjacent maps and transparent collars. I could ask the Mapc2Mapc developer to add support for 24 bit pngs with transparency in sqlitedb, but at present it wouldn`t change anything for the better in Locus.
1. I still thinks that the transparent collars feature is needed. Now when Menion introduced layers, its shouldn`t be very hard to implement also transparency/blending for the collars. We just need more votes for this idea.
2. Why are you taking a screenshots for that? This is tedious and taking a lot lot of work and it is not even effective. Feel free to write me an email to kif(at)poczta.ats.pl . I will help you to find a better way of doing this. write me the source of your maps here, please.
1. I still thinks that the transparent collars feature is needed. Now when Menion introduced layers, its shouldn`t be very hard to implement also transparency/blending for the collars. We just need more votes for this idea.
2. Why are you taking a screenshots for that? This is tedious and taking a lot lot of work and it is not even effective. Feel free to write me an email to kif(at)poczta.ats.pl . I will help you to find a better way of doing this. write me the source of your maps here, please.
Thanks for your reply elmuSSo. I take screenshots because I don`t know any better, that`s it! But I`m open to new ideas, will mail you about that.
Thanks for your reply elmuSSo. I take screenshots because I don`t know any better, that`s it! But I`m open to new ideas, will mail you about that.
What is the status of this ticket?
What is the status of this ticket?
on holiday :)
on holiday :)
Any progress?
Any progress?
currently no. Seems that not much people is currently interested in this task and because it`s not so simply, I`m leaving topic open, for now ...
currently no. Seems that not much people is currently interested in this task and because it`s not so simply, I`m leaving topic open, for now ...
Hello all!
I`ll definitely vote in here!
There often is the case where I want to use partially transparent overlays in LOCUS, with areas or polygons being coloured and other areas being transparent showing the base map. It is thus not only the issue with the collars!
Wouldn`t this be a super-feature??
And the approach suggested above - choosing a colour and treating it as transparent - doesn`t seem to be a very complicated thing to implement, isn`t it?
I plan to produce angle slope, aspect, contour, and other overlays for LOCUS for skiing and mountaineering - for this thing transparency of parts of the images would be essential!
Regards,
Kay
See the test-version of my planned service:
http://terrain-overlays.blogspot.co.at/
Hello all!
I`ll definitely vote in here!
There often is the case where I want to use partially transparent overlays in LOCUS, with areas or polygons being coloured and other areas being transparent showing the base map. It is thus not only the issue with the collars!
Wouldn`t this be a super-feature??
And the approach suggested above - choosing a colour and treating it as transparent - doesn`t seem to be a very complicated thing to implement, isn`t it?
I plan to produce angle slope, aspect, contour, and other overlays for LOCUS for skiing and mountaineering - for this thing transparency of parts of the images would be essential!
Regards,
Kay
See the test-version of my planned service:
http://terrain-overlays.blogspot.co.at/
I also ran into this issue, when using histircal scanned maps. I have setup a geoserver instance just to serve WMS layers in order to avoid this issue. I am sure there is a smarter way :-)
I also ran into this issue, when using histircal scanned maps. I have setup a geoserver instance just to serve WMS layers in order to avoid this issue. I am sure there is a smarter way :-)
Replies have been locked on this page!