James Fee GIS Blog

95 responses so far ↓

• 1 J Wallis // Nov 1, 2007 at 8:24 am

  What do you mean “ESRI refuses to support KML out of the box”? Doing a simple search on KML in ArcGIS Desktop help reveals a lot of discussion on how ESRI supports KML.

• 2 Simon Jackson // Nov 1, 2007 at 9:01 am

  in 9.2 ArcInfo I can add KML data straight into a data frame

• 3 James Fee // Nov 1, 2007 at 9:24 am

  ESRI does not support KML or KMZ out of the box. Show me where I can drop a KML or KMZ right into ArcMap or view it with ArcCatalog.

  It cannot.

• 4 Cellulose // Nov 1, 2007 at 9:35 am

  I’m not sure what you mean by “support GML” since it’s a 500 page behemoth with many 1000’s of pages add-on/optional specs… it’s much like saying “support XML”, what does it mean?

  Out of the box, 9.2 lets you import GML and WFS data using the “free” version of the Data Interoperability Extension. You can also export a layer to GML using the Simple Profile.

  If you’re worried about GML, I’m not sure why KML is relevant to the mix? Isn’t the point of GML to get away from those evil “proprietary” formats like KML and Shapefiles (even though the specs are published and well-known)?

• 5 James Fee // Nov 1, 2007 at 9:42 am

  You are right, you can import simple GML, but support is still substandard.

  As for the “why I’m worried” about excellent GML/KML support, that has to do with the specs of the scope of work. It doesn’t matter that you can import KML into ArcGlobe or simple GML. It matters that in 2007 ArcGIS is substandard on two data formats that should have been supported years ago. I mean cartographic representations are nice, but how can KML not be dropped into ArcMap at this point?

  Amazing!

• 6 Cellulose // Nov 1, 2007 at 9:45 am

  Ooops. beat me to it so I changed this post (i.e. only Globe can handle KML).

  You’re right–the KML support is less than desirable and could be far better than it is. And if the demand is driven by user requirements, then logic has nothing to do with it.

  I’m still not clear on what you’re looking for in the GML area? Supporting full GML 3 is not possible as it’s like supporting XML–there’s an infinite number of ways to express your data and no single, generic reader will do it right.

• 7 James Fee // Nov 1, 2007 at 9:46 am

  Right, which is a problem.

  Am I the only one flabbergasted that we still don’t have KML support in ArcGIS?

