Latest Contributions by Bud

I think it's a way of tricking SDE. If the system tables for that FC are broken, then if you create a new FC in it's place, SDE will replace the broken system table data with new system table data. So hopefully when you delete the new FC this time, the system table data will be deleted successfully too. And then the FC will disappear from Catalog, which is what you want.   My limited experience is: Sometimes these things take multiple attempts. And sometimes, if you just wait a few days, it resolves itself. I'm not an expert though. So I could be wrong. ... View more

After digging a bit more, I did come across a PDF that mentions 'MULTILINESTRING M': https://portal.ogc.org/files/?artifact_id=25355 (PDF download). Search the PDF for "MULTILINESTRING M". So, from that limited evidence, I suppose the extra M might be the correct syntax after all. Maybe the problem is SDO_GEOMETRY, not ST_GEOMETRY. Could Esri delete this idea? I don’t think I can delete it myself. ... View more

Esri confirmed it's a defect: BUG-000148390. ... View more

Thanks for the info. I talk more about my use case here: Practical GIS automation for non-IT users ... View more

For example, a query that generates rows for each vertex (3000 features):   1 SELECT a.ROAD_ID 2 ,b.NUMBERS VERTEX_INDEX 3 ,a.SDE.ST_X(SDE.ST_PointN(a.SHAPE, b.NUMBERS)) AS X 4 ,a.SDE.ST_Y(SDE.ST_PointN(a.SHAPE, b.NUMBERS)) AS Y 5 FROM ROAD a 6 CROSS JOIN NUMBERS b 7 WHERE b.NUMBERS <= SDE.ST_NumPoints(a.SHAPE) ---------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 5996 | 1545K| | 262 (1)| 00:00:01 | | 1 | MERGE JOIN | | 5996 | 1545K| | 262 (1)| 00:00:01 | | 2 | INDEX FULL SCAN | R23715_SDE_ROWID_UK | 30 | 90 | | 1 (0)| 00:00:01 | |* 3 | SORT JOIN | | 3997 | 1018K| 2392K| 261 (1)| 00:00:01 | | 4 | TABLE ACCESS FULL| ROAD | 3997 | 1018K| | 34 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- " 3 - access(""B"".""NUMBERS""<=""SDE"".""ST_NumPoints""(""A"".""SHAPE""))" " filter(""B"".""NUMBERS""<=""SDE"".""ST_NumPoints""(""A"".""SHAPE""))"   That query takes 30 seconds to run, which is far too long. In comparison, pretty much any other query on the FC runs instantly.   Testing/benchmarking: I created two tables (both contain 10,000 rows): ROADS_BM and ROADS_STARTPOINT_BM. I ran simple queries on the tables using each of the functions that are involved. Here are the results:   +-----------+------------------+---------------------------------------------------------------------------+ | TIME(sec) | RETURN TYPE | QUERY | +--------------+-----------+------------------+---------------------------------------------------------------------------+ | ST_X | < 0.5 | Double precision | SELECT ROAD_ID FROM ( | | | | (Number) | SELECT ROAD_ID, SDE.ST_X(SHAPE) AS X FROM ENG.ROADS_STARTPOINT_BM | | | | | ) WHERE X IS NOT NULL ORDER BY ROAD_ID | +--------------+-----------+------------------+---------------------------------------------------------------------------+ | ST_Y | < 0.5 | Double precision | SELECT ROAD_ID FROM ( | | | | (Number) | SELECT ROAD_ID, SDE.ST_Y(SHAPE) AS Y FROM ENG.ROADS_STARTPOINT_BM | | | | | ) WHERE Y IS NOT NULL ORDER BY ROAD_ID | +--------------+-----------+------------------+---------------------------------------------------------------------------+ | ST_NumPoints | < 0.5 | Integer | SELECT ROAD_ID FROM ( | | | | | SELECT ROAD_ID, SDE.ST_NumPoints(SHAPE) AS NUM_POINTS FROM ENG.ROADS_BM | | | | | ) WHERE NUM_POINTS IS NOT NULL ORDER BY ROAD_ID | +--------------+-----------+------------------+---------------------------------------------------------------------------+ | ST_PointN* | **9.5** | ST_POINT | SELECT ROAD_ID FROM ( | | | | (ST_GEOMETRY | SELECT ROAD_ID, SDE.ST_PointN(SHAPE,1) AS ST_POINT FROM ENG.ROADS_BM | | | | subclass) | ) WHERE ST_POINT IS NOT NULL ORDER BY ROAD_ID | +--------------+-----------+------------------+---------------------------------------------------------------------------+   Function documentation: ST_X, ST_Y, ST_NumPoints, ST_PointN The result? ST_PointN is the problem. Its 9.5 second response time is slow compared to the other functions.  So I think that proves that the performance of ST_PointN needs to be improved.             ... View more

In SQL Server, does “geometey.M” generate individual rows for each vertex/M-value? I’m not aware of a simple way to generate rows for each vertex…when it comes to SDE.ST_GEOMETRY in Oracle. We don’t have a GetVertices function, etc. ... View more

Reason: it’s a possible simplistic way to check M-values for issues: Find polyline vertices where M-value is not cumulative length The thought being: I could check the existing M-sum vs. the theoretical M-sum. If there is a difference, then that would tell me I have incorrect M-values. ... View more

I’ve been asking this same question for the last 10 years. No one seems to understand…just let me base my road events on the length of the line. Why do I need to redefine the M-values via the Set as distance tool  every time a feature is edited? I only recently developed a way to automatically redefine M-values (when a geometry is edited):  - Arcade attribute rule: Set polyline M-values to cumulative length of line  - PL/SQL (could be used in a Oracle db trigger): Update polyline vertices with cumulative length of line But we shouldn't need to write custom tooling for that. We should have the option to do that OOTB...right in the FC properties. Related: Automatically set M-values to cumulative length of line (after edits) Length-based linear referencing event layer Find polyline vertices where M-value is not cumulative length Get sum of M-values using SQL ... View more