Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement context fusion #60

Draft
wants to merge 42 commits into
base: geo_upload
Choose a base branch
from
Draft

Implement context fusion #60

wants to merge 42 commits into from

Conversation

mtiessen1175
Copy link
Collaborator

@mtiessen1175 mtiessen1175 commented Sep 9, 2024

Refers to #45

The following data and metadata should be present in a suitable dataset for the context-fusion feature:

  • Mosaic and single image files
  • extent of mosaic (geo-referenced coordinates)
  • (at least one) geo-referenced coordinate of each single image
  • yaw/angle of the single images (defining their rotation within the mosaic)
  • pixel-to-unit ratio of mosaic AND images (preferred, but not a necessity atm since manual scaling is currently an option)

ToDo-list:

  • mechanism to update the layer upon changes (i.e. a changed opacity, currentImage, activeOverlay) without having to delete the context-layer, but rather setting the visibility true/false.
  • once a suitable dataset and WMS is available, the alignment of the wms resource and the image can be developed (i.e. shifting, rotating and scaling the tile-layer)
  • fix the tile-loading function. The issue: Tiles of a geoTIFF context-layer may disappear beneath the image although they are still in the viewport. I suspect this happens due to the rotation of the context-layer (using tileLayer.on('prerender',...). For instance, when the layer is rotated by 180°, and dragging the image downwards, tiles in the upper viewport disappear (so it seems the tile-loading function is not mirrored with the rotation).

Improvement list:

  • implement "automatic" scaling, given suitable data exists (i.e. pixel-to-unit-ratio's of both mosaic and image)

  • change the manual scaling method to reflect the scaling of the context-layer in the viewport. The current solution functions as follows: In the image annotation-view...

    1. ...press the Edit-scale button in menu-bar.
    2. ...move cursor over OL viewport.
    3. ...use mouse-scroll to adjust scale (the scaling factor will be shown as a number next to the Edit-button)

    Currently, the mousewheelzoom interaction gets deactivated when in Edit-mode (to not zoom in/out when adjusting scale). But this also hinders the scaling itself to be reflected on the OL-viewport.

  • possibly generalize the calculateExtent() method, as it is currently assumed that the reference point of the single image is the center of the image

For further details on the ToDo's, see also comments in settingsTabPlugin.vue

@mtiessen1175 mtiessen1175 linked an issue Sep 9, 2024 that may be closed by this pull request
5 tasks
this.overlays = biigle.$require('annotations.overlays');
// console.log('geoOverlays: ', this.overlays);
// console.log('activeId: ', this.settings);

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mzur,
I am a bit confused by all the imports between the biigle modules, which is why I pose this question:

In the geo-module I created a ContextLayerMixin for the annotationCanvas.vue of biigle/core.
In this mixin, I want to access a couple of variables from the annotation settings tab (i.e. the activeId or opacity of the geo-overlay settings, which are part of yet another plugin that is published from the geo-module to the settingsTab.vue in core).
In order to access these variables, do I have to make them available as properties in the annotationCanvas component (here) in biigle/core, or can I directly import them, for example the whole settings-variable from the settings-store?

The first option should work because the variables would be made accessible within the ContextLayerMixin, but it would require changes to the code in biigle/core, which doesn't seem right. Regarding the second option, I'm not sure how to make the settings-store variable available.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your point, there is no direct way to access the settings in an annotation canvas mixin. Maybe you can do it like the reports module. It does everything in the settings tab plugin by using the annotations.map.init and images.change events to hook up OpenLayers objects and update image data.

return tileLayer;
},
updateCurrentImage(id, image) {
this.currentImage = image;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mzur,
when metadata is provided for the volume, what is the currently implemented way to access the metadata for each image (i.e. the point geo-coordinate)?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The image model has the attributes lat and lng. Other metadata must be accessed via $image->metadata.

@mtiessen1175
Copy link
Collaborator Author

@mzur,
the latest commits entail the experimental context-layer feature with working localization and rotation mechanism (quality of the outcome is of course dependent on data quality). For the example mosaic dataset and corresponding metadata file, the results are reasonable okay!
However, the calculated pixel-to-unit ratio's for the example image dataset were not very useful, as they seem to be very off.

I'll forward you the example dataset + computed metadata-file for testing purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Geospatial context fusion display
2 participants