James Fee GIS Blog

26 responses so far ↓

• 1 Tim Maddle // Dec 19, 2007 at 6:26 pm

  I really want to start working with ArcGIS Explorer. It is much improved from the slow, klunky 3.x betas. I pulled in a simple KML polygon layer and was amazed at how it gave a nice 3D gradient shading to the polygons. On the downside, Google Earth was still far more flexible in terms of tweeking the KML in the viewer without having to directly edit the text file and Explorer didn’t do as well with a shapefile as I had hoped.

  Still, Explorer is much faster than it once was, and the API seems to be a big plus over Google Earth. The hard part is always finding the time between the barrage of “get it done now” projects.

• 2 Bonzo // Dec 19, 2007 at 6:59 pm

  I’m glad they told us it was released at “approximately 1:58 p.m. PST”. Was someone’s job on the line to get it out before 2:00 or what? Well, it’s approximately 7:59 PM CST and I’m submitting this post.

• 3 ebp // Dec 20, 2007 at 8:14 am

  Can it read directly from an sde gdb?

• 4 newversions // Dec 20, 2007 at 8:54 am

  Look what I’ve found out there about this new version:
  http://ahogo.blogspot.com/2007/12/arcgis-explorer-build-440-released.html
  hahaha!

• 5 James Fee // Dec 20, 2007 at 9:12 am

  @ebp: Still only file geodatabases. I believe you should use ArcGIS Server Basic to use “SDE GDB”. AGS Basic is included with ArcGIS Server Enterprise.

• 6 Matt // Dec 20, 2007 at 11:01 am

  I successfully installed and tested it at home last night. However, tried it at work today on my brand new PC and it crashes with errors when launched. In fact, after pointing to our internal ArcGIS Server test services my computer shut down and re-booted itself. Same thing happened the next three times I tried it after uninstalling, reinstalling, checking system requirements, etc. Big bummer!

  Cheers,
  -Matt

• 7 James Fee // Dec 20, 2007 at 11:08 am

  I’ve had great luck with this release. By far the most polished version of ArcGIS Explorer I’ve used to date.

• 8 Leandro.ar // Dec 20, 2007 at 12:39 pm

  The shortcut created in Program Files… doesn’t work for me.
  I’ve navigated to the folder where the file E2.exe is located and execute from there. After that, I’ve created the shortcut myself and the program has run correctly.

• 9 Kevin // Dec 20, 2007 at 4:53 pm

  @Matt
  Try deleting you cache folder for ArcGIS Explorer:
  C:\Documents and settings\%user%\Local Settings\Temp\AGX
  Then re-starting.

  http://forums.esri.com/Thread.asp?c=184&f=2206&t=240585&mc=4

• 10 Unfrozen Caveman Lawyer // Dec 20, 2007 at 5:44 pm

  What’s with the new AGX globe logo?

• 11 timmy // Dec 20, 2007 at 6:28 pm

  any thoughts on using ArcGIS Explorer to allow non-GIS staff to view spatial data via an SDE database vs. using the standard web interface that comes with ArcServer?

  Mainly interested in the capabilities of working with the ArcGIS Explorer ADF vs. customizing the web interface via ASP.NET

• 12 ebp // Dec 21, 2007 at 7:49 am

  @timmy

  If you come up with a solution let me know. I’d like to do the same.

  We recently installed sde where I work, and I’ve been able to generate services from the feature classes stored in our database. It’s all very nice.

  But, I was suprised to learn that A.E. wont read feature classes stored in SDE geodatabases.

  I suppose I could replicate to a file based GDB. Seems a convoluted route to make it all work though.

• 13 anon // Dec 21, 2007 at 7:57 am

  @ebp: Seriously you want to use ArcGIS Server to server up datasets rather than filegeodatabase or shapefile. Performance is so much better when you let the server handle the 3D globe than the client. It just rasterizes the local files anyway so it isn’t a good way to go.

  Just serve up the SDE using ArcGIS Server and be happy.

• 14 timmy // Dec 21, 2007 at 10:17 am

  AGS is definately the way to go with AGX, if you have the hardware power to do it.

  My question was more aimed at developing custom tools via the AGX ADF vs. the web ADF with ASP.NET. Does one offer more functionality over the other? I guess that’s a pretty indepth question depending on needs, license level and many other factors.

