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

Geometry cannot have Z values error when packaging a mobile map

GWThompson

So I am having an issue when packaging a mobile map for offline viewing. This is a package that I normally do every week, but just recently I have started getting the Z value error

unfortunately the error message isn't very helpful, and the log doesn't show much either

Through trial and error I narrowed it down to one layer, and checking out the layer it doesn't have Z or M values enabled, yet I am still getting the error

I've tried creating a new feature class and copying records over, tried deleting the last 2 months of new/edited records. I've ran the repair geometry tool which fixed some lines with short sections, and one null geometry, but still did not solve the problem.

Any ideas???

Find more posts tagged with

Accepted answers

All comments

Eugene_Adkins

By chance, do you have a field in that layer that actually has z value data entered? I don’t know if you’re creating this data from scratch, but if the data is preexisting then perhaps it was created when z values were aware?

GWThompson

the data comes from an enterprise geodatabase, and same thing, no Z values anywhere. The only geometry field is a standard line type. I'm guessing the field type would be geometry if there was something that changed in the schema with a z value field

There are about 25 layers that are part of the map, and there is only the one layer causing the issue. I'm assuming there is some errant data that is causing the issue, but like I said I tried deleting records from the past 2 months just to rule that out.

Hornbydd

This is a wild guess, so your geometry has no Z-values which you clearly show. Does the coordinate system of this Feature Class have a vertical coordinate system and could that be the problem?

So here is a screen shot of a dummy dataset where I have set the coordinate system to be British National grid and set its vertical coordinate system to be Newlyn. In ArcPro you can quickly check that the VCS has been set by looking at the layer properties, example below.

KK_CCLP

Hey there. Having a similar issue. Did you find a solution?

RobertKain1

Any Solution? I am having the same issue here when packaging a project.

ChristineSeidel

Any solution to this issue? I'm having the same trouble. I've tried saving as a new ArcPro Project and then attempt to create the Map Package. - no luck. I've pasted the Map into a new Project & tried Map Package again. No luck. All the datasets are from various ArcGIS OnLine cloud sources. I'm trying to save the Map Package locally. None of the datasets have z values but still get this error. Thanks.

WardMitchell1

I don't know if this will help, but I ran into the same problem (which lead me to here). I search the ESRI error

ESRI response:

"Solution

Note:

While this error can occur, it occurs so rarely that the typical causes have not been identified so no solution is available at this time.

If you would use the feedback form to provide details about the steps you were using that led to this error, that will be helpful in identifying and providing a solution in the future."

That being said I exported the layer into my default GDB and I was able to publish the web layer.

EgorNozdrya

I am having the same issue and log file entry coded by an idiot - it does not not have reference for the layer causing the error

RoanokeDave

What's the fix? I just started getting this on a map package that I've created a dozen time before.

EgorNozdrya

For me, fix was to delete all online hosted feature service layers from the map/layer before packaging (or export 'em to file geodatabase first). In my case error message was completely misleading and issue has nothing to do with Z value.

ESRI Support reply was (though fix described did not work for me):
"Thank you for the update! This issue is associated with a known bug (BUG-000167727). This defect is currently in review status, and our team is actively investigating the issue. I will attach the defect to your case and you will be able to get updates on the defect from your My Esri Portal (My Esri > Support > Bugs and Enhancements).

I sincerely hope that this defect does not disrupt your operations. If you have any further questions or need additional assistance, please feel free to reach out."

Miralem_Zeljo

When is this issue getting resolved? Why would we not be able to package map with 3d layers or z enabled features?

RoanokeDave

I went through my layers and moved them one by one to a new map, and made a mobile map package and discovered which one is causing this. It's my parcels layer, so I can't really re-make that layer very easily. The Z values are inactive and the elevation is set to ground - I don't know where else to look for anything related to a Z value. What I MAY try next is to write a model that will export all of the layers to a local GDB with the Z values disabled, make the mobile map package, then delete the copies.

Miralem_Zeljo

Yeah. that is really frustrating. We had this issue when we were packaging layers or project package. This is really inconvenient especially if you have multiple layers with Z values. I hope esri gets this addressed quick.

Miralem_Zeljo

By the way, we have this problem with packaging standard map as well.

RoanokeDave

I feel like something Esri did as an enhancement cause this unintended consequence, because last October I made all the mobile map packages with this exact data and it worked fine.

Jeremy_Z

I was working on an update for BLM's National Recreation MMPK system and ran into this same problem yesterday. Took all day to figure out what happened and how to work around it. Essentially, I changed a layer, and added two new layers, so I knew it had to be one of these.

We exported the suspect layer by itself, and it worked, and none of the new layers showed Z or M values enabled or present in the Attribute Table. What we did find though, the GNIS dataset from USGS has a vertical reference system defined for it.

PROJECT! Re-Projecting the data didn't work, for some reason we kept getting an error that it couldn't begin writing, no matter what settings we used. In the end, I created a new GDB, with a feature class in it in Web Mercator, and then used the IMPORT function to bring in the affected data without the vertical reference.

I imported my symbology from a .lyrx file I made, and now can export again.

SCCOGGIS

Same Problem - never used to run into these issues, or at least the error message was more clear.

RoanokeDave

In a discussion with a colleague, I was told of another bug with z-values. It seems that if you have a multi-part true curve there are issues with it not being z-aware - and our issue seems to be if it IS z-aware:

BUG-000170356: Unable to modify hosted feature layer with multipart true curves https://lnkd.in/gYSKqpu7

BUG-000175572: 'Geometry cannot have Z values' error returned when attempting to edit the geometry (Move, Rotate, etc.) of ArcGIS Online hosted feature layers that are not z-aware

Is it possible that the addition of true curves was the trigger that did something to the z-value processing that caused the mobile map package error?

Miralem_Zeljo

That is really interesting observation. I will be testing this myself.

Jeremy_Z

Not in my case.

BrianHall7

This just fixed the issue for me. Re-sourced a boundaries layer from the ArcOnline-hosted version to a local geodatabase version. I was then able to publish.

AveryCook2

I was also having the same error when packaging a project package. None of the layers had Z values or a vertical coordinate system. I was not able to clear the error, but was able to find a work around by selecting the "Upload Package to Online Account" option rather than saving to file. The Project Package tool did not throw an error when packaging and uploading. Then could just download the package from my AGOL account.

RoanokeDave

A year later and I'm still looking for a fix. The workaround the I use is to make a temporary file geodatabase, making sure to set the Z values to Disabled! Then I wrote a model that copies all of the layers into the temp GDB. What makes this less of a pain now is that I can go to my real map with the real feature layers and click Copy, then in the map where I reconstruct everything with the files from the temp GDB I can hit "Paste Properties" and get everything set up like I want. Then package with success.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

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