• 8 Cellulose // Nov 1, 2007 at 9:50 am

  Weird–I rewrote that comment (since I didn’t see your #4 post until AFTER I posted) and its not showing the changes. Argh.

• 9 James Fee // Nov 1, 2007 at 9:56 am

  I’ve got a GML that the client wants to be able to view.

  I mean I understand your point about GML, but if OGC products can create GML that ArcGIS cannot read, how can ArcGIS be OGC complaint?

• 10 Cellulose // Nov 1, 2007 at 10:05 am

  Aiee! I’m in comment heck! (now the changes show up)

  I have long considered the lack of KML support to be a case of sour-apples from ESRI. No matter how they viewed the Google/Keyhole product, they knew that KML had become/was becoming a defacto standard.

  Bitterness is unattractive no matter who it comes from. And all it’s done is made our lives harder.

  In regards to GML–aside from WFS/WMS, I’m still not sold on the concept. This may have to do with the fact that I’ve read the standard cover-to-cover several times now and am no closer to understanding how it’s supposed to make my life easier (am I the only person who doesn’t get ‘it’?)… but everytime I’ve used the GML3 standard to deal with anything except WFS/WMS, I’ve had to use/write custom, task specific interpreters that had intimate knowledge of the xml schema/tag hierarchy… So now I can re-use my polygon-parser class, but that’s a tiny piece of my problems.

  Coming up with an XML-ish way to describe spatial constructs was a cute idea, but I still have to embed those GML tags into my own, proprietary XML document that uses my own convoluted sense of “logic”… or, as the case is, forces me to understand and search someone else’s hideous XML documents to uncover a few nuggets of spatial data.

  Thanks, but no thanks. I’m ready to just go back to CSV’s… oh, wait… ArcGIS doesn’t handle those out of the box either.

• 11 Chris C. // Nov 1, 2007 at 10:28 am

  Not just you Cellulose:

  ‘Import Drawing - GML

  GML is an abbreviation for “Geography Markup Language.” A spectacularly inefficient format, GML is based on XML and is being touted as a proposed standard in some circles. Unfortunately, GML is something of a non-standard since every implementation of GML to date for saving GIS data has been incompatible with other implementations. Besides the intrinsic incompatibility designed into GML, the main problem with GML is the extreme inefficiency of the format: GML will frequently require files that are over 100 megabytes in size to store GIS data that other formats can save in only five megabytes.’

  I’ll let you guess which GIS program’s Help file that comes from

• 12 J Wallis // Nov 1, 2007 at 10:29 am

  Am I the only one who doesn’t WANT KML support? I unfortunately don’t live in the free for all happy GIS for everybody world that some of you live in. I need data structures that are SECURE and KML doesn’t come close to that. KML is a liability where I work and usage of the format is banned (along with shapefiles). KML is just the 21st century Shapefile. It is a simpleton little format that I hope no one ever tries to use for GIS analysis.

  Viewing, sure….but ArcGIS pops out KML from layer files “right out of the box”. So you can do all of your analysis using robust data structures and then water them down to KML for viewing.

  I refuse to adopt any “open” data structure for the sake of “openness” that lacks so many basic functionalities that enterprises who make a living off of their data come to expect. I think ESRI sees it the same way and will support GML/KML when they mature into an format good enough to play with the big boys.

• 13 kj // Nov 1, 2007 at 10:44 am

  Me persoanlly, I just want it to support more formats, especailly open ones, out of the box with out making me purchase data interoperability extension. You know, like Manifold already does today. So for example, I want to do something very simple in an ArcGIS app, like map a table from a SQL server database that has a field that contains geometry for points, lines, or polygons as WKT. You can do it in manifold out of the box. You can do it in ArcGIS but you have to program your own custom layer - yuk!! What’s up with that? It should be built in like mapping an XY event table thankfully is, and yet it is not.

• 14 J Wallis // Nov 1, 2007 at 10:50 am

  OMG, I knew someone would say this.

  From the ESRI help:

  ArcGIS supports this GML simple features profile out-of-the-box for all users.

  that said -all users- You don’t need a Data Interop license to read GML out of the box. It uses Data Interop, but you are getting GML support FOR FREE.

  Furthermore, to be thorough:

  “ArcGIS also provides an optional suite of data conversion tools as part of the Data Interoperability Extension so that users can add custom GML formats that support any particular GML profile. Using the Data Interoperability Extension, users can work with a series of GML profiles.”

  So for the complex GML stuff you DO need an Interop license.

  Please please PLEASE people, RTFH before jumping on the ESRI bashwagon.

• 15 Cellulose // Nov 1, 2007 at 10:54 am

  @J Wallis

  What format do you use then?

  What do you mean by secure? Data integrity? Encrypted storage? Signing? Chain-of-custody? ACL?

  I haven’t found any format that deals with those security mechanisms very well–if at all.

• 16 simon jackson // Nov 1, 2007 at 10:55 am

  im pretty sure this is not related to any extension ive installed, in arcmap 9.2 I can opne kml/kmz straight from the add data button
  http://i7.photobucket.com/albums/y254/jak-c/Clipboard01.jpg

• 17 J Wallis // Nov 1, 2007 at 11:00 am

  @Cellulose

  Enterprise Geodatabases or Oracle Locator for enterprise datasets. If it can’t support row level ACL’d security then we don’t touch it.

• 18 Cellulose // Nov 1, 2007 at 11:01 am

  @Chris C.

  That help-entry alone might be enough to get me to use that other product. I’ve finally found a kindred spirit.

  I’ve spent years trying to convince people to use the various binary-XML formats that have come along to try and reduce XML-induced overhead… but then I guess I like those lost causes.

  On the plus side, GML can be compressed really well–down to just 2x the size of other formats.

• 19 James Fee // Nov 1, 2007 at 11:01 am

  @J Wallis: I’ve RTFM many times and it still says the same thing. Full KML and GML support is not “out of the box” as I’ve posted again and again.

  I’m sick of having to find expensive solutions to problems that clients have.

• 20 Lefty // Nov 1, 2007 at 11:03 am

  @simon jackson

  I’m not seeing that on my ArcInfo 9.2.

• 21 simon jackson // Nov 1, 2007 at 11:08 am

  weird.
  ive got it on my other computer with 9.2 arcview.
  Ive installed a script which exports to kml but it would not affect this. Ill try and determine how ive got it and others havnt. Works a treat (as long as everything else is in wgs1984).

• 22 J Wallis // Nov 1, 2007 at 11:11 am

  @James Fee

  If your clients are hell bent on using KML/GML they need to have their heads checked.

  Standards are generally draconian and slow to change. OGC and google rip out a new “standard” of their formats every 6 months it seems. How can companies (or software vendors for that matter) afford to keep up with that?

  The baseline for data interchange is the GML simple features profile. ESRI supports it at 3.1.1. ESRI supports KML at the 2.0 release. If that isn’t “complex” or “full” enough then I guess you should continue to get mad at ESRI, but I think they have better things to do than support unstable data structures.

  If there is one company that knows something about data interchange formats, it is ESRI. How many software packages can you think of that work with shapefiles? It is de facto. Crappy format, but de facto.

• 23 Cellulose // Nov 1, 2007 at 11:12 am

  @J Wallis,

  Ok–I think I understand your point and agree with the principle. KML/GML/Shapefiles/etc don’t come with the infrastructure necessary to provide enterprise-level ACL.

  If you want it with KML, you have to implement it yourself (i.e. custom web apps to generate custom KML’s, etc). And even then, it’s a kludge.

  Though, I still think RDMS solutions still have a long ways to go before I would call them “secure.” How about giving me ENCRYPTION over the network by DEFAULT, instead of forcing me to muck with the “Advanced Security” tool or whatever Oracle calls it this release. How about giving me some control or integrity of the data once it’s been sent to the client?

• 24 J Wallis // Nov 1, 2007 at 11:24 am

  adopting encryption at the database level is crap anyways. It needs to be done at the SAN/NAS level, handled by a dedicated controller on the network. That gives you a uniform encryption plan for all data, not just your RDBMS.

• 25 James Fee // Nov 1, 2007 at 11:27 am

  @J Wallis: ESRI doesn’t support KML 2.0 out of the box so that argument is bull. Buying an extension to read KML is a major PITA for interoperability.

  As for the clients need for GML/KML support, they have good reasons for needing it. What it will come to in the end is their need for GML/KML support will trump the need for ArcGIS and in the end that will be a huge loss for ESRI.

• 26 J Wallis // Nov 1, 2007 at 11:34 am

  http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?id=2939&pid=2932&topicname=KML_in_ArcGIS

  That isn’t KML support out of the box? I give up.

• 27 Lefty // Nov 1, 2007 at 11:34 am

  J Wallis:
  

  If your clients are hell bent on using KML/GML they need to have their heads checked.

  Standards are generally draconian and slow to change. OGC and google rip out a new “standard” of their formats every 6 months it seems. How can companies (or software vendors for that matter) afford to keep up with that?

  KML? The standard doesn’t “change” every 6 months, but even if it did ESRI doesn’t support it by default. They have their head in the sand here.

  The industry is moving forward and ArcGIS is like a big anchor keeping folks tied down. By the time they free themselves, they’ll be irrelevant.

• 28 James Fee // Nov 1, 2007 at 11:40 am

  @J Wallis

  ArcGlobe isn’t free. At least not in my neck of the woods.

• 29 Cellulose // Nov 1, 2007 at 11:45 am

  @J Wallis

  I think we’re talking about two different things.

  SAN/NAS encryption (i.e. encryption of the physical database files), while a very important problem, really has nothing to do with the client/server security problem I’m worried about.

  It also doesn’t impact data integrity at the application level. The data may be encrypted on disk via my NAS/SANS, but it doesn’t guarantee that someone with access to the server (i.e. after the encryption/decryption phase) hasn’t tampered with my data…

  And it sure as hell doesn’t give me any capabilities to discourage my users from abusing the data once it reaches their client machine.

• 30 Cellulose // Nov 1, 2007 at 11:49 am

  @James, J Wallias

  And getting it into ArcGlobe doesn’t mean you can get it into ArcMap or ArcCatalog.

• 31 J Wallis // Nov 1, 2007 at 11:49 am

  last time I checked, no ArcGIS product was free. Are you bemoaning cost or functionality? The functionality is there, but yes, in order to make money sometimes you have to spend money.

  I can’t tell you how many times I have worked with companies that wanted to “rage against the machine” and not simply adopt an existing solution. 9 times out of 10 they ended up spending more money than if they would have simply bought the (usually ESRI) product. But hey, as I used to say (and still refer back to) “Consultants: If you aren’t part of the solution there is good money to be made prolonging the problem”

  And Lefty, if you call data formats tied to a single geodetic reference “moving forward” then I would hate to see what your example of moving backwards is.

• 32 kj // Nov 1, 2007 at 11:53 am

  J Wallis - yeah I need it in ArcGIS Engine Runtime though - not desktop (back on connecting to a layer that is a table in a SQL Server containing WKT w/o having to write a custom layer). If you could point me at some help for doing that I would be grateful. Hopefully saying that won’t make your head explode in rage.

• 33 J Wallis // Nov 1, 2007 at 11:55 am

  @Cellulose

  there is no encryption solution that can solve data abuse once it reaches the authenticated client’s desk. A bad person is a bad person, and you can’t simply reboot them and make them start working ethically. You can’t solve basic HR problems with technology. If you have an errant user, you establish consequences for not following policy.

• 34 James Fee // Nov 1, 2007 at 11:57 am

  There are very good reasons to buy 3D Analyst. To read KML into ArcGlobe is very low on that list. But that doesn’t change my original statement that said you can’t read KML in ArcGIS out of the box.

  As for spending money on an “ESRI solution”, that isn’t possible as the way the Data Interop extension handles KML/GML renders it useless. It has nothing to do with my comments on the scope of work on my desk. I’m guessing that it will be a server side ogr2ogr solution, but that is yet another step without ESRI.

• 35 J Wallis // Nov 1, 2007 at 12:09 pm

  ok, it is time to split some hairs here and get the terminology/product names right.

  You can’t load a KML file into ArcMap, which is part of ArcGIS Desktop. You can load a KML into ArcGlobe, which is also part of ArcGIS Desktop.

  The statement “ArcGIS doesn’t support KML/GML out of the box” is incorrect since ArcGIS is a suite of applications and of which certain applications of that suite do accept KML as a client format.

  Furthermore, the statement “ESRI refuses to support KML” is wrong on face value but subject to interpretation if you want to view that statement as an opinion. They may seemingly refuse to support it at the level you want (KML 2.1 2.2, or whatever flavor Google is pushing these days), but that still doesn’t omit the fact that ESRI supports -a- version of the KML standard.

• 36 Kipter Uh // Nov 1, 2007 at 12:33 pm

  We are in the weeds here, but I think James’ wording is correct. Buying add ons to a product does not mean it supports KML out of the box. I think if he said ArcGIS didn’t support KML and left it that way, you’d be correct. But he did add that “out of the box” to the end.

• 37 Steve Larch // Nov 1, 2007 at 12:50 pm

  When I saw the comment count I thought you’d been hit by a spambot. lol

  I can’t comment intelligently upon KML support because I’m a newb and haven’t fooled with it. With sharks like Google and Microsoft swimming in the water though the last thing you want is to appear overpriced and unresponsive to customer needs.

• 38 J Wallis // Nov 1, 2007 at 1:07 pm

  ESRI is responsive to customer needs. That’s why KMl 2.0 IS supported “out of the box” by the ArcGIS suite. So it isn’t supported in the ArcMap 2D application “out of the box”. boo hoo. Google doesn’t have a 2D desktop product to support it with either. But both companies support it in a globe viewer product. And both companies support it in web applications.

  Microsoft is going to buy ESRI one of these days anyhow when Jack decides to retire, so ESRI doesn’t have to worry -too- much about being unresponsive. They just need to be responsive to the right people.

• 39 Steve Citron-Pousty // Nov 1, 2007 at 1:08 pm

  And here I thought there were 37 comments congratulating me on the new devZone…

• 40 Cellulose // Nov 1, 2007 at 1:17 pm

  @J Wallis

  Technology can provide some vague level of control that can prevent casual abuse (i.e. unintentional or novice level abuse). Adobe Acrobat, Sharepoint, and other technologies provide such mechanisms. They are not perfect, but they do help to enforce policy and discourage casual abuse.

  Perhaps my point has been obfuscated. Database-based GIS formats may fix one security problem (ACL), but they still leave so many other problems that calling “secure” is misleading at best.

• 41 Are you kidding me? // Nov 1, 2007 at 1:51 pm

  “ESRI is responsive to customer needs. “

  Only if you spend a lot of money. ESRI has proven year in and year out, those with money to spend get the features, no matter how unimportant they are to the community at large.

  KML import/export support from ArcMap is key to the future. I’m not saying it has to be as complex as A2E, but dammit we deserve to be treated better than we have.

• 42 Erin // Nov 1, 2007 at 1:56 pm

  I’m sorry J Wallis, but boo hoo? That is the kind of reaction that has gotten all these new programmers out there doing Web GIS using open source and other solutions and not ESRI products.

  Boo hoo is what I’ll be saying in 5 years when ESRI is bought by Pitney Bowes.

• 43 George B // Nov 1, 2007 at 3:26 pm

  “I’m sick of having to find expensive solutions to problems that clients have.”

  Why don’t you try Manifold?

• 44 mfd // Nov 1, 2007 at 5:01 pm

  yeah, I don’t understand what the problem is. A $100 runtime version of Manifold and about 6 lines of VBScript, and you are done.

  Hell, I’ll write it for you:

  DrawingName = InputBox(”Enter Drawing Name”)
  Set theDrawing = Document.ComponentSet(DrawingName)
  Set KMLExp = Application.NewExport(”KML”)
  KMLExp.Export(theDrawing,”c:\temp\”&DrawingName&”.kml”,false)

  There, you are done!

• 45 James Fee // Nov 1, 2007 at 6:45 pm

  I don’t need Manifold to do that. I can do it already for free.

• 46 Mike Sumner // Nov 1, 2007 at 7:28 pm

  I thought we were talking about your clients?

• 47 J Wallis // Nov 1, 2007 at 7:43 pm

  @Erin

  “I’m sorry J Wallis, but boo hoo? That is the kind of reaction that has gotten all these new programmers out there doing Web GIS using open source and other solutions and not ESRI products.”

  And there enlies the problem. I’ve had many a programmer come running to me, “ohh ohh, look what I can do with KML and GE!” Then I ask them to provide me the data in something other than WGS1984 and serve up features only to appropriate authenticated users. Usually all I ever get is blank stares. Sometimes I get the “well why would you want to do that?”

  Hence my point of the overblown need for KML interchange. The thought of enterprises using KML as their corporate data format scares me…but if I were their competitor it would absolutely delight me.

  And on another thought, who is actually doing GIS analysis with KML/GML? I mean the hard core type of analysis we’ve come to expect with ArcGIS, not some simple buffering or clipping. I’d love to see some robust examples.

• 48 James Fee // Nov 1, 2007 at 8:12 pm

  @Mike Summer: We are and they want to use ArcGIS Desktop with the KML/GML generated.

  I can use ogr2org to convert to shapefiles, but that adds a step. Manifold adds nothing to this problem irrespective of the fact that it can handle the conversion.

  @J Wallis: The issue is that the GIS Analysts want to get the KML into ArcGIS so they CAN do analysis. That is why KML import is important.

• 49 Dylan Beaudette // Nov 1, 2007 at 9:59 pm

  @J Wallis:

  With respect to secure access to data: that is what SSH was developed for. Why windows does not come with this (free) service is beyond me. Try using a real operating system some time.

  As for KML and GIS analysis. No one is pushing analysis within the context of KML or GE. Furthermore no one is pushing standardizing around GCS/WGS84.

  A similar example can be made of shapefiles. Take a look at vector data which has been created in the last 5-7 years, and you will find a pile of topologically incorrect spaghetti. How about all of the fun associated with storing attributes in DBF files?

  James is asking for basic functionality which open source software can provide- and the (how much is that ArcInfo license these days?) “leading” GIS app can’t. What is the big deal?

• 50 Christopher Schmidt // Nov 2, 2007 at 4:43 am

  J Wallis:

  I’ve never touched an ESRI product, and all my analysis experience is in http://crschmidt.net/mapping/wpserverdemo/ , which apparently (despite doing a number of things that ESRI software doesn’t let you do without paying extra for more licenses) isn’t enough.

  (The list, for the record is:
  dissolve, union, difference, intersection, symmetric difference, line simplification, convex hull, centroid, and buffering.)

  So, what *is* ‘real’ analysis?

• 51 J Wallis // Nov 2, 2007 at 5:04 am

  @Dylan
  SSH is not going to secure FCs down to the feature (row) level. And the infrastructure that you would have to reinvent to do something close would be ridiculously expensive when you could just use existing technologies. Securing GIS data is not an all or nothing scenario….unless you feel like splicing your datasets into subsets based on user.

  And my point was not on WGS1984 standardization, it was that KML is stuck in one geodetic reference.

• 52 wed // Nov 2, 2007 at 5:10 am

  I think it’s fine that J Wallis is happy with his ESRI stack and has no interest in KML/GML support.

  What mystifies me is why he feels the need to vehemently oppose the addition of better support for those formats into the products. Just because the capability is available doesn’t mean you have to use it.

  I do a lot of work where data security is an issue and I probably wouldn’t choose KML or GML in that case. But I also wouldn’t choose shapefiles, SDTS, DXF or a host of other formats that are already supported.

  James wants KML and J Wallis doesn’t. Unless they’re sitting side-by-side in the same shop, I don’t see the problem.

  And, for the record, I agree that better support for KML/KMZ/GML is long overdue and would love to see it added to ArcMap and ArcCatalog instead of just ArcGlobe.

• 53 J Wallis // Nov 2, 2007 at 5:15 am

  I just still take issue with the original comment that “ESRI refuses to support KML” because they obviously support it in some fashion. If they were truely refusing to support it then there would be -zero- ability to use KML in ArcGIS.

• 54 Steve Larch // Nov 2, 2007 at 5:38 am

  I’m sorry but SOA is going to keep pushing the need for interoperability. If ESRI views that as an overblown need then they’ll eventually be at a competitive disadvantage to someone more willing to keep up with the industry.

  It isn’t so much that enterprises want to use KML as their standard data format. Its that they would like the ability to leverage other data sources regardless of the format and without having to spend an arm and a leg for something that should come in the box.

• 55 J Wallis // Nov 2, 2007 at 5:56 am

  ESRI doesn’t see it as overblown, but I guess their customers do since ESRI isn’t working overtime to build such support “out of the box”.

  Ironic that people clamor for this stuff “out of the box” when there is good money to be made by providing a well written ArcGIS extension. It sounds like ESRI is providing a good opportunity for someone to make money to provide KML capability to the 2D application side of ArcGIS.

  I know if KML support “out of the box” was the only thing I had to complain about with ArcGIS my life would be much easier.

• 56 wed // Nov 2, 2007 at 6:36 am

  I know if KML support “out of the box” was the only thing I had to complain about with ArcGIS my life would be much easier.

  That’s something I think we can all agree with!

• 57 James Fee // Nov 2, 2007 at 6:46 am

  I know if KML support “out of the box” was the only thing I had to complain about with ArcGIS my life would be much easier.

  Sure, we can all have a bitch post were we list the millions of things that bother us about ArcGIS, but this post was about a client who wants their GIS Analysts to have access to KML/GML generated by another product they use/plan to use.

• 58 NoLove // Nov 2, 2007 at 7:42 am

  Holy @#$% …the old gaurd vs. the Web 2.0 crowd. I LOVE IT!

  James maybe you should add a new blog posting titled: “GIS is dead…swallowed by IT”…and see what kind of response you get.

• 59 Righty // Nov 2, 2007 at 7:47 am

  @simon jackson: Any insight into what may have allowed you to see into the kml from ArcMap?

  On another note, I can’t see any kml listed in ArcGlobe either…

• 60 mfd // Nov 2, 2007 at 7:58 am

  Hi. This isn’t flamebait. Really, it isn’t. But, having only used Manifold, that is my only perspective.

  Can’t you just ask ESRI to include something? And, won’t they do it in the next release? Manifold typically incorporates user requests rather quickly - especially if it is some kind of one-off thing like importing and exporting KML.

  So, rather than complaining here, why not just ask ESRI to do it. Especially James, because you are a business partner. If they won’t listen to you, then maybe you have to re-evaluate how committed ESRI really is to their user base. Maybe they are only trying to protect their economic turf - which doesn’t bode well for the user community.

• 61 kj // Nov 2, 2007 at 8:09 am

  “complaining” can be called healthy discussion. ESRI does implement lots of enhancement requests - even more than Manifold, becuase the products are bigger and broader! ESRI has even implemented some of my feature requests, where-as manifold has not. That’s not to say one is better than the other, it probably just means that more people asked for the same thing as me for some of my ArcGIS requests than for some manifold requests. There are proper channels at both companies for enhancement requests, and like all software companies not all enhancement requests (e.g. candidates) can be implemented - so they weigh against frequency of the request and strategic product vision and direction. So that means that if you really want something, your best bet for getting it is to log the enhancement request via the proper channel with the software vendor, but then ALSO to advocate for it in user forums - which gets other users who see it and want it to log the same request, and also exposes discussion to the vendors both of whom lurk here - so when they see a hot topic or things people are freaking out over in blogs, they can use that in their decision making process when picking feature candidates to implement.

• 62 Steve Larch // Nov 2, 2007 at 8:16 am

  @NoLove

  You see where I’m coming from…. Google shouldn’t be discounted for not having a desktop application for the same reason it shouldn’t be assumed that Microsoft will buy ESRI. You can bet both companies have people who are attempting to come up with a view of GIS five years down the road and whatever the shape when you’re dealing with uncertainty the solution has to be flexible.

  Also, when you have Google and Microsoft interested in location-based services how long does it take before IBM’s interest is piqued? If the GIS of the future is a web 2.0 application sitting on top of an analytical API going against a spatially-enabled database then who is in the best position to capture market share?

• 63 J Wallis // Nov 2, 2007 at 8:30 am

  @No Love

  I think it is more fundemental than “old guard vs Web 2.0″. It is “flash web programmers vs geographers.”

  This is probably meant for a totally different thread, but someone should start tallying up the costs associated with having programmers with no geography skills implement GIS. Working with data formats that have geodetic limitations are only the tip of the iceberg.

• 64 NoLove // Nov 2, 2007 at 9:29 am

  @JWallis

  I have no time for flash but I do have time for AJAX. We would not be having this discussion if it were not for non-GIS programmers. KML, Virtual Globe technology, and Web 2.0 are all thanks in part to computer software engineers and not GIS programmers.

  I come from a more traditional geography/GIS background, and I would rather hire computer programmers and train them on GIS then hire GIS analysts and train them how to program. Now there is some waste!

  There is a place for geographers and GIS staff, but let’s face it GIS is not as complicated as we all (the GIS crowd) tend to think.

  Long gone are the days of AML…at least I hope.

• 65 J Wallis // Nov 2, 2007 at 10:06 am

  @No Love

  send some of those magical programmers my way then.

• 66 NoLove // Nov 2, 2007 at 10:11 am

  @JWallis

  I think they have been talking to you for the last 60 or so comments (minus yours).

• 67 oakfish // Nov 2, 2007 at 11:53 am

  Being a web programmer myself (not sure if I’m “magical”), I can honestly say that this discussion brings to mind that arguing that KML is unfit for GIS Analysis is like arguing that AJAX is unfit for programmers. You can argue all you want, but in the end the benefit of Web 2.0 technology isn’t for the brainiacs behind the scenes — it’s for the benefit of the USER experience. KML has been (AJAX, too) an integral part of popularizing GIS or location-based applications, if you prefer. ESRI needs to (and I believe they know this) keep up with the times if they want to survive. They’re already falling way behind in the Web-based map viewer race. I’ve already converted several burgeoning ArcGIS Server sites to Virtual Earth.

• 68 miken // Nov 2, 2007 at 12:24 pm

  I agree with No Love. GIS is simple! The difficult part is the development of a ” web 2.0 application sitting on top of an analytical API going against a spatially-enabled database “. Look at power users of GIS…I am one and I have no formal training in it. i just started up Arc what ever and Manifold and plugged away until I learned what I was doing (about two days). I try to do the same with progaming (years) and I still have just begun.

• 69 wed // Nov 2, 2007 at 12:36 pm

  I’ve been programming for a long time, most of it in the GIS world. I don’t know that I’m prepared to say that GIS is “simple.” If you find it to be simple, then there’s a lot more to discover.

  I would suggest that you not forget that all of those APIs out there wrap some pretty complex operations that people with an advanced understanding of both geography and programming packaged up to make it look “simple.”

• 70 Brian Timoney // Nov 2, 2007 at 12:46 pm

  @oakfish–
  Thank you for being sensible.

  As for this latest version of “what starts as an ESRI feature commentary morphs into a ‘Whither GIS?’ debate”, I will only add that in 18 months the majority of location-based analysis will be done by .NET programmers using SQL statements against spatially-enabled databases –with the visual output being piped to a “lightweight” web interface.

  Whether you call it “GIS” or not is irrelevant. Whether you turn up your nose at “buffers & intersections” is irrelevant. This is where the explosive growth is going to happen. Should you choose not to participate, fine. But the next generation of developers will not only be liberated from the burden of these endless desktop debates but also blissfully unaware of the misplaced condescension of the GIS priesthood.

  Brian

• 71 oakfish // Nov 2, 2007 at 12:51 pm

  I hate that this sounds like a lovefest between me and Brian, but dude — that comment says so much so well. Well said, indeed.

• 72 NoLove // Nov 2, 2007 at 1:00 pm

  Well said Brian!!

• 73 Dimitri // Nov 2, 2007 at 3:31 pm

  What an interesting thread….

  Let’s start with the most amazing fallacy:

  “I will only add that in 18 months the majority of location-based analysis will be done by .NET programmers using SQL statements against spatially-enabled databases”

  Brian, I respectfully disagree. That is about as likely as people giving up Excel in order to peruse “spreadsheet analysis done by .NET programmers using SQL statements against data-enabled databases.”

  The number of people who prefer an entirely visual, point-and-click GUI within a modern GIS to any sort of SQL (let alone any sort of .NET programming) outweighs the text interface , “let’s all code our own server-side appliance” brigade by at least 1000 to 1. That’s true of working with spatial data regardless of where it resides, be it in file-based storage or fetched in seamless connections to a spatial DBMS.

  In fact, that’s especially true of spatial DBMS storage, as anyone who has ever tried to market a spatial DBMS (like Oracle Spatial) will tell you. The first thing they all realize they need once they engage the market is a highly visual interface that eliminates the need to write code to do routine analysis. Otherwise, they find themselves at the mercy of whatever rich GIS interface customers choose to consume and manipulate data stored in the spatial DBMS. Listen to ESRI brag about how they strong-armed Oracle with Arc-middleware and you’ll know what I mean.

  Sure, there are developers who will create server-side applications in the style you discuss. Those applications will be outnumbered by about 1000 to 1 by people who simply use the spatial DBMS for storage and do all their work through point-and-click analytics within a modern, visual GUI like that in Manifold.

  Regarding KML:

  It doesn’t have to be the best thing on the planet or the standard to end all standards to be worth supporting. It simply has to be something that is used by 100 million Google Earth users. That makes it by far the most widely used (perhaps by a factor of 100 over whatever is in second place) spatial data standard around in terms of the number of people for whom it is their native spatial data format. It’s a trivial thing, anyway, to support, so may as well do it.

  Turning to James’ comment:

  “I can use ogr2org to convert to shapefiles, but that adds a step. Manifold adds nothing to this problem irrespective of the fact that it can handle the conversion.”

  On the contrary, it adds a lot… James, for shame: as an experienced GIS guy you know it is almost never the case that one should blindly convert one format into another and fire it off (although of course as experienced GIS guys we all are especially appreciative when we can get away with that…

  Realistically, you want to take a look at the data after import and before export so you can fix the usual, hare-brained errors in matters like datums, coordinate system parameters, etc. that have been inflicted upon you by whoever gave you the data, assuring you it was good to go as is. A real GIS like Manifold allows you to see whatever you’ve imported in context with however many other layers you want, so errors like wrong coordinate system parameters leap out as data is visually misaligned (here we have an example of why the whole world prefers visual GUIs to black box operations with .NET programs that call SQL statements).

  A real GIS also enables you to do the usual slicing and dicing you might want to do with data as well. Suppose you get an AutoCAD dxf showing parcel boundaries as lines from that friendly CAD guy in the streets department. You know, the guy who hands it to you proudly calling it a “map” and gets a blank look when you ask him anything about projections or georeferencing.

  You’re going to want to georeference that .dxf, clean up the usual CAD errors (dangles, overshoots, boundary lines not closed, etc.), create area objects (”polygons” in ESRI-speak), and so on *before* you put your name on the work product by exporting it as KML or anything else. A real GIS like Manifold lets you do all that within the comfort of a vast array of supportive tools and visual constructs that save you time, reduce errors and ease you on your way to a blissful weekend. [Don't get that either with a simple format converter or from the .NET guys writing SQL code who will be doing everyone's job for them in 18 months... ]

  And, given the interest in spatial DBMS, you’re going to especially want to be careful with the data by giving a good examination and cleaning before you upload it into your spatial DBMS. Don’t want to contaminate that central data warehouse with bogus data!

  So, yeah, sure it makes sense to use the real GIS of your choice to do format conversions, and that’s a good argument for your GIS being able to read formats of interest like KML.

  Can’t resist nitpicking one comment, which I realize was offered in good faith so I admit in advance this is nitpicking:

  “ESRI does implement lots of enhancement requests - even more than Manifold, becuase the products are bigger and broader! “

  I’d respectfully disagree with the “more than Manifold” bit. First, count up the number of new features released every year and Manifold is far ahead. Many of those are responses to user requests. Second, look at the elapsed time from when users start to ask for something and it gets done, especially noting really significant requests that users especially must have to stay competitive - Manifold does those much faster.

  Examples that come to mind are support for Vista, native 64-bit code for all products, bona-fide use of multi-core processors, integrated IMS, direct usage of native spatial DBMS [Oracle, DB2, Katmai, PostgreSQL] and built-in use of image servers. I could be wrong about this, but as far as I know ESRI is far behind in those areas despite a lot of user requests. ESRI probably will do most of these things, but years after Manifold.

  Third, I’d respectfully disagree that ESRI’s products are bigger and broader. No ESRI product comes close to Manifold Universal in breadth or depth. Not even close. At best, you have to glue together [whatever ESRI is calling them now...] ArcInfo ArcSDE ArcIMS ArcObjects parts of 3D Analyst. And even with that ensemble all put together I don’t think ESRI is doing 500 to 1000 new features a year as Manifold does, nor are they doing really major technological things like using NVIDIA CUDA to get supercomputer speed on a desktop for a few hundred bucks.

  Regards to all!

• 74 Dave Bouwman // Nov 2, 2007 at 3:39 pm

  Cheers to Brian for adding some sanity to this thread.

• 75 EB // Nov 2, 2007 at 4:03 pm

  Hey Steve,

  Congrats on that devZone, Dude!

• 76 Paul Bissett // Nov 2, 2007 at 4:42 pm

  Good thread. Not much more that I could add except a couple of anecdotal comments.

  1) Our own hiring practice is heavily weighted towards competent programmers before GIS experience. Given our experience in building sensors and creating mapping products perhaps we are tilted towards that which we lack. However, it was far easy for us to give GDAL to our programmers and explain some of the geospatial terms and meanings than it was to give GDAL to those with GIS experience and expect them to write the code to process near-real time reprojections for terabyte size files.

  2) Our previous government clients have got the KML-jones bad, including the Navy. It appears that Google has put the hard sell on them to use Google Earth Enterprise Services. This is reaching into the USACE and other branches of the DoD and civilian agencies. Anecdotal evidence, but I think it points to some of the push we are seeing to incorporate KML as part of an interoperability standard.

  3) Betamax was a better standard than VHS. Is there a useful analogy here?

