Latest Contributions by alex_friant

‎08-22-2018

ArcGIS Pro has a nice tool called "Table to Excel" which allows you to export to an .XLS (if your table has less than 65535 records) or .XLSX, and it allows you to click a checkbox that states "Use field alias as column header". However, that checkbox is referring to the field alias registered with the feature class, not the table inside the map, as you see it. So, if you can use the field aliases as they are set in the feature class, that's a great tool to use. But if you've modified the field aliases in the table in your map, and then want those new ones, this tool won't work. However, if you're dataset isn't too large, you can still select all records, copy them, and then paste them directly into Excel. That preserves the alias column names you customized, as you see them in the map table. TL;DR: You can use Pro's "Table to Excel" tool, -OR- you can just select all records, and copy/paste directly into Excel from Pro.

‎05-11-2018

Thanks Brian! Wow, I did not expect that to work because the "Catalog Preview" pane is not a "newly added layer" in a "Map or Scene". To me this seems like an oversight or unintended consequence of that switch. In my opinion, they should rename the settings title to "Map, Scene, and Preview", as well as add verbiage to that checkbox section: "(affects Catalog Preview map as well)". I just don't see the connection otherwise. This is kind of unfortunate for users like me, who don't like layers turned on by default when added to a map because sometimes a layer could have hundreds of thousands of features, and if you are trying to do a lot of quick work, waiting for it to draw kind be a drag. Anyways, thanks again for pointing out this not so obvious setting effect. I greatly appreciate it!

‎05-11-2018

While this is a slightly different situation, it's similar in nature. Your feature class GLOBALID field needs to join to a GUID field in the standalone table. The standalone table should have it's own GLOBALID field, but that's just like the OBJECTID field: a unique id for each record. That's the way AGOL converts relationships between FC's and tables that join using OBJECTID, it adds a GUID and GLOBALID to the standalone table, a GLOBALID to the FC, and changes the relationship class to join this way FC.GLOBALID <----> TABLE.GUID So it makes sense that it won't let you use GLOBALID on both sides of the join because the GLOBALID values need to be unique inside a Geodatabase across all items.

‎04-23-2018

Thanks for that! To improve the user friendliness of this, Esri should provide a link under the Appearance ribbon to this "Add System Style" which is found under the Insert ribbon. In my opinion, if a user can delete a style group from the Symbology pane, they should be able to rectify that from the same pane. Thanks for posting this, it was very helpful.

‎02-06-2018

Ha ha, yes, I did find that once I did some googling!

‎02-06-2018

Oops! Thanks, my bad.

‎02-06-2018

Cut to the chase: If you attempt to import the arcgis module (or even parts of it) in your python script, then do not name your python script "pytest.py". You will see some very strange behavior and your script will fail. The name of your script will conflict with pandas initialization scripts, which just-so-happen to have a variable named "pytest". The Long Version (skip if you are squeamish): I have ArcGIS Pro 2.1 with the patch installed. I was troubleshooting a script and decided to create a simple python test script to figure out what was going on. I innocently named it "pytest.py". I suddenly started seeing strange errors I hadn't previously seen when attempting to execute my script. Okay, fine, I thought. Let me see if I can manually run these commands "import arcgis" in the Python Shell. What happened next made no sense at all - the Python Shell responds by re-running my "pytest.py" script and the same errors occurred! What? I was in a completely different session. So I uninstalled ArcGIS Pro, deleted the Python folder and reinstalled ArcGIS Pro. I opened the Python Shell and manually entered the command "import arcgis". Again, it responded by re-running my "pytest.py" script and errored out. This fried my brain. The day ended and I went home. After a long night of nightmares of Python acting weird, I came to work this morning and carefully examined the Traceback results. I saw that the Pandas package was reporting "AttributeError: module 'pytest' has no attribute 'mark'". It suddenly clicked: I decided to rename my script "mytest.py" and everything worked fine and the manual command errors also disappeared. It turns out that the name of your script will conflict with pandas initialization scripts, which is part of arcgis intialization, which just-so-happen have a variable named "pytest". I just thought I'd put this out there for the next poor soul who attempts to name a python test script "pytest.py" and import arcgis inside of it. And yes, I learned to pay more attention to traceback results 😉

‎01-05-2018

