Posts Tagged web
Changing selection colour in MapGuide AJAX viewer
Posted by Jason Birch in MapGuide, OSGeo, Open Source, Tutorial on December 2, 2008
One of the annoyances that people have faced with MapGuide Open Source is that the selection colour was hard-coded in one of the C++ rendering functions. There were a few ways of getting around this without recompiling, but they were all a lot of work. RFC 38 included some code changes that made it possible to modify this value on the fly, but it doesn’t look like this capability was taken advantage of by the AJAX viewer that was distributed with MGOS 2.0.x.
If you’re using MapGuide Open Source 2.0 (2.0.2 recommended) and are not happy with the default blue selection colour, you can easily change it on a per-install basis by modifying the mapviewerajax template file. This is located at:
(INSTALLDIR)\WebServerExtensions\www\viewerfiles\ajaxmappane.templ
You will need to find the function called RequestMapImage, which includes a line that looks like this:
url = webAgent +
"?OPERATION=GETDYNAMICMAPOVERLAYIMAGE&FORMAT=PNG&VERSION=1.0.0&SESSION="
+ sessionId + "&MAPNAME=" + encodeComponent(mapName)
+ "&SEQ=" + Math.random();
You will need to modify this to change the VERSION to 2.0.0, and add the BEHAVIOR and SELECTIONCOLOR parameters:
url = webAgent +
"?OPERATION=GETDYNAMICMAPOVERLAYIMAGE&FORMAT=PNG&VERSION=2.0.0&SESSION="
+ sessionId + "&MAPNAME=" + encodeComponent(mapName)
+ "&SEQ=" + Math.random() + "&BEHAVIOR=7&SELECTIONCOLOR=FF5300FF";
Before:
After:
The BEHAVIOR parameter is a bitmask that controls what is rendered, and is described in RFC 38. The SELECTIONCOLOR parameter is a hex string in RGBA format, or its integer equivalent. Note for geeks: the A (opacity) portion of the string is ignored; the server code masks this out of the passed value, and then adds 200 (C8) as the line opacity and 160 (A0) as the fill opacity.
Note, the mapagent call allows you the flexibility to add more complicated behaviour to your viewer, such as changing the selection colour dynamically based on the map name, but I’ll leave that as an exercise for the reader (mostly because I’m lazy and use Fusion anyway and wouldn’t benefit from the work).
-J
OpenSocial: scope of disruption
Posted by Jason Birch in Google, Loose Integration on November 2, 2007
If you’re only looking at adoption by the players like MySpace, I think you’re missing the big picture.
Sure, buy-in by these sites is going to push adoption of the APIs, but for me the real value is that this extends social capabilities beyond the sphere of these "container" sites to the entire web. If you read the Google OpenSocial FAQs, nowhere do they say that its goal is to enhance sharing between portals. In fact, they explicitly say:
This is an effort which we hope will benefit the entire web community. [...] In the future, we are planning to open-source the components that are required to run OpenSocial on your own website.
The code hasn’t been released yet, but the docs make it clear that this vision has merit. OpenSocial uses gData, AtomPub, and a whole lot of REST goodness to allow any website to implement interactive social capabilities.
I see this taking off quickly in blogging (FriendBlogRoll,etc), but I also see huge potential for things like distributed social mapping. Take a look at what Google has done with its Put Yourself on the Map capabilities. That’s pretty cool on an individual mapping level, but imagine extending that out to community maps, implemented similar to the concept of “Groups” on Facebook. Encapsulate some GeoRSS in gData (via Sean) and how hard would it be to build an OpenSocial system where "friends" can all interact with the same map through their interface of choice? OpenSocial is already geo-aware to some extent; the People data includes a GeoRSS GML Point element to locate individuals!
OpenSocial has incredible value for traditional web sites as well. I’ve been considering several different applications for my hobby website (I built this Drink Recipes website in college, and it’s stuck with me since) such as "tell a friend", "friends favourite drinks", etc, etc. All of these could be built as plug-ins for OpenSocial-enabled sites (and of course as an additional plug-in for Facebook), but they can also be exposed on the main website, turning the whole web into one big social network.
One area that I don’t really understand is how OpenSocial deals with distributed authentication. It looks like you can either authenticate locally (through user/pass) or through Google Accounts using AuthSub. I don’t know a lot about this area, but I really think that this may need to be extended to authentication methods like OpenID.
-J
User Map
Recent Comments