Cropped geo-referenced pdf compatibility

[Off-track]

I have been experimenting with ways to crop geo-referenced pdf Mapsheets to remove the margin information, so that OM will automatically display map detail (not margin notes) as it moves from one pdf to the next. Several ways might work, but all currently run into hitches in OM. The geo-referenced pdf files that I start with do work in OM.



1. Several pdf cropping programs like pdfscissors or briss produce output that opens in OM, but displays white in some cropped areas (bottom and right in the examples I checked). I appreciate that 'cropping' a pdf just hides the margins, but it gives files that appear as if the margins are removed in other viewers. Could this be implemented in OM?



2. The fastest way when geo-referenced pdfs have appropriate neatline data is to use gdalwarp to cut to the neatline, then gdal_translate to get back to geo-referenced pdf format. Although these files do open correctly (with spatial referencing) in other spatially-aware viewers, OM gives the error "> Can not find GEO info!". Could OM be made to recognise geo-referenced pdfs from gdal?



3. This may be more problematic, but because each geo-referenced pdf is a separate map, OM only shows one at a time. As a user approaches the edge of one pdf map, the adjacent map area is blank (grey); until the edge of the current map passes the screen centre-point whereupon OM shifts to the adjoining map, but the map area just traversed goes blank. It would be good if the pdf maps could be tiled as a more seamless mosaic; for example by loading all those 'in view' on the screen rather than just the one covering the screen centrepoint.



The reason I experiment with this is that in some areas geo-referenced pdf maps have better resolution than available wms maps or openandromaps. People experienced with digital maps have no solution that I can implement, so it seems like time to ask the OM developer.

[orux]

I have been experimenting with ways to crop geo-referenced pdf Mapsheets to remove the margin information, so that OM will automatically display map detail (not margin notes) as it moves from one pdf to the next. Several ways might work, but all currently run into hitches in OM. The geo-referenced pdf files that I start with do work in OM.



1. Several pdf cropping programs like pdfscissors or briss produce output that opens in OM, but displays white in some cropped areas (bottom and right in the examples I checked). I appreciate that 'cropping' a pdf just hides the margins, but it gives files that appear as if the margins are removed in other viewers. Could this be implemented in OM?



2. The fastest way when geo-referenced pdfs have appropriate neatline data is to use gdalwarp to cut to the neatline, then gdal_translate to get back to geo-referenced pdf format. Although these files do open correctly (with spatial referencing) in other spatially-aware viewers, OM gives the error "> Can not find GEO info!". Could OM be made to recognise geo-referenced pdfs from gdal?



3. This may be more problematic, but because each geo-referenced pdf is a separate map, OM only shows one at a time. As a user approaches the edge of one pdf map, the adjacent map area is blank (grey); until the edge of the current map passes the screen centre-point whereupon OM shifts to the adjoining map, but the map area just traversed goes blank. It would be good if the pdf maps could be tiled as a more seamless mosaic; for example by loading all those 'in view' on the screen rather than just the one covering the screen centrepoint.



The reason I experiment with this is that in some areas geo-referenced pdf maps have better resolution than available wms maps or openandromaps. People experienced with digital maps have no solution that I can implement, so it seems like time to ask the OM developer.

Hello;



Thanks for trying the geopdf maps.



Although you see the borders, the app uses the neatline as the boundary of the map, so it must load another new map by passing those limits. But I have find a lot of maps with a neatline outside the map limits.



It is not possible to load multiple maps simultaneously. It is not easy unless they use exactly the same projection and zoom level. Otherwise the app would have to reproject the images, and it is a difficult and expensive task.



If you have a geopdf map that does not work (those one created with gdal), I would be interested in testing it, please send it to me.



The latest beta version posted in the forum adds support for other geopdf maps formats, perhaps you have not tried it.



If the maps are very overlapping, you can have the app change hte map before reaching the limit, changing the values in configuration - maps - margins X/Y.



orux

[Off-track]

Thanks Orux! Your explanation helps a lot, and geo-referenced pdf display is also much more capable in the v 7.0.18 beta3.



For example, NSW (e-Topo vector) pdfs now display without blinking on my phone (ZTE A462). There are some residual strange effects at low zoom levels (blank tiles, lower right of the map shown as an insert at upper left) and the maps can be very slow to load (to the point that Android thinks that OM has stopped working), but all of this is probably due to the limited processing power of the phone.



There does seem to be a new problem with QLD (QTopo raster) pdfs. They load with incorrect geometry: grid 'squares' are rectangular (stretched N-S). Also these maps do not transition at the map edge. It is almost as if they have been loaded with the whole mapsheet in the area for the neatline?



With your explanation there is no advantage in cropping, although I guess some enthusiasts might want instead to edit some files to substitute neatlines that do correspond with the map area. The good news for them is that geo-referenced pdfs from gdal do load in OM 7.0.18 beta3. In fact those I cropped from QLD pdfs display with correct grid geometry and transition at the neatline, though OM still displays a white area at bottom and right which is not seen in other spatially-aware viewers (like Acrobat viewer).

[orux]

Thanks Orux! Your explanation helps a lot, and geo-referenced pdf display is also much more capable in the v 7.0.18 beta3.



For example, NSW (e-Topo vector) pdfs now display without blinking on my phone (ZTE A462). There are some residual strange effects at low zoom levels (blank tiles, lower right of the map shown as an insert at upper left) and the maps can be very slow to load (to the point that Android thinks that OM has stopped working), but all of this is probably due to the limited processing power of the phone.



There does seem to be a new problem with QLD (QTopo raster) pdfs. They load with incorrect geometry: grid 'squares' are rectangular (stretched N-S). Also these maps do not transition at the map edge. It is almost as if they have been loaded with the whole mapsheet in the area for the neatline?



With your explanation there is no advantage in cropping, although I guess some enthusiasts might want instead to edit some files to substitute neatlines that do correspond with the map area. The good news for them is that geo-referenced pdfs from gdal do load in OM 7.0.18 beta3. In fact those I cropped from QLD pdfs display with correct grid geometry and transition at the neatline, though OM still displays a white area at bottom and right which is not seen in other spatially-aware viewers (like Acrobat viewer).

Thanks for your testings!



I have downloaded some maps from QTopo, working fine in my devices.



If you can share some not working maps with me, I can try to find where is the problem,





orux

[Off-track]

All the QTopo 1:25000 pdf mapsheets along the Eastern part of the border between QLD and NSW give this same 'geometry' problem for me in both 7.0.17 and 7.0.18beta3 versions of OM. The overlapping mapsheets from e-Topo (NSW) do not have the problem. Also the QTopo sheets do not have the problem when viewed in Acrobat reader.



As mentioned before, the QTopo maps do not give the geometry problem in OM (beta) after cropping using gdal (but there is some loss in resolution during the transformations).



A good example of the problem is the QTopo Tyalgum sheet vs the e-Topo Tyalgum sheet (ignoring the insert at TL).



Both give the same projection and datum details in gdalinfo; but the QTopo map is stretched N-S when viewed in OM.



I hope that helps.

[Off-track]

Thanks again Orux, it works without  problems  in v7.0.18beta4