Orienteering NZ Wiki

A special form of a data source. LINZ has heights interpolated from the 20m topos on a regular grid. We can expect better and finer heights to become available from LIDAR surveys. This is about PROCESSING such data with our mapping software, we want to produce contours.

Koordinates have just released 15m DEM for all of new zealand, this is the best resolution dem we have so far

http://koordinates.com/search/category/contours-terrain/#/layers/category/contours-terrain/hillshades-terrain/?s=r

they are free, crop them to your specific area. The base data (photogrammetry) is the same as all the other national DEMs but it seems the process has been refined and 15 metres is the best resolution national grid we have now.

not sure if its useful or not just thought i'd let you know.

Thanks Simon, you got my hopes up that LINZ might have done something about its ancient terrain data. But no, seems to be a student project that interpolated the 20m topo contours onto a 15m grid, which is finer than what others have done. Guess its possible to generate say 10m contours from this. But GIGO.

But I'm curious and downloaded the Wgtn sheet, its a TIF. I would expect a DEM to be a text file containing XYZ values. The DEM menu in OCAD 10 won't import it. And neither will my graphic software open it. Any ideas? Simon, Map Guy, Linley you have played with DEMs?

OCAD10 Pro can generate contours and relief shading from DEM data.

I'll have a look at a trial bit around Taupo. I've used DEM data (asc files) to do both in the past.

I couldn't import the TIF into OCAD10 Pro. I tried a bit around New Plymouth as there isn't anything for Taupo - yet.

The Help section of OCAD suggests that we contact them to see if this format can be implemented into the software.

Problem solved! I downloaded the Gridded Raster as a ASCII Grid instead of a TIFF for a few square km in the Hutt Valley. Works well - neat relief shading too. Yet to compare with existing 20m contours.

Now I'm waiting for the rest of NZ to become available.

Thanks Map Guy, also Jason who pointed out the Ascii option for download (doh!) Tried generating some 10's out of the DEM and find the in-betweens have a lot less detail than the 20's as you would expect. The OCAD-generated 20's match the topo 20's reasonably well which is a check on the mathematical process. I've still got some nitty gritty questions, email me if you want to take part in this exploration.

Some mappers now have experience with the 15m DEM (digital elevation model on a 15m grid) which was interpolated from the topo 20's by Otago Uni Surveying School. It is available on Koordinates. The potential of this is that OCAD v10 can interpolate contours at a given interval from this, say 10m contours.

Koordinates have fixed a bug which created random zeroes when you cropped a rectangle of interest. There still appears to be a systematic shift in the data of up to one grid interval to the west and to the south, when compared to say 20m contours obtained directly. It might be the cropping, it might be the way OCAD treats things. Regenerating the 20's, they don't look to bad although there's some loss of definition. Creating 10's, the in-between ones don't have nearly the ins and outs of the 20's. But it saves you drawing them yourself, if you want a starting point and you don't have anything else.

Jason Markham is one of those who have been experimenting with DEMs. He can't post at present but asks:

Tasman District Council (TDC) have provided Lidar data of the St Arnaud area which the Nelson club will use for a new basemap. Yeah! The data has been provided in ASCII .xyz format (lat, long and elevation) except there is a fourth column of integer values at the end of each row. This column doesn't seem to represent anything concerning the topography as the values range between 1 and 74 (in a non-random distribution with 1 being most frequent and 74 the least). TDC geodata staff haven't been able to enlighten me about this yet.

What does this fourth value represent? Should I delete it before converting the DEM to contours in OCAD?

The 4th column is a measure of intensity

… intensity of what Martin? And what does it mean for the x, y and z?

Quoting from ESRI: http://www.esri.com/news/arcuser/0103/lidar.html “The intensity value is a measure of the return signal strength. It measures the peak amplitude of return pulses as they are reflected back from the target to the detector of the LIDAR system. Intensity values are relative rather than absolute and vary with altitude, atmospheric conditions, directional reflectance properties, and the reflectivity of the target.”

Also… “the ability to generate photographic images from LIDAR intensity data is not widely known”

It appears to be used when LIDAR data is used to create images, for mapping I would delete it and use the x,y,z coordinates.

Thanks. Is it possible there are multiple returns with the same xyz, maybe this is how they can distinguish reflections from the treetops, ground etc. Though I would have thought a local body would use a surveying contractor, who would have filtered out erroneous and irrelevant data. Maybe if the resulting contours look noisy, select only the data with highest intensity.

There's now elevation data on an 8m grid on the LINZ Data Service, this is twice as fine as the previous best. That's fine horizontally not vertically, it has been compiled from the same source data (the LINZ 20m contours which are now pretty old hat). It may not be much better at finding the holy grail, er, generating contours finer than 20m where you don't have photogrammetry or LIDAR. Anyone used it?

Got some and it works OK in terms of allowing OCAD to calculate contours. Always disappointing when the subtle shapes that we depend on to indicate spurs and valleys get lost in the interpolation processes. (I compared to the digitised 20m contours, which may even have lost something compared to the original topo, would they have been hand plotted?) Perhaps OK to fill in stuff where you don't have anything else, say just outside a council's LIDAR coverage.