• 77 J Wallis // Nov 3, 2007 at 9:40 am

  @Paul

  pushing KML works great for the military since they are standardized on WGS84. That is where the format advantages end though (if that even were one). However the Google Earth enterprise product doesn’t even begin to address the analysis needs that the military requires.

• 78 KoS // Nov 3, 2007 at 10:44 am

  Doesn’t Google keep track of the usage of their product? Like, viewing or importing data.

  Why would the military want/allow a third party know what data they are viewing, what type of analysis being done, so on and so forth? Even if it’s not classified work. Wouldn’t one think it’s not wise to have a third party looking over ones shoulder or even maintain a listing of what has been done.

  It’s my understanding why some use WorldWind over GE because of those exact concerns.

  KoS

• 79 Tim Maddle // Nov 3, 2007 at 11:45 am

  I -think- GE Enterprise is, or can be, a self-contained solution. On the server side, you’re connecting to your own internal GE Server, so there’s no need to connect to Google’s GE servers where they can monitor your activity. On the client side, I would assume the military has firewalls that can block any attempt by GE desktop to transmit usage information.

  GE Enterprise doesn’t offer the advanced analysis that an organization like the Navy requires, and nor should they. The best option would be for GE Enterprise to focus on being the best presentation layer possible while interfacing with existing systems that have been created to do the analysis. This seems to be the future of GIS - a separation between products offering presentation of data versus those that offer geoprocessing and analysis.

  James, thanks for the FeatureServer link. I will give it a look. I’ve been using MapServer/Mapscript in a similar fashion - as a RESTful service under ASP.NET. Mapscript makes it possible to point to existing .map files or dynamically create maps in response to user requests. You can work with existing data or dynamically create “virtual” layers as necessary and return results as images, GeoRSS, json, VE pushpins, or whatever your heart desires.

