OS OpenData product update – OS Terrain 50

At the end of March we saw Ordnance Survey’s free data portal, OS OpenData, upgraded with the release of a new version of OS VectorMap District. Today, sees another significant update to OS OpenData with the release of OS Terrain 50.

OS OpenData users and developers can now access a new fully maintained analytical height product called OS Terrain 50. The new product, which has a similar resolution to Land-Form PANORAMA, will enable users to access an advanced product with consistently maintained height content for the whole of Great Britain.

Land-Form PANORAMA was an unmaintained product and was last updated in the 1990s. The new product will give users more confidence in the currency of the data and will be supplied in additional formats, making it far more accessible.

It can be easily integrated with Vector Map District which is available through OS OpenData, or OS MasterMap Topography Layer and will be a welcome addition to the tools used for terrain analysis and 3D visualisation by a wide range of users.

Arriving as a grid file, it is expected that OS Terrain 50 will be used primarily as an analytical tool for landscape visualisation and analysis over large areas. For example interrogating the visual impact of wind turbines or high-level flood risk assessment, transport infrastructure planning, environmental impact assessment (wind farm location for example), signal propagation (radio, telephone) and security and defence planning

OS Terrain 50 is part of the new OS Terrain family; OS Terrain 5  a mid-resolution DTM, designed to be interoperable with our large-scale data will be released in the near future.

 For now, OS Terrain 50 is available through the OS OpenData portal to download now.

Please select OS Terrain 50 and chose the ‘Supply format’ as ASCII GRID AND GML (GRID) – GB and tick the box to download the files.

You may also like

Mapping a personal journey with OS OpenData
Introducing our OS Data Hub
OS OpenData products now available in GeoPackage format
NHP partnership conference

