Summary: | dgml is missing an option center the map (lonlat) [patch] | ||
---|---|---|---|
Product: | [Applications] marble | Reporter: | boris.sh.1983+kde.bugzilla |
Component: | general | Assignee: | marble-bugs |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | CC: | rahn |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | All | ||
Latest Commit: | https://invent.kde.org/education/marble/commit/a4aa19db604e1c233982b20e1ab886df76839094 | Version Fixed In: | |
Sentry Crash Report: | |||
Attachments: | [PATCH] lonlat from dgml |
Description
boris.sh.1983+kde.bugzilla
2016-01-30 16:36:22 UTC
Created attachment 96928 [details]
[PATCH] lonlat from dgml
Sorry, this nice patch got completely "drowned" and remained undiscovered in our bug database. A better place for submission would have been Gitlab at https://invent.kde.org/education/marble/-/merge_requests Thanks for the contribution - this is indeed a feature that I had planned since long to get implemented. I will review this and will add this (likely with modifications) to our codebase. Thanks a lot! My need for this patch arises from the usecase of creating WMS-based dgml-themes. Many WMS services just cover a particular geodetic bounding box (and many are only meant as an overlay to be used for "groundlayers"). Now there are two issues in this context which I currently consider: - Ideally instead of "centerOn" I'd like to rather see "setViewLatLon(Alt)Box()" which would also steer the zoomlevel to ensure that a particular region gets centered and fully displayed. The case where the map should only be centered could be accomplished by using the same API with a boundingbox that has no size (and is a point). - In the implementation of the patch the centering is done whenever the map theme changes if the map theme specifies a center-point. I'm not sure whether this is a good approach. During application startup we have the option to either center on the "home position" or to recall zoom level and center point last time when Marble was quit. Also we usually don't change the view when a map theme is changed. I see several other usecases where one might want a different behavior: - The centerOn/setViewLatLonAltBox would only get applied the first time the map theme gets invoked (however that is impossible to detect at the moment). - The centerOn/setViewLatLonAltBox would only get applied if the current point that Marble focuses on is not in the valid boundingbox specified for the map theme. - Or as this patch does we always enforce centerOn/setViewLatLonAltBox whenever the map theme is invoked. Of course we could add an option that would override this behavior (globally or restricted to this map theme) but that would make things increasingly complex. Tough choice :-) Another finding: Marble already has void MarbleAbstractPresenter::centerOn(const GeoDataLatLonBox &box, bool animated) implemented which is available in MarbleWidget and which tries to approximate the setViewLatLon(Alt)Box() behavior mentioned before. The implementation of this method is not ideal (see https://bugs.kde.org/show_bug.cgi?id=461569) but should work well enough for a start. Git commit a4aa19db604e1c233982b20e1ab886df76839094 by Torsten Rahn. Committed on 24/04/2023 at 11:55. Pushed by rahn into branch 'master'. Patch by Boris Shhtrasman: - dgml is missing an option center the map (lonlat) In order to integrate this with MapWizard's WMS support I changed the behavior by - centering on the geodetic boundingbox instead of a geodetic point - only center when the map theme is changed if the current view points outside the boundingbox of the map theme. M +35 -0 src/apps/marble-kde/KdeMainWindow.cpp M +1 -0 src/apps/marble-kde/KdeMainWindow.h M +35 -1 src/apps/marble-qt/QtMainWindow.cpp M +1 -0 src/apps/marble-qt/QtMainWindow.h M +12 -0 src/lib/marble/MapWizard.cpp M +36 -0 src/lib/marble/OwsServiceManager.cpp M +1 -0 src/lib/marble/OwsServiceManager.h M +2 -0 src/lib/marble/geodata/CMakeLists.txt M +1 -1 src/lib/marble/geodata/data/GeoDataCoordinates.h M +1 -0 src/lib/marble/geodata/handlers/dgml/DgmlElementDictionary.cpp M +1 -0 src/lib/marble/geodata/handlers/dgml/DgmlElementDictionary.h M +31 -0 src/lib/marble/geodata/scene/GeoSceneMap.cpp M +12 -1 src/lib/marble/geodata/scene/GeoSceneMap.h M +16 -1 src/lib/marble/geodata/writers/dgml/DgmlMapTagWriter.cpp https://invent.kde.org/education/marble/commit/a4aa19db604e1c233982b20e1ab886df76839094 Hello Boris, sorry, but for the lack of your realname I had looked up your name on the Internet and copied your name over from https://kdepim-bugs.kde.narkive.com/9IhS4B3v/akonadi-bug-339393-new-akonadi-fail-to-fetch-imap-folder-content-with-over-100mib-of-messages where this typo was unfortunately included. Again sorry, and also sorry that this took so long. I had been basically on parental leave during the last few years (with a great wife and two marbleous kids). Your patch has made the WMS improvements that I'm looking into a whole lot more enjoyable. Thanks for that! :-) Thank you a lot, sorry for that link as well. I need to see how that had happened in the first place :)
On Tuesday, 25 April 2023 20:38:53 IDT Torsten Rahn wrote:
> https://bugs.kde.org/show_bug.cgi?id=358779
>
> --- Comment #6 from Torsten Rahn <rahn@kde.org> ---
> Hello Boris,
>
> sorry, but for the lack of your realname I had looked up your name on the
> Internet and copied your name over from
> https://kdepim-bugs.kde.narkive.com/9IhS4B3v/akonadi-bug-339393-new-akonadi-fail-to-fetch-imap-folder-content-with-over-100mib-of-messages
> where this typo was unfortunately included.
>
> Again sorry, and also sorry that this took so long. I had been basically on
> parental leave during the last few years (with a great wife and two marbleous
> kids).
>
> Your patch has made the WMS improvements that I'm looking into a whole lot more
> enjoyable. Thanks for that! :-)
>
>
|