On Sun, Mar 23, 2008 at 3:28 PM, MilesTogoe <[EMAIL PROTECTED]> wrote:
> 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. > I think Inkscape could be a very useful part of the solution for style editing. The Osmarender rules file comprises two major parts. The first part is the rendering rules which determine what nodes and ways get selected and how they are drawn. The second part is a list of CSS styles that are applied to each of the elements generated by the rendering rules. It seems to me that a good first step would be to find a way of using Inkscape to edit the CSS styles for a rules file. This is the most time consuming part of creating rules files as it currently requires a render between each edit iteration to be able to see the effect. Some method for working with and editing the rules themselves could then follow as a second step. 80n PS here's some info about how rule files are structured: A rule is something like this, which says select all nodes tagged with amenity=theatre and render a symbol with the specified size and offset: <rule e="node" k="amenity" v="theatre"> <symbol xlink:href="#theatre" width='1.75px' height='2.5px' transform='translate(-0.9,-1.25)'/> </rule> Or this which says, select all ways tagged with highway=motorway and if they are also tagged with area=yes then render a filled area, otherwise render a path using the specified styles: <rule e="way" k="highway" v="motorway"> <rule e="way" k="area" v="yes|true"> <area class='highway-core highway-motorway-area' /> </rule> <else> <line class='highway-core highway-motorway-core' /> </else> </rule> And the relevant styles are: .highway-core { stroke-linecap: square; stroke-linejoin: round; fill: none;} .highway-motorway-core { stroke-width: 1.7px; stroke: #809BC0; } .highway-motorway-area { stroke-width: 1.7px; stroke: #809BC0; fill: #809BC0; } The generated SVG will contain the styles verbatim and each generated path will reference those styles as per the rule file. > > 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
