nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Does Generalize Support 3D?

RyanCoodey

Trying to generalize some 3D lines, but it does not seem to obey the distance tolerance in the Z space. Documentation doesn't seem to say anything either way. Would like to confirm if the generalizer even supports 3D? If not, any recommendations on simplifying a 3D line?

Actually trying to do this in FME, but it was simplifying the same way... so using an ArcGIS GP was going to be the backup plan until it appears to not obey Z values either. Running 10.4 at the moment.

Thanks a lot!

Encontre mais publicações marcadas com

Accepted answers

All comments

FridjofSchmidt

I found what I was looking for. There is a Generalize3D method in the ArcObjects interface IPolycurve3D. It just hasn't been exposed in a toolbox tool.

FridjofSchmidt

Hi Dan,

Just found this discussion, and I have another application case where I would need 3D generalization. My customer maintains a road network and wants to print kilometrage on maps that can be used by car drivers and should be consistent with their trip meters. Since part of the network is in mountainous terrain, we decided to use 3D length derived from a 10m DGM and accumulate it in M values. In a first step, we get the Z component onto the road nethwork with the Interpolate Surface tool, so that we can calculate the 3D length. You might argue that this does not represent the "true" length of the road, but it is certainly closer to reality than the 2D length.

The tool densifies the road network with vertices at about every 10 m, blowing up the size of the dataset by about 100%. We now want to generalize the dataset to get rid of vertices that do not have an influence on 3D length and the M values - that is, vertices that fall on a straight line in 3D space (straight line in XY space and zero or constant slope).

My approach for now is this:

From the densified and 3D length calibrated road network, extract all vertices to points and add X, Y, Z, M attributes
Generalize the road network (all vertices on straight lines in the XY space will drop out)
Locate features along routes to get updated M values for the extracted vertices along the generalized routes
Determine the difference between M values before and after generalization - those points where the difference is greater than a tolerance value we need to add back (this is a subset of the points that dropped out before)
Re-calibrate the road network with its vertices plus the points identified in step 4 - this will add only the relevant vertices back

I still think that the Douglas Peucker algorithm should not be too difficult to be implemented in 3D space, so maybe I will give it a try some day as an alternative.

NeilAyres

If you can do that using fme, you are better than I am at calculating dx,dy.dz using that interface. Would love to see it when done.

But what is the spacing downhole of the survey? Is it really that sparse? After all, the interpolated 1ft values are rather imaginary anyway.

RyanCoodey

Hi Neil,

Yes, we do. Since we already had these interpolated curves we thought it simplest to just generalize those (until this issue of course). Just connecting the dots from the survey though would also be too far off. Was thinking we probably need to add some logic during this interpolation to just throw away points until it deviates the max tolerance in the either X, Y or Z space. We still need to hold onto the high precision line as well though so would have to output two versions at this point.

Or we could probably just build our own FME job to do something like this. Start with the first vertex then loop through all of them until it is greater than the tolerance along any axis. Then hold on to that coordinate and do the same looping to the next. And so on. That sound like a viable option?

Thanks much!

RyanCoodey

Dan, other than playing with Pro for about 10 minutes, I cannot say I have worked with it much. It had crossed my mind to check it out for this current issue... but thought it probably still used the same GP tools and calculations. If that is not the case, I will certainly check it out more?

FYI, the boreholes are not perfectly straight. Part of the problem with the generalize not obeying Zs is that it is straightening them out too much and deviating too far from the original line.

Thanks for all the help!

NeilAyres

Ryan,

do you have access to the original downhole survey data. This will be undoubtably more sparse than the interpolated curve fitting XYZ's you have now.

Could regenerate the drill trace using the survey dip, azimuth, depth.

DanPatterson_Retired

Ryan, so the boreholes have a fixed surface location and the X,Y,Z values represent their respective values with depth relative to the surface. Interesting. So in this context, one could be interested in maintaining a perfectly straight borehole or or to be able to monitor the positional and depth values if you were doing something like horizontal drilling.

Have you worked in ArcGIS Pro yet?

DanPatterson_Retired

They are working with vectors, so I am not sure of your point. Rasters and arrays are two different data structures which might share a often similar outward appearance visually but can be completely different conceptually and structurally.

AbdullahAnter

Yes that logically for vector, look to Ryan Coodey Question,Dan.

" Trying to generalize some 3D lines" is line Raster ??????

about cell size

when you get elevation from survey points , you shouldn't waste any one of them

for example, If I have 5 survey points in one meter square and adjust my cell size to 1 meter , that is meaning wasting for survey.

you should make your cell size not have more than one point ( In 3d modeling application).

So you should be carious for cell size and make it small enough to don't contain more than one point, and it will make the Lines smooth as far as survey enables us.

I'm not talking about dividing a cell pixel after creation a raster or increase pixels without varies data, Dan

because its output will be same pixel value and we will not see a difference.

DanPatterson_Retired

Abdullah...this is for vector, not raster

x,y,z data can be represented as either sparse or dense arrays and it is possible to generalize the array in the 3rd dimension, then extract those array elements that either deviate globally or sequentially from a specified value or within a range.

As a sparse array, you are not confined by a cell size which limits the spatial resolution to finite units since there is no requirement for equal locational spacing.

This type of analysis currently is the forte of analytical tools such as numpy, scipy, r etc which we are beginning to interface with arcmap.

RyanCoodey

Dan,

The majority of the lines are not straight nor do they follow any pattern. The lines are for wellbores starting at the surface and winding their way between geologic structures and other wellbores to a point thousands of feet below the surface. The means of getting there is manual and varies for each.

Abdullah,

The elevations are subsurface and come from survey points. A minimum curvature algorithm is used to closely generate the line between survey points. So a DEM wont work for us in this situation.

Thanks a lot guys!

AbdullahAnter

I think that generalization in the Z axis is depend on

The interpolation method for DEM creation
cell size ( small cell size make your 3d line more smooth )

After create DEM make your line get elevation from DEM surface.

layer properties > base heights >elevation from surface > floating on a custom surface

DanPatterson_Retired

I am curious now. Are your lines straight? or do they collectively follow a pattern?

I am thinking along the lines of your data forming a 3D array. It is easy to determine points of departure in the z direction, then generalize in the x,y based on that, perhaps rather than generalizing in the xy, first. If you have any more comments on the data form that would be interesting.

RyanCoodey

Hi Dan, thanks for that information.

We are basically after simplification based on proximity. We have ~60,000 3D lines each varying from 1,500 to 6,000 feet long. Each of these lines has a vertex at each foot along it, that's a lot! So after running the current generalize tool, a line might go from 2,000 vertices to 100. We just need the line to stay within a tolerance of about 1/2 a foot.

Our drivers for this are:

1. The performance on this dataset in ArcMap and ArcScene is tremendously better.

2. We need to intersect these 3D lines with 3D multipatchs... that intersection GP tool works great but takes many, many hours when run on the non-generalized dataset. The multipatches that are intersecting these lines change often so we have a nightly job to recalculate the intersections.

That's our reasoning for this at least. Thanks again for the help and if you or anyone might have any recommendations to solve this issue, that would be much appreciated.

DanPatterson_Retired

I will say no... generalization in 2D has some application such as data simplification based on proximity or duplicates.

I think to generalize in the Z axis would be a bit more complicated since one would presumably have to perform the generalization in the xy directions first.

Now will there be a counter-point???

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.