Subscribe to this thread
Home - General / All posts - Another issue with projections in M9
drtees
158 post(s)
#14-Oct-22 15:26

In Manifold 8, I got into the habit of selecting only the part of a LiDAR file that was included in the general vicinity of a project. This way, I could manipulate the LiDAR data faster. Manifold 9 is astonishingly fast in its ability to create contours, filling sinks, and creating watersheds as well as merging two or more LiDAR files together when a project site is too close to the edge of one file. Even then, I still do not need the entire LiDAR dataset.

In M8, I would select that portion of the LiDAR file that I needed, copy, and then paste into the project window. The child set had the exact same location information as the parent file. The trouble with M9 is that this does not work. Copying a portion of a LiDAR file and pasting it into the Project pane creates a table. If I use that table to create an image, the projection information is permanently damaged. I cannot restore the parent projection to the child dataset. This includes creating a Favorite projection setting that overwrites metrics.

I've been using the latest Edge builds. I downloaded and installed the latest Base build to see if the issue existed there. It does.

I've attached a series of screen captures made as I tried to repair the projection of the child dataset to illustrate what is happening. The link includes the LiDAR file I was using. I understand that there is likely a script that would accomplish what I am trying to do. Unfortunately, my knowledge of SQL extends only slightly beyond knowing that the acronym stands for Structured Query Language.

https://www.dropbox.com/sh/u6fq62xho8fe7ln/AADQ6aIsSRPGRmP5WWbfNE3ta?dl=0

oeaulong

441 post(s)
#14-Oct-22 16:03

Did you have a specific question? Or are you looking to why your dataset zoomed to another location?

1. I think on your screen#3 you should have checked the box labeled "Custom unit scale"

Due to this, your resulting image was resampled to 1 meter per pixel, but in the Feet units. So the pixel size is now 2x what it should, as well as the offset was modified by the ft->m conversionX and saved. The resulting units are still feet, but the location has effectively migrated by the scaling * offset.

2.re: the copy/paste of a sub-image to another component. Use the Copy transform from the Transform pane. copy only the selection and create the result to a new table file & image. same thing, but streamlines it better.

cheers.

drtees
158 post(s)
#14-Oct-22 23:20

The specific question was; "How do I make this work?"

I am very comfortable with M8. I'd rather use M9 because of its speed.

Dimitri

7,115 post(s)
#15-Oct-22 06:35

Copying a portion of a LiDAR file and pasting it into the Project pane creates a table. If I use that table to create an image, the projection information is permanently damaged. I cannot restore the parent projection to the child dataset. This includes creating a Favorite projection setting that overwrites metrics.

This sounds like a series of procedural errors. You don't say precisely what you are doing so I cannot point to specific steps you might need to correct.

1. LiDAR data isn't an image, but a drawing of points. That means it is point data stored in a table that is visualized by a drawing. See the illustrations in the "Drawings and Tables" section of the Drawings topic.

2. The coordinate system in use by drawing's table is a property of the table, which you can see in the Properties dialog of the table (right-click the table in the project pane, choose Properties), as illustrated in the above Drawings topic. It's the FieldCoordSystem.Geom property.

3. When you copy points "from a LiDAR file" I presume you're copying points from the LiDAR drawing (that is the correct way). Pasting those points into the project creates a table.

4. If you want to create a drawing from that pasted table (note that you create a drawing, not an image), you have to say what coordinate system you want it to use. The easiest way to do that is to simply copy the value of the FieldCoordSystem.Geom property from the original LiDAR drawing's table, and then in the pasted table create a FieldCoordSystem.Geom property and paste the value from the original table into that. Takes but a few seconds and a couple of clicks. You can then create a drawing on that table (couple of clicks) and the correct coordinate system will be in use.

I just did that, using the sample Pentagon LiDAR data set that's used in examples and on the downloads page. Copy points from the drawing, paste into the Project pane as a table, copy and paste the FieldCoordSystem.Geom property's value into the new table and create a drawing. The pasting and adding the coord system and then creating the drawing takes a just a few clicks. Drag and drop the new drawing into a window showing the old drawing, and everything lines up perfectly.

Once you have a new LiDAR drawing that is a subset of the original data set, you can create images from that using whatever interpolation method you like.

If you have strong skills, you could create subsets from images, but to my mind that's not only the long way around asking for trouble if you overlook some detail, but it also loses accuracy since LiDAR data is vector point data, not pixel raster data.

One last thing, a minor detail although just about everybody ignores it: "the acronym stands for Structured Query Language."

Nope. It's not an acronym. See the Notes section of the Queries topic.

drtees
158 post(s)
#17-Oct-22 19:58

The technique I was trying to use was one that works perfectly in Manifold 8. I have since learned that there is a more elegant way to copy LiDAR data.

My use of terminology is the result of how M8 and M9 present LiDAR data. M8 imports LiDAR data as a surface with a distinct icon. M9 imports the data but uses the raster image icon.

As for SQL, I have known about this language since about 1989 when I was working for the US Forest Service. Until Manifold 9 came about, I had no need to learn it. I remember it being called "Structured Query Language" back then and remember seeing how-to books at the book store using the same verbiage. I am confused by the discussion of the term SQL meaning only SQL purportedly from IBM, which initially created the language in the 1970s. Here is a link from IBM.

https://www.ibm.com/docs/en/developer-for-zos/14.0.0?topic=support-what-is-sql

In any event, I can no longer avoid learning SQL if only for simple tasks. It is possible for this old dog to learn a new trick!

rk
566 post(s)
#17-Oct-22 20:22

You're talking about lidar-derived images/surfaces, right? You shouldn't call it lidar data. Lidar data is 3d points (and possibly several other attributes) and ratherlooks like this.

drtees
158 post(s)
#10-Nov-22 21:45

A set of 3D points is still data in the strictest sense of the word. Granted that it is presented as a raster image or a point cloud with each pixel or point having a value. That it has a value or values that can be manipulated satisfies the general criteria for being data.

I am looking at this primarily as a scientist attempting to know something about GIS!

tjhb
10,017 post(s)
#11-Nov-22 09:39

That wasn't Riivo's point.

His point was that LiDAR data is always points (or to be fussy, returns and their attributes).

If you have a raster, then it cannot be LiDAR data per se, but can be LiDAR-derived data.

It may seem like splitting hairs, I know.

The reason it matters is not really about LiDAR (though that often matters as well).

It's more about whether the data (whatever its source) is in point form or raster form, because the range of potential answers will be different in the two cases.

In your question, when you said "a LiDAR file", you implied points, which I suppose was a false lead, no big deal though.

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.