Latest Contributions by MarcoBoeringa

I was hoping someone knows of a way to make the SHAPE.AREA/SHAPE.LEN fields popolate and update automatically even if using SDO_GEOMETRY.  Maybe someone has found a way to "trick" Oracle to use these fields??? I hope that clarifies my question. Thanks in advance, Wes It does. The "trick" is DBA work. Your DBA needs to set a so called "trigger" on these fields, and possibly create a database function and / or stored procedure to update the fields automatically each time a record changes. How that may interfere with ArcSDE, and if there are any risks involved (I guess limited to none considering these fields aren't updated as you noted), ESRI is in a better position to answer. Using Triggers (Oracle documentation) ... View more

Thx a lot. We can't use ST_GEOMETRY, since we access the data also via Java using Hibernate. For this we use Hibernate-Spatial, which provides support for SDO_GEOMETRY, but not ST_GEOMETRY. We couldn't find any Hibernate Provider for ST_GEOMETRY at all. We actually had to spend some time for evaluation how to integrate Java/ArcSDE/Oracle, since there is not much documentation about best practises. One approach would have been using ST_GEOMETRY along with Java SDE API, but ESRI says this API won't be supported after 10.2. Maybe not entirely relevant to this thread with its requirement for Apache, but while the ArcSDE Java API may be a dead end after 10.2, the ESRI Geometry API for Java certainly isn't. It is a current Open Source GitHub project and may offer functionality you need or could use: ESRI Geometry API for Java Also have a look here possibly for Open Source code samples: http://esri.github.io/ ... View more

If using sdo_geom, is there any way to get the SHAPE.AREA and SHAPE.LEN to populate correctly?  Yes, other fields could be added to store this geometry info., but I'd rather not do that if possible. Thanks in advance, Wes Calculating area, length, and other geometric properties (10.1 Help) ... View more

So, just using the same SQL from the Query Layer to create a DB view, then registering it with the GDB would essentially get you the same thing as using sdetable -o create_view? I think I need to correct myself here a bit. This is all a bit to the limit of what I tested, but if I understand the Help right, you can only register tables, not views, with the geodatabase. This essentially means the spatial view that you create, will remain a stand-alone table / layer, not registered and read-only. So you can't edit it or have it participate in geodatabase behaviour. ArcCatalog and ArcMap are able to make good use of the data though. As an example, as to what is possible and to what I tested, in the images below you see a database view created that joins an ArcSDE Versioned View with a normal database table based on the fields "name" and "morph_type" that have the same content. You preferably need to include an ObjectID as well in the view definition if already available, otherwise ArcCatalog or ArcMap will prompt you for a unique column (combination). The SQL statement for this is shown both in SQL Server Management Studio, and in ArcCatalog. In ArcCatalog you see the resultant layer (just one record actually, a multi-part polygon in this test). The example screenshot here is from ArcGIS 10.2, but Query Layer functionality, and the ability to directly see and use non-geodatabase registered spatial tables in ArcCatalog, was introduced at 10.0. ... View more

Thanks Marco.  My question was specifically whether an ESRI "Query Layer" can be persisted on the database side to appear as a feature class in a geodatabase.   Sounds like the answer is "no". Dan, Query Layers just use any valid SQL syntax for your database (Oracle, SQL Server etc.). This means that to "persist" the Query Layer, you would simply copy the Query Layer's SQL statement from the ArcMap dialog, and copy it straight into the database dialog involved in database view definition. This database view can subsequently be used in another Query Layer using a simpler SQL statement to add / view it straight in ArcMap, or view it being displayed in ArcCatalog. PLEASE NOTE ARCCATALOG WILL DISPLAY THIS DATABASE VIEW IMMEDIATELY WITHOUT DEFINING A NEW QUERY LAYER (EVEN SPATIALLY, you can view the geometries)! But it will NOT be part of a Geodatabase, unless you register it with the geodatabase. You can however use this database view in any other application (e.g. AutoCAD Map or something) that supports reading database views. E.g. If I had a Query Layer "1" with a SQL statement SELECT fieldA FROM tableB WHERE fieldA = 'something' I can copy this definition in the dialogs for database view definition, e.g. in SQL Server Management Studio, and give it a name, e.g. "MySpatialView", to persist it at database level. This database view is now usable by any application. And subsequently create a second spatial Query Layer "2" by dragging and dropping it from ArcCatalog to ArcMap, or defining a simpler query: SELECT * FROM MySpatialView This Query Layer will now embody the original selection of 'something'. So the answer is basically "Yes"!, unless you mean to suggest the layer should show up in Feature Datasets, and be able to be exhibit advanced Geodatabase behaviour (become part of a Parcel Fabric, Geometric Network, Topology), in which case the answer is "No". ... View more

I just wasn't sure if there was a way of creating a query layer and persisting it in the GDB as a FC... Dan, selections (or queries in database terms) on tables in databases are defined using the SQL language. You define a SQL statement using a number of keywords the database recognizes in one human readable text sentence. E.g. SELECT fieldA FROM tableB This text string or SQL statement can be either dynamically generated, e.g. each time you pan or zoom in ArcMap, ArcMap generates these queries and sends them off to the database to collect the features in the current data frame's extent, or persisted in some way. Persisting can be done in several ways: - At the database level. The database stores the SQL statement / query string as a "database view". This option does not involve any ESRI features, you use the standard database tools to define or create them. - At the ArcMap application level. ArcMap stores statements in the MXD document. If the statement is persisted at the application level, there are basically two options: - Queries that link to ArcSDE / Geodatabase Feature Classes. All of these queries are fully processed via ArcSDE's Direct Connect DLL's on your local PC and "connect / involve" the ArcSDE Repository with it's ArcSDE System Tables and Geodatabase System Tables in the database. - Queries that link to non-ArcSDE spatial type tables (new feature from 10.0 onwards). *** THESE ARE CALLED "QUERY LAYERS" BY ESRI *** All of these are more or less directed straight through ODBC drivers, and don't involve "ArcSDE" in the classic sense (no ArcSDE Repository used, although some ArcSDE components on your local PC are being used in query processing). One thing to note, is that a Query Layer can reference two database sources: - Plain (spatial) database tables - Database views of (spatial) tables. So, while the database view persists a SQL query on the database level, a Query Layer can persist a SQL query referencing a database view (queries can reference queries). ... View more

Okay, now I'm really confused.  One way we know that works for fixing this is to export the data out and re-import it in.  I was going to export an entire version out just to make sure that would work when I had an error during export. [ORA-00904: "A"."DUCT_MATERIAL":invalid identifier][GEOSPATIAL.SPAN] Well, the base table looks fine but when I look at the A table I see that there are a ton of fields missing from it...  I don't even know how to go about explaining how that is even possible.    (Well, except for someone modifiying the schema through oracle rather than ArcCatalog, but I hope everyone knows not to do that...) Jeff If it is an issue, it may be unrelated. But are you absolutely sure you are looking at the right A table? You need to look in the: SDE_table_registry table and find out what the "registration_id" is for your layer / Feature Class, in order to find the correct "Ax" table. A and D tables use the registration_ID as part of the table name, not the layer_id from the SDE_layers table. Anyway, the error by itself indicates an issue and missing fields looking at the error message, so you probably do have missing fields in the A table. ... View more

I guess you may be running in the same configuration issues Vince pointed out in this thread. See the reference Vince pointed out in that other thread: http://support.esri.com/en/knowledgebase/techarticles/detail/39119 And see this 10.1 Help page for how to solve this (configuration needed on your Oracle database server): Configuring the Oracle extproc to access the geodatabase with SQL You essentially need to "tell" Oracle that there are additional (ESRI) libraries it can use to access the SQL functions specific for ST_Geometry. If you don't do this, you will still be able to use ST_Geometry in your database, but not all of the spatial functions like the ST_INTERSECTION you attempted to use, as Oracle will not have knowledge of what to do with these statements. ... View more

I think you should also have a look at the ESRI Geometry API for Java, as it is OGC ST_Geometry based. It is used in ESRI's Open Source samples for Hadoop that may give you ideas too, an implementation including python Geoprocessing tools as well (also see my PDF here for some brief introduction to the Spatial Framework for Hadoop) http://esri.github.io/ https://github.com/Esri/geometry-api-java ... View more

I have posted this question after reading many pages and trying many ways that all lead me to failure, and I have very little time to finish this task. I expected that any one will help me by giving the steps that should be done and then I'll research each step. I didn't expect to be blamed for sending a question here. Thank you for not answering my question, Well, you're welcome 😉 (joke)... Sorry, but you provided very little background, not even what version of ArcSDE geodatabase / ArcGIS you are running and what procedures you tried, nor specific issues you encountered we might be able to answer. Maybe these Help pages are of use, and if you specify what exact issues or error messages you encountered, some of us might be of further help: A quick tour of setting up a geodatabase in Oracle Methods for moving a geodatabase in Oracle Moving a geodatabase using an XML document And maybe this OTN Community thread with rather detailed instructions on duplicating a database is of some use: TIP 04: Duplicating a Database in 10g by Joel Pèrez https://forums.oracle.com/thread/247436 ... View more

I have a task of moving an oracle database with SDE (geodatabase) to a new server. I don't have experience in Oracle so I need detailed explanation if possible, so I need to know what is the best way to do this task. The source server is Windows Server 2008 R2 The source database server is Oracle10g The destination server is Windows Server 2008 R2 the destination database server in Oracle11g Thank you in advance, I am always slightly surprised to read these kind of questions. Yes, admittedly, I have taken on tasks for which I wasn't initially qualified too, nor had experience in, but I always started out reading a ton of (ESRI) documentation about the subjects and software I needed to take on, and familiarizing myself with the software I needed to use on (test) machines, before I started posting any specific question about issues I may have encountered. You can't just start from scratch and hope for a "cookbook" to solve your issues... Start reading the Online Help and ESRI's extensive (whitepaper) online documentation (e.g. here and here), get some course in Oracle or familiarize yourself with it. ... View more

Later this year we'll be upgrading our SQL Server 2008 to 2012,  Right now we're using SQL Standard 2008  edition on a server we're using for both development and test.  The manager working with our Microsoft rep says all we need is the developers edition on this server.  That just doesn't sound right to me.  Does that sound kosher?  Thanks I think this link answers your question: http://dba.stackexchange.com/questions/37149/when-is-it-appropriate-to-use-sql-server-developer-edition As long as all of the users of your test environment have an associated developer or developer CAL (client access license) license, you should be fine... If instead, you have only a limited amount of (MSDN) developer licenses, and a lot of non-licensed "normal" users are involved in testing (at least a significant bigger number than you have developer licenses), you might be violating the license agreement... it seems to work on a per-user basis. These two links may be of use too: http://social.msdn.microsoft.com/Forums/sqlserver/en-US/2f40a273-a928-4e05-93e3-b4196283a1a4/sql-server-license-for-developer-edition http://www.microsoft.com/licensing/about-licensing/client-access-license.aspx ... View more

2) Trying to Publish the REST Endpoint that exposes the MySql Spatial data as xml or json(xml preferable) Is there any other best idea to do this please revert me if any of you guys are working with similar kind of work process Can't comment on the specifics of web services and REST, as I have no experience with it, but if you are able to expose feature data as JSON, you might be able to make some good use (possible or most likely after your own code customization) of ESRI's new Spatial Framework for Hadoop and the Geoprocessing Tools for Hadoop, as it contains functions for converting JSON data to and from geodatabase Feature Classes. That is probably not a good end-point for you, but since the code is Open Source, you may be able to convert to some other format more suitable to your requirements on the client side. I guess this is a rather involved procedure though, some people with more experience in this area can probably come up with easier solutions and references to useful code. For some insights into what the Spatial Framework for Hadoop is, see my PDF and all the references therein here. ... View more

