Skip to content

fix: splitter fails for local file catalog items#7762

Open
zoran995 wants to merge 1 commit intomainfrom
feat/local-data-compare-2
Open

fix: splitter fails for local file catalog items#7762
zoran995 wants to merge 1 commit intomainfrom
feat/local-data-compare-2

Conversation

@zoran995
Copy link
Collaborator

@zoran995 zoran995 commented Feb 13, 2026

What this PR does

Fixes #7757

Store local file data as blob URLs in the URL trait instead of private instance fields, and follow the same approach already used for GLTF and Assimp catalogue items. This ensures duplicateModel() preserves the data since traits are copied during duplication. One potential downside of this approach is that we are currently not disposing the catalogue items from memory on remove (here is a ticket to track that #4816)

Test me

How should reviewers test this? (Hint: If you want to provide a test catalog item, create a Gist of its catalog JSON, add its url and your branch name to this url: http://ci.terria.io/<branch name>/#clean&<raw url of your gist> , and then paste that in the body of this PR)

Checklist

  • There are unit tests to verify my changes are correct or unit tests aren't applicable (if so, write quick reason why unit tests don't exist)
  • I've updated relevant documentation in doc/.
  • I've updated CHANGES.md with what I changed.
  • I've provided instructions in the PR description on how to test this PR.

Store local file data as blob URLs in the url trait instead of private
instance fields. This ensures duplicateModel() preserves the data since
traits are copied during duplication.
@zoran995
Copy link
Collaborator Author

Deployment is failing due to the branch name

@zoran995
Copy link
Collaborator Author

This fixes the same bug as #7760, @ljowen, @na9da can you review and see which approach you think is better

@zoran995 zoran995 requested review from ljowen and na9da February 13, 2026 22:31
@na9da
Copy link
Collaborator

na9da commented Feb 15, 2026

Hi @zoran995 - both PRs look good to me.

One thing to check with this approach is whether it causes unnecessary duplication of memory because we are creating an object URL and then fetching from it again. My guess is the other strategy of keeping reference to the file might be slightly more memory efficient? You could use the devtools memory profiler to test the theory.

(here's a sizable geojson file for testing)

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.

Error on compare vector data

2 participants