a WMTS questions

Started by inu, November 25, 2019, 07:31:04 PM

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

inu

Hi,

Some questions regarding the OruxMap's WMTS abilities

1. Implementation.
According to the OGC standard specification, WMTS is carried out using just three abstract requests: GetCapabilities, GetTile, and (optionally) GetFeatureInfo. However, in order to support different distributed computing platforms, each of that operation can be implemented using different standardized "encodings". Currently, the standard defines the KVP encoding, the SOAP encoding, and the resource-oriented encoding. Moreover, for certain encodings (e.g. KVP), when the service is carried out over the http protocol, a client can use either GET or POST HTTP message to request the information from a server. Perhaps a future standard versions will define even more varieties to satisfy more stakeholders within the committee. Unfortunately, the document does not specify any kind of basic common profile to ensure interoperability. It's up to developers which encodings to implement. We hardy can expect from a mobile client to support all the encodings as doing so will result in considerable overcoding. I presume an interoperability issues are quite possible when a client and a server (both correctly labeled as "WMTS-compliant") are unable to interwork because of encoding difference. If that's the case, the user have nothing to do and I presume the best strategy would be to stop wasting the time by trying to connect to incompatible server. For a server, it's easy to find out which encodings are supported by looking into the capabilities xml document the server does advertise. For a client (such as OruxMaps), it's not so easy and a little help from the developers would be appreciated. Please clarify which exactly WMTS technologies OruxMaps does implement.

2. Configuration.
To view an on-line map, user first have to configure OruxMap accordingly for particular server. For WMS servers, the user's manual discusses two configuration methods. With the first method, the configuration can be done using related menu items when the app is running and internet access is available (let's call it the on-line method). With the second method, the user can specify all the necessary configuration parameters in a text file (e.g. wms_services.xml). When the app is started, it takes that file into account. That method does not mandate net access so let's call it the off-line method. As for WMTS, there is not a single word about that in the user's manual. Fortunately, related information is provided in the blog section. According to that information, access to a WMTS server can be configured using the on-line method. How about the off-line method? Does OruxMap recognize respective configuration file (wmts_services.xml or something like this)?

3. Troubleshooting
Looks like the OGC standards are a recent development so the implementations are far from being stable. For some services, a technicians are working hard perfecting the things so changes there happens almost weekly. So the users are forced to update the client's configuration frequently. Otherwise, the app displays an error message with high level description for the problem. I wonder if OruxMaps supports a log file of some king allowing users to find out what exactly went wrong?

Thanks in advance

orux

Hello!
OruxMaps is not a full WMTS or WMS viewer. It only implements a small fraction of those standards. The minimums so that a majority of the maps currently offered are visible.

The standards that define WMTS are very broad and there are no good libraries that implement them, at least on Android.

The support given to that standard in OruxMaps is very basic. The most common formats are supported. As a user detects a problem or a specification that may be useful, I implement it.

The wms_services.xml file was the first attempt to support WMS maps years ago, looking for the basic attributes of all WMS. Today I keep it for compatibility.

I included the WMTS format later, so I no longer included a complex procedure for normal users, such as the xml format.

