[OSM-dev] Application draft for Google SoC

[Mario]

Hi!

I'm sending you the draft of my application about an osmarender 
frontend, so that you can comment on it if you want. Thanks again to you 
all for your help and suggestions throughout past week.

Mario

=======

*Project background*

Actually OSM counts on two engines to render map data: Osmarender and 
Mapnik. Both are able to work with a XML input file to modify the custom 
style of the resulting map, and both lack a GUI frontend to let 
XML-unaware people modify them. An usable GUI frontend would be a great 
enhancement for OSM spreading: the overall potential is there, but 
almost hidden to common people. I've started and then followed a very 
interesting discussion in the dev list to know community feelings and 
willings for a GUI frontend, focusing on Osmarender. I've read many 
different opinions about what an useful GUI frontend should be:
- Web application
- JOSM plugin
- Standalone application
- Inkscape plugin
I've also read many interesting opinions about features and 
enhancements, which I integrated with mine.

*Project*

I'm strongly convinced that a seriously user-oriented web application 
it's the way to go to spread OSM potential, and that's why I'm writing 
this application. I wish to start a proficuous developing of a WYSIWYG 
GUI frontend for Osmarender, which, given its core a XSLT sheet, is 
better web-oriented and more scalable, as all the rendering can be left 
to the client.
To achieve this goal, I'm proposing to develop a mixed Javascript/PHP 
web application. This will lead to a double service: XML rules and CSS 
styles handling will be Javascript encoded, so they will be available as 
a standalone application and will leave the server necessary only for 
strongly-needed tasks.

Key features
- Accepted inputs: test file, OSM files, lat/lon bounding box
- Outputs: SVG, PNG
- Communication through OSM API for OSM files retrieving
- Communication through osmxapi to retrieve shrinked OSM files
- Developing of an own JS API to handle rules files
- Wiki-style gallery to share custom rules and SVG symbols

Here logical architecture and corresponding features:

/Common Core (Innermost Model)/
- The rules/style handling core will be written in Javascript language. 
It'll have public (prototype) functions and a proper well-documented 
API, to let other contributors use it for other applications in the future.
- Reading, editing and writing "osm-map-features.xml" files (rules and 
styles)
- Handling of tangled CSS styles (i.e. core and casing lines for a road)
- A test file with common used OSM features to have a test preview
- Accepted input: OSM files

/Web Application Core (Outermost Model)/

- Including of custom SVG symbols in "osm-map-features.xml" by uploading 
SVG file
- Communication with OSM API to accept bounding box coordinates as input 
and automatic retrieving of corresponding OSM file
- Rules smart handling to communicate properly with Osmxapi and retrieve 
filtered OSM file to speed up rendering.
- Linking to SVG symbols libraries

/Common Wrapping (Innermost Controller)/
The core will be wrapped (called, indeed) under a layer which will 
include common functions for the outermost controller.

- XSLT transforming for file previewing
- Common Controller functions

/Web Application Wrapping (Outermost Controller)/
- List of SVG symbols/libraries available on server
- List of rules files available on server
- Upload custom SVG symbols and/or custom rules in server gallery
- SVG2PNG using Inkscape serverside, automatic for browser with bad SVG 
support.
- Downloading of all involved files (rules, SVG, PNG, separated or 
zipped together)

Then there will be a common GUI layer (Common View) and a web 
application one. The GUI will have facilities like a color-picker for 
CSS and wizard-style handling of rules. I'm leaving GUI features a 
little bit undefined because I prefer to better collaborate with OSM 
community to decide them, "opensource style".

Standalone application will have similar functionalities, given the 
limited possibilities:

/Standalone Core (Outermost Model)/
- Including custom SVG symbols (this will be achieved by cutting and 
pasting from a textarea)

/Standalone Wrapping (Outermost Controller)/
- List of SVG symbols available in the distribution
- List of rules files available (standard files like 
"osm-map-features-zXX.xml")
- Output to GUI of all involved files (rules, SVG) in a textarea


*What and how I'll achieve during SoC (Timeline)*

I'm perfectly aware that not all that I've written could be achieved in 
three months because of project's proportion: I want to be in strong 
contact with my mentor and OSM community, so many new and exciting 
features will come out. Furthermore, I know Murphy's law is everytime 
behind the corner :)
However with an incremental development, as described below, we'll get 
something perfectly functional by SoC ending anyway. Here the 
timeline,based on Google's:

- April 15 - May 26: I'll study more about OSM and Osmarender. I'll 
search any useful opensource libraries that can be included to speed 
development, keeping in contact with the dev list and/or my mentor (as 
needed) to better refine and analyse the architecture and define GUI 
usability guidelines.
/Deliverables:/ UML class hierarchy, GUI mockups, ER (rules gallery), API

- May 26 - end of June: I'll start to setup the project. First step will 
be the development of a rough working demo that permits XSLT 
transforming a test file with a textarea for rules file input. Then will 
come the common core to handle XML rules. I'll also develop the 
corresponding GUI elements. At this time, the application will not be 
aware of CSS classes (they will be in a textarea), so they will be 
referred through text fields.
/Deliverables:/ Working GUI demo that handles XML rules

- July: This month will be focused on CSS handling, wiki/gallery 
functions and output to PNG.
/Deliverables:/ CSS base handling, wiki/gallery functions, PNG export

- August (end of SoC): I'll focus on refining the overall functioning, 
including general debugging, revising of unit tests, documentation

*What I'll do to feedback OSM community*

I always pay attention to proper communication, also because I like 
feedbacking my works very much. During SoC I'll:

- Participate in the dev list
- document my code
- write unit tests
- document the API in the Wiki
- release often to the svn
- maintain a blog describing my progresses

*About Me*

My name is Mario Ferraro, and I'm studying Computer Engineering in 
Rome's University "La Sapienza". My interest for coding begun when I was 
9, trying to build something like a textual adventure in QBasic on an 
Intel 386. Since that day, I've started learning languages such as

- x86 Assembly (studying Randall Hyde's book)
- Object Pascal (Delphi)
- C/C++
- Javascript
- Java/Java servlet
- SQL (having worked with HSQLDB, MySQL and Oracle)

Having worked full time (and now part time, however I agreed not to work 
during SoC) for a roman web agency, I've now a strong background also on 
PHP 5 (using DB_DataObject, Image_Graph, XML_Serializer PEAR libraries 
and template engines like Smarty) and Web/XML-related technologies, such 
as XHTML, CSS (fixed or fluid layout), XSLT, DOM, XInclude, XPath, JSON, 
GoogleMaps API, etc. I grew a strong awareness of such technologies 
working on Backbase Enterprise Ajax framework also. I'm also experienced 
and/or interested on

- software design (using DBDesigner, Axure RP Pro, ArgoUML, Enterprise 
Architect)
- documentation (PHPDocumentor)
- test (PHPUnit, Selenium)
- debugging (Firebug, XDebug)
- software quality
- web accessibility (WCAG, Italian 4/2004 law, unobtrusive javascript)
- web usability
- information architecture

I applied most of these technologies and concepts developing an Italian 
Public Administration site, www.idromare.it