Skip to main content
  • EN

Hello,

I have one point cloud tile with extents, for example, of min (0,0) and max (1000, 1000).

I want to make a DEM from this point cloud, which seems pretty straightforward, but it isn't.

If I want a raster with a 1x1 cell size, the RasterDEMGenerator makes a DEM that has 1001x1001 pixels and extent min (-0.5,-0.5) max (1000.5,1000.5). The main problem is, that the values of the bounding pixels are not ok, as half of the pixel surface does not have corresponding points.

Is it anyhow possible to define that I simply want a DEM between 0,0 and 1000, 1000 (original point cloud extent) with cell size 1x1?

From my point of view, it just doesn't make sense to implement a "point cloud to DEM" solution that always takes half of a pixel size larger extent than the original point cloud extent, which is, of course,

 

empty (without points). I know how it works; the algorithm places the center of the left lowest DEM cell to the point of min extent of the input point cloud, and this is just wrong. I cannot imagine any case where

 

this approach would make sense. This always makes DEM with a "crippled" boundary all around that needs to be clipped to a smaller extent. Therefore I get only 999 x 999 pixels DEM that is useful with the extent of min (0.5, 0.5) and max (999.5, 999.5).

If I am not missing something here that enables me to do what I want, I suggest you implement that ASAP, as this results in many bad (wrong) results that people are mostly even not aware of.

Regards, Jernej

Hi @j_geo,

 

this actually works as it should. Point clouds and rasters are similar in many respects, but not identical. When you have a point cloud stretching from 0,0 to 1000,1000 with spacing 1 you actually have 1001 point along each side - points in a point cloud have no size of their own, only location. Pixels on the other hand, always have some size however tiny it might be. So, when we create a raster from a point cloud, we replace a sizeless object with an object of a certain size with some origin, which can be (and usually is) in the center of the cell. We create a pixel for each point as if buffer it with a tiny square (or a rectangle), and this is why the raster goes beyond the point cloud extents in all directions. If we would place the lower left pixel in 0,0, we'll end up with the upper right pixel going from 1000,1000 to 1001,1001.

 

 

To make it really simple, imagine a point cloud consisting of one point, which you need to turn into a raster - it absolutely will go outside of the original bounds of the point cloud.

 

 

We can't make a decision for a user to fit a raster into the "0,0,1000,1000" box because we simply don't know what users might actually want or need. We, however, give all the tools to handle this situation. A user can, for example, offset the DEM to the lower left corner of the original point cloud and then use Clipper or RasterSubsetter to get rid of the extra pixels.

 

 

Dmitri

Hi Dimitri, thank you for the answer.

I looked more into this and figured out that the problem is the poorly modeled surface that is apparently

 

the basis for DEM values calculation.

The issue has already been identified:

https://knowledge.safe.com/idea/35642/delineate-option-in-surfacemodellertingenerator.html

This is very problematic, as you are forced to clip and remove the outer ring of the raster pixels, as they do not have reliable values.

 

Regards, Jernej

Reply


Community Stats

30,110
Posts
114,303
Replies
37,745
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.