Many WMTS (those that support the projection of google, which are the majority) can be configured in the file onlinemapsources.xml, such as those of the Spanish IGN
<onlinemapsource uid="514">
   <name>Mapa Base IGN (ES)</name>
   <url><![CDATA[http://www.ign.es/wmts/ign-base?request=getTile&layer=IGNBaseTodo&TileMatrixSet=GoogleMapsCompatible&TileMatrix={$z}&TileCol={$x}&TileRow={$y}&format=image/jpeg]]></url>
   <website><![CDATA[<a href="https://www.cnig.es/" target="_blank">Instituto Geográfico Nacional (ES)</a>]]></website>
   <minzoom>1</minzoom>
   <maxzoom>19</maxzoom>
   <projection>MERCATORESFERICA</projection>
   <servers></servers>
   <httpparam name="User-Agent">{om}</httpparam>
   <cacheable>1</cacheable>
   <downloadable>1</downloadable>
   <maxtilesday>0</maxtilesday>
   <maxthreads>0</maxthreads>
   <xop></xop>
   <yop></yop>
   <zop></zop>
   <qop></qop>
   <sop></sop>
</onlinemapsource>

All I can tell you is that, if you need a full WMTS viewer, you should search for another tool.

When you configure a WMTS map, the error message is shown in the display to help users send to me a  screen capture, and try to solve that problem, but no file log is saved.


orux

inu

Hi Orux,

Thanks a lot for the info. So, regarding WMS/WMTS, the conclusion is that OruxMaps support only the KVP encoding, right? Beside, in current and future app versions, the preferred method for advanced configuration is by using the onlinemapsources.xml file. Understood.

As for compatibility, thanks again for mentioning it. It matters a lot. Every shiny thing is declared obsolete in a couple of year so from the user's perspective the backward compatibility is a really big deal. For instance, I have an Android 4.0.4 tablet (GT-P6810 to be precise). OruxMaps works perfectly on this device and occasional connection problems are caused not by the app, but by the platform itself. More and more servers today are optimized by removed support of an obsolete protocols for security reason. When OruxMaps is trying to connect to such server, an error message is displayed for a moment saying that hello handshake has aborted because of the problem in the SSL library, etc., etc. Indeed Android 4.0.4 does not support TLS versions greater than 1.0 so it's not possible to establish a secure connection to a server that does not support TLS 1.0 any more. But I've noticed that on the same device, Google Chrome browser is able to connect to that sever with no problem. Actually, it supports up to TLS 1.2. I've no idea how do they do it. Maybe Chrome just uses its local copy of the TLS stuff. After all, Chrome is also from Google. But according to the Android developer documentation, in some cases, easy workaround for the problem can be done programmatically:

https://developer.android.com/training/articles/security-gms-provider

Anyway it's not about how to bring more features but perhaps that's the way to make your great app even more greatest. What do you think?

---
regards,
inu

orux

Quote from: inu on November 26, 2019, 04:30:01 PM
Hi Orux,

Thanks a lot for the info. So, regarding WMS/WMTS, the conclusion is that OruxMaps support only the KVP encoding, right? Beside, in current and future app versions, the preferred method for advanced configuration is by using the onlinemapsources.xml file. Understood.
Yes, KVP is the common way.
The onlinemapsources.xml file is only for googlemaps projection maps.WMS can be configured in old way (wms_services.xml) or using the wizard.WMTS using the onlinemapsources.xml if GoogleMaps projection compatible, or using the wizard.

QuoteAs for compatibility, thanks again for mentioning it. It matters a lot. Every shiny thing is declared obsolete in a couple of year so from the user's perspective the backward compatibility is a really big deal. For instance, I have an Android 4.0.4 tablet (GT-P6810 to be precise). OruxMaps works perfectly on this device and occasional connection problems are caused not by the app, but by the platform itself. More and more servers today are optimized by removed support of an obsolete protocols for security reason. When OruxMaps is trying to connect to such server, an error message is displayed for a moment saying that hello handshake has aborted because of the problem in the SSL library, etc., etc. Indeed Android 4.0.4 does not support TLS versions greater than 1.0 so it's not possible to establish a secure connection to a server that does not support TLS 1.0 any more. But I've noticed that on the same device, Google Chrome browser is able to connect to that sever with no problem. Actually, it supports up to TLS 1.2. I've no idea how do they do it. Maybe Chrome just uses its local copy of the TLS stuff. After all, Chrome is also from Google. But according to the Android developer documentation, in some cases, easy workaround for the problem can be done programmatically:

https://developer.android.com/training/articles/security-gms-provider

Anyway it's not about how to bring more features but perhaps that's the way to make your great app even more greatest. What do you think?

---
regards,
inu
Chrome probably does not use Android libraries, it is very typical of Google :) Surely it uses other embedded.

The problem is that, as of the following update of OruxMaps, it is only supported on Android 4.1 or higher. For this and many other things, the effort to maintain compatibility with older Android versions becomes unfeasible.

orux

inu

Hi Orux,

It's all right. The good thing is the necessary information is provided. No matter it's spread on the bit-by-bit basis over various places like forum posts, blogs, etc. rather than being captured by one reference manual. And yes, it's not practical to support everything forever for free. AFAIK, a full-blown support for TLS 1.2 (suggested minimum for today) was implemented by Google starting from Android 5. Earlier versions required special attention in that regard from manufacturers, developers or both and the consistency is still not there. So the mentioned workaround technique (using the google play services api) seems applicable to Android 4.1 as well. Just thoughts...

---
regards,
inu