Latest Contributions by VinceAngelo

You'd have to ask the folks that designed that model their reasoning. ... View more

Equivalence usually has a very specific meaning when it comes to geometry: Same topology type Same number of vertices Same vertex values You are not looking for an "equal" geometry, but something quite a bit more elastic.  The answer could be to use SDE.ST_DIFFERENCE to "subtract" one geometry from the other, and test that for being non-empty. Assuming two tables: table1:      A|POLYGON ((0 0, 0 10, 10 10, 10 0, 0 0))      B|POLYGON ((0 10, 10 10, 10 0, 0 0, 0 10))      C|POLYGON ((10 10, 10 0, 0 0, 0 10, 10 10)) table2:      A|POLYGON ((0 0, 0 10, 10 10, 10 0, 0 0))      B|POLYGON ((0 10, 5 10, 10 10, 10 5, 10 0, 5 0, 0 0, 0 5, 0 10))      C|POLYGON ((0 0, 5 10, 10 0, 0 0)) SQL> select sde.st_isempty(sde.st_difference(a.shape,b.shape))   2  from table1 a, table2 b   3  where a.tid = b.tid; SDE.ST_ISEMPTY(SDE.ST_DIFFERENCE(A.SHAPE,B.SHAPE)) --------------------------------------------------                                                  1                                                  1                                                  0 Curiously, the Oracle implementation of ST_Equals produces that "forgiving" model SQL>  select sde.st_equals(a.shape,b.shape)   2   from table1 a, table2 b   3   where a.tid = b.tid; SDE.ST_EQUALS(A.SHAPE,B.SHAPE) ------------------------------                              1                              1                              0 - V ... View more

Keep in mind that there really hasn't been anything called an "SDE View" for a long time.  The term of art is "spatial view" or just "database view" (geometry columns being a normal part of modern databases). The only time sdetable -o create_view should be used is with SDEBINARY storage geometry layers (which are rapidly becoming rare).  For all other use cases, the database or geodatabase view construction tools are the appropriate tools.  After view construction and validation, you can use sdelayer -o register to eliminate the Query Layer requirement of selecting an ID column (views must always be registered with a USER-set rowid column). If you need to replace an existing view which has been registered with ArcSDE, you should use ArcCatalog or sdetable -o delete to drop the previous view, then use database tools to recreate the view, then use sdelayer -o register to re-register with ArcSDE. - V ... View more

Yes.  It would be difficult to find a geodatabase SME who would recommend otherwise. - V ... View more

Forty-five databases is quite a few.  The rule of thumb I'd recommend is to focus on use patterns -- Keep stuff which is used together near to one another.  RDBMSes are designed to work well with lots of rows, but not so much with lots of tables. Databases are an excellent way to isolate the table count between objects that are never used together, but I expect there's a Law of Diminishing Returns with respect to Too Many Databases.  You may find that bumping up the RAM on the database server is enough to keep up with a large pool of databases, but at some point, the additional worker processes are going to start impacting your available CPU. Please do keep a close eye on best practices with respect to feature datasets:  Using FDS as a "folder" solely for UI presentation is a burden on your geodatabase.  There are a number of places where Desktop performance is linked to O(number_of_featuredatasets) and O(number_of_featuredatasets^2).  I realize that presenting oodles of tables can be a burden as well, but clever naming policies can handle many of the "flat" presentation issues. - V ... View more

Moved to Geodatabase ... View more

There's a number of issues to address, starting with upgrading your database -- SQL Server 2008/2008R2 support is deprecated at 10.3 (not supported by 10.4 & higher​ [top of p3]) Are your 40 databases really completely independent?  Are they all active, or do you need to look at archiving at least some of them to a neutral format (e.g. file geodatabase)? FYI: "Very large" has a specific meaning in the context of databases, usually referring to tables with more than tens or hundreds of millions of rows.  While it's possible for a 50K+ row table to be unwieldy, it's rare that one can achieve "very large". Even medium to large tables (more than 200k features) which have evolved over time often benefit from spatial defragmentation (export and reimport, or export and rename, as can be achieved using the Sort utility). Actually, the draw performance of all tables improves with spatial sorting, but the difference is often only noticeable over 100-200k+ rows. In general, performance optimization cannot begin until you accurately capture metrics of existing performance.  From there the rule of thumb is to optimize the capabilities with the longest runtime ("longest pole" first). Good luck. - V ... View more

Ya, ya, "thousand million" and all that rot.  But I hope the US$ helped clarify my intent (having spent some time tracking and/or using AU$ on occasion, I try to strive for clarity). - V ... View more

Tell them it will cost an extra US$2Billion to rewrite the GIS to use "long double" and US$5Trillion to reinvent geodata collectors to get within six orders of magnitude of the required accuracy. Most metadata collection isn't accurate to even a single meter (5 places in degrees). - V ... View more

Look at how layers are modelled.  Each layer is associated with a connection (zero or one).  Connection pooling (successful connects) will prevent additional connections to the same set of parameters, but unsuccessful connections will not pool (and therefore effectively retry). Unfortunately, three and done on service-oriented accounts is an effective denial of service attack. - V ... View more

I don't believe there is any failed attempt threshold.  Each time you request an attempt to connect, that connection will be attempted (once).  ArcGIS Server manages connection pools differently, but I'm not aware on any limit there either (probably only a frequency thing -- retry interval, not retry count). - V ... View more

I came close, with the 720-side shape.  And don't forget that C in Cartesian, professor! ... View more

I didn't make any claims about software functionality. The File Geodatabase API is an open-licensed API library for simple feature access to Esri File Geodatabase data.  It is a subset of the capability of ArcObjects with respect to geodatabases, as documented.  It is most certainly not the reference implementation for File Geodatabase access. Even though steps were taken to prevent it, there still exists a possibility that data generated via FGDBAPI.dll will have issues when accessed by ArcObjects, especially with respect to true curves (aka CAD objects).  This is more an issue of the arcane complexity inherent in CAD representation, where the same words mean different things in different CAD software.  If geometry "repair" corrects a CAD issue, then it wasn't encoded correctly (and if the area changes significantly, it may be due to the parallel shape vertex array not being populated correctly). Again, in order to evaluate whether a defect exists, you need to provide Esri with a reproduction case.  If it's a FileGDBAPI issue, provide FileGDBAPI code; if it's an ArcObjects issue, create a new thread over in ArcObjects and provide ArcObjects code. - V ... View more