[Dutch] mini-seminar RD en Open Source Software (follow-up)

Zo Okt 23 10:19:17 PDT 2016

On 10/23/2016 06:00 PM, Richard Duivenvoorde wrote:
> On 23-10-16 16:00, Sebastiaan Couwenberg wrote:
>> On 10/21/2016 01:22 PM, Sebastiaan Couwenberg wrote:
>>> On 10/01/2016 12:51 PM, Frank Steggink wrote:
>>>> Op donderdag 20 oktober a.s. organiseert OSGeo.nl het mini-seminar "RD
>>>> en Open Source Software". Het doel is tweeledig: allereerst om de
>>>> bezoeker kennis bij te brengen over coördinatenstelsels in het algemeen
>>>> en het Rijksdriehoeksstelsel in het bijzonder. Het tweede doel is om
>>>> coördinatenstelsels op een juiste manier toe te passen binnen software,
>>>> waarbij de focus natuurlijk ligt op open source software.
>>>
>>> [...]
>>>
>>> Resultaat van de discussie rondom de NTv2 grid shift files was dat geen
>>> aanpassing meer nodig is voor recente versies van PROJ.4, PostGIS en
>>> GeoTIFF om de juiste towgs84 waardes, zoals gepubliceerd door Kadaster,
>>> te gebruiken.
>>>
>>> Dankzij de discussie met Lennard in 2014-2016 op deze lijst [0] zijn er
>>> bugs gevonden in GDAL [1] en PROJ.4 [2] welke resulteerde in incorrecte
>>> waardes voor EPSG:28992 en fouten bij gebruik van de NTv2 grid shift files.
>>>
>>> [0] https://lists.osgeo.org/pipermail/dutch/2014-October/000980.html
>>> [1] https://lists.osgeo.org/pipermail/dutch/2015-February/001105.html
>>> [2] https://lists.osgeo.org/pipermail/dutch/2016-February/001377.html
>>
>> Een van de vragen rondom de NTv2 grid shift files van Kadaster was hoe
>> deze te gebruiken in QGIS, het installeren van de proj-rdnap package op
>> Debian/Ubuntu is daarvoor niet genoeg (dit maakt ze slechts beschikbaar
>> voor PROJ.4).
>>
>> QGIS gebruikt een SQLite database voor zijn diens projecties (srs.db) en
>> synchroniseert deze bij de installatie met de definities gebruikt door GDAL.
>>
>> Hiervoor wordt onder andere de epsg.wkt file van GDAL gebruikt en op
>> Debian/Ubuntu en Fedora zijn de twee include files daarin
>> (esri_extra.wkt & cubewerx_extra.wkt) niet beschikbaar omdat er geen
>> licentie voor bekend is (en zodoende onder strikte copyright valt). In
>> cubewerx_extra.wkt is o.a. EPSG:900913 gedefinieerd waardoor de Google
>> Mercator projectie komt te vervallen.
>>
>> Gelukkig bied QGIS de mogelijkheid om zelf een CRS te definieren (via
>> Settings -> Custom CRS...), dit is de aangewezen methode om ontbrekende
>> projecties toe te voegen. [3] Deze projecties worden in het user profile
>> opgeslagen (in qgis.db) worden zodoende ook niet overschreven bij een
>> upgrade van de software, wat wel gebeurd als
>> /usr/share/qgis/resources/srs.db wordt aangepast.
> 
> Hoi Bas,
> 
> ik stuitte nog op deze post van Sourcepole:
> 
> http://blog.sourcepole.ch/2014/02/18/ntv2-transformations-with-qgis/
> 
> blijkbaar is het dus zo dat je mits je het juiste vinkje hebt, QGIS kan
> laten vragen WELKE datum transformatie hij moet gebruiken. Je krjgt dan
> voor 28992 naar een andere crs deze dialoog:
> http://pix.toile-libre.org/upload/original/1477238061.png
> waarin ik volgens mij OOK die 4833 herken waar Lennart het over had :-)
> 
> BLIJKBAAR kun je daar dus ook een NTv2 grid laten verschijnen door die
> aan de srs.db toe te voegen (en MITS je die grid natuurlijk beschikbaar
> heb in "/usr/share/proj on Linux and OSGeo4W\share\proj on Windows")
> 
> Dus: we zouden:
> - een pull request kunnen doen om die row toe te voegen aan de srs.db
> (dat zou voor mij al helpen aangezien in Debian ik proj_rndap heb
> geinstalleerd :-) )

