James Fee GIS Blog

82 responses so far ↓

• 1 Arnie // Feb 5, 2008 at 10:40 am

  What a great solution James. I like how the workflow is so simple. This is what ESRI should have done years ago.

• 2 Gretch // Feb 5, 2008 at 11:01 am

  Neat stuff. I like how you can use the software you want to use and share with everyone. I agree, why isn’t this already available in ArcGIS?

• 3 Yo! // Feb 5, 2008 at 11:41 am

  I can’t believe you are calling the ESRI GIS Portal Toolkit slow, expensive and hard to use.

  You can chalk up our organization as one that just rolled it out a couple weeks ago and now realizes that its crap (well the rank and file know this, the leaders who have dinner with Jack seem to not care). As a taxpayer you should be outraged!

• 4 KipterUh // Feb 5, 2008 at 2:25 pm

  I like the approach here. Simple solutions to simple problems. I think we loose sight of that in the GIS world.

• 5 MTBMaven // Feb 5, 2008 at 2:56 pm

  Very interesting stuff. I have just started following your blog, which I’m loving BTW. Question regarding this topic. It seems that the proposed type of editing is rather simple (not meant in a derogatory way), kind of like editing in ArcView 3.x. Is there any support for snapping?

  It appears in your example images the client needs to digitize building footprints from an aerial photo and may not need snapping capabilities. However for proper data creation it seems snapping would be an important feature.

• 6 James Fee // Feb 5, 2008 at 3:17 pm

  Yes you can perform snapping. You can check out the demo here for an example:

  http://dev.openlayers.org/sandbox/camptocamp/feature/examples/modify-feature.html

  You can edit the polygon by clicking on it and moving the nodes or draw a new polygon and have it snap to those same nodes.

  We choose not to implement this right now because it just isn’t needed. Though as more polygons get created, being able to modify them and snap them will become very important.

  You can even take it one step further and perform basic GIS analysis:

  http://crschmidt.net/mapping/wpserverdemo/

  What is nice is we can start with a very simple application and add functionality as needed rather than start with the kitchen sink and strip things away.

• 7 Tim Maddle // Feb 5, 2008 at 7:21 pm

  @James,
  “What is nice is we can start with a very simple application and add functionality as needed rather than start with the kitchen sink and strip things away”

  I couldn’t have said it better myself. My organization has a need for a simple online polygon editing system. This type of solution would make a lot of sense, but it takes imagination and commitment, and it’s easier for many people to believe that AGS Advanced, out of the box, will cure all our problems.

  I’d be anxious to try a similar setup using Spatial SQL against the SDE (if I may still call it that), which is supposed to support versioned updates if you structure your SQL properly. If only I could get that extension installed.

• 8 j // Feb 5, 2008 at 7:56 pm

  Very nice. I like the flow.

  Of course, we often run into the “ESRI shop” (or “Autodesk shop” for that matter) syndrome in the fact that the IT and/or GIS dept. won’t let us stray from what they already have, which is quite short sighted if you ask me:-(

• 9 timmy // Feb 5, 2008 at 8:37 pm

  There is a COTs web solution available that offers data editing in SDE via an ArcIMS front end.

  http://demos.geocortex.net/imf-5.1.006-es/sites/demo_editing_suite/jsp/launch.jsp

  There is a COTs web solution available that offers data editing in SDE via an ArcIMS front end.

  http://demos.geocortex.net/imf-5.1.006-es/sites/demo_editing_suite/jsp/launch.jsp

  It’s not free but there is something to be said for leveraging the distribution of development and maintenance cost and risk over a large client base. I certainly couldn’t justify paying for the staff or vendor support to build and support an application of this nature.

• 10 timmy // Feb 5, 2008 at 8:39 pm

  argh… sorry for the redundant text. Not sure what happened there.

• 11 bender // Feb 6, 2008 at 2:40 am

  James, you’re beginning to preach. Don’t believe, that your solution leads to the thesis that’s it is developed quicker, more focussed and all in all cheaper, give us well structured arguments.

  1.) it is cheap because you don’t have to pay license fees and Christopher has helped you out without any costs. What saves costs behind that? What does it depend on? Friendship, community?

  2.) is it quick because of the same reasons? is there a dependency to the knowledge level of support? are small software clusters (like christopher and you) more agile and better prepared than big ones (like esri support)? where are the depend parameters?

  3.) is it a good technical concept because it’s based on more or less official standards? does standards have something to do with the marketing concept of the software vendors? where are the “standards”? where are they missing?

  Please, again: Don’t put buzzwords together. Keep the discussion clear. Several reasons are mixed up in your argumentation. First of all it was cheap, second of all you’ve had a agile, flexible community, third of all, you’ve had a underlying protocol.

  I’m missing clarity here at all sides.

• 12 Sune Edmund Pedersen // Feb 6, 2008 at 4:48 am

  Remotely editing of data is now one of the keys to providing efficient workflows, and ESRI technology is not always the first choice. Open Source, Free (of cost) and Free is one choice, but as some correctly notice there are other solutions out there. Our company has developed a remote editing solution for Oracle, WFS-T, ArcSDE and PostGIS, and the OGC standard will help others like us to put solutions on the market.

  You will find versions ranging from free to 3000€/year on
  http://www.spatialedit.com.

  ESRI and others price policy paves the roads for both Open Source and companies like Manifold and us to address certain market segments.

• 13 Sune Edmund Pedersen // Feb 6, 2008 at 5:30 am

  Looking at the images, I just realised why ArcGIS cost more than Google Earth - They put more car into the images

• 14 James Fee // Feb 6, 2008 at 6:42 am

  @bender:
  You’ll just have to wait for tomorrows post on that.

• 15 Paul Ramsey // Feb 6, 2008 at 8:56 am

  @timmy,

  James did use off-the-shelf components, there just wasn’t a capital cost associated with purchasing them. IMF is a off-the-shelf component, so are Openlayers and Featureserver. Why is the integration cost of the components James chose so much more galling than the integration cost of bringing IMF into a shop?

  On your second point, what makes you think Openlayers and Featureserver aren’t leveraging development over a large community?

• 16 James Fee // Feb 6, 2008 at 9:58 am

  @timmy

  Anyone putting money down on an ArcIMS solution in 2008 might as well toss it in the trash.

  My clients realize that ArcGIS server is the modern way to go. In this case they did not want to spend the money on services they didn’t need. This could have been done with AGS, but we accomplished the same thing without spending any extra money on licencing. Plus OL & FS were improved.

  Beers all around.

• 17 timmy // Feb 6, 2008 at 1:08 pm

  @ paul

  I’ll admit the concept of open source has my attention technically and is an intriguing market model but there are some strategic points that I can’t seem to reconcile, perhaps you all can clue me in…

  1. Staffing- The specialized skills necessary to build and maintain an open source app are hard to come by. There is a premium on any specialization, is the talent pool to build and support these open source solutions deep enough to maintain continuity in staff skills?
  2. Risk- Our landscape is changing so fast there is an extreme amount of exposure to dumping resources into a solution that isn’t supported. If any one component of the enterprise stack changes you’re vulnerable and I trust those I’m paying to cover my maintenance than I do an ethereal community. When it comes to supporting my clientele I need tangible support resources. How good are the support resources for open source solutions? Is there comprehensive up to date documentation? Can I call someone in an a oh $*!&% moment?
  3. Sociology / Psychology- There is so much more to pitching a solution to those who control the purse strings than technical logic. Selling open source to the powers that be is… well it’s tough. Are there consultants that can be hired to answer the hard questions and make the decision makers feel comfortable? I would love to see more real world business cases for comprehensive GIS environments that must cater to diverse requirements.
  4. Compatibility- This problem reaches across the board but when it comes to open source vs. closed source; from what you’ve seen is it a wash? I must admit that I’m inclined to stick with the devil that I and everyone else knows. Additionally doesn’t the nature of open source introduce opportunities for proprietary stovepipes?
  5. Business model- I think I’m missing the business opportunity behind open source. Perhaps its altruism or a hobby… but that only goes so far. How are people leveraging this to pay the bills? Are services where the money is at?
  6. Third party business applications- It could be argued that an enterprise GIS exist to support business requirements which often call for a third party client solution. Are vendors building COTs apps against these third party solutions?

  These are sincere, and perhaps naïve, questions; I’m not trying to prove a point and pick a fight rather I’m simply trying to develop an intelligent perspective.

  @ James

  You have a point at first blush… and you’re right there is no “one size fits all” application out there. Which makes me surprised to read your blanket comment about IMS. Many clients need solutions now and the business requirement that the solution is designed to support will lose much much more if it isn’t in hand yesterday. So… do they eat the loss as they wait… and wait… and wait… for something else or buy something proven that is immediately available that can be deployed without additional layers on their enterprise stack?

  So far I haven’t seen any application as stable, robust, and efficient when it comes to editing online. If someone knows of an application or can build an application with its capability AND support for less that what they’re selling it for…. I have cash in hand and am all ears.

  Seriously.