• 80 Tim Maddle // Nov 3, 2007 at 11:56 am

  I seem to have problems editing my comments. I wanted to add that in ESRI’s latest newletter they mentioned their own “Aerial Imagery” appliance that reminded me of GE Enterprise. Instead of using the ESRI servers, you would purchase this appliance and point your ArcGIS Explorer to it instead of ESRI’s public servers.

• 81 J Wallis // Nov 3, 2007 at 6:37 pm

  @KoS

  Google earth is like crack….once they get people hooked on it they overlook things like privacy and security. Never in my life have I seen people fall over themselves for such a weak app.

  But if it was called Microsoft Earth you can guarantee people would be all over the usage tracking issue.

  And yes ESRI has an appliance that you pop in behind your intranet. Unlike google it isn’t tied to one app. You can point AGS at it and serve it up as WMS. I haven’t heard the cost but I’m strongly considering it because I don’t want my internet connection saturated going out to their services.

• 82 Tim Maddle // Nov 3, 2007 at 6:50 pm

  I assume Microsoft monitors usage. After all, their licensing for VE is supposed to be “X” number of tiles per day free, then you start paying. No complaints from me.

• 83 kj // Nov 5, 2007 at 7:44 am

  “Third, I’d respectfully disagree that ESRI’s products are bigger and broader. No ESRI product comes close to Manifold Universal in breadth or depth. Not even close”

  I like Manifold a lot. By broader and deeper I mean there are some capabilities in the ESRI stable not in the Manifold stable, to name a few:

  - ability to do GIS in the “cloud” - meaning the Web API’s of ArcWeb Services (like google maps API, MS VE APIs, and the rest) - I am not aware of Manifold having anything similar?

  - mobile apps designed to run on mobile operating systems - meaning ArcPad, ArcGIS Server Mobile ADF, StreetMap Mobile SDK with 2.5d maps

  - cross platform support, only one example -ArccGIS Engine QT controls for cross-platform development - as I understand it Manifold runtime engine is for Windows only?

  - sheer size of ArcObjects (thousands of interfaces) - like for example I looked up MapServer in Manifold help and it has around 30 properties, around 20 methods, and is covered on a single page in the help. The Manifold scripting reference shows something like 270 objects. I think it seems smaller.

  - deeper like GIS server is scalable beyond one single server out of the box (though I admit the price does not scale well at all), as well as the larger object model providing way more fine grained objects

  - free geobrowser + SDK - ArcGIS Explorer - similar to Google Earth, but with geospatial analytical capabilities + robust SDK, I don’t think Manifold has released a free geobrowser

  I understand anyone can think ArcObjects is too big, and indeed its difficult to find your way round sometimes, and parts of it cost a lot, and it stinks when you bump into something you think should be in the base product that is in an extension, and even that sometimes less is more. I understand the mfold business model is to not develop for non-windows platforms or mobile operating systems, and I think their model is elegant and streamlined - which definitley allows them to be very quick and agile by focusing only on one main product - and they have released some wonderful innovations. I like Manifold a lot.

  I was just responding to I think misleading comments suggesting ESRI is sitting around not releasing anything new from version to version and SP to SP, because its just not true. Because of the breadth and depth of their line, add it up and they release lots of stuff each year spread across it all. They have been very busy latley, just like everybody else.

