Latest Contributions by MarcoBoeringa

In the same context, what might be the effect on increasing the resolutions? A potentially unwanted loss of accuracy / precision of the stored coordinates. With the default, you can reasonably store measurements up to millimetre precision, changing the default resolution to something like 0.1 m, will not allow that. Also see this Help page: The properties of a spatial reference And mind the following quote from that page: "Esri strongly recommends using the default x,y resolution in most cases because it has proved to perform quite well and can store adequate coordinate precision for most situations." Also see this quite interesting Help topic. Although it is related to Parcel Fabrics, it gives some nice background regarding historic surveys / measurements and what "accuracy" they represented: About accuracy ... View more

Hai, Have you successfully upgrade geodatabase 9.2 to 10 version with the project versions by adopting the steps suggested by Jon. It is highly unlikely you will get a response from someone who started a thread 2 years ago, and since then only made 3 posts on the forums... As per the other thread you started: ensure you have a full (and tested!) backup of the database before venturing into the unknown, then follow the steps outlined in the links provided here and especially in the other thread you started (ensure the links and Help topics you follow refer to your new version of ArcGIS!, so the links provided by Nidhin in the other thread are actually the ones you should follow up on.) ... View more

The reason for that is my enterprise layer may receive polygons of very small areas (due to conversions from CAD by using FME) and I don�??t want to consider these small areas as errors. Do you really want to maintain these, most likely, sliver polygons in your final layers? They are likely to cause issues or at least confusion later on when the data is used or analysed. You may wish to have a look at the options presented on this page: Removing slivers or gaps between polygons I realize none of the options presented there is "ideal/perfect" (but then the real world isn't :eek:). Setting up a Topology will give you most control over what is happening, and where it is happening, but requires manual intervention. Integrate is automatic, but requires a very careful setting of the tolerance and experimentation so as to not loose data that you want to maintain. I also see there is another tool presented on the first linked page that you may wish to explore: Eliminate, also helping you with cleaning up slivers. You may wish to use a two step approach: - Run Integrate (and / or Eliminate) with an effective, but conservative(!), setting so as the clean up the bulk of tiny slivers or spurious small polygons. - Then create a Topology of the resulting layer, and clean up the rest manually assisted by the Topology tools. ... View more

Back to my issue: Please, consider the attached file geodatabase layer. It has �??self intersections�?� error. Nevertheless, Copy\Paste from file geodatabse to enterprise works fine without fixing the error (repair geometry). [ATTACH=CONFIG]33421[/ATTACH], [ATTACH=CONFIG]33422[/ATTACH], [ATTACH=CONFIG]33423[/ATTACH] My question here: how the Enterprise Geodatabase Layer (SQL) accepts features that have error? Jamal, I now had a more thorough look at the sample data you provided as a File Geodatabase in above post. I can confirm: - That the Feature Class it contains (LanduseAndRoadsPolygons_FME) has an error in the last geometry with OBJECTID 51, as detected by Check Geometry and reported as "self intersections". - Using Copy/Paste to a Desktop Geodatabase in SQL Server 2012 Express doesn't lead to automatic fixing of the geometry in question (contrary to what the Check Geometry Help topic suggests). If I copy the Feature Class back to the FGDB and run Check Geometry again, it is still reported as having self intersections. - Using Import/Export (which uses the Feature Class to Feature Class tool) instead of Copy/Paste gives a similar result: the invalid geometry is happily transferred from the Desktop Geodatabase to the FGDB and back, without any automated fixes applied. So I can't reproduce the "difference" Vince described in this post in the thread. - I can not reproduce the "two donuts or outer shells overlap" issue you described, but since you provided another small test dataset with a detected error, and not the large one that initiated this thread, this is no real surprise. - I also tried to load the data with the erroneous geometry in the Open Source QGIS (2.2.0 Valmiera). QGIS has an option for checking geometries as well. I opened both straight the FGDB Feature Class (which is possible using the Add Vector Layer option and choosing "folder" instead of "file"), and a converted shapefile version of the layer, but QGIS is unable to detect any geometric error in both of these... so it considers them valid (may have to do with the type of validation checks). It starts to look like a bug / loop hole that may need fixing. Sorry to see no one else of ESRI staff responded yet and did some tests with this data, although an official support call is the way to go here. ... View more

Thank you both for the replies. Thanks for the link Vince.  The diagram will be very useful to explain to the managers. Have a great weekend, Tony Actually, to be honest, I find that diagram - if you are referring to the first image visible on the page Vince linked - rather unhelpful and kind of misleading. It suggests that Desktop, Workgroup and Enterprise Geodatabase are somehow stacked on top of each other, with one supplementing the other like some sort of "extensions", or that they even "communicate" through each other. This is not the case. You either have a Desktop, Workgroup, or Enterprise Geodatabase, not all at once. Essentially, and especially from a user perspective, the difference between the types of ArcSDE multi user geodatabases boils down to a different licensing scheme, allowing you to run more or less consecutive clients / connections against the geodatabase (3, 10 or limited by licensed hardware). Technically, the differences between the multi user geodatabases are minimal though, except for a different means of authorizing your licensing scheme, and a few other differences. ... View more

In case you wish to try the Oracle Instant Client, instead of Oracle Client, to which Vince referred in the other thread, Richard Watson provided some install instructions in this post: http://forums.arcgis.com/threads/74635-Is-it-necessary-to-install-the-%E2%80%9CMicrosoft-SQL-server%E2%80%9D-before-installing-the-%E2%80%9CArcSDE%E2%80%9D?p=261569&viewfull=1#post261569 ... View more

�?� Correct. I didn�??t apply the �??Geometry validator�?� for the Roads layer and Boundary layer. My final layer is neither the Roads nor the Boundary but one layer that combines both Land use and Roads. This is why I didn�??t apply the �??Geometry validator�?� Roads or Boundary but I did before the �??LanduseAndRoadsPolygons_FME�?� Layer. This is the layer that is collected in the enterprise layer as it represents one urban master plan for a particular community. OK, misunderstood that part. �?� Topology\repair geometry\integrated could be solutions. What is horrible is that the enterprise layer accepts features with errors, and that is in turn, generates big problems such as �??two donuts or two outer shells overlap�?� and leads to deadlock. I think that the enterprise layer (SQL or Oracle) should be designed not to accept features with errors as this will lead to destroy the data. Yes and No. ESRI already applies one of the strictest models for valid geometries in enterprise geodatabases in the industry. I am still not sure how to judge this "loop hole" you found with this layer, whether it is a bug or "by design"... I am still eager to hear more from Vince or other ESRI staff regarding this particular issue, especially since the ESRI enterprise geodatabases, not allowing Check Geometry and Repair Geometry to be run, are "supposed" to contain valid shapes. As the ArcGIS Help says in the Check Geometry page: "SDE Geodatabases automatically check the validity of each geometry when they are uploaded; therefore the Check Geometry and Repair Geometry tools are not for use with SDE." On the other hand, databases will always be kind of "open". The geometry validation as implemented by ArcSDE, is a layer "on top" of the enterprise database. You could always circumvent this by, for example, using a SQL client (e.g. SQL Server Management Studio, Oracle SQL*Plus) to write out invalid shapes and thus still cause issues. This also highlights the need (and you are already working on this!), to validate the data before loading in any conceivable way, especially if suspected "dirty" data from a third party system needs to be ingested. ... View more

My question here: how the Enterprise Geodatabase Layer (SQL) accepts features that have error? I can't answer this Jamal, but just a number of quick observations (need to have a closer look yet): - I was able to reproduce the addition of the geometry number 51 with the geometric error to my SQL Server 2012 Express (all patched up) database using the Copy / Paste. This really is not good, but may be explained by a simple acceptance of the "geometry-as-is" by the Copy / Paste operation, and inserting it straight in the database. This screams for the ability to run Check Geometry and Repair Geometry against Enterprise Geodatabases as well, not just File Geodatabases (which isn't currently possible: the tool doesn't accept Enterprise Geodatabases as data source). I don't know if this would actually classify as a "bug" or is "as-build", maybe Vince can elaborate a bit more... - The geometry with the error is the roads polygon in the layer - As an addition to the above, I noticed, although you already build in 3 "Geometry Validator" steps in your FME model, you don't actually check and repair the road and boundary layers as the end products of your model. I would suggest adding two more "Geometry Validator" instances to the model, to tackle this problem. See the attached image. - I would also strongly suggest to run "Check Geometry" and "Repair Geometry" against the data created by FME in your File Geodatabase, before adding it to the SQL Server. And possibly also run "Integrate" and / or create a "Topology" for the layer, to check for overlapping or non-contiguous areas in the polygon layers. A Topology will tell you more than just running Integrate, as it will highlight possible issues, instead of just "fixing" them, and give you more control over what is happening or how it should be fixed. Do note that all of these tools, and especially Integrate, can lead to small shifts in the vertex coordinates of the vertices making up the geometries, so small shifts compared to the original CAD data, may occur. ... View more

The display of the data in ArcMap is actually really fast. But adding it to ArcMap takes minutes. Just selecting it in ArcCatalog freezes the application for minutes. Other layers in the database, even fairly large ones, are instantaneous. This all makes me think there is some cruft in the SDE tables, or at least something wrong in them. Do you, by default, work with ArcCatalog with the "Preview TAB" selected? Unfortunately, ArcCatalog always tries to draw the entire extent / dataset when hitting or opening the "Preview TAB", which may cause an apparent application hang. This voids any use of indexes or proper spatial ordering of the datasets in the underlying tables (spatial fragmentation), as it will need to read the entire table to draw the dataset. If so, you would do good to avoid using the Preview TAB as much as possible, and only draw the datasets in ArcMap with a proper minimum and maximum display scale applied through the layer settings. It is also good practice to always access *.lyr files on a file system referencing your Feature Classes in the geodatabase using ArcCatalog, instead of accessing the Feature Classes directly through a database connection, as you will be a able to pre-define and limit display scales, set symbology and appropriate labelling. It would also be wise to post some stats / specs about server hardware used, LAN speed, and the number of users on the servers and using these Feature Classes at any given point in time. ... View more

We may need to apply the �??check geometry�?� before copy\paste or Import\Export\Load to have the list of incorrect features that will be deleted\repaired. This seems wise. Run Check Geometry, and possibly Repair Geometry, as often as possible in your workflow. The sooner you detect serious geometric issues, even if caused by another step in your workflow than the initial data generation in CAD, the better. The more points in your entire workflow that you run Check Geometry, the higher the chance of homing in on potential (digitization) problems and problematic data conversion steps. It would also be wise to start collecting some data on what problems occur if caused by digitization errors. You may than be able to put on paper some "best practices" and warnings concerning digitization issues, and distribute this among colleagues to make them aware of the issues. It may lead to better practices regarding digitization. The CAD colleagues may not even be aware of any issues (of course, this assumes issues are in initial data generation - which is likely - and not caused by subsequent conversion steps - less likely, but still very much possible). ... View more

The issue of �??two donuts or two outer shells overlap�?� is escalated. Now, I�??m not able even to display the layer or export\load\import. ... What other options do I still have to extract my data from this enterprise layer? You might be able to recuperate much of the data by using the FME / Data Interoperability extension against the layer and exporting to some other non-enterprise database format, or possibly using SQL Server tools for repairing geometries. (There is a MakeValid command, but you will need SQL knowledge and I don't know if there are risks running this against an ESRI Enterprise Geodatabase, e.g. there might be issues with area / perimeter after geometries have been cleaned via SQL. Also see here and here). Other option: restore from recent backup and see if you can restore the layer by re-importing data. Last but not least: contact ESRI support... maybe a local representative with thorough ArcGIS knowledge could help you out, these kind of things are difficult to solve from a distance... ... View more

Now I�??m really in trouble due the data flow issues between file\enterprise databases. I can�??t transfer the data in both directions. Data will be lost �?� Import\export\load data tools will apply the �??repair geometry�?� . The enterprise layer contains 44657 while the exported file layer is reduced to 42769 I am slightly surprised, I would have expected it to be the other way around: dirty data in the File Geodatabase with 44657 records, and then a certain number of records dropped on import to the Enterprise Geodatabase because of failure to comply with the (Clementini) rules and not repairable: 42769 records in the Enterprise Geodatabase. How did you get this data in the Enterprise Geodatabase? Theoretically, the situation you created shouldn't be possibly (but I guess the answer may be the FME workflow you set up for ingesting the CAD files...). I guess the next step might be to get back to the original (CAD) data, import this into a File Geodatabase first (possibly using your FME workflow, but with a changed target in the File Geodatabase instead of Enterprise Geodatabase if possible), run Repair Geometry / Integrate against the Feature Class in the File Geodatabase, and only then attempt to import the data in the Enterprise Geodatabase. But I may be missing some vital steps in your current workflow, I only have a fragmented overview based on the different threads you started. ... View more

You really need to consider upgrading your ArcSDE geodatabase urgently, to at least 10.0 SP5. ArcSDE 9.1 is outdated and totally unsupported by ESRI by now (except for do-it-yourself online Help available for 9.1), being about 10 years old. I think you will have many benefits after upgrading, not least probably being able to do what you want, although I can't really comment on that. Anyway, as the 10.x Help says on this page: "Functionality specific to the current release is not available when connecting to a previous release of the geodatabase. For example, if you connect from an ArcGIS 9.1 client to an ArcGIS 9 personal geodatabase, you will only have access to functionality available at ArcGIS 9." By the way, how are you actually connecting to ArcSDE 9.1 with a 10.x client? According to the same page, 10.x shouldn't be compatible with 9.1, only with 9.2 minimum... Only 9.1 personal geodatabase (Microsoft Access) are supposed to be supported in 10.x. You may wish to start looking at this page: A quick tour of geodatabase upgrades ... View more

Okay, please do not consider this a binding/legal Esri answer, but going by the ArcGIS for Server Product life cycle document, 10.0 is in mature support while 10.1 is still in extended support. Further information on what that means is available here. Melita Ergo (looking at the document Melita linked): they should help you out in Technical Support and answer your questions, as long as you have a support contract. Even for the "Mature" 10.0 that doesn't get any new service packs or patches. ... View more

Ha yep! Thought it might be a bit of a long shot on here...no matter, will try MathWorks again. Cheers See my last remark about Geostatistical Analyst in the edited post above that you may have missed. And actually, it is not that long of shot. I am actually a little bit "stumped" by the apparent lack of interoperability 15 years onwards. At least Google and searching on the MathWorks website, did not turn up any real straightforward way to exchange raster data between the two platforms. The ArcGIS for Desktop Help seems also void of references to Matlab... ... View more