Osmarender Frontend

From OpenStreetMap Wiki
Jump to navigation Jump to search

Osmarender Frontend Page

Shortcut to current online version and Shortcut to the screencast showing current features

Welcome to Osmarender Frontend brainstorming wiki page. Osmarender frontend has been my GSoC 2008 project.

This project has three main focuses:

  • Let the community propose enhancements to default Osmarender stylesheets the easy way
  • Let everyone out there render a custom map without knowing XML internals, just playing with a shiny GUI interface
  • Develop a Javascript API to let other developers contribute or start new projects

In the near future I'll publish more informations about the Javascript API (CMYK library, which is currently under deep refactoring to improve it) and the dojox-based widget (JUICE) used by Osmarender Frontend for editing CSS classes.

Progress report

You can see day by day progress in various ways:


You can download some screencasts of Osmarender Frontend in action, let's watch it growing up!

Where to Download

Please remember that there are (and there will be) two versions of Osmarender Frontend: one online and one offline version. So:

Online Version

Offline Version

You can download the offline version and use it as you want. With the offline version you can use any data file!

Old Demos

Old demos (pre-GSoC acceptance) can be found here.


You can find latest code version in the SVN trunk


Osmarender Frontend's manual for version 0.2 is available in

  • English
    • version 20080901: ODT or PDF format.
    • all revisions till 20080901: ODT
  • Italian
    • version 20080901: ODT or PDF format.
    • all revisions till 20080901: ODT


Please let me know your desires to improve Osmarender Frontend. Please sign/date every wish with 4 tildes..


Please let me know bugs you've found. Preferably you should use trac to do this (new ticket). Otherwise please sign/date every bug with 4 tildes..

  • Hi, I've found a bug. I live in Germany and we use comma instead of a point to write decimal numbers. Your program say, that numbers with points are incorrect and delete thepoint so I can't write coordinates. Could you please fix it? Thank you! --AndreR 01:11, 22 August 2008 (UTC)
    • Hi! As you can see in Probably Fixed Bugs section, for the moment you can try to install Quick Locale Switcher and change your Firefox locale to "en-us". I'm working to solve this really annoying bug, will post here to let you know when it'll be fixed. Merio 13:01, 22 August 2008 (UTC)
      • Bug seems to be workarounded for now (trunk and online version updated), but messages will be in English and no more localized for now. Seems to be a Dojo bug that doesn't let me override locale settings for number formats in the component without overriding locale settings for messages. I'll try a cleaner solution, but for the moment it works :) Merio 16:11, 22 August 2008 (UTC)

Known Bugs

  • Only innermost rules between classes and key/value pairs are considered. I've to improve the rule data model before.

Probably Fixed bugs

  • Some GUI (and perhaps model) mess when dialing with styles edited via spinners (especially with "px" suffix in Firefox 3 and with "invalid number" warning if browser has not US locales, for this you can use Quick Locale Switcher Firefox Extension)

I've tried to resolve this bug, I've tested it and it now works with any locale. However, if this problem appears to you, this is the known solution. Please let me know in this page if you encountered this error.


Actually, I've found these topics that could be useful for brainstorming. Please add any idea or nice-to-have feature in any topic separately. Any idea is welcome, and I'll do my best to take care of everything during my actual design phase. Obviously I've to stay in GSoC deadlines, so not everything can be achieved during GSoC. But there is so much time after the deadline :) Please sign/date every idea with 4 tildes.. so I know who's to thank :) Some of the features listed before any Suggestions section comes from our email discussion in the dev list when I was writing my application, so if you are the "asker" for any of listed features, feel free to modify.

Feel free to add new sections as you like and thank you very much for your help.


