01. INACITY inner workings
INACITY's back-end is designed in such a way that allows easy coupling of new Geographical Information Systems, Imagery Providers, and Computer Vision algorithms. The front-end concerns the direct use of the registered components (e.g. coupled Image Providers) through a web interface.
The diagram below illustrates the relationship between managers, abstract classes, and derived counterparts. Each manager is responsible for delegating requests from some front-end client to the components responsible for collecting urban imagery, GIS data, and data extracted by some Image Filter.
The following class diagram shows the Manager classes (following the Strategy design pattern) and the subclasses of the MapMiner, ImageProvider and ImageFilter abstract base classes. By subclassing such base classes one can create new modules into INACITY extending it to allow queries in new Geographical Information Systems, Imagery Providers (e.g. KartaView), and extract or process the collected images with new ImageFilter subclasses.
The front-end part comprises a website for the end-user (see the diagram below). The main components are its pages and communication classes. The pages essentially enable the end-user to interact with the website and render updated information as the user makes requests. The communication components are responsible for encapsulating requests for the back end and, at the current version, for Google Street View (GSV) servers. It is noteworthy that the GSVService component, responsible for communication with GSV servers, is implemented at the front end due to restrictions on GSV. However, the signing key and the GSV request formulation algorithms are implemented at the back end.
The diagram below illustrates the relationship between managers, abstract classes, and derived counterparts. Each manager is responsible for delegating requests from some front-end client to the components responsible for collecting urban imagery, GIS data, and data extracted by some Image Filter.
The GeoJSON is a standard based on the JSON notation to describe geographical features in a textual format (the JSON format). We extend it to include data relevant for geolocalized images, creating a new standard that we call GeoImage.
The Figure below shows a class diagram representing the GeoImage standard proposed, based on GeoJSON, and the relationship between the GeoImage and GeoJSON standards. The GeoImage object keeps metadata about some image collected from an image provider and data extracted from that particular image using some Computer Vision algorithm.
Geoimage is a component designed to encapsulate an image collected from a GID (e.g., Google Street View). It keeps together metadata about the image as its location, timestamp, viewpoint (horizontal and vertical angles of the camera). The proportion of the image (in relation to the image size) regarded as green vegetation will be stored in the density property of a ProcessedImageData object associated with the GeoImage of the processed image. The base64 serialization of the image is used for simplicity.
