Difference between revisions of "MapGuide Wishes"
Jump to navigation
Jump to search
m |
|||
| Line 21: | Line 21: | ||
# Ability to publish data sources as GeoRSS feeds (would need date column, number of latest entries to publish, expression builder for title and contents, etc...) | # Ability to publish data sources as GeoRSS feeds (would need date column, number of latest entries to publish, expression builder for title and contents, etc...) | ||
# A full metadata storage and retreival service/front end that supports important relevant standards such as Z39.50 search, FGDC & ISO 19115 (TC211) metadata, and OGC Catalogue Services. Population of this should be integrated into the Studio load procedures, and the metadata for all of the layers in any specific map should be should be readily available from the map legend and from the API so that a custom metadata index listing could be developed. Addition of information around unmanaged data sets should also be permitted. Contact information, Locations, Departments, Organisations, etc should all be normalized in the metadata store rather than stored independantly for each dataset. | # A full metadata storage and retreival service/front end that supports important relevant standards such as Z39.50 search, FGDC & ISO 19115 (TC211) metadata, and OGC Catalogue Services. Population of this should be integrated into the Studio load procedures, and the metadata for all of the layers in any specific map should be should be readily available from the map legend and from the API so that a custom metadata index listing could be developed. Addition of information around unmanaged data sets should also be permitted. Contact information, Locations, Departments, Organisations, etc should all be normalized in the metadata store rather than stored independantly for each dataset. | ||
| − | # Full support for important OGC standards such as WFS-T | + | # Full support for important OGC standards such as WFS-T, SLD, WCS, etc... |
# Active Directory and LDAP integration | # Active Directory and LDAP integration | ||
# Support for dynamic KML with implementation as good or better than GeoServer. | # Support for dynamic KML with implementation as good or better than GeoServer. | ||
# Better support for unmanaged data sets | # Better support for unmanaged data sets | ||
| + | # Create method to convert geometry from polygon to line (MG147) | ||
| + | # Create method similar to centroid, but guaranteed to return a point within the parent polygon (MG148) | ||
| + | # Allow specification of lines and polygon borders in map units/mapping space (MG158) | ||
Revision as of 11:53, 25 July 2006
This page is should be used to capture ideas for MapGuide. Please provide comments in BOLD and your name in italic
- Include functions like reprojection, routing, network traces,geocoding, spatial overlays, proximity comparisons, reclassification, raster algebra, etc. All of the cool stuff that makes GIS GIS. COMMENT: XXXX NAME:JSmith
- Expose fundtions in the API
- Provide simple web service interfaces to reprojections functions etc..
- Use standards such as XML, GML, JPEG2000
- Use internal open mechanisms (such as AWKB)"
- Isolate the API from the web. Currently, to deploy a client-side app that communicates with the server, I need to load an entire web config file with paths that should not be required. Think of MapGuide as a geo-server, not as a web server.
- Support Python at least at the API level (if not at the web UI level)
- A layer between Layouts and Maps, allowing many maps to be integrated into a single layout, with a drop-down list allowing choice between them. This layout->map lookup layer should maintain for each map: *Theme name, *Map resource, *Reset or maintain current extents, *Active tools
- A cool "history" tool, with thumbnails of recent map states, allowing the user easy access to previous views.
- Enhanced server-to-server communication. Binary WFS???
- Projection of rasters on the fly.
- Projection support for WMS
- Redlining/markup tools that allow markup sessions to be stored to the server, shared with other users (fine-grained authorization) and saved out as DWF and SDF.
- Integration with an open IM tool for spatial-enabled chat
- Redlining sharing of current map state with other users
- Ability to define GeoRSS URLs as data sources
- Ability to publish data sources as GeoRSS feeds (would need date column, number of latest entries to publish, expression builder for title and contents, etc...)
- A full metadata storage and retreival service/front end that supports important relevant standards such as Z39.50 search, FGDC & ISO 19115 (TC211) metadata, and OGC Catalogue Services. Population of this should be integrated into the Studio load procedures, and the metadata for all of the layers in any specific map should be should be readily available from the map legend and from the API so that a custom metadata index listing could be developed. Addition of information around unmanaged data sets should also be permitted. Contact information, Locations, Departments, Organisations, etc should all be normalized in the metadata store rather than stored independantly for each dataset.
- Full support for important OGC standards such as WFS-T, SLD, WCS, etc...
- Active Directory and LDAP integration
- Support for dynamic KML with implementation as good or better than GeoServer.
- Better support for unmanaged data sets
- Create method to convert geometry from polygon to line (MG147)
- Create method similar to centroid, but guaranteed to return a point within the parent polygon (MG148)
- Allow specification of lines and polygon borders in map units/mapping space (MG158)