• 15 Bill // Dec 21, 2007 at 6:29 pm

  I’m with James. This version is the best one yet. I like the rapid pace of improvement. I can’t wait for ESRI to implement this software development process across their whole product line.

• 16 Tim Maddle // Dec 23, 2007 at 12:18 pm

  I think timmy hits on a point when he says that AGS is the way to go -IF- you have the hardware power to do it. That might be a big “if”. Being forced to use AGS to view SDE layers via ArcExplorer means more load and memory usage on your AGS server machine. Certainly for internal use, a direct connect option, ala ArcMap, would be a very welcome addition.

  On the topic of the Explorer ADF versus the .NET ADF, I can’t give you much of an opinion either way, except to say that both seem powerful. I’m swinging towards Explorer because I like the speed and flexibility a user has when navigating in the application.

• 17 James Fee // Dec 23, 2007 at 2:13 pm

  @Tim: SDE ceases to exist at 9.3 so I see no issue using ArcGIS Server (which is already installed) to view “SDE” layers. Plus adding layers directly to AGX just results in them being rasterized anyway. AGS is by far the better choice to view even Shapefiles.

• 18 Tim Maddle // Dec 24, 2007 at 4:36 pm

  @James, perhaps I should have used the term Spatial DataStore (SDS) instead of SDE.

  In ArcGIS 9.2, if you have ArcMap and AGS and want to view a layer in your SDS, you have the following options:

  1. Connect via an “SDE” process (i.e. giomgr.exe(?)) running on a server (usually the same server as the RDBMS).

  2. Use the “direct connect” option in ArcMap, possible because ESRI has built much of the logic that used to be only the SDE process directly into ArcMap.

  3. Publish the layer as a service in AGS (i.e. a SOC.exe process) and add it as a GIS server connection.

  In Explorer, you have this option:

  3. Publish the layer as a service in AGS and add it as a GIS server connection.

  The “direct connect” option has distinct advantages in terms of end-user flexibility and conservation of server resources over publishing layers as AGS services. Given a choice, I would tend to think this would be the preferred option for internal use.

  The data is available sitting there in the Spatial DataStore - why should we have to jump through another hoop of publishing it via AGS to make it viewable in AGX? Why make me publish additional MXDs and take up additional server resources?

  I don’t want to complain too much, because I do think it’s a nice product, but if I could just open up AGX and pick layers off the SDS and pull them in without having to publish them in AGX, that would be a real win and (even with view-only capability), I bet that AGX would be one of the most popular apps in my organization.

• 19 James Fee // Dec 24, 2007 at 4:45 pm

  Wouldn’t you rather have the server handle the globe than the client? Seems backwards to me to not just consume the 3D globe layer natively from AGS rather than convert the SDS to a raster image on AGX.

  Because of how AGX works, you can’t consume vector layers natively at all so it makes no sense to me to bother with local connections when AGS is just sitting there waiting to be used.

• 20 Tim Maddle // Dec 30, 2007 at 10:22 am

  James, here’s another long post. I wish I could explain in fewer words, but here are my thoughts.

  When you’re talking about environments such as Google Earth or AGX, I think there is value to moving as much work as possible to the client. The ability to pan and zoom in a very dynamic fashion in these environments mean they can make many more requests and put a lot more strain on your server. Add to that the fact that I don’t find AGS to be particularly zippy, and, IMO, the ability to directly open layers from the SDS in AGX without going through AGS would be a valuable addition.

  In regards to AGS just “sitting there”, that doesn’t negate the fact there is a cost involved with publishing layers. This change in 9.3 seems to mean that we’ll get one additional installation of the full AGS product. When we upgrade the server that runs the SDE process (which is currently how we connect), that server will now be a full-fledged AGS server instead of just an SDE server. However, that box is also our RDBMS box, and that is one server that I definitely cannot devote RAM and CPU cycles towards running AGS map services. That server will still just run the SDE process, meaning the extra AGS capabilities will go to waste. I suspect that we won’t be the only organization who faces that situation, especially among smaller organizations.

  Theoretically, if we configured our ArcMap users to connect to the SDS using direct connect, we would no longer have to run the SDE process on our RDBMS box. That would free up the AGS license to run on another box (assuming we had a spare server), but if the 9.3 licensing is like the 9.2 licensing, the AGS license will transfer to the existing hardware as it is currently configured. That means we can’t take that license that is currently only running the SDE process and move it to another server that we’re more comfortable using as a full-blown AGS server. I’m not sure how strict ESRI is in terms of the moving licenses, but, per the licensing summary that was linked to from this blog, the 9.2 license agreement does specify that it transfers to the existing hardware as configured at the time of the upgrade.

  Most of our SDS rasters and feature classes are not available as services in AGS, and the nature of AGS seems to hinder our ability to make them available. Most of our data is not organized as one big feature class, but a number of regional classes. To publish a complete raster or vector dataset, we need to create an MXD that has 10-20 layers instead of one, and the more layers in an MXD, the more memory AGS seems to use.

  In the end, I would just reiterate that the ability for any user in our organization to open up AGX and browse to a layer on our SDS without me having to use time or server resources to publish the layer (because most of our SDS feature classes are available via AGS) would be a welcome addition. Either that, or slim down AGS and make it more memory efficient and faster.

