Sunday, December 28, 2014

Inner System GIS

A diary of working with high detail inner solar system data to showcase graphics and UX chops.

Don't blame it on the sunshine, don't blame it on the moonlight, don't blame it on the good times, blame it on the boogie.

1. Raw Topography

Height maps will require 16 bits per pixel. Downloaded from the internet sources listed and converted to 16 bit single channel png files they look like this:

2. Normal Map generation

Experiments with unpacking local regions from these single world png files fails so I have moved to using 16bit source png files created above to generate some squared friendly resolution normal maps.

After adding Mercury and Venus to the list of sources we move on to some desktop friendly resolutions for our first test renders.

3. Initial Renders

More than some issues with my code and still some obvious issues to get from here:

to to  and

with some issues remaining in the mapping and normal departments...

MacMini 2010 is much happier when it is just bump map as texture fetch seems very expensive on big maps on little pootas...

And out on the red planet, one wonders what left the massive scar. And the shape of it's moons, what's with that? hmmm

4. Cartesian Topography

Closer to home, the local maunga (mountains) are a planned test case for eruption engine.

A new terrain engine that generates mesh from the blue iso lines is next...

Those blue lines look a lot more interesting if we head south a little bit

The fine print as always is read carefully:

Topo50 is the official topographic map series used by New Zealand emergency services. When using Topo50 data, please be aware of the following: 1. The existence of a road or track does not necessarily indicate public right of access. 2. Closed tracks are defined as being no longer maintained or passable and should not be used by recreationalists. The Department of Conservation or other authorities should be contacted for the latest information on tracks and huts. 3. Not all aerial wires, cableways and obstructions that could be hazardous to aircraft are held in the data. 4. Contours and spot elevations in forest and snow areas may be less accurate. 5. Not all pipelines including both underground and above ground are held in the data or shown on the printed maps. For the latest information please contact the utility and infrastructure agencies. 6. Permits may be required to visit some sensitive and special islands and areas. Contact the Department of Conservation to see if you need to apply for a permit.

I am not sure recreationalists is a word but 3.2 gigabytes later we have some data files ready for mesh conversion therapy.

5. ESRI shape files

Unfortunately our favourite language monkey is not yet able to handle 64 bit data types natively so today we are back programming in Java for the following processing step.

The shape file downloaded from LINZ in previous step now needs a parser based on the shape file specification here:

It may have been prudent to use KML but that format smells of google and we have some existing code in our personal Java repository that needs a refresh. Replacing some bit fiddling with ByteBuffer ByteOrder.LITTLE_ENDIAN would be a start...

6. Orbit Concrete

Shadow casting of earth onto moon should make for a nice lunar calendar.

After attempting a Google search on celestial bodies, and trying to remember the terms for the satellite location data types used to configure GPS chipsets (alamanac and ephemeris) had a small epiphany - it would be more educational to model moon light and tides and in fact entire project from here on in using observational data alone.

Data such as high tide being at a guess about 8pm tonight and the moon, ummm, from a search on Lunday evening, not present. Real world shadows and some basic sky mapping would certainly be real world fun addition to my "edu-tech" universe.

7. Contour lines

The LINZ data in shape file format has contours and coast line of entire country and it is currently being sorted so every segment of every contour line is added to a large pool and ordered using top point from North to South.

Release mode code on fast machine is taking over 30 minutes due to lazy insertion sort. I have to use Stacks not Lists otherwise I run out memory so slower sorting for the win. Increasing the number of buckets would speed things up but I only got it to not crash so a pass that writes to disk is underway.

OK, maybe more like an hour, the southern alps shown in previous image are going to slow this process down a little.

[many hours later]

Whew, finally got the isoline code running in x64 mode on PC (monkey says yes except for eof becoming broken and audio not linking) without blowing it's guts, memory usage went up to 6.5GB but at least I can now just plug in more RAM....


With road networks and mountaing contours passing initial tests gamification begins.


1. Source Data

Available topographic mapping projects with maximum resolutions:

earth - etopo1 - 21600x10800
moon - lola - 368640x184320
mars - mola - 46080x23040
mercury - mdis - 61324 x 30662
venus - magellan - 8192 x 4096

Earth surface maps

  1:50000 Linz Topo Data

Saturday, December 20, 2014

in search of :poop:

in which Christopher Robin opens the Font Book application on his new Apple computer and discovers a colour emoji font

and sets about searching for more information on this happy pooh
hmm, something is starting to smell like Christmas on the Chrome context menu!
which generates the following scented URL:

and with a little more effort the low down is

  • emoji shortcut is :poop:
  • unicode name is PILE OF POO (U+1F4A9)
I'm off to tweet poop, hope it works💩💩💩


and one last test, some poop in my code:

Friday, December 19, 2014

android lollypop refresh

Between jobs and refreshing my technology chops...

Which begins with a download of TADP (nVidia's Tegra Android Dev Pack) but Eclipse based dev seems to have been deprecated so over to Android Studio where switching to Vampire mode (night palette) puts us in a far more positive mood.

Yup, it's December 2014 and lollipop device users are rounded to 0.0% which I am going to pretend is actually a good sized market for an independent such as myself to target.

After mistakenly making things too complicated by creating a new app for both "mobile" and "tv" I restart and stick with "mobile" only.

After first diversion in which Google points us to stack overflow for some gradle discussion in which an expert uses the term "work in progress" I fail to discover what "Picasso" dependency is even doing in my first project and move on with my second, where a blank app is now waiting for some experiments with Full Screen to be added to the menu.