Notice to YSPilots/YSFLIGHT

Notice to YSPilots/YSFLIGHT
Legacy Pack available under the YSFLIGHT category.
Any individual requests for a model must be made to my email address, see bottom of the page..

Sunday, 12 March 2017

QGIS TPI Based Landform Classification Style

In SAGA GIS (and by extension - QGIS) there is a tool called Topographic Position Index.
It is a tool that assigns an index value based upon the land form feature - ridges and peaks are assigned positive values, and valleys are assigned negative values.

In addition to this tool - there is a TPI based landform classification - which takes that Position index, and classifies the landscape into different land forms, such as:

  • Canyons, deeply incised streams,
  • Mid-slope drainage, shallow valleys
  • Upland drainage, headwaters
  • U-shaped valleys
  • Plains
  • Open slopes
  • upper slopes/messas
  • local ridges/hills in valleys
  • midslope ridges, small hills in plains
  • Mountain tops and high ridges

Basically, I've created a QGIS style based upon the map used in the poster by A. Weiss.
3D plot over OS Terrain 50
© Crown Copyright and Database Right (2017). Ordnance Survey

Map view of TPI Landform Classification based on OS Terrain 50

The TPI Based Landform Classification is useful for determining the landform characteristics for a given area - and by classifying them into set categories, one can compare landforms in different areas. 

To use the tool you need a DEM, and QGIS. 
The tool is located in the Processing Toolbox under SAGA>Terrain Analysis - Morphology > TPI based landform classification

Friday, 19 August 2016

YSPilots Podcast Releases

There have been some requests on YSFHQ for the old YS Pilots Podcast from... 2006?
I've therefore re uploaded them to the internet for future generations to learn from our mistakes.

1st Season:
YSP Podcast 1-12

2nd Season:
YSP Podcast 13-14

...and something that I think never made it to the final cut:
Seraphim's reading of part of the YS Story (I've no idea what happened to the previous parts)
YS Story: Mitchy pt 2

Good times.

Monday, 16 May 2016

Recap360 Pro to QGIS (Quantum GIS) - The hard way

I've recently obtained Autodesk Recap360. It's basically a software package that stitches images from drones/multiple viewpoints together to make a 3D model. I think it's the slightly more advanced version of 123D Catch.

I've also got a drone, and in June of 2014 I flew a series of missions with it over my home. Since then I've not really known what to do with the large selection of images (overall, about 1000), so they've just sat on my hard drive waiting for something to happen.

Something happened when I was trying to make a bid for a drone for work. I had to price up the software available, and the hardware (...the flying bit). I looked at the usual suspects for drone imagery, Pix4D, Agisoft etc, but a new one popped up, Autodesk's Recap360.

Their system works in the cloud, so you upload your images to their servers, and tell it what to do, and about an hour later you get a lovely email saying it's done.
At the moment, their online viewing and editing tools are out of action, so I've not tried their georeferencing tools online (which is hopefully the easy way...). I went for the hard way.

When you process your data, there is the option for either a quick preview (which I guess is perfect for just making sure it'll all come out okay) or ultra (which allows you to do all the fancy stuff, including download the orthomosaics). Ultra costs credits, which I assume you top up and pay for (because I'm a teacher, I'm using it for education (it'll be used to teach my students about DEMs next year) I get it for free.)

When it's processed, you've got the option to download the products, such as OBJ files (I guess you could use it for making 3D prints of stuff too, which is cool), but more interesting is the .TIF download option.

What you get is 2 TIFs, one orthomosaic and one elevation model.

I use QGIS 2.8.1 as my main GIS software, which can happily open Tiffs. so it made sense to import them into that.
This is where it got a bit harder.
The orthomosaic went in just fine, 3 layers, red green and blue, just fine. They all looked good in the GIS (Apart from being mirrored, and un-georeferenced). Both of these problems were easily rectified by georeferencing it to Google Maps.
It referenced pretty well - with only 4 points, I had pretty good accuracy. I didn't do any serious work on it, just a quick 4 points in the corners, and checked it against where the roads were on an OS map, and it looked reasonable.
There are some oddities, such as the fence bordering on the road, but this is actually because the OS Street View map I'm using is an old one, and we moved the fence between the road and the path.
Apart from that, the fences line up well, etc etc. Not bad for 4 control points!
So far so easy.
Now things got a little trickier.
The Digital Surface Model.
I imported it the same way, it's a Tiff too, but I was greeted with this:
There were no values assigned to it, and when I opened the properties, I ended up with "bad allocation" and no property box. I tried exporting and reimporting it, no joy, still unchanged.
In the end, I thought, "I'll do this manually" and saved it as a .asc file. If you don't know, an .asc, or ASCII file is basically a text file, you can open it in Notepad, and edit it, but when you import it into a GIS, it is an elevation/raster file again. It's basically just a text file full of pixel values.
Because it is a text file, you can edit it easily in Notepad. The problem, I suspected, was the fact that the transparent parts of the image were set to "#INF", rather than -9999 which they are often set to, I guess QGIS doesn't like #INF as a numerical value, and maybe this was the reason it was throwing an exception.
So, find "#INF" and replace with "-9999". Suddenly, QGIS was quite happy opening this new file with -9999 as the transparent colour. 
I could now change all the colours in QGIS, and georeference it as I pleased, but.... it ran on a scale from -3.7 to 2.8. So the lowest bit of the map was -3.7m below sea level, and the highest was just 2.8m. This is the North Yorkshire Moors! It should be higher than that by at least 100!
It was also reading -3.7 for the highest place, and 2.8 for the lowest.... 
I used QGIS's Raster Calculator to do "1 - the DSM layer" to invert it, so now it was the right way, but the scale was still wrong. 
If I'd paid more attention in maths, I would know an easier way of doing this, but I didnt... So instead I compared another digital elevation model of the same place, and compared 2 areas: I looked at what my drone DSM said, and what the real one did, and came up with:
DSM value of -2.7083 corresponded with an actual height of 175.889m,
DSM value of 0.913 corresponded with an actual height of 249.6m.
Now I just had to figure out how to scale them both up, and now my brain left me.
So, I had to do it a slightly more cheaty, boring way, I made a graph.

Very kindly, excel can put the formula on the graph too, and this is the formula I could use to calculate all heights from the weird values on the DSM.
y (real height) = 20.352 x the value on the DSM + 231.02. I'm sure there was an easier way of doing this, but it worked.
From this, I could calculate what the actual minimum and maximum values should be, from the -3.7 and +2.8. I thought it might allow me to simply put this formula into the Raster Calculator, and just create a new layer from that, but the result had the same "nan" and the error....
Luckily QGIS has a tool for the job. Enter "Grid Normalisation".
It obviously allows me to normalise the data, and luckily it does it from a known maximum and minimum, which we'd calculated using the formula.
This done, and my DSM was finally showing the correct height values! It was still in the wrong place, and mirrored, but hey! at least it was the right value! (+/- a few meters...)

Now it was just a matter of georeferencing it (which was done against the outline of the orthomosaic, as it is a hell of a job trying to georeference a flat field on a DSM... it is just featureless....).
The resolution is quite a bit lower on the DSM than the Ortho - the ortho is about 11cm, the DSM is 50cm. But, overall, it made a pretty little map, so I'm happy!

This was just from 150 of the photos, so I may try and run it again with more. ReCap360 has an upper limit of 250 photos, so it isn't going to be many more, but I might try and chose some from areas that aren't so well represented or are a little fuzzy.
The orthomosaic also has some odd artefacts around trees, where they look oddly pixelated, I think it is because of the way it is constructed. The images are formed into a 3D model, with flat faces, so if there is a slight lack of detail, the model is incomplete, and when viewed from above, it looks slightly like a model from a Playstation 2 game.
I can live with it though, for now.

I'm not sure what I'm going to use my newly georeferenced orthomosaic for...We shall see... but it's nice to have found a method that can potentially process drone images in an occasionally reliable way...
Now I just need to get the drone flying again

Wednesday, 4 February 2015

Fitting a DCC decoder to an Arnold 2242 Chassis

So, I’ve got an Arnold 2242 Chassis under a Five79 Quarry Hunslet body,

(See here: RC-4) and I want to convert it to DCC control, so.. Here goes.

What I’ve got is a LokPilot V4.0 Micro (Which I got from ebay), and my Arnold 2242 chassis. So. Lets begin.


Once the body is removed, make sure the two contacts (Marked above) are straightened out (And ensure the motor is insulated from the)


Then, solder the red and black wires onto the bronze contacts. They should go on pretty easily, and as long as you dont hang about with the soldering iron, it’ll be reet!

Will look like this:


The orange and grey wires from the decoder are the next, and these need to be soldered onto the motor contacts.


This is how they should look after being soldered on.

Watch out on this bit. This part of the motor is made of plastic! You’ll need to be very quick with the soldering iron to make sure you don’t melt it!

That’s pretty much it! I routed the wires under the motor, and secured them in place with regular PVA glue in case I need to get them out again.


These can then be routed up into the cab, where I’ve got the decoder.


The only down side of this is that the cab looks like a rats nest…. But hey! It somehow works!

At the moment I dont have my DCC controller, so I’m unable to test it.

Wednesday, 25 June 2014

Dinorwic Office Building scale drawing

Here is my second drawing. It is an office on Australia Level in Dinorwic quarry. The internal wall has a large opening, possibly for a counter or similar. Walls are slate slabs, similar to other buildings, but rendered over the top.


^ My interpretation



Pete Wilson’s original drawings ^


==-- Download Drawing Here (PDF)--==

Monday, 23 June 2014

Dinorwic Slate Quarry Scale Drawings- #3 Penrhydd Bach Locomotive Shed

Here is my 2nd attempt at a scale drawing. This is for the shed Penrhydd Bach in Dinorwic Quarry. This shed housed the Quarry Hunslet locomotive called “Holy War” for a time.
This isn’t totally finished, as there is in fact a store house that was built later on behind the locomotive shed, which can be seen here.
The measurements I’ve used are from Pete Wilson, and are from April 1987DSC_7100
These are his original designs that he so kind to copy for me.
^ Preview…
This is a bit different from the previous designs, as I’ve included a cutting list for the walls. This was actually never intended for release as it was just for my cutter/plotter to cut out the walls from Styrene sheets.
Anyways, enjoy!

Monday, 2 June 2014

Lernion Locomotive Shed - Denorwic Slate Quarry

This is a schematic diagram of the Lernion Locomotive Shed at the Dinorwic Slate quarry in North Wales. It's build up from a number of photographs from here:
The scale is set in LayOut to 1:72 for printing on A4.
Other scales can be made if anyone wants.