• 21 James Fee // Dec 30, 2007 at 2:57 pm

  Tim, that all makes sense except the purpose of clients such as Google Earth and AGX is that they are clients for servers, not stand alone products. It sounds like AGX or GE might not be best for what you propose.

• 22 Tim Maddle // Jan 1, 2008 at 4:57 pm

  This leads me to a great idea. If I can pull it off, I’ll let you know.

• 23 Timmy // Jan 2, 2008 at 6:30 pm

  Tim -

  Your long but enjoyable post begs to me ask this beat to death question here….

  Currently we have two servers supporting our GIS, a box with AGS installed on it, it hosts all of our services and our websites. Then we have our database box running SQL Server. We use direct connects to the database. We’re licensed for four cores. Our AGS box has two, and I believe our SQL box has two. Since we’re using direct connects, do the cores on our database box count against our license limits?

  I realize this is a bit off topic, however everyone I talk to at ESRI, including the technical PM’s down in Charlotte, tells me something different. Just seeing if anyone has any similar situations in which they found the answer out the hard way.

• 24 Tim Maddle // Jan 3, 2008 at 5:52 pm

  Timmy, I won’t pretend to have a legit answer to your question. I just realized how big an assumption I was making thinking that going to direct connect would free up the license currently on the SDE machine. Maybe when 9.3 comes out there will be further clarification.

• 25 Tim Maddle // Jan 7, 2008 at 6:16 pm

  Timmy,
  here’s a link from Dave Bouwman’s blog where he believes that if you use Direct Connect, the RDBMS box does not “consume” licenses:

  http://blog.davebouwman.net/2006/11/18/ArcGISServerLicensingTheFinePrint.aspx

  Again, I guess only ESRI has the final knowledge. Hopefully you can make some headway on that front.

  On another topic, I was able to bring my project to life - a desktop WMS server that uses the HttpListener capabilities of .NET 2.0 and the Open Source MapServer to dynamically serve layers from ArcSDE without requiring them to be set as services in ArcGIS Server.

  On the upside, this tool worked great in Google Earth. On the downside, it worked not very well in AGX. Google Earth behaves as I would expect - each time you move the globe, GE sends one request for the WMS image of the current extent. AGX tries to be smart and create caches (even when I thought I set it not to). The result was very inconsistent performance. When a position change in AGX caused it to build a cache, everything came to a grinding halt as it pelted the WMS server with image requests. Then you’d get good performance as AGX used the cached images, but I never knew for certain whether changing position would be fast as cached images were used or really slow as new images were added to the cache. In addition, AGX seems to be slow in rendering the images.

  I wish AGX would go to the “dumb” model of just making a fresh WMS request each time the globe was moved or would quickly update the visible portion of the screen and do the caching in the background.

• 26 timmy // Jan 9, 2008 at 7:14 am

  Tim,

  Thanks for the link! The idea of direct connects not tying up a license seems to make the most sense, I’m just extremely nervous about getting a quad-core DBMS server when all we’re licensed for is four cores. My company is small with an even smaller budget, and a non-existent budget when it comes to GIS technology, so a bad recommendation would really put me in the dog house.

  I’ve also found AGX to be extremely slow. When you add layers from a FGDB, its works pretty well. Once you add a map service though, it’s like a dial-up all over again. With that kind of performance, we’ll have to stick with a web application.

Leave a Comment