Modelling archaeological layers as 3D polygons

[ArmandoMelo]

Dear all,

I’m new to this forum and new to 3D GIS, though I’ve been using ESRI software for some time. I am trying to use ArcMap and ArcScene to solve an archaeological issue: I need to link archaeological finds to their stratigraphic layers and excavation units.

I thought I could work with projections of the finds (points, XYZ data) and the layers/units (as 3d polygons) to cross information between both, by means of “select by location”, i.e. select all points that “are within” a certain layer or unit polygon. Indeed, I ended up with a selection of points/finds in ArcScene but apparently the elevation data of points was not taken into consideration, that is, all points within the polygon area (2D) were selected, regardless of their respective Z values. I also tried “Inside 3D”, with the same results.

So, my question at this point is: am I doing something wrong and/or skipping some important step of the process, or is ArcGis capable of/suitable for this type of operation at all? In other words, and assuming that my 3D projection of the finds (points) is correct (which would seem to be the case), are the polygons really 3D and Z aware, or only partly so, or not at all…?

Has anybody tried something like this before? Any contributions or comments would be much appreciated, I’m at a total loss right now. Thanks a lot for your time!

[XanderBakker · Accepted solution]

When working with 3D polygons (Z aware polygons) the polygon vertices may have a Z value, but the polygon does not have a volume. The tool Interpolate Polygon To Multipatch (3D Analyst), can create a Multipatch which has a volume.

When you have multi patches, you can use Inside 3D (3D Analyst) to determine if they are inside.

[ArmandoMelo]

Many thanks for a quick and clear reply. OK, I was afraid 3D polygons did

not really have a volume, now I know for sure...!

I have tried your suggestion but no results so far, apparently I cannot use

it with my previously extruded polygons and as the tool only accepts one

input surface, I don't see how I can get the right kind of volume, as I

have to include the top and bottom surfaces of each volume, according to

field data (XYZ topographic points). Those surfaces are the stratigraphic

limits of layers or excavation units.

Anyway, I tried before with multipatches, I used "enclose" and/or checked

with "is closed" and also tried "inside 3D", but the resulting selection

of finds/points always includes points that are way above the polygon.

Actually, all points within the polygon's XY area are always included,

regardless of their Z values. BTW, the point feature class does include Z

values and projects OK in ArcScene.

[VictorKlinkenberg]

Hi Amando,

I have struggled with the same issues in the past, also in an archaeological context. I haven't tried these operations yet with arcgis 10 but I recognise your problems from previous versions.

One possible solution: have you made sure that your point feature class is 3D (so not Z as attribute data)?

Let me know if you found an answer to these issues!

Victor

[ArmandoMelo]

Hi Victor,

Thanks for your interest, I'm glad to see that someone else faces the same issues. Thanks also for the solution, indeed in my early attempts the point feature class was not 3D but at a certain stage I also thought that this could be the problem and made it 3D, using 3D Analyst's "Feature to 3D by attribute", and the Shape field now is "Point ZM" so it should be 3D, but the selection still doesn't work right.

BTW, I've been reviewing some recent litterature on the subject of GIS uses in Archaeology and came across some interesting papers, namely Preparing the Paliambela Kolindros Archaeological Project digital archive for long term preservation by Marcos Katsianis (2012), who quotes from Alistair Ford's (2007)

Visualizing Integrated Three-Dimensional Datasets. Modelling data in the geodatabase using multipatch features. According to Ford, and as Xander rightly pointed out, the solution is using Multipatch features, so that "(...) spatial entities can be represented with true three-dimensional features and still be queried and selected and have full attribute data (...)". But Ford also refers that "The multipatch feature cannot be created in normal edit sessions in ArcMap as with the standard ESRI geometry types. These features must be created using ArcObjects (...) or from raw data sources."

Unfortunately, this sounds a bit "out of my way", I'm only an archaeologist and software user, and by no means a programmer or developer. I'm really looking for some straightforward solution, without having to become proficient in external 3D software and/or programming languages, but I'm starting to think that there isn't one right now... Anyway, I hope those papers may be of some interest to you or anyone else on GeoNet, I'll keep searching and I'll certainly post any solutions or useful information, or a friendly goodbye message when I give up...! Thanks for your time!

[XanderBakker]

If you're willing to share a small part of your data (or if you can generate some dummy data following the same format) I could have a look if with some python coding the stratigraphic layers and excavation units can be extracted.

[ArmandoMelo]

Hi Xander, Victor & All,

Folks, I think I have good news! The solution seems to be: surface TINs+Area polygon>Extrude Between>Interpolate Polygon to Multipatch>Enclose Multipatch>Is closed 3D>Inside 3D AND 3D points!! I guess the latter should have been obvious from the start, but I didn't realize it until later on and I didn't repeat the Inside 3D step until just now. That´s why I told Xander that it didn'y work either, sorry about that, a clear case of beginner mistake!

So, it was really both your answers that put me in the right path, thanks a lot guys! I still have to double check the results and still have to deal with some outliers, but this time it's XY, not Z, outliers, and certainly caused by the need to edit my surface TINs to ensure total area coverage, this should take care of all outliers.

OK, it's not the ideal solution, it would be better if I could get a selection directly on my finds/points feature class. With Inside 3D what you get is a table, so next I have to join both tables and then "display XY data" to check the results, but it seems to be A solution - in other words, that's one small step for the GIS Community, one giant leap for Armando...

