Project

General

Profile

Actions

Feature #2158

closed

Georeferencing files for multiple places (overlay)

Added by Roland Filzwieser 3 months ago. Updated 17 days ago.

Status:
Closed
Priority:
Normal
Category:
Maps
Target version:
Start date:
2024-01-17
Estimated time:

Description

When a file/map is linked to a place and georeferenced, using overlay, this positioning is not transferred if the same map is linked to another place. The georeferencing has to be done again. This is very time consuming if a map shows multiple places (example: https://thanados.openatlas.eu/entity/217872), yet the positioning of a map should not change in regard to different places. Thus, if possible, it would be helpful if the georeferencing could be transferred to each new connection with another place.

Actions #1

Updated by Alexander Watzinger 3 months ago

  • Category set to Maps
  • Status changed from New to Acknowledged
  • Target version set to 8.4.0

Thank you for reporting. We will have to look into this in detail but it really sounds like a very useful workflow improvement.

Actions #2

Updated by Bernhard Koschiček-Krombholz about 1 month ago

Since a georeferenced image should always use the same coordinates, maybe it is better to store somehow the coordinates directly linked to the image, and each entity which is linked to that image uses automatically the coordinates. For entities without map, this wouldn't change anything, and for entities with map it is most likely the wanting behavior.

Actions #3

Updated by Roland Filzwieser about 1 month ago

Yes, the possibility to use GeoTIFFs (https://www.ogc.org/standard/geotiff/) might be a partial solution. However, from former conversations with Stefan I recall, that that might be difficult to do, also, already uploaded images would still face this problem. Or do you already have a solution in mind?

Actions #4

Updated by Alexander Watzinger about 1 month ago

Overlay data is stored in database table web.map_overlay with values:
  • image_id
  • place_id
  • link_id
  • bounding_box

We could remove place_id and link_id to make this information independent from a place and also make image_id unique just to be save.
Regarding existing data, because image_id should now be unique but there might be already multiple entries (for different places) I would suggest to just take the first entry and delete all others because they should be the same anyway.

With this solution there would be no additional work for users, no information would be lost (places and images are still linked via the model) but following implementation steps are necessary:
  • Write an SQL update script for web.map_overlay
    • Remove place_id and link_id
    • Delete multiple image_id (keep one)
    • Make image_id unique
  • Adapt views to use overlay if overlay data is available (and is enabled in profile)
  • Adapt links and views to set/change overlay data (place_id is still needed for navigation to redirect back to the place view)
Actions #5

Updated by Bernhard Koschiček-Krombholz about 1 month ago

Sorry, I didn't mean in the image, because reading GeoTIFFs would be another big feature. Yesterday I had no further time to explain it.

Let me explain it in a workflow. Currently, we are doing this:
  • Link image 1 to place 1
  • Set overlay coordinates at place 1
  • Link image 1 to place 2
  • Set overlay coordinates at place 2
  • Link image 1 to place 3
  • Set overlay coordinates at place 3
If we remodel it, the workflow can look like this:
  • Link image 1 to place 1
  • Set overlay coordinates at place 1
  • Link image 1 to place 2 (image 1 automatically an overlay)
  • Link image 1 to place 3 (image 1 automatically an overlay)
Or we set the coordinates at the image detail view:
  • Upload image 1
  • At image detail view, click a button "Set coordinates"
  • Set coordinates
  • Link image 1 to place 1 (image 1 automatically an overlay)
  • Link image 1 to place 2 (image 1 automatically an overlay)
  • Link image 1 to place 3 (image 1 automatically an overlay)

In the database, we can drop the columns place_id and link_id from web.map_overlay, since the link is enough.

Actions #6

Updated by Alexander Watzinger about 1 month ago

Yes, I missed that we can drop the link_id too (I edited my former comment accordingly) but would argue to leave the view location as is (your first approach).
It would be less rewriting, users are already familiar with this workflow and I think it is more accessible/needed at the place view anyway.

Actions #7

Updated by Bernhard Koschiček-Krombholz 25 days ago

  • Status changed from Acknowledged to In Progress
  • Assignee set to Bernhard Koschiček-Krombholz

I'm currently working on it and it looks promising.
Since all duplicated entries will be deleted, we checked your data and it looks good. Only one file has an issue, that the coordinates are not the same for all the linked places:
https://thanados.openatlas.eu/entity/198570
@Roland Filzwieser can you resolve this issue?

SQL to detect duplicate entries with different coordinates:

 SELECT a.image_id, a.bounding_box FROM web.map_overlay a WHERE (
    SELECT count(*) FROM web.map_overlay b WHERE a.image_id = b.image_id and a.bounding_box != b.bounding_box
 ) > 1

Actions #8

Updated by Bernhard Koschiček-Krombholz 25 days ago

  • Status changed from In Progress to Closed
Actions #9

Updated by Alexander Watzinger 24 days ago

  • Subject changed from Georeferencing/Overlay same File multiple Places to Georeferencing files for multiple places (overlay)
Actions #10

Updated by Roland Filzwieser 24 days ago

Bernhard Koschiček-Krombholz wrote in #note-7:

I'm currently working on it and it looks promising.
Since all duplicated entries will be deleted, we checked your data and it looks good. Only one file has an issue, that the coordinates are not the same for all the linked places:
https://thanados.openatlas.eu/entity/198570
@Roland Filzwieser can you resolve this issue?

SQL to detect duplicate entries with different coordinates:
[...]

It should be resolved. All four linked places had basically the same coordinates, only one had more decimal places than the others. An excellent example for a possible issue with this, that is now resolved ;)

Actions #11

Updated by Bernhard Koschiček-Krombholz 24 days ago

That is nice, thank you.
I will update Thanados next week. Because it involves a database upgrade, I need to approve, that everything will be fine with your presentation sites.

Actions #12

Updated by Bernhard Koschiček-Krombholz 17 days ago

Thanados is updated.

Actions

Also available in: Atom PDF