Omdat crssync alle records uit srs.db verwijderd waarvan het EPSG ID
niet in de GDAL CSVs voorkomt is bovenstaande niet voldoende.

Als records voor EPSG:7000 (Amersfoort to ETRS89) & EPSG:7001 (ETRS89 to
NAP height) door QGIS upstream worden toegevoegd, zullen deze alleen
beschikbaar zijn in srs-template.db op basis waarvan de srs.db wordt
aangemaakt. Net zoals bijvoorbeeld EPSG:900913 wel in srs-template.db
staat maar niet in srs.db omdat de EPSG ID niet in de GDAL CSVs voorkomt.

Zolang geen antieke versie PROJ.4 (<= 4.7.0) wordt gebruikt checkt
synccrs de projecties echter ook m.b.v. pj_init_plus() & pj_get_def(),
dus het ontbreken van de projecties in de GDAL CSVs hoeft bij nader
inzien geen blocker te zijn. Om ondersteuning voor de proj-rdnap package
aan QGIS toe te voegen zouden we waarschijnlijk kunnen volstaan met het
toevoegen van de twee records zoals gedefinieerd in /usr/share/proj/rdnap:

             srs_id = ?
        description = RDNAP with NTv2 and VDatum
 projection_acronym = sterea
  ellipsoid_acronym = bessel
         parameters = +proj=sterea +lat_0=52.15616055555555
+lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000
+ellps=bessel +nadgrids=rdtrans2008.gsb +geoidgrids=naptrans2008.gtx
+units=m +no_defs <>
               srid = ?
          auth_name = RDNAP
            auth_id = rdnap
             is_geo = ?
         deprecated = 0
           noupdate = 0

             srs_id = ?
        description = RD with NTv2 only
 projection_acronym = sterea
  ellipsoid_acronym = bessel
         parameters = +proj=sterea +lat_0=52.15616055555555
+lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000
+ellps=bessel +nadgrids=rdtrans2008.gsb +units=m +no_defs <>
               srid = ?
          auth_name = RDNAP
            auth_id = rd
             is_geo = ?
         deprecated = 0
           noupdate = 0

Zolang de rdnap configuratie en NTv2 bestanden zijn geinstalleerd (in
PROJ_LIB) zou crssync de projecties gedefinieerd in srs-template.db ook
over moeten nemen in srs.db.

> - voor OSGeo4W zou het betekenen dat we moeten zorgen dat jou package
> ook daarin wordt opgenomen

Voor de Windows gebruikers is dat wel wenselijk ja, gebruikers van
andere Linux distributies en macOS zijn dan aangewezen om de NTv2
bestanden op dezelfde wijze als Debian/Ubuntu in PROJ.4 te configureren
(dus met de 'rdnap' bestandsnaam en de <rdnap> & <rd> projectie IDs).

> Iets verder in de toekomst moeten we misschien dan toch eens gaan
> nadenken over wat Lennart voorstelde: ipv ALLEEN de projectie tonen als
> 'crs', een combinatie van projectie+transformatie. In dit geval dus:
> 28992_48?? (28992 projectie met 48?? transformatie).

Daar valt wat voor de zeggen. Waarschijnlijk is het verstandig de
betreffende upstreams (GDAL/GeoTIFF/PROJ.4/PostGIS) bij die discussie te
betrekken, gezien zij beter in de materie zitten.

> Idee?

Zeker.

> Groet,
> 
> Richard Duivenvoorde

Mvg,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1