After investigating the "Parcels" feature class it seems that somehow there are records (3 total) with AREA and LENGTH of 0.  I'm not sure if this is by design with the Parcel Fabric or not?   I assume this is what is causing the extents to go all the way to the extremes.  Any info on the SRID 0 issue? Well, I can't speak for ESRI, as I am not working for them, nor do I have experience with Parcel Fabrics, but I am pretty much 100% sure this is "not by design"... It seems your current workflow introduces geometries with areas so small the shapes "collapse", or they may contain polygon features with less than 3 vertices (minimum for any polygon). This might be due to some editing actions and sliver type polygons introduced by them that you may not even be aware they exist. It seems more regular checks on geometry and topology is in order, use the ArcGIS tools for that. As to the SRID being reported as 0, IDK... ... View more

One thing to take note of when converting from a file geodatabase to an ArcSDE based (SQL Server Express in your case) database, is the user permissions. With a file geodatabase, you don't have to worry about database user or Windows accounts etc. With an enterprise geodatabase, albeit "personal" ArcSDE, you do... If you don't setup a proper system for database users and permissions on Feature Datasets / Classes using roles, you may be unable to access data even though already converted and inserted in the database unless you set proper permissions. This is especially true if you run multiple accounts on the same computer, e.g. administrator or restricted users. ... View more