[fixed] Suggested data for the Netherlands and some feature requests

[Jochem]

The government of the Netherlands supplies a lot of geo-information as open data, mainly via the website http://pdok.nl/. I created AQX files for the most interesting maps: Topographic maps in different styles, digital elevation models, aerial imagery, cadastral and administrative borders, hiking and cycling paths:
http://jochem.lesparre-dewaal.nl/download/aqx/PDOK.aqx
and historic topographic maps:
http://jochem.lesparre-dewaal.nl/downlo ... jdreis.aqx
I shared these AQX files with other people and a dozen of them are now happily using All-in-one OfflineMaps or AlpineQuest too. It would be nice to add these maps to the community maps in the app, so other people can easily access them too.

While preparing these AQX files, I got a some ideas for small improvements in the app:

• If available, I added a link to the map legend in the description of a map layer. However, this is not so easily accessible in the app: one has open the the list of maps, tap the dots of a layer and choose "Details" before the link is visible. Moreover, these have to be downloaded manually to be available offline. Would it be an idea to add a new feature to store and access map legends in the app?
• Some of the maps of the Netherlands are only available in the national CRS (EPSG:28992). Unfortunately, maps in this CRS have an alignment error of approximately 10 metres in the app, just a bit too large for the most detailed data: the offset with the other layers is visible. The tiles supplied by the government services are correct (I checked this), so I suspect the transformation or projection of this CRS is not handled precise enough in the app.
• One of the data sets is a WMS for a very detailed hill-shade with dynamic contrast. The dynamic contrast causes annoying contrast differences between tiles. Is there a possibility to make the app to get a map for the entire screen instead of in several tiles? That would solve the problem for online use, but I'm not sure how to make this work for offline use too.

Thanks for the nice app,
Jochem

[Psyberia-Support]

Hi and thank you for your support,
Sorry for the delay.

Thank you for sharing the AQX file.

Concerning your suggestions:
- For the map legend, I agree with you, it's not very visible and convenient to use right now. I haven't been able yet to find a place where it's more visible but not too much for users that don't care about it.
Also it would be great if it could be stored locally, I'll try to do this when possible.
- For the EPSG:28992 maps misalignment, I honestly don't think it's due to the CRS handling in the application (but nothing is sure of course). Those CRS are tested with multiple unit tests and have results with a decimetre accuracy. I would say it's due to the computations of the variable in the AQX file that matches tiles with coordinates.
In order to check this, I've imported the maps using my personal script and all the maps seems correctly aligned, even those with CRS EPSG:28992.
You can have a look at it here:

geodata.nationaalgeoregister.nl.aqx

(50.91 KiB) Downloaded 793 times

For information, I've update very recently the help page on expressions in AQX files.
- An equivalent to get an image of the entire screen would be to use larger tiles, like 1024x1024 pixels instead of the default 256x256 pixel. Each tile would then cover a larger area the size of a screen. But unfortunately there is no way to make the app refresh the entire screen when you move the map.

[Jochem]

Thanks for your response and sorry that I did not reply sooner. Your answer on my 1st and 3rd suggestion were very clear. Your answer on my 2nd suggestion required a bit more research, so I left the subject for some time and only recently took it up again.

I created an AQX file to demonstrate the misalignement:

misalignment.aqx

(5.1 KiB) Downloaded 578 times

However, the problem can be shown also by just displaying the screen center coordinates and comparing these with coordinate transformation software:

misalignment.jpg

(143.05 KiB) Not downloaded yet

• Screen center coordinates in "Lat/Long (Deg)" WGS84:
  53.435799°N, 6.882173°E
• Transformation with All-in-one OfflineMaps of screen center coordinates from "Lat/Long (Deg)" WGS84 at date 2022-09-17 to secondary location format "Amersfoort / RD New" EPSG:28992 · Amersfoort · meter:
  254360 m, 606540 m
• Standard transformation with PROJ.org and EPSG.org from "WGS84 datum ensemble" (EPSG:4326) at any epoch to "Amersfoort / RD New" (EPSG:28992):
  254352.6 m, 606537.1 m