• 84 al // Nov 5, 2007 at 9:18 am

  Worst jobs for the 21st Century

  “Like computer programmers. Despite all the advances — and expected job growth — in the computer industry, expect the number of programmers to increase by about 2 percent between 2004-2014. Why? Outsourcing.”

  http://www.msnbc.msn.com/id/21311274/

• 85 Cellulose // Nov 5, 2007 at 9:39 am

  I have no idea what the hardware costs are for the ArcGIS Data Appliances, but the data costs start at around $15k for data. Obviously, it can be way up or a bit down depending on your needs, age of data, etc. I had an option to serve it through ArcIMS, ArcGIS Server, or a data appliance.

  We have a worldwide dataset served from within our ArcGIS Server infrastructure in-house. Completely self contained, no phoning home, or unwanted activity logs… just the ones I keep.

  The same dataset from Google was around $75k and I would have been *forced* to buy the GE Server appliance at a cost of 6-figures. The GE appliance was self-contained and could operate without phoning home… though they were evasive when asked how to sanitize the appliances of usage information.

• 86 tom riddle // Nov 5, 2007 at 10:37 am

  - sheer size of ArcObjects (thousands of interfaces) - like for example I looked up MapServer in Manifold help and it has around 30 properties, around 20 methods, and is covered on a single page in the help.
  

  Nice post. I won’t address everything, but here is one example of where you may be confused. In Manifold IMS, if you grab the MapServer, you can get the document, or application object:

  Set ManApp = MapServer.Application
  Set ManDoc = MapServer.Document

  once you do that, EVERY SINGLE Manifold object is now available to you over the Internet - including the User Interface controls. So, all the vector, raster, and table operations are now available to you. That is way more than ArcIMS, and probably comes close to rivaling ArcGIS Server

  But, you are right, ArcObjects is certainly more “granular” than Manifold, and has many more objects exposed.

