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; } } }

Problems displaying feature classes created via API in ArcMap

SimonWood

Hi,

I have noticed some problems when displaying feature classes in ArcMap that have been created and populated using the FileGDB API. Specifically, when I add such a feature class to ArcMap, nothing is being drawn (note: I am starting with nothing else displayed in ArcMap).

If I zoom out to the maximum then I can see the data and if I then zoom in, it is displayed where I expect it to be. If I zoom in beyond a certain amount (different for each layer - in the order of 1:600000), the data disappears again. "Zoom to layer" doesnt do anything. Ive checked min/max zoom levels for the layer and they are not set.

The data in the feature classes seems ok (it reads and displays fine via non ArcMap means).

I have attached a modified version of TableSchema.cpp that reproduces the problem. When the modified file is built and run, it adds 3 lines in the "streets" feature class that the test creates. When I display this feature class in ArcMap I dont see anything. If I change it to only create 1 shape (any of the three - it doesnt seem to matter which one), then the feature class does display ok in ArcMap.

Possibly I am creating the rows/shapes incorrectly in the feature class?

Thanks,
Simon

TableSchema.zip

Najděte více příspěvků označených jako

Accepted answers

All comments

SimonWood

Thanks,

The GridSizes were ok in my real code, but turns out I was setting XYScale too large for projected CRSs and this caused the same behaviour.
Once I fixed this up, its now all working ok in ArcMap (when creating using windows).

Thanks again,
Simon.

LanceShipman

The problem in this case is with the grid sizes that you defined in the .xml file. They are not valid. To fix this change:

<GridSize0>0.983688354492188</GridSize0>
<GridSize1>3.04943389892578</GridSize1>
<GridSize2>9.45324508666992</GridSize2>

To:

<GridSize0>0</GridSize0>
<GridSize1>0</GridSize1>
<GridSize2>0</GridSize2>

This is a flag to calculate the spatial index grid size based on the contained features. If you do this the feature class behaves correctly.

SimonWood

Messed around a bit using windows and found that using a geographic CRS does work ok, but using a projected CRS causes the same (or a very similar) problem to occur.

I have attached another zip which contains an updated xml table definition file - basically Streets.xml modified to use a projected CRS instead of geographic (I generated the spatial reference by creating a Feature Class using the desired projected CRS in ArcMap, dumping the defintion xml and then cutting and pasting into the Streets example xml). The zip also contains an updated source file which creates the same data as before, but uses equivalent projected coordinates instead of geographic.

I used VS2008 32 bit to compile and run.

When I display the generated AGD84/Z51 feature class in ArcMap it looks fine... However, if you zoom in past a point where the whole feature class is not visible, then everything disappears. If I try the same thing but generating a geographic feature class, then it works as expected and I can zoom in to the maximum permitted and still see the shape.

Cheers
Simon

TableSchema2.zip

SimonWood

So I tried my sample code using windows and it does work ok.
I will have to try and track down what is different between the two code paths.

Simon

SimonWood

Right...

I am definitely still seeing the same symptoms with FileGDBs generated by our application on windows as well (just retested it) - zooming in ArcMap doesnt work. I am using VS2008 / 32 bit, in case that is relevant.

I will try the sample code I posted on windows and see if I get the problem (it might be something different between the code path in our app and the way the sample code has been written).

Should I expect the extents to be correct when FileGDBs are created using the API on windows (ie using Table::GetExtents())? If so, I will see how they look.

Thanks,
Simon

LanceShipman

The problem from the other thread will only happen when the code is run on Linux. Display with ArcMap will be messed up if you zoom in. Data generated on Windows should not have this problem.

SimonWood

Yes... I built the sample code I posted on a 64 bit rhel6 machine, but compiled against 32 bit version of the 1.1 API (using ARCH=32).

I havent tried this sample code on windows, but I do see the same problem with feature classes that have been generated using our application on windows.

I also did try feature classes based on a projected CRS, and the reported extents were correct for these, but they still suffer from the same zooming problem in ArcMap.

I did occur to me that its possible that the problem is with ArcMap rather than the API - I was going to post the file geodatabase that doesnt work for me, and also make sure my ArcMap install is up-to-date.

Thanks,
Simon

LanceShipman

Are you using Linux?

SimonWood

I didnt change the Streets.xml - was using it as it was shipped (just double-checked this).

I should have mentioned that I was running this TableSchema based example on linux (64 bit rhel6 machine but compiling against 32 bit version of the 1.1 API using ARCH=32). I have observed the same problem on windows as well though (when running our full application).

I dont have access to ArcMap today, but will try modifying the ShapeBuffer example to make it write more than one shape and see if that also reproduces the problem.

I was also wondering if there is something weird going on with the extent of the feature class

The TableSchema example Streets.xml starts with the following:
<Extent xsi:nil="true"/>

After loading the three lines into it (as per my changes) and retrieving the table definition, the extent has not changed and is still: <Extent xsi:nil="true"/>

I added the following lines into (my) TableSchema.cpp (after the LoadOnlyMode(false) call):

Envelope env;
streetsTable.GetExtent(env);
wcout << fixed << setprecision(10)
        << env.xMin << " "
        << env.yMin << " "
        << env.xMax << " "
        << env.yMax << endl;

And this prints out:
123.0000000000 -32.0000000000 123.0000000000 -32.0000000000
Which seems wrong.

The coordinates I used were from a FileGDB Feature Class that I created in ArcMap. If I query the extent of that feature class I get the following:
123.191221922000 -32.917583554000 123.308169561000 -32.795342766000
Which is what I was expecting to see.

Possibly projected coordinates will work as expected.. I will try this tomorrow.

Thanks again,
Simon

LanceShipman

Using the 1.1 version of the API I'm not able to reproduce your issue. I can zoom in, zoom out, and zoom to layer. Did you change the xml? If so please post it.

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

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