On Sun, Mar 23, 2008 at 2:10 PM, Mario <[EMAIL PROTECTED]> 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). >
Possibly. There may be some benefit to using JOSM to define rules: 1) Create a way. 2) Tag with highway=motorway; layer=1; style=highway-motorway-casing, render-sequence=548 3) Define style somehow 4) Render using mapaint 5) Save as OSM file 6) Convert OSM file to Osmarender rules file > > 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) > The options are easy to edit in the XML file, and not changed often. Very low priority. Do this last, if at all. > > 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) > Osmarender can use the full power and extent of CSS, including cascading style definitions. Any CSS editor would need to be quite complex and very comprehensive. That's why I think starting with a good existing CSS editor would be a good idea. > > 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. Do you mean "select * from ways where highway=motorway and layer=1"? Much better would be to draw a line, using a graphical editor (JOSM perhaps) and then add highway=motorway to it. Then attach a style to it (style=highway-casing highway-motorway-casing). > > > 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". Yes, some validation to make sure that all referenced styles exist and a way of vacuuming redundant styles. > > > 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. > I don't understand this. > > 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. > Symbols are SVG files. No need for any additional complexity here. > > 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? Osmarender tags are rendering hints. They exist in the OSM data and are interpreted by the core rendering engine. I don't think they are relevant to your task. > > > 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? > Yes, exactly. > > Bye! > > Mario >
_______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