• 18 James Fee // Feb 6, 2008 at 3:34 pm

  @timmy: My comment stems from the fact that multiple ESRI devs have told me that for all intents and purposes, ArcIMS is in maintenance mode. It doesn’t support any new features and probably won’t. Investing in such a product means that you won’t be able to invest in future more modern products because you’ll be tied to the past. ArcView 3.x works, but you wouldn’t drop thousands on dollars on a solution (or at least I how you wouldn’t) and the same goes for ArcIMS.

  Editing vectors in OpenLayers is as “feature rich” as anything I’ve ever seen on the ESRI side.

• 19 timmy // Feb 6, 2008 at 8:20 pm

  @ james

  You raise a good point and you’re right.

  If I developed the application myself or had someone develop the application for me I would be out of luck when ESRI drops IMS support (which I would argue will be quite some time if 3.x is any indication). But that’s my point… I want to buy the COTs application with a large customer base thus leveraging economies of scale to reduce risk and cost and …if I’m savvy enough… make sure the maintenance covers upgrades that will accommodate the inevitable evolution of the backend technology. If I’m even smarter… I would pay the same vendor for any customization that is required and work with them to include it in the next release or sell it as an extension insuring that my maintenance covers the cost and reduces the risk of the inevitable software upgrade.

  As for OpenLayers are there any “plug and play” products out there or would they have to be built from scratch?

• 20 James Fee // Feb 6, 2008 at 8:49 pm

  OpenLayers is a Javascript API in the same sense that Google Map and Virtual Earth are. What types of products are you talking about here? FeatureServer, TilesCache, ArcGIS Server, ArcIMS, etc… all “plug and play” server products.

  Or am I not understanding you.

• 21 timmy // Feb 7, 2008 at 3:59 pm

  Maybe if I put it this way. I don’t want to develop the software that meets my requirements, I want to buy it as a complete product. I understand OpenLayers is an API that can pull in data from multiple sources.

  In this post you noted that your client wants you to build something to meet their business requirements and you’re using openlayers to develop it. It’s the end product that you would provide to them that I’m talking about. However I want to avoid sinking money into building what amounts to an exclusive application with high exposure to risk to get what I need. I want to buy it and mitigate risk by paying for maintenance. A good example would be the third party client applications that sit on top of ArcIMS (i.e. GeoCortex, Freeance, GeoSmart, et). It is very improbable that someone could exclusively build any one of those applications for what you would pay for them off the shelf. Why? Because the cost is spread out over the entire customer base. Its COTs applications such as these that leverage the open source resources that you’ve discussed that I’m interested in. Make sense?

• 22 Lakshmanan // Feb 8, 2008 at 4:01 am

  Good Article

• 23 Christopher Schmidt // Feb 8, 2008 at 6:58 pm

  I haven’t yet understood what people want from ‘plug and play’ editing, but a feature list would at least let me understand whether OpenLayers can do it, and maybe even start building it (if there is an it to build).

• 24 Chris Holmes // Feb 8, 2008 at 7:06 pm

  Just FYI, GeoServer 1.6.x has ArcSDE write capabilities, and OpenLayers talks directly to it with WFS-T (and soon we’re hoping to implement REST like FeatureServer does).

  We’ve also got some versioning of features with a PostGIS backend. You can check out the demo.

  The UI is a bit rough, but we’re working on improving it. With some additional funding we’d love to hook it up to ArcSDE’s versioning. We also have another beta demo with a slicker UI, but less focused on ‘GIS’ needs is at

  @timmy: We’re working a lot on online editing, contributing the capabilities to OpenLayers and GeoServer. I don’t know how much Arc* web editing costs, but we build applications and sell commercial support on GeoServer and OpenLayers. Though we’re full on work right now so may be a couple months till we could get started.

• 25 James Fee // Feb 9, 2008 at 8:28 am

  @timmy: There isn’t anything custom there at all other than the features in PostGIS and the HTML eye candy around the map.

  There was some coding that Christopher had to do to get the GML to work with ArcGIS, but now that is done any project (not just mine) can take advantage of that. None of it is custom.

  @Chris Holmes Yea we’ve started looking at GeoServer as well. I think GeoServer might be more comfortable for ESRI Server users than MapServer because of its configuration. Much closer to what ESRI users are used to using over MapServer.

• 26 MTBMaven // Feb 10, 2008 at 8:58 am

  @James Fee:
  “Anyone putting money down on an ArcIMS solution in 2008 might as well toss it in the trash.”

  I’m sticking with ArcIMS AXL services unless something like feature linked anno or complex custom symbols are needed. AXL image service are clean and simple. AGS is single threaded and a total performance dog.

• 27 James Fee // Feb 10, 2008 at 9:00 am

  Without TileCache ArcIMS is slower than ArcGIS Server with its MapCache.

  Having to request a new image every time you change the map is very slow.

• 28 MTBMaven // Feb 10, 2008 at 9:17 am

  @ James Fee:
  It seems as if you are missing timmy’s point all together…or maybe we are missing yours. I am 100% in timmy’s position. I need a product I can buy and easily implement and migrate. I can’t afford to be constantly tweaking things and getting under the hood of an application every time I need to add a connection to a new database, create a new search or report, or add some new functionality. I need proven supported software. Our resources are too scares to spend this kind of time playing around with things.

  Some organizations can quickly deploy the types of application you develop. These would likely be small more agile organizations. Larger less agile organizations (government, utilities, etc.) need proven more established applications with maintenance plans and migration paths.

  Now don’t get me wrong. I’m glad…very glad…there are people like you out there working on stuff like this. Because soon these ideas are going to make their way into products that work for my organization. The hope is these products will be better, faster, cheaper.

  Some here have poo pooed the idea of open source. I see it as a development process by the public rather than a software company. In the end we as users and software consumers will all benefit. So keep up the good work!

• 29 MTBMaven // Feb 10, 2008 at 9:20 am

  @James Fee:
  “Without TileCache ArcIMS is slower than ArcGIS Server with its MapCache.

  Having to request a new image every time you change the map is very slow.”

  We have developed tile caching for ArcIMS image services. It’s kind of beta as a pet project for our developer while he takes the bus home. It is really dang fast.

• 30 James Fee // Feb 10, 2008 at 9:37 am

  By Timmy’s logic, your tile cacheing isn’t “off the shelf” and not deployable in his world.

  You can actually use TileCache.org to handle the caches with ArcIMS.

  With your comment above, what you describe seems to be filled by open source software. Very agile stuff.

• 31 MTBMaven // Feb 10, 2008 at 10:44 am

  “By Timmy’s logic, your tile cacheing isn’t “off the shelf” and not deployable in his world.”

  No I totally agree. I have no idea how or if we can deploy it, which sucks because it’s pretty cool.

