[UPDATE 3/1/07 8:00am : After a few emails with ESRI, they agreed that discussing their public API, as it relates to the security of passwords is reasonable, and they have confirmed that the password that is returned by IWorkspace.ConnectionProperties is encrypted. For obvious reasons they will not disclose any of the technical details. Thanks to ESRI for confirming this, and for permitting me to share the answer.]

[UPDATE 2/28/07 7:50pm : I received a request from ESRI to take this posting, and my related forum post down because they discuss security and encryption related to their software. At this time, I'm taking the posting down, and will work with them to determine a reasonable update. Stay Tuned]

[ORIGINAL POSTING]
I posted a question [I deleted it's contents at ESRI's request] over at the ESRI forums about this, but thought I’d also throw it out here as well. Essentilly, I’m looking to build a secure application, and I want to know if it’s possible to extract the connection password from the data returned by IWorkspace.ConnectionProperties. I posted some VBA code from an EDN sample that pulls the connection properties from the first layer in the map and displays the properties in a popup. All I added was a few lines which would actually write out the password byte array.
 

What I’d like to know (preferably from someone @ ESRI) just what that byte array is. I suspect it’s the password encrypted, but it could also be a hash. If it is the password encrypted, where is the key? How safe is it? If it is a hash, is it reversible?

[Clarification: In my  original posting, I had asked a series of rhetorical questions (above) - I did not expect to get these answers from ESRI, nor do I really want them - I really just wanted to know that the password is "relatively" safe - i.e. encrypted.]

I had heard that raster performance in a File Geodatabase was good, and thought I’d check into it. For source data I used 4 tiles of 6 inch orthophotography. The files are TIFFs, and come in at 715MB each.

Initially I tried loading all 4 into ArcMap, and it just took too long to display, so I killed ArcMap, and re-started by just loading one.

To load and draw the file (no pyramids) took ~60 seconds (based on my watch)

Next, I used ArcCatalog to created pyramids for another of the tiles (took a few minutes and created an 80Mb RRD file). This loaded in about 5 seconds.

Finally, I loaded all 4 TIFFs into a file geodatabase (again took a few minutes). The resulting File Geodatabase is 2.87 GB in size, so it’s a little bigger than the source TIFFs, which were 2.7GB. When loading into ArcMap, the layer took about 1 second to draw (again using my watch – it maybe a half second – hard to tell, other than it was FAST).

The other thing to note is that in both the TIFFs, the resulting image looks pretty choppy at this scale (compare the images above). The File Geodatabase image looks great.

As far as zooming and panning, the File Geodatabase just rocked. It’s screaming fast. This next shot is at full resolution – I zoomed in 3 times drawing a rectangle each time, and the screen re-draw just about as fast as I could draw the boxes. Amazing.

The TIFF with pyramids seemed to be about the same speed with panning and zooming, but the TIFF without was consistenly a much slower 2-5 seconds for a pan or a zoom.

So – if you’ve got imagery that’s slow, try out the file geodatabase and see if you get the same boost in speed.

Note: All these tests were done on a local disk – connecting across a network will impact performance.

I was looking around for the archived version of Wednesday’s “Intro to the ArcGIS Mobile SDK” training seminar (incidentally, it’s not up yet), and found a recent entry that talks about building ArcGIS Server applications with the .NET Framework.

Although I have not checked it out myself (yet), if you are jumping into ArcGIS Server development with the .NET Web ADF, this should be a good starting point.

I just got Image Server up and running and the first thing I did was dump in 500GB of tiled TIFFs. Since I used the software in the early betas, I was excited to see the New Service Wizard. This greatly streamlines the creation of an image service, and I quickly whipped through it and hit “Finish”.

While I did see the “Generate overviews” check box, and I conceptually understood that this would create a set of reduced resolution images for use at larger scales, the impact of this decision is not exactly obvious.

 

At this point, it’s been chugging for 8 hours, and created 845 overview files, and I’m thinking it’s nearing completion, but it’s hard to tell. I have no doubt that once it’s all done, the image service will be screaming fast, but it would be good to have some indication as to how long this process might take. The other option is to uncheck the “Generate Overviews” option, and just create them manually. In that case, you could get the imagery staged up very rapidly, and simply put scale dependancies in your map so that you don’t turn the imagery on until you are very zoomed in.

Anyhow – just thought I’d post this so others know what they may be getting into if they check this box.

Thought it would be fun to gather the various ESRI bloggers and blog readers for some face to face conversations and beers. The ESRI Showcase and Vendor Expo ends at 7:00pm, so let’s meet up at about that time in the Wyndham bar (it’s in the lobby for those who have not been there before).

See you all there!

In building ArcExperts.net, I wanted to create a simple blog roll from the OPML file that I was using to run the aggregator. For those not familliar with it, OPML is an xml “format” which describes a list of blogs. i.e…

Before digging into this I did a little Googling and found an example where someone was using an XmlDataSource to do something similar. For grins I tried it and had a blog roll up in about 5 minutes. Here’s how (download the source to skip the steps):

1) Create a new web project in Visual Studio 2005
2) Copy an OPML file into the root (get ArcExperts one here)
3) Add an XmlDataSource to Default.aspx
4) Point it at the OPML file. In the XPath box enter opml/body/outline
(this just tells it to bind to the outline elements in the file – which contain the items we want in our list)

5) Drop a DataList on the page, and set it’s data source to the XmlDataSource

6) Add some markup so we get a nice list

