Closed jidanni closed 2 months ago
Well I spent hours trying to convert this m.aqx.gz with no luck. So I give up.
Here is an example from your .agx config converted into Viking maps.xml:
</objects>
<object class="VikSlippyMapSource">
<property name="label">DMAPS LAYER</property>
<property name="url">https://landmaps.nlsc.gov.tw/S_Maps/wmts/DMAPS/default/EPSG:3857/%d/%d/%d</property>
<property name="copyright">©nlsc.gov.tw</property>
<property name="referer">https://maps.nlsc.gov.tw/</property>
<property name="id">289</property>
<property name="zoom-min">6</property>
<property name="zoom-max">20</property>
<property name="lat_min">20.0</property>
<property name="lat_max">30.0</property>
<property name="lon_min">110.0</property>
<property name="lon_max">130.0</property>
<property name="switch-xy">TRUE</property>
</object>
</objects>
Which works for me. You can probably refine the extents to be more precise, to prevent requests that won't get a useful response. The rest of the other maps are left as an exercise for the reader. :) HTH.
I think the confusion over the file-extension
property is the statement:
"If the tile source URL ends in something other than .png, then this parameter will need to match"
Which is a little misleading.
The download request URL is formed from the hostname and/or url parameters. But then the save to (and read from) local disk uses the file-extension property when the Cache Layout map setting is 'OSM'. The (old and now not the default) 'Viking' cache layout did not use any file extensions.
Since one specifies the full URL as a string - it has no concept of the file extension, the option of the file-extension is to aid in saving the file to disk in the cache layout with an appropriate extension.
When the source URL has no extension (like in this example case), then by default the ".png" will be used in the save/read to/from disk (even if the source is not actually a PNG type). The underlying image reader doesn't care about extensions and uses the internal binary image type of the file contents itself - the filename convention is more a guide for Human users.
So I think what the Help is trying to say - for consistency - if the tile source is not a PNG file - then to have correspondingly the same file name on disk, it is recommended to set the file-extension to the appropriate value. When there is no file extension in the URL, it will be saved with the file-extension value. i.e. If the tile source is JPG and the URLs end in '.jpg', you currently need to specify this file-extension, otherwise they will end up with the miss-leading filename .png extension.
I obviously need to work on my clarity!
Admittedly, it could use the URL string to find a file extension and reuse that automatically.
Hopefully this succinct update should be better:
"If the tile source URL ends in something other than .png, then this parameter will need to match." --> "If the tile source is not a PNG file, then this parameter can be used to specify the naming to have consistent extension filenames on disk."
Man page says
OK, but do mention there what if there is no extension. E.g., the tiles URLs are just ...444/2314/43 with no trailing .something.