So many errors with this tool. Sometimes simply copying the feature first fixes it. The error seems to occur randomly and these are so hard to pin down. This happens in both ArcGIS Desktop and ArcGIS Pro. These features are stored in a feature dataset. They are polygon features. If anyone has ideas on how to pin this issue down please let me know. For now I might just use esri2open instead (GitHub - project-open-data/esri2open: this repo is an ESRI toolbox and tool(s) that export ESRI Feat... )...wait...ArcGIS Desktop just crashed when trying to load the esri2open tool into my model. I would much rather use the built in tools but I am spending too much time trying to track this issue down.
Some of my ideas on this issue -
Is it related to multipart features?
Does it have an issue with extremely small polygons?
Something to do with starting with a feature stored inside a feature dataset?
Exporting to a shapefile first has fixed the issue for at least one feature.
I've been having the same issues. It's too bad no one got back to you.
I have a circle and a wedge.
The wedge will export.
The circle will not.
The merged circle and wedge also will not export.
Each time I get a 9999 error. It's confusing and frustrating.
Shapefile conversion worked as far as being able to run the command successfully. The true test is "Does it work in the program I'm importing it into?" (No, but that's a different issue)
When I performed a JSON to Feature class, it was a Polygon ZM type. I created a new feature class that was ZM enabled, and it still didn't work for me.
I'm curious about one thing:
I delved into the rfc7946 the GeoJSON spec after comparing two different program's outputs of GeoJSON. The ESRI output has 4 values per vertex.
From RFC 7946:
Implementations SHOULD NOT extend positions beyond three elements because the semantics of extra elements are unspecified and ambiguous. Historically, some implementations have used a fourth element to carry a linear referencing measure (sometimes denoted as "M") or a numerical timestamp, but in most situations a parser will not be able to properly interpret these values. The interpretation and meaning of additional elements is beyond the scope of this specification, and additional elements MAY be ignored by parsers. So why does ESRI have 4 elements?
I had a similar problem with the 3rd and 4th indices. They were causing this exception when trying to load the GeoJSON file as a dataLayer into google maps api.
"message": "in property \"features\": at index 0: in property \"geometry\": in property \"coordinates\": at index 0: at index 0: at index 3: not a number",
"stack": "Error\n at new bf (https://maps.googleapis.com/maps/api/js?.
The solution for me was to create a new projection Layer from the old layer using ArcMap software. In there you have the ArcToolbox, Under "Data Management Tools" there is "Projections and transformations." Under that you select "Project." Then you select the layer you want to re-create, select the coordinates system (pick something that will ultimately provide decimal degrees output) and under the Environments, disable the M and Z values. Once that layer is created, you can then choose another conversion tool (Features to JSON) select GeoJSON as the output file, and the Z and M values are greyed out because they are not available, and will not be included with the coordinate vertices.
For me there was an issue with the projection. Converting the file to WGS 1984 first or simply selecting the box "Project to WGS_1984" in the Features to JSON tool solved the problem.
If it only is working if you save to shapefile first, it may be because you have curves in your feature geometries: Error: 999999: Error executing function. Failed to execute (FeaturesToJSON) I don't know how to inspect a feature class to see if there are any curves are present, but I had the same issue and found the linked support guidance while troubleshooting. Saving as shapefile also solved the issue for me, so maybe it was curves, maybe something else?