|
IDEA
|
Any updates on BUG-000112514? The latest Pro 2.3.2 still has the bug.
... View more
05-01-2019
11:34 AM
|
0
|
1
|
3454
|
|
POST
|
I've been doing this in File Geodatabases, so I just tried this out in SDE with all 3 scenarios of index, and they all worked: index, Unique = Yes no index index, Unique = No I can't replicate the issue with index scenarios. It would be interesting to see if you can create a new FC in SDE, add GlobalIDs, and then append the data again for each of those indexing scenarios I just outlined above. If yours works with the "index, Unique = Yes", and not the other two below it, that would be an interesting result. I would then repeat the experiment with a File Geodatabase target instead of SDE. But if you can successfully preserve GlobalIDs across all 3 index scenarios in SDE, then my guess would be that something was corrupted with the original feature class index you witnessed the non-preservation of GlobalIDs with, and that by deleting the original index and recreating it, the corruption disappeared along with the bad index, and it has nothing to do with "Unique = Yes/No". If you're happy with the result you have now, by no means feel you need to satisfy my curiosity about the scenario. My motivation is find where the flaw is. It's how I roll. 😉
... View more
04-18-2019
10:55 AM
|
1
|
2
|
3216
|
|
POST
|
I don't think so. I'm in 2.3.2 and the issue still occurs. I had to close Pro and reopen for snapping to work again while creating new features. I hope 2.4 solves this bug.
... View more
04-18-2019
09:47 AM
|
0
|
0
|
2814
|
|
POST
|
I just tried this in Pro, and it worked with no index at all for GlobalID. Indexing is only used for speeding up queries so it makes sense that an index shouldn't actually be required in order to append data to a field. I tried adding a GlobalID field in ArcCatalog, and it also generates an index for the field with Unique marked as 'No'. I really don't think the index has anything to do with it. Are you using File Geodatabases, SDE geodatabases, or Personal Geodatabases?
... View more
04-17-2019
01:35 PM
|
0
|
4
|
3217
|
|
POST
|
My GlobalID index is marked as "No" for Unique, but it still worked. Does that same FC has an ObjectID field with an index set to Unique = 'Yes'? Mine does. I downloaded the FC from AGOL at one point, so perhaps that's
... View more
04-17-2019
11:46 AM
|
0
|
6
|
4377
|
|
POST
|
Interesting. The "Add Global IDs" tool adds the index automatically, so perhaps it was added manually or the index was removed by accident? Either way, glad you got it figured out!
... View more
04-17-2019
09:58 AM
|
1
|
8
|
4377
|
|
DOC
|
Great class Jack! I'm super excited to jump into our County's Parcel Fabric now and make some improvements.
... View more
04-17-2019
09:35 AM
|
0
|
0
|
1620
|
|
POST
|
If you want to add a new field, you need to add it to the source feature layer, where it will be visible and then update the view definition to make it visible in dependent hosted feature layer views. Hi Kelly, I'm currently attempting to this exact workflow, but despite the new field existing in the HFL, the new field is not a checkable option when trying to update the VL view definition. I'm forced to create an entirely new VL in order to see the new field. Is there currently any documentation that covers this particular workflow (i.e. Create new field in HFL, then make it available in pre-existing VL's based on that HFL)? Thanks!
... View more
09-12-2018
03:57 PM
|
0
|
1
|
2509
|
|
POST
|
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.
... View more
08-22-2018
09:42 AM
|
2
|
0
|
3694
|
|
POST
|
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!
... View more
05-11-2018
11:38 AM
|
0
|
1
|
1495
|
|
POST
|
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.
... View more
05-11-2018
11:20 AM
|
1
|
0
|
4376
|
|
POST
|
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.
... View more
04-23-2018
02:51 PM
|
0
|
1
|
6332
|
|
POST
|
Ha ha, yes, I did find that once I did some googling!
... View more
02-06-2018
01:50 PM
|
0
|
0
|
1636
|
|
POST
|
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 😉
... View more
02-06-2018
10:21 AM
|
3
|
5
|
2094
|
| Title | Kudos | Posted |
|---|---|---|
| 3 | 09-15-2025 01:02 PM | |
| 3 | 12-06-2024 08:27 AM | |
| 1 | 03-07-2024 09:45 AM | |
| 3 | 12-04-2024 11:38 AM | |
| 4 | 09-24-2024 12:05 PM |
| Online Status |
Offline
|
| Date Last Visited |
4 weeks ago
|