I too looked into Hadjieleftheriou's Spatial Index Library before settling on shapelib's quad tree (for Quadtree). My C++ chops are a bit flabby these days, and Frank's C code is very easy to work with. Given my limited time and minimal requirements, the choice was obvious. Now, I'll definitely be looking into the QGIS R-tree implementation.
Jason Birch points out new MapGuide Open Source demos that beg to be compared against the ArcGIS Server ADF demos. I spent a few minutes trying out the three generic tasks and must say, this is more like it. Autodesk is employing some UI and graphic designers. They haven't found the sweet spots yet, but are closer than the ADF team. They need to drastically reduce the number of mouse clicks needed to theme a layer -- the color picker is particularly painful to use. The markup task is poorly named (HTML is markup), and almost useless. The larger goal is to share placemarks (or lines, or polygons) with other users across applications. Why jail them inside MapGuide? The feature query task ought to support more complex multi-property queries, and the polygon digitization tool is a nightmare (The ADF's performs much better).
The browser swamp is a rough home for GIS applications. One of the keys to success is putting swamp dwellers to work on an application. In theory, MapGuide Open Source has the edge: there aren't any proprietary barriers to the participation of a PHP or Javascript savant. I suspect that ESRI prefers to retrain its desktop developers for swamp duty. (This suspicion is based on an article -- which I found via Jeff Thurston, and can not now find at all -- where an ESRI technical lead spoke about the pressing need for strong typing in Javascript.) I'm betting on the swamp dwellers.
Author: Jason Birch
I wouldn't spend too much time looking at the UI for those samples; they're primarily meant as API examples that developers can use to build truly useful applications. Personally, I'm tossing the default UI and using Fusion (based on Chameleon) instead. This will allow me to make poor UI decisions and take personal responsibility for them :) The important part (to me) is that all of the functionality that is behind those samples is part of the native MapGuide API. It's still a bit early in its life, and there aren't many real world apps out there yet, but I can't wait to see what kinds of things people do with MapGuide as it picks up steam. Not that I'm biased or anything... JasonIt's an improvement over the abysmal ArcIMS client, for sure, but is less impressive than all the hype suggested. The HTML table of operation panes looks and feels clunky. Reordering the panes conflicts with Firefox's right-click menu. The scale bar is nowhere near as sexy as Tim Schaub's (in PrimaGIS and OpenLayers), and the scale slider is nowhere near as smooth as the one in Google Maps. I was expecting it to feel more usable and look more appealing.
Author: dylan
Hi, I posted this on the blog in question, but I see that it was since edited out. The ADF application doesn't work too well on a mac: with safari or firefox, with JS errors and the like. Last night I wasn't even able to see the TIN. This morning I was able to see the TIN, or rather the tiled version of a TIN, however none of the analysis worked. Frankly, I saw better response times from the experimental pywps project! (https://wald.intevation.org/projects/pywps/ ) Cheers, DylanAuthor: Sean
Dylan, I see a comment on that blog attributed to you. Comment scrubbing is a pretty strong accusation. Are you sure?Author: dylan
ikes! thats egg on my face. I must have missed it. apologies to all involved. DylanThere is a request in comments for more details and examples of declarative programming with MapServer. Before I elaborate, I must stress that I'm advocating a new-ish, different way of looking at MapServer. It's not widely recognized that the instructions encoded in a MapServer mapfile comprise a domain-specific language. (Norman Vine, for one, gets it.) The reference itself is concerned only with the content of a configuration file, and doesn't acknowledge the existence of a language. Like it or not (and I do have my issues with the syntax and semantics of it), there is a map language. To embrace the map language is to benefit from simplicity, usability, and portability. Now, don't misunderstand, there's nothing inherently wrong with imperative programming. The problem is that imperative mapscripting exposes its practitioners to the many rough edges and pitfalls of MapServer's internal API, and produces less than portable applications.
Author: Tim Schaub
Thanks Sean. None of that was obvious to me until described that way. You'll certainly forgive those of us who stumbled into mapserv, immediately found limitations, and jumped to mapscript for the flexibility. Writing mapserver patches is a whole lot more intimidating than writing (smelly) mapscript work-arounds. Until the restrictions you mention are lifted (and more), mapscript will continue to provide an efficient (if not always elegant) way to get things done. Perhaps your advice would be "something missing in mapserv, shp2img, etc? jump on the development team." This is not a practical alternative for folks who need to deliver something next week. I'll take the advice to limit imperative (mapscript) programming and appreciate your ideas.Author: Homme Zwaagstra
I agree that the declarative approach has much to be said for it, and would be much more useful if mapserver (including mapscript!) was open to mapfile input from non file based sources (e.g. mapfiles could come from standard input, or strings). Practicality, however, is often a balance between extremes. In this case initial mapfiles can often be created using your favourite templating/text-based approach. Mapscript sessions can then be instantiated with these mapfiles (saving much imperative drudgery) and used to tweak the map as required.