I don't see why not. The Append Tool should be scriptable, but I haven't had time to look into that yet. It's a good idea!

‎01-05-2018

Thomas, check out the update in my original post. I found a very simple, supported, non-hack way to do this using ArcGIS Pro.

‎12-05-2017

The data is to be hosted in AGOL eventually, so hacks won't work.

‎12-05-2017

After further testing, Mitch's solution won't work for us. The GUID field created doesn't autopopulate with a GUID in either ArcMap nor ArcGIS Online once deployed. Unless there is another trick to it, I'll have to stick to my original solution.

‎12-04-2017

Great answer, thanks! Your solution is better because once the change is made, then I never have to deal with the issue again after changing schemas. Thanks again.

‎10-30-2017

Just discovered that if you use these exact names in your input table, geocoding fails as well: SHAPE_STArea SHAPE_STLength The reason this is causing geocoding to fail is because the output is a POINT feature class, and when ArcGIS is attempting to generate a new feature class, it gets rejected because POINT feature classes aren't allowed to have those reserved field names. It makes sense, but it seems like the geocoding module should check for those things, like reserved field names, when you provide the input table and so not allow it to be used as an input table (maybe a red circle exclamation point thing ArcGIS GP tools are so fond of using when they anticipate an error with the input provided). Or at the very least, specifically tell the user in the error window that the input table contained field names that aren't allowed in a point feature class, instead of it being some mysterious issue (as this thread can attest to).

‎10-25-2017

I found this page searching for the same error: "There was an error trying to process this table" I didn't see my resolution here, so I thought I'd share it: If the address input table contains either one of the following field names, Geocoding the table will fail: SHAPE_STArea__ SHAPE_STLength__ Those are 2 underscore ('_' + '_') characters at the end of the field name. It has to be 2 underscores; 1 is no problem. It's a bug I'm going to document with Esri Support for our case. I got those fields because I was trying to create a small stand-alone test table based off a subset of feature attributes by exporting them from a feature attribute table. It took forever to figure out why the bug was occuring with perfect data, and I'm sure it's not a very common occurence, but if you have either one of those fields in your input CSV or stand-alone geodatabase table, Geocoding your table will fail.

‎10-10-2017

We would like to have a Hosted Feature Service (HFS) that we can have named AGOL users bring into ArcMap and do the "edit locally" and "sync back to server" workflow. However, we also need that HFS to be viewable as read-only to the Public. Is this possible? We've tried to set this up, but the only way to do the ArcMap local editing/sync thing is to make the HFS have the "Enable Editing" option turned on. And when you have Editing turned on with the HFS being available to the Public, then the anonymous Public can edit the data inside the HFS, which is not desireable. If you turn off Enable Editing, then we can't do the local editing/sync workflow. At this point, the only workflow that works is to have the GDB stored locally, permanently, and publish it out/overwrite the existing HFS with "Query" being the only capability checked, when we have updates. It works, but it's a one-way workflow, which we were hoping to avoid.

Online Status	Offline
Date Last Visited	Tuesday

My Ideas

Latest Contributions by alex_friant

Re: Export table using field alias as name, remove join table name from field name

Re: ArcGIS Pro 1.4 database data preview is blank. Anyone else seeing this too?

Re: Preserving a GlobalID while moving data between Feature Classes

Re: Lack of symbology styles in Pro

Re: Do not name your Python script "pytest.py" with ArcGIS Pro installed

Re: Do not name your Python script "pytest.py" with ArcGIS Pro installed

Do not name your Python script "pytest.py" with ArcGIS Pro installed

Re: Preserving a GlobalID while moving data between Feature Classes

Re: Preserving a GlobalID while moving data between Feature Classes

Re: Preserving a GlobalID while moving data between Feature Classes

Re: Preserving a GlobalID while moving data between Feature Classes

Re: Preserving a GlobalID while moving data between Feature Classes

Re: There was an error trying to process this table.

Re: There was an error trying to process this table.

Possible? Hosted Feature Service with named user "local editing/sync", Public read-only

Re: Can I create/design my fields in Excel and imp...

Re: New Experience Builder update (06/2023) - map ...

Re: The Homeless Point-in-Time Solution now requir...

Re: Error creating SQL label expression for Shape....

The Homeless Point-in-Time Solution now requires H...