[OSM-dev] [OSM] Informations about osmarender for Google SoC

80n 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,
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080323/0b6e74a0/attachment.html>


More information about the dev mailing list