topic Re: Unable to Import 3D Files with real-world position in 3D Questions

Unable to Import 3D Files with real-world position

ChristopherWebb — Fri, 10 Dec 2021 22:10:26 GMT

The following link identifies a method of importing one or more 3D models into a multipatch feature class.

http://resources.arcgis.com/en/help/main/10.1/index.html#//00q900000097000000

Test Case

I have thus implemented this using arcpy in the following test case to import 2 OpenFlight files from 'D:\foo', (test1.flt and test2.flt): -

# check out 3d analyst license

# use the appropriate reference system
spacial_ref = arcpy.SpatialReference()
spacial_ref.factoryCode = 4326 # WGS84 http://spatialreference.org/ref/epsg/4326/
spacial_ref.create()

# create the database
arcpy.CreateFileGDB_management("D:\\", "bar.gdb")

# create a point feature class to act as the 'in_featureClass' parameter
arcpy.CreateFeatureclass_management("D:\\bar.gdb", "qux", "POINT", spatial_reference = spacial_ref)

# Add a field in the point feature class that will contain the name of the 3d file
arcpy.AddField_management("D:\\bar.gdb\\qux", "OFNAME", "TEXT")

with arcpy.da.InsertCursor("D:\\bar.gdb\\qux",("OFNAME", "SHAPE@XY")) as cursor:
    cursor.insertRow(("test1.flt", (52.1, 4.0)))
    cursor.insertRow(("test2.flt", (52.2, 4.1)))

# Import the files using the point feature class and specifying the symbol_field
arcpy.Import3DFiles_3d("D:\\foo", "D:\\bar.gdb\\baz", spatial_reference = spacial_ref, file_suffix = "flt", in_featureClass = "D:\\bar.gdb\\qux", symbol_field = "OFNAME")

# check in 3d analyst license

This indeed creates the bar.gdb which includes the point feature class, 'qux' and the imported openflight models, 'baz'.

The confusing part, for me, is that the point feature class indeed does show the points at the correct positions, i.e. 52.1, 4.0 and 52.2, 4.1, whilst the imported models do not. They appear on top of each other at 0,0.

Why do I think what I should have done works?

The following quote from the link above states that an optional in_featureClass can be specified: -

The point features whose coordinates define the real-world position of the input files. Each input file will be matched to its corresponding point based on the file names stored in the Symbol Field. The Coordinate System parameter should be defined to match the spatial reference of the points.

Is this not what I have done? I have specified the symbol_field as specified by: -

The field in the point features containing the name of the 3D file associated with each point.

Question

There seems to be no examples in the ArcGIS Resources section that shows these optional parameters being used and so far the code I have written above does not place the input files at their correct, 'real-world' position. Does anyone have any working example of this or could provide some insight as to why my input OpenFlight files are appearing at 0,0 instead of the points specified by the point feature class?

Re: Unable to Import 3D Files with real-world position

TimBarnes — Fri, 10 Dec 2021 22:10:29 GMT

The help lists the syntax as: Import3DFiles_3d (in_files, out_featureClass, {root_per_feature}, {spatial_reference}, {y_is_up}, {file_suffix}, {in_featureClass}, {symbol_field})

It appears you have missed one parameter and incorrectly specified the optional parameters:
Note that you don't need to type out the 'in_featureClass =' etc, just add the string or variable in the correct location
Also, the parameters are read in order meaning you either need to specify one of the available options (i.e "Z_IS_UP") or accept the default option ("#")- You still need to put something there otherwise your parameters will get mixed up.

So I think you should have:

# Import the files using the point feature class and specifying the symbol_field
arcpy.Import3DFiles_3d("D:\\foo", "D:\\bar.gdb\\baz", spacial_ref, "Z_IS_UP", "flt", "D:\\bar.gdb\\qux", "OFNAME")

Re: Unable to Import 3D Files with real-world position

ChristopherWebb — Mon, 24 Feb 2014 06:57:23 GMT

Hello timmo1982,

In Python, you may specify optional parameters by using their parameter name as I have done. The documentation states optional for the y_is_up parameter, thus for my scenario, the default value will suffice, surely?

See http://www.diveintopython.net/power_of_introspection/optional_arguments.html, specifically: -

But in Python, arguments can be specified by name, in any order.

Are you suggesting that I have to use a hash instead of not specifying anything for an optional parameter? If so, that's very counter-intuitive and seems contrary to the design principles of Python, specifically as there is a mechanism for this.

Regards,

Chris