the marble (map) replacement dilemma

[Lubomir I. Ivanov]

On 10 July 2017 at 17:29, Hartley Horwitz <hhrwtz at gmail.com> wrote:
>>
>> ---------- Forwarded message ----------
>> From: "Lubomir I. Ivanov" <neolit123 at gmail.com>
>> To: Subsurface Mailing List <subsurface at subsurface-divelog.org>
>> Cc:
>> Bcc:
>> Date: Mon, 10 Jul 2017 00:25:38 +0300
>> Subject: the marble (map) replacement dilemma
>>
>> .........
>> you can pick between Google Maps and Qt Location
>
>
> My pick is to use Google Maps and accept that access to the maps when
> offline isn't supported.  Obviously that only makes sense if Subsurface
> suppresses the viewport update to prevent the software from hanging or
> producing error messages.

in my current tests, if the internet drops, the google maps widget in
subsurface would not feedback any errors to the user frontend.
what happens is that it would cache the current zoom level and perhaps
some tiles form the neighbor zoom level, but if the user zooms out too
much the viewport just turns grey even if it has already cached the
tiles from that zoom level previously to disk.

we can potentially install a more user friendly error handling. for
instance - filling the google map widget with an overlay message
saying: "no internet connection" and once the internet is back (e.g.
via ICMP echo) the message can be hidden.

>
> The reason I lean towards Google maps is that I like to see the reefs using
> satellite images, and thus I'm already looking at Google to help set the
> dive location (if I don't have the exact GPS coordinates).

the Qt Location solution (see the animated GIF in first post) also has
satellite imagery. however, i would consider that imagery lower
quality than that of google maps.
(e.g. some tiles with drastically different colors are stitched
together at places)

> Actually sometimes I still use Google maps because I may have the coordinates in
> sexagesimal degrees coordinates and its easier to type in coordinates in
> decimal and google is an easy source for that translation.
>

i don't think we support sexagesimal coordinates yet, but we can
certainly add support for that.

lubomir
--