Latest Contributions by VinceAngelo

I'm not a big fan of coordsys offsets with large numbers of significant digits.   0.003281 would be an *awful* precision to use.  I would choose 0.001 or 0.002, since the conversion to integer is "times 1000" or "times 500" (and not "times 304.78512648582749161840902163974". Precision to a thousandth of a foot is gratuitous overkill for all but precision amoeba farming, but it's a nice round number. I try to avoid the default values, because they were chosen to maximize precision, at the cost of compressibility, and I'd rather transfer a BLOB with 278 bytes than one with 40K (your mileage may vary, but you should take your most complex geometries and try them at different scalefactors, to determine what the exact compression loss might be). - V ... View more

Copy/delete/rename is far from the most efficient methodology here. I have tables with tens of millions of rows in them; doing this would cost me hours and could result in tables with columns slightly different from the datatypes I originally declared them to be. I pretty much avoid Copy for this reason. - V ... View more

Brian -- There are potential issues to managing records in a registered table in this manner. The easiest solution is to just leave the feature class unregistered, and access it as a Query Layer.  But make sure you recluster the table, since doing this sort of "load, then update geometry" process thoroughly fragments the table.  Truncate and reload is not a very efficient process, and leaves any service looking at the table during that transition somewhat bereft. I prefer to do change detection, and only INSERT new records, UPDATE changed records, and DELETE removed ones. I'm doing this daily with tens of millions of rows and hundreds of thousands of potential changes, in just minutes over the time it takes to read the new records. - V ... View more

Alicia -- The RDBMS (or file geodatabase handler) is not aware of feature datasets, so even though you see it "in" a feature dataset, it isn't really, and you can't have duplicate-named feature classes, so you can't do a straight copy. I just drag the feature class out of the feature dataset to be standalone, then drag it back in to a different feature dataset, but I just tested, and it's possible to just drag from dataset1 to dataset2 without copy.  So long as the Spatial Reference is the same, it's no big deal. If the spatial references are different, then you have to rename to "_old" then use FeatureClassToFeatureClass to change the SpatialReference. But you might want to re-evaluate whether you need to have feature classes in a feature dataset at all.  If they're not being used for "feature-dataset-ish" tasks like topologies, then having more standalone feature classes would reduce the overhead of locking all the feature dataset members whenever a lock is placed on any feature class in the dataset. - V ... View more

Barbara -- There's probably a two-billion-ish limit on the number of concurrent states, but if you were to attempt it, your server would likely fail from old age before it completed. Keep in mind that a "version" is a named reference to a state in the state tree, and that you're unlikely to have 2^31-1 versions, because each edit is usually its own state, and there's usually more than one edit in any edit session. I doubt you'd be so lucky that some posts would succeed in such a situation, since it's a multi-pass process.  If you want to find effective limits, I suggest you conduct a benchmark of sorts, with multiple edits per version, with increments of 500 versions at a time. You should be prepared for this to take an inordinate amount of time, and for it to eventually corrupt your instance, so I wouldn't suggest you do this on a production system. - Vince ... View more

Paige - Cool.  But don't forget to check if there are other, multi-part types in the table: SELECT ST_GeometryType(geomcol), count(*) as nfeats FROM owner.geomtable GROUP BY ST_GeometryType(geomcol) ORDER BY 2 DESC Note that the database name isn't required, because PostgreSQL doesn't support cross-database queries. - V ... View more

You need to put a WHERE constraint on the QueryLayer definition to restrict by either GeometryType(geomcol) or ST_GeometryType(geomcol), then specify the desired type in the layer definition  Those two functions return different values (e.g. "POINT" and "ST_POINT"), and you may need to use an IN operator, because multi-part linestring and multi-part polygon geometeries are represented as different types in PostGIS. You may want to use ST_Dimension(geomcol) instead, since that just sorts POINT, LINESTRING, and POLYGON data into 0, 1, or 2 (but be careful, because MULTIPOINT also returns 0, and it's a different type as well, though not as common).  In a perfect world, the various geometry types wouldn't be smushed together like that (it's an antipattern, but some folks love to go down that route).  You'd get better performance on large tables (>100k features) if the dimensionality were also an attribute property capable of being indexed (e.g. 'WALL', 'WELL','PATIO') though I suppose a covering index on one of the differentiator functions could be effective (but only if you can get the data owners to construct that index). - V ... View more

I've got a couple of read-only RDS replicas exposing PostGIS geodata via Query Layers. Works great. Selection sets would likely be a problem from an EGDB, since the database is read-only. EGDB replication would likely be better than an RDBMS replica for true geodatabase functionality. - V ... View more

Yes, this is unfortunately true. - V ... View more

According to Stack Exchange, you want Latin1_General_100_..._UTF8 - V ... View more

No, latin1 is NOT UTF-8, it's latin1. You need to use a UTF-8 character set. - V ... View more

I've been UTF-8 compliant on my databases for 22+ years now. There really is no reason to go out of your way to make international names like "Côte d'Ivoire" give your front-end developers nightmares. - V ... View more

I've had good experiences with leveraging an SHA-1 hash of the non-key important data*, storing the hashes with the actual primary key in a parallel table.  Due to the nature of the data, I've sometimes converted the data to only a few significant digits, then hashed that (to enable "fuzzy matching", when 3.71 -> 3.72 or 3.68 is not significant, but 8.23 is). Recently I've stored the geometry and non-geometry hashes separately, and have even been able to match rows without a useful rowid key by inverting the hash dictionary spanning tens of millions of features, so that hashes could resolve feature matching at 85-97% accuracy. Unfortunately, I can't release my code without  approval. And in order to make this work , you need to  be really comfortable with endian integer and floating-pint storage representations. I can say the core code is a set of encoder functions (one for each supported type), which is stored as a bytearray sequence, that is fed into a core Python hashing function. Use of SHA-1 can generate safety warnings, but using it for hashing (not cryptographic) purposes is perfectly safe. - V --- *Unimportant data would include a URL that incorporates the primary key and another column, which could be recomputed (or changed at will) ... View more

You need to go back and review the documentation on versioning. Versions stay forever, until deleted. They also pin subsequent edits in the A/D tables, making the geodatabase less efficient. This is not something which should be ignored. If that initial set of edits in that version was just to prove it was possible, and never intended to be merged into the table, the version should be removed, and the state tree compressed, to eliminate the exact problems you're having now. Versioned editing is a process, with primary use cases designed to incorporate the edits as quickly and efficiently as possible. Coloring outside the lines of best practice can stress the implementation and result in suboptimal performance. - V ... View more

One simple heuristic: Use Create Fishnet (Data Management) to partition the space, then iterate the features, using them to Select Layer By Location, and compare the number of selected features. If fishnet cell size is, say, 20-50% larger than the usual subdivision area, missing subdivisions will stand out in the feature counts. From a computer vision standpoint: Symbolize the features with exceptionally wide line symbols, in two different primary or secondary colors with 50% transparency, then make a series of tiled images, and look for images (areas) where one color predominates. - V ... View more