Integrate tile2net task
#91
Conversation
web/src/layers.ts
Outdated
| const colormapRange = options?.colormap?.range || defaultStyle?.data_range; | ||
| const nodataValue = options.nodata || defaultStyle?.transparency_threshold; | ||
|
|
||
| const tileParams: Record<string, string> = { | ||
| projection: "EPSG:3857", | ||
| band: "1", | ||
| // band: "1", |
There was a problem hiding this comment.
What should be done with this?
There was a problem hiding this comment.
Thanks for pointing this out. I had commented this out for the (now default) case of using no colormap for a raster, and I didn't test out the colormap functionality. We do need this argument when applying a colormap, so I added this back in for the colormap case in 5511b25.
| @@ -48,6 +48,7 @@ def add_styling(geojson_data, style_options): | |||
|
|
|||
| def create_raster_map_layer(file_item, style_options): | |||
There was a problem hiding this comment.
This function is now very large, with lots of code nested under context managers, try/catch, etc. I think this should be split up a bit.
There was a problem hiding this comment.
Gotcha, I split this function in f493c8d
uvdat/core/tasks/map_layers.py
Outdated
| new_map_layer.cloud_optimized_geotiff.save( | ||
| cog_raster_path, ContentFile(cog_raster_file.read()) | ||
| try: | ||
| source = large_image.open(raw_data_path) |
There was a problem hiding this comment.
I think this function could use some comments as well. It's not really clear to someone reading the code, what the intent of these code blocks are.
There was a problem hiding this comment.
Good idea, I added comments in f493c8d
There was a problem hiding this comment.
Where is this file invoked? I don't see it used anywhere.
There was a problem hiding this comment.
You're right, I don't invoke this code anywhere. This is a script that I invoked manually to composite separate raster files into one before using the output file for ingest. I want to keep this code somewhere, though, in case we want to incorporate it into the ingest process more formally later. But that will be dependent on our modelling decisions relating to composite rasters.
This PR adds an orthoimagery (3.6 GB raster) dataset to the Boston floods use case and adds a new simulation type which runs
tile2neton a selected imagery dataset. The "Segment Curbs" task downloads tiles of raster data in a format expected bytile2netand then runs thetile2netgenerateandinferencefunctions. The output files generated by the inference step are then interpreted as new Datasets to add to the current project.The newly-created vector datasets are sent through our existing vector conversion process and are made available to view on the map. The first Dataset is the "polygons" generated by the inference, which represent the segmentation of curbs, crosswalks, and other walkable paths in the imagery. The second Dataset is the "network" generated by the inference, which is a processed version of the "polygons" set, consisting of semi-connected line segments. An avenue for future work would be to interpret the "network" set into our own
Networkrepresentation. However, due to the nature of walkable urban systems, the resultingNetworkwould be very disconnected and not viable for meaningful GCC analysis.Results
Clifton Park set got poor results, took 2 mins for a 144 MB file (not trained for this area, not very walkable)
Boston set got good results, took 2 hours 10 mins for 3.6 GB file (trained for this area, semi-walkable)
Capitol Hill set got fair results, took 8 mins for a 1 GB file (trained for this area, highly walkable park)
