[BUG]: stray dive-sites after parsing ssrf/xml

[Jan Mulder]

Did some analysis on my logbook (that I have stored as a local git repo, 
so not an ssrf/xml). I found approx. 10 dive sites that had 0 dives 
connected to it. They all seemed the result of misspelling of the dive 
site name, and correcting it later.

On 07-11-17 21:50, Lubomir I. Ivanov wrote:
> 
> in MapWidgetHelper::reloadMapLocations() we do not skip such and
> markers are added for them.
> judging from the Marble port that i did, we had the same behavior there.
> 
> also, not exactly sure how this ended up happening, but i need some
> decision making here:
> - should we discard these at the parsing stage?

Not sure about this one. When we make shure that we never save dive 
sites without dives attached to it (see below), there is no need to add 
any logic for this.

> - should we discard this at the saving stage?

The fix for this is easy, and it seems wise to implement this (I will 
create a PR for review). Why would we keep carrying around site data 
that is not related to any dive? Obviously, this introduces the issue 
that you cannot "clone" dive sites any more to attach your dives later 
to it, but I do not see that as a relevant use case, as it involves 
manual editing of the logbook storage (as we do not have true dive site 
management).

> - should the map widget *ignore* such dive sites that are not linked
> to dives and not create markers for them?

Also, not needed any more when we do not save them ...

> - should we leave this as is? but perhaps tell the MainTab to deselect
> the last dive, because at them moment clicking such a marker doesn't
> do that.

Well, I ended up with with bogus dive sites that I was unable to delete, 
so doing nothing seems not the right way.

--jan