Compare commits

..

No commits in common. "2f908278138f8200bf39c6a72d4f3a3b9fee304d" and "bd9d6e35d0d2b4272f3bcab1b3cb04c146305af1" have entirely different histories.

5 changed files with 18 additions and 24 deletions

View File

@ -5,9 +5,7 @@ This is our project for the INF205: Resource-efficient programming course
- [x] Read .tif file into memory using gdal
- [ ] Run the marching squares algorithm and produce a "casemap"
- [ ] Use a lookuptable to produce a vector file from the "casemap"
## Dependencies
- GDAL
- OpenMP
## How to build:
```
mkdir build
@ -15,4 +13,4 @@ cd build
cmake -DCMAKE_BUILD_TYPE=Debug ..
cmake --build . --parallel
```
Then you can run `./contour-creator PATH/TO/HEIGTHMAP.TIF`
Then you can run `./contour-creator`

View File

@ -1,13 +1,7 @@
## Group: Trygve and Esther
# Functionality
Our program usees the marching squares algorithm to create a vector contour map from a raster heightmap.
The cli interface is `gdal_contour [OPTIONS] <src_filename> <dst_filename>` with these options:
```
-i <elevation intervall> Interval between contours
-f <format> Fileformat to output
```
# data structure and input/output
![](ER_diagram.svg)
# What problem will you be working on in your programming project?
We will be implementing a marching squares algorithm to produce a contour map from a heightmap image file.
# Responsibilities:
Esther will create the algorithm itself with multitreading. This will essentially be a function that takes a grid of pixels as input and returns a similar grid of cells.
Trygve will take care of reading in the tiff file into our own datastructure and creating a vector image from the output of the algorithm.
@ -15,3 +9,6 @@ Trygve will take care of reading in the tiff file into our own datastructure and
# How do you plan to make it easily verifiable that your objectives are reached?
We can compare against the `gdal_contour` cli program which is a implementation widely used in other software. We can compare speed, memory usage and the result itself.
Each step in our program also produces a output which we can be worked on and evaluated independently.
# ER diagram:
![](ER_diagram.svg)

BIN
documentation/plan.pdf Normal file

Binary file not shown.

Binary file not shown.

View File

@ -1,26 +1,25 @@
#include <stdexcept>
#include <gdal/gdal.h>
#include "gdal/gdal_priv.h"
#include <gdal/gdal_frmts.h>
#include <iostream>
#include <stdfloat>
#include "HeightMap.hh"
HeightMap::HeightMap(const char* filepath)
{
// Open the file with gdal:
// Open the file with some gdal nonsense:
const GDALAccess eAccess = GA_ReadOnly;
GDALDatasetUniquePtr file;
GDALRegister_GTiff();
GDALAllRegister();
file = GDALDatasetUniquePtr(GDALDataset::FromHandle(GDALOpen( filepath, eAccess )));
if( !file )
{
throw std::runtime_error("Could not open tif file!");
std::cout << "Could not open tiff file!"; // handle error
}
// The heigthmap only has one band
auto band = file->GetBands()[0];
// write the attrributes
this->width = band->GetXSize();
this->height = band->GetYSize();
@ -28,10 +27,10 @@ HeightMap::HeightMap(const char* filepath)
this->max = band-> GetMaximum();
this->data = (float *) CPLMalloc(sizeof(float)*width*height);
CPLErr error = band->RasterIO( GF_Read, 0, 0, width, height,
band->RasterIO( GF_Read, 0, 0, width, height,
this->data, width, height, GDT_Float32,
0, 0 );
if (error) { throw std::runtime_error("Could not read tif file!"); }
band->FlushCache();
}
float HeightMap::get_pixel(int x, int y)