The delivery guy just dropped off the package. I think we are looking at a final version in 4 weeks, just like Jack Dangermond said at Where 2.0. Remember, 9.3 is going to be a game changer for ESRI users with Javascript APIs, Google Maps/Virtual Earth support, KML support, the list just keeps getting better.
About
James Fee - jfee@weogeo.com
James works for WeoGeo helping people organize, share and monetize their geo-content.
Connect
Subscribe
26 Comments
YEAH more DVD’s!!
I guess it is better than a mountain of CD’s.
Must be anticipating issues though…. I recently noticed that the ESRI website now indicates a Q3 release instead of the promised Q2.
http://www.esri.com/software/arcgis/index.html
AA
Jack was up on stage at Where 2.0 saying “4 Weeks”. Everything I’ve heard via ESRI is this release is going very smoothly and will be quite the bug fix release.
I anticipate 9.3 being a release that we’ll all remember very fondly.
No one would be happier than I, would you be correct….. I and the +500 ArcGIS users I support.
Aaron
I better go check the mailbox, might take a day or 2 more to get to the eastern half of the US though…
@Jake B
I got mine in Maryland!
FWIW, 9.3 beta was pretty high-quality. With the RC now in hand, I can see 4 weeks being realistic.
So what is the point of the 9.3 Release Candidate if they are going to release a final copy soon?
@Bill
Time to go on a treasure hunt I guess.
@Tri
There you go with the hard questions!
It’s what I do.
It would be good to hear some feedback on 9.3 in particular with stability issues with geoprocessing tools and large complex datasets. Majority of organisation back here in UK are still on 9.1 due to bad rep of the 9.2 release – Would be good to jump straight to 9.3 once you lot have guinea pigged it for us.
Very good tip! thanks
Can someone tell me how to get the registration number for ArcGIS Server 9.3 Beta? I got the DVD too. thanks,
@Alex
You should have gotten an e-mail with the registration numbers. Are you the primary person on your ESRI account?
OK, I found it in the Media DVD. Thanks for your reply.
If you’re like me and you carefully read directions only as a LAST resort, you might want to know a little more about where the registration information is: There is a license file in the “EA” folder on the install DVD.
I’ve been playing around with 9.3 and so far I have not seen many differences from 9.2, at least not on Desktop stuff. This could be the fewest changes for a version upgrade in ESRI history. I’ve seen service packs that had more stuff than this.
Ah well it’s nice to test this out and work out the bugs befor e release.
Since everyone has been asking about 9.3 testing, I have been testing ArcGloble hoping that major bugs would be fixed. However, this is not the case when in ArcGlobe. When viewing Lidar Terrain Datasets with .25 foot pixel orthos in ArcGlobe on a 24″ monitor it crashes. I tested on a Dell Workstation laptop with a quadro 2500m inside, 3.5GB RAM, Windows XP 64bit.
In contrast, ArcScene has many improvements when using the flythrough tools. Our demo flythrough using high resolution imagery (.5 foot) overlay on a DTM TIN staggered when flying through dense tins but 9.3 fixed this issue.
I’ve been impressed with RC1 since it fixed some attribute editing bugs. Backwards compatibility with 9.2, 9.1, and 9.0 is a great feature when editing in ArcSDE and/or personal geodatabases.
Finally, export to KMZ is a really nice addition.
In 9.3, in my opinion I think this is a noteworthy release. 9.2 was ok but had many bugs in the new processes. 9.3 seems to be a logical choice; like 8.3 it seems to be refined. Even though we haven’t tested the server products yet (waiting to install RC1) Desktop really seems to be refined and the small tools added are high quality.
I’m a little confused about orthophoto generation tools. Why is ESRI trying to move in this direction? BAE, INPHO, Cardinal Systems, DAT/EM, ERDAS are powerhouses in the market. Personally, I think ESRI needs to focus on their core products instead of trying to do everything for every geospatial operation. Let’s focus on how to edit, analyze, and serve data better than the competition. Let’s create a toolset that is stable and oh……use multiple cores. Speed, performance and stability has been the slogan of ESRI for the last couple of years and still needs a lot of work but 9.3 is in the right direction.
@Bonz: As a Desktop user, 9.3 is what I wish 9.2 was. Fixing the little things that need to be fixed and improving the workflow. New features introduce new bugs. Faster and easier is what I think we all need at this point with Desktop.
I totally agree that performance and stability are still major issues and perhaps they’ve done better with 9.3 in these regards, I just haven’t really tested it enough to know for sure. Plus the laptop I have my 9.3 installed on is a much faster processer than my 9.2 desktop PC so I’m not sure how to compare the software performance alone.
So yeah I geuss I agree with you guys, this may be a significant upgrade after all.
I posted some demos I found on this and what we are planning on using 9.3 for on my blog. http://giswebdevelopments.blogspot.com/2008/05/arcgis-server-93-rc1.html
Just joined the thread, and was interested to see Luke’s comment on running 9.3 on XP x64 with an NVIDIA Quadro 2500m and 3.5 GB of RAM. It is important to be clear that ArcGIS 9.3 cannot run 64-bits and ESRI has no “immediate plans” (I guess with ESRI that phrase probably covers the next few decades…) to make it 64-bit.
Luke comments:
The best way to get “speed, performance and stability” is to run 64-bit code in 64-bit Windows, especially considering the tasks and data sizes that have become commonplace in the last few years. In 2008 to not be doing 64-bit products is totally lame… no other way to put it, as everyone who has upgraded from 32-bit GIS to 64-bit GIS will immediately attest.
Unfortunately, throwing away the performance, power and reliability of your 64-bit processor and 64-bit Windows is ESRI’s plan for 9.3 and at least the immediate future beyond (from the ESRI web site) :
I trust everyone understands that going 64-bit for ArcSDE while leaving everything else in lobotomized 32-bit mode is an admission they don’t have the technical chops to modernize their product line. That’s especially telling considering 64-bit Windows has been around now for, what? … three years?
Going multicore before 64-bit doesn’t make much sense because there’s little to gain by having two or four cores that are still bottlenecked by 32-bit limitations. I do agree that once you do the 64-bit thing, going multicore is a great idea as well, which is why modern GIS products that made the jump to 64-bits a long time ago also went multicore long ago.
However, writing parallelized code that can sensibly take advantage of multiple cores is much more difficult than it is to simply go through your 32-bit code and rev it up to 64-bit code. Since ESRI has failed to achieve 64-bit operation with 9.3 and has no immediate plans to remedy that failure, it seems very likely that in addition to falling far behind in 64-bit operation they will be even slower to give their users the benefit of modern multicore processors.
While I understand a user who has bought into ArcGIS desktop will be happy for any small gains and will thus applaud 9.3, in the middle of happiness for small things it would be wise to consider just how long you will wait for speed, performance and stability on the desktop while ESRI is off trying to bring back time-sharing with ArcGIS Server.
If they failed to do 64-bits by now and, worse, they’re openly telling you they don’t have any plans to do it soon, well, that’s a pretty clear sign they are not going to invest into the desktop to keep up with more effective competitors.
Dimitri: Missed you around here!
Interesting to hear more about ESRI and where its going (or not going) with 64bit. Thanks Dimitri for summary.
Sorry to sound stupid, I do understand the fundamentals to how a 64bit OS and 64bit designed package would be over 3bit, but as an end-user what would this actually mean when using AG-Desktop?
I assume when ive previously had memory issues when dealing with geoprocessing with large datasets, these would be resolved? Is it going to mean that I would be able to deal with larger and more complex datasets and process them quicker? This is something that has limited me in the past with 9.x.
However, id rather they sorted out all the memory leaks with their existing geoprocessing tools more so than providing me a 64bit enabled application.
Assuming they did a 64-bit implementation competently, almost certainly yes.
Yes, exactly.
Memory leaks are exactly the sort of problem that go away when you run 64-bit code.
Look, running 64-bit code is an enormous gain over running 32-bit code. It is a huge deal and the notion that anyone would run 64-bit processors or 64-bit Windows in lobotomized 32-bit mode is just a plain, garden variety rip-off. No excuse for it.
Dimitri, I think you misread “memory leaks” for “memory shortages”. Memory leaks are caused by programming mistakes and they are not going away automatically when you switch from 32-bit code to 64-bit code. That said, switching to 64-bit code usually means a fairly large rewrite / review of the existing code so I can see when that can help get rid of memory leaks as well.
64-bit rules, of course (an understatement).
Sam – We’re in total agreement. No, I meant “memory leaks” for two reasons, one of which was exactly the point you mention.
Before I reply, I’d like to take a moment to clear up a misunderstanding some folks have that has come to my attention via private correspondance on this thread: when you run 32-bit ESRI products in 64-bit Windows those products do not magically turn into 64-bit code. You don’t get the benefits of 64-bit code with those 32-bit products. Instead, what happens, in effect, is that when your 32-bit application runs it is running within a temporary 32-bit instance of Windows so you have all the limitations of 32-bit applications together with the unreliability of 32-bit Windows. It is more than a little bit misleading when some sales people tell customers that “oh, yeah, ArcGIS Desktop runs in 64-bit Windows” with the implication that it is doing so with the benefits of 64-bit operation that people seek with 64-bit Windows. Not so: the moment you launch that 32-bit application you’ve just lobotomized your modern 64-bit system back into 32-bit operation.
Back to Sam’s comments:
Unless you’ve written your code with an eye to 64-bit operation the re-write from 32-bit code to 64-bit code can be surprisingly time-demanding as it usually involves an almost line-by-line code review. A side effect of that is that many errors, especially errors involved in memory allocation, management, etc., get found and eliminated.
The second effect is that whether you find them or not a large class of errors involving memory tend to have much less impact with 64-bit operation because the amount of memory available for processes is so much greater that the error doesn’t bite. Leaks are a good example of such errors.
This weekend I saw DDR2 RAM advertised for under $80 for 4 GB. At prices so low it becomes completely routine to have at least 4 GB of RAM in your machine and more likely 8 GB. That’s a lot of RAM as rather few people work with data sets more than a few hundred megabytes in size, which, of course, leave a lot of slack available on the way to using up 8 GB of memory.
However, those few hundred megabytes will routinely crunch into the ceiling imposed by 32-bit operations, since given memory used by various Microsoft facilities linked into your code, buffers for UnDo, etc., it’s remarkably common that 32-bit code really only has about 512 MB of working space. With 32-bit applications like ESRI products, if you have a few hundred MB of data there’s not much left between you and a crash if you have any sort of memory leak at all.
In contrast, with 64-bit operation you could have a variety of leaks and never know about it because the process space is so much larger. A problem that doubles or triples the amount of memory your process consumes? No problem – it will still run OK because double or triple a few hundred megabytes and you still have plenty of headroom with 4GB or 8 GB available.
As an analogy for readers who are not programmers, it’s like the difference between setting off across the desert in a car with a very small gas tank that just barely suffices to get you across – any problems with the fuel injection, engine performance or small leaks that cause you to use more gas than thought will strand you. But if you start off with a very large gas tank there are many problems that won’t leave you stranded in the desert because despite those problems you’ll still have enough gas.
There is also a related improvement in that 32-bit code designed to work with tasks that don’t fit into 32-bit process space is naturally far more complex than 64-bit code: you end up going through all sorts of intricate maneuvers to chop up a task into manageable bites [almost wrote "bytes" there but that would have been too painful...
]. All that intricacy introduces more opportunities for errors, especially since you are playing about with memory limitations that are highly artificial compared to the beautifully clean and straightforward addressing regime of 64-bit operation. Going 64-bit removes all that spaghetti code and the errors it tends to introduce.
I don’t mean by this to excuse any unprofessional programming practices – I’m just pointing out that history shows an upgrade to 64-bits results in more reliable code for two reasons:
The code review surfaces many errors previously unnoticed, and
The much larger addressing range of 64-bit code on the one hand allows cleaner code less prone to error and on the other hand allows larger memory that is more forgiving of certain types of errors (but not all!).
By the way, this is all kind of kicking someone when they are down because ESRI is the classic example in GIS of both coding problems: their code is notoriously ad hoc, created as it was in different bits and pieces that have evolved separately over the years, and also notoriously designed in an era when the programmers obviously weren’t writing with 64-bit operation in view.
In contrast, the GIS package that went 64-bit two years ago was able to do so because it was all modern code written relatively recently with 64-bit operation in mind from the very beginning. One advantage to having a GIS operation that includes many people who come from a place like Intel is that you understand Moore’s Law and know architectural improvements, like 64-bit and multicore processors, will be upon you in the blink of an eye, so you write with that in mind.
Another aspect of that is that you don’t write spaghetti code to get around limitations that you know will soon be eliminated when 64-bit architectures arrive.
Two years ago there was a lot of pressure from users on you-know-who (everyone knows the 64-bit GIS system I’m talking about, but I won’t use the name to avoid freaking ESRI folks out…) to do a quick fix to enable faster operation with larger data sets.
The company resisted, saying that it was better to keep investing into fundamentals and that 64-bit operation would be here soon enough and would take care of all that. That turned out to be the right strategy, as 64-bit operation does indeed take care of all that, plus you have the benefit of two years of development not having been spent on a coding dead end of spaghetti code written to get around the limitations of 32-bit Windows that soon no one will be using, but instead invested into leveraging the 64-bit / multicore hardware and Windows systems that have become commonplace today. So instead of wringing our hands all worried about how to de-lobotomize obsolete 32-bit code, we’re able to enjoy 64-bit operation today and to look forward (later this year, late summer or early fall) to massive speed and capacity improvements that will enable multi-hundred gigabyte, if not terabyte, operation with a $250 desktop GIS package.
All that, by the way, is not so much our doing as it is the doing of the processor vendors, the RAM industry, and Microsoft for providing the 64-bit platforms. We just believed in them and planned accordingly.