- compare to [requirements](#requirement specification)
Analysing the [requirements](#requirement-specification) and comparing them to the finnished result the sucess is judged criticly:
- Maintain functionality of TMT tool: Or project
- Remove any special dependencies: In our OMT we do not have any major dependencies. There are some libraries like leaflet, which are used, but the big external tools, mainly OSMCha und mapbox are removed.
- Filter changesets by region: A bounding box or a more specific polygon can be defined and will refine the number of changeets displayed. Since a lot of data is checked this can take a little longer if many cahngesets need to be verified.
- Filter changesets by tags: Changesets can be filtered by tags by defining a key-value pair. It is also possible to filter by multiple tags at the same time.
- Filter changesets by nodes/ways: The new application is able to filter tags on the included objects of any changeset, which includes nodes, ways and relations. When multiple tags on a high number of changesets is filtered the process might take a moment.
- Filter by date: It works well to filter the changesets according to date.
- Track progress: Every changeset has a status assigned which can be used to monitor if it has not been looked at (open), is "in progress" or already finished.
- Responsive GUI: The user interface of the OMT is able to handle a wide range of display sizes. All contents are adapted responsivly. Only when the screen-area get too narrow (for example for smartphones) the application is no longer optimised and will at some point lose its elegance.
From the nice to have requriements a couple were implemented aswell:
- Introduce ranking: The Qrank system from IFS was integrated into the application to sort the changesets by their assigned priority.
- Predefined regions for observation: The application is not able to do this distinction.
- History slider: The application is not able to do this, but an external Page like OSM can be used to see history data.
- Add users + notifications: During the project this was determined not to be that great of a benefit and was therefor not implemented.
### Comparison
...
...
@@ -849,61 +864,37 @@ During the project we were able to minimise most of the risks, although some can
## Results and further development
The results of the project can be found in part I [results](#results) and the [software documentation](#software-documentation).
<!--
TODO: Kapitel nicht weglassen. Möglichkeiten der Weiterentwicklung: Funktionen und mögliches weiteres Vorgehen. Ist System gut erweiterbar == gutes design
TODO: Weiterentwicklung ist obligatorisch und erscheint in zwei separaten Kapitel (ggf. Dokument): Im Technischen Bericht, Unterkapitel Resultate/Ausblick, und in der SW-Projektdokumentation.
TODO: Weiterentwicklung in der SW-Projektdokumentation ist an Architekten / SW-Entwickler gerichtet wie jedes andere SW-Dokument.
-->
### Further development
As with every project there is always more work to be done. The following list of things would be options of what to approach next.
Some of the smaller improvements that could be done are the following:
- Show the last time the changesets were loaded. This would give the user an indication of how current his page is.
- Include the tags of deleted osm-elements. Since OSM does not retain them for deleted objects it would be necessary to analyse the history of the individual contained objects in order to regenerate its tags. However it would make the search for tags complete.
- Optimise the database queries. Especially if a lot of data has to be processed the requests on the database tend not to be that fast. By optimising the queries a little more some improvement might be possible.
- Add production settings to the application. Currently only development settings are available.
- Limit the map extract to Switzerland when the Satellite map is choosen. Because the gathered data for the areal view is only available for Switzerland.
- Add support for small devices like smartphones, even it the usage on such a small screen probably isn't that efficiant and most work will be done on a regular desktop machine.
- introduce regions for watching (i.e. currently switzerland) at the beginning of the project
- load correct data
- get correct map data (especially satalite)
- history slider (to see changes over time for objects in changeset)
- additional or more advanced filtering
- filtering the tags, introduce full-text searching
- introduce searching on filtered changesets
- imporove DB speed
- possibly find a new approach that would remove the high data volume in the database
- predefined shape boundaries
- internationalization
- two db's
Besides the smaller improvements, there are some additional features that would extend the application nicely:
- as mentioned in the comparison to the requirements adding users is not a major factor at the moment, but would certainly open the door for some interesting further possibilities. A login via OAuth with an OSM account would be the ideal
- The exact last working state could be retained and returned to the next time the application is opened.
- Custom filters could be keeped private or shared with other users.
- Some sort of notification system for example in case an accordingly modified filter detects a change that fulfills the necessary criteria a notification can be sent to the user or a group of users.
- Especially if the software would be utilized in other areas aswell, a switch at the start or simply during the installation would be nice, where the area that should be tracked can be determined. This would reduce the size of the database while still providing the option of an international deployment. However some features like the satalite map provider would have to be changed dynamicly which might not be trivial in all regions.
- Similarly it would be nice to introduce some internationalisation in order to support more langagues besided german.
- Introduce more information about the changeset direcly in the application, like data about the history of the current objects would allow user to make decisions about the changeset faster.
- Even more advanced filtering of the changesets for example with a full-text search would further extend the options of limiting the number of entires to the most relevant. This might also include a search function for the already filtered list of changesets.
- To make the application faster and reduce the capacity needed it would be nice to reduce the size of the database. This might require more data to be loaded externaly and certainly requires some major changes in the entire changeset processing, but would pose an interesting and efficient change to the current state.
### Possible approach
The options above are in no particular order. Here we quickly discuss some possible approaches. Of course they might vary depending on the motivation with which the project is extended. It should also be noted that the best approch strongly depends on the future needs of a potential client.
If no particular features are urgently requested, it would make most sense to first improve the current features. This can consists of making them more robust, improving performnce or to extend them with new options.
When after this there are still ressources available a new feature or functionality can be implemented. The list in [above](#major-additions) is not prioritised in any way and it has to be determined for the specific occasion which addition is the most usefull to develop.