As I've been trying and experimenting a lot, my map and scene documents are full of "noise", so what I'll do is improve my input data and start fresh on new documents, making sure that I write down every step so that I can post the whole sequence+results+issues in case someone else finds it useful.

Xander, thanks a lot for your offer, I really appreciate that! I could send you the following, for a small experiment:

- the topographic data pertaining to the upper and lower boundaries of a particular archaeological unit (XYZ points), as a feature class and/or an excell table

- the corresponding top and bottom surface TINs

- an excavation area polygon (2D)

- a sample finds feature class (XYZ points; again, feature class and/or table), possibly including finds that definitely belong to that archaeological unit and others that definitely don't, to see if the selection method (whichever) only selects the former?

These would be "raw data", from ArcMap. If you prefer, I could send the extruded polygon and 3D finds feature class as well or instead. Please let me know if this would be enough or you need something else/more/different. Cheers!

[XanderBakker]

If you can include all the data you mentioned (for a representative part), I can have a look what the possibilities are. No promises though...

[VictorKlinkenberg]

Hi Armando, that is good news indeed. I guess the main thing is that all parameters are properly taken care off in this situation (points truly 3D, use of closed multipatches, etc.) I'll be sure to see if this will work with some old datasets I used to try this on.

One question though, how did you create your excavation surfaces? did you use surface measurements or section drawings perhaps? I have found that the simple linear interpolation of TINS may result in oversimplified surface models if not enough measurements are given. In my case, using measurements from section drawings, the simple interpolation did no justice to the complex original surfaces. As finds are often located close to the lower surface of a deposit this meant many finds were allocated to the wrong horizon.

Anyway, good to hear you succeeded!

Victor

[ArmandoMelo]

Hi Victor, Xander and All,

I’m very sorry for the delay, other things got in between and I’ve been in and out of connection due to heavy storms. Still, I managed to work some more on the GIS project and retrace my steps on “clean” documents. Inside 3D definitely works, so:

Victor – I’m real glad you find this useful, please keep me briefed on your results/issues and on any developments/improvements of the method, I’m very interested, thanks in advance. My topographic points are actual surface measurements taken as-we-dig, not elevations from profiles or cross-sections. The resolution changes between different stages of the excavation, from 9 points per square meter on the earlier “sondage” phase to an average of 20 points for an area of some 11 square meters, which is not much but still seems to produce reasonably accurate surface TINs. I have draped georeferenced photos of the surfaces over the TINs and also over the extruded polygons, with satisfying results in terms of the correspondence between surface features and TIN elevation. But this is a very good point, if TINs are oversimplified, the whole method is a waste of time, as it will produce misleading results. And yes, finds located close to the boundaries of a deposit are an issue, even during excavation, because the deposit in this particular site is a mostly loose, sandy sediment with a strong probability of small-scale vertical migration of finds between occupation horizons. I still have to decide how to deal with the issue…

Xander – I’m sending you the data and I really appreciate your willingness. No major expectations, it would just be great that you could give it a try, if and when you can spare the time. Even negative results would be welcome, at least I would know it is a “no can do” thing!

What I have achieved so far goes like this:

Question:

Which finds belong to each archaeological unit?

Data:

• Point feature classes (XYZ, Shape=Point ZM) with the topographic points corresponding to the top and bottom surfaces of each archaeological unit (OH – occupation horizon)
• Point feature class (XYZ, Shape=Point ZM) with the finds
• Polygon feature class (2D) covering the excavation area

Method (ArcScene):

• Create TINs for each OH surface (top and bottom) [ArcToolbox>3D Analyst Tools>Data Management>TIN>Create TIN]
• Create individual 3D polygons for each OH, with the corresponding surface TINs as “Input TINs” (top and bottom) and the 2D excavation area polygon as the “Input Feature Class”; this seems to work better if the first input TIN is the bottom surface [ArcToolbox>3D Analyst Tools>Triangulated Surface>Extrude between]
• Close the resulting 3D polygons [ArcToolbox>3D Features>Enclose Multipatch]
• Check whether it is totally closed using “Is Closed 3D” [ArcToolbox>3D Features>Is Closed 3D]
• Run “Inside 3D” to Identify the “finds” points that belong to each 3D polygon, using the “finds” feature class as the “Input Feature Class” and one of the 3D “OH” polygons as the “Input Multipatch Features”; the output is a table [ArcToolbox>3D Features>Inside 3D]
• Join the “finds” feature class table with the “Inside 3D” output table, using the FID field from the former and the TARGET ID field from the latter
• On the “finds” feature class table, select all points marked as “Inside” to see a projection of the finds belonging to that particular OH

This time around I skipped the “Interpolate Polygon to Multipatch” step, as the extruded polygons are already multipatch features. I still have to do more testing, in order to check the real need to close the multipatches. “Inside 3D” seems to work with not-closed polygons as well but I would have to compare results from different attempts to see what is more accurate. I have tried the above method a few times by now and it seems to work, but I would stress the need for more testing and comparing results at this stage. The method must be totally accurate or else it is useless to me – no data is better than bad data!

I’ll keep you informed of further developments, any comments/improvements would be much appreciated, thanks for your time.

Armando