• 87 KJ // Nov 5, 2007 at 11:47 am

  “In Manifold IMS, if you grab the MapServer, you can get the document, or application object”

  - thanks, you are right. I a big fan of Manifold IMS, and there are definitley things I can do with it that I need ArcGIS Server enterprise advanced for.

• 88 Dimitri // Nov 5, 2007 at 12:09 pm

  Following up on kj’s post with yet another book-length missive…

  “By broader and deeper I mean there are some capabilities in the ESRI stable not in the Manifold stable, to name a few:”

  I 100% agree with you that in any comparison of products that each have thousands of pages of documented features it will always be the case that there will be features in one product family that are not in the other. But I respectfully point out that the presence of some exceptions on either side does not a “broader and deeper” case make - to do that, you really have to consider the overall set of features. There, I still would contend ESRI has no product (and, for that matter, not even a product ensemble) that even comes close to the breadth and depth of Manifold Universal. Even though there are parts of ESRI’s product family that have features Manifold does not (as expected), so does Manifold have many capabilities ESRI products do not. And the overall balance is way more on the Manifold side of the ledger.

  You raise some interesting points that merit further conversation - I hope folks understand the following is in the spirit of detailed conversation offered in respect of the good faith points raised. It’s too easy sometimes to give the impression of tit for tat when what is intended is a spirited discussion prompted by intelligent points raised.

  “- ability to do GIS in the “cloud” - meaning the Web API’s of ArcWeb Services (like google maps API, MS VE APIs, and the rest) - I am not aware of Manifold having anything similar?”

  Sure it does. There is the vast array of capabilities enabled through the Manifold API via IMS, which include things exactly like image servers (like GE), WMS servers, WFS-T servers and so on.

  “- mobile apps designed to run on mobile operating systems - meaning ArcPad, ArcGIS Server Mobile ADF, StreetMap Mobile SDK with 2.5d maps ”

  That’s a negative for ESRI and a sucker trap for developers, not a positive. It’s a bit like being proud you have an API for 8-track cartridge tapes and cassette Walkmen in an era of iPods.

  Manifold feels that there are two approaches that make sense for mobile devices: 1) Web 2.0 stuff using ultra-thin browsers in the mobile device and full-power web applications running server-side on Manifold IMS, or, for those vanishingly small number of users outside the cell cloud, 2) Running real Windows with non-lobotomized applications on UMPCs.

  The first is obvious and should have a lot of appeal given your first point. The second bears some discussion, since at times people forget to reckon the high price they pay for obsolete software strategies that are led around by the nose by inadequate appreciation of hardware evolution.

  I’m an ex-Intel guy, like many of the folks at Manifold, and we all have immense faith, acquired through direct experience, of the operation of Moore’s law. It takes a lot of time to lobotomize something like ArcInfo or Manifold into a stripped-down version that runs within a limited PDA operating system. In fact, it take so much time that by the time you are done the PDA has evolved into a real PC that is even slimmer than what you started with, has a much bigger screen and more capabilities.

  The stupid thing to do is to burn a lot of resources creating a lobotomized PDA version. That wastes engineering time and creates yet another Arc-thingy that is incompatible with all your other Arc-thingies. Your PDA Arc-thingy will forever lag behind whatever progress your company can muster in the other Arc-thingies, and it will always cost disproportionately more to sell and to support because it is a special case lobotomy product. If you are a third party developer, the last thing you should consider is developing to some lobotomized SDK because that simply guarantees that all your hard effort will result in a product that is even further removed from modern capabilities.

  Manifold won’t do anything that dumb. Our standard, off the shelf product runs great in standard, off the shelf UMPCs, which are continually getting smaller and smaller. Everythying we do, every new capability we add, every feature we fix, every optimization we do runs perfectly, without modification in new genration handhelds. You can buy the standard product and take advantage of huge economy of scale, know you are getting the latest and best technology all the time, and leverage dramatically better technology for end users: much higher resolution screens that enable more sophisticated and more user-friendly interfaces, etc. That’s real depth and breadth, as compared to lobotomized obsolescence.

  “- cross platform support, only one example -ArccGIS Engine QT controls for cross-platform development - as I understand it Manifold runtime engine is for Windows only?”

  “only” ? The old joke is that when the Manifold sales guy is asked what operating systems Manifold supports he or she cheerfully replies “All of them! … Windows Vista, Windows Server 2003, Windows XP….” That is, indeed the reality as Manifold really does have an exclusive focus on Windows. But that is an example of Manifold’s better breadth and depth, not a counter-example.

  Manifold’s focus on Windows is not because of any personal animosity to other operating systems, it is simply catering to our customer base. Windows users want their vendors to have a focus on Windows. Windows users are fed up with vendors who blather about other operating systems while failing to do as good a job in Windows as vendors, like Manifold, who focus on Windows. In Manifold’s case, customers know that they can count upon us for fanatic and expert support of Windows with no siphoning of attention or resources to rescue people who failed to move to Windows when our customers did.

  They don’t get that from ESRI, which is a black mark against ESRI’s breadth and depth for those 96% of c0mputer users who run Windows. A good example is that Manifold supported Vista from Microsoft’s earliest interal betas and today supports all Vista editions, including 64-bit native Manifold code for Vista x64, while ESRI is still blathering about maybe supporting Vista real soon some day. That ESRI takes years to figure out they should be supporting Windows standards, long after the Windows ecosystem has moved to those standards, is a huge black mark against ESRI.

  “- deeper like GIS server is scalable beyond one single server out of the box (though I admit the price does not scale well at all), as well as the larger object model providing way more fine grained objects”

  I defer to tom riddle’s comments about objects. Regarding scalability, Manifold is far more scalable in Enterprise applications. ESRI does not even come close. There are several dimensions of Manifold’s greater scalability ranging from simple to sophisticated.

  The simplest example of scalability is also the most brutal gain in Manifold performance over ESRI: Manifold runs as true, 64-bit code and utilizes multicore processors while ESRI does not. That is a brutal and decisive advantage in scalability for over 99% of IMS and Enterprise applications ranging from the single consultant hosting web sites to some very large companies.

  By being limited to 32-bits ESRI is condemned to grossly inefficient, small memory spaces. By failing to utilize multicore processors they are condemned to add physical computers to attempt to keep up with Manifold. Consider an example case:

  With Manifold, you can deploy a motherboard with two processor sockets and plug a quad-core processor into each for a total of eight, 64-bit processor cores. Install 16 to 32 GB of RAM and run x64 Windows. Your Manifold IMS will eat alive ESRI IMS even if you deploy that ESRI IMS on multiple machines.

  Better still, you’ll get the huge savings of running just a single server with one copy of Manifold (a mere $225 for x64 Universal), one operating system license, one license for all sorts of accessory software, one system to maintain, to power, to find rack space for, to cool, etc.

  Let’s take a more sophisticated look at scaling. The real bandwidth in almost all web applications comes in the DBMS side of the application - it is the DBMS that really controls the scalability of your application.

  With ESRI, you have to use whatever they are calling their bizarrely obsolete ArcSDE middleware these day. Lame! Costly! Slow!

  With Manifold, you can connect directly to whatever rocket-hot spatial DBMS you choose to use: Oracle, DB2/spatial, Microsoft SQL Server 2008 spatial, even PostgreSQL/PostGIS. Without any ESRI-style middleware nonsense, you get to immediately take advantage of the endless scalability your DBMS vendor has spend billions of dollars to provide for you. Fast! Cool! Inexpensive!

  And… keep in mind that your connecti0n to those databases, because Manifold automatically takes advantage of multiple processors for such things, will indeed be automatically multi-threaded through all those cores you have running. And it will be a 64-bit connection and you get all that built into that same $225 price per server, with no extra costs for Arc-middleware. And, you get the benefit of interoperability with all the other applications your enterprise employs with that DBMS because Manifold uses the vendor’s native geometry types and not some hare-brained proprietarization as does ESRI. Interoperability is a key part of scalability.

  I guess the last part of the puzzle is that some web applications will indeed, even with multicore servers, require multiple servers. No problem there with Manfiold as well. Centralize your data within a spatial DBMS and any web guy worth his salt knows how to plug in more IIS servers running IMS to provide front ends. I grant you that it will require some thought in the writing of the web application, but such applications require thought anyway and scaling them out to many servers is not a significant part of the percentage of thought required overall.

  “- free geobrowser SDK - ArcGIS Explorer - similar to Google Earth, but with geospatial analytical capabilities robust SDK, I don’t think Manifold has released a free geobrowser”

  There’s the free Manifold Toolbar for IE, which enables any IE user to take advantage of any image server interface module from within IE: use Virtual Earth, Google Earth, Yahoo, etc.

  Our view is that the world does not need yet more proprietary browsers. We already have IE and Firefox and that if the world is really interested in browsing geographic content on web sites, use IE or Firefox.

  Web sites already provide all sorts of content. They provide images, audio and video using all sorts of different formats. There are endless new forms of content appearing supported by endless new types of plug-ins of various kinds for IE and Firefox. But no one in their right minds suggests, in the usual course of events, that just because someone invents a new type of content you should suddenly have to drop using Firefox, or Opera, or Mozilla or IE to browse a web site.

  People only try that when they are trying to trick you into supporting their proprietary new browser. It is a time honored strategy of cornering the public Internet - sucker people into using a new browser that only you control and that is designed to herd users into