Latest Contributions by Bud

Regarding the various spatial types that are supported by ArcGIS: What types auto-validate geometries? And what types don't auto-validate? For example, if I were to create a polygon geometry from this incorrect WKT (the last vertex is slightly different from the first vertex, which is wrong), what would happen? Would the incorrect geometry be accepted, or would it throw an error? --Example: SDE.ST_GEOMETRY select sde.st_geometry ('polygon ((676832.320 4857578.086, 665287.423 4857578.086, 665277.423 4878109.585, 676832.320 4878119.585, 676842.320 4857588.086))', 26917) from dual  ORA-20004:  ORA-06512: at "SDE.ST_GEOMETRY_SHAPELIB_PKG", line 12 ORA-06512: at "SDE.ST_GEOMETRY", line 55   SDE.ST_GEOMETRY in Oracle: Auto-validates — would throw an error. SDO_GEOMETRY (Oracle): Doesn't auto-validate — doesn't throw an error, unless we explicitly perform a validation via a validation function(?). Others? Have I understood that correctly? ... View more

SDE.ST_GEOMETRY in Oracle: I have two vertices of a rectangle: Lower-left: 10,10 Upper-right: 100,100 I want to construct a rectangle polygon from those two vertices using ST_GEOMETRY functions. Currently, there doesn't seem to be a a way to construct that rectangle using only the two vertices. It seems like the only way to construct the rectangle is to determine what all four (or five?) vertices are — and construct the rectangle that way. It would help if functionality could be added so that we could construct an ST_GEOMETRY rectangle from just the lower-left and upper-right vertices. Similar to what we can do with SDO_GEOMETRY's rectangle functionality: select sdo_geometry(2003, 26917, null, sdo_elem_info_array(1, 1003, 3), sdo_ordinate_array(665287.423,4857578.086, 676832.320,4878119.585)) -- only two vertices 🡅 🡅 from dual Result: [MDSYS.SDO_GEOMETRY]   ... View more

In an item's properties in Catalog (tables, FCs, views, etc.): It would help if the item's creation date were available in the properties window. Possibly in the General tab. That would be helpful for data management purposes. I'm aware that the creation date can be gleaned from the db via SQL in a pinch. But that's inconvenient, not available to non-DBA users, and doesn't help us for non-enterprise GDBs. Out-of-the-box info in Pro would be better. ... View more

In the diagrams in the spatial grid index docs: Why are the grid cells parallelograms instead of rectangles? As a novice when it comes to indexing, I would have expected the grid cells to be right angles.  ... View more

SDE.ST_GEOMETRY spatial indexes (in Oracle 18c): I’ve read that the indexes are domain indexes. I’ve also read that they’re grid indexes. Which is it? Or is it both? Thanks.   ... View more

Oracle Feature classes that use ST_Geometry storage use a separate table to store information for the spatial index. The spatial index table is named S<n>_IDX$, where <n> is the geometry index value for the table. The geometry index value is stored in the SDE.ST_GEOMETRY_COLUMNS geodatabase system table. The spatial index table is created as an Oracle Indexed Organized Table (IOT). The spatial index on the ST_Geometry attribute appears as A<n>_IX1 when viewed through Oracle Enterprise Manager. The value of <n> represents the LAYER_ID value stored in the LAYERS geodatabase system table. Spatial indexes and ST_Geometry  https://oracle-base.com/articles/8i/index-organized-tables Does that bolded blurb in the docs mean it’s possible to select the index data as rows in a query from the ST_GEOMETRY stpatial index? Like this: select * from _; spatial_index_data ---------------------- [ST_GEOMETRY shape] [ST_GEOMETRY shape] [ST_GEOMETRY shape] [ST_GEOMETRY shape] … Background: Get map to use function-based spatial index (ST_GEOMETRY) Thanks.   ... View more

Regarding registering a database view with the geodatabase - via the view’s properties in Catalog: Registering a view is painfully slow (minutes, not seconds). It’s not clear why it takes so long, since the operation is merely inserting a few rows into GDB system tables. Sure, the operation might be calculating the extents of the view, which can take some time. But calculating the extents is a lot faster when doing other things like adding a non-registered view directly to the map as a layer. So it seems weird that it would be so much slower when doing it via the register-with-GDB tool. Maybe it’s doing multiple extents-calculations or select *’s unnecessarily?  Why is registering a view with the GDB so slow? Can it be improved? ... View more

ArcMap 10.7.1.: I've created a new point FC from scratch using Catalog (using all the default settings). The General tab mentions "Storage: High Precision": Whereas the Domain, Resolution and Tolerance tab mentions "XY Resolution": What's the difference between "Precision" and "XY Resolution". Thanks.   ... View more

Edit: Mods, I suppose this post could be moved to the Data Management community (or whatever's appropriate). What resources do you recommend for learning about SRIDs? SRIDs have always been a gap for me. For example, when working with a FC using SQL, it's not clear to me if/when I would need to change the SRID for the output geometries. If I extract points from a line FC via an SQL query: When constructing the resulting points using SQL, should I use the original SRID from the lines, or do I need a new SRID since the geometry type has changed? (from lines to points) select objectid, --Side note: If anyone's wondering, this is why I convert to/from WKB: https://support.esri.com/en/Technical-Article/000011333 sde.st_geomfromwkb(sde.st_asbinary(sde.st_startpoint(sde.st_geometryn(shape,1))),sde.st_srid(shape)) points_shape -- 🡅 --Question: When constructing the resulting points, should I use the original SRID from the lines, -- or do I need a new SRID since the geometry type has changed? (from lines to points) from lines --Note: The original SRID of the lines is 300051.   Or, if I remove the M-dimension from lines via an SQL query: Do I need to use a different SRID when constructing the non-M-enabled geometries via SQL?   Thanks. ... View more