-
Notifications
You must be signed in to change notification settings - Fork 1
Development
Page about what development is lined up and currently being worked on
This section talks about what is actively being developed on the application milestones, branches ect
Image processing is currently being heavily worked on. with the focus on dealing with the palette
Image Branch
Currently the palette for the map of the moon is broken down into each vertical pixel and that RGB value is assigned a altitude. This only gives <389 possible values.
After some analysis of the palette we do not believe there is any single equation that will allow it to be reversed.
The palette can be broken into smaller sections that can then be used to interpolate more points between them. Coding to write mono, bi & tri-linear interpolation classes is currently being done. This will then lead to an initial hard coded version of the sectioning system before looking into designing the code to be able to determine sections and type of interpolation required.
Image Branch
With the above improvements to the palette processing it is hoped that the speed to decode the image RGBs and convert them into Altitude will go down (with some clever thinking). Currently this is possibly the slowest part of digesting the image.
Planned development.. but as it's only one person currently maintaining/developing the code there's likely to be a lot in here and not much above
Priority: High
Currently the roughness map has some black lines due to integer truncation, this will be looked at to hopefully remove this problem. Likely fix is to swap from analysing by distance and swap to lat/lon steps that 360 are divisible by.
The KMZ (Goole Earth file) currently using a single image to cover the moon, future development will look at splitting the image into smaller pieces (~8).
Future development for the database side of the application
Priority: Medium
Currently the image used gives ~16million points on the moon, which means each pixel is quite large (~2km at equator), there are higher resolution images (~252 million pixels) and much higher resolution datasets (down to meters).
To improve performance and try to prevent table sizes getting ridiculous (several gigs) the data will have to be sharded. This means splitting the data over several tables and the code doing intelligent joins between tables. This should reduce find/sort time.
Priority: Low
It is likely that using a GIS (Geographic Information System) Database could improve the speed of the database as they are specifically designed for storing 'Geographic Information'. PostGIS is a likely candidate.
Priority: Low
With expansion of this project the ability to use multiple datasets as well as possibly other celestial bodies modifying the way the code and database works is required.
The current concept is to have a few configuration tables that store information about what data is in the database. These tables will point to the sharded data tables for the given body & data set.
Priority: Low
Currently to use the code you need to know how it works so you only trigger the part of the code you need (fairly simple to be fair :P).
Development of a simple UI that calls the specifically chosen commands as well as allowing configuration of the system (database ect..) would allow others to be able to use this tool.