An Update on Working with kaMap
Hm, turns out I do have something in common with Britney Spears. I code like she dances. Quite a while ago I decided to put kaMap in between the user and Mapserver on a bunch of different projects (including a simple Wabash River (Indiana) orthophoto scanning project and a very alpha soil survey digitization application. Why? I like what kaMap purports to do and of all the options (OpenLayers, [shudder] ArcIMS, etc.) it made the most sense to me. But the problem is that I’m a librarian, so coding is not really my forté.
…Which I suppose is like saying parenting or singing or career management is not the forté of Spears. If Spears:child->Me:code, then we share the same disinterest in our children. I guess it would follow, too, that if I were a smoker I would smoke in the face of my code as she did her hers.
But with great help from my two grad assistants, the thing is coming along enough that we’re building dynamic layers from data in at least two separate postgres servers located in completely different places. Does that count as geoinformatics? Let’s say yes. Anyway, I have a decent-looking interface, but more importantly we’ve been able to work around strange problems with MapScript in kaMap to alter pretty much anything we want on the fly. Querying has been more of a problem, but we have workarounds for that, too. Rough ones (involving a near-invisible index layer used to then re-query PostGIS to get the values from the real feature classes), but we are able to query on PostGIS layers, present results, and launch little overlay layers (xmlOverlay) that identify, by click, individual geometries pulled by the query. I’m clinically stupid when it comes to coding and development, but even I recognize how important having access to the source code for this stuff really is, and even I was able to get in and fix some stuff.
So thanks, people who developed kaMap, we’re going to stick with it.