This section is user-centered: which features do we want? How the GUI should be designed (tabbed, wizard, colors to use,...)? What about the wiki-style gallery?


  • Open, Edit, Save rules/styles
  • WYSIWYG feedback
  • Can read OSM files to fetch key/value pairs and match them to styles, with some kind of "query editor" for multiple nodes/ways
  • Color picker for styles
  • CSS Editor
  • Input from test file, OSM file, bbox
  • Pass easily from styles to rules editing
  • I18n?
  • Import and export symbols
  • Handling of tangled styles (core/casing line for a road)
  • Can upload icons in any format (is it possible?)
  • Outputs for all data (OSM file, rules file, symbols)
  • Communication with OSMAPI e osmxapi
  • Perhaps with osmxapi we can fetch every node/way created by an user, to let anyone view only what he created (could be a cool feature for main page!)


  • example-data visualisation, where a lot of typical situations (park, crossing, many-level-crossing, cycleway, building pedestrian-area and more) help to decide (usually you don't have them in a small plan excerpt which will be your wysiwyg-screen)
  • nice editor for rendering-order. It is very important for the final map, which elements are rendered down and which up. Modifications should be possible (shiny tool with preview on example-data (and/or original map data) (which shows all interesting combinations like bridges, buildings, landuse as they typically occur in the real world) -- Dieterdreist 23:31, 29 April 2008 (UTC)
  • easy font-editor with the possibility to make an unlimited number of freely nameable templates, so you can assign different Text-sizes and fonts to different features. Easy possibility to change many of them. (ideally they should be ordered hierarchically and inherit or link properties/settings from their parents and it should be possible to change: all the elements (which means top-element) (e.g. all fonts from helvetica to times, all selected fonts 2 points bigger), or just one part (all streetnames (maybe level 2), all landuse (level 2?), all pedestrian AND area=yes (level 3?) ...). These templates or template-sets should be possible to save on disc (maybe together with other related data as one "mapfile"). When modifying the font type, the size should not change and vv. -- Dieterdreist 23:56, 29 April 2008 (UTC)
  • combined tag-parsing, so that more than just one tag is used (examplerule: use symbol for all points amenity=restaurant AND cuisine=pizza, examplerule2: use all highway=pedestrian AND area=yes)
  • don't know if it's possible, but: omit selective features: Click on the wysiwyg screen and select a streetname and mark it as not to render. If it was possible to do this for the whole part of the map that you want to render (and maybe even allow to change the positioning of writings) this would be a real nice way to goodlooking printed maps -- Dieterdreist 23:50, 29 April 2008 (UTC)

Use cases


GUI guidelines

  • Visual selection combo-box for SVG symbols
  • Task-oriented tips
  • Do not show real tags not to confuse any noop, try to use common words. Perhaps a double functionality (base and advanced) to give more advanced users more flexibility. Can take some example from JOSM.
  • Checkboxes for yes/no
  • Sliders for scale values
  • Preview for any rendering instruction (line, circle, text, etc) transforming in real-time a sample OSM file (i.e. that contains only a way); multiple previews if the rendering instruction applies to multiple features (node, way, etc). Drag and drop? to apply the style to nodes and ways selected by a rule (with preview of only them in the test file or in the OSM file giving reasonable length).
  • Faceted classification of features. Here a good article on how to code them


Wiki features

  • Compute automatically time for generation, show it along with the example uploaded in the wiki (perhaps with some other info integrated: browser, CPU, etc..)



This section is developer-centered: my application will be written in JavaScript, so there will be a standalone version. For my GSoC project, I've written that I want to develop public methods that anyone who wants can call to change Osmarender rules with a known JavaScript API, without even knowing how rules file works. A separated part will be instead in direct communication with PHP scripts on the server to upload new rules file to a wiki-style gallery.


I will post soon an image of the supposed architecture I've in mind. However feel free to add your suggestions.

  • OO Encapsulation of rules and styles (CSS and SVG styles). Give however the possibility, for advanced users, to edit css text directly with some help of existing javascript CSS editors. OO Encapsulation can be achieved, for example, by using some derivation of Interpreter pattern: [1] [2] [3] [4] [5]. This would give enough abstraction to deal with other renderers in the future. Beside any future integration, I might consider this article to model Osmarender's grammar into objects.




Potential Issues

Will my application (once used by users) cause some issue to servers? Please note that Osmarender's XSL transformation will be done all client-side, as you can see in the screencast and in the demo available in my older blog (Soon I'll transfer that data in my new blog).


My application will use OSMAPI to retrieve bbox data. Would this be a problem for the server? Although I will use osmxapi to retrieve only relevant data basing on Osmarender rules, if you see the demo, the application can select any single street, any single feature from the original OSM data. So retrieving a complete OSM file is a nice-to-have feature, instead of basing all styles editing on a test file.


Besides overloading the API server and thus preventing people editing the data, you'll have problems with the size of the bounding box when retrieving the data. I suggest you use OSMXAPI, which does not have any such limits and is intended for read-only access. Kosmos too will use OSMXAPI in the next version. --Breki 17:00, 14 May 2008 (UTC)


My application will talk with osmxapi to retrieve shrinked OSM files basing on Osmarender rules. Can this lead to any server issue?


Integration with the Slippy Map

One thing we can consider is a future integration with the slippy map to retrieve automatically the bbox, so improving usability. Please let me know your opinion!


  • nice idea. It would be ideal to select an area in the slippymap like the export function does (maybe use their code?) and then download the osm-data for this area and use custom/modified rendering-stylesheets to render just this area. -- Dieterdreist 00:08, 30 April 2008 (UTC)

Open Source Libraries/Programs

Some open source libraries out there can take care of some (sometimes boring) tasks, thus letting me reserve some time for more exciting improvements. I've already used some of them. Feel free to add your suggestions!

Software Design






  • Sarissa: Take care of browser quirks for DOM handling and XSLT
  • Javeline: Has an "all-Javascript" XSLT processor and XPath parser. It doesn't however support node-set() function
  • fvlogger: A nice and quick logging library for Javascript
  • Console Service: Perhaps I can listen to Firefox's console to catch messages from Osmarender's XSL, thus showing a sort of progress bar during rendering. Don't sure if possible though, perhaps using Firefox 3's Threads to run XSLT Processor.
  • Dojo:
    • Core library:
      • JSON handling
      • i18n API



The following are well-known cross-browser Javascript libraries for any GUI firework we could have. They also take care of internals with some kind of Javascript facility. Feel free to add any library you think can be useful to the project. If you want, you can look to these famous projects and tell me which widget/animation can be great to have and for which function for Osmarender Frontend. Obviously GUI fireworks are not assured for GSoC timeline ;)