Latest Contributions by VinceAngelo

This is the same issue as a recent thread in this forum. What it comes down to is the coordinate resolution used to describe the shapes -- When the table containing an existing geometry column is registered with ArcSDE, a precision is defined for the X/Y dimension (and Z and M dimensions, if appropriate). ArcSDE uses this precision to convert coordinate vales to internal representation. If the geometry cannot be represented, then an error is raised on the query stream, using the first transfer buffer available when the error was encountered (if the error occurred on feature 100, it's still possible that only 70 shapes could have been returned at the time the draw request failed). If you use the ArcGIS Desktop standard of ~1mm precision, then you'd need to lop seven places off the WKT strings (assuming the coordinate system unit is meters) to evaluate them for possible conflict within ArcSDE's internal SE_SHAPE representation (even still, other implementations aren't guaranteed to handle shapes identically). If the layer was defined without an explicit coordinate reference, it may have used the ArcSDE default coordref of "0,0,1" ({0,0} origin, 1 meter/foot/degree precision), which should generally be avoided (especially when working with geographic coordinate systems).  You can determine the precision registered with ArcSDE by using the command 'sdelayer -o describe_long -l {table},{geomcol} -u ...' (look for "Offset" and "System Units"). If you want to preserve the (assumed) 10 nanometer precision in the WKT strings, then the layer registration command would need to be altered to match that precision (using the third parameter of the '-x' switch), with a scale value of 100000000 (multiplicitive inverse of 0.000000001) -- though this may impact the range of coordinates accepted within geometries (you only have 53 bits of precision available). Please see the Understanding Coordinate Management in the Geodatabase white paper for more information on how coordinate systems are constructed and managed within ArcSDE. - V ... View more

It looks like the 'sdelayer -o feature_info' capability isn't functional for SQL-Server. What does 'sdelayer -o describe_long' report for the coordinate reference on your layer? What command did you use to register the layer? I prototyped a workaround, but it's not going to be pretty. You'll need a copy of se_toolkit for the 'sdequery' and 'ascinfo' utilities, and you'll need to create a view of the layer that dumps the well-known text of the geometries as either string (if it will fit in varchar(8000)) or text. Then you can query the registered rowid column and WKT with 'sdequery', and pipe it through 'ascinfo' to reject the rows that fail SE_shape_generate_from_text, producing an ASCII file with ID and problematic well-known text. If you want to go this route, it would probably be easier to take this offline. Unfortunately, I didn't have time to whip up some data massage classes to automate removal of spurious jagged lines in geometry. - V ... View more