• 32 James Fee // Feb 10, 2008 at 10:55 am

  OK, I think we are arguing the same points. Buzzwords get in the way of innovation which is probably why the interesting stuff is in open source and open APIs such as Google Maps.

  We need to step away from these words in the ESRI world and focus on products.

• 33 Dimitri // Feb 11, 2008 at 6:39 am

  “We need to step away from these words in the ESRI world and focus on products.”

  Well said, James, although it would have been even better said if you enumerated those products which will do what you want in this thread for absurdly low cost, no self-development required.

  I have to admit, though, that I feel sympathy for you in the original blog posting for this thread - it is like you have been so abused by the limitations of the ESRI software you use that you are willing to do backflips through hoops, and feel happy about it no less, to accomplish what should be a natural, built-in part of the software you use.

  Doing the GIS equivalent of cobbling up your own shoes in this case is fine if your hobby is software development and integration and maintenance (the real cost over time) and you don’t care how much time that swallows, but it is totally off the charts in the common sense department if you have a business to run. Anyone who is happy about spending so much money on ArcGIS thingies yet still having to do stratospherically expensive self-development like this probably is not spending his or her own money.

  Manifold solves everything you describe in this thread in the off-the-shelf Enterprise edition for $395. Two visual examples are even online:

  http://www.manifold.net/doc/example_tracing_virtual_earth_into_sql_server_2008.htm

  This shows using Virtual Earth to create vector layers directly into SQL Server 2008 spatial (Katmai, the new Microsoft product ESRI still does not support), but it could have just as easily been Google Earth and SDE (both of which can be connected to in an identical fashion by Manifold).

  http://www.manifold.net/doc/exporting_kml_to_google_earth.htm

  This shows the use of Virtual Earth to create data for a KML file. Manifold reads and writes KML, of course.

  If you want to have many thousands of people subsequently editing against a centralized data store, of course you can do that as well.

  I should point out that besides the initial lower cost of buying well-debugged functionality off the shelf you also get the continued benefit of someone else maintaining that functionality so that everything keeps working well together even as technology changes (new Windows releases, etc., not that ESRI cares about those… Vista anyone?)

• 34 Edd // Feb 21, 2008 at 1:51 pm

  good points

• 35 James Fee // Feb 23, 2008 at 3:31 pm

  @Dimitri:

  I have to admit, though, that I feel sympathy for you in the original blog posting for this thread - it is like you have been so abused by the limitations of the ESRI software you use that you are willing to do backflips through hoops, and feel happy about it no less, to accomplish what should be a natural, built-in part of the software you use.

  My choice of open source tools has more to due with the requirements set forth by the client, not any need to avoid ESRI. I’m able to grab tools that I need to meet those requirements and still integrate them in with workflows that are ESRI centric.

  Something very powerful there. ESRI or not is not a point to take away from this project. It is meeting their requirements exactly by using tools that give us the freedom to do what we need with zero overhead.