• Precise time-dependent transformation with PROJ.org and EPSG.org from "WGS84-G2139" (EPSG:9754) at epoch 2022.7 to "Amersfoort / RD New" (EPSG:28992):
  254352.1 m, 606536.5 m

Note that there is no misalignment in the centre of the Netherlands, but the difference grows when moving away from the centre of the country, up to about 8 metres in the far northeast.

[Psyberia-Support]

Hi again,
Thanks for the additional information.
I'll investigate and let you know soon.

[Jochem]

If you need help with getting the coordinate transformation of the Netherlands right, I can help. Making (and using:) AQX files for geo-information of Dutch government agencies is a hobby project in my free time, but when I am working I am one of the experts at NSGI.nl responsible for the definition of the Dutch coordinate reference systems. Do you use the PROJ.org library and/or EPSG.org database? If so, what versions? It suspect the problem is not in the datum transformation (if so it would be in the scale factor), but in the oblique stereographic projection. You can send an email to rd@kadaster.nl for help with the analysis of the problem.

[Psyberia-Support]

Thanks a lot.
Yes absolutely I also think it's the projection, and not the datum transformation.
The application currently uses the P. Snyder version of the oblique stereographic projection, and I've seen that the USGS version results differ a little bit.

An alternative approach is given by Snyder, where, instead of defining a single conformal sphere at the origin point, the conformal latitude at each point on the ellipsoid is computed. The conformal longitude
is then always equivalent to the geodetic longitude. This approach is a valid alternative to that given here, but gives slightly different results away from the origin point. The USGS formula is therefore considered
by EPSG to be a different coordinate operation method to that described here.

(EPSG Guidance, Coordinate Conversions and Transformations including Formulas, October 2004)

So I'll also add the USGS version and compare the results. This is why I need a little more time, sorry about that.
The application uses its own library, and for this CRS I use the postgis PVT conversion parameters.

[Jochem]

Here you can find an ascii dataset with points to test the transformation and projection of the national CRS of the Netherlands (RD with NAP height). The test points are for ETRS89, but the accuracy is under 1 metre for the most recent WGS84 realisation at current epoch. The first 7500 test points are within the bounding box of the Netherlands and its EEZ. https://www.nsgi.nl/geodetische-infrast ... fvalidatie

[Psyberia-Support]

Hi,
I've released beta version 2.3.3.r7950 with improved accuracy for the Netherlands coordinate systems. You can get beta versions of the app from the Play Store.
I've imported both versions of the test file (ETRS and RD) and the points now perfectly match.
This will be available in the next official release.

[Jochem]

Thanks! How do I find the beta release in the Play Store? I don't see it.

[Psyberia-Support]

You have to go in the app page in the Play Store app, then click on "Enroll beta program", and the Play Store will show you beta versions just like regular versions.

[Jochem]

Now that this issue is fixed, do you considder to add (some of) the maps from the AQX files I made to the "community maps" in the app?
Links to updated versions:
- http://jochem.lesparre-dewaal.nl/download/aqx/PDOK.aqx
- http://jochem.lesparre-dewaal.nl/downlo ... jdreis.aqx

I think you should at least add the topographic map (BRT in classic and/or background visualisation), since the map from opentopo.nl that is now listed for the Netherlands in the community maps will stop being a free service on 31 December 2022 (source: https://geoforum.nl/t/uitfasering-opent ... -pdok/7303 in Dutch).

[Psyberia-Support]

Hi Jochem,
Yes absolutely, I'll have a look asap!

[Psyberia-Support]

The PDOK maps are now available.

[suntalla]

Dag Jochem,
Mocht je ooit tijd, zin en puf hebben,
de waterkaarten van Zeeland, rest van Nederland, Friesland voor Alpine Quest zou geweldig zijn.
Géén idee of die kaarten geschikt gemaakt kunnen worden voor A.Q. Zijn wel gratis toegankelijk denk ik.
Vriendelijke groet
Jos

[Jochem]

Mocht je ooit tijd, zin en puf hebben, de waterkaarten van Zeeland, rest van Nederland, Friesland voor Alpine Quest zou geweldig zijn.

Als je een internetadres van een viewer met deze kaarten hebt, dan kan ik wel een keer kijken of dat lukt.

Groeten, Jochem