Close #LGVISIUM-101: Removed deprecated AWS Lambda script and removed the AWS Region from the environement variables

[dcleres]

After working together with Oliver from Geowerkstatt, we were able to find a setup that makes it possible to integrate the data extraction API into the borehole application. This mainly involved figuring out which environment variables AWS needed to connect to the right S3 bucket in the correct region.

As it is also very unlikely that we will deploy the API using AWS Lambda in the near future I removed the code to avoid any sort of confusion.

The README was also edited to only document the possibility of passing the AWS credentials as environment variables to the container, as this is how the container is used in production.

[github-actions]

Coverage Report

File	Stmts	Miss	Cover	Missing
src/stratigraphy
__init__.py	8	1	88%	11
extract.py	186	186	0%	3–483
get_files.py	19	19	0%	3–47
main.py	117	117	0%	3–308
src/stratigraphy/data_extractor
data_extractor.py	57	3	95%	33, 66, 103
src/stratigraphy/depthcolumn
boundarydepthcolumnvalidator.py	41	20	51%	47, 57, 60, 81–84, 110–128, 140–149
depthcolumn.py	194	64	67%	25, 29, 50, 56, 59–60, 84, 87, 94, 101, 109–110, 120, 137–153, 191, 228, 247–255, 266, 271, 278, 309, 314–321, 336–337, 380–422
depthcolumnentry.py	28	6	79%	17, 21, 36, 39, 56, 65
find_depth_columns.py	106	19	82%	42–43, 73, 86, 180–181, 225–245
src/stratigraphy/layer
layer_identifier_column.py	74	52	30%	16–17, 20, 28, 43, 47, 51, 59–63, 66, 74, 91–96, 99, 112, 125–126, 148–158, 172–199
src/stratigraphy/lines
geometric_line_utilities.py	86	2	98%	81, 131
line.py	51	4	92%	25, 50, 60, 110
linesquadtree.py	46	1	98%	75
src/stratigraphy/metadata
coordinate_extraction.py	108	5	95%	30, 64, 94–95, 107
src/stratigraphy/text
description_block_splitter.py	70	2	97%	24, 139
extract_text.py	29	3	90%	19, 53–54
find_description.py	64	28	56%	27–35, 50–63, 79–95, 172–175
textblock.py	80	9	89%	28, 56, 64, 89, 101, 124, 145, 154, 183
src/stratigraphy/util
dataclasses.py	32	3	91%	37–39
interval.py	104	55	47%	29–32, 37–40, 46, 52, 56, 66–68, 107–153, 174, 180–196
predictions.py	107	107	0%	3–282
util.py	39	17	56%	41, 69–76, 90–92, 116–117, 129–133
TOTAL	1652	723	56%

Tests	Skipped	Failures	Errors	Time
82	0 💤	0 ❌	0 🔥	6.162s ⏱️

[stijnvermeeren-swisstopo]

Could you clarify why we need both AWS_ENDPOINT and AWS_S3_BUCKET? Is there any use case where these might refer to different buckets? Or if they always refer to the same bucket, then why can't we always connect using the endpoint URL (which contains the bucket name, if I recall correctly)?

[dcleres]

Geowerkstatt is using this structure for its environment variables, so I need to comply with it. When we developed the code, we passed all the information into the AWS_ENDPOINT variable, but Oliver told me that they prefer to do it this way. I think that this indeed leaves you the flexibility to open several S3 buckets from the same AWS account by adapting the bucket name.

If you have a strong opinion about having everything in the AWS_ENDPOINT then I can ask Oliver whether it is possible for them to adapt their code.

[dcleres]

@stijnvermeeren-swisstopo I added the information provided by Oliver from Geowerkstatt to the README.

[dcleres]

Thank you for adapting the README. Overall, I think it makes sense to remove some information regarding the environment variables as this was taking quite some space in the README. The rationale behind having all this information was that even people who are not super experienced with the concept of environment variables can have a quick start. With some of the info removed, I think it is still feasible but requires a bit of research. That is fine for me. I will keep that in mind for future README edits