rasbats / photolayer_pi Goto Github PK

A way of handling transparancy in geotiffs would be great.
The black borders from skewed charts is quite annoying.

See example image

FS#2698 - Many plugins cannot compile with new PluginConfigure.cmake requiring to run from a git repo

The new version of PluginConfigure.cmake file written by John Gaugh and reused for several plugins (see list bellow) requires the build to be run fro ma git valid repo.
When building packages in the distro system (my case Open Build System from OpenSUSE), the source used for the build is a copy and not a valid git repo, so the cmake fails miserably.

Having at least an option to deactivate that feature to allow and off git build is required.

Could we have a clean solution to by overcome that feature when not needded ?

Thanks.

Dominig

OpenCPN-DR_pi
OpenCPN-nmeaconverter_pi
OpenCPN-ocpn_draw_pi
OpenCPN-photolayer_pi
OpenCPN-UKTides_pi
OpenCPN-vfkaps_pi

I have some GeoTiff images created with SASPlanet and sat images
All are correctly placed using Linux version of plugin, self compiled (2.1.1 version)
Some are misplaced with same version plugin in Windows10/64 bit. Misplace is sometime at 0/0 lat/lon, sometime at another coordinate. In only one image there is a small displacement from correct coordinate.

If needed I can provide files misplaced.

Regards

Franco Spinelli

Trying to get the dependencies correct. Tries to use local libs for geotiff and libtiff but this fails.

https://app.circleci.com/pipelines/github/Rasbats/photolayer_pi/302/workflows/9bb4df9d-eb70-4580-b45d-08731862a26d/jobs/3030

Tried to add mingw32-libtiff and mingw32-geotiff to opencpn-deps.spec but this does not work. Still tries to use the local libs.

linkchecker says:

 List of broken links and other issues:
2021-08-23T07:55:50.3754607Z 
2021-08-23T07:55:50.3755094Z https://www.opentopomap.org/	
2021-08-23T07:55:50.3755587Z   Line: 677
2021-08-23T07:55:50.3755910Z   Code: 200 OK
2021-08-23T07:55:50.3756417Z  To do: Some of the links to this resource point to broken URI fragments
2021-08-23T07:55:50.3756998Z 	(such as index.html#fragment).
2021-08-23T07:55:50.3757491Z The following fragments need to be fixed:
2021-08-23T07:55:50.3758106Z 	map=12/43.7116/-7.6101        	Line: 677
2021-08-23T07:55:50.3758449Z Anchors
2021-08-23T07:55:50.3758665Z 

OTOH, feeding #map=12/43.7116/-7.6101 to opentopomap seems to work fine in the browser.

It might be that the url needs to be url-encoded. Could you try to change map=12/43.7116/-7.6101to the url-encoded representation map%3D12%2F43.7114%2F-7.6103 ?

EDIT: The url-encoded value is map%3D12%2F43.7116%2F-7.6101

Using leamas workflow files.

Adding these files to the linker allows the plugin to compile and work locally (VS2017).
opengl32.lib
glu32.lib

How to modify CMakeLists.txt or elsewhere to fix this?

Bad formatting in CML at the moment. Just going to fix this.

The plugin uses the system libgeotiff and proj runtime libraries. This leads to problems where users need to install various packages to make plugin work an all platforms besides windows.

The flatpak variant rebuilds these libs from sources. This makes it easier for users, which don't need to mess with installing packages besides libtiff which often is installed anyway.

We should try to rebuild these packages as part of the plugin in the same way as flatpak an other platforms.

The plugin is built using libraries from homebrew: libtiff, libexif, and sqlite (which pulls in sqlite). These libraries are not available in runtime, and must thus be dealt with similar to how linux is handled.

libexif and sqlite are just not used and can be dropped.

libtiff creates a runtime dependency:

 $ otool -L  app/photolayer-3.4-darwin-10.13.6/OpenCPN.app/Contents/PlugIns/libphotolayer_pi.dylib | grep tiff
 /usr/local/opt/libtiff/lib/libtiff.5.dylib (compatibility version 12.0.0, current version 12.0.0)

This just wont work, since the /usr/local/opt/libtiff/lib/libtiff.5.dylib lib belongs to the brew package which isn't available in runtime. (it is most likely the reason the plugin doesn't load). Must be fixed somehow.

Build is failing because geotiffio.h is not found while present on the build system in standard Linux location. Cmake is somewhere not oing the right thing.
Most likely not using package config libgeotiff.pc
--------- error log -------------
/home/abuild/rpmbuild/BUILD/photolayer_pi-5.0.0.1562685896.cecf6a5/src/PhotoLayer.h:30:10: fatal error: geotiffio.h: No such file or directory
#include "geotiffio.h"

----------- extract of list of include files --------------

/usr/include/libgeotiff
/usr/include/libgeotiff/cpl_serv.h
/usr/include/libgeotiff/epsg_datum.inc
/usr/include/libgeotiff/epsg_ellipse.inc
/usr/include/libgeotiff/epsg_gcs.inc
/usr/include/libgeotiff/epsg_pcs.inc
/usr/include/libgeotiff/epsg_pm.inc
/usr/include/libgeotiff/epsg_proj.inc
/usr/include/libgeotiff/epsg_units.inc
/usr/include/libgeotiff/epsg_vertcs.inc
/usr/include/libgeotiff/geo_config.h
/usr/include/libgeotiff/geo_ctrans.inc
/usr/include/libgeotiff/geo_keyp.h
/usr/include/libgeotiff/geo_normalize.h
/usr/include/libgeotiff/geo_simpletags.h
/usr/include/libgeotiff/geo_tiffp.h
/usr/include/libgeotiff/geokeys.h
/usr/include/libgeotiff/geokeys.inc
/usr/include/libgeotiff/geonames.h
/usr/include/libgeotiff/geotiff.h
/usr/include/libgeotiff/geotiffio.h
/usr/include/libgeotiff/geovalues.h
/usr/include/libgeotiff/xtiffio.h
/usr/lib64/libgeotiff.so
/usr/lib64/pkgconfig/libgeotiff.pc
/usr/share/doc/packages/geotiff-devel
/usr/share/doc/packages/geotiff-devel/ChangeLog
/usr/share/doc/packages/geotiff-devel/NEWS
/usr/share/doc/packages/geotiff-devel/README
/usr/share/licenses/geotiff-devel
/usr/share/licenses/geotiff-devel/COPYING
/usr/share/licenses/geotiff-devel/LICENSE

--------- libgeotiff.pc -------------
cat /usr/lib64/pkgconfig/libgeotiff.pc
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib64
includedir=/usr/include/libgeotiff

Name: libgeotiff5
Version: 1.5.1
Description: GeoTIFF file format library
Libs: -L/usr/lib64 -lgeotiff
Cflags: -I/usr/include/libgeotiff

Hello and thank you for this very useful plugin.

I have some troubles by loading the photolayer_pi plugin in openCPN 5.2.4 in one of my two computers, both running on Ubuntu 18.04.

When the plugin manager load the plugin, i have the following error in the opencpn log :
ERROR dlunix.cpp:2291 ...../lib/opencpn/libphotolayer_pi.so: undefined symbol: proj_get_type

Do you have any idea about what is going on?

Thanks!

VRI

As reported in https://www.cruisersforum.com/forums/showthread.php?p=3319962#post3319962 there are problems also with libGLU on Raspbian. There is also an indirect libtiff dependency from libgeotiff.

SEE https://ci.appveyor.com/project/rgleason/photolayer-pi/builds/22674555

Here is the appveyor.yml file that I used.
Mike, Any idea why it is failing?
----PhotoLayer.h(30): fatal error C1083: Cannot open include file: 'geotiffio.h': No such file or directory?

"C:\project\weather_routing_pi\build\package.vcxproj" (default target) (1) ->
"C:\project\weather_routing_pi\build\ZERO_CHECK.vcxproj" (default target) (2) ->
(CheckWindowsSDK71A target) -> 
  C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Platforms\Win32\PlatformToolsets\v141_xp\Toolset.targets(39,5): warning MSB8051: Support for targeting Windows XP is deprecated and will not be present in future releases of Visual Studio. Please see https://go.microsoft.com/fwlink/?linkid=2023588 for more information. [C:\project\weather_routing_pi\build\ZERO_CHECK.vcxproj]
"C:\project\weather_routing_pi\build\package.vcxproj" (default target) (1) ->
"C:\project\weather_routing_pi\build\ALL_BUILD.vcxproj" (default target) (3) ->
"C:\project\weather_routing_pi\build\PhotoLayer_pi.vcxproj" (default target) (4) ->
"C:\project\weather_routing_pi\build\PhotoLayer-i18n.vcxproj" (default target) (5) ->
  C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Platforms\Win32\PlatformToolsets\v141_xp\Toolset.targets(39,5): warning MSB8051: Support for targeting Windows XP is deprecated and will not be present in future releases of Visual Studio. Please see https://go.microsoft.com/fwlink/?linkid=2023588 for more information. [C:\project\weather_routing_pi\build\PhotoLayer-i18n.vcxproj]
"C:\project\weather_routing_pi\build\package.vcxproj" (default target) (1) ->
"C:\project\weather_routing_pi\build\ALL_BUILD.vcxproj" (default target) (3) ->
"C:\project\weather_routing_pi\build\PhotoLayer_pi.vcxproj" (default target) (4) ->
  C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Platforms\Win32\PlatformToolsets\v141_xp\Toolset.targets(39,5): warning MSB8051: Support for targeting Windows XP is deprecated and will not be present in future releases of Visual Studio. Please see https://go.microsoft.com/fwlink/?linkid=2023588 for more information. [C:\project\weather_routing_pi\build\PhotoLayer_pi.vcxproj]
"C:\project\weather_routing_pi\build\package.vcxproj" (default target) (1) ->
"C:\project\weather_routing_pi\build\ALL_BUILD.vcxproj" (default target) (3) ->
"C:\project\weather_routing_pi\build\PhotoLayer_pi.vcxproj" (default target) (4) ->
(ClCompile target) -> 
  c:\project\weather_routing_pi\src\photolayerimage.cpp(158): warning C4700: uninitialized local variable 'lastphase_pos' used [C:\project\weather_routing_pi\build\PhotoLayer_pi.vcxproj]
"C:\project\weather_routing_pi\build\package.vcxproj" (default target) (1) ->
"C:\project\weather_routing_pi\build\ALL_BUILD.vcxproj" (default target) (3) ->
"C:\project\weather_routing_pi\build\PhotoLayer_pi.vcxproj" (default target) (4) ->
(ClCompile target) -> 
  c:\project\weather_routing_pi\src\PhotoLayer.h(30): fatal error C1083: Cannot open include file: 'geotiffio.h': No such file or directory [C:\project\weather_routing_pi\build\PhotoLayer_pi.vcxproj]
  c:\project\weather_routing_pi\src\PhotoLayer.h(30): fatal error C1083: Cannot open include file: 'geotiffio.h': No such file or directory [C:\project\weather_routing_pi\build\PhotoLayer_pi.vcxproj]
    4 Warning(s)
    2 Error(s)
Time Elapsed 00:00:27.68

Opening browse for files does not show supported GeoTIFFs (*.tiff). Instead one have to select show all to be able to select a file.

This should also support batch import of layers instead of picking one after another.

The plugin displays Spanish when using Swedish as language-setting in Opencpn. No way of changing the language in the plugin.

If passing the variable via cmake -DBUILD_TYPE:STRING=pkg
cmake complete but creates a make file that try to download a project with a non existant URL.
Would master branch be broken ?

Scanning dependencies of target EXT_PROJ
[   93s] [  1%] Creating directories for 'EXT_PROJ'
[   93s] [  2%] Performing download step (download, verify and extract) for 'EXT_PROJ'
[   93s] -- Downloading...
[   93s]    dst='/home/abuild/rpmbuild/BUILD/photolayer_pi-5.2.0.1612093049.9974833/libs/libgeotiff/cache/proj-7.2.1.tar.gz'
[   93s]    timeout='none'
[   93s] -- Using src='https://github.com/OSGeo/PROJ/releases/download/7.2.1/proj-7.2.1.tar.gz'
[   93s] -- Retrying...
[   93s] -- Using src='https://github.com/OSGeo/PROJ/releases/download/7.2.1/proj-7.2.1.tar.gz'
[   93s] -- Retry after 5 seconds (attempt #2) ...
[   98s] -- Using src='https://github.com/OSGeo/PROJ/releases/download/7.2.1/proj-7.2.1.tar.gz'
[   98s] -- Retry after 5 seconds (attempt #3) ...
[  103s] -- Using src='https://github.com/OSGeo/PROJ/releases/download/7.2.1/proj-7.2.1.tar.gz'
[  103s] -- Retry after 15 seconds (attempt #4) ...
[  118s] -- Using src='https://github.com/OSGeo/PROJ/releases/download/7.2.1/proj-7.2.1.tar.gz'
[  118s] -- Retry after 60 seconds (attempt #5) ...
[  178s] -- Using src='https://github.com/OSGeo/PROJ/releases/download/7.2.1/proj-7.2.1.tar.gz'
[  178s] CMake Error at /home/abuild/rpmbuild/BUILD/photolayer_pi-5.2.0.1612093049.9974833/build/libs/libgeotiff/EXT_PROJ-prefix/src/EXT_PROJ-stamp/download-EXT_PROJ.cmake:159 (message):
[  178s]   Each download failed!

Got the error while trying to import GeoTiffs created via Georeferencer.com

QGIS can open the file.

Would help if there were a FAQ/more in depth walk through when it comes to what kind of meta-data the the plugin requires.

As heading says. No time to fix now.