| 8 | | !MapGuide and Google Web Toolkit [Mentor: Simon Pelicon (Haris Kurtagic)]::[[BR]] |
| 9 | | [[BR]] |
| 10 | | Develop !MapGuide Java AJAX viewer using Google Web Toolkit framework. |
| | 5 | === Web Studio Enhancements === |
| | 6 | |
| | 7 | [Mentor: Paul Spencer] |
| | 8 | |
| | 9 | This project entails working with AJAX techniques to make a number of improvements to !MapGuide Web Studio, including adding support for all FDO providers (generically), color selection tools, map thematic generation logic and user interface improvements, etc. |
| | 10 | |
| | 11 | === !MapGuide and Google Web Toolkit === |
| | 12 | |
| | 13 | [Mentor: Simon Pelicon (Haris Kurtagic)] |
| | 14 | |
| | 15 | Develop !MapGuide Java AJAX viewer using Google Web Toolkit framework. |
| | 16 | |
| | 17 | === !MapGuide Web 2.0 Enhancements === |
| | 18 | |
| | 19 | [Mentor: Jason Birch (if nobody else volunteers)] |
| | 20 | |
| | 21 | While !MapGuide's support for enterprise standards (OGC), and KML is well established, there are several areas where we could take a leading edge stance. These enhancements all around Web 2.0 data interchange techniques: Tile Map Service (TMS), GeoRSS, and REST-based feature retrieval. These could be initially written as PHP scripts and then brought into the core code base if desired at a later point. |
| | 22 | |
| | 23 | ==== TMS ==== |
| | 24 | |
| | 25 | The [http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification TMS Specification] provides a well documented method for sharing pyramid-based map tile caches between multiple mapping applications. This scales to public use much better than WMS, and allows extension of !MapGuide's internal tile caching service to external applications. |
| | 26 | |
| | 27 | This component of the project would involve the development of a PHP "gateway" script that exposes a MapGuide tile cache as a TMS service. |
| | 28 | |
| | 29 | ==== GeoRSS ==== |
| | 30 | |
| | 31 | Adoption of [http://www.georss.org/ GeoRSS] as a simple method of sharing spatial information is growing rapidly. There are several compelling use cases for this. At the municipal level, it would be desirable to generate feeds of spatially related information such as recent fire calls, approved building permits, and road closures. |
| | 32 | |
| | 33 | This component of the project would involve the development of a PHP "gateway" script that allows the end user to configure the Geometry, Name, Description, and Modified Date from an existing feature source, and present this as a GeoRSS feed in any of Atom 1.0, RSS 1.0, and RSS 2.0 formats, leveraging the GeoRSS Simple and GML profiles. |
| | 34 | |
| | 35 | ==== REST-based feature retrieval ==== |
| | 36 | |
| | 37 | [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] is form of system architecture which defines unique URIs for each feature, and then applies methods against these URIs. This is different from a typical GET query string, where the parameters are somewhat arbitrary, and make it impossible to distinguish which parameters define the feature, which define the operation, and which control the output type. |
| | 38 | |
| | 39 | This component of the project would involve the development of a PHP "gateway" script that allows the end user to define a REST-based feature retrieval system from !MapGuide resources. A typical request might look something like this: |
| | 40 | |
| | 41 | GET !http://localhost:8008/mapguide/gateways/rest.php/parcels/231-232-534?accepts=application/vnd.google-earth.kml+xml |
| | 42 | |
| | 43 | or: |
| | 44 | |
| | 45 | GET !http://localhost:8008/mapguide/gateways/rest.php/parcels/231-232-534?representation=zoningmap&accepts=image/png |
| | 46 | |
| | 47 | In these cases, the user would have to configure how these requests are handled, and somehow publish the content-types and representations that are available. |
| | 48 | |
| | 49 | ''This component requires more input before submission.'' |
