|
IDEA
|
Could Esri consider changing the "Exclude from Application Evaluation" flag so that it's more intuitive? A lot of people find that flag confusing. For example, change the flag to "Allow Application Evaluation". Thanks.
... View more
03-30-2022
01:02 PM
|
0
|
2
|
1648
|
|
BLOG
|
Is that link broken? It seems to just point to the "About Esri" page: https://www.esri.com/en-us/about/about-esri/overview
... View more
03-30-2022
10:16 AM
|
0
|
0
|
229
|
|
IDEA
|
Related: Attribute Rules Blog: Auto Snapping with Attribute rules during Editing
... View more
03-30-2022
09:54 AM
|
0
|
0
|
2427
|
|
BLOG
|
Regarding this blurb: In 2.7, we added the ability to assign an attribute rule to the shape field, which will allow the Arcade expression to return a geometry to update the $feature geometry. Is there any chance that's a typo? If I understand correctly, we can edit the geometry in version 2.6. Screenshots of Pro 2.6.8:
... View more
03-30-2022
09:52 AM
|
0
|
0
|
1420
|
|
POST
|
Thanks! Regarding: "...workflows similar to those implemented in ArcMap for editing non-versioned data." This is my understanding: Currently, in ArcMap, we can discard edits when editing unversioned data (but we can't undo). Currently, in ArcGIS Pro, we can't discard edits when editing unversioned data (we can't undo either). The edits get automatically saved (the save & discard buttons are greyed-out). And we don't seem to have the option of disabling auto-saving the edits either; it's already disabled by default : I'm still skeptical that future versions of ArcGIS Pro will allow undo of unversioned data. My guess is: it will only be possible to discard an edit session, not undo (consistent with how ArcMap works now). I would be very happy to be wrong though.
... View more
03-30-2022
09:37 AM
|
0
|
0
|
5538
|
|
POST
|
I have a multi-part polyline in an SDE.ST_GEOMETRY feature class (Oracle 18c EGDB). I've written a PL/SQL function that replaces the geometry's M-values with the cumulative length of the line. (My plan is to eventually create a database trigger that uses the function to update polyline geometries — when features get edited.) Input:
MULTILINESTRING M (( 0.0 5.0 -100000.0, 10.0 10.0 -100000.0, 30.0 0.0 -123),( 50.0 10.0 456, 60.0 10.0 789))
--select sde.st_astext(shape) from polylines
Output:
MULTILINESTRING M ((0 5 0, 10 10 11.18, 30 0 33.54),(50 10 33.54, 60 10 43.54))
--select m_as_length(shape) from polylines Question: The m_as_length() function works as expected. But I'm a PL/SQL novice, so I thought I'd ask: Can the script be improved? with
function pythagoras(x1 in number, y1 in number, x2 in number, y2 in number) return number is
begin
return round(sqrt( (x2 - x1) * (x2 - x1) + (y2 - y1) * (y2 - y1)), 2); -- Power is a slow function
end;
function m_as_length(shape in sde.st_geometry) return varchar2
is
result varchar2(32767);
vertex_set varchar2(32767);
oldX number;
oldY number;
newX number;
newY number;
line_len number := 0;
begin
for vPartIndex in 1..sde.st_geometry_operators.st_numgeometries_f(shape)
loop
vertex_set := null;
for vPointIndex in 1..sde.st_geometry_operators.st_numpoints_f(sde.st_geometry_operators.ST_GeometryN_f(shape,vPartIndex))
loop
newX := sde.st_geometry_operators.st_x_f(sde.st_geometry_operators.st_pointn_f(sde.st_geometry_operators.st_geometryn_f(shape,vPartIndex),vPointIndex));
newY := sde.st_geometry_operators.st_y_f(sde.st_geometry_operators.st_pointn_f(sde.st_geometry_operators.st_geometryn_f(shape,vPartIndex),vPointIndex));
if vPointIndex <> 1 then
line_len := line_len + pythagoras(oldX, oldY, newX, newY);
end if;
oldX := newX;
oldY := newY;
vertex_set := vertex_set || newX || ' ' || newY || ' ' || line_len || ', ';
end loop;
result := result || '(' || rtrim((vertex_set),', ') || '),';
end loop;
return 'MULTILINESTRING M (' || rtrim((result),',') || ')';
end;
select
m_as_length(shape)
from
polyline Related: Use SDE.ST_GEOMETRY functions in a custom function Explains why the function calls are so verbose: sde.st_geometry_operators.st_numgeometries_f. ST_GEOMETRY functions: st_numgeometries st_x st_startpoint st_geometryN st_numpoints st_pointn I'm aware that this sort of thing can be achieved with Arcade in ArcGIS Pro 2.6+. Even still, I want to learn how to do this in PL/SQL, for professional development reasons, and to have a plan B, for scenarios where Arcade won't work (due to compatibility issues, etc.). My FC is registered as versioned (with option to move edits to base). We don't use named versions, we only use the default version (so that we can undo/redo edits while editing). So in this case, using database triggers on a versioned FC shouldn't be an issue -- especially since we're exclusively working in the base FC -- and are using the "with base" option.
... View more
03-30-2022
07:17 AM
|
0
|
0
|
1208
|
|
POST
|
Instead of creating a custom integration mechanism, I wonder if you could do the following: Create a view in the GIS database that connects to Maximo via a dblink. In the view, generate fake rows for the missing GIS assets -- if those assets haven't already been changed to decommissioned in Maximo. Flag the rows in the view as status=decommissioned (all done dynamically in the view -- we're not creating any data here). Then sync those fake rows to Maximo as decommissioned assets. The view could contain your existing/real assets too -- not just the fake decommissioned ones. That way, you could use the out-of-box Maximo/GIS integration mechanism that already exists (the ArcGISDataSync cron). No customization would be required! Sounds a bit too good to be true... Edit: One possible problem with that idea: With the fake decommissioned rows, what about all the other attributes that exist on the Maximo side? The fake row would have nulls in all it's fields, which would overrite your Maximo info, so that's likely a problem. Some of those fields would be mandatory in Maximo (the integration would throw an error if you tried to sync nulls). And I would think there would be other valuable fields in Maximo where you'd want to keep that information...you wouldn't want to set those fields to null. You could grab the data from Maximo...for the missing fields...and put them in the GIS view..and sync the data back to Maximo. But now, this is feeling like a messy/bad idea. Oh well, it was worth saying it out loud. Just a side note: If I remember correctly, when you're syncing an asset to Maximo for the first time, I don't think the status can be decommissioned. I think the status needs to be ACTIVE or something like that -- for the first sync. You'd have to ask around for details if you thought it'd be an issue, although it sounds like it might not be an issue for you.
... View more
03-28-2022
08:24 AM
|
0
|
0
|
2091
|
|
POST
|
Some thoughts about your deletes idea: I don't think you could use the out-of-box Maximo Spatial integration mechanism (called the ArcGISDataSync cron task) for your deletes idea. Unless you got your consultant to customize the Java, but that sounds pretty terrible. You might need to do something like this in Maximo: Create a custom cron task or escalation -- to run a Python or JavaScript "automation script" on a schedule. The automation script would perform the logic you mentioned above (find GIS assets that have been deleted and mark them as decommissioned in Maximo). Would you connect to GIS using an HTTP call? Or a dblink? The automation script would update the appropriate Maximo records by changing the status to decommissioned. You might find this script interesting: Escalation: Email me if external web service returns any records (JSON) or if service is down. That script is totally different than what you want, but you still might be able to use parts of it. It makes HTTP calls to GIS on a schedule, which seems relevant. I'm not an expert on this stuff. I would definitely recommend bouncing your idea off the folks in the IBM Maximo Community. It's funny, at one point, I'd actually wondered if we'd create a custom Maximo/GIS integration mechanism ourselves, using logic similar to the above -- instead of using the OOB Maximo Spatial mechanism (ArcGISDataSync cron). That mechanism requires a lot of extra Maximo objects to be set up -- which is fiddly, when you have a lot of GIS layers to integrate. And it isn't customizable. I had wondered if we might use the custom mechanism idea mentioned above...since most of the work is already done in that script I mentioned: Escalation: Email me if external web service returns any records (JSON) or if service is down. We probably wouldn't have used it for asset integrations (not necessary in our case), but for integrating WOs from ArcGIS Collector/Field Maps...to Maximo. Either of the two methods would work (custom or ArcGISDataSync -- we tested the later and it worked fine). But it was still interesting to think about...what if we wanted to customize the integration? The automation script would be decent option, I think.
... View more
03-28-2022
08:10 AM
|
0
|
1
|
2091
|
|
POST
|
Thanks. It turns out, the compatibility issue is with license manager. I can upgrade Pro to version 2.6.8, but anything beyond that would be incompatible with our version of license manager.
... View more
03-28-2022
07:14 AM
|
0
|
1
|
7224
|
|
POST
|
Interesting idea! No, we hadn't looked into that. In our case, we already had a status field in most of our asset feature classes. For example, we have proposed and future assets in there too. So we're used to filtering on status...it comes naturally at this point.
... View more
03-28-2022
06:40 AM
|
1
|
0
|
2106
|
|
POST
|
Yeah, I think they just stay in Maximo forever. We have status fields in our GIS layers. When a GIS asset gets removed due to a road reconstruction, etc, we just change the status to something like removed, decommissioned, abandoned, inactive, etc. We use that status field to hide the removed GIS assets from various inspection maps, web maps, etc…via a definition query…so that they appear to be deleted. But really they’re just flagged as removed and hidden from sight. In our GIS db views for Maximo, we translate the GIS stratus to a Maximo status, such as Maximo’s decommissioned status. Alternatively, you can create a status “synonym” in Maximo.
... View more
03-25-2022
01:43 PM
|
0
|
4
|
3147
|
|
POST
|
If I've understood correctly (it's possible that I haven't), I think you're suggesting that all rows in all FCs be flagged as needing to be synced to Maximo. We wondered about that too...just sync everything...once a week or once a month. That would be nice and simple. The problem with that is that the Maximo Integration Framework (MIF) is relatively slow. A municipality like @BrianBulla's (or ours) has hundreds of thousands, possibly millions, of asset records. Unfortunately, it would take Maximo several days or even weeks to do a sync like that. So it wouldn't be feasible. The challenge is: How to flag new or updated GIS features -- so that only those changes, aka "the delta" are synced to Maximo. IBM's mechanisms for this sort of thing are naive/incorrect. A lot of organizations try to find alternatives. Companies like ActiveG and GeoNexus have made entire products for it.
... View more
03-25-2022
11:22 AM
|
1
|
0
|
2127
|
|
POST
|
Regarding triggers: No, we didn't investigate them. We have 20-40 GIS layers that we integrate to Maximo. Triggers on 40 layers seemed like it'd be a lot to manage. The db view option seemed simpler for our purposes. And as analysts, we could create and manage the views ourselves, whereas we'd need to get other staff involved with triggers, which would have taken extra time. The db views (and dblink) option I mentioned worked well for us. And like I said, we needed to translate the GIS data for Maximo anyway, so db views worked good for that too. Edit: I forgot to mention that we take the db views and export them to feature classes on a schedule. Reason: static feature classes are faster than views. Regarding deletes: If I remember correctly, once an asset is created (or integrated) in Maximo, Maximo won't allow us to delete it. We can only "decommission" it. So our hands were tied -- we had to come up with a "don't delete GIS assets, only flag them as decommissioned" business rule for our GIS technicians. We'll likely enforce that rule using ArcGIS Pro attribute rules. We've already done it for a couple of FCs. But it sounds like attribute rules aren't an option for you. Is your GIS data versioned? If so, then it isn't possible to allow edits, and at the same time, specifically prevent deletes. At least not through the ArcMap/ArcGIS Pro privilege settings for a given feature class. With that said, I did come up with a proof-of-concept db trigger that seemed to work with versioned feature classes. But my testing was limited (I didn't end up needing the trigger; we'll probably use attribute rules instead). Prevent deletes in a versioned table at the database level
... View more
03-25-2022
11:07 AM
|
0
|
6
|
3165
|
|
POST
|
Various other things to keep in mind: Regarding Maximo Spatial's MXCREATIONSTATE / sync mechanism: Bear in mind that when Maximo syncs a record, it will then update the MXCREATIONSTATE field in GIS to "successfully synced" or whatever the actual numeric code is (I can't remember). The problem with that is: I believe the edit will trigger editor tracking, since the edit is done through the ArcGIS REST API. So, if you were using that editor tracking field for other stuff in GIS, then it means that Maximo has compromised your editor tracking info. Your editor tracking will indicate the last time Maximo edited the field, not necessarily the last time a user edited the field. Maximo Spatial's cron task for syncing GIS records to Maximo sometimes fails. There are scenarios where it runs, but nothing happens -- no records are synced. So you don't want to use logic like the following: "If the last Maximo cron run date is less than the GIS last_edited_date, then sync the record". The last cron run date in Maximo will be misleading in that case...records likely failed to sync, and wouldn't be picked up in the next sync. If I remember correctly, GIS's editor tracking fields need to be set to UTC time -- for ArcGIS-specific reasons that I can't remember off hand. However, the time zone in Maximo will likely be different. So comparing date fields between the two systems/time zones can get messy. With that said, we put some thought into the logic at play, and didn't think the time zone thing would end up being a problem for us -- for our weekly asset syncs.
... View more
03-25-2022
07:44 AM
|
3
|
1
|
3192
|
|
POST
|
Ugh, Maximo Spatial. You poor soul. We took a deep dive with our Maximo/GIS integrations a couple of years ago. We abandoned most of the IBM mechanisms, including the MXCREATIONSTATE field thing. I honestly don’t know where to start. There are so many things I want to warn you about. @jcarlson is on the right track with the last_edited_date thing, as an alternative to MXCREATIONSTATE. We did it by using database views on our feature classes to generate a sync_needed field, in conjunction with a database link to the Maximo database: select ..., case when fc.last_edited_date > maximo_asset.lastsyncdate or maximo_asset.lastsyncdate is null then 1 else 0 end as sync_needed from gis_fc fc left join custom_maximo_owner.asset@gistomax maximo_asset --this is a dblink in the Maximo database that lets GIS select from the Maximo asset table on fc.asset_id = maximo_asset.assetnum --note: lastsyncdate is a custom field we created in the Maximo asset table. It's easy to populate that field with the Maximo system time using the &SYSDATE& default value: https://i.stack.imgur.com/2cNyk.png One additional benefit to using a db view in GIS is that you can translate/format your data before it gets to Maximo. That's potentially easier than trying to do the translation in Maximo's JSON Mapping application.
... View more
03-25-2022
07:14 AM
|
1
|
2
|
3193
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 03-20-2026 02:12 PM | |
| 1 | 03-19-2026 11:42 AM | |
| 1 | 06-03-2026 04:02 AM | |
| 1 | 03-18-2026 07:08 PM | |
| 2 | 3 weeks ago |