Mario wrote: > Hi 80n! :) > > >> JOSM is directed towards editing nodes, ways and relations. For the >> Osmarender frontend you want to be editing rules and styles. Not sure >> that JOSM helps much with that. >> > > My idea was to integrate this as an independent JOSM plugin only to let > the final user living with as few different programs as possible. IMHO, > this could improve the overall usability. There would be no direct > relation with JOSM code (perhaps, if it's possible, the plugin could > take the OSM file which JOSM is editing in the same time). > > >> 1) I'd imagine something that has a test .osm file and a complete rules >> file as input. It should then display the rendered test file and >> provide a way for the user to change the styling of any element >> (motorway, footway, river, building, etc). It should then emit a >> modified rules file. Once you have a solution that can edit styles, >> you'd then need to be able to add/remove/edit rules. This is a >> different kind of activity from editing styles. >> > > So, if I understood well.. I'm focusing these guidelines, which I'm > integrating with some ideas of mine: > 1) The user can edit overall options (found in > http://wiki.openstreetmap.org/index.php/Osmarender/Options) > > 2) There should be some way to add/remove/edit styles. My idea is to let > the user select from a list of the real CSS names and/or select from a > "modified name" (eventually hierarchical.. i.e. "stroke-width" becomes > "width" under menu "stroke", with some associated help tip) > > 3) Enter rules easily. This should be something like a "query editor" to > select "all kind of nodes like.." or "this node" (is there a way to pick > up a specified node in the original OSM? Sorry I've to study better :)) > and associate a style to it. > > 4) There should be a way to pass easily between styles and rules to > handle issues like "I've created a rule but I forgot to create the > associated style..." or "This style it's not what I wanted, I must > change that". > > 5) Node names or way names (or groups) can be selected through a kind of > pull down menu which filters the content of the original OSM file. > > 6) Symbols/areas can be selected by a text/visual selection, which > contains images extracted from symbol-catalogue.svg (or other collection > like that). In addition, it should accept custom symbols uploaded by the > user. > > 7) I think it could be great to let the user view tips somewhere in the > program, like what can be found in > http://wiki.openstreetmap.org/index.php/Osmarender/Tips, or what can be > found in http://wiki.openstreetmap.org/index.php/Osmarender_Styleguide. > These tips should be not the "tip-of-the-day", but I imagine something > more "target-oriented", so they will be viewed only in relevant areas of > the program. (for example, color tips should be viewed when I'm editing > a color style, not a width style :))) > > 8) Something useful could be optionally saving created > styles/rules/symbols (a sort of internal library). > > 9) This is a question more than a proposal. I can't understand how are > "osmarender:" tags are used. Should they be added to the OSM file before > applying styles and rules? > > In this case... it could be great to select single ways/areas directly > from the preview output.. but I'm starting to be visionary ;) ;) > > Please let me know if there is something I haven't understood well. > > >> It might be worth looking to see what can be done with Inkscape plugins. >> >> 2) Another approach would be to augment some generated svg with >> javascript and build a style/rule editing app that runs in a browser. >> This would probably be a bit more work than using, say, Inkscape, but >> could be a nice lightweight solution. >> > > Can you please explain better this approach? I'm figuring a "classic" > web app, with some AJAX to let the browser render any modified SVG file > the WYSIWYG way, and some javascript (or a Java servlet) to modify > styles/rules. Is this correct? > > Bye! > > Mario > > Mario, At SCALE a few of us discussed the idea of using Inkscape as a map editor and having a plug-in that would allow the movement of data in and out between OSM and Inkscape. The idea was not scoped out well enough to get on the OSM or Inkscape wiki page for GSoC ideas but is of interest to both projects. These might be some pretty big tasks so if of interest to you, you might want to break your proposal into several steps, with maybe just 1 of the steps to do this summer. If successful then the other steps could lead to future support as well. My guess is that the rule set editor and the map editor would be significantly different and large to be separate projects, however, it would make sense that everything would be coordinated to integrate well. In fact, even your idea of the rule editor might be large enough to break into several steps with only some of them able to get done in the summer. For example editing the symbols might be done via an Inkscape plugin and that could be a separate step which might or might not be able to get done this summer. It's important that you have 1 or more steps that you can finish this summer and have your project be a success within the Google procedures.
With SVG, XSLT does make some sense and I haven't looked closely at the rule set to understand why it's so much slower than a procedural language. While Perl is certainly powerful, it might not be good to have different modules coded in different languages across the project. And btw Inkscape plug-ins are set up for Python. _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
