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

i.sentinel.mask: adapt for non-SQlite vector databases #540

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

griembauer
Copy link
Contributor

This PR adaps i.sentinel.mask such that it works in a mapset with a non-SQlite vector database connection. SQlite allows some simplifications of commands that are not possible in other systems (tested here with PostgreSQL):

  • when running v.db.addtable to also add new columns, the datatype of the column must be indicated
  • running v.db.droptable only works if the table exists in the database, it will otherwise throw an error. Because of this, a check is now implemented beforehand
  • running v.to.db already creates an appropriate column so it is not necessary to create the column with v.db.addcolumn beforehand.

@griembauer griembauer marked this pull request as draft June 9, 2021 06:47
@griembauer
Copy link
Contributor Author

Update: Please ignore for now, more adaptions to i.sentinel.mask are to come (performance improvement)

@ninsbl
Copy link
Member

ninsbl commented Jun 11, 2021

Hi, @griembauer
When you are looking for speed improvements, maybe you could have a look at #138 for a significant speed improvement of cloud shaddow detection in cases where one has a significant amount clouds that slow vector processing. Basically, the idea is to keep things in raster all the way and use r.region (which takes seconds) + r.stats instead of v.transform + v.overlap which both can take minutes... With few clouds, the vector approach may still be faster though. Since you need the mask as raster dataset further down the processing chain, staying in the raster world is probably an advantage for the next processing steps too...
Unfortunately, I have not found the time to implement that myself. So pleasee feel free to pick from there, if relevant for you...

@griembauer
Copy link
Contributor Author

Hi @ninsbl, Thanks a lot for the link, I wasn't aware of this PR honestly, but of course it makes much more sense to take it from there! (indeed staying in the raster world as long as possible is probably the best way to go)

@ninsbl
Copy link
Member

ninsbl commented Dec 28, 2023

Please see: #1002

Is this PR still needed then?

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.

None yet

2 participants