7) Done – view your output and add more CSS to make it pretty

Maybe you all use this every day and are very ho-hum about it, but this was my first time using this, and I think it totally rocks.

Download the source code here

The ArcExperts.net feed is up and running. It caches for 15 minutes, pulls it’s own copy of the feeds, and is running through Feed Burner.

You can subscibe using this url: http://feeds.feedburner.com/arcexperts or directly at ArcExperts.net

Neither the site, nor the RSS feed are particularly optimized beyone caching. Specifically, they do not utilize Entity Tags or SkipHours in the source RSS feeds (read more here). Both of these allow the consumer of a feed to be more intelligent about when it pulls feed data – thus saving everyone bandwidth and improving performance. Also, the underlying JRN blog roller code does not specify how far back the posts should be pulled – it just says how many posts should be pulled.  So, for blogs where there are sparse postings – say one in May, one in June, 2 in September and one in November – the current code would fetch all of them because it’s just pulling the last 5 posts in the feed (this assumes the person’s rss feed is not date sensitive – many are).

If we actually get a reasonable number of subscribers / users of the site, then I’ll look at re-tooling it – either with Dimitry Robsman’s ASP.NET RSS Toolkit, or just try to re-work the JRN blog roller code to be a little smarter.

Anyhow – it’s up and running, and we’ll see how it goes. Contact me if you’ve got questions / ideas / want a blog added or dropped etc.

Just a quick note – ArcExperts.net does not have an RSS feed yet. Your browser or RSS reader may detect a Feed on the page, but it’s just picking up the feeds on the Blog Roll.

I’m going to try and whip up an RSS feed this evening, but we’ll see how that goes. I think it should be pretty easy to put together as I parse the feed items, but I’m a little unsure about ordering the xml fragments by date. It will also use a 15 minute cache.

Also – If you’ve asked to have your feed added,  they will be added this evening.

I will post the feed once I have it working.

Since PlanetGeospatial is running in “Lite” mode, and I had a few hours while my son was napping,  I decided to put up a blog roller that will aggregate ArcGIS / ESRI Developer blogs. I like PlanetGeospatial, but all the Google Earth / Virtual Earth and Island shoreline stuff was a little off-topic for me.

Anyhow – you can play with it over at ArcExperts.net. I grabbed this domain a year or so ago, and it’s just been wasting space, so it seemed like a good home for something like this. As usual, this is a free service – any ads which show up are part of the originating RSS feed.

About the code…
The site is ASP.NET 2.0 code, based on the JRN Blog Roller project that’s hosted over at CodePlex.com.
This gave me the foundation of the roller itself – conveniently packaged as a UserControl that is easily embedded into any page.

At it’s current 0.3 release, JRN’s blog roll configuration is a semi-colon delimited list, stored in the web.config file. Since this was kinda kludgy, I grabbed an OPML parser from Bruno ‘Shine’ Figueiredo’s site
http://www.brunofigueiredo.com . By folding these two together, I’m able to
manage the blog list as an OPML file (download here), and still leverage the bulk of JRN (which actually is pretty lean).

I also took this opportunity to play with XmlDataProvider and found out just how easy it is to work with Xml files in ASP.NET. The blog
list is literally 5 lines of code… I’m going to do post about this since it was just so crazy easy to use.

Getting on the Roll…

If you want your blog added to this site, contact me through this site, or over at ArcExperts.net. If your blog is listed, and you want it removed, same thing. Right now it’s working with RSS 2.0 feeds and stuff from Feedburner. I’m skeptical if it will parse Blogger.com feeds – if someone wants to have one added, I’ll try.

Performance…
I’ve set things up to cache for 15 minutes, so as long as people hit it occasionally, it should be pretty speedy. I’m still having issues with my hosting, so we’ll see how this works out.

Future Additions…
When I have some more time, I’m going to change the main page to background load the feeds via Ajax. From there I’ll create a RSS feed from the site, and run that through feedburner.

I’m open to any other ideas, and would love to hear how this works for everyone.

I’m on the road this week, but thought I’d post a quick follow up to my posts on creating configuration section handlers for your .NET applications.

This is a case where you may “know” something, but you do something, which leads to really  “understanding” that thing. In this case, I knew that config handlers are cached – the config file is only read once, and the data (objects etc) that you create in the handler are then cached. This is done for efficiency, and that makes sense.

In a project I was working on I created real business objects from my configuration file. In their role as business objects, they maintained selection sets on
particular layers (hence the config file) in an ArcIMS application. And actually stored them in Session.

This all worked fine, and things were progressing until two of us hit the app on the same server at the same time. For some reason, we appeared to be sharing the same selection set. I would select a feature, and it would appear on my map, and and the other users map. This caused a few minutes of head scratching before I clued into it – the objects that were created in the config section handler were cached by ASP.NET, and thus each session was accessing (pointers to) the same instance of the objects – thus the selection set appeared to be shared.

Interesting behavior, if that’s what you’re after. This was easily solved by whipping up a quick SimpleClone method that I could invoke prior to setting other properties and sending the object into session (I opted not to implement IClonable because I did not want to actually clone the whole object hiearchy – just a simple clone of the configuration data). This solved the issue, and showed that despite “knowing” something, sometimes it’s hard to see the implications.

Thus, my suggestion is to only create <myobject>Config classes from Configuration handlers – this will help avoid the tendancy to simply use the classes directly, and possibly stuff them into session where you’ll get unexpected results.