Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - inu

#1
GENERAL / Re: a WMTS questions
November 27, 2019, 04:10:57 PM
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
#2
GENERAL / Re: a WMTS questions
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.

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
#3
GENERAL / a WMTS questions
November 25, 2019, 07:31:04 PM
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