ArcSDE has been using exact arithmetic for geometry computation since the technology was aquired in 1995.  What is now known as BASIC precision uses 31 bits; HIGH precision (released with 9.0, and made default since 9.2) uses 64-bit integers (but is 53-bit, due to double precision mantissa size).  The system is very flexible for the different data units found in international databases; the default values chosen by ArcGIS are optimized by coordinate system (projection) for preservation of real-world spatial data to millimeter precision (which is roughly one hundred times the accuracy of most of the spatial datasets I've ever used.) . The distance parameter in Douglas-Peucker doesn't correspond to precision, but to deflection; value selection is data dependent (and, to some degree, more art than science). - V ... View more

The CONNECTIONS parameter at 9.3+ reflects both application server and Direct Connect conections.  I've yet to be able to convince a Windows host to accept more than ~117 application server connections without running out of non-interactive desktop heap (I ran equivalent Linux hardware to 400 application connections in a fraction of the time), so I'll assume you're mostly using Direct Connect.  It's really up to the database on how many connections to accept, and the server host to perform adequately under load.  You will hit a limit at some point, and it will likely become obvious when you do; unfortunately, there may not be much warning before performance goes into a death spiral.  For the meantime, you can keep an eye on things by establishing an evaluation test to be done weekly, during a point in time where the system is under "normal" load, which captures both number of connected users and the time to accomplish a medium difficulty process; it's easier to justify infrastructure improvements when you have data to back up your request. - V ... View more

The principal problem with using arbitrary precision with real-world coordinate data is the implicit assertion of accuracy not present at input. The orginal data was collected at centimeter scale. Varying the locations by a few hundred nanometers can change topology, but if it does, then it becomes a data quality issue -- *should* we trust spatial data for which the Heisenberg uncertainty principle applies? There are a number of ways to process this data to remove the problematic vertices. The simplest to code would be to perform angle calculation over three coordinate sets -- vertices that belong in a shape at that scale would not bend the line by more than 165 degrees (+/-) -- Whether this line bends by 180 degrees or 179.999999 degrees wouldn't matter in this sort of algorithm, just that you remove the vertex that produces the shortest segment. A more robust processing step would be to apply a full Douglas-Peucker generalization to the polygon ring as a line, with a tolerance distance of, say, 1/20th the diagonal of the bounding box (or just a fixed value, like 0.5 meters), then attempt to cast the rings back into a polygon. I have a tool that may be able to do this sort of processing (in a timely fashion with millions of rows), but I'd have to play with an ASCII dump of the well-known polygon text to figure out if this was a 20-minute hack or something more involved. - V ... View more

It looks as though this instance failed at validation, so it is unlikely to have been upgraded. Do the WEBMERC.IMG_FP, WEBMERC.MISSIONS_FP, WEBMERC.MISSIONS_FP_Simplified93_5M, S_CSCDATA.IMG_FP, and S_CSCDATA.MISSIONS_FP tables exist in the database?  If not, they were likely deleted in a way that corrupted the geodatabase table registry. The easiest way to address nominal corruption like this is to create tables of the same owner and name (no need for more than a single INTEGER "objectid" column), then use ArcGIS to delete the tables (and their metadata entries).  Once this is done, validation should succeeed, and then the instance wil be viable for upgrade. - V ... View more

Vector tables are easy to append to -- why not break your raster into managable pieces, extract the multipoints for each part, and merge into a final product? - V ... View more

I can't give away even old training materials (mostly bullet lists on which the instructor needed to expound, anyway). All the concepts are available in the documentation, or in User Conference proceeedings (1997 and/or 1998 -- I *did* say this was mature technology, right?) - V BTW: The original "Clementini" paper, which I'll often go back to, is: E. Clementini, P. Di Felice, and P. van Oosterom, "A Small Set of Formal Topological Relationships Suitable for End-User Interaction," in Advances in Spatial Databases - Third International Symposium, SSD '93. vol. 692, D. Abel and B. C. Ooi, Eds. Berlin: Springer-Verlag, 1993, pp. 277-295. ... View more

The SE_shape_generate_polygon is reasonably adaptive. In this case, if you add the missing closing vertex to the array, the API will nominate the ring that begins and ends at 529790.078,180895.523 as a subpart (hole), then complete the primary ring. Having determined that the subpart is not within its original parent, it is then promoted to an independent part. Parts and subparts are permitted to touch at a single point (but not share boundaries or area). The API will also demote rings which *are* within other parts, making them subparts. I was the course author for the (now retired) "Accessing SDE with 'C'" 3-day training class. We spent the second half of the first day on Clemetini topology and relationships. There was exercise code which permitted generation and comparison of shapes from command-line arguments. Those exercises are gone, but the core parsing functions live on, exposed in the se_toolkit DAT module, which is how I was able to assemble and test your geometry. - V ... View more

'sdelayer -o feature_info -r invalid' should scan a table for invalid shapes. - V ... View more

SQL-Server isn't handling the geometry right, but the root of the problem is your GML source, which also has a topology bug. I must admit that I also find the representation errors (two places in, twelve out) disturbing as well -- it looks as though the values have been stored in single precision. - V ... View more

When you register a *layer* (not table) with ArcSDE, an entry is made in the LAYERS table for that GEOMETRY column, making it availbale to ArcGIS for geodatabase participation.  Query layers view GEOMETRY columns without registration. - V ... View more

Look at the documentation for registering a layer with ArcSDE, or if you're using ArcGIS 10, for query layers. - V ... View more

The ArcSDE topology engine is quite mature. It uses Clementini's topology rules, which includes the definition of a simple line. All polygon rings must adhere to simple line restrictions, and this line overlaps itself (linear intersection, not point). C:\>sdequery -l testshape2,shape -F1 SM_II:line:531404.44,104177.02,531401.59,104168.47 -v ArcSDE 9.3 Generic Query Tool            Thu Dec 30 08:53:42 2010 ------------------------------------------------------------------------          1             objectid: 5                shape: Line shape (1 part, 2 vertices)                     1   531404.440000, 104177.020000                     2   531401.590000, 104168.470000          2             objectid: 6                shape: Line shape (1 part, 2 vertices)                     1   531401.590000, 104168.470000                     2   531401.600000, 104168.500000 2 rows found in 31.00 ms C:\>sdequery -l testshape2,shape -F1 SM_II:line:531401.59,104168.47,531401.60,104168.50 -v ArcSDE 9.3 Generic Query Tool            Thu Dec 30 08:53:42 2010 ------------------------------------------------------------------------          1             objectid: 5                shape: Line shape (1 part, 2 vertices)                     1   531404.440000, 104177.020000                     2   531401.590000, 104168.470000          2             objectid: 6                shape: Line shape (1 part, 2 vertices)                     1   531401.590000, 104168.470000                     2   531401.600000, 104168.500000 2 rows found in 47.00 ms If you do the math, you'll see that segments 5 & 6 have reciprocal slopes; since they share a vertex, they overlap. In order for vertex #6 to be included, several points would need to be added, including a point to make a polygon of the deformed interior polygon ring, a vertex for the interior ring to touch, and vertices to open and close the interior ring. - V ... View more

I made a line out of polygon shell, and generated a shapefile from it, then inspected the line.  That shape does self-intersect, in the vicinity of 531401.6,104168.5.  - V ... View more