Jack’s Answers to the 2007 UC Q&A
UPDATE: I have no idea why ESRI doesn’t believe in permalinks so all those links below do nothing special. Sorry.
I’m not going and probably most of you aren’t either so this might be your best bet as to getting an idea what might or might not be said Monday morning.
ESRI International User Conference 2007 Q&A
Some of note:
Q: What are ESRI’s plans for ArcGIS 9.3?
Doesn’t that sound like what 9.2 was supposed to be?
Q: When will ESRI support multiple layouts in an MXD?
I know this is a big deal for many of you, but I’ve learned to live with it)
Q: What is ESRI working on beyond 9.3?
Am I the only one that worries about more integration of everything into the geodatabase?
Q: Can you clarify the difference between ESRI’s viewer technologies ArcGIS Explorer, ArcExplorer, and ArcWeb Explorer? When should I use one over the other?
How about stop naming everything the same? I spend more time explaining to clients the difference between AGX and ArcExplorer than I do showing them its capabilities.
Q: Does ArcGIS 3D Analyst provide support for interchanging SketchUp models?
Now we are talking, import without the need of an additional extension (well beyond 3D Analyst) is huge. That said where is the export to SketchUp?
Q: What are your plans for improving documentation for ArcGIS Server, especially related to developer help?
#1 request of mine. Keep the improvements coming.
Q: Please provide an overview of the ArcGIS Server licensing model.
The only thing more confusing that ArcGIS Explorer/ArcExplorer/ArcWeb Explorer is the ArcGIS Server licensing model. I guess they needed something to go with the ArcObjects model.
Q: What’s coming in ArcGIS Server 9.3?
Anyone who’s tried to implement AGS knows the security model is a mess. The Javascript API is interesting and better WMS/WFS support is great. Where is the improved KML support?
Q: What happened to ArcSDE?
Yea what did happen to ArcSDE?
Q: I have heard Microsoft is developing a spatial type in SQL Server. Will ESRI be supporting this?
I suspect SQL Server and ArcGIS will go together like bees and honey.
Q: What are ESRI’s plans for opening up access to the geodatabase?
Well there you go, more proof that they will go the API route on this.
Q: Will ArcGIS Server support PostgreSQL? Will it provide SQL access to features stored in a geodatabase?
While I think generally, most ESRI users will gravitate to SQL Server, PostgreSQL support is huge.
Q: What is the status of CAD Client?
The most unloved part of the ESRI stack. We need it and use it, but it lags so far behind. I can only hope they’ll at least support Autocad 2007 at 9.2, but I’m not hopeful.
Q: When will ESRI be releasing Service Pack 3?
So July 2007 it is….
Q: When will ESRI publish a list of known software defects?
OK, I’ll be the first to say it, “How long do you think that list will be?” 
Q: To what extent does ESRI support interoperability with KML and Google Earth? Is KML becoming an OGC standard like GML?
I was hoping to see more mention of KML. Seems like ESRI still isn’t going to jump with both two feet into supporting KML. Kinda looks like they are being dragged into it. Too bad for us.
Q: Does ESRI have an interoperability strategy to work with or integrate its tools with Google Earth and Virtual Earth?
Again I have to say it, you’d think by Summer 2007 ESRI with have a more focus strategy than “ESRI is also actively working with both Microsoft and Google to improve interoperability”. We should be seeing integration at 9.3. *shrug*
Q: How is ESRI participating in the Open Source environment?
Interesting answer to that question, I’ll give you that…
Q: What is the status of ESRI’s support for running ArcGIS on 64-bit operating systems?
There we go, the answer we all were looking for.
Q: Does ESRI have a plan to improve ArcGIS Desktop to utilize multiprocessors on a PC?
Again, great answer!
Q: Can you provide better access to ESRI customer records about my organization?
When will ESRI Customer Care be open to Business Partners? It seems like we’ve been waiting for a long time.
Q: What is ESRI doing in ArcGIS to make it easier for users to share geoprocessing models and best practices?
Community building is a wonderful idea.
Q: What is the GeoWeb? How will it be used?
ESRI’s definition of the GeoWeb.
Q: What are some of the results from your survey? What have you discovered?
Interesting to say the least. ESRI users want a little of everything.
Amazing… most of your comments mimic my own. Developer documentation and GE/VE interoperability would both reduce my stress-level by around 95% and give me a lot more leverage.
To this day, I waste most of my support incidents trying to get clarifications of AutomationException’s with that standard, “unspecific error” code of 0×80004005. I’ve been fighting with them to publish a list of COM error codes that’s us Java developers can find… no such luck.
The rest of my time is spent arguing with people about Google Earth licensing.
I plan to corner the Postgres developers and try to pry a little info out of them. ArcSDE..er…um, ArcGIS Server Geodatabase for Postgres is my last, best hope for sanity.
Microsoft is too slow; Oracle is just a sales-pitch for Oracle Pro Services; DB2/Informix is a procurement nightmare where I work.
By too slow, I mean the “Spatial” extension seems like it’ll be “in development” longer than Vista.
Here’s another question:
how do you plan to compete in an environment where enterprise based GIS software running in true 64-bit mode, connecting to Oracle spatial, DB2, and SQLServer, and including built in IMS software can be had for under $500.?
We believe our users will still pony up whatever money they have to buy our product because we have a sales force that can hand out really nice glossy marketing material.
Q: What is the status of ESRI’s support for running ArcGIS on 64-bit operating systems?
There we go, the answer we all were looking for.
I have actually followed the link in the answer and what they are planning to do is to “certify” ArcGIS and others (yes, even ArcGIS Server) to run as 32-bit applications on 64-bit Windows systems.
Are you sure you were looking for that answer, James?
top: Yeah I also read the link and this is hilarious, they obviously are not bothered developing native 64bit software, even though GIS surely is a prime example of a software category which can benefit from the move to 64bit and connected benefits.
Just out of ignorance, a 32bit app running on a 64bit OS on a machine with say 16gb ram, can that app take advantage of the whole 16gb ram ?
I have copied the article below so other people dont have to digg it up:
Question
Does ESRI support 64-bit processors with ArcGIS products?
Answer
ESRI is in the process of certifying the ArcGIS software products in the 64-bit processor environment. This certification is not yet complete and ESRI does not have a completion timeframe to offer at this time. Please check this article again for future updated information.
ESRI is committed to certifying the ArcGIS applications on the Intel or AMD 64-bit processor families; for example, AMD64 and Xeon64, beginning with the ArcGIS 9.2 release.
All ArcGIS platform certification is dependent on any required 3rd party files and are also supported on the platform. For example, if a component such as .NET 1.1 is not supported on a specific platform – none of our technology dependent on that technology can be supported on the platform.
ArcGIS Desktop, ArcInfo, ArcEditor, ArcView, and ArcReader on 64-bit
ArcGIS Desktop is a native 32-bit application and is currently being certified running as a 32-bit application on 64-bit (x64) Microsoft Windows
ArcGIS Server and ArcIMS on 64-bit
ArcGIS Server and ArcIMS are native 32-bit applications. They have both been certified running as a 32-bit application on 64-bit (x64) Microsoft Windows. Web server support is based on the web server vendor’s support of 64-bit Microsoft Windows. Check with your web server vendor if the web server is supported on 64-bit Microsoft Windows.
ArcGIS Engine on 64-bit
ArcGIS Engine is a native 32-bit application and is currently being certified running as a 32-bit application on 64-bit (x64) Microsoft Windows.
ArcSDE on 64-bit
ArcSDE is available as a native 64-Bit application for versions of Sun Solaris (Oracle and DB2), HP HPUX (Oracle and DB2), HP Tru64 (Oracle), and IBM AIX (Oracle and DB2). On Windows, ArcSDE is a native 32-bit application. ArcSDE has been certified running as a 32-bit application on 64-bit (x64) Microsoft Windows. DBMS support is based on the DBMS vendor’s support of 64-bit Microsoft Windows. Check with your DBMS vendor if the DBMS is supported on 64-bit Microsoft Windows.
I like this one:
When will ESRI publish a list of known software defects?
What? Software defects? Are there any?
@top:
I thought my whole post dripped of sarcasm, but I’ll try harder next time.
@ mfd:
You’re last 2 posts have been priceless
James, I too misunderstood your sarcasm. But, all that aside, what do you make of this answer:
Q: Does ESRI have a plan to improve ArcGIS Desktop to utilize multiprocessors on a PC?
Yes, the release following ArcGIS 9.3 will support the multiprocessor hardware environments with threading. This is already supported in the ArcGIS Server environment.
do you think that ESRI will actually rewrite their algorithms to truly take advantage of multiple processors? That is, will polygon overlay actually offload certain computations into different cores?
You seem to have a good understanding between what ESRI says and does, and I was curious if they were going to actually do this.
I’m not sure how they are going about this and not going to the UC I won’t be able to ask.
At the Dev Summit I was told that it will split the workload between the cores, but it wasn’t exactly at “technical” explanation.
We’ll have wait for the beta to see what their implementation will be.
Just out of ignorance, a 32bit app running on a 64bit OS on a machine with say 16gb ram, can that app take advantage of the whole 16gb ram ?
No. Technically, a 32-bit application can try using more than 4 Gb of memory (2 Gb of which is already taken by the OS) via AWE, but this has two serious drawbacks and so noone does this.
First, using AWE means operating with physical rather than logical memory which is one level down in abstraction and can mess things up rather badly if used improperly. Using AWE is more or less equivalent to telling the OS to get out of the way and let your application make its own assumptions on how much memory to give to its own process and to other processes. This can only ever work well for something that takes over the entire machine. Applications, be they GIS applications or not, do not want to take over the entire machine since otherwise they would have to take responsibility for a great deal of tricky things, eg, decide how much memory to leave to disk cache so as not to throw the performance out the window, etc.
Second, using AWE means a significant amount of work for developers, much more work than “just” porting an application to 64-bit. There is a separate API which have to be called explicitly. Requests to allocate more physical memory start failing pretty fast compared to requests to allocate more virtual memory issued by true 64-bit applications. Existing data structures have to be recoded, retested, etc.
In the end, if ESRI can not port their applications to 64-bit Windows platforms, they surely can not use AWE in any meaningful way.
I thought my whole post dripped of sarcasm, but I’ll try harder next time.
I’ll try harder to read the tone next time, too.
top: ESRI announced that they’ll have 64-bit executables at 10.0+
Thus there are no plans for porting 9.x code to 64-bit. I had no idea my little ESRI 64bit comment would generate so much discussion.
http://www.spatiallyadjusted.com/2007/03/20/esri-developer-summit-2007-day-1/
Expanding on the now-understood sarcasm, here is another item:
What are ESRI’s plans for opening up access to the geodatabase?
ESRI will provide full and open access to the geodatabase using the following methods:
A free and open API to the file geodatabase. * The file geodatabase was introduced at ArcGIS 9.2. While ESRI would ideally like to open the file geodatabase format in a manner similar to what we did for shapefiles when we released ArcView 2, geodatabases are complex and can be easily corrupted outside the ArcGIS environment. Instead, we plan to engineer a high performing and well documented API that developers can freely embed in custom applications and that will read and write file geodatabase datasets. This will be released after ArcGIS 9.3.
This begs the question:
Why design a geodatabase so that it can be easily corrupted outside the ArcGIS environment?
This truly is beyond me.
This is the nature of databases. Would you attempt to directly edit Oracle files from outside of the Oracle API’s? Would you attempt to directly write to Postgres database files?
You could, but it’s very easy to corrupt those databases as well.
Cellulose:
The analogy is not entirely correct, as a geodatabase is a MBD database, and most programs attempting to read/write from a pgd to my belief use a database connection to the MBD, and thus use a “official” indirect way.
The problem stems more from the fact that ESRI never officialy specified the technical spec for a PGD, in enough detail for external providers to be able to develop interfaces that can read/write from a Personal Geodatabase in a efficient way, instead having to rely on reverse engineering to guess what the right structure is.
Even though a API is a good start, why not directly provide the detailed technical specification of the ESRI PGD.
PS: I might be talking completely out of my ass here, so dont take my wisdom too seriously
while I agree with Cellulose about corruption, it still seems like a red herring. I wonder if we’ll be able to redistribute the api libraries for free (and how many dlls that will entail)
cheers
brian
@pez, we are talking about file geodatabases here, so MS Access is irrelevant.
To clear some things up, “geodatabase” in ESRI terms refers to 3 “products”.
Of course this confusion is mostly ESRI’s fault for letting the term be used loosely, but just to keep track, in this instance (the Q&A), the API is for File Geodatabases.
Oh good to know, some stuff happened since I left the warm cuddly world of ESRI software
Hmm am a bit confused, so this file geodatabase is a dumb collection of files in a directory? is this managed than in some way by ArcGIS ? arent these than not sinply shape files ?
This is the nature of databases. Would you attempt to directly edit Oracle files from outside of the Oracle API’s? Would you attempt to directly write to Postgres database files?
No, this is not the nature of databases, and your analogy is incorrect.
There already is an API to geodatabases and this API is SQL. The “corruption” that ESRI is so afraid of is the ability for whoever is connected to a geodatabase to change one piece of data without making synchronizing changes to other pieces. Well, guess what, maintaining the integrity of databases has been bread and butter of database design for the last 30 years or so. There are many things you can do here, from normalizing your data structures so that they can not ever get desynced no matter what, to using triggers and stored procs. If the design of geodatabases is such that it allows pieces of data to get desynced (and the design of geodatabases in fact makes it hard not to do that), then this design is bad.
Which brings us to my point: why release something with a design which is obviously, terribly broken, yet alone call that a “database”?
Yes, the files are managed by ArcGIS in the same way that any other database manages its data.
A file-geodatabase is implemented in a similar way to other databases (Oracle, MS SQL, Postgres, Derby, Berkley DB, etc). It’s a collection of *managed* files in a directory–which should only be accessed through proper API’s or servers.
The API/server manages file locking, transactions, consistency, indices, etc (i.e. ACID and other DB type features). Specifications to do this could be published, but very minor bugs could easily cause severe problems. That’s why you don’t see other DB developers “encouraging” you to directly manipulate their data files.
@Petz:
The file geodatabase is ESRI’s proprietary database. It isn’t “dumb” in the classic sense, but without ArcGIS it might as well be wasted space. The API is supposed to open it up to more users, but that remains to be seen. Right now, if you don’t have ArcGIS 9.2, you can’t access it (9.1 can’t see them).
The reason for the file geodatabase existing is that personal geodatabases have limitations to them that limit there use in 2007. I’m pretty sure if ESRI had a time machine, we’d never have seen the personal geodatabase.
Top–I see your point and I agree the schema of an ArcSDE geodatabase have severe fundamental problems. I disagree that a full-proof schema is possible with any RDBMS, but I do agree ESRI could do a whole lot more to get *much* closer to a tamper-resistant schema.
I think the File-GDB API is intended to address a different use-case. I’m unaware of an SQL interface to the File-GDB (if there is, point me at the docs because I would like to use it!).
Even if there were an SQL interface, ESRI would then need to port the SQL and database engine to various platforms and distribute them to developers. I think this still leaves them in the same place–needing to distribute some kind of library to users (DLL’s, libs, etc).
@ Petz File GDBs are not a directory of shapefiles. File GDBs can contain topologies, geometric networks, terrains, etc and were introduced in 9.2.
An overly simplistic view of file GDBs is that they are a cross platform indexed feature repository with no 2GB file limit (a per file limit of 1 TB I recall). If you want to think of file GDBs as big shapefiles, then realize that they also duplicate all of DBase as well.
File GDBs are more than just a binary shape format. If someone wanted to roll their own file GDB code they would need to reproduce everything you get in shapefiles, everything you get in DBase, topology support, terrain support, raster support, network support etc, etc, etc as well as QAQC for this while stress testing it up to multiple terrabytes. There is alot of wheel to reinvent.
@James
Yes personal geodatabases have size and performance limitations. Also they are windows only. Access however is great for making charts.
Oh, and I see your point now. It did not occur to me that the API planned by ESRI might be different from SQL.
If the API will not be SQL, then, of course, it could disallow corruption while preserving the existing design of geodatabases. However, I seriously doubt that it will be as expressive and scalable as SQL (yes, SQL is not good for everything but it is good for lots and lots of things), not to mention that developers who would want to use it would have to adopt to one more API instead of using the techniques that has been already proven to work.
But, I stand corrected, a non-SQL API to what is being referred to as a “database” is better than no API at all, and if ESRI delivers it, it will be a good thing.
fGDBs are really fast!
I’m looking forward to an API – sure an SQL API would be great! – so that fGDB can be opened up to non ArcGIS Users.
In the meantime you can use FME to get data in and out of your fGDB
I don’t know very much about the actual ‘guts’ of a File Geodatabase (FGDB). I don’t believe you can access it via SQL and therefore I’m not sure it’s actually a database at all. I’m sure the data is structured which technically would make it a database, but I don’t think it has the functionality that most users would expect. Here is a good link describing the different Geodatabase formats. From the way it’s described it seems pretty clear they want the FGDB it become the new ’shape file’. This isn’t a ’spatial’ sqlite. It’s simply another spatial format and a complicated one at that. Hence the need for a API. I’ll second Brian Floods concern though. If this isn’t a freely distributable API then this is a total non-starter.
A little detail about the FGDB.
Top–
If the API turns out anything like the ArcObjects API for geodatabases (all types), it definately will be *less* flexible and scalable than SQL.
I’ve been battling with MS SQL Server and trying to express complex spatial queries through the ArcObjects API… It’s simply not possible. My account rep has got me scheduled with some AO/SDE developers to give me some more ideas, but I suspect the answer will be “switch to one of the other SDE databases”.
Cam–SQL is *not* an essential part of a DB. It’s just a commonly accepted way to access relational databases. Keep in mind that SQL is standardized across databases… It’s treated as more of a guideline than a standard.
@Cam
Just to annoy James, here is a wikipedia link discussing Databases:
http://en.wikipedia.org/wiki/Database
“In computing, a database can be defined as a structured collection of records or data that is stored in a computer so that a program can consult it to answer queries.”
So file GDB is a database. (Excel probably is too).
And to prove a point about wikipedia, here is a link with more than twice the text of the database article discussing the weighty topic of Daleks:
http://en.wikipedia.org/wiki/Dalek
In fairness to wikipedia the Dalek article has some good pictures.
@Doug & Cellulose: I totally agree any structured data could be considered a database. My point is if your going to call it a ‘database’ then I have some expectations. I figure most GIS users would have the same expectations (like being able to use SQL). We’re not working with some format here that is 15 years old. SQL isn’t essential, but honestly what recent database doesn’t use it?
@Cam W.: I would say most databases don’t use SQL. Right now I’m using Apple’s Aperture to edit some photos. The “library” that stores the photos is just a database. How many other programs do you use every day that store data in some sort of format? I’d guess most of them and I doubt you are using SQL to access them.
James: Okay, the library in Aperture doesnt expose a SQL interface to you the end user, but I wouldnt be surprised if internally, the program front end communicates via SQL queries with the library backend, translating your graphical clicks into actions.
Same is probably true for a lot of software systems, I would imagine. That doesnt mean that SQL is the wrong method of interacting with data though.
In the GIS world specifically, a lot of users would wish for some direct way to manipulate data, and not only point and click.
Going back to beloved Manifold, they do expose all of the data (and a lot of functionality) inside the GIS through a SQL interface, and anyone who has spent the time mastering that interface can tell how much power over the data that has given them, without the need for a full-blown API.
So my point is I guess, ideally there should be a multitude of interfaces allowing one to access data hold in such databases, be it GUI, SQL, API, but all of them need to manage user actions and make shure that things dont get broken easily.
I didn’t say SQL wasn’t needed, in fact I totally agree you.
SQL just isn’t a requirement for a database and I would say 90% of databases out there don’t use SQL at all.
James’ poor example choice notwithstanding (aperture uses SQLite) I agree with is point. My wife stores all her internet passwords in a database.
Her choice? A table in MS Word.
That doesn’t make it any less of a database than it would have if she used Oracle.
Everyone appears to agree that SQL is the best way to access databases, but that doesn’t mean that without it, you don’t have a database.
Everyone appears to agree that SQL is the best way to access databases, but that doesn’t mean that without it, you don’t have a database.
This is a bit like saying that running in 32-bit mode on 64-bit systems means having “64-bit support”.
Both statements are technically correct, but, well…
Allan, thanks for clearing up Aperture. I probably should have used a Windows application example as Apple seems to use SQLite for everything these days.
top, I know you were trying to be funny, but that is a horrible analogy.
Most of the non-SQL databases I’ve seen and used tend to be embedded databases. While it’s a reasonable interface to a some types of databases, it’s become an expectation even when it’s not needed.
It is by no means a “subset” of a full-API, as it requires a feature-rich API to implement SQL correctly. SQL adds a huge overhead in terms of parsers, code-bloat, and bugginess that we don’t need sometimes (though in the context of GIS, it’s a reasonable thing to expect and demand).
BerkleyDB is a commonly used database with no SQL front-end… It only has programming API’s (C, Python, etc). It’s used as the back-end on many applications, everything from Subversion to OpenLDAP to MySQL (one of many options for MySQL!).
NetCDF an HDF are also used/operated like databases… Those formats are used by many of the world’s large-scale physics simulations and supercomputers. No SQL there either.
Both Windows and Linux have several apps backed by a database without SQL interfaces. Everything from the registry to thumbnail caches to LDAP to Yellow Pages.
I know you were trying to be funny, but that is a horrible analogy
Um, why?
I agree that a table in a Word document might be considered to be a database if the term “database” was to be applied broadly (significantly more broadly than is allowed by the Wikipedia definition that has been cited earlier – not by me). The point was that computer-savvy people like those of us who work in the GIS field do not call something a database if it does not behave like one.
My wife also has a Word document where she keeps her cooking recipes and she also calls it a database. I call this a Word document.
On the other hand, I have my own definition of the word “clean,” which my wife vehemently disagrees with.
So, if you want to call something with tables, columns and records, but with an API that does not resemble that of other databases, a “database,” I am fine with that.
Perhaps wives’s databases follow a different logic that ours
It would not be the first difference between m&w ….
I’ll try to convince mine to store cooking recipes in a File geodatabase ….
I’ll keep you informed
When will ESRI publish a list of known software defects?
ESRI will publish a full list of software bugs in all of it’s software products in August 2007. Due to the size of the list it can only be viewed on 64-bit machines.
While I see why James’ analogy with Aperture isn’t perfect it still makes a point. If it was called ‘Aperture Photo Database’ would you’re expectations be different? Many applications use a ‘database’ to manage all sorts of things and don’t expose any SQL. My point is ESRI is promoting this file format as a database. I’m not aware of any new format (in the last 5 years or so) that was advertised as a database and was not accesable via SQL. Don’t get me wrong I really like what I’ve seen of FGDB, but I think it’s misleading to call it a database.
I’d like to see some examples of “new formats” created in the last 5 years that are advertised as a database that include SQL.
If you take a look at developer soutions and B2B products, you’ll find non-SQL databases all over the place–and marketed as such.
Some examples:
My favorite so far is Xindice, an “XML Database” accessible only by XPath. Very useful, very novel, and very un-SQL.
RDF Triple Stores are frequently marketed as a “database”, but are accessible through non-SQL languages like SPARQL or Versa. The entire “semantic web” is based on this non-SQL “database”.
There are at least half a dozen implementations of RDF’s that don’t have SQL interfaces. I believe all of them market themselves as a database.
Again, I give you HDF (about 7 years old) and there’s not a lick of SQL there either.
These are just the ones I’ve worked with personally…
When it comes to systems design and implementation……ESRI gets a D. If they hadn’t announced multiprocessor support in 9.3 I’d give them an F.
As someone else mentioned I seriously doubt they will re write their algorithms to offload to multiple cores. At best they will support basic threading that allows to offload OS tasks to a different thread or core.
The 64-bit answer is embarassing. Somewhere I think Jack is mumbling “No one will ever need more than 640K!”
Oh the advantage of having a private company….you dont have to answer to anyone!
The fundamental problem with all modern software is that it’s still run on transister computers…
I long for those days of vacuum tubes, slide rules and carbon paper…
@ Cellulose:
I should stop posting so damn late at night. As soon as I thought about it a little longer I realized that someone was going to point to the “semantic web” as an example.
Xindice is good example, but I would argue it’s been a around for longer that 5 years (but really I pulled that number out of the air). I don’t recall in my very limited experience with HDF it being referred to as a database. Heck I didn’t even realize it was queryable. I’m nitpicking here though. Point taken. There are lots of examples. I just have my own opinions of what a database should entail
Q: Why is ESRI pushing ArcGIS Server so aggressively?
Let me add some perspective on this. A small client, with limited resources, is entering the geospatial world with two 7 Mb pgdb files (yes, 14 M-M-Megs). A handful of people sitting in the same office will occasionally need to view these files along with local base layers. There is one newly hired GIS Tech. They have no intention of putting anything on the internet.
ESRI’s recommended software solution was ArcGIS Server Workgroup/Standard and concurrent licenses of ArcEditor and ArcView. My client was bamboozled into the purchase before I knew about it. I hit the roof because they are still in the paper/digital conversion phase.
That is aggressive marketing!
[...] it’s been made public and comments are flying in(http://www.spatiallyadjusted.com/2007/06/11/jacks-answers-to-the-2007-uc-qa/), talking about the preconference questions that have been [...]
Hi, can any one help me out where should i get the examples on accessing image server using c#