| | 1 | [[PageOutline]] |
| | 2 | = Project ideas = |
| | 3 | |
| | 4 | This page collects ideas for possible student projects. |
| | 5 | |
| | 6 | == Dynamic retiling of arrays == |
| | 7 | * __Mentors__: dmisev |
| | 8 | * __Languages__: C/C++, a bit of parsing (Flex/Bison) |
| | 9 | * __Overview__: |
| | 10 | |
| | 11 | Multidimensional arrays in rasdaman are broken-down and stored as tiles (more info on [wiki:Tiling tiling]). At the moment the tiling is ''static'' and can be only specified when the data is initially inserted into rasdaman. Furthermore, the tiling is global to the array, i.e. it is not possible to tile one part of the array using one strategy, and another with a different strategy. |
| | 12 | |
| | 13 | The idea is to make tiling ''dynamic'', so that an array or even parts of the array can be re-tiled at any time with a different tiling strategy. This could be part of the UPDATE statement in rasql: |
| | 14 | {{{ |
| | 15 | update collName as c |
| | 16 | set c[domainToBeTiled] |
| | 17 | tiling ... |
| | 18 | }}} |
| | 19 | |
| | 20 | Once this is achieved, further enhancement would be to make the server self-aware of data access patterns. Rasdaman would keep statistics and learn what's the best tiling based on the queries that are typically run, and re-tile the data accordingly. |
| | 21 | |
| | 22 | __Ticket__: #312 |
| | 23 | |
| | 24 | == Web interface for loading geo-spatial data == |
| | 25 | * __Mentors__: dmisev, abeccati, pcampalani |
| | 26 | * __Languages__: Java, possibly some C/C++ |
| | 27 | * __Overview__: |
| | 28 | |
| | 29 | rasdaman is a domain-independed array DBMS, but via it's [wiki:PetascopeUserGuide petascope] component it becomes a geo-spatial server with support for various OGC standards -- WCS, WCPS, WCS-T. Currently data can be loaded into rasdaman in two ways: |
| | 30 | 1. By using the rasql language, e.g. via the rasql client tool. This does not provide support for inserting geo-spatial information, which needs to be done manually with SQL scripts. |
| | 31 | 2. By using [source:applications/rasgeo/README rasimport], a client tool based on GDAL which can extract geo-information from the input files and automatically insert it into petascope, along with the data into rasdaman. |
| | 32 | |
| | 33 | WCS-T (an OGC standard for updating coverages) is on the agenda for implementation in petascope. A prerequisite for WCS-T implementation is enabling petascope (a Java servlet) to insert coverages itself. There are two possibilities for achieving this: |
| | 34 | 1. Use native system calls to the rasimport command-line tool, which would be very hackish and potentially dangerous. |
| | 35 | 2. Implement it directly in petascope by using the Java bindings for GDAL, and provide a generic interface that can be used by WCS-T implementation or further clients. |
| | 36 | |
| | 37 | Further work would then include |
| | 38 | * Implementing WCS-T |
| | 39 | * Implementing a web application (an admin page in petascope), that allows to easily load data by selecting files and filling in metadata details (in case it's missing from the files themselves and GDAL can't figure it out). |
| | 40 | |
| | 41 | |
| | 42 | __Ticket__: #312, related ticket #292 |
| | 43 | |
| | 44 | == Overlays of Geometries == |
| | 45 | * __Mentors__: pcampalani, abeccati |
| | 46 | * __Languages__: Java, SQL |
| | 47 | * __Overview__: |
| | 48 | |
| | 49 | At the moment Petascope works with ''aligned'' coverages, i.e. coverages with axes parallel to the external CRS dimensions. Enabling rotations and curvilinear grid topologies will add computational burden on the domain2grid conversion. The task is to implement '''optimized''' algorithms to identify which cells are to be extracted. |
| | 50 | |
| | 51 | == (Web) Graphical query builder == |
| | 52 | * __Mentors__: hstamerjohanns, dmisev |
| | 53 | * __Languages__: HTML, !JavaScript, possibly JSP or PHP |
| | 54 | * __Overview__: |
| | 55 | |
| | 56 | New users typically have difficulties initially with writing ''WCPS'' or ''rasql'' queries. Such users would benefit a lot from a graphical user interface (preferably web-based) that allows them to build queries and extract information from the database without knowing much about the query languages. Some examples in the SQL world about such tools are: |
| | 57 | - http://www.activequerybuilder.com/ |
| | 58 | - http://www.ajaxquerybuilder.com/ |
| | 59 | - http://www.dbfacephp.com/query-builder/ |
| | 60 | - http://www.razorsql.com/features/sql_gui.html |
| | 61 | |
| | 62 | This could possibly be done by taking an existing open-source SQL builder, and adapting it to rasql/WCPS. |
| | 63 | |
| | 64 | == JDBC (or ODBC) driver for rasdaman == |
| | 65 | * __Mentors__: dmisev |
| | 66 | * __Languages__: Java or C/C++ |
| | 67 | * __Overview__: |
| | 68 | |
| | 69 | rasql is modeled closely by SQL, so it would not be too hard to implement either a [http://en.wikipedia.org/wiki/Java_Database_Connectivity JDBC] (java) or an [http://en.wikipedia.org/wiki/ODBC ODBC] (C) driver for rasdaman. These drivers specify common interfaces for accessing relational databases, and many applications have plugins for connecting to databases via JDBC/ODBC drivers, like Matlab, R, etc. This would enable such applications to access data stored in rasdaman. |
| | 70 | |
| | 71 | == !GeoServer and Rasdaman Integration == |
| | 72 | * __Mentors__: abeccati, pcampalani + discuss and work with !GeoServer community |
| | 73 | * __Languages__: Java |
| | 74 | * __Overview__: |
| | 75 | |
| | 76 | Establish prototype to demonstrate that [http://geoserver.org GeoServer] can exploit Rasdaman as a native raster data source |
| | 77 | |
| | 78 | == Refactor and complete regression tests == |
| | 79 | * __Mentors__: dmisev, jyu |
| | 80 | * __Languages__: Bash, possibly Python. Some C/C++ and Java for the unit tests. |
| | 81 | * __Overview__: |
| | 82 | |
| | 83 | A robust and extensive regression test suite is essential for building and maintaining stable software. Rasdaman has an [source:systemtest integration test framework] as well as various unit tests. Unfortunately they are rather incomplete and outdated, and should be improved in several aspects: |
| | 84 | * ''Usability'' - tests should be easy to run by both developers and users, with zero or minimal configuration required. Furthermore, test results should be easy to read and provide as much information as possible about the failing cases. |
| | 85 | * ''Portability'' - different platforms and systems must not affect the results of the tests. |
| | 86 | * ''Extensibility'' - adding new tests should be simple and straightforward, so that developers are not turned off from the idea of adding new tests. |
| | 87 | * ''Coverage'' - tests should cover as much functionality as possible. E.g. the tiling and indexes options are not tested at all. Many "unit" tests are legacy code and not regression tests. |
| | 88 | * ''Modularity'' - rasdaman is comprised of many different components: database server, web servers, clients (command-line, GUI, !JavaScript, ...), resolvers, etc. The test suite should therefore be modular and adaptive to the current environment setup. |
| | 89 | * ''Documentation'' - on how to run the tests and add new tests. |
