|
POST
|
Jamal, Before I (or someone else) can answer this properly, can you tell me one thing: Is version U2 derived / based on / a child of version U1 or is version U2 derived from SDE.DEFAULT directly?
... View more
10-01-2013
10:14 AM
|
0
|
0
|
15291
|
|
POST
|
I don't know what your options are, but the first thing that comes to mind is using ArcEngine, which gives you all the power of ArcObjects to access the full geometry info. Or maybe ArcGIS Runtime, which can be deployed as a "desktop" type applications as well (besides mobile devices platforms), but I have no clear picture of the current limitations regarding geometries in that. But if ArcEngine or ArcGIS Runtime is no option, other than that, you may get into the "web services" and ArcGIS for Server realm. You might run an ArcGIS for Server "Feature Service" of your ArcSDE Compressed Binary data, or maybe an OGC WFS, and than use for example ESRI's SOAP API to access this. It is an ESRI "Feature Service" in combination with the latter API, what ESRI is using to make true curves available in ArcGIS for AutoCAD (see the remark by ESRI's Karen Hodge in this lengthy thread). The SOAP API seems to have Curve and PolyCurve (returnable in for example JSON), as possible geometry types, with curve even seeming to support Bezier Curves. There are some lesser known options, like the ability to create a Server Object Extension based on ArcObjects, possibly allowing you to expose detailed geometry info in whatever format you like via web service, without having to resort to ArcObjects based applications on the client desktop.
... View more
09-26-2013
10:28 AM
|
0
|
0
|
1699
|
|
POST
|
But here's the twist: the SDE user can connect to the production database via any method. Again, this was not true last I posted; something IT changed during this process made it so. So, again, I am left to strongly suspect permissions as the root issue. I will post when the resolution appears. If the SDE user can access the same database from exactly the same client PC, and access the full (ArcMap) geodatabase functionality without issues, than I think you are right and we can exclude an issue with the ArcSDE Repository, and also a possible misconfiguration of the database client on the client PC. The permission track you are on sounds right, especially in the light of all the other issues related to permissions and roles you highlighted in your last post. You may find this Help page useful to track down the issue: User privileges for geodatabases in Oracle
... View more
09-26-2013
08:52 AM
|
0
|
0
|
497
|
|
POST
|
Then do I need to purchase hardware (GG03) and software (Zeno Connect) just to get my GPS device (leica CS25) connected with my laptop/tablet machine? Another question is if you are aware of the accuracy achievable with and without an external GPS antenna like the GG03, and whether that plays a role in your decision, or need, for extra hardware. Looking at the specs for the Leica-CS25, it seems the CS25 will only achieve a 2-5 meter accuracy on its internal GPS antenna (and that is corrected by an external augmentation signal as WAAS in the US or EGNOS in Europe). If not using augmentation or DGPS, it will be worse. If you need RTK/DGPS "survey" accuracy down to the cm level, it seems you either need to have the compact antenna that is provided as part of the Leica CS25 GNSS package (which will give you 10-20 cm accuracy when referenced to a base station, and is directly pluggable in the CS25 computer), or a bigger fully separate "pole type" GG03 L2 receiver, which should give you up to cm level accuracy when corrected by known references. Depending on the age of the unit, there is either a MiniGPS or U-Center application installed that manages the NMEA data. You may be able to utilize it to relay the data to a bluetooth port or the serial port, but it is unlikely. It probably is not of any direct help since the GPS unit is not in the laptop, but in the separate CS25, but it seems ArcGIS / ArcPad 10.2 has enhancements in this respect via new customization options using the Windows Locations API, and the new "Location Sensor" option in ArcPad based on this: What is a location sensor? What's New in ArcPad 10.2 (Video) And see this for other ideas to directly tap into NMEA data (for those with electronics skills...): GPS Test 1 - Reading NMEA Data using an Arduino http://www.arduino.cc/ NMEA data The internal GPS of the CS25 unit is on COM 3, with a baud rate of 38400. So if your software was on the CS25 unit, you'd make the appropriate COM port and baud rate settings. It probably is easier to install ArcPad (Studio) on the the CS25, and do testing using live GPS there.
... View more
09-25-2013
08:49 AM
|
0
|
0
|
11318
|
|
POST
|
Everything works fine but connection is so slow...Their all tables are granted as public. So when i connected to database from Arc Catalog i can see the all that hundreds of table from all users. I don't know this can be reason of this slow problem... Any one has some idea what is my problem? It most likely is the problem... Granting access rights, even if it is read-only, to all tables in what most likely is a non-geodatabase enabled enterprise database, certainly isn't best practice. Your solution therefore is to create database roles in Oracle, and associate the database roles with appropriate read/write access to particular tables as necessary in your GIS workflows, and assign your individual GIS users (yourself) or even better (Windows) user groups to the appropriate database roles to limit access to spurious tables.
... View more
09-25-2013
02:09 AM
|
0
|
0
|
857
|
|
POST
|
ArcSDE does not use ODBC in Oracle (Informix only). - V Sorry, should have written "database client" instead of ODBC database driver... although for those not knowing it, it seems ESRI will support the Microsoft ODBC database driver for SQL Server as well for Direct Connect in a future release: http://forums.arcgis.com/threads/86711-Direct-Connect-to-SQL-Server-2012-in-10.1?p=307267&viewfull=1#post307267 and http://forums.arcgis.com/threads/86711-Direct-Connect-to-SQL-Server-2012-in-10.1?p=307517&viewfull=1#post307517 I agree Query Layers have nothing to do with geodatabase system tables in the ArcSDE Repository, but they do have some similar dependencies as Direct Connect on proper ArcGIS and database client installation / configuration. Anyway, Marianne still needs to answer if my assumptions of post 7 were correct, might tell a bit more of what might be wrong.
... View more
09-21-2013
11:16 AM
|
0
|
0
|
2875
|
|
POST
|
One added bit of info: the user can create a Query Layer (10.0) and an ArcSDE Connection File (10.2). The error is only thrown when attempting a direct connect. This makes me curious... Am I correct to assume that what you are saying here is: - You can access some Feature Classes in 10.2 by a means of an ArcSDE Connection File and running ArcSDE Application Server. - You can access these same Feature Classes by means of a Query Layer in ArcGIS Desktop 10.0 - You can't access these same Feature Classes by means of a Query Layer in ArcGIS Desktop 10.2 - You can't access these same Feature Classes through Direct Connect in 10.2 Are you sure you have installed a proper ODBC database driver on your Client PC that runs 10.2? Is the Oracle Client fully functional, can you execute SQL commands against your database?
... View more
09-19-2013
03:06 AM
|
0
|
0
|
2875
|
|
POST
|
If I were you, I would refrain from incorporating "geometry type" in Feature Class names, unless you maintain multiple geometry types (polygon, polyline) for what are in essence a single Feature Class and need unique names... (which probably isn't best practice, if you need to have a "boundary line", you can set a legend on a polygon Feature Class to only display the outline, instead of maintaining a seperate Feature Class with polylines). ArcCatalog displays geometry type (polygon, polyline, point), through it's usage of unique icons, so there is no need to include something like "Line" in a Feature Class name. This saves you at least 4 characters, and if you skip "Boundary" as well (which will be obvious in the context of a polyline feature class for "areas"), you save another 8. NanaimoSDE.Engineering.AdministrativeAreaBoundaryLine Alternatives: - NanaimoSDE.Engineering.AdministrativeAreaBoundary - NanaimoSDE.Engineering.AdministrativeArea
... View more
09-19-2013
02:50 AM
|
0
|
0
|
7548
|
|
POST
|
7. Open a SQL window and run the command EXEC sde.version_util.set_current_version('MY_VERSION') -This is when I get an error ORA-00900: Invalid SQL Statement. -A coworker recommended trying to run this command in the PL/SQL command window as the following: BEGIN EXEC sde.version_util.set_current_version('MY_VERSION') END; -But then I couldn't figure out how to run the select statement and see a returned record. Have you tried including the SELECT statement inside the same BEGIN/END block? What do you mean with the bold text, I understand you want to export to CSV. I must admit I am less familiar with PL/SQL, but I guess there may be commands for that. Just Googling on "pl/sql export to csv" turns up a whole bunch of code samples you may find useful...
... View more
09-12-2013
11:44 AM
|
0
|
0
|
1641
|
|
POST
|
I'm using a 10.1 SP1 client. My test SDE database is 10.2 ... Anyone have any ideas? Your problem may be here. While ArcMap 10.2 can connect to SDE geodatabases of a lower version, as it is backward compatible with most versions of SDE geodatabases still around, I am pretty sure a 10.1 client is not guaranteed to connect to a 10.2 successfully. Your asking for forward compatibility here... I would recommend you to upgrade your ArcGIS for Desktop client to 10.2 and try again. BTW, as of 10.1, versioned views should be automatically created each time you enable versioning on data, so there is no need for step 3 in your description. See this Help text from the link you gave: "Beginning with ArcGIS 10.1, versioned views are created when you version data. If your data was versioned prior to 10.1, you can create a versioned view by running the Create Versioned View geoprocessing tool."
... View more
09-12-2013
11:27 AM
|
0
|
0
|
1641
|
|
POST
|
I have tried replicating the issue in our development environment by launching the script in task scheduler there, but have been unsuccessful. I am thinking it is something unique to production, ie a conflict with another process etc. Have you ruled out differences in database privileges / rights between development and production? It might be that your development environment database user login has more rights than a "similar" user on production.
... View more
09-12-2013
03:00 AM
|
0
|
0
|
1303
|
|
POST
|
thank u Dan for ur reply, i want longitude , latitude and z value which i have given at the time of IDW interpolation, can u tell me how can i make grid file , is it in .grd format, how can i make .grd format or where can i find it. thanx in advance Your interpolation results may be meaningless or at least harmed if you don't use an appropriate projected coordinate system during interpolation. Please see the excellent explanation by William Huber in this GIS StackExchange thread: IDW spatial interpolation: appropriate projection? http://gis.stackexchange.com/questions/58105/idw-spatial-interpolation-appropriate-projection
... View more
08-30-2013
02:31 AM
|
0
|
0
|
1350
|
|
POST
|
Basically, we're provided the exact table structure for our spatial tables; specific to the decision makers decisions on how the tables should be structured. We have no say in how what fields these tables will include. They are designed to be specific for different feature classes though (i.e., buildings, natural resource surveys, power lines, etc. all have a custom fields but also have certain fields in common). The ancillary tables that store the majority of attribute data is totally up to us how it is structured. Here in the Netherlands, we currently have a big project going on bearing similarities to the one in the U.S. It involves a standardization of large scale mapping (1:00 - 1:1000) across the entire country. They have taken a slightly different path though. Instead of standardizing the actual implementation of spatial or attribute storage at any given sites (we're talking about a few hundreds at municipal, provincial and country level that use a variety of CAD / GIS systems), they set up a support organization / facility that will hold the main database. The point where standardization takes place is the exchange of new or updated data. All organizations are forced to comply to an exchange standard, and there are very stringent, mostly automated, checks on spatial (e.g. topology) and attribute checks before delivered data is accepted and entered into the main database. Any data that fails will be rejected and must be repaired. From the main database, a number of products will be delivered that all organizations will, by law, need to make use of internally. It is the "Gold" standard so to say. This means that exchange will be two-way. Data producers will also be data consumers for those parts of the main database they do not maintain themselves, and must have facilities to consume change updates (e.g. like in geodatabase replication). Currently, this process is ongoing. Of course, it will be a headache to some, but all major CAD / GIS software vendors here in the Netherlands have committed to this process and are starting, and most already have, implemented tools to facilitate this "change update" process and creation of standard compliant GML exchange format with the main database facility organization. What problems lie ahead no one can tell yet for sure, but I do know that one of the major players (a country wide governmental organization maintaining the highway system and river / coastal defences), has already been working with a similar "change update" process, storage of history, and stringent automated QC for years in combination with commercial data producers, and despite initial issues, have real world and extensive experience with this. This real world experience will probably pay off in this new project.
... View more
08-29-2013
11:55 PM
|
0
|
0
|
2477
|
|
POST
|
We do use triggers on many fields and in the past used them on our own geometry fields. We've changed things a lot lately to be in compliance with SDSFIE 3.0 standards and it has caused HAVOC! Basically, now all the fields we used to have in spatial tables are now in stand-alone ancillary tables. So our geometry fields are now in stand-alone tables...doesn't really make sense does it? I just did a very brief and quick read-up on this standard as I am not familiar with it. To what extent are these changes really necessary? Physical (Geospatial Platform) constraints may limit to what is feasible or wise. Funny, related to this, I encountered two contradicting figures in two official DoD PDFs: http://www.fgdc.gov/participation/coordination-group/meeting-minutes/2011/april/sdsfie-update-cg-20110419.pdf http://www.acq.osd.mil/ie/bei/disdi/factsheet_sdsfie.pdf Notice how the left figure shows a "Platform Dependent" implementation at the "Geospatial Technology Platform" level, while the right figure shows "Platform Independent" implementation. I do not immediately see how the implementation at that level could be "Platform Independent"... This PDF that you undoubtedly know of is interesting in the context of (ArcGIS) implementation: How Will I Get My Data into a SDSFIE Geodatabase? http://proceedings.esri.com/library/userconf/proc03/p0108.pdf EDIT: Ah, well, now noticed this is actually a very old 2002 PDF dealing with migration from coverages / shapefiles to a Geodatabase, not really relevant... although it does give some insight as to what you are talking about and background to the history of it. And these links seem more relevant and recent related to SDSFIE 3.0: SDSFIE 3.0 Data Migration http://www.acq.osd.mil/ie/download/disdi/presentations/SDSFIE3.0_Data_Migration.pdf An overview of the SDSFIE v2.6 to v3.0 migration process http://www.esri.com/esri-news/arcuser/spring-2013/an-overview-of-the-sdsfie-v26-to-v30-migration-process ESRI Support for SDSFIE 3.0 Implementation http://proceedings.esri.com/library/userconf/ieug09/papers/esri_support_for_sdsfie_nov2009_jay_cary.pdf
... View more
08-29-2013
11:54 AM
|
0
|
0
|
2477
|
|
POST
|
So essentially you are saying Wesley has no other option than to: - Create two new fields in the business table of the Feature Classes to store the Area and Length (the ArcMap displayed Area and Length fields can not be used since they only exist as "virtual fields" in the returned query result *** for SDO_GEOMETRY ***). - Populate these using for example the Calculate Geometry tool, or an equivalent Oracle Spatial SQL statement. - From then on, possibly use database triggers to update the fields using Oracle Spatial SQL statements to cope with any changes in the Feature Classes geometries, to get the desired automation.
... View more
08-29-2013
10:40 AM
|
0
|
0
|
3343
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 01-31-2026 04:45 AM | |
| 1 | 12-08-2025 09:12 AM | |
| 1 | 12-05-2025 12:38 PM | |
| 1 | 12-04-2025 10:08 PM | |
| 1 | 12-04-2025 10:11 AM |
| Online Status |
Offline
|
| Date Last Visited |
05-29-2026
03:22 AM
|