[OSM-dev] [OSM] Informations about osmarender for Google SoC
80n80n at gmail.com
Sun Mar 23 15:36:26 GMT 2008
On Sun, Mar 23, 2008 at 2:10 PM, Mario <fadinlight at gmail.com> 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,
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
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
> 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
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
> > 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
> styles/rules. Is this correct?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev