• Qt+GDAL开发笔记（二）：在windows系统msvc207x64编译GDAL库、搭建开发环境和基础Demo

    若该文为原创文章，转载请注明原文出处
    本文章博客地址：https://hpzwl.blog.csdn.net/article/details/132077288

    红胖子网络科技博文大全：开发技术集合（包含Qt实用技术、树莓派、三维、OpenCV、OpenGL、ffmpeg、OSG、单片机、软硬结合等等）持续更新中…

    Qt开发专栏：三方库开发技术

    上一篇：《Qt+GDAL开发笔记（一）：在windows系统mingw32编译GDAL库、搭建开发环境和基础Demo》
    下一篇：敬请期待…


    前言

      上一篇使用mingw32版本的gdal，过程曲折，为更好的更方便搭建环境，在windows上msvc方式对于库比较友好。


    相关博客

      《麒麟系统开发笔记（十二）：在国产麒麟系统上编译GDAL库、搭建基础开发环境和基础Demo》
      《Qt+GDAL开发笔记（一）：在windows系统mingw32编译GDAL库、搭建开发环境和基础Demo》
      《Qt+GDAL开发笔记（二）：在windows系统msvc207x64编译GDAL库、搭建开发环境和基础Demo》


    大地坐标简介

    概述

      大地坐标（Geodetic coordinate）是大地测量中以参考椭球面为基准面的坐标，地面点P的位置用大地经度L、大地纬度B和大地高H表示。

    原理

      当点在参考椭球面上时，仅用大地经度和大地纬度表示。大地经度是通过该点的大地子午面与起始大地子午面（通过格林尼治天文台的子午面）之间的夹角。规定以起始子午面起算，向东由0°至180°称为东经；向西由0°至180°称为西经。大地纬度是通过该点的法线与赤道面的夹角，规定由赤道面起算，由赤道面向北从0°至90°称为北纬；向南从0°到90°称为南纬。大地高是地面点沿法线到参考椭球面的距离。

    北京54坐标系：BJZ54

      北京54坐标系(BJZ54)是指北京54坐标系为参心大地坐标系，大地上的一点可用经度L54、纬度M54和大地高H54定位，它是以克拉索夫斯基椭球为基础，经局部平差后产生的坐标系。

    • 长半轴a = 6378245m
    • 短半轴b = 6356863.0188m
    • 第一偏心率平方e2 = 0.006693421622
    • 扁率α =1/298.3

    世界大地坐标系统：WGS-84

      WGS-84坐标系是世界大地坐标系统，其坐标原点在地心，采用WGS-84椭球（1984世界大地坐标系）。
      WGS-84坐标系是美国国防部研制确定的大地坐标系，是一种协议地球坐标系。
      WGS-84坐标系的定义是：原点是地球的质心，空间直角坐标系的Z轴指向BIH（1984.0）定义的地极（CTP）方向，即国际协议原点CIO，它由IAU和IUGG共同推荐。X轴指向BIH定义的零度子午面和CTP赤道的交点，Y轴和Z，X轴构成右手坐标系。
      WGS-84椭球采用国际大地测量与地球物理联合会第17届大会测量常数推荐值，采用的两个常用基本几何参数：

    • 长半轴a = 6378137m
    • 短半轴b = 6356752.3142m
    • 第一偏心率平方e2 = 0.00669437999013
    • 扁率 α= 1/298.257223563

    国家大地坐标系：CGCS2000

      2000国家大地坐标系，是我国当前最新的国家大地坐标系，英文名称为China Geodetic Coordinate System 2000，英文缩写为CGCS2000。
      2000国家大地坐标系的原点为包括海洋和大气的整个地球的质量中心；2000国家大地坐标系的Z轴由原点指向历元2000.0的地球参考极的方向，该历元的指向由国际时间局给定的历元为1984.0的初始指向推算，定向的时间演化保证相对于地壳不产生残余的全球旋转，X轴由原点指向格林尼治参考子午线与地球赤道面（历元2000.0）的交点，Y轴与Z轴、X轴构成右手正交坐标系。采用广义相对论意义下的尺度。

    • 长半轴a = 6378137m
    • 短半轴b = 6356752.314m
    • 第一偏心率平方e2 = 0.00669438002290
    • 扁率α = 1/298.257222101

    GDAL库

    概述

      GDAL(Geospatial Data Abstraction Library)是一个在X/MIT许可协议下的开源栅格空间数据转换库。它利用抽象数据模型来表达所支持的各种文件格式。它还有一系列命令行工具来进行数据转换和处理。 OGR是GDAL项目的一个分支，提供对矢量数据的支持。 有很多著名的GIS类产品都使用了GDAL/OGR库，包括ESRI的ARCGIS 9.3，Google Earth和跨平台的GRASS GIS系统。利用GDAL/OGR库，可以使基于Linux的地理空间数据管理系统提供对矢量和栅格文件数据的支持。

    功能特征

    • GDAL提供对多种栅格数据的支持，包括Arc/Info ASCII Grid(asc)，GeoTiff (tiff)，Erdas Imagine Images(img)，ASCII DEM(dem) 等格式。
    • GDAL使用抽象数据模型(abstract data model)来解析它所支持的数据格式，抽象数据模型包括数据集(dataset)，坐标系统，仿射地理坐标转换(Affine Geo Transform)，大地控制点(GCPs)，元数据(Metadata)，栅格波段(Raster Band)，颜色表(Color Table)，子数据集域(Subdatasets Domain)，图像结构域(Image_Structure Domain)，XML域(XML:Domains)。
    • GDALMajorObject类：带有元数据的对象。
    • GDALDdataset类：通常是从一个栅格文件中提取的相关联的栅格波段集合和这些波段的元数据;
    • GDALDdataset也负责所有栅格波段的地理坐标转换(georeferencing transform)和坐标系定义。
    • GDALDriver类：文件格式驱动类，GDAL会为每一个所支持的文件格式创建一个该类的实体，来管理该文件格式。
    • GDALDriverManager类：文件格式驱动管理类，用来管理GDALDriver类。

    OGR体系结构

    • Geometry类：Geometry (包括OGRGeometry等类)封装了OpenGIS的矢量数据模型，并提供了一些几何操作，WKB(Well Knows Binary)和WKT(Well Known Text)格式之间的相互转换，以及空间参考系统(投影)。
    • Spatial Reference类：OGRSpatialReference封装了投影和基准面的定义。
    • Feature类：OGRFeature封装了一个完整feature的定义，一个完整的feature包括一个geometry和geometry的一系列属性。
    • Feature Definition类：OGRFeatureDefn里面封装了feature的属性，类型、名称及其默认的空间参考系统等。一个OGRFeatureDefn对象通常与一个层(layer)对应。
    • Layer类：OGRLayer是一个抽象基类，表示数据源类OGRDataSource里面的一层要素(feature)。
    • Data Source类：OGRDataSource是一个抽象基类，表示含有OGRLayer对象的一个文件或一个数据库。
    • Drivers类：OGRSFDriver对应于每一个所支持的矢量文件格式。类OGRSFDriver由类OGRSFDriverRegistrar来注册和管理。

    下载地址

      Home：https://gdal.org/download.html
     选择3.2.1版本


    关于编译顺序

       因为首先选择的是之前vs2019编译成功的版本，但是本次vs2017x64无解了。
      gdal依赖proj，proj又依赖sqlite，所以本篇先sqlite，再proj，最后gdal。


    编译SQLite 3.34.1（windows msvc2017x64版本）

    步骤一：下载解压

      https://www.sqlite.org/download.html
      在这里插入图片描述

    步骤二：使用VS2017新建VC++空工程

      在这里插入图片描述

      在这里插入图片描述

    步骤三：添加文件到工程

      在这里插入图片描述

      在这里插入图片描述

    步骤四：添加宏命令

      在这里插入图片描述

    _USRDLL
SQLITE_ENABLE_RTREE
SQLITE_ENABLE_COLUMN_METADATA
SQLITE_ENABLE_FTS5
SQLITE_ENABLE_UNLOCK_NOTIFY

    • 1
    • 2
    • 3
    • 4
    • 5

      在这里插入图片描述

    步骤六：修改sqlite3.def

    sqlite3_unlock_nofity

    • 1

      在这里插入图片描述

    步骤七：修改目标

      这里release和debug都要改成配置类型“静态库(.lib)”：
      在这里插入图片描述

    步骤八：编译成功

      编译：
      在这里插入图片描述

      在这里插入图片描述

      在这里插入图片描述

      在这里插入图片描述


    编译PROJ 6.2.0（windows msvc2017x64版本）

    步骤一：下载解压

      https://proj.org/download.html
      在这里插入图片描述

    步骤二：CMake配置，添加sqlite3

      在这里插入图片描述

      （注意：配置的时候选择编译器就要选择x64的，不要去vs里面再建，有些环境变量需要CMake带进去）
      没有添加SQLIte，则会报错：
      在这里插入图片描述

      添加：
      在这里插入图片描述

      在这里插入图片描述

      安装python到系统，自己下个python3.7.3版本，装到系统，然后将python的可执行文件添加进系统变量：
      在这里插入图片描述

      然后重启CMake，再继续：
      在这里插入图片描述

      下个对应版本的sqlite3.exe：
      在这里插入图片描述
    在这里插入图片描述

      继续配置，配置通过：
      在这里插入图片描述

    步骤三：CMake生成工程

      在这里插入图片描述

    步骤四：打开编译（使用vs2017打开）

      在这里插入图片描述

      （PS：若是这里没有x64，则是需要在CMakeGui的时候配置configure选择x64，在这里新建是会要报错的）

    步骤五：编译成功

      在这里插入图片描述

      在这里插入图片描述


    编译GDAL（windows msvc2017x64版本）

    步骤一：下载解压

      之前做osgearth编译过Qt5.15的2019x64版本，本次编译qt5.9.3的2017x64版本。
      在这里插入图片描述

    步骤二：修改源码

      修改目录下的nmake.opt文件，如下：
      第41行的代码修改为：
      在这里插入图片描述

    !IFNDEF MSVC_VER
#MSVC_VER=1800 # VS2013
#MSVC_VER=1900 # VS2015
MSVC_VER=1910 # vs2017
#MSVC_VER=1921 # VS2019
!ENDIF
WIN64=1

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7

    步骤三：打开vs2017命令行编译

      在这里插入图片描述

      在这里插入图片描述

      找到目录，并输入命令：

    nmake /f makefile.vc MSVC_VER=1910 WIN64=1 DEBUG=1

    • 1

      出现错误：
      在这里插入图片描述

      修改如下（前面鄙夷的时候，请注意proj的prefix_install路径配置，来看install到哪个位置了）：
      在这里插入图片描述

      入坑编译过不去解决：
      在这里插入图片描述

      然后继续编译：

    nmake /f makefile.vc MSVC_VER=1910 WIN64=1 DEBUG=1

    • 1

    步骤四：编译

    nmake /f makefile.vc MSVC_VER=1910 WIN64=1 DEBUG=1

    • 1

      在这里插入图片描述

      这是前面配置proj的时候没有去掉多shell32和ole32，然后继续：
      在这里插入图片描述

      这是没有引入sqlite，重新在gdal引入下;
      在这里插入图片描述

      然后继续，终于编译成功了，问题居多，历时两天了，：
      在这里插入图片描述

      在这里插入图片描述

    步骤五：安装提取

      （这里debug就是代表调试模式）

    nmake /f makefile.vc MSVC_VER=1910 WIN64=1 DEBUG=1 install

    • 1

      在这里插入图片描述

      在这里插入图片描述

      还得进行一次devinstall：

    nmake /f makefile.vc MSVC_VER=1910 WIN64=1 DEBUG=1 devinstall

    • 1

      在这里插入图片描述

      在这里插入图片描述

      在这里插入图片描述

      头文件终于出来了。

    步骤六：走一遍非调试模式

      之前以为DEBUG是编译过程打印调试信息，现在看来就是生成的库是不是调试模式了，我们需要release所以再来一遍：

    nmake /f makefile.vc MSVC_VER=1910 WIN64=1 
nmake /f makefile.vc MSVC_VER=1910 WIN64=1 install
nmake /f makefile.vc MSVC_VER=1910 WIN64=1 devinstall

    • 1
    • 2
    • 3

      在这里插入图片描述

    步骤七：调整工程测试

      对pri文件进行windows库的引入，如下图：
      在这里插入图片描述


    模块化

      在这里插入图片描述


    Demo源码

    GDALManager.pri

    INCLUDEPATH += $$PWD
DEPENDPATH += $$PWD

HEADERS += \
    $$PWD/GDALManager.h

SOURCES += \
    $$PWD/GDALManager.cpp


win32 {


    # windows Qt5.9.3 msvc2017x64 版本 gdal
    INCLUDEPATH += $$PWD/gdal-3.2.1_msvc2017x64/include
    LIBS += -L$$PWD/gdal-3.2.1_msvc2017x64/lib
    LIBS += -lgdal_i



    # 引入也失败了,当前不深
#    # windows Qt5.9.3 mingw32 版本 sqlite3
#    INCLUDEPATH += $$PWD/gdal3.2.1_qt593_mingw32/sqlite3/include
#    LIBS += -L$$PWD/gdal3.2.1_qt593_mingw32/sqlite3/lib
#    LIBS += -lsqlite3

#    # windows Qt5.9.3 mingw32 版本 proj6.2.0
#    INCLUDEPATH += $$PWD/gdal3.2.1_qt593_mingw32/proj6.2.0/include
#    LIBS += -L$$PWD/gdal3.2.1_qt593_mingw32/proj6.2.0/lib
#    LIBS += -lproj

#    # windows Qt5.9.3 mingw32 版本 gdal3.2.1
#    INCLUDEPATH += $$PWD/gdal3.2.1_qt593_mingw32/gdal3.2.1/include
#    LIBS += -L$$PWD/gdal3.2.1_qt593_mingw32/gdal3.2.1/lib
#    LIBS += -lgdal
}else {

    DEFINES += LINUX

    # GDAL系统安装的默认路径位/usr/local
    # 系统库，头文件路径和库文件默认已包含
    LIBS += -lgdal
    # PROJ系统安装的默认路径位/usr/local
    # 系统库，头文件路径和库文件默认已包含
    LIBS += -lproj
}

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46

    GDALManager.h

    #ifndef GDALMANAGER_H
#define GDALMANAGER_H

#include 

class GDALManager : public QObject
{
    Q_OBJECT
public:
    explicit GDALManager(QObject *parent = 0);

signals:

public:
    static void testEnv();                     // v1.0.0 测试环境

private:
};

#endif // GDALMANAGER_H

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20

    GDALManager.cpp

    #include "GDALManager.h"

#include "gdal.h"

#include 
#include 
//#define LOG qDebug()<<__FILE__<<__LINE__
//#define LOG qDebug()<<__FILE__<<__LINE__<<__FUNCTION__
//#define LOG qDebug()<<__FILE__<<__LINE__<
//#define LOG qDebug()<<__FILE__<<__LINE__<
#define LOG qDebug()<<__FILE__<<__LINE__<<QDateTime::currentDateTime().toString("yyyy-MM-dd hh:mm:ss:zzz")

GDALManager::GDALManager(QObject *parent)
    : QObject(parent)
{
    // 注册所有驱动
    GDALAllRegister();
}

void GDALManager::testEnv()
{
    QString version = QString(GDALVersionInfo("RELEASE_NAME"));
    LOG << version;
}

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24

    工程模板v1.1.0

      在这里插入图片描述


    上一篇：《Qt+GDAL开发笔记（一）：在windows系统mingw32编译GDAL库、搭建开发环境和基础Demo》
    下一篇：敬请期待…


    若该文为原创文章，转载请注明原文出处
    本文章博客地址：https://hpzwl.blog.csdn.net/article/details/132077288

  • 相关阅读:
    拥抱AI，怎么跨越Prompt这道鸿沟？
    微服务框架 SpringCloud微服务架构 16 SpringAMQP 16.6 FanoutExchange
    STL：string容器详解
    iOS关于列表布局的几种实现方式小结
    Linux远程连接失败（Linux与Windows相互可以ping）
    安装node， 配置npm全局安装位置，安装Vue.
    vector的模拟实现
    Python requests有问题
    docker部署django（uwsgi+nginx）
    odoo16前端框架源码阅读——启动、菜单、动作
  • 原文地址：https://blog.csdn.net/qq21497936/article/details/132077288