• 36 Dimitri // Feb 24, 2008 at 1:26 pm

  Let’s have a long posting for a change…

  About the jargon: “COTS” means “Commercial Off The Shelf,” as in a commercial package sold in standard production, that is, not a custom package developed as a “one off” and not freeware.

  James:

  My choice of open source tools has more to due with the requirements set forth by the client, not any need to avoid ESRI. I’m able to grab tools that I need to meet those requirements and still integrate them in with workflows that are ESRI centric.

  Let me translate that into words less fraught with political/religious overtones: “I could not do what my client required me to do with the ESRI tools I had. So I used some other tools in addition to the ESRI tools I had.” That’s the essence of the matter, don’t you agree?

  I understand that you are not saying that you made some political decision to “avoid ESRI”. It is clear that your words simply mean, no more and no less, than the ESRI tools you had did not meet the requirements of your client. So you went out and got some other tools that did. That is your point and I can see that.

  But, why would you reach for “open source” tools with such evident commitment when you could have done the same thing, perhaps even much better, for an utterly trivial cost using COTS software? Could it be that while you will not allow yourself to fall into the mistake of “avoiding ESRI” just for the sake of avoiding ESRI, nonetheless you will eagerly dive into the equivalent mistake of “avoiding COTS” in the case of outstanding, high performance COTS software that happens not to be ESRI?

  You are conveniently ignoring my point, which is that there is nothing about your situation that compelled you to use open source tools instead of, say, COTS tools that are available for free but which do not provide source code access, COTS tools that are expensive but still cheaper than the labor time you expended, COTS tools that are inexpensive and dramatically less cost than the labor time you expended and so forth. Quite obviously, COTS tools available in GIS will enable you to maintain your ESRI-centric workflow. Manifold, for example, is happy to play with SDE data sets.

  Nothing at all about your situation compelled you to use open source tools instead of commercial tools that could have done the same job much better with much lower configuration time required. You can quibble about the costs involved, but I think experienced people realize perfectly well that a commercial tool which costs almost nothing but which saves many hours, days or weeks of time and which does a job much “better” (in the sense, perhaps, that “better” is commonly used in GIS, for example, to mean that it is more performant, more reliable and much easier to maintain into the future) is hands down the wiser choice than, say, an open source toolkit which may be “free” but which costs far more time to utilize and is not “better” at the task.

  If what I write is true, that a package selling for a few hundred dollars could have accomplished all this out of the box, for most people it would have been incredibly unwise to have a) wasted all that money on an ESRI platform that failed in the first place and then b) ignored the opportunity to grab a COTS solution which at an astonishingly low price would have saved them from launching their own mini software development / integration engineering effort.

  Many people would wonder why you would cling to “workflows that are ESRI centric” if dong so requires you to either keep buying other people’s commercial GIS products or to launch your own software development / integration projects using open source modules in an attempt to fill in the holes of what ESRI is not able to do. Even if the COTS products you use are low in cost, and even if you discount your costs with open source, in either case the question naturally arises, to quote your words in a different context, why you would cling to a vendor that does not allow you to meet the needs of your projects directly but instead imposes workarounds upon you?

  ESRI or not is not a point to take away from this project.

  I take the above at face value, but you are asking us to make some logical back flips here unless you know something about “back room” requirements here that you’ve not told us.

  Quite obviously, if your massive investment in ESRI software failed to meet the requirements of the project then it very much is a question of “ESRI or not,” at least as far as this particular project evidences. What other lesson can you take away from this project in the “ESRI or not” department? That your choice of ESRI was correct because it did everything you needed without workarounds? That it didn’t matter that you had chosen ESRI?

  If you could have used a different vendor’s software from the beginning so that your client’s project needs could be served directly without any workarounds, you bet it is a classic example that your initial choice of ESRI was wrong, dead wrong, especially if using some other vendor’s software from the beginning could have saved you lots of money over using ESRI.

  For that matter, suppose you could have done the entire thing from the beginning with open source instead of using ESRI software. In that case also, it would be clear that your choice of ESRI from the beginning was the wrong choice.

  I can understand that if for political reasons, perhaps a pre-existing political commitment to using ESRI you had no choice but to make it look as if the project was being done on ESRI software. In real life, that happens all the time so I agree maybe that is what is going on.

  If that is what is going on in this case, well, then it makes perfect sense to me that you would not want folks to look closely at why on Earth were you using ESRI stuff in the first place and thus got yourself caught in the jam of having to hack up workarounds using open source components, to fill in with such workarounds what ESRI could not do but which any sensible, modern GIS would do from the get go.

  But if that is what is going on, that has nothing to do with a choice between commercial and open source software. It is just a common, grubby case of politics forcing you to make it look like you are working with ESRI stuff when in fact you need to use some other tools to get the job done.

  For that matter, if it is politics in play could that be the real reason you could not choose a more effective COTS package instead of having to jump through hoops with an open source develoment project? Could it be what is really going on is the politics of the matter do not allow you to use a much better COTS package because doing that might make it clear that the choice of ESRI was a mistake in the first place? If that’s what it is, well, I understand that is how it goes. But let’s not use your suffering because of that as a way of somehow suggesting that open source tools in this particular case were as a matter of technical or business efficiency the best choice.

  It is meeting their requirements exactly by using tools that give us the freedom to do what we need with zero overhead.

  James, the point of using whatever toolset you choose is to choose tools that give you the freedom to exactly meet requirements, hopefully with zero overhead. Nothing about that happy ideal points one way or the other between commercial tools or open source tools. Your statement is simply the rather banal one that you should choose the right tools for the job.

  In this case, your initial choice of ESRI tools was not the right tools to give you the freedom to meet the requirements of the job, so you supplemented that by choosing additonal tools, in this case “open source” tools.

  Your statement does, however, for all of its obvious banality does include one massive bear trap just waiting to clamp down upon the unwary: this interesting notion of “zero overhead” you introduce.

  I trust that given your stylish and effective writing style you didn’t mean that literally. I know from meeting you personally that you are an intelligent and insightful guy who is not the sort to be easily fooled the way inexperienced beginners so often are. So, for example, even though you and I have never discussed your background in physics, there is no doubt in my mind that your general experience and intelligence would save you from believing in, say, perpetual motion machines.

  So that’s why there is no doubt in my mind that you know full well that there is no such thing as a perpetual motion machine in software, either, and thus you did not mean the words “zero overhead” literally. I know you know perfectly well there is always overhead of some kind and that it is just a matter of choosing what kind of overhead one prefers.

  So my inference is that by “zero overhead” you meant one of two things. You either meant that to say “OK, I knew I had additional costs but they were bearable.” Or, perhaps you mean that phrase to mean, “I can bury these costs where they will not be seen, because only I know the labor I spent on this.”

  One last thing: nothing about your reported development process in any way takes advantage of the “open source” nature of the tools you used. As far as I can see, you did not do any source code reprogramming of the tools you used. You simply employed them as “black box” modules using their APIs as one normally would utilize any objects or modules provided by someone else. Because in no way did you touch the source code for the tools you used, the “open source” aspect of it did not come into play at all. You could have just as easily been using commercal tools.

  The above points out a common point of conceptual confusion within many “open source” tools discussions. The talk often mushes together in a confused, inarticulate way several different characteristics of software that are in fact quite separate entities:

  Is source code available or not for the software? - There are plenty of commercial packages that make source code available, for maintenence, for education, for customization, to reduce risk through escrow, etc. , and they do so over a very wide range of terms and conditions, from darned near close to public domain to tightly controlled.

  Are you allowed to use this package at all, either in source code or in binary? - Both commercial and open source packages will often place significant limitations on how you can use either the source code or binaries.

  Source code access is not just something unique to “open source” software, and, as the GNU license makes clear, it is not just commercial software that makes source code available with terms and conditions attached. People can quibble all they like about whether the terms and conditions in a particular case are benign or malicious, tolerable or intolerable, nobel in purpose or greedily base, etc., but it is indisuptable that in almost all cases source code provided either for “open source” or for “commercial” products comes with terms and conditions attached. Likewise, in almost all cases there are significant limitations on how even binaries can be used. Many “open” packages, for example, do not allow commercial use.

  [For that matter, if you are working in a commercial setting (you said the word "client" so I assume you might be), you also have the labor/legal cost of parsing the various licensing agreements of the different bits and pieces you have chosen to integrate to see if you can even use those "open source" bits in your commercial application. That is sometimes not so easy, as I invite anyone who is not familiar with OpenLayers to see for themselves: go to the http://www.openlayers.org/ site and see for yourself just how long it takes you to even find a license let alone how long it takes you to figure out exactly the limits of commercial activity you can do with it. This is not easy for someone completely new to that module. I realize that giving the faintest flying hoot about licensing is not something that script kiddies care about, but it is something that responsble folks like James and you, the gentle reader, and I care about.]

  Is the product free of cost? - Plenty of commercial packages are completely free of any licensing cost whatsoever. Visual Studio Express, SQL Server Express, DB2 Express with Spatial Extender and similar are completely free of charge. Conversely, plenty of “open source” packages cost money to acquire, packaged Red Hat Linux to name just one.

  Can the package be freely redistributed? Surprisingly many open source packages cannot be freely redistributed. For example, if you are a “commercial” or “for profit” user in many cases you cannot redistribute or even utilize some of the open source packages, while quite many commercial packages are far more freely redistributable. A “commercial” package, SQL Server Express, for example, is actually free of cost and freer to redistribute than some versions of the “open source” package, MySQL.

  Can you make source code modifications without losing rights? - It is no accident that many “open source” products are copyrighted so that if you do indeed exercise your contracted rights (the GNU license so often used is indeed a contract) to make modifications you can lose other contracted rights you have paid for, typically support rights or the rights to even refer to the modified product by its trademarked name. It is no accident that many successful open source products are developed and controlled by consortia which do not allow just anyone to willy-nilly say that what they have created is that product using the trademarked name.

  All the above play into many cases where people say the words “open source” without having a clue as to what they are talking about, or whether what they mean is “I could download it for free from the web” and not at all access to source code or, even, the ability to lawfully use it for a particular client. For example, surprisingly many “open source” products are not licensed for use in for-profit enterprises, even if the “for profit” is a nice guy like James doing a bit of GIS consulting for a local small business.

  James, in your case you seem to have confused “free of initial cost” with “my access to source code made this possible.” You used the capabilities of the tools exactly as they were. You didn’t invent new tools or extend the existing capabilities of the tools you used, you simply used them as they were. The theoretical availability of re-engineering the innards didn’t play into what you did at all.

  The only thing that mattered was a) what the capabilities were that you needed to fill the holes in your initially wrong choice of ESRI and b) how much would it cost you to fill those holes using the tools you chose.

  For that latter point, I trust no one reading this blog is so incredibly inexperienced as to fail to realize that the acquisition costs of software are usually by far the lowest cost involved in using it. Even in the case of excessively high legacy pricing like ESRI’s, the cost of the software is usually dwarfed by the costs of configuring, integrating, deploying and maintaining the application.

  I wish, therefore, James that in your excitement about your use of “open source tools” in this particular example you would acknowledge that open source code access played no role whatsoever in your utilization and that you did indeed have nonzero overhead, namely the very high labor cost of configuration, integration, application development, deployment and, forever into the future while the application lives, maintenance. [We'll set aside legal costs since many open source advocates routinely ignore them anyway.]

  If the end result works for you, fine. But let’s not have any of this pretense that choosing the wrong tools in the first place followed by a labor-intensive workaround process that ignores all costs except initial licensing is remotely as cost effective as simply choosing the right COTS solution, at dramatically lower cost, which would have given you the freedom to address your project’s needs directly without any workarounds.

  I am no more against the use of open source tools than I am against the use of commercial tools. But I do hope that in either case folks consider all factors involved and that in either the case of “open source” tools or “commercial” tools there can be traps for the unwary which should be considered.

  I would be interested in hearing from James exactly what it was his use of this particular set of open tools allowed him to do that he could not have done with much greater efficiency using a modern, low cost commercial GIS package. He did not use source code access, so we know it was nothing to do with that. What could it have been?

• 37 jonny // Feb 24, 2008 at 8:23 pm

  Could anyone actually read all that. I could only read about 1/5th of it.

  James, lets put this to bed right now. Please list the requirements of your application and then see if Dimitri can recreate it in Manifold. If he can, I’ll buy Manifold - if he can’t, then you should ban him from this blog.

• 38 Dimitri // Feb 25, 2008 at 1:28 pm

  Actually, jonny, I have already pointed out waaay back in the beginning of the thread that all this could indeed be accomplished with Manifold. Thanks also for your generosity of spirit in that people who disagree with you should be banned from conversation. That really shows you have a lot of faith in your views.

  My posting sought to explore meaning of James’ comments, mainly “It is meeting their requirements exactly by using tools that give us the freedom to do what we need with zero overhead,” and how that statement does or does not explain why it makes sense to use open source tools instead of commercial tools.

  I’d especially like to understand why James presented his use of open source tools in a way that seems to indicate he did not think that commercial tools could have been used to solve his problem. I suspect that James simply was very pessimistic because his ESRI tools could not do the job, so I wrote to encourage him not to think that just because the ESRI tools were not up to the task to assume that his only way out was to ignore all other commercial tools.

  I am deeply curious what acknowledged experts like James find useful in “open source GIS.” In this case, is it because James is reacting to the limitations of an ESRI toolset or is it because open source GIS tools have some meaning beyond a reaction to the limits of legacy products?

  But even with experienced, serious people of indisputable good faith like James it has been difficult to nail down exactly why they use open source, because (as can be seen in these recent threads) you get circular reasoning in response to key questions.

  Someone says “I use open source because it is free, it has zero overhead.” I say, “well, it’s not hardly free there are costs involved, plus you know there are plenty of commercial packages that are free and have less overhead.”

  So they say “Oh, no, I don’t mean “free” as in free of cost I mean “free” as in “freedom” to use my source code access to adapt this tool to whatever I need it to do, so that I can meet the needs of my project directly, without any workarounds.”

  And then when I point out, “You haven’t used source code to adapt the innards of what you are using, but instead you are using it just as you would commercial code… anyway, if you had adapted the the source code isn’t that a greater ‘workaround’ than the open doors a quality commercial product would give you?”

  … and that’s when the justification gets back to “But, it is free of cost, you know, licensed through GNU” …and then we go through the whole thing again but with a bit more said about licensing.

  If people play this game of “Oh, it’s that it is free of cost” oscillating with “Oh, no, it’s that it is free to modify the source” they never actually give you a cogent reason why they are using it even though they are implying at both turns a gross misconception about commercial software: either that commercial software has to cost you more or that commercial software can’t ever allow you to utilize whatever modifications you see fit.

  James’ comment:

  “It is meeting their requirements exactly by using tools that give us the freedom to do what we need with zero overhead.”

  …in his usual succinct style has distilled down both such justifications into a single, concise sentence.

  The declaritive purity of that sentence in expressing the case for open source GIS makes it a highly useful starting point to see if the intended meaning holds for most people doing GIS on a day-in, day-out basis. I say that for most people for most tasks on most days neither the ability to modify source code nor the implication that there is zero overhead is true. Frankly, I don’t think it is even true on this particular day for James and his task.

  It could be that James’ use of open source tools for his project was nothing more than the curiosity of a gifted mind that found this interesting, that had a friend who was willing to provide expert technical services free, that this solved today’s problem in an interesting, new way and there was nothing more to it than that. If that’s all it was and there was no intention to suggest that open source tools in this particular instance were any better or worse than commercial tools (ESRI tools excepted, of course, because James has explicitly stated they weren’t up to the task), well, then this particular experience is not the Rosetta Stone that can be used to decode the mysteries of when it is right to use open source GIS tools instead of commercial tools for the masses who are doing GIS.

  In that case, ESRI, MapInfo Pitney Bowes, Intergraph and the like can rest easy, because they need not fear that open source GIS will blow them away.

  I don’t put Manifold in the above crowd because the very low price of Manifold coupled with the very many open doors within Manifold aimed exactly at enabling people to utilize open source solutions if that’s what they want doesn’t make the use of open source GIS tools a threat to Manifold as it is a threat to, say, ESRI.

  Think about it: someone attempting to do a web site to fit into an ESRI-centric workflow as James has done will be plenty tempted to avoid spending tens of thousands of dollars on ArcGIS server and SDE middleware even if it involves a fair amount of labor to configure MapServer, OpenLayers or whatever.

  With Manifold it is not tens of thousands of dollars but a mere $225 for a Universal x64 Runtime, which provides not only the IMS but also direct connection to spatial DBMS and thousands of other features. Someone could merrily utilize open source DBMS like PostgreSQL/PostGIS using OGC WKB, publish out through the IMS to HTML or WMS or WFS-T and all that good stuff for a mere $225. I mean, even if you like spending your time programming there is a certain temptation when pre-packaged, fully integrated applications are thoroughly debugged and maintained for you to simply reach for the off-the-shelf item.

  Which brings me to my final point: I don’t think that miscellaneous utilities or libraries like Proj 4 will either be the most widespread use of open source GIS or even the most influential: it will be fantastic packages like PostgreSQL/PostGIS and (eventually) MySQL. The data warehouse tends to drive everything before it, taking such a role of primacy that even whatever you choose for a GIS package becomes a mere accessory.

  If anything, that was James’ missed opportunity to leverage the power of open source products: it was getting his data trapped in a dumb and obsolete SDE silo instead of doing the most open thing possible and utilizing PostgreSQL/PostGIS.

  Note that here I am far from arguing against open source but instead praising and recommending a very strong, very effective, open source tool, PostgreSQL/PostGIS where it truly makes sense.

• 39 Christopher Schmidt // Feb 25, 2008 at 2:17 pm

  Dimitri:

  To be honest, there are multiple points that I totally disagree with in the previous comment. However, they are simply differences of opinion of someone who feels that the ability to modify the tool he is using — both legally and technically — is important, and someone who feels that that is not important. Ignoring that particular problem at the moment, allow me to get to a question that might make a difference beyond the idealogy:

  Can Manifold provide a customizable web interface which allows for the deployment of geographic vector data on top of Google Maps Satellite Imagery, Virtual Earth Satellite Imagery, Virtual Earth Hybrid imagery/maps, in the browser, such that users can:
  * Select a feature
  * Get attributes about that feature in the web interface
  * Download that feature in multiple formats (specifically, Atom, KML, and GML) for the different tools they might want to view it in
  * From the web interface, edit the attributes of the feature
  * From the web interface, modify the geometry of the feature

  These were, as I understand it, the key features that the customer in question was interested in. The “Web browser” aspect was key: the users who were going to be viewing this are your everyday Joe Users. They were not GIS oriented at all.

  Some of the users who were going to be editing this data were pretty close to this level: they know how to work in an interface like Google Earth, but they don’t have any GIS software, and have never used any.

  And of course, there were ‘real’ GIS users, who had tools they needed to view the data created by the others in their tools, like ArcGIS.

  OpenLayers allowed James (and myself) to build an interface which allowed for the display of data to non-GIS users, the editing of data by non-GIS users, and the use of data by GIS users.

  It allowed (within the terms of use of the APIs) the use of Google Maps and Virtual Earth imagery

  It allowed for the development of a custom web frontend and work flow that worked best for the users in question.

  I’m willing to forget the open source zealotry for a minute if you are: The key thing was the ability to build a custom application, quickly and easily, based on commonly used web tools, that did what we needed.

  Perhaps this would be simple with Manifold, I’m not sure. To be honest, I thought that Manifold was a desktop appliction: I didn’t know that it had (or could be set up as) a server to provide data to OpenLayers other than through the “IMS”, which I thought provided images, not vector data. If I’m wrong, it’s possible that a Manifold based server would have been better than FeatureServer in some cases. However, I don’t see in your licensing options what I should be buying… and that still doesn’t necessarily solve the web client problem.

  If your statement is “James’s users might have been better off using GIS software to do all their GIS work, instead of working in a web browser” — you’re making a mistake on the target audience of the tool that we built. The key portion of the project was that the end result be viewable by users on the customer’s web site as a draggable map that would allow users of the site to see information about geographic features in an area (including attributes about them) as a dynamic map, without any tool other than a web browser, and that key piece of technology doesn’t seem to be present in Manifold, unless I’m missing something. Can you tell me where I’ve gone wrong?

• 40 Dimitri // Feb 25, 2008 at 5:01 pm

  Christopher:

  I appreciate the sincerity and clarity of your posting. You make it clearer what your mission was with James so I now better understand why you went the way you did.

  My thesis is about making choices and striking a balance between commercial tools and open source tools - it is not about Manifold as a specific package so it is important when Manifold is used as an example not to allow that to cloud the general conversation about balance between commerical tools and open source tools.

  But I do agree that it is sometimes very useful not to keep discussions totally abstract and to call upon specific examples or counter-examples. In that spirit, I use Manifold because I am most familiar with that GIS. If someone says “oh, you can’t do that with commercial software” and I can cite a precise example of doing it in Manifold, I just do that as a concrete example and not, not in any way, suggesting that you could not also do that with other commercial tools.

  So in that spirit let me respond to your specific questions:

  Can Manifold provide a customizable web interface which allows for the deployment of geographic vector data on top of Google Maps Satellite Imagery, Virtual Earth Satellite Imagery, Virtual Earth Hybrid imagery/maps, in the browser, such that users can:
  * Select a feature
  * Get attributes about that feature in the web interface
  * Download that feature in multiple formats (specifically, Atom, KML, and GML) for the different tools they might want to view it in
  * From the web interface, edit the attributes of the feature
  * From the web interface, modify the geometry of the feature

  Yes, of course. There are many ways of doing *all* of the above within Manifold depending upon the preferences of the web architect. Manifold, whether utilized as a desktop application, as an objects library or through the IMS objects is highly customizable and people do that sort of thing all of the time. In fact, if you view the various IMS tutorial examples (deliberately kept simple so that the particular focus of each can be understood) you’ll see examples of programming various parts of the above.

  In fact, from James’ postings there is more to your task than the above and that is to achieve a dynamic connection with SDE geodatabases, which Manifold can also do.

  For the sort of application you describe, you’d probably use the WFS-T (OGC feature server with transactions) capabilities of Manifold IMS. I personally think there is a better way (see below) but there are many people within the Manifold community who disagree with me and who prefer serving vectors. In fact, folks like David Brubacher (who gave a talk at the recent user gathering in Phoenix) are actually basing new products on the idea of AJAX feature serving using Manifold IMS.

  Note that since Manifold can dynamically link drawings from an SDE geodatabase you could indeed create a web site that enabled clients through WFS-T to view and edit features with the post-back edits quite literally manipulating features (such as adding, deleting, editing parcels, etc.) within your SDE geodatabase.

  My only caveat is that what you download those features in would be by default in one of the 80 GIS or DBMS formats such as KML, which Manifold writes to (it is immensely popular as a KML editor to create Google Earth content) but not to formats like Atom which no one uses for GIS data. It is difficult to find a serious GIS package of any kind which cannot read one of the commonly used GIS formats, such as shapefiles, so if interchange with other GIS tools is what you ask, yes, sure. I believe one of the published tutorial examples allows drawing a selection marquee and then downloading a shapefile with the selected contents. [Folks with strong tastes and programming skills could, of course, run the output of Manifold into their own tool for massaging into whatever format they liked for download.]

  The “Web browser” aspect was key: the users who were going to be viewing this are your everyday Joe Users. They were not GIS oriented at all.

  Some of the users who were going to be editing this data were pretty close to this level: they know how to work in an interface like Google Earth, but they don’t have any GIS software, and have never used any.

  And of course, there were ‘real’ GIS users, who had tools they needed to view the data created by the others in their tools, like ArcGIS.

  OpenLayers allowed James (and myself) to build an interface which allowed for the display of data to non-GIS users, the editing of data by non-GIS users, and the use of data by GIS users.

  That’s an extremely common situation with users of Manifold. Really, you’ve described something which is typical of just about every town, county and state worldwide, where a mix of desktop GIS, enterprise GIS and IMS is required. That’s why all this stuff is in Manifold.

  Just about every organization that works in a significant way with GIS data has exactly that cast of characters: a relatively small percentage of people actually “do” GIS while most members of the organization simply view the results of doing GIS. Distributed, enterprise GIS functionality on clients takes care of the first class of people while publication via IMS takes care of the latter.

  By the way, even though you can use Manifold very effectively to accomplish the architecture you described, just because you can do it that way doesn’t mean it is the only way or even the best way.

  Our internal research indicates Manifold in IMS uses out-installs ESRI by over 100 to 1. It is not even close. That is not a very surprising fact when you consider that someone can deploy Manifold IMS for as little as a $100 Professional Runtime license [which, by the way, includes full HTML, WMS, Image Server and WFS-T capability... and for 64-bits to boot...] so there are a heck of a lot more people who afford to run IMS with Manifold than by forking over the cost of ArcGIS Server or ArcIMS. In fact, quite a large percentage of folks who buy Manifold with no interest whatsoever in IMS end up putting up an IMS site all the same, simply because all Manifold licenses except Personal include IMS. If you spent $295 for a regular Manifold license for your desktop and you discover that you can put up an IMS set with no further purchases required, well, quite a few people do.

  My point is that we have a *lot* of people using IMS and those folks are not at all shy about telling us what they want to do and how they want to do it. Here is some of what they tell us:

  Experience shows that when people publish IMS sites for totally inexperienced colleagues, they usually find out that their audience sifts out into two classes of users:

  First, those who simply want to view, get attribute information, make selections, run queries, maybe grab something off the site for download, etc. These people are mainly consumers of data sets even if they run lightweight analyses against that data and even if they are making lighweight contributions to the data set (such as, contributing point data, editing/updating attributes, etc.).

  Second: Those folks who want to edit the geometry of the underlying data set. An example would be clerks in the county office who need to edit the shapes of parcels or add new parcels or to edit the boundaries of the county.

  Regardless of what toolset you use it is pretty easy to satisfy the first group of users. The second group, however, quite rapidly become more sophisticated than they were at the beginning and once they get a taste of “hands on” work directly on a non-timeshared machine that’s all they want.

  Once people get a taste of the incredible density of capabilities and raw speed made possible by editing “in the box” they usually don’t think much of editing through the web no matter how sophisticated the interfaces you present.

  In the legacy GIS world, folks can’t afford to do that and are stuck with time-sharing (which is what your architecture is) because they can’t afford the cost of effective software to take advantage of distributed processing. But if the cost of such software is very low, people can take advantage of distributed processing.

  So, although there are of course exceptions championed by folks who prefer a web-based architecture, the great majority of Manifold installations in larger organizations tend to be as follows:

  An enterprise DBMS, usually a spatial DBMS of some kind, is used as the central data repository. Oracle and SQL Server are hands down the most popular choices.

  Folks who create data sets and maintain them, for example, editing parcel drawings, connect to that DBMS using Enterprise edition Manifold licenses and execute Manifold on their desktops as a super-rich client to the DBMS. Thousands of people can edit the same large drawing at the same time with automatic identification and resolution of editing conflicts. The cost of Enterprise Edition in volume can be very low, under $200 a seat or even less if License Server is used so that floating licenses can assure that no license need be purchased for seats that go unused.

  Manifold running as IMS sits on web servers also connected to the central DBMS to publish data to intranets and to Internet. Usually, the intranet applications allow some degree of editing or querying that is greater than the Internet applications. If people want to download data via intranet or Internet into local storage, that’s rigged into the application to allow such downloads.

  Yeah, sure, people do simple editing through the web all the time. But for significant editing they tend to reach for a super-rich client (Manifold) with a direct connection to the data warehouse. It’s not because they can’t do web editing (people do that all the time with Manifold) it is because they prefer a non-timeshared, super-rich local client much better. And, by the way, the less experience people have with GIS tools the more the above scenario tends to hold true.

  For that matter, many applications developers prefer the configuration of a local client (Manifold is highly customizable, allowing elimination of menus you don’t want newbies to see, allowing adding of add-ins and pre-built queries and scripts to custom toolbar buttons, etc.) to cobbling up and maintaining “editing through the web” applications.

  I think a good example of the above was the presentation at a recent user conference by Robin Wood of ScanControl on his company’s tools for vineyard management, as currently used by Kendall Jackson (KJ) and many other large wineries.

  When you are running 50 vineyards plus winemaking facilities spread out over hundreds of square miles you have a lot to keep track of. KJ keeps track using detailed maps of individual vineyards. The law requires them to keep track of every application of chemicals and even who did the application. KJ wants to know, with hundreds of attributes, exactly what cost and labor inputs have gone into individual, different parts of vineyards so that they can see with very fine resolution what is productive and what is not, what makes good wine and what does not work so well.

  ScanControl runs everything on a SQL Server DBMS. Field workers, some of whom have not even touched electronic equipment before, carry smart phones with embedded camera, GPS and a suite of small apps. They also carry a bluetooth, pen-sized barcode scanner.

  They can call up all sorts of pre-built forms, choose from pulldown menus, scan the barcodes of employees and chemicals and locations, make notes on what they do, take pictures of vines or grapes or whatever, and all that gets automatically replicated into the DBMS servers.

  ScanControl used to use richer PDAs and spent a lot of effort on in-the-field editing only to discover that by far that stuff was better done in the office with field staff collecting data not by editing parcel shapes in the field but instead by using rich sets of tools to edit attributes, take pictures and the like.

  In KJ and contractor offices worldwide, people have Manifold running connected to the DBMS to do all sorts of sophisticated work and queries and editing. Someone takes a picture of a sick vine in the field and an analyst sitting in France or Australia or California can click on the icon in the Manifold display to view it, and immediately send off instructions “dial back the irrigation…” or whatever.

  They also publish data out to the field using IMS, so that foremen or more sophisticated users can cruise along looking at the fields around them through thematic presentations that they can call up: what needs watering, what the work ticket is for this plot, all that stuff.

  Because the application is tightly integrated with SQL Server, all the rest of KJ’s management suite works as well. KJ knows the content origiun of (literally) every bottle and they know their financials (inventory, revenue from, etc.) on every bottle as well. So they can instantly create thematic renderings of any property they own to see in fine detail which vineyards are most productive or best for a particular purpose. That allows them to invest resources where they do the most good.

  The above is a very typical application that really doesn’t use anything but HTML and some cell modems in the smart phones. I give it as a real-world example where less-experienced GIS data consumers usually do better when working with a simplified interface, and also to point out that you don’t always have to use a limited set of web interfaces like feature servers, it sometimes makes better sense to connect directly to DBMS with either super-rich or thin clients.

  Perhaps this would be simple with Manifold, I’m not sure. To be honest, I thought that Manifold was a desktop appliction: I didn’t know that it had (or could be set up as) a server to provide data to OpenLayers other than through the “IMS”, which I thought provided images, not vector data. If I’m wrong, it’s possible that a Manifold based server would have been better than FeatureServer in some cases.

  Manifold is not just a desktop application. The same package can also serve images (in a variety of ways: HTML, WMS, image server) or vectors (WFS-T).

  However, I don’t see in your licensing options what I should be buying…

  ESRI (and much of open souce) use a non-integrated approach to web stuff: you need an editor like ArcView or ArcInfo to whip your data into shape interactively, an ArcSDE thingy to talk to DBMS, an ArcObjects thingy to program stuff and an ArcGIS Server thing to publish to the web. And all that stuff was written by different teams on different schedules using different object models.

  Manifold incorporates all that into a single application. The case for doing this is at

  http://www.manifold.net/info/ims_top_ten.shtml

  Therefore, you buy Manifold IMS by getting any Manifold edition except Personal edition.

  I’d recommend any edition from Enterprise ($395) on up. Although Professional ($295) also includes IMS, I suggest Enterprise because Enterprise vastly expands the utilization of spatial DBMS and it is only $100 more.

  For deployment onto a web server you’ll need either a Professional x64 runtime at $100 per server (one price no matter how many processors, no matter how many web sites you serve, visitors, connections, etc.) or Universal x64 runtime at $225 per server. The Universal runtime is basically an Enterprise license plus Business Tools, Geocoding Tools and Surface Tools extensions. It is so inexpensive that folks pretty much automatically deploy using Universal just so they know they have it all.

  There are no maintenance fees. Updates providing bug fixes are free within a given release level to all licensees. About once a year a major new release comes out (hundreds of new features and improvements) and that new product is traditionally offered to licensees of the previous release for a flat fee, usually about $50.

  and that still doesn’t necessarily solve the web client problem.

  Well, it is only a problem if you make it a problem! Seriously, whatever WFS-T server you use you will need a WFS-T compatible client. Use the same one with Manifold.

  But better still, consider my remarks that if you genuinely need any sort of significant polygon editing you could well do much better to simply toss a full Manifold license onto the users’s machine and utilize a direct connection to the DBMS. It’s up to you either way.

  The key portion of the project was that the end result be viewable by users on the customer’s web site as a draggable map that would allow users of the site to see information about geographic features in an area (including attributes about them) as a dynamic map, without any tool other than a web browser, and that key piece of technology doesn’t seem to be present in Manifold, unless I’m missing something. Can you tell me where I’ve gone wrong?

  Yeah, sure Manifold can do all that.

  Where have you gone wrong? Well, you haven’t really, except only in the case that as technology improves we are all going to have the pleasure of seeing newer and more cost-efficient things surprise us as they pop up. That’s a good thing.

  Especially at a time of rapid technological evolution we can’t all be experts on all applications, especially exceptionally broad and deep ones like Manifold that come at you with an evolutionary path of around 1000 improvements a year. Look away for a few months and it has grown more than ESRI did this last decade, so yeah, sure there will be surprises.

  It’s also human nature to try to understand the world in terms of what we already know, and ESRI is not exactly eager to tell ESRI users just how far behind they are. If you have spent 20 years going to user conferences in San Diego and being told that you need to buy separate, psychotically-expensive packages like the ArcGIS suite and ArcGIS Server you would not expect that you could do much more than all that for around $500 with a single integrated package.

  I had lunch with one of our phone folks today who told me about a call he had this morning. A guy had spent $180,000 on an Enterprise ArcView license and was looking to bid a job using Manifold for an IMS application. The thing that astonished this caller was that for $425 (Enterprise Geocoding Tools bundle) and another $225 for the web server he could for well under $1000 have everything he needed to develop a very rich spatial DBMS application front-ended by however rich an IMS web site he cared to create. He was surprised by that given what he had already spent on ESRI. So you are not alone in your reaction.

  However, in all fairness to the mainstream, though, we don’t get that same reaction from the zillions of Microsoft mainstream people who buy Manifold. None of them have been exposed to the notion that they should have to pay tens of thousands of dollars to get an IMS site up. Tell those folks it is $225 a server for Universal x64 runtimes and they’ll ask, “Wow… that’s a lot… How do I get a better price?” … my kind of people!

• 41 Christopher Schmidt // Feb 25, 2008 at 7:32 pm

  Dimitri:

  Just so you know, I personally give up about halfway through reading your comments most of the time. Being a bit more concise might help others like me who are lacking long attention spans to work their way through your arguments.

  I’m going to try to respond where I can, but I’ll point out that FeatureServer was a handy part of the equation above, but there’s no strong reason it was chosen other than “It was there”.

  The key part of the application is the web frontend (at least, as far as I’m concerned) — the FeatureServer chunk was unimportant. And it doesn’t sound to me like Manifold IMS really changes the situation (other than forcing the use of WFS-T over a RESTful web-oriented architecture for feature editing, I guess?) — there isn’t an out of the box web editing application shipping with Manifold, you have to put it together yourself. (I could be misunderstanding you: I apologize for confusing the issue with bringing up cost, which isn’t really relevant.) It sounds like what you’re saying is “Sure, you can use OpenLayers with Manifold, but you’ll have to write that frontend” — in which case, Manifold wouldn’t solve any real problems either way.

  There are examples of how to do it: great. FeatureServer comes with an example of how to deploy it, along with OpenLayers, to edit features, though the easiest way to deploy it (If you have the most widely targeted setup) is to simply unpack the tarball in your webserver directory and visit the directory in your web browser, since it ’ships’ with an OpenLayers-based example for editing features and attributes pre-configured.

  There are cases where running Manifold for this would make sense. I can’t speak entirely to the cases where it does or doesn’t. However, this problem was pretty simple from the point of view of the server — we grabbed FeatureServer because it ended up doing what we needed, and being trivial to integrate with OpenLayers. (Does the Manifold gallery have OpenLayers examples? If not, I’d recommend ‘em. I’d check myself, but I couldn’t find it, though I’ll admit that if it wasn’t attached, I often wouldn’t be able to find my own head.)

  Building the client seems to me to be a one-off task either way, and that one-off task is the one that mattered. Although James concentrated here on the fact that FeatureServer already did what he wanted — mostly because that’s the impressive part — the part that really mattered was the fact that it went into OpenLayers trivially, since that’s the ‘hard’ part of this particular problem.

  You mention “You’ll need a WFS-T client either way”… but we’re not working with WFS-T here, we’re working with a totally different type of editing. I’m not aware of any good web-browser based WFS-T editors. OpenLayers isn’t one (though you could make it be one), primarily because WFS-T is ill suited for web-based editing.

  Does the Manifold IMS ship with a web-based WFS-T client out of the box, with support for editing on top of Virtual Earth and Google Maps? If so, is it really a key part of Manifold, or could we seduce you into sharing with OpenLayers and helping improve web-based editing for everyone? I’ve limited experience with web-based editing outside of my narrow open source view: in general, I’ve not been impressed, but maybe I’m looking in the wrong direction. Still, if Manifold is maintaining its own web-based editing toolchain, it might be able to benefit from OpenLayers; I can go into that more if you’re interested in how it could help you (even if you don’t want to help OpenLayers out). The license (which I’m not sure why you feel it’s hard to find: it does say on the homepage of the project “Released under the BSD license”) makes it perfectly easy for you to steal the code and offer nothing other than a line that says “Includes OpenLayers” in your documentation.

  Anyway, I was just a contract guy. I was asked if I could do a job, and how much I could do it for. I quoted a number, and an implementation. It’s the only one I can put together: I don’t have access to any computers I can install Manifold on. OpenLayers and FeatureServer both worked great. They both got some new features — which are now fully supported, and no one will have to pay for them in the future, if they want them. The OpenLayers community also benefits, and extended some of the work I did even farther, so the limited amount of money that was invested paid out more than it might have otherwise.

  Although I appreciate your concentration on the area you know best, and I agree that I’m doing the same, it sounds to me like the tools we used weren’t the wrong ones (though there are obviously alternatives). Which brings the entire disagreement down (in my mind) to being over the value of Open Source: with that in mind, it’s probably best to declare it a truce and move on, since using Open Source software has a significant benefit to its users that is in the ideology, and if you’re not convinced, there’s no need to try to become convinced (as far as I’m concerned, anyway).

• 42 Joshua Zeidner // Feb 26, 2008 at 11:05 am

  hello,

  I just wrote this article on a related subject:

  http://zeidnertechshowcase.blogspot.com/2008/02/data-security-and-google-member-maps.html

• 43 Nils // Feb 26, 2008 at 11:55 am

  I’m hesitant to add to this lengthy blog but here it goes. My question, or argument, is this: where does the cost associated with the learning curve come into play? As far as I can tell all of the open source solutions I have seen are pretty much figure out how to use it and implement it on your own. They may have a website with some minimal documentation, but I have not seen much instruction on how to use a particular solution. I know there are smart programmers out there that can figure things out, but shouldn’t that be included in the cost of implementing such a solution? Say what you want about ESRI but there is a wealth of documentation, books, courses, and support.
  My company is evaluating different solutions for evaluating different map serving/enterprise GIS technologies and currently we are struggling with the cost of learning to use the different solutions. This also leads to my next question: as a consultant how do you deliver a solution based on various toolkits/APIs that the client is unfamiliar with? Are they comfortable getting something that no body in their organization has experience with? What happens when it breaks or they have to modify it in someway? Do they have to call you for support? Maybe that’s the beauty of it.

  Don’t get me wrong I am not arguing for one way or another. I am just looking for answers to my questions.

• 44 Dimitri // Feb 26, 2008 at 1:11 pm

  since using Open Source software has a significant benefit to its users that is in the ideology, and if you’re not convinced, there’s no need to try to become convinced (as far as I’m concerned, anyway).

  I agree with you 100% that ideology is why some people, perhaps even many people, pursue open source solutions. That is exactly one of the points I set forth in that famous letter to the editor.

  But as much as I agree with you that a key benefit gained by open source users is identification with a particular ideology, that is a psychological and social matter, not a case for operational efficiency. For that matter, I think acceptance of ideology without a sound, pragmatic case for why that ideology performs in real life better than alternatives is the way one gets into dead ends. Launching into a life based upon ideological slogans like “From each according to his ability and to each according to his need” without first considering whether it was possible to map such slogans into practical reality is exactly how the beloved homeland of my people ended up enduring 70 years of communist ruin.

  I say that if you are a true friend of open source you reject mere ideology and you insist on hard headed arguments that in every detail make a common sense case why your approach is significantly better. That is the way to make open source stronger, because it rejects the slothful, slacker path of confusing slogans for competitive value. If you don’t have a significant reason for being beyond the appeal of a stylish, but squishy, ideology you end up getting marginalized by other approaches which do have enduring, real value.

  Being a bit more concise might help others like me who are lacking long attention spans to work their way through your arguments.

  Well, sure I could be more concise if I didn’t have to lay out an argument on your side as well as mine!

  Seriously, getting open source folks to explain exactly why what they are advocating is better than a commercial approach is like nailing jelly to a tree. The open source guy lobs up some jelly in the form of a statement like…

  It is meeting their requirements exactly by using tools that give us the freedom to do what we need with zero overhead.

  …and then one has to spend endless paragraphs unfolding exactly what the above means, trying to nail that jelly to the tree. I mean, if I am to respect the intelligence of readers I can’t just reply or “oh, there’s no zero overhead” or “oh, you’re just assuming your conclusion” because then it is not a mature discussion but rather a decomposition into an exchange of sound bites.

  Speaking of “assuming your conclusion” I think you are doing that here. Consider:

  And it doesn’t sound to me like Manifold IMS really changes the situation (other than forcing the use of WFS-T over a RESTful web-oriented architecture for feature editing, I guess?) — there isn’t an out of the box web editing application shipping with Manifold, you have to put it together yourself.

  Pausing a moment to note that the out of the box editing application is Manifold itself, let me now get into why the above is “assuming your conclusion.”

  If I understood the description of the client correctly, they wanted to be able to edit features in an SDE geodatabase and to do so on the desktop as well as on remote desktops, to be able to publish their data for viewing to a larger audience on a web site and also to be able to download selected parts of the data set for local editing by local tools. That is the task.

  If your clients are indeed non-GIS people, then I’m sure they did not come to you by saying “I want a RESTful web-oriented architecture”. They simply said “I want to have remote access to my data, to see what it contains, and to edit it.”

  I agree that when someone comes and says something like the above to a consultant who is predisposed to “open source” (whatever that is) as a matter of ideology it is often the case the consultant will hear only what he wants to hear. If he is driven by ideology rather than optimal solutions, he may well indeed hear the client say “I want to use only open source tools, it cannot have anything to do with Microsoft, it must be web centric and it cannot have anything to do with commercial companies except Google and SUN and Red Hat, which I think are cool, and it must interoperate with stylish but dumb standards that no one in the mainstream uses, like OGC things, for example GML.” And then when you ask the consultant why he did what he did he replies, honestly, “that’s what the client required” when in contrast it was not what the client asked but rather only what his ideol