Discussion: Kartapullatin Error

Hello everyone,

I was processing some .las files with kartapullatin, and I got the following error:

GD Warning: one parameter to a memory allocation multiplication is negative or zero, failing operation gracefully gdImageCreate error at GD/Image.pm line 86.

Does anyone know if the problem is with my computer / the lidar / something else....?

It created this image, missing the vegitation and the cliffs. I've never had this problem before...

Is there any chance you ran out of memory during the image rendering process after all the main processing is done? (If you had anything open that uses a lot of memory, you might try closing those apps and running pullauta.exe again. If it was memory, it might work by just doing the final render without a lot of processing.)

How big is the las file?

Is there any chance it's in feet and you haven't reprojected the data or used scaling factors in the ini? (Typically 0.3048 for x, y, and z)

You might run lasinfo and look for clues in the txt report. Try

lasinfo -i filename.las -otxt

Then look at the output txt file.

Michael, I've sent you a separate note but for the public record I happen to know that the data being used here is not a complete las file. What I mean by that is that data only contains ground points with all other returns stripped out. I dont know the details of what the file looks like but I can only assume that's why KP is returning an error.

Michael, please contact me. I have an interesting possibility for you mapping and training in the Crowsnest Pass area. I do not have your e-mail address. Mine is in my profile.

Check in the temp folder that is created when you run the process. For the rockfaces, there should be 3 files: c2.png, c2g.dxf and c3g.dxf. There should also be a vegetation .png and .pgw file. You can import the dxf files into OCAD or OOM - c2g should give you the identified rockfaces. If those show where'd you expect to see them, the error is in the final image rendering process as cedarcreek suggested.

The .png files can be opened as background images - the .pgw are the georeference world files.

Not scaling from feet to meters will generally only give you more contours (5 foot versus 5 meters), more rockfaces/dotknolls/etc - which use more memory, but it should still process otherwise.

Thanks everyone! I checked the temp folder and opened up the .dxf files in OOM. The cliffs were still missing. I think that Jeff was right about the .las being separated and only having ground information. I don't think i ran out of memory for this the file was fairly small.

@gordhun I sent you and email, maybe check your spam...

99 I replied to your e-mail yesterday at 3:10 pm Ottawa time.

Ground-only input files should still make cliffs, right?

Any ideas why there are areas of white forest showing in the raster output?

White here is no ground points (any points) there.

I have converted DEM's to lidar ground points and processed it without crashes so I wonder what can be the problem here.

No, there is undergrowt stripes too. Maybe thre is some non gound points too after all?

Runner99 can you tell us where you got the files?

I got the files from someone in Ottawa who had access to the University of Carlton lidar data. I would have thought it should pick up cliffs with the ground data too, and idk why there are the little white bits.

Also in each package, there were directories of ground, and non-ground each with their own .las file. I tried running the non ground through KP and it came out messed up as a bunch of squiggly contours. It took a long long time to process also.

Can you Google Drive or Dropbox to me an example ground/non-ground of the tile location?

I'd want to but the data is not public, so I shouldn't post it online. The person who gave it to me doesn't want me posting it. I'll ask them, thanks!

You could lasmerge the files all together, then tile them. That might clean things up. Some 'lasinfo' on the files shared here might be useful, too, to see what's actually in there.

I tried running the non ground through KP and it came out messed up as a bunch of squiggly contours.

If here is no ground points KP should not produce any contours, most likely it will just crash. So there imust have been points classified as ground even if those are not ground.

You could try merging files and classifying them by the directory they were located. For example:

las2las -i ground.las -set_classification 2 -olaz -o new_ground.laz

las2las -i nonground.las -set_classification 4 -olaz -o new_nongound.laz

las2las -i new_*.laz -merged -olaz merged.laz

pullauta merged.laz

But I believe this cliff crash is something else, probably a bug. Maybe there is two points with same x and y coordinates but different z (rare but entirely possible if point density ist very high or amount of decimals is shortened to shrink file sizes) making some steepness calculations trying dividing by zero. I need to take look at this. Edit, such sharp spike will not make steepness calculation crash but the cliff direction calculation will. I don't need the file, Runner99 I'll make a version with a fix in couple of days for you to try it out.

Edit2, no, it's not the point over point thing. All of your points are classified as zero and some fallbacks results as all points being seen as ground when doing contours but the rest does not survive it. Some ground points as seen as low vegetation (stripes) and cliff calculation crash. If you merge files and set classification by folder it will be good.