Difference between revisions of "OSGeo Cartographic Engine"
m (→Functionality) |
|||
| (105 intermediate revisions by 32 users not shown) | |||
| Line 1: | Line 1: | ||
| + | '''Summer of Code 2010: This project has been proposed for [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2010_Ideas#The_ideas_pages SoC 2010]''' | ||
| + | |||
| + | '''JOIN MAILING LIST''': A list is now available for discussion around these concepts/ideas: [http://lists.osgeo.org/mailman/listinfo/carto Carto list]. | ||
| + | ----- | ||
| + | '''NOTE: This is not actually about building an API, rather about establishing some specifications for interaction between some common applications and a map production engine. ''' | ||
| + | ----- | ||
| + | [[Image:Carto_engine_v1.png | thumb | right | 300px | Conceptual overview]] | ||
| + | |||
== Motivation == | == Motivation == | ||
| + | To develop a common method and tools for printing high quality maps from a variety of mapping software. Starting with Mapnik as the renderer and QGIS, GRASS or others as the source application. Initial focus on building standards, then building command line tools or GUI tools. | ||
| + | |||
| + | There are plans for new/rewritten cartographic tools (map composer) for QGIS, as well as for GRASS. We suggest to develop a joint library for the various functions which could be shared across GRASS, QGIS and other projects with bindings to Qt, Python etc. The concept applies to all OSGeo projects in general as well - so high quality production can be something all projects have access to without having to code it from scratch in their own applications. | ||
| − | + | This applies to web mapping applications as well as desktop ones where high resolution, large format printing is required. But it also applies generally to smaller print jobs as well, e.g. high resolution laser printers. | |
| − | + | The GUI part for exporting layouts, etc. could be done within the individual software projects, while this project focuses on standard libraries or command line utilities to ''process'' compliant documents. The production of a printing interchange specification/standard is needed as well. An advanced layout tool in the form of a GUI would also be very useful. | |
| − | + | The concepts and idea below are quite diverse and represent a broad range of input. If a SoC student takes on this project, part of their job would be to help focus on a particular part of the problem (and possible clarify some of the others into workable sized components). | |
| − | + | == Ideas for Summer of Code 2010 Project == | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | This year the project will focus on building the capabilities using the [http://mapnik.org Mapnik] package due to its ability to output high quality vector maps. It supports XML based configuration files, but needs additions to handle the needs of this project. The QGIS [http://bitbucket.org/springmeyer/quantumnik/wiki/Home Quantumnik plugin] is an excellent example of moving toward the end goal of this project. Other applications may be considered too. | |
| − | * | + | Some further ideas to consider (add your own!!): |
| + | * An approach for transforming XML files from other applications into format compatible with Mapnik or this project specs | ||
| + | * How to handle caching web services at the proper resolution for printing? | ||
| + | * Consider icon collision handling | ||
| + | * Tweaking Mapnik and underlying Cairo library to handle text/font exporting better | ||
| + | * ...what else....? | ||
| − | + | A workplan might look like this, but is totally open to new ideas: | |
| + | |||
| + | # Review existing map definition standards (e.g. from a few desktop and web applications [[Configuration Files]]) | ||
| + | # Identify missing components from those standards. | ||
| + | # Create new specification or make a choice of existing one. Document the primary components as necessary for other app developers to build to its specification. | ||
| + | # Identify print-specific options/configuration (and challenges) needed for producing a hard copy. (see Potential Components below for an idea of overall concept) | ||
| + | # Write scripts to consume a compliant document and produce a output file - e.g. postscript, PDF or raster. (See discussion below re: output formats) | ||
| + | # If possible, write a sample GUI for one OSGeo project to use the specification. | ||
| − | + | == Potential Components == | |
| + | Breaking the end goal into some components will help to recognise which area(s) there is greatest need. There seems to be at least four primary components to the proposal. Any of these would be worth looking at, but it is not necessarily a final list. Add your ideas! | ||
| − | * | + | '''Style & Layout Configuration Standards''' |
| − | * | + | * Specifications for styling of features and layout of a map composition |
| − | + | * Could re-use existing approaches where applicable (e.g. SLD, WMC, MapServer Mapfile, OGR Feature Styles) | |
| − | + | * Specifications to be used in map definition/configuration files | |
| − | |||
| − | * | ||
| − | |||
| − | * | + | '''Graphical Style & Layout Editor''' |
| − | ** | + | * To create styles interactively |
| + | * To define map layout | ||
| + | * Could be stand-alone | ||
| + | * Could be adopted as part of another application | ||
| + | * Saves a style/layout definition document according to above standards | ||
| − | + | '''Graphical Map Composition Editor''' | |
| + | * Implemented by existing applications (e.g. GRASS, QGIS, etc.) | ||
| + | * Sets up pointers to data layers | ||
| + | * Assigns styles definitions to the layers | ||
| + | * Applies layout definition to maps | ||
| + | * Outputs a map composition configuration file | ||
| − | + | '''Rendering Engine''' | |
| + | * Stand-alone application (no GUI) | ||
| + | * Reads standard map composition configuration file | ||
| + | * Reads and applies the required style/layout definition documents | ||
| + | * Outputs final graphics to specific files | ||
| − | == | + | == See also == |
| − | * [[ | + | * [[OSGeo Cartographic Engine Discussion]] - more (original) detailed brainstorming and ideas |
| − | + | * [[OSGeo map symbol set]] | |
| − | * [[ | + | * [[Configuration Files]] |
| − | * [[ | + | * PAL - A cartographic labelling library ([http://pal.heig-vd.ch website], FOSS4G2008 [http://foss4g.org/index.php/foss4g/2008/paper/view/275 abstract], [http://mistic.heig-vd.ch/taillard/articles.dir/pal_foss2008.pdf PDF]) |
| − | * | + | * [[Programming Languages Project]] |
| − | |||
| − | * [[ | ||
[[Category: Software Stack]] | [[Category: Software Stack]] | ||
| + | [[Category: Printing]] | ||
Latest revision as of 22:42, 6 April 2010
Summer of Code 2010: This project has been proposed for SoC 2010
JOIN MAILING LIST: A list is now available for discussion around these concepts/ideas: Carto list.
NOTE: This is not actually about building an API, rather about establishing some specifications for interaction between some common applications and a map production engine.
Motivation
To develop a common method and tools for printing high quality maps from a variety of mapping software. Starting with Mapnik as the renderer and QGIS, GRASS or others as the source application. Initial focus on building standards, then building command line tools or GUI tools.
There are plans for new/rewritten cartographic tools (map composer) for QGIS, as well as for GRASS. We suggest to develop a joint library for the various functions which could be shared across GRASS, QGIS and other projects with bindings to Qt, Python etc. The concept applies to all OSGeo projects in general as well - so high quality production can be something all projects have access to without having to code it from scratch in their own applications.
This applies to web mapping applications as well as desktop ones where high resolution, large format printing is required. But it also applies generally to smaller print jobs as well, e.g. high resolution laser printers.
The GUI part for exporting layouts, etc. could be done within the individual software projects, while this project focuses on standard libraries or command line utilities to process compliant documents. The production of a printing interchange specification/standard is needed as well. An advanced layout tool in the form of a GUI would also be very useful.
The concepts and idea below are quite diverse and represent a broad range of input. If a SoC student takes on this project, part of their job would be to help focus on a particular part of the problem (and possible clarify some of the others into workable sized components).
Ideas for Summer of Code 2010 Project
This year the project will focus on building the capabilities using the Mapnik package due to its ability to output high quality vector maps. It supports XML based configuration files, but needs additions to handle the needs of this project. The QGIS Quantumnik plugin is an excellent example of moving toward the end goal of this project. Other applications may be considered too.
Some further ideas to consider (add your own!!):
- An approach for transforming XML files from other applications into format compatible with Mapnik or this project specs
- How to handle caching web services at the proper resolution for printing?
- Consider icon collision handling
- Tweaking Mapnik and underlying Cairo library to handle text/font exporting better
- ...what else....?
A workplan might look like this, but is totally open to new ideas:
- Review existing map definition standards (e.g. from a few desktop and web applications Configuration Files)
- Identify missing components from those standards.
- Create new specification or make a choice of existing one. Document the primary components as necessary for other app developers to build to its specification.
- Identify print-specific options/configuration (and challenges) needed for producing a hard copy. (see Potential Components below for an idea of overall concept)
- Write scripts to consume a compliant document and produce a output file - e.g. postscript, PDF or raster. (See discussion below re: output formats)
- If possible, write a sample GUI for one OSGeo project to use the specification.
Potential Components
Breaking the end goal into some components will help to recognise which area(s) there is greatest need. There seems to be at least four primary components to the proposal. Any of these would be worth looking at, but it is not necessarily a final list. Add your ideas!
Style & Layout Configuration Standards
- Specifications for styling of features and layout of a map composition
- Could re-use existing approaches where applicable (e.g. SLD, WMC, MapServer Mapfile, OGR Feature Styles)
- Specifications to be used in map definition/configuration files
Graphical Style & Layout Editor
- To create styles interactively
- To define map layout
- Could be stand-alone
- Could be adopted as part of another application
- Saves a style/layout definition document according to above standards
Graphical Map Composition Editor
- Implemented by existing applications (e.g. GRASS, QGIS, etc.)
- Sets up pointers to data layers
- Assigns styles definitions to the layers
- Applies layout definition to maps
- Outputs a map composition configuration file
Rendering Engine
- Stand-alone application (no GUI)
- Reads standard map composition configuration file
- Reads and applies the required style/layout definition documents
- Outputs final graphics to specific files
See also
- OSGeo Cartographic Engine Discussion - more (original) detailed brainstorming and ideas
- OSGeo map symbol set
- Configuration Files
- PAL - A cartographic labelling library (website, FOSS4G2008 abstract, PDF)
- Programming Languages Project