91 Responses

  1. Steven H

    The ordering of the OS Terrain 50 data doesn’t work for me. I tick the box to to select the product and press Next, it then flips back to the top of the order page. All other OpenData Download products work.

    1. Melanie

      Hi Steven,
      If you select the ‘Supply format’ as ASCII GRID AND GML (GRID) – GB
      and tick the box, it should download without any problems. I will change the blog to make this clearer. Thanks for highlighting it.
      Good luck!

      1. Steven H

        That works, I hadn’t read the notice that says the contours will follow later. It would have made more sense to me anyway to remove the contour options in the dropdown until they are available.


  2. Joshua Arnott

    I’ve just done a quick comparison between the PANORAMA DTM and the new Terrain 50 DTM. This mostly just highlighted areas that have been quarried in the last 23 years, although there have clearly been updates across GB.

    It looks like the Terrain 50 doesn’t include any elevation data for the Isle of Man. Is this an oversight, or an intentional omission?

  3. Joe

    I currently have Panorama data as a single tile in ArcGIS (in a geodatabase). What is the fastest way to import the data in its current format? I notice it is provided as a Zipped file of many zipped files in folders – i can see this being complicated!

    1. Gemma

      Hi Joe
      No problem, I’ve just caught up with our Products team and I’m told that the zips look complex but it’s actually really simple. Our instructions below are based on using Winzip, but there are many free download managers available too. It is worth mentioning that once it’s downloaded and unzipped you can search for all files ending in *.asc to get the data in one place. So:

      1. Unzip the main Terrain 50 download to a suitable location
      2. Go to the location using file manager (My Computer) from the desktop
      3. Use the file manager search facility to find all zip files below this location e.g. *.zip
      4. When finished, select all the .zip files in the search result window
      5. Right click and select winzip – Extract to (assuming that winzip is loaded)
      6. Select location for data to be unzipped to (about 500mb)
      7. Wait – It takes a while to unzip all the tiles
      8. Throw away the files you don’t want

      I hope this helps you out. If you have any further questions, my colleagues in our Customer Contact Centre would also be more than happy to help out. You can contact them on 08456 050505 or customerservices@ordnancesurvey.co.uk
      Many thanks

  4. Joe

    Thanks that was simple – in addition to this I am trying the ‘Mosaic To New Raster’ tool in arcgis to import all the ascii files as a single raster layer

      1. Gemma

        Hi Joe

        Due to local tidal conditions, the height of the mean high and low water mark varies continuously around the coast of Britain. In OS Terrain 50, the mean high and mean low water lines have been assigned constant height values, based on the average for each tile from information sourced from tide tables. These values have been continued offshore up to the tile edge to ensure consistency. Inevitably, this means that there is a small discrete step from the tidal area between adjacent tiles.

        Thanks, Gemma

  5. dave storey

    There is also a (google) tool called multi-unpacker that will handle nested zip files (using winrar). However they really are a bit of a PITA compared to a single level archive.

    I note the new .asc files actually seem to match the documentation about numbers of rows, columns, and presumably what order the data is in (the old landform panorama .asc files are about as backwards as you can get – abiding by arcgis rules for ascii dems, instead of OSGB spec).

  6. Dave Storey

    Is it only me or does the .asc dem tile for NK14have a small glitch, in that the header says
    ncols 200
    nrows 200
    xllcorner 410021
    yllcorner 840000
    cellsize 50

    where the xllcorner should surely be 410000 (unless the whole tile is slipped 21m)

    1. Gemma

      Hi Dave
      Thanks for bringing this to our attention, our Products team are looking into this and we’ll come back to you once we’ve investigated further.
      Thanks, Gemma

    2. Gemma

      Hi Dave

      Just caught up with our Products team again and thanks for the feedback on OS Terrain 50. We are investigating the problem, which has highlighted an issue with one of the software modules used. We will keep you updated, but expect to be able to make an updated version of the product shortly.

      Thanks, Gemma

      1. dave storey

        Thanks for the update – please do let me know when there is an update, and how much of the previous data I need to replace!

  7. Jonny


    Do you happen to know how I could go about converting this data to .NTF? The software we’re using can only batch convert from NTF into its own format so I’m going to have to manually convert the whole of the UK tile by tile otherwise!!


  8. Alex

    Any rough estimate on when the OS Terrain 50 contours will be released? Is there any means of being notified when it will become available? (e.g. a blog, RSS feed, mailing list etc.)

    1. Gemma

      Hi Alex
      Our team are working on this and checking the data now and would expect to be in a position to release this within a fortnight or so. We’ll make sure we let people know via our blog (there is an RSS you can subscribe to on this blog) and our website – and if you follow us on Twitter @OrdnanceSurvey, we’ll be tweeting about it too. We will be updating the OS Terrain 50 grid also to correct some anomalies that were found in the position of some tiles.
      Thanks, Gemma

      1. dave storey

        On the subject of corrections/fixes, is there any chance of fixing gridinquest7 (probably just the data tables) so that it doesn’t give ‘out of area’ errors when trying to convert some of the OS opendata?

        The worst offenders are the (farthest) corners of the sea-tiles (which OK, ARE outside the surveyed area, but still) .. but I think some of the low water boundary has the same issue.

        1. Melanie

          Hi Dave,

          I think this relates to the issue we have fixed where some tiles were out of place. With regards to gridinquest this is a separate piece of software that is showing an error but it is not part of the height data. We expect to release the update in the first week of July that should correct this and provide contour data. Many apologies for the inconvenience.

          1. dave storey

            Great .. it’s on it’s way down to my PC. If I find any more exciting variances from reality you’ll be the first to know. 8>.

            Do I assume these are ‘hand crafted’ contours, rather than just ‘chuck the DEM through a contouring program’?

  9. dave storey

    I understand gridinquest is not part of the height data, but it does have a problem with some of the corners of sea tiles which are giving ‘out of area’ not necessarily just the height/contour data, there are other opendata files like low water, which have same problem). You can see the same thing with the online coordinate converter last time I tried it.

    The problem is that the gridinquest tables for coordinate conversion don’t comprehend the points at the ‘outer’ corner of mostly-sea squares (let me know if you want some examples). I’m thinking of points like the NW corner of HP or HT – if you put those into GIQ7 is just bleats about ‘out of area’.

    1. Melanie

      Hi Dave,
      Our Product Manager is going to contact you directly via email for your examples and to see what we can sort out. Hope that helps.

  10. Dave Storey

    I note that the Terrain 50 ESRI release contains (as well as contours)spot heights. Not surprising! However these seem completely unrelated to the spotheights in the ‘vectormap district’ Opendata release – i.e. different places (and therefore, obviously, different heights).

    I assume the Terrain 50 set are more current, and the Vectormap district spotheight files should be retired, scrapped, updated, or whatever? (I have not adited the Vectormap spot heights against the Terrain DEM or contours yet – a job for a rainy day I guess).

    In a similar vein, the Vectormap district files also contain much of the same data as the Boundaryfiles dataset (parish, county, etc. boundaries) .. but in that case the two seem reasonably well correlated.

    1. Gemma

      Hi Dave

      Thanks for getting in touch. We’re pleased that you appreciate the consistency in the content that you received in the products that you have ordered from OS OpenData, this is something that we believe is important and is something that we are working to continue to improve across a broader range of the products that we produce.

      OS Terrain is a brand new range of height products from Ordnance Survey, and they have been created using photogrammetric techniques. In developing OS Terrain we have carefully developed our processes to automatically generate the contour, spot height and grid content. Unlike previous height products produced by Ordnance Survey, OS Terrain is intended as an analytical product (to answer users queries) as opposed to an explicitly cartographic product, although we do think that OS Terrain 50 does look pretty good too! So whilst these are not ‘hand crafted’ contours, we have done rather more than just ‘chuck[ing] the DEM through a contouring program’.

      You are correct that the spot heights between OS VectorMap District and OS Terrain 50 do differ; those that are present in OS VectorMap District are sourced from Ordnance Surveys height data archive, whereas the spot heights in OS Terrain 50 were created as part of the development of this new product. We will be integrating some of our new height data content into a future release of OS VectorMap District so the differences you note should be resolved. We would suggest, if you have a particular interested in spot height and terrain information that OS Terrain 50 would be the best OS OpenData option for you as the height content is far greater in this product.

      A comparison is shown via the link below to illustrate the difference between the spot height content in OS Terrain 50 (Red Stars) and OS VectorMap District (Blue Circles) in Grid Square SU30 (part of the New Forest national Park).


      Thanks, Gemma (on behalf of our Products team)

      1. dave storey

        Thanks Gemma, I’ll go with the Terrain 50 spotheights then, and shortcut the Vectormap future updates. Most of my users are more interested in contours anyway, but (accurate) spotheights are sometimes useful for GPS calibration .. I have the (antique) OS trig points mapped as well, for similar reason.

        Nothing wrong with ‘chucking the points through a contouring program’ .. tiz what we did with NASA height data for years, before OSGB released their contours .. at least this way all contours are likely to be complete and joined up (not the case in the landform panorama dataset). The downside is that cliff faces and the like don’t get any special treatment (as in ‘I give up, let’s just have a break-line instead’)

        The vectormap looks pretty good (but not yet perfect) too .. I’ll feedback on that elsewhere when I’ve finished mincing it.

  11. Alan

    Can you please confirm / clarify my understanding of the Terrain 50 ASCII grid data.

    SD60 starts

    ncols 200
    nrows 200
    xllcorner 360000
    yllcorner 400000
    cellsize 50
    127 129 130.9 133 135.2 …
    127.2 129.1 130.4 133.9 …

    My understanding is that this means there are 200 cells of 50m from 360000 to 370000 and 400000 to 410000.

    127 is therefore the height of the SW corner cell and should be considered as a spot height at the centre of the cell.

    127 is therefore at 360025, 400025 if considered as a point height (i.e points are at 25, 75, 125 etc).

    This differs from panorama data as that has 401 points per 20km tile and the points are at 50, 100, 150 etc.

    It is important for accuracy of use in vector products that I know where the 127 height is applied.

    1. dave storey

      Well my understanding is the same as yours, and so far it seems to tally with other data sources (within the 4m or so the OS specifies). However note that the panorama points started at 0, not 50 (I’m sure that’s what you meant).

      I’d have liked it better in larger chunks .. modern computers have no trouble with a whole grid square (100km * 100km) DEM, instead of these woosy little 10km square nibbles, but ‘glue it together’ technology works OK, once you conquer the multilevel zip nonsense.

      The other vector data now comes in full grid squares (albeit with internal 10km fractures in).. and some like boundary line data actually comes country wide, all joined up and everything.

      1. Thanks Dave – yes 0 as you say. I agree with your point about larger squares being more useful.

        The raster / cell type format causes my program a bit of a problem when filling in a large data block (often at different grid points). I handle the data as vector points and therefore interpolate between the extremities of each input data block (as points). This implies a gap between Terrain 50 tiles, which did not occur on Panorama data tiles as that had the one point overlap.

        Easy enough to program around treating this as a special case, but difficult to handle when generalised to many other types of data that could have missing data.

        1. dave storey

          Not sure I exactly follow what you are doing, but for myself I combine all the teensy little tiles into a single ‘megaDEM’ for the whole of mainland UK (OK it’s a 1.3GB file – so what!) which I can then random access by Easting/northing (for the 50m gridded values). Take 30 mins or so to do it, then it gets stored forever, and read as required.

          For the height at a random point I am using quintic interpolation anyway, which needs a 6×6 height grid around the random point, so even with panorama data I was going to be pulling in stuff from 1,2,3,or 4 tiles, which is a royal PITA (especially with .asc format data – needless to say ‘megaDEM is random access binary file, with heights stored as 4 byte singles).

          I suggest that you look at reformatting the terrain50 data into something more usable for you .. neither storage nor CPU ought be a problem these days (but stay under 2 GB if you can!)

    2. Gemma

      Hi Alan,

      Apologies for the delay, I needed to check with one of my colleagues in Products team to ensure I gave you the correct information.
      Landform Panorama was provided in 20km² and each axis included 401 values, and the data used a SW corner origin.
      OS Terrain 50 is supplied in 10km² and each axis includes 200 values and each is pixel centred.
      The height values provided in OS Terrain 50 of 127 should be considered as (mean) average value applied across the whole 5m² cell and should not be treated as a spot height.
      Many thanks

      1. Thanks for confirming my interpretation.

        I have no choice but to treat the heights as spot heights in order to draw wireframes of the landscape. Plotting a landscape like a histogram would look horrible.

        As I understand it both Panorama and Profile (10m grid) data are spot heights. Assuming that Profile is up to date (I appreciate that Panorama isn’t) are you suggesting that a 50m data set derived from the Profile data will be more accurate than the Terrain 50?

        It would have been so much better to produce a 50m point data set similar to Panorama.

        Thanks Alan

        1. Gemma

          Hi Alan

          I’ve been back to our Product team and they tell me that:

          I hope we haven’t caused any confusion with the term Spot Height, as for us these are points that are supplied with the contour data. OS Terrain 50 grid is a dataset of grid points that can be treated as you say ‘spot heights’ in order to draw the model in your software. This is similar to Land-form Profile and Panorama grids, except that the height is pixel centred. So the height of the whole grid square is dictated by the data point. This avoids any overlaps or gaps in data as present in pixel-cornered data such as the Land-Form Profile grid. Both Land-Form Profile and Panorama are frozen datasets so the only way to see the current view of the terrain is by using OS Terrain 5 or 50. OS Terrain products also benefit from detailed modelling of features such as lakes, motorways and quarries which were not part of the Land-Form product specification. You can search the downloaded files to extract the ascii grid files more easily.

          Many thanks

  12. John Dodsworth

    Following Alan’s question re the ASC header…
    The documentation says that xllcorner and yllcorner refer to the north west corner (each successive row moving south) but the GML file and other info suggests it is the south west corner (ll meaning lower left?). Do you know which it is

    1. Gemma

      Hi John

      I’ve just caught up with our Products team and they fear their previous answer may have caused some confusion. The grid file comprises of z values that start from the north west corner and read left to right as stated in the user guide. However the header xllcorner value and the gml ‘header’ provide the lower left corner, as you say. This needs to be made clearer in the documentation by stating, for example:
      In the ASCII grid file the values are presented 25 m from the north-west corner of the tile (to provide the pixel-centre). The data is presented in rows reading from west to east creating a row of 200 z values. The next row will begin 25 m from the western edge 50 m south of the origin and again progressing at 50 m intervals to the east. The header provides the coordinates of the south-west corner (xllcorner and yllcorner) to ensure that a GIS places the data correctly.

      Thank you for bringing this to our attention and apologies for any inconvenience.

      Thanks, Gemma

  13. dave storey

    I think you’ll find it is Lower Left corner (as per standard for .asc files), but the parts are in the file from top left across, then down to the next row, etc (also .asc standard).

    The documentation for the panorama .asc files was pure scribble .. not sure I’ve seen the docs on the terrain 50 .asc files, but I’m pretty sure they are standard .asc format.

  14. Phil Marsh

    I had been puzzling over that description of the relationship between the values and the origin in the user guide. “The next row will begin 25 m from the western edge 50 m south of the origin” (Gemma’s post above)is still a little confusing. Am I right that the centre of the first cell/pixel of the first row in the file is 25m from the western edge and 25m from the northern edge ? Which would put the centre of first cell in the last line of the file at xllcorner+25, yllcorner+25.

    1. I understand you to be right. It used to cause me some confusion – hence my questions earlier to make sure my and OS interpretation coincided.
      Think of the Terrain 50 as a raster data set of pixels of 50m size with each cell having a height value. The centre of the cell is then the logical point at which to apply the height when you need it at a point.
      Panorama data was what most people would call a vector data set – the heights are at the corners of the cells. I do wish OS had stayed with that presentation.

    2. Gemma

      Hi Phil

      Yes, you are right. Our Products team are going to make some tweaks to the OS Terrain 50 user guide to hopefully make this clearer for everyone.

      Thanks, Gemma

      1. Phil Marsh

        Thanks Gemma,
        Like Alan I preferred the previous way (for height data), though I appreciate that there are advantages in adopting a widely-used format.

  15. Phil Marsh

    A related question. One characteristic of the cell-based format is that unlike with Panorama and Profile there are no matching post locations between Terrain 50 and Terrain 5. The Terrain 50 cell centre it as the common corner of four Terrain 5 cells. What is the relationship between the two models?

    From a quick comparison with the Terrain 5 sample data it looks like the Terrain 50 value could be taken directly from the TIN or be calculated from the Terrain 50 data by something other than averaging. However, Gemma’s post above (25, July, 2013 at 3:29 pm) “The height values provided in OS Terrain 50 of 127 should be considered as (mean) average value applied across the whole 5m² cell” suggests some form of averaging. (I am thinking that 5m² was a typo for 50m²).

    Sorry if this seems a little pedantic – I’m trying to make sure I have not misunderstood.

    1. Gemma

      Hi Phil

      No problem, I’ve caught up with my Products colleagues and they say:

      The OS Terrain products differ from the previous Land-Form products because the pixel-centred grid provides one height value for a whole cell, either 5m2 or 50m2. The source data from which we derive the products contains masspoints and breaklines which have been created in a TIN model. To create the grid we evaluate the TIN surface that falls within each grid square. We employ barycentric interpolation, which is a standard method of interpolating between triangles of a TIN. Therefore each point in the grid will be the height at that point on the TIN. But because the grid point represents the just one height, the value given applies for the whole cell. I hope that helps to explain matters better.

      Many thanks

  16. Phil Marsh

    Thanks Gemma, that helps.

    My concern over details is because if, say, I am analyzing surface slopes then I do need “the height at that point on the TIN” as you put it. In that situation applying it to the whole cell does not mean much (unless it the ground is horizontal !)

    (and oops, I just noticed that I typed 50 for 5 on one occasion up there).

  17. Hi Gemma
    Thanks for all your help. Could you please supply me with a sample of Terrain 5 (yes 5, asc format). I have an issue with sample data from a supplier and wish to confirm with the data from yourselves. It is also with regards to the header info.
    I tried to locate a sample on your web site but could not find one.

        1. Gemma

          Hi Alan

          Do let us know if you spot anything, I can feed it back to our web team to resolve for you.

          Thanks, Gemma

  18. alan harris

    Thanks, had a look at the Terrain 5 sample and it confirmed mine and Phil’s points that it is cell based and height points are at the centre of cell, so 2.5, 7.5 etc
    The definition we have been going over above does not seem to have been understood by at least one of your suppliers, who provide an xyz Terrain 5 format data set sample that is at cell edges e.g. 0, 5, 10 etc.

    1. Gemma

      Hi Alan
      Thanks for the feedback. I’ve passed that on to our Products team so that they can check with our partners.
      Thanks, Gemma

  19. Alan Harris


    I feel the need to make a case for the alternative vector data set (i.e. like Panorama with height data at the edge of the 50m cells and not at the centre). I do not know all the pros and cons of either data format. All I am aware of is that the Terrain 50 makes it easy to produce pretty pictures by assigning the height to a colour from a table. What I think has been missed is that it is trivial to produce a raster (Terrain 50) set of height data from the equivalent vector data set (you simply average the four corner height values) whereas generating the vector edge of cell values is an order of magnitude more difficult because you need to use the adjacent tiles to interpolate the edge of tile height values. That reason alone should have led OS into producing the vector data set as the primary one. Is there any chance that a vector data set could be produced (Terrain 50V)? That would satisfy both camps and I expect would not take much effort on the part of the OS.

    If you throw in the Terrain 5 data whose centre cell points do not align with the Terrain 50 data set (they are at 2.5, 7.5 etc) you have another level of complexity!


    1. dave storey

      Not sure why you think it is a big issue – you still have the same grid of points, it is just shifted by half a grid unit each way. You can still join them up and get a surface .. just that the edges and vertices are no longer on 50m grid boundaries. Unless you absolutely have to know what the height is at 200000,200000 in which case, yes, you have some math to do (but it isn’t that hard – I’ve build a mega DEM file for the whole UK, and use a bi-quintic curve fit, so I can get a smooth surface and a guesstimated height anywhere on it (e.g. at 200001.35,200007.8). For any sort of reasonable curve fit you always had to look into adjacent DEM (potentially three, plus the one of interest) files anyway.

      I don’t like the old one better than the new one, or vice versa. I would like it not to keep changing, and I would like the documentation and the product to align (which they didn’t use to).

      1. Phil Marsh

        How big an issue it is may depend on the user and the use. One suggested use for the product is “landscape visualisation”. The landscape is not made up of 50m squares and the detailed raster base maps have pixels representing less than 50m. So if one wants to plot some sort of continous function (e.g. height indicated by a colour or shading computed from slope) then either one has to extrapolate 25 metres to the edges of the map or an extra row of DTM postings all round. The latter is not problem if one has the whole dataset but might be if buying a subset.

        Are resellers set up to provide as routine, say, a 50,000m square block of raster data and a ‘matching’ 50,100m square block of Terrain 50 ? Maybe not a big issue, but probably an inconvenience. For what applications is having the postings ‘cell centred’ better ?

      2. Alan Harris

        I tend to agree with you. If I was using the data myself I would use something like your approach and there wouldn’t be any problem.

        However, producing software for other people you have to be a lot more general. For example, a user will probably use a set of tiles, and they may be embedded (Terrain 5 or even independent lidar measured heights inside a Terrain 50 group). Basically it means that with raster you need to interpolate across tiles, which adds the extra complexity. I will probably have to program this in, but I have not had to do it yet for any other country.

  20. Pingback : How to view and query elevation models and other raster data | scottishsnow

  21. The Terrain 50 data has non-zero height values for the sea. I assume Terrain 5 is the same. While there may be a good reason for this, it means that it is impossible to identify the coastline and islands (a very useful function) if there are any positive heights in the sea.

    It is impossible to check for positive values without the coastline – catch 22. So are all the sea height values 0 or negative? If they are then the coastline can be identified. If not, is there a coastline definition available from the OS?

    1. Phil Marsh

      Tile SH53 has sea above zero. I was not going to ask about it until I had checked for others, but since Alan has commented I will chip in.

      Tidal regimes being as they are there is no reason why mean low water should not be above OS datum. Though I wonder if in the case of SH53 (NE corner of Cardigan Bay) the large tidal estuary with a narrow entrance at low water may be skewing the average and the open sea might not go that low.

      It would be useful to have the value used for each tile as a table (or in the metadata)to use when doing graphics like the one at the top of this page. It looks wrong when the sea comes out land-coloured !

      With some fiddling around it can be pulled out of the attribute data for the contours – but a list from the OS would be nice please !

      1. Melanie

        Hi Phil,
        I’ve passed your query onto our Product Management team and will get back to you with a response shortly.

    2. Melanie

      Hi Alan,
      I’ve passed your query onto our Product Management team and will get back to you with a response shortly.

  22. Jim Joyce

    Hi all,
    Just found this blog. It’s great.
    Dave Storey does things I would love to do.
    Back in July, he mentioned he had built a MegaDEM of the UK.
    He said it took only 30 minutes.

    I attempted a micro version of that, joining only 4 tiles.
    I reckon that took me the best part of 30 minutes, copying and pasting into Excel. I’m sure Dave has a better method.

    Would he be willing to share his secret?

    1. dave storey

      Yep, you can certainly have the code. Email me at gsv dot quik dot me dot .. not sure I can post VBA code here.

      For clarification, what I build is a BINARY random access file, from which you can look up the height at any position on the original mesh .. it isn’t an ASCII DEM, because that would be too big, and too much of a PITA to access randomly.

      The way I use it is for any arbitrary point (probably not on the mesh) I grab a 6*6 array of surrounding points, and calculate a height value from those (using a spline fit), but for most purposes just grabbing the one nearest point which is on the mesh would probably do (or you can have a 4*4 grid or 5*5 or whatever you want .. a 6*6 just happens to fit points to a curve where there are no abrupt slope changes from square to square in the mesh).

      Building the mega-dem (using VBA) is, as I said, fairly swift (assuming a PC with reasonable memory and CPU). Accessing it for a single point is fairly swift too – even for the 6*6 grid and curve fit, it isn’t too bad. The one thing which did take all day was re-reading every OS DEM file, and then getting what should have been the matching height from the mega-DEM to check it (that’s a LOT of random access file reads).

      Last point – the mega-DEM has height zero for any point not provided from OS DEM (i.e. sea areas and out of UK areas) .. this probably doesn’t match with the surrounding sea, which (as mentioned earlier in this blog) is quite likely to have +/- a few m altitude.

      Anyway, feel free to contact me.

  23. Dave Storey

    Dear OSGB .. is there a similar blog for non-terrain 50 Open data? I have a problem getting a sensible answer on the vectormap (ESRI shape file version) .. basically 11 or so weeks ago I reported that it has at least one road missing (a very old one, in the middle of Bishop’s Castle, Shropshire), and the product team confirmed the problem .. since when I’ve not managed to get anyone to tell me how it happened, how many roads (or other things) may also be missing, or when I can get a fix DVD (or just the patches). I have emailed, to no avail.

    Apart from anything else I’d like any other users of the product to be aware of the problems, before they route someone off the edge of the planet, or whatever.

    1. Gemma

      Hi Dave

      Sorry to hear about this. I’ll pass this on to my colleagues in Products and try and get an answer for you ASAP.

      Thanks, Gemma

    2. Gemma

      Hi Dave

      I’ve had a word with our Products team and they do apologise that this query seems to have slipped through the net. They have investigated and tell me that the road was incorrectly coded in our database and this has now been corrected. The changes made will be reflected in the next refresh in March 2014, although if there is an opportunity to provide an early release of the tile ahead of that, the team will do their best.

      Many thanks

  24. Jamie

    Hello – I’m not sure if this is the right place to ask questions about Terrain 50, but Stac an Armin (just off St Kilda) doesn’t seem to have any contours: NA151064. Will this be corrected in future updates?

    1. Gemma

      Hi Jamie

      I’ve passed this on to our Products team to have a look into, I’ll let you know when I have some more information.

      Thanks, Gemma

        1. Gemma

          Hi Jamie

          Our Products team have finished their investigation now and we regret to confirm that there is a small area of missing data that seems to have been caused by a software malfunction. We are reprocessing the data and it will be available in the next OS Terrain 50 product update, due in July 2014. Thank you for bringing this to our attention and we’re sorry if it’s caused you any inconvenience.

          Thanks, Gemma

  25. Dave Kenyon


    I’m trying to create a single DEM file of grid square SH. The intention is to output the merged model as an ASCII file and then convert this to a .stl file for further modelling.

    I’m using a program called Microdem and to ‘open and merge’ the original .asc files you supply. Unfortunately, the result has a ‘trench’ running East-West at the joins.

    Could you confirm whether this is a prblem with the data or perhaps my use of the Microdem software.


    1. Hi Dave

      I spoke to our Products team and they suspect that the problem may be caused by the fact that OS Terrain 50 is pixel centred, the data points start 25m in from the edges, so you could ask the chap to have a look at where Microdem positions the data. There is a detailed explanation in p.23 of the user guide http://www.ordnancesurvey.co.uk/docs/user-guides/os-terrain-50-user-guide.pdf

      You also may find some advice in our OS OpenData forum, if others are using similar programs: https://openspaceforums.ordnancesurvey.co.uk/openspaceforum/category.jspa?categoryID=4

      There is also an FAQ on pixel centred in the support page: http://www.ordnancesurvey.co.uk/business-and-government/help-and-support/products/terrain-50.html

      We hope one of those routes helps you, but do let me know if not and our Products team can have another discussion.

      Thanks, Gemma

    2. Dave Storey

      Looks to me like Microdem is expecting a “nodata_value -9999” line after the
      “cellsize” line, and (there not being one) is eating the first line of height data points. It then adds a line of zeroes to the bottom of the grid square.

      I’ve turned in a bug report to the author, so maybe it’ll get fixed. The 25m offsets might still be a minor problem, but less significant that a zero height trench under each mini-tile. Of course if OSGB would output large size .ASC dem files, instead of itsy-bitsy ones the problem would be less of an issue until you want to merge whole Grid Squares.

    1. Doug Chesterman

      Hi Rob – The link to the srtm1 version of the data doesn’t seem to work anymore. Do you know where I can find the data now? Thanks

    1. Hi Rob

      Huge apologies for the delay in responding, this comment seems to have slipped through the net while I was out of the office. I’ll check with the Products team and come back to you as soon as possible.

      Thanks, Gemma

  26. Steve Williams

    In my opinion the OS Terrain 50 user guide is still ambiguous/misleading with regards to the actual positioning of data points in the Ascii file. Please can you confirm my interpretation or advise errors:-
    * The xll and yll coordinates in the header refer to the lower left hand (southeast) corner of the tile.
    * The tile origin is at the northwest corner of the tile at ( xll, yll + 10000).
    * The first 50m x 50m pixel (cell might be a better word) is at the top left corner of the tile.
    * The 200th pixel is at the top right corner of the tile.
    * The 201st pixel is directly south of the 1st pixel.
    * If we imagine that height points plot at the centre of each pixel then a complete row of height points contains a first point with x = xll +25, followed by 199 intervals of 50m between height points and the last height point having x = xll + 10000 – 25.
    * The top left corner of the first pixel is at the tile origin ( xll , yll+10000).

    1. Hi Geoff

      OS Terrain 50 is only available in GML 3.2 and ASCII (DTM grid); GML 3.2 and Esri shapefile (Contours). We’ve passed your feedback along to the Product team though.

      Thanks, Gemma

Leave a Reply

Your email address will not be published. Required fields are